Руководство по системному администрированию#

Сценарии администрирования#

Настройка основных параметров системы#

В этом разделе описываются основы системного администрирования в DropApp Plus. Основное внимание уделяется задачам, которые системный администратор должен выполнить сразу после успешной установки и настройки.

При развертывании DropApp Plus, осуществляется работа с кластерами. Кластер состоит из набора nodes, которые запускают контейнерные приложения. Кластер DropApp имеет, как минимум, две worker nodes.

Управляющий слой (control plane), представляет собой совокупность master nodes и управляет worker nodes и pods в кластере DropApp Plus.

После установки администратор кластера может настроить следующие компоненты:

• node;

• кластер;

• сеть;

• хранилище;

• пользователи;

• оповещения и уведомления.

Настройка функций операционной системы#

Machine Config Operator управляет объектами MachineConfig. Используя Machine Config Operator, выполняются следующие задачи в кластере DropApp Plus:

• Настройка узлов с помощью MachineConfig объектов;

• Настройка пользовательских ресурсов, связанных с MachineConfig.

Оператор MachineConfig управляет и применяет конфигурацию и обновления базовой операционной системы и среды выполнения контейнера, включая все, что находится между ядром и kubelet.

Оператор MachineConfig содержит компоненты:

• machine-config-server: предоставляет конфигурацию Ignition новым машинам, присоединяющимся к кластеру;

• machine-config-controller: координирует обновление машин до желаемых конфигураций, определенных объектом MachineConfig. Предусмотрены опции для управления обновлением наборов машин по отдельности;

• machine-config-daemon: применяет новую конфигурацию машины во время обновления. Проверяет и отслеживает состояние машины в соответствии с запрошенной конфигурацией машины;

• machine-config: предоставляет полный источник конфигурации машины при установке, первом запуске и обновлениях машины.

Оператор MachineConfig управляет обновлениями systemd, CRI-O и Kubelet, ядра, Network Manager и других системных функций. Он также предлагает MachineConfigCRD, который может записывать файлы конфигурации на node.

Типы компонентов, которые MachineConfig может изменить, включают:

• config: создает объекты конфигурации Ignition, чтобы выполнять такие действия, как изменение файлов, системных служб и других функций на машинах с DropApp Plus:

  • Configuration files: создает или перезаписывает файлы в каталоге /var или /etc;

  • systemd unit: создает и устанавливает статус службы systemd или добавляет к существующей службе systemd с помощью дополнительных настроек;

  • users and groups: изменяет ключи SSH в разделе passwd после установки.

• kernelArguments: добавляет аргументы в командную строку ядра при загрузке nodes;

• kernelType: опционально указывает нестандартное ядро, которое будет использоваться вместо стандартного ядра. Командаrealtime позволяет использовать ядро RT (для RAN);

• extensions: расширяет возможности SberLinux OS Core, добавив выбранное предварительно упакованное программное обеспечение;

• Custom resources (для ContainerRuntime и Kubelet). Помимо конфигураций компьютера, MachineConfig управляет двумя специальными пользовательскими ресурсами для изменения настроек среды выполнения контейнера CRI-O (ContainerRuntime CR) и службы Kubelet (Kubelet CR).

Проверка состояния пула конфигурации машины#

1. Чтобы просмотреть количество nodes, управляемых Machine Config Operator и доступных в кластере для каждого пула конфигурации, выполните следующую команду:

   oc get machineconfigpool
   

   Пример вывода:

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-…         True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-…         False    True       False     3             2                  2                   0                     4h42m
   

   Где:

   • UPDATED - статус True указывает, что Machine Config Operator применил текущую конфигурацию машины к nodes в этом пуле конфигурации. Текущая конфигурация указывается в поле STATUS поле oc get mcp выходных данных. Статус False указывает, что node в пуле конфигураций обновляется.

   • UPDATING - статус True указывает, что Machine Config Operator применил желаемую конфигурацию машины, указанную в пользовательском ресурсе MachineConfigPool, по крайней мере, к одному из nodes в этом пуле конфигураций. Обновляемые nodes могут быть недоступны для планирования. Статус False указывает, что все nodes обновлены.

   • DEGRADED - статус True указывает, что Machine Config Operator заблокирован от применения текущей или желаемой конфигурации машины хотя бы к одному из nodes в этом пуле конфигурации или применение конфигурации не удалось. Nodes с пониженной производительностью могут быть недоступны для планирования. Статус False указывает, что все nodes готовы.

   • MACHINECOUNT - указывает общее количество машин в этом пуле конфигурации.

   • READYMACHINECOUNT - указывает общее количество машин в этом пуле конфигурации, готовых к планированию.

   • UPDATEDMACHINECOUNT - указывает общее количество машин в этом пуле конфигурации, имеющих текущую конфигурацию.

   • DEGRADEDMACHINECOUNT - указывает общее количество машин в этом пуле конфигурации, помеченных как устаревшие или несовместимые.

   В примере вывода есть три master nodes и worker nodes. Плоскость управления и связанные nodes обновляются до текущей конфигурации. Worker nodes обновляются до желаемой конфигурации машины. Две worker nodes обновляются, на это указывает UPDATEDMACHINECOUNT равное 2.

   Пока nodes обновляются, конфигурация машины, указанная в CONFIG, является текущей конфигурацией, с которой обновляется пул конфигурации. После завершения обновления указанная конфигурация машины будет желаемой, до которой был обновлен пул конфигурации.

2. Выполните проверку пула конфигурации путем вывода CRD.

Настройка функций кластера#

Администратору кластера доступны следующие ресурсы конфигурации основных функций кластера DropApp Plus:

• реестр образов;

• конфигурация сети;

• поведение сборки изображения;

• поставщик удостоверений;

• конфигурация etcd;

• создание комплекта машин для обработки рабочих нагрузок.

Для получения текущей документации по настройкам, которыми управляются эти ресурсы, используйте команду oc explain, например: oc explain builds --api-version=config.openshift.io/v1.

Все ресурсы конфигурации кластера имеют глобальную область действия (не в namespace) и имеют имена cluster:

Эти ресурсы конфигурации представляют собой экземпляры в области кластера с именем cluster, которые управляют поведением определенного компонента, принадлежащего конкретному оператору.

Ресурсы конфигурации оператора.

Выполнение операций с узлами#

По умолчанию DropApp Plus использует вычислительные машины Platform V SberLinux OS Core 8.9.1 (далее - SLC). В роли администратора доступны следующие операции в кластере:

• добавление и удаление вычислительных машин;

• добавление и удаление дефектов и доступов к машинам;

• настройка максимального числа pods на машину.

Добавление вычислительных машин в кластер#

Предварительные условия:

• кластер успешно установлен;

• образы SLC, которые использовались для создания кластера, доступны;

• получен URL-адрес файла конфигурации Ignition для worker nodes кластера. Этот файл загружен на HTTP-сервер во время установки.

Выполните следующую последовательность действий:

1. Используйте файл ISO для установки SLC на большем количестве worker nodes. Метод установки описан в документе «Руководство по установке».

2. После загрузки экземпляра нажмите клавишу TAB или E для редактирования командной строки ядра.

3. Добавьте параметры в командную строку ядра:

   coreos.inst.install_dev=sda # Укажите блочное устройство системы, на которую будет производиться установка.
   coreos.inst.ignition_url=http://example.com/worker.ign # Укажите URL-адрес файла конфигурации вычислений Ignition. Поддерживаются только протоколы HTTP и HTTPS.
   

4. Нажмите Enter, чтобы завершить установку. После установки SLC система перезагрузится. После перезагрузки применится указанный файл конфигурации Ignition.

5. Повторите шаги 1-4 в зависимости от количества необходимых worker nodes для кластера.

Настройка сети#

После установки DropApp Plus доступны для настройки следующие сетевые параметры:

• входящий трафик кластера;

• диапазон обслуживания порта узла;

• сетевая политика;

• включение прокси-сервера на уровне кластера.

Конфигурация оператора сети кластера.

Конфигурация сети кластера указывается как часть конфигурации оператора сети кластера (CNO) и хранится в объекте настраиваемого ресурса (CR) с именем cluster. CR указывает поля для NetworkAPI в operator.openshift.io группе API.

Конфигурация CNO наследует следующие поля во время установки кластера от NetworkAPI в Network.config.openshift.io группе API, и эти поля нельзя изменить:

• clusterNetwork- пулы IP-адресов, из которых выделяются IP-адреса pods;

• serviceNetwork - пул IP-адресов для сервисов;

• defaultNetwork.type - поставщик кластерной сети, например, OVN-Kubernetes.

Настройка хранилища#

По умолчанию контейнеры работают с использованием эфемерного хранилища или временного локального хранилища. Эфемерное хранилище имеет ограничение по сроку службы. Чтобы хранить данные в течение длительного времени, необходимо настроить постоянное хранилище. Настроить хранилище можно одним из следующих способов:

• динамическое предоставление. Выделение хранилища по требованию, определяя и создавая классы хранения, которые управляют различными уровнями хранилища, включая доступ;

• статическое представление. Использование постоянных томов Kubernetes, чтобы сделать существующее хранилище доступным для кластера. Статическая подготовка может поддерживать различные конфигурации устройств и варианты подключения.

Объект StorageClass описывает и классифицирует хранилище, которое может быть запрошено, а также предоставляет средства для передачи параметров для динамически предоставляемого хранилища по требованию. StorageClass-объекты также могут служить механизмом управления различными уровнями хранения и доступом к хранилищу. Администраторы кластера определяют и создают StorageClass-объекты, которые пользователи могут запрашивать без необходимости каких-либо подробных знаний об источниках базовых томов хранения.

Платформа постоянных томов обеспечивает эту функцию и позволяет администраторам предоставлять кластеру постоянное хранилище. Платформа также дает пользователям возможность запрашивать эти ресурсы, не зная базовой инфраструктуры.

Многие типы хранилищ доступны для использования в качестве постоянных томов. Хотя все они могут быть предоставлены администратором статически, некоторые типы хранилищ создаются динамически с использованием встроенных API-интерфейсов поставщика и плагина.

Подробнее см. «Сценарии использования опциональных компонентов» -> «CSI».

Настройка пользователей#

Токены доступа OAuth позволяют пользователям аутентифицироваться в API. Для администратора кластера доступна настройка OAuth для выполнения следующих задач:

• указание поставщика удостоверений;

• использование управления доступом на основе ролей для определения и предоставления разрешений пользователям;

• установка оператора из OperationHub.

По умолчанию kubeadmin в кластере существует только пользователь. Чтобы указать поставщика удостоверений, необходимо создать настраиваемый ресурс (CR), описывающий этого поставщика удостоверений, и добавить его в кластер.

Следующий пользовательский ресурс (CR) показывает параметры и значения по умолчанию, которые настраивают поставщика удостоверений. В этом примере используется поставщик удостоверений htpasswd:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: my_identity_provider # Это имя поставщика добавляется к именам пользователей для формирования идентификационного имени
    mappingMethod: claim # Управляет тем, как устанавливаются сопоставления между удостоверениями и User-объектами этого поставщика
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret # Существующий секрет, содержащий файл, созданный с использованием htpasswd.

Управление оповещениями и уведомлениями#

По умолчанию оповещения о срабатывании отображаются в пользовательском интерфейсе оповещений веб-консоли.

По умолчанию оповещения не настроены на отправку в какие-либо системы уведомлений. Возможно настроить OKD для отправки оповещений следующим типам получателей:

• PagerDuty;

• Webhook;

• Email;

• Slack.

Маршрутизация оповещений получателям позволяет отправлять своевременные уведомления соответствующим группам при возникновении сбоев. Например, критические оповещения требуют немедленного внимания и обычно передаются отдельному пользователю или группе реагирования на критические ситуации. Оповещения, содержащие некритические предупреждения, вместо этого могут быть направлены в систему обработки заявок для несрочного рассмотрения.

Проверка работоспособности оповещений с помощью сторожевого таймера.

Мониторинг включает в себя постоянно срабатывающее сторожевое оповещение. Alertmanager неоднократно отправляет уведомления о предупреждениях сторожевого таймера настроенным поставщикам уведомлений. Поставщик обычно настроен на уведомление администратора, когда перестает получать оповещения сторожевого таймера. Этот механизм помогает быстро выявить любые проблемы связи между Alertmanager и поставщиком уведомлений.

Настройте приемники оповещений, чтобы получать информацию о важных проблемах в кластере:

1. В качестве администратора перейдите в раздел «Administration» → «Cluster Settings» → «Global Configuration» → «Alertmanager».

   Альтернативно можно перейти на ту же страницу через панель уведомлений. Щелкните значок колокольчика в правом верхнем углу веб-консоли OKD и выберите «Configure» в оповещении AlertmanagerReceiverNotConfigured.

2. Выберите «Create Receiver» в разделе «Receivers».

   В форме «Create Receiver» добавьте имя получателя и выберите тип получателя из списка.

Сценарии использования опциональных компонентов DropApp Plus#

Компоненты дистрибутива DropApp, которые могут быть использованы при реализации сценариев с данными компонентами, представлены в документе Руководство по установке в разделе «Состав дистрибутива DropApp».

API-server#

API-server — это центральный компонент кластера DropApp Plus. Он является связывающим компонентом для всех остальных сервисов. Все взаимодействие как самих компонентов, так и обращение извне к кластеру проходит через kube-apiserver и проверяется им.

Это единственный компонент кластера DropApp Plus, который общается с базой данных etcd, где хранится состояние кластера DropApp Plus.

API-Server не принимает решения, например, за то, на каком node запустить тот или иной сервис.

В нем существует логика проверки формата запросов, аутентификации, проверки прав и т.д.

Еще одной функцией API-Server является рассылка изменений конфигураций и состояния кластера DropApp Plus.

Другие компоненты подписываются на события, отслеживают их и обрабатывают, либо с определенной периодичностью считывают конфигурацию через API-Server.

Kube-scheduler#

Kube-scheduler — это компонент управляющего слоя, с его помощью необходимо отслеживать созданные pods без привязанного node и осуществлять выбор node, на котором pods должны работать. При развертывании pods на node учитывается множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) nodes/pods, местонахождения данных, предельных сроков.

Используя механизм оповещения об изменениях API-Server, kube-scheduler получает сообщения от управляющего слоя, когда необходимо запустить экземпляр сервиса и принимает решение о том, на каком node он должен быть запущен, и через API-server обновляет состояние кластера DropApp Plus. Сам kube-scheduler ничего не запускает.

Controller-manager#

Controller-manager - это компонент, отвечающий за запуск контроллеров, которые определяют текущее состояние системы.

Каждый контроллер представляет собой отдельный процесс, и для упрощения все такие процессы скомпилированы в один двоичный файл и выполняются в одном процессе.

Эти контроллеры включают:

• контроллер node (Node Controller): уведомляет и реагирует на сбои node;

• контроллер репликации (Replication Controller): поддерживает правильное количество pods для каждого объекта контроллера репликации в системе;

• контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (Endpoints), то есть связывает сервисы (Services) и pods;

• контроллеры учетных записей и токенов (Account & Token Controllers): создают стандартные учетные записи и токены доступа API для новых namespaces.

Kube-rbac-proxy#

Kube-rbac-proxy — это HTTP-прокси для одного исходящего потока, который может выполнять авторизацию RBAC для DropApp Plus API с помощью SubjectAccessReview.

В кластерах DropApp Plus без применения сетевой политики любой pod может выполнять запросы к любому другому pod в кластере. kube-rbac-proxy применяется для ограничения запросов только теми модулями, которые предоставляют действительный и авторизованный RBAC токен или клиентский TLS-сертификат.

Преимущества использования kube-rbac-proxy:

• разгружает API DropApp Plus, чтобы он мог обрабатывать фактические запросы, связанные с компонентами кластера, а не запросы от клиентов;

• принимает входящие HTTP-запросы, это позволяет гарантировать, что запрос авторизован и имеет право доступа к приложению, а не просто имеет сетевой доступ к объекту.

При входящем запросе kube-rbac-proxy выясняет, какой пользователь выполняет запрос. Он поддерживает использование клиентских TLS-сертификатов, а также токенов. В случае использования сертификата, он проверяется настроенным центром сертификации.

После того как пользователь прошел аутентификацию, снова используется authentication.k8s.io для выполнения SubjectAccessReview, чтобы авторизовать соответствующий запрос и убедиться, что аутентифицированный пользователь имеет необходимые роли RBAC.

У kube-rbac-proxy есть все glog флаги для ведения журнала. Чтобы использовать опциональный компонент, установите несколько флагов:

• --upstream: - исходящий поток проксирования;

• --config-file: - файл, в котором указаны сведения о SubjectAccessReview, их необходимо выполнить по запросу. Например, можно указать, что объекту, выполняющему запрос, должно быть разрешено выполнять развертывание get pod с названием my-frontend-app.

Все флаги командной строки kube-rbac-proxy представлены в таблице.

Таблица. Флаги командной строки kube-rbac-proxy.

RBAC различается по двум типам, которые необходимо авторизовать: ресурсные и нересурсные. Например, авторизация запроса ресурса может заключаться в том, что запрашивающему объекту необходимо авторизоваться для выполнения действия get при развертывании DropApp.

Выполните следующие действия для защиты приложения с помощью kube-rbac-proxy (в примере ниже - prometheus-example-app). В этом примере запрашивающему объекту разрешено вызывать подресурс proxy в службе DropApp Plus с именем kube-rbac-proxy. Это настраивается в файле, переданном kube-rbac-proxy с флагом --config-file. Кроме того, необходимо установить флаг --upstream для настройки приложения, которое должно быть проксировано при успешной аутентификации и авторизации.

Kube-rbac-proxy также требует доступа RBAC для выполнения TokenReviews, а также SubjectAccessReviews. Это API-интерфейсы, доступные в DropApp Plus API для аутентификации и последующей проверки авторизации объекта.

Установка Kube-rbac-proxy#

Предварительные условия#

Предварительными условиями для установки Kube-rbac-proxy являются:

• развернут кластер DropApp Plus;

• установлен oc.

Установка#

Для установки Kube-rbac-proxy:

1. Создайте файл yaml:

   Создайте deployment.yaml в DropApp Plus с использованием файла deployment.yaml, как представлено ниже.

   Команда oc create позволяет создать deployment на основе файла deployment.yaml, который содержит описание приложения и его настроек. Файл deployment.yaml может содержать информацию о контейнерах, ресурсах, настройках сети и другие параметры, необходимые для создания и управления deployment.

   oc create -f deployment.yaml
   

2. Внесите при помощи текстового редактора, следующее содержание манифеста:

   Пример настроек kube-rbac-proxy.yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: kube-rbac-proxy
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: kube-rbac-proxy
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: kube-rbac-proxy
   subjects:
   - kind: ServiceAccount
     name: kube-rbac-proxy
     namespace: default
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: kube-rbac-proxy
   rules:
   - apiGroups: ["authentication.k8s.io"]
     resources:
     - tokenreviews
     verbs: ["create"]
   - apiGroups: ["authorization.k8s.io"]
     resources:
     - subjectaccessreviews
     verbs: ["create"]
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: kube-rbac-proxy
     name: kube-rbac-proxy
   spec:
     ports:
     - name: HTTPs
       port: 8443
       targetPort: HTTPs
     selector:
       app: kube-rbac-proxy
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kube-rbac-proxy
   data:
     config-file.yaml: |+
       authorization:
         resourceAttributes:
           namespace: default
           apiVersion: v1
           resource: services
           subresource: proxy
           name: kube-rbac-proxy
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: kube-rbac-proxy
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: kube-rbac-proxy
     template:
       metadata:
         labels:
           app: kube-rbac-proxy
       spec:
         securityContext:
           runAsUser: 65532
         serviceAccountName: kube-rbac-proxy
         containers:
         - name: kube-rbac-proxy
           image: quay.io/brancz/kube-rbac-proxy:v0.14.1
           args:
           - "--secure-listen-address=0.0.0.0:8443"
           - "--upstream=HTTP://127.0.0.1:8081/"
           - "--config-file=/etc/kube-rbac-proxy/config-file.yaml"
           - "--logtostderr=true"
           - "--v=10"
           ports:
           - containerPort: 8443
             name: HTTPs
           volumeMounts:
           - name: config
             mountPath: /etc/kube-rbac-proxy
           securityContext:
             allowPrivilegeEscalation: false
         - name: prometheus-example-app
           image: quay.io/brancz/prometheus-example-app:v0.1.0
           args:
           - "--bind=127.0.0.1:8081"
         volumes:
         - name: config
           configMap:
             name: kube-rbac-proxy
   

   Примечание

   IP адреса являются ненастоящими и приведены в качестве примера.

3. Разверните объект Job, который выполняет curl, чтобы протестировать приложение prometheus-example-app. Поскольку он имеет правильные роли RBAC - запрос будет выполнен успешно:

   oc create -f client-rbac.yaml client.yaml
   

   Это команда для создания клиента RBAC. В данном случае, команда создает два файла: client-rbac.yaml и client.yaml. Файл client-rbac.yaml описывает клиента RBAC и содержит информацию о пользователях, группах и ролях, которые будут иметь доступ к ресурсам кластера. Файл client.yaml содержит конфигурацию клиента, включая его имя, IP-адрес и другие параметры.

   После выполнения команды oc create, клиент будет создан и готов к использованию.

4. Внесите при помощи текстового редактора, следующее содержание манифеста:

   Пример манифеста

   apiVersion: rbac.authorization v1
   kind: ClusterRole
   metadata:
     name: kube-rbac-proxy-client
   rules:
   - apiGroups: [""]
     resources: ["services/proxy"]
     verbs: ["get"]
   ---
   apiVersion: rbac.authorization v1
   kind: ClusterRoleBinding
   metadata:
     name: kube-rbac-proxy-client
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: kube-rbac-proxy-client
   subjects:
   - kind: ServiceAccount
     name: default
     namespace: default
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: krp-curl
   spec:
     template:
       metadata:
         name: krp-curl
       spec:
         containers:
         - name: krp-curl
           image: quay.io/brancz/krp-curl:v0.0.2
         restartPolicy: Never
     backoffLimit: 4
   

   При просмотре журнала вывод должен отображать следующее содержание:

   oc logs job/krp-curl
   
   *   Trying 10.111.34.206...
   * TCP_NODELAY set
   * Connected to kube-rbac-proxy.default.svc (10.111.34.206) port 8080 (#0)
   > GET /metrics HTTP/1.1
   > Host: kube-rbac-proxy.default.svc:8080
   > User-Agent: curl/7.57.0
   > Accept: */*
   > Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5clkLKJlkLK;lknLKnmLKNlknlkn:LkhGfgufiytFl[p;":lpl";l'kX
   >
   < HTTP/1.1 200 OK
   < Content-Type: text/plain; version=0.0.4
   < Date: Sun, 17 Dec 2017 13:34:26 GMT
   < Content-Length: 102
   <
   { [102 bytes data]
   * Connection #0 to host kube-rbac-proxy.default.svc left intact
   # Информация о версии этого бинарного файла
   version{version="v0.1.0"} 0
   

   Примечание

   IP адреса являются ненастоящими и приведены в качестве примера.

Machine API Operator#

Machine API Operator (MAO) - оператор, который обеспечивает управление физическими серверами и виртуальными машинамии, автоматизацию развертывания виртуальных машин в кластере DropApp Plus. Путем использования машинного API оператор позволяет управлять жизненным циклом виртуальных машин, их масштабированием, мониторингом и управлением ресурсами.

Machine API Operator поддерживает автоматическое назначение IP-адресов при создании новых виртуальных машин.

Machine API Operator управляет жизненным циклом CRD - пользовательского определения ресурса, контроллеров и объектов RBAC определенного назначения, которые расширяют Kubernetes API. Это позволяет декларативно передавать желаемое состояние машин в кластере.

Контроллеры#

• MachineSet Controller - контроллер машинного набора;

  Убедитесь в наличии ожидаемого количества реплик и заданной конфигурации провайдера для набора машин.

• Machine Controller - контроллер машины;

  Убедитесь, что экземпляр provider создан для объекта Machine в данном поставщике.

• machine-api-provider-aws;

• machine-api-provider-gcp;

• machine-api-provider-azure;

• cluster-api-provider-libvirt;

• cluster-api-provider-openstack;

• cluster-api-provider-baremetal;

• cluster-api-provider-ovirt;

• cluster-api-provider-ibmcloud;

• Nodelink Controller - контроллер Nodelink;

  Убедитесь, что у машин есть nodeRef на основе IP-адресов или соответствия providerId. Пометьте nodes меткой, содержащей имя машины.

• MachineHealthCheck Controller - контроллер проверки работоспособности машины.

  Убедитесь, что машины, на которые нацелены объекты MachineHealthCheck, удовлетворяют критериям работоспособности или исправлены иным образом.

Создание машин#

Создайте новую машину, применив манифест, представляющий экземпляр CRD-машины:

apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: clusterID
    machine.openshift.io/cluster-api-machine-role: role
    machine.openshift.io/cluster-api-machine-type: role
  name: machineName
  namespace: openshift-machine-api
spec:
  providerSpec:
    value:
      kind: AWSMachineProviderConfig
      ami:
        id: ami-0df3f99538fbef10f
      apiVersion: awsproviderconfig.openshift.io/v1beta1
      blockDevices:
        - ebs:
            iops: 0
            volumeSize: 120
            volumeType: gp2
      credentialsSecret:
        name: aws-cloud-credentials
      deviceIndex: 0
      iamInstanceProfile:
        id: clusterID-worker-profile
      instanceType: m5.large
      placement:
        availabilityZone: us-east-1a
        region: us-east-1
      securityGroups:
        - filters:
            - name: tag:Name
              values:
                - clusterID-worker-sg
      subnet:
        filters:
          - name: tag:Name
            values:
              - clusterID-private-us-east-1a
      tags:
        - name: kubernetes.io/cluster/clusterID
          value: owned
      userDataSecret:
        name: worker-user-data

Метка machine.openshift.io/cluster-api-cluster будет использоваться контроллерами для поиска нужного экземпляра облака.

Установите другие метки для предоставления пользователям удобного способа получения групп машин:

machine.openshift.io/cluster-api-machine-role: worker
machine.openshift.io/cluster-api-machine-type: worker

Разработка#

• Сгенерируйте код:

  make generate
  

• Создайте сборку:

  make build
  

• Извлеките images.json в файл из install/0000_30_machine-api-operator_01_images.configmap.yaml и запустите:

  ./bin/machine-api-operator start --kubeconfig ${HOME}/.kube/config --images-json=path/to/images.json
  

• Создайте образ:

  make image
  

Machine API Operator предназначен для работы совместно с Cluster Version Operator.

Развертывание Machine API Operator с Kubemark#

1. Разверните MAO через DropApp Plus:

   kustomize build | oc apply -f -
   

2. Предварительные требования для развертывания Kubemark actuator:

   kustomize build config | oc apply -f -
   

3. Создайте cluster infrastructure.config.openshift.io, чтобы сообщить MAO о развертывании поставщика kubemark:

   apiVersion: apiextensions.k8s.io/v1beta1
   kind: CustomResourceDefinition
   metadata:
     name: infrastructures.config.openshift.io
   spec:
     group: config.openshift.io
     names:
       kind: Infrastructure
       listKind: InfrastructureList
       plural: infrastructures
       singular: infrastructure
     scope: Cluster
     versions:
     - name: v1
       served: true
   storage: true
   ---
   apiVersion: config.openshift.io/v1
   kind: Infrastructure
   metadata:
     name: cluster
   status:
     platform: kubemark
   

4. Запустите файл конфигурации config/kubemark-config-infra.yaml:

   oc apply -f config/kubemark-config-infra.yaml
   

Machine image customization controller#

Machine image customization controller - это контроллер для настройки образов в DropApp Plus. Отвечает за управление и обновление образов контейнеров, развернутых в кластере. Он может использоваться для настройки параметров образа, таких как переменные окружения, секреты и другие настройки конфигурации. Работая с Machine image customization controller, можно легко внести изменения в образы контейнеров в кластере DropApp Plus без необходимости повторного развертывания всего приложения.

Создание образа#

Сетевые данные для каждого хоста должны быть в формате NMState под ключом с именем nmstate в секрете, указанном в networkDataName в поле PreprovisioningImage.

Все PreprovisioningImage файлы с меткой infraenvs.agent-install.openshift.io будут проигнорированы этим контроллером.

Сгенерированные URL-адреса являются случайными и изменятся при перезапуске контроллера.

Сохраняется только файл Ignition для каждого образа. При получении HTTP-запроса веб-сервер генерирует поток с архивом CPIO, содержащим файл Ignition и добавленный к initramfs. Поддерживаются запросы диапазона HTTP.

Настройки среды#

Требуются следующие переменные среды:

• IRONIC_AGENT_IMAGE;

• DEPLOY_ISO;

• DEPLOY_INITRD.

Опциональны следующие переменные среды:

• IRONIC_BASE_URL;

• IRONIC_INSPECTOR_BASE_URL;

• IRONIC_AGENT_PULL_SECRET;

• IRONIC_AGENT_VLAN_INTERFACES;

• IRONIC_RAMDISK_SSH_KEY;

• REGISTRIES_CONF_PATH;

• IP_OPTIONS;

• HTTP_PROXY;

• HTTPS_PROXY;

• NO_PROXY.

Запуск контроллера#

Двоичный файл контроллера - /machine-image-customization-controller.

Для настройки используются следующие флаги командной строки:

• -namespace - namespace, который отслеживает контроллер для согласования ресурсов preprovisioningimage;

• -images-bind-addr - адрес и порт для привязки к веб-серверу;

• -images-publish-addr - адрес, с которого клиенты будут получать доступ к конечной точке образа.

Статическая работа#

Существует также отдельный двоичный файл, /machine-image-customization-server, который запускает веб-сервер с использованием статических конфигурационных файлов, а не как контроллер DropApp Plus.

Для настройки используются следующие флаги командной строки:

• -nmstate-dir - расположение статических файлов NMState;

• -images-bind-addr - адрес и порт для привязки к веб-серверу;

• -images-publish-addr - адрес, с которого клиенты будут получать доступ к конечной точке образа.

Сluster-storage-operator#

Cluster Storage Operator - это инструмент, предназначенный для автоматизации развертывания, масштабирования и управления хранилищем данных, таким как Persistent Volumes (PV), Persistent Volume Claims (PVC) или Storage Classes, в кластере DropApp Plus.

Cluster Storage Operator позволяет упростить процесс управления хранилищем данных с помощью изменения настроек и управления данной частью инфраструктуры. Он также может обеспечивать более надежное и эффективное использование хранилища данных в кластере DropApp Plus.

Также Cluster Storage Operator обеспечивает установку плагинов тома CSI по умолчанию (см. «Сценарии использования опциональных компонентов» -> «CSI»).

Cluster-openshift-apiserver-operator#

Оператор Kubernetes API Server управляет и обновляет сервер Kubernetes API, развернутый поверх OpenShift. Оператор основан на платформе Go библиотеки OpenShift и устанавливается через оператор версии кластера (CVO).

Он содержит следующие компоненты:

• Operator;

• Bootstrap manifest renderer;

• Installer based on static pods;

• Configuration observer.

По умолчанию оператор предоставляет метрики Prometheus через сервис. Метрики собираются из компонента Kubernetes API Server Operator.

Configuration observer отвечает за реагирование на внешние изменения конфигурации. Например, это позволяет внешним компонентам (registry, etcd и т.д.) взаимодействовать с конфигурацией Kubernetes API (пользовательский ресурс KubeAPIServerConfig).

Operator также предоставляет события, которые могут помочь в отладке проблем. Чтобы получить события оператора, выполните следующую команду:

oc get events -n  openshift-cluster-kube-apiserver-operator

Этот оператор настраивается через CRD KubeAPIServerс:

oc describe kubeapiserver

apiVersion: operator.openshift.io/v1
kind: KubeAPIServer
metadata:
name: cluster
spec:
managementState: Managed

Текущий статус оператора сообщается с помощью ресурса ClusterOperator. Чтобы получить текущий статус, выполните следующую команду:

oc get clusteroperator/kube-apiserver

Etcd#

Etcd — это высоконадежное распределенное хранилище данных. DropApp Plus хранит в нем информацию о состоянии существующих кластеров DropApp Plus, сервисах, сети и т.д.

Доступ к данным осуществляется через REST API. При изменениях записей, вместо поиска и изменения предыдущей копии, все предыдущие записи помечаются как устаревшие, а новые значения записываются в конец. Позже устаревшие значения удаляются специальным процессом. В важных системах, требующих избыточности и высокой доступности, etcd следует создавать в виде кластера, состоящего из нескольких nodes.

API server является основной точкой управления всего кластера DropApp. Он обрабатывает операции REST, проверяет их и обновляет соответствующие объекты в etcd. API server обслуживает DropApp Plus API и задуман как простой сервер, с большей частью бизнес-логики, реализованной в отдельных компонентах или в плагинах. Ниже приведены некоторые примеры API, доступных на сервере API.

# pods
api/v1/pods

# services
api/v1/services

# deployments
api/v1/deployments

Когда происходит работа с кластером DropApp Plus с использованием oc интерфейса командной строки, взаимодействие осуществляется с основным серверным компонентом API. Команды oc преобразуются в HTTP-вызовы REST и вызываются на сервере API. API server также отвечает за механизм аутентификации и авторизации. Все клиенты API должны быть аутентифицированы для взаимодействия с сервером API. Возможно написание клиентских библиотек/приложений DropApp Plus, используя API server.

Сluster-ingress-operator#

Сluster-ingress-operator — это компонент DropApp Plus, который обеспечивает внешний доступ к службам кластера путем настройки контроллеров Ingress, которые маршрутизируют трафик, как указано в ресурсах OpenShift Route и Kubernetes Ingress.

Чтобы обеспечить эту функциональность, Сluster-ingress-operator развертывает и управляет входным контроллером Kubernetes на базе HAProxy.

Сluster-ingress-operator реализует API входного контроллера OpenShift.

Сluster-ingress-operator — это основная функция DropApp Plus, которая включена по умолчанию.

Каждая новая установка имеет ingresscontroller с именем default, которое можно настроить, заменить или добавить экземпляры ingresscontroller. Чтобы просмотреть входной контроллер по умолчанию, используйте команду:

oc describe --namespace=openshift-ingress-operator ingresscontroller/default

Создавайте и редактируйте ресурсы ingresscontroller.operator.openshift.io для управления ingresscontroller.

Взаимодействуйте с входными контроллерами с помощью утилиты oc. Каждый ingresscontroller находится в namespace openshift-ingress-operator.

Масштабируйте ingresscontroller для обеспечения внешнего доступа к службам кластера:

oc scale \
   --namespace=openshift-ingress-operator \
   --replicas=1 \
   ingresscontroller/<name>

oc patch \
   --namespace=openshift-ingress-operator \
   --patch='{"spec": {"replicas": 2}}' \
   --type=merge \
   ingresscontroller/<name>

Используйте команду oc для устранения проблем оператора:

1. Проверьте статус оператора:

   oc describe clusteroperators/ingress
   

2. Просмотрите логи оператора:

   oc logs --namespace=openshift-ingress-operator deployments/ingress-operator
   

3. Проверьте состояние ingresscontroller:

   oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
   

Machine-config-operator#

Machine-config-operator (MCO) воздействует на операционную систему (ОС), управляя обновлениями и изменениями конфигурации systemd, cri-o/kubelet, kernel, NetworkManager и других компонентов, располагающихся между ядром и kubelet.

Он также предлагает новый CRD MachineConfig, который может записывать файлы конфигурации на хост.

Machine-config-operator тесно взаимодействует как с установщиком ОС, так и с самой ОС. Как только machine-api-operator подготовит машину, Machine-config-operator ее настроит.

machine-os-content#

bootimage - это исходный образ Platform V SberLinux OS Core, например: VMWare VMDK, OpenStack QCOW2 и т.д.

bootimage в то же время является частью образа machine-os-content, которым управляет Machine-config-operator.

Machine-config-operator с помощью machine-os-content обновляет слой OSTree поверх прочих операционных систем, каждое обновление – новый слой, с возможностью возвращения к предыдущим версиям.

Cluster Version Operator#

Cluster Version Operator (CVO) - один из операторов кластера, которые выполняются в каждом кластере DropApp Plus. CVO использует артефакт, называемый Выпуск образа полезной нагрузки, который представляет определенную версию DropApp Plus. Образ полезной нагрузки содержит файлы манифестов, необходимые для функционирования кластера.

CVO согласовывает ресурсы внутри кластера, чтобы они соответствовали манифестам в образе полезной нагрузки. В результате CVO реализует обновления кластера. После предоставления образа полезной нагрузки для более новой версии DropApp Plus CVO согласовывает все операторы кластера с их обновленными версиями, и операторы кластера аналогичным образом обновляют свои операнды.

Как и другие операторы кластера, Cluster Version Operators настраивается с помощью ресурса Config API в кластере ClusterVersion:

oc explain clusterversion
  KIND:     ClusterVersion
  VERSION:  config.openshift.io/v1

  DESCRIPTION:
       ClusterVersion is the configuration for the ClusterVersionOperator. This is
       where parameters related to automatic updates can be set. Compatibility
       level 1: Stable within a major release for a minimum of 12 months or 3
       minor releases (whichever is longer).

  FIELDS:
     ...
     spec   <Object> -required-
       spec is the desired state of the cluster version - the operator will work
       to ensure that the desired version is applied to the cluster.

     status   <Object>
       status contains information about the available updates and any in-progress
       updates.

Ресурс ClusterVersion следует установленному шаблону DropApp Plus, где свойство spec описывает желаемое состояние, которого CVO должен достичь и поддерживать, а свойство status заполняется CVO для описания его статуса и наблюдаемого состояния.

В типовом кластере DropApp Plus ресурс ClusterVersion с областью действия кластера, называется версией:

$ oc get clusterversion version
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.11.17   True        False         6d5h    Cluster version is 4.11.17

Bare metal machine controllers#

Bare metal machine controller один из набора инструментов для управления инфраструктурой bare metal с использованием DropApp Plus, реализует исполнительный механизм DropApp Cluster API.

Cluster API предоставляет декларативные API в стиле DropApp Plus для создания, настройки и управления кластерами. API является общим для нескольких облачных поставщиков.

Baremetal machine controller один из поставщиков Cluster API и позволяет пользователям развертывать кластер на основе Cluster API поверх инфраструктуры bare metal.

Cluster API - подпроект DropApp Plus, ориентированный на предоставление декларативных API и инструментов для упрощения подготовки, обновления и эксплуатации нескольких кластеров DropApp Plus.

Определения API и ресурсов#

Машина#

Ресурс машины определяется проектом Machine API Operator. Машина включает поле providerSpec, которое содержит данные, относящиеся к данному поставщику Cluster API.

machine-api-operator управляет жизненным циклом CRD, контроллеров и объектов RBAC специального назначения, которые расширяют Kubernetes API. Это позволяет передавать желаемое состояние машин в кластере декларативным способом.

BareMetalMachineProviderSpec#

image - включает в себя два подполя, url и checksum, состоящие из URL-адреса образа и URL-адреса контрольной суммы для этого образа.

userData - включает в себя два подполя, name и namespace, ссылающиеся на секрет, содержащий пользовательские данные в кодировке base64, которые должны быть записаны на диск конфигурации на подготовленном BareMetalHost.

hostSelector - задает критерии для сопоставления меток на объектах BareMetalHost. Это может быть использовано для ограничения набора доступных объектов BareMetalHost, выбранных для данной машины.

Пример настройки машины:

apiVersion: cluster.k8s.io/v1alpha1
kind: Machine
metadata:
  annotations:
    metal3.io/BareMetalHost: metal3/master-0
  creationTimestamp: "2019-05-13T13:00:51Z"
  finalizers:
  - machine.cluster.k8s.io
  generateName: baremetal-machine-
  generation: 2
  name: centos
  namespace: metal3
  resourceVersion: "1112"
  selfLink: /apis/cluster.k8s.io/v1alpha1/namespaces/metal3/machines/centos
  uid: 22acee54-757f-11e9-8091-280d3563c053
spec:
  metadata:
    creationTimestamp: null
  providerSpec:
    value:
      apiVersion: baremetal.cluster.k8s.io/v1alpha1
      image:
        checksum: http://NNN.NN.N.N/images/CentOS-7-x86_64-GenericCloud-1901.qcow2.md5sum
        url: http://NNN.NN.N.N/images/CentOS-7-x86_64-GenericCloud-1901.qcow2
      kind: BareMetalMachineProviderSpec
      userData:
        name: centos-user-data
        namespace: metal3
      hostSelector:
        matchLabels:
          key1: value1
        matchExpressions:
          key: key2
          operator: in
          values: {'abc', '123', 'value2'}
  versions:
    kubelet: ""

где NNN.NN.N.N – актуальный IP адрес.

Пример секрета userData:

apiVersion: v1
data:
  userData: BASE64_ENCODED_USER_DATA
kind: Secret
metadata:
  annotations:
  creationTimestamp: 2019-05-13T13:00:51Z
  name: centos-user-data
  namespace: metal3
  resourceVersion: "1108"
  selfLink: /api/v1/namespaces/metal3/secrets/centos-user-data
  uid: 22792b3e-757f-11e9-8091-280d3563c053
type: Opaque

Поле hostSelector имеет два возможных необязательных подполя:

• matchLabels - пары меток ключ/значение, которые должны точно совпадать;

• matchExpressions - набор выражений, которые должны принимать значение true для меток на BareMetalHost.

Допустимые операторы включают:

• ! - Ключ не существует. Значения игнорируются;

• = - Ключ равен указанному значению. Должно быть указано только одно значение;

• == - Ключ равен указанному значению. Должно быть указано только одно значение;

• в - Значение является членом набора возможных значений;

• != - Ключ не равен указанному значению. Должно быть указано только одно значение;

• notin - Значение не является членом указанного набора значений;

• exists - Ключ существует. Значения игнорируются;

• gt - Значение больше указанного. Значение должно быть целым числом;

• lt - Значение меньше указанного. Значение должно быть целым числом.

Пример: BareMetalHost только с ключом key1, установленным в value1, и ключом key2, установленным в value2:

spec:
  providerSpec:
    value:
      hostSelector:
        matchLabels:
          key1: value1
          key2: value2

Масштабирование MachineSet#

Для автоматической масштабируемости MachineSet до количества совпадающих BareMetalHosts, пометьте MachineSet ключом metal3.io/autoscale-to-hosts и любым значением.

При согласовании MachineSet контроллер подсчитает все nodes BareMetalHosts, которые:

• либо соответствуют спецификации MachineSet Spec.Template.Spec.ProviderSpec.HostSelector и имеют значение ConsumerRef, равное nil;

• либо имеют значение ConsumerRef, которое ссылается на машину, являющуюся частью MachineSet.

Cluster-baremetal-operator#

Cluster-baremetal-operator (CBO) разработан как оператор DropApp Plus, который отвечает за развертывание всех компонентов, необходимых для обеспечения работы серверов Baremetal, на worker nodes, которые присоединяются к кластеру DropApp Plus.

CBO отвечает за обеспечение того, чтобы развертывание metal3, состоящее из контейнеров Bare Metal Operator (BMO) и Ironic, всегда выполнялось на одном из master node в кластере DropApp Plus.

CBO отвечает за проверку обновлений DropApp Plus для ресурсов, которые он просматривает, и принятие соответствующих мер. CBO сообщает о своем собственном состоянии через ресурс ClusterOperator baremetal, как того требует каждый оператор DropApp Plus. CBO считывает и проверяет, предоставленную в ресурсе Provisioning Config (CR), и передает эту информацию в развертывание metal3. Он также создает секреты, которые используются контейнерами.

Bare Metal Operator#

Bare Metal Operator реализует Kubernetes API для управления хостами baremetal. Он ведет реестр доступных хостов в качестве экземпляров пользовательского определения ресурса BareMetalHost. Bare Metal Operator позволяет:

• проверить сведения об оборудовании хоста и сообщить о них на соответствующем BareMetalHost. Сведения включают информация о процессорах, оперативной памяти, дисках, сетевых адаптерах и многом другом;

• предоставить хостам заданный образ;

• очистить содержимое диска хоста до или после подготовки.

BareMetalHost представляет собой хост сервера и содержит информацию о сервере. Классификация полей по следующим широким категориям:

• известные свойства сервера: такие поля, как свойства bootMACAddress сервера;

• неизвестные свойства сервера: такие поля, как CPU и disk, являются свойствами сервера и обнаруживаются Ironic;

• предоставленное пользователем: такие поля, как image, предоставляются пользователем для определения загрузочного образа для сервера;

• динамические поля: такие поля, как IP, могут динамически назначаться серверу во время выполнения DHCP-сервером.

В течение жизненного цикла Bare Metal хоста некоторые из этих полей изменяются в зависимости от информации, поступающей от Ironic или других контроллеров, в то время такие поля, как MAC-адрес, не меняются.

Bare Metal Operator также может работать с Bare metal machine controller. При участии Bare metal machine controller и Ironic ниже показан упрощенный путь передачи информации и обзор ресурса BareMetalHost:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: node-0
  namespace: metal3
spec:
  bmc:
    address: ipmi://NNN.NNN.NNN.N:6230
    credentialsName: node-0-bmc-secret
  bootMACAddress: 00:5a:91:3f:9a:bd
  image:
    checksum: http://MMM.MM.M.1/images/CENTOS_8_NODE_IMAGE_K8S_v1.22.2-raw.img.md5sum
    url: http://MMM.MM.M.1/images/CENTOS_8_NODE_IMAGE_K8S_v1.22.2-raw.img
  networkData:
    name: test1-workers-tbwnz-networkdata
    namespace: metal3
  online: true
  userData:
    name: test1-workers-vd4gj
    namespace: metal3
status:
  hardware:
    cpu:
      arch: x86_64
      count: 2
    hostname: node-0
    nics:
    - ip: MMM.MM.M.73
      mac: 00:5a:91:3f:9a:bd
      name: enp1s0
    ramMebibytes: 4096
    storage:
    - hctl: "0:0:0:0"
      name: /dev/sda
      serialNumber: drive-scsi0-0-0-0
      sizeBytes: 53687091200
      type: HDD

где NNN.NNN.NNN.N – актуальный IP адрес одной подсети, а MMM.MM.M.1 и MMM.MM.M.73 – актуальные IP адреса другой подсети.

Ресурс BareMetalHost содержит адрес и аутентификационную информацию для сервера.

Bare Metal Operator передает эту информацию Ironic и получает взамен сведения об оборудовании - данные проверки, такие как процессор и диск сервера. Эта информация добавляется к статусу ресурса BareMetalHost. Чтобы получить такую информацию, связанную с сервером, сервер загружается с помощью служебного ramdisk. Если происходят изменения, связанные с оборудованием, BareMetalHost обновляется соответствующим образом.

Масштабирование кластера, подготовленного пользователем, с помощью Bare Metal Operator#

После развертывания кластера инфраструктуры, подготовленного пользователем, можно использовать Bare Metal Operator (BMO) и другие компоненты metal3 для масштабирования baremetal хостов в кластере более автоматизированным способом.

Настройка Provisioning ресурса для масштабирования кластеров, подготовленных пользователем#

Создайте Provisioning пользовательский ресурс (CR), чтобы включить компоненты платформы Metal в кластере инфраструктуры, подготовленном пользователем.

Процедура#

1. Создайте Provisioning CR.

   Сохраните следующий YAML-настройку в файле provisioning.yaml:

   apiVersion: metal3.io/v1alpha1
   kind: Provisioning
   metadata:
     name: provisioning-configuration
   spec:
     provisioningNetwork: "Disabled"
     watchAllNamespaces: false
   

2. Создайте Provisioning CR, выполнив следующую команду:

   oc create -f provisioning.yaml
   

   Пример вывода:

   provisioning.metal3.io/provisioning-configuration created
   

Проверка#

Убедитесь, что служба подготовки запущена, выполнив следующую команду:

oc get pods -n openshift-machine-api

Пример вывода:

NAME                                                  READY   STATUS    RESTARTS        AGE
cluster-autoscaler-operator-678c476f4c-jjdn5          2/2     Running   0               5d21h
cluster-baremetal-operator-6866f7b976-gmvgh           2/2     Running   0               5d21h
control-plane-machine-set-operator-7d8566696c-bh4jz   1/1     Running   0               5d21h
ironic-proxy-64bdw                                    1/1     Running   0               5d21h
ironic-proxy-rbggf                                    1/1     Running   0               5d21h
ironic-proxy-vj54c                                    1/1     Running   0               5d21h
machine-api-controllers-544d6849d5-tgj9l              7/7     Running   1 (5d21h ago)   5d21h
machine-api-operator-5c4ff4b86d-6fjmq                 2/2     Running   0               5d21h
metal3-6d98f84cc8-zn2mx                               5/5     Running   0               5d21h
metal3-image-customization-59d745768d-bhrp7           1/1     Running   0               5d21h

Подготовка новых хостов в кластере, подготовленном пользователем, с помощью BMO#

BMO может быть использован для подготовки baremetal хостов в кластере, подготовленном пользователем, путем создания пользовательского ресурса BareMetalHost.

Чтобы предоставить кластеру baremetal хосты с помощью BMO, установите для спецификации spec.externallyProvisioned в пользовательском ресурсе BareMetalHost значение false.

Предварительные требования#

• создан Provisioning кластер, подготовленный пользователем;

• получен доступ к контроллеру управления базовой платой (BMC) к узлам;

• развернута служба подготовки в кластере, создав сертификат подготовки.

Процедура#

1. Создайте Secret CR и BareMetalHost CR.

   Сохраните следующий YAML в файле bmh.yaml:

   Пример манифеста

   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: worker1-bmc
     namespace: openshift-machine-api
   type: Opaque
   data:
     username: <base64_of_uid>
     password: <base64_of_pwd>
   ---
   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     name: worker1
     namespace: openshift-machine-api
   spec:
     bmc:
       address: <protocol>://<bmc_url>
       credentialsName: "worker1-bmc"
     bootMACAddress: <nic1_mac_address>
     externallyProvisioned: false
     customDeploy:
       method: install_coreos
     online: true
     userData:
       name: worker-user-data-managed
       namespace: openshift-machine-api
   

2. Создайте baremetal хост, выполнив следующую команду:

   oc create -f bmh.yaml
   

   Пример вывода:

   secret/worker1-bmc created
   baremetalhost.metal3.io/worker1 created
   

3. Утвердите все запросы на подписание сертификатов (CSR).

   • Убедитесь, что состояние подготовки хоста подготовлено, выполнив следующую команду:

     oc get bmh -A
     

     Пример вывода:

     NAMESPACE               NAME          STATE                    CONSUMER   ONLINE   ERROR   AGE
     openshift-machine-api   controller1   externally provisioned              true             5m25s
     openshift-machine-api   worker1       provisioned                         true             4m45s
     

   • Получите список ожидающих CSR, выполнив следующую команду:

     oc get csr
     

     Пример вывода:

     certificatesigningrequest.certificates.k8s.io/<csr_name> approved
     

Верификация#

Убедитесь, что узел готов, выполнив следующую команду:

 oc get nodes

Пример вывода:

NAME        STATUS   ROLES           AGE     VERSION
app1        Ready    worker          47s     v1.24.0+dc5a2fd
controller1 Ready    master,worker   2d22h   v1.24.0+dc5a2fd

Marketplace Operator#

Marketplace Operator - оператор, который позволяет управлять и разворачивать приложения и сервисы из Marketplace - рынка приложений, в кластере DropApp Plus.

Marketplace Operator позволяет пользователям просто настраивать и управлять различными приложениями, которые могут быть использованы в их кластере через централизованный механизм управления. Он обеспечивает простоту развертывания различных приложений в кластере DropApp Plus без необходимости знания их внутреннего устройства или конфигурации.

Open Virtual Networking with Kubernetes#

Подключаемый модуль OVN-Kubernetes Container Network Interface (CNI) — это поставщик сети для кластера по умолчанию. OVN-Kubernetes, основанный на открытой виртуальной сети (OVN), предоставляет реализацию сети на основе наложения.

Кластер, использующий сетевой поставщик OVN-Kubernetes, также запускает Open vSwitch (OVS) на каждом node. OVN настраивает OVS для реализации объявленной конфигурации сети.

OVN обеспечивает виртуализацию сети для контейнеров. В режиме наложения OVN может создавать логическую сеть между контейнерами, работающими на нескольких хостах. В этом режиме OVN программирует экземпляры Open vSwitch, работающие внутри хостов. Этими хостами могут быть простые машины или обычные виртуальные машины.

Telemeter#

Telemeter - это набор компонентов, используемых для удаленного мониторинга работоспособности DropApp Plus. Он позволяет кластерам отправлять данные их телеметрии в качестве метрик Prometheus.

Cервер телеметрии должен получать и отправлять метрики через несколько границ безопасности и, следовательно, должен выполнять несколько проверок аутентификации, авторизации и целостности данных. Он получает метрики и пересылает их вышестоящей службе в виде запроса на удаленную запись Prometheus через две конечные точки.

SDN#

SDN оригинальный сетевой плагин для DropApp Plus. Он использует Open vSwitch для локального подключения модулей с туннелями VXLAN для подключения различных nodes.

SDN предназначен для установки оператором Network Operator, и некоторые его компоненты, такие как Deployment и DaemonSet, находятся в образе Network Operator.

Network Operator определяет два образа: образ sdn, включающий SDN-компоненты контроллера и компоненты node, и образ kube-proxy, разворачивающийся сетевым оператором для сторонних сетевых плагинов, которым это необходимо.

SDN устарел и больше не разрабатывается. Рекомендуется использовать OVN Kubernetes.

Network-tools#

network-tools - это набор инструментов для отладки сетевых проблем кластера DropApp Plus. Также содержит инструменты для получения информации из кластера. Предназначен для управления и мониторинга сетевых соединений в кластере, отладки и диагностики проблем.

network-tools содержит:

• сценарии отладки кластерной сети, написанные на bash;

• часто используемые сетевые инструменты CLI, такие как ping, netcat, tcpdump, strace и др.

Чтобы использовать network-tools локально, клонируйте и запустите репозиторий ./debug-scripts/network-tools -h, в котором будут перечислены все доступные команды.

Чтобы использовать network-tools в кластере, используйте команду oc adm must-gather --image-stream openshift/network-tools:latest -- network-tools -h.

Network Metrics Daemon#

Network Metrics Daemon - это компонент, который собирает и публикует метрики, связанные с сетью.

После установки Network Metrics Daemon Kubelet публикует показатели, связанные с сетью:

• container_network_receive_bytes_total;

• container_network_receive_errors_total;

• container_network_receive_packets_total;

• container_network_receive_packets_dropped_total;

• container_network_transmit_bytes_total;

• container_network_transmit_errors_total;

• container_network_transmit_packets_total;

• container_network_transmit_packets_dropped_total.

Метки в этих метриках содержат:

• имя pod (pod name);

• pod namespace;

• название интерфейса (interface name).

Network interface bond CNI#

Плагин Bond-CNI предоставляет метод объединения нескольких сетевых интерфейсов в единый логически связанный интерфейс.

CNI (Container Network Interface) - состоит из спецификации и библиотек для написания плагинов для настройки сетевых интерфейсов в контейнерах операционных систем, а также ряда поддерживаемых плагинов. CNI занимается только подключением контейнеров к сети и удалением выделенных ресурсов при удалении контейнера.

Чтобы добавить связанный интерфейс к контейнеру, необходимо создать определение сетевого подключения типа bond и добавить его в качестве сетевой аннотации в спецификации pod. Связанные интерфейсы могут быть взяты либо из хоста, либо из контейнера на основе значения параметра linksInContainer в определении сетевого подключения.

При настройке Bond CNI в качестве автономного плагина, интерфейсы формируются из namespace хост-сети. С помощью этих физических интерфейсов в namespace контейнерной сети создается связанный интерфейс.

При использовании с Multus появляется возможность связать два интерфейса, которые ранее были переданы в контейнер.

Основным вариантом использования соединения в контейнерах является сетевое резервирование приложения в случае сбоя сетевого устройства или пути и последующей недоступности.

Must-gather#

Must-gather - это инструмент для сбора данных кластера. Он выгружает данные clusteroperator и связанные с ними данные namespace в указанное местоположение --base-dir.

Сбор сценариев#

Сценарии сбора данных хранятся в ./collection-scripts. Содержимое этой папки помещено в /usr/bin в образе. Сценарии сбора данных должны включать логику сбора только для компонентов, которые включены как часть полезной нагрузки DropApp Plus. Сторонним компонентам рекомендуется создавать аналогичный образ Must-gather.

Запуск#

Запустите must-gather в кластере с помощью oc adm must-gather. Используйте флаг -h, чтобы просмотреть доступные параметры.

Cкрытие конфиденциальной информации#

Существует специальный раздел для скрытия и пропуска конфиденциальной информации must-gather-clean.

Machine-os-images#

Machine-os-images содержит компоненты, необходимые для создания node на базе Platform V SberLinux OS Core. Процесс включает в себя создание контейнера, который состоит из последней версии Platform V SberLinux OS Core для разработчиков, артефактов кластера DropApp Plus, демона Machine Controller и других различных контейнерных слоев.

Cloud Credential Operator#

Cloud Credential Operator - это контроллер, синхронизирующий пользовательские ресурсы CredentialsRequest. Запросы credentialsrequest позволяют компонентам DropApp Plus запрашивать подробные учетные данные для конкретного облачного провайдера, в отличие от использования учетных данных администратора или повышенных разрешений, предоставляемых через роли экземпляра.

Cluster-kube-storage-version-migrator-operator#

Cluster-kube-storage-version-migrator-operator (storage-version-migrator) - это управляемый контроллер ресурсов DropApp Plus, который отвечает за управление миграцией данных хранилища. Например, хранилища данных, используемые в приложениях или сервисах, при обновлении версии хранилища или сущности управления данными, такими как базы данных.

Storage-version-migrator помогает автоматизировать процесс миграции данных и обеспечивает их безопасность и целостность во время процесса обновления.

Storage-version-migrator переносит сохраненные в etcd данные в последнюю версию хранилища.

Мигратор состоит из двух контроллеров: триггерного контроллера и фактического контроллера миграции.

• Триггерный контроллер:

  • обнаруживает изменения версии хранилища путем опроса документа обнаружения сервера API каждые 10 минут;

  • создает запросы на миграцию для типов ресурсов, версия хранилища которых изменяется.

• Контроллер миграции обрабатывает запросы на миграцию один за другим. При переносе типа ресурса для всех объектов этого типа ресурсов контроллер миграции получает объект, а затем записывает его обратно на API server без изменений. Цель состоит в том, чтобы запустить API server для кодирования объекта в последней версии хранилища перед его сохранением.

Container Networking Plugins#

Некоторые сетевые плагины CNI поддерживаются Container Networking.

CNI (Container Network Interface) состоит из спецификации и библиотек для написания плагинов для настройки сетевых интерфейсов в контейнерах Linux и Windows, а также ряда поддерживаемых плагинов. CNI занимается только подключением контейнеров к сети и удалением выделенных ресурсов при удалении контейнера.

Поддерживаемые плагины#

Main: interface-creating:

• bridge: Создает bridge, добавляет к нему хост и контейнер;

• ipvlan: Добавляет интерфейс ipvlan в контейнер;

• loopback: Устанавливает состояние интерфейса обратной связи на up;

• macvlan: Создает новый MAC-адрес, перенаправляет весь трафик идущий на него в контейнер;

• ptp: Создает пару veth;

• vlan: Выделяет устройство vlan;

• host-device: Перемещает уже существующее устройство в контейнер;

• dummy: Создает новое фиктивное устройство в контейнере.

Windows: Windows specific:

• win-bridge: Создает bridge, добавляет к нему хост и контейнер;

• win-overlay: Создает интерфейс наложения для контейнера.

IPAM: Распределение IP-адресов:

• dhcp: Запускает демона на хосте для выполнения DHCP-запросов от имени контейнера;

• host-local: Поддерживает локальную базу данных выделенных IP-адресов;

• static: Выделяет контейнеру один статический IPv4/IPv6-адрес.

Meta: другие плагины:

• tuning: Настраивает параметры sysctl существующего интерфейса;

• portmap: Плагин для отображения портов на основе iptables. Отображает порты из адресного пространства хоста в контейнер;

• bandwidth: Позволяет ограничить полосу пропускания за счет использования tbf управления трафиком (вход/выход);

• sbr: Плагин, который настраивает маршрутизацию на основе источника для интерфейса, от которого подключен;

• firewall: Плагин брандмауэра, который использует iptables или firewalld для добавления правил, разрешающих трафик в/из контейнера.

Cluster Update Keys#

Cluster Update Keys добавляет ConfigMap к образу DropApp Plus, который инструктирует оператора версии кластера проверять обновления с использованием предоставленных ключей и хранилищ перед их выполнением.

ConfigMap должен содержать аннотацию release.openshift.io/verification-config-map, которая предписывает оператору версии кластера проверять полезные нагрузки на соответствие сигнатурам OpenPGP в формате подписи атомарного контейнера.

Ключи в ConfigMap определяют, как выполняется проверка:

verifier-public-key-*: One or more GPG public keys in ASCII form that must have signed the
                       release image by digest.

store-*: A URL (scheme file://, http://, or https://) location that contains signatures. These
         signatures are in the atomic container signature format. The URL will have the digest
         of the image appended to it as "<STORE>/<ALGO>=<DIGEST>/signature-<NUMBER>" as described
         in the container image signing format. The docker-image-manifest section of the
         signature must match the release image digest. Signatures are searched starting at
         NUMBER 1 and incrementing if the signature exists but is not valid. The signature is a
         GPG signed and encrypted JSON message. The file store is provided for testing only at
         the current time, although future versions of the CVO might allow host mounting of
         signatures.

Cluster-policy-controller#

Cluster-policy-controller отвечает за поддержание ресурсов политики, необходимых для создания модулей в кластере. Контроллерами, управляемыми Cluster-policy-controller, являются:

• контроллер согласования квот кластера – управляет использованием квот кластера;

• контроллер распределения namespace SCC - выделяет UID и метки SELinux для namespaces.

• контроллер утверждения кластера csr - утверждает csr для мониторинга очистки;

• контроллер синхронизации меток допуска podsecurity - настраивает метки namespace допуска PodSecurity для namespaces с меткой security.openshift.io/scc.podSecurityLabelSync: true.

Cluster-policy-controller запускается как контейнер в openshift-kube-controller-manager namespace, в статическом pod kube-controller-manager. Этот pod определяется и управляется оператором кластера kube-controller-manager, который устанавливает и поддерживает пользовательский ресурс KdubeControllerManager в кластере.

Его можно просмотреть с помощью:

oc get clusteroperator kube-controller-manager -o yaml

Сluster node tuning operator#

Сluster node tuning operator (CNT) - это оператор, который отвечает за оптимизацию и настройку nodes кластера для обеспечения оптимальной производительности и эффективности ресурсов.

Он анализирует производительность nodes и принимает решения о том, какие настройки и изменения должны быть применены для улучшения производительности и оптимизации использования ресурсов.

Сluster node tuning operator управляет настройкой на уровне cluster node.

Большинство высокопроизводительных приложений требуют определенного уровня настройки ядра. Оператор предоставляет пользователям унифицированный интерфейс управления sysctls на уровне node и больше гибкости для добавления пользовательской настройки. Оператор управляет контейнерным настроенным демоном, как набором демонов DropApp Plus. Это гарантирует, что спецификация пользовательской настройки передается всем демонам с контейнерной настройкой, запущенным в кластере, в понятном формате. Демоны запускаются на всех nodes кластера, по одному на каждый node.

При изменении профиля контейнерный настроенный демон отменит любые изменения настроек на уровне node перед применением нового профиля. Контейнерный настроенный демон обрабатывает сигналы завершения, откатывая все настройки на уровне node, которые он применил, перед корректным завершением работы.

Cluster Service CA Operator#

Cluster Service CA Operator - это оператор в DropApp Plus, который управляет сертификатным авторитетом (CA) для кластера. Он обеспечивает генерацию, обновление и управление сертификатами для различных компонентов и nodes в кластере.

Cluster Service CA Operator автоматически управляет выпуском сертификатов на основе запросов от различных компонентов в кластере. Он генерирует сертификаты для nodes кластера, служб, хранилищ данных и других ресурсов. Оператор также автоматически обновляет и перевыпускает сертификаты при истечении их срока действия.

Предоставляет возможность отслеживать и контролировать доступ к различным ресурсам и компонентам в кластере с помощью сертификатов.

Cluster Service CA Operator обычно устанавливается и конфигурируется вместе с кластером DropApp Plus и предлагает средства для управления сертификатами из командной строки или интерфейса пользователя. Интегрируется с другими компонентами и инструментами безопасности в DropApp Plus, такими как RBAC (модель на основе ролей), для обеспечения более надежной аутентификации и авторизации в кластере.

Cluster Service CA Operator запускает следующие контроллеры:

• serving cert signer - выдает подписанную пару, обслуживающий сертификат/ключ, службам, помеченным service.beta.openshift.io/serving-cert-secret-name с помощью секрета.

• configmap cabundle injector - отслеживает конфигурационные карты, помеченные service.beta.openshift.io/inject-cabundle=true, и добавляет или обновляет элемент данных (ключ service-ca.crt), содержащий пакет подписи CA в кодировке PEM. Затем пользователи configmap могут доверять service-ca.crt в своей конфигурации клиента TLS, разрешая подключения к службам, использующим сертификаты обслуживания служб.

Cluster Network Operator#

Cluster Network Operator устанавливает и обновляет сетевые компоненты в кластере DropApp Plus.

Cluster Network Operator предоставляет инструменты для создания и настройки сетевых политик, балансировки нагрузки, маршрутизации и других функций сетевого взаимодействия внутри кластера.

Упрощает настройку и управление сетью в кластере DropApp Plus, предоставляя средства для выполнения сложных задач сетевого взаимодействия и автоматического управления сетевыми службами.

Cluster Network Operator следует шаблону контроллера: согласовывает состояние кластера с желаемой конфигурацией. Конфигурация, указанная с помощью CustomResourceDefinition с именем Network.config.openshift.io/v1, имеет соответствующий тип.

Большинство пользователей смогут использовать Config API верхнего уровня, который имеет сетевой тип. Оператор автоматически преобразует объект Network.config.openshift.io в Network.operator.openshift.io.

Чтобы связаться с оператором сети:

oc get -o yaml network.operator cluster

Когда контроллер согласован и все зависимые от него ресурсы объединены, в кластере должен быть установлен сетевой плагин и рабочая сервисная сеть. В DropApp Plus сетевой оператор кластера запускается на самом раннем этапе процесса установки – пока сервер boostrap API все еще запущен.

Cluster machine approver#

Cluster machine approver - контроллер, предоставляющий следующие функциональные возможности:

• отслеживание конечной точки CSR на предмет запросов CSR;

• решение о разрешении или запрете CSR;

• утверждение или отклонение и обновление статуса CSR.

CSR (Certificate Signing Request - запрос на подписание сертификата) — это зашифрованный запрос на выпуск сертификата, содержащий подробную информацию о домене и организации. Генерация CSR является необходимой процедурой подготовки к получению SSL-сертификата. Сгенерированный CSR включается в анкету на получение сертификата.

DropApp Plus обладает поддержкой TLS bootstrapping для nodes.

В кластере DropApp Plus компоненты на рабочих nodes - kubelet и kube-proxy - должны взаимодействовать с компонентами плоскости управления Kubernetes, в частности с kube-apiserver. Чтобы гарантировать конфиденциальность связи, отсутствие помех и то, что каждый компонент кластера взаимодействует с другим доверенным компонентом, следует использовать клиентские сертификаты TLS на nodes.

Чтобы упростить процесс начальной загрузки этих компонентов, в DropApp Plus включен возможность запрос сертификата и подписи API.

Для нормальной работы Kubelet требуется два сертификата:

• Сертификат клиента – для безопасного взаимодействия с Kubernetes API server;

• Сертификат сервера – для использования в собственной локальной конечной точке HTTPs, используемой API server для обратной связи с kubelet.

При подготовке нового хоста kubelet запустится и свяжется с конечной точкой CSR API для запроса подписанных сертификатов клиента и сервера. Он выдает этот запрос, используя учетные данные bootstrap, которые находит в своей локальной файловой системе.

CSR должны быть утверждены. Они могут быть утверждены вручную через API с использованием oc, или kube-controller-manager может быть настроен для их утверждения.

Cluster machine approver - пользовательский компонент для утверждения CSR через API. Cluster machine approver используется для автоматического утверждения CSR, но с более строгими критериями, чем те, которые поддерживаются в kube-controller-manager.

На этапе начальной загрузки кластера служба approve-csr на node начальной загрузки автоматически утверждает все CSR. Эта служба в конечном итоге одобрит CSR для nodes плоскости управления, в то время как cluster-machine-approver возьмет на себя управление будущими новыми CSR от рабочих nodes.

Cluster DNS Operator#

Cluster DNS Operator развертывает и управляет CoreDNS, чтобы предоставить службу разрешения имен для pods, позволяющую обнаруживать службы DropApp Plus на основе DNS.

CoreDNS - это быстрый и гибкий DNS-сервер/переадресатор, который объединяет плагины, выполняющие определенную DNS-функцию.

Cluster DNS Operator создает рабочее развертывание по умолчанию на основе конфигурации кластера.

По умолчанию домен кластера - cluster.local.

Cluster DNS Operator поддерживается ограниченная конфигурация CoreDNS, Corefile или плагинов kubernetes.

Cluster DNS Operator развертывает CoreDNS с использованием DaemonSet, что означает, что у каждого node есть локальная CoreDNS pod-реплика. Эта топология обеспечивает масштабируемость по мере роста или сокращения кластера и устойчивость в случае, если node становится временно изолированным от других nodes.

Cluster Monitoring Operator#

Cluster Monitoring Operator управляет и обновляет стек мониторинга кластеров на основе Prometheus, развернутый поверх DropApp Plus.

Он содержит следующие компоненты:

• Prometheus Operator;

• Prometheus;

• Alertmanager - для оповещения на уровне кластера и приложения;

• kube-state-metrics;

• node_exporter;

• prometheus-adapter;

• kubernetes-metrics-server только на кластере TechPreviewNoUpgrade.

Prometheus Operator обеспечивает встроенное развертывание и управление Prometheus и связанными с ним компонентами мониторинга.

Prometheus отвечает за мониторинг и предупреждения в кластере и компонентах DropApp Plus.

Alertmanager - компонент кластера для обработки предупреждений, генерируемых всеми экземплярами Prometheus, развернутыми в кластере.

Kube-state-metrics - компонент мониторинга DropApp Plus, который предоставляет метрики состояния кластера, такие как, количество pods, replicaSet, deployment и других ресурсов DropApp Plus.

Node_exporter позволяет отслеживать ресурсы node: CPU, использование памяти и диска и многое другое.

prometheus-adapter может заменить сервер метрик в кластерах, на которых уже запущен Prometheus, и собирать соответствующие метрики.

Metrics-server - API-сервер, который сохраняет и предоставляет данные метрик DropApp Plus. Он используется для мониторинга ресурсов кластера, таких как CPU, память и ресурсы сети в режиме реального времени.

Добавление новых метрик для отправки с помощью телеметрии#

Чтобы добавить новые показатели для отправки с помощью телеметрии, добавьте селектор, соответствующий временному ряду в cluster-monitoring-operator.yaml.

Пример настроек cluster-monitoring-operator.yaml для Cluster Monitoring Operator:

# Этот configmap используется оператором мониторинга кластера для настройки
# клиента telemeter (телеметрии), который отвечает за считывание метрик из
# экземпляров Prometheus в кластере и пересылку их в службу телеметрии.
#
# Единственный поддерживаемый ключ в metrics.yaml - это "matches", представляющие список меток
# селекторов, которые определяют, какие метрики будут пересылаться. Метки
# селекторов могут выбрать одну метрику (например, '{__name__="foo"}') или все
# имена метрик, соответствующие регулярному выражению (например, '{__name__=~"foo:.+"}').

apiVersion: v1
data:
  metrics.yaml: |-
    matches:
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:usage recording rules summarize important usage information
    # about the cluster that points to specific features or component usage
    # that may help identify problems or specific workloads. For example,
    # cluster:usage:openshift:build:rate24h would show the number of builds
    # executed within a 24h period so as to determine whether the current
    # cluster is using builds and may be susceptible to eviction due to high
    # disk usage from build temporary directories.
    # All metrics under this prefix must have low (1-5) cardinality and must
    # be well-scoped and follow proper naming and scoping conventions.
    - '{__name__=~"cluster:usage:.*"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # count:up0 contains the count of cluster monitoring sources being marked as down.
    # This information is relevant to the health of the registered
    # cluster monitoring sources on a cluster. This metric allows telemetry
    # to identify when an update causes a service to begin to crash-loop or
    # flake.
    - '{__name__="count:up0"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # count:up1 contains the count of cluster monitoring sources being marked as up.
    # This information is relevant to the health of the registered
    # cluster monitoring sources on a cluster. This metric allows telemetry
    # to identify when an update causes a service to begin to crash-loop or
    # flake.
    - '{__name__="count:up1"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_version reports what payload and version the cluster is being
    # configured to and is used to identify what versions are on a cluster that
    # is experiencing problems.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_version"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_version_available_updates reports the channel and version server
    # the cluster is configured to use and how many updates are available. This
    # is used to ensure that updates are being properly served to clusters.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_version_available_updates"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_version_capability reports the names of enabled and available
    # cluster capabilities.  This is used to gauge the popularity of optional
    # components and exposure to any component-specific issues.
    - '{__name__="cluster_version_capability"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_operator_up reports the health status of the core cluster
    # operators - like up, an upgrade that fails due to a configuration value
    # on the cluster will help narrow down which component is affected.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_operator_up"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_operator_conditions exposes the status conditions cluster
    # operators report for debugging. The condition and status are reported.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_operator_conditions"}'
    #
    # owners: (@openshift/openshift-team-cincinnati)
    #
    # cluster_version_payload captures how far through a payload the cluster
    # version operator has progressed and can be used to identify whether
    # a particular payload entry is causing failures during upgrade.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_version_payload"}'
    #
    # owners: (@openshift/openshift-team-installer, @openshift/openshift-team-cincinnati)
    #
    # cluster_installer reports what installed the cluster, along with its
    # version number and invoker.
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="cluster_installer"}'
    #
    # owners: (@openshift/openshift-team-master, @smarterclayton)
    #
    # cluster_infrastructure_provider reports the configured cloud provider if
    # any, along with the infrastructure region when running in the public
    # cloud.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster_infrastructure_provider"}'
    #
    # owners: (@openshift/openshift-team-master, @smarterclayton)
    #
    # cluster_feature_set reports the configured cluster feature set and
    # whether the feature set is considered supported or unsupported.
    - '{__name__="cluster_feature_set"}'
    #
    # owners: (@openshift/openshift-team-etcd, @smarterclayton)
    #
    # instance:etcd_object_counts:sum identifies two key metrics:
    # - the rough size of the data stored in etcd and
    # - the consistency between the etcd instances.
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="instance:etcd_object_counts:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # alerts are the key summarization of the system state. They are reported
    # via telemetry to assess their value in detecting upgrade failure causes
    # and also to prevent the need to gather large sets of metrics that are
    # already summarized on the cluster.  Reporting alerts also creates an
    # incentive to improve per cluster alerting for the purposes of preventing
    # upgrades from failing for end users.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="ALERTS",alertstate="firing"}'
    #
    # owners: (@openshift/ops)
    #
    # code:apiserver_request_total:rate:sum identifies average of occurences
    # of each http status code over 10 minutes
    # The metric will be used for SLA analysis reports.
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="code:apiserver_request_total:rate:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:capacity_cpu_cores:sum is the total number of CPU cores in the
    # cluster labeled by node role and type.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:capacity_cpu_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:capacity_memory_bytes:sum is the total bytes of memory in the
    # cluster labeled by node role and type.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:capacity_memory_bytes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:cpu_usage_cores:sum is the current amount of CPU used by
    # the whole cluster.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:cpu_usage_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:memory_usage_bytes:sum is the current amount of memory in use
    # across the whole cluster.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:memory_usage_bytes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # openshift:cpu_usage_cores:sum is the current amount of CPU used by
    # OpenShift components, including the control plane and host services
    # (including the kernel).
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="openshift:cpu_usage_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # openshift:memory_usage_bytes:sum is the current amount of memory used by
    # OpenShift components, including the control plane and host services
    # (including the kernel).
    - '{__name__="openshift:memory_usage_bytes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # workload:cpu_usage_cores:sum is the current amount of CPU used by cluster
    # workloads, excluding infrastructure.
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="workload:cpu_usage_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # workload:memory_usage_bytes:sum is the current amount of memory used by
    # cluster workloads, excluding infrastructure.
    #
    # consumers: (@openshift/openshift-team-olm)
    - '{__name__="workload:memory_usage_bytes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:virt_platform_nodes:sum is the number of nodes reporting
    # a particular virt_platform type (nodes may report multiple types).
    # This metric helps identify issues specific to a virtualization
    # type or bare metal.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:virt_platform_nodes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # cluster:node_instance_type_count:sum is the number of nodes of each
    # instance type and role.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="cluster:node_instance_type_count:sum"}'
    #
    # owners: (https://github.com/kubevirt)
    #
    # cnv:vmi_status_running:count is the total number of VM instances running in the cluster.
    - '{__name__="cnv:vmi_status_running:count"}'
    #
    # owners: (https://github.com/kubevirt)
    #
    # cluster:vmi_request_cpu_cores:sum is the total number of CPU cores requested by pods of VMIs.
    - '{__name__="cluster:vmi_request_cpu_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # node_role_os_version_machine:cpu_capacity_cores:sum is the total number
    # of CPU cores in the cluster labeled by master and/or infra node role, os,
    # architecture, and hyperthreading state.
    #
    # consumers: (@openshift/openshift-team-olm, @openshift/openshift-team-cluster-manager)
    - '{__name__="node_role_os_version_machine:cpu_capacity_cores:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring, @smarterclayton)
    #
    # node_role_os_version_machine:cpu_capacity_sockets:sum is the total number
    # of CPU sockets in the cluster labeled by master and/or infra node role,
    # os, architecture, and hyperthreading state.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="node_role_os_version_machine:cpu_capacity_sockets:sum"}'
    #
    # owners: (@openshift/openshift-team-olm)
    #
    # subscription_sync_total is the number of times an OLM operator
    # Subscription has been synced, labelled by name and installed csv
    - '{__name__="subscription_sync_total"}'
    #
    # owners: (@openshift/openshift-team-olm)
    #
    # olm_resolution_duration_seconds is the duration of a dependency resolution attempt.
    - '{__name__="olm_resolution_duration_seconds"}'
    #
    # owners: (@openshift/openshift-team-olm)
    #
    # csv_succeeded is unique to the namespace, name, version, and phase
    # labels.  The metrics is always present and can be equal to 0 or 1, where
    # 0 represents that the csv is not in the succeeded state while 1
    # represents that the csv is in the succeeded state.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="csv_succeeded"}'
    #
    # owners: (@openshift/openshift-team-olm)
    #
    # csv_abnormal represents the reason why a csv is not in the succeeded
    # state and includes the namespace, name, version, phase, reason labels.
    # When a csv is updated, the previous time series associated with the csv
    # will be deleted.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="csv_abnormal"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # cluster:kube_persistentvolumeclaim_resource_requests_storage_bytes:provisioner:sum
    # gives the total amount of storage requested by PVCs from a particular
    # storage provisioner in bytes. This is a generic storage metric.
    - '{__name__="cluster:kube_persistentvolumeclaim_resource_requests_storage_bytes:provisioner:sum"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # cluster:kubelet_volume_stats_used_bytes:provisioner:sum will gives
    # the total amount of storage used by PVCs from a particular storage provisioner in bytes.
    - '{__name__="cluster:kubelet_volume_stats_used_bytes:provisioner:sum"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # ceph_cluster_total_bytes gives the size of ceph cluster in bytes. This is a specific OCS metric.
    - '{__name__="ceph_cluster_total_bytes"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # ceph_cluster_total_used_raw_bytes is the amount of ceph cluster storage used in bytes.
    - '{__name__="ceph_cluster_total_used_raw_bytes"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # ceph_health_status gives the ceph cluster health status
    - '{__name__="ceph_health_status"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # odf_system_raw_capacity_total_bytes gives the size of storage cluster in bytes. This is a specific OCS metric.
    - '{__name__="odf_system_raw_capacity_total_bytes"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # odf_system_raw_capacity_used_bytes is the amount of storage cluster storage used in bytes.
    - '{__name__="odf_system_raw_capacity_used_bytes"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # odf_system_health_status gives the storage cluster health status
    - '{__name__="odf_system_health_status"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:ceph_osd_metadata:count is the total count of osds.
    - '{__name__="job:ceph_osd_metadata:count"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:kube_pv:count is the total number of Persistent Volumes created by ODF present in OCP cluster.
    # This metric is deprecated in ODF 4.12, refer to job:odf_system_pvs:count instead.
    - '{__name__="job:kube_pv:count"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:odf_system_pvs:count is the total number of Persistent Volumes created by ODF present in OCP cluster.
    - '{__name__="job:odf_system_pvs:count"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:ceph_pools_iops:total is the total iops (reads+writes) value for all the pools in ceph cluster
    - '{__name__="job:ceph_pools_iops:total"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:ceph_pools_iops:total is the total iops (reads+writes) value in bytes for all the pools in ceph cluster
    - '{__name__="job:ceph_pools_iops_bytes:total"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:ceph_versions_running:count is the total count of ceph cluster versions running.
    - '{__name__="job:ceph_versions_running:count"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:noobaa_total_unhealthy_buckets:sum is the total number of unhealthy noobaa buckets
    - '{__name__="job:noobaa_total_unhealthy_buckets:sum"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:noobaa_bucket_count:sum is the total number of noobaa buckets.
    # This metric is deprecated in ODF 4.12, refer to odf_system_bucket_count instead.
    - '{__name__="job:noobaa_bucket_count:sum"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # job:noobaa_total_object_count:sum is the total number of noobaa objects.
    # This metric is deprecated in ODF 4.12, refer to odf_system_objects_total instead.
    - '{__name__="job:noobaa_total_object_count:sum"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # odf_system_bucket_count is the total number of buckets in ODF system
    - '{__name__="odf_system_bucket_count", system_type="OCS", system_vendor="Red Hat"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # odf_system_objects_total is the total number of objects in ODF system
    - '{__name__="odf_system_objects_total", system_type="OCS", system_vendor="Red Hat"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # noobaa_accounts_num gives the count of noobaa's accounts.
    - '{__name__="noobaa_accounts_num"}'
    #
    # owners: (@openshift/team-ocs-committers)
    #
    # noobaa_total_usage gives the total usage of noobaa's storage in bytes.
    - '{__name__="noobaa_total_usage"}'
    #
    # owners: (@openshift/origin-web-console-committers)
    # console_url is the url of the console running on the cluster.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="console_url"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_auth_login_requests_total:sum gives the total number of login requests initiated from the web console.
    #
    - '{__name__="cluster:console_auth_login_requests_total:sum"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_auth_login_successes_total:sum gives the total number of successful logins initiated from the web console.
    # Labels:
    # * `role`, one of `kubeadmin`, `cluster-admin` or `developer`. The value is based on whether or not the logged-in user can list all namespaces.
    #
    - '{__name__="cluster:console_auth_login_successes_total:sum"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_auth_login_failures_total:sum gives the total number of login failures initiated from the web console.
    # This might include canceled OAuth logins depending on the user OAuth provider/configuration.
    # Labels:
    # * `reason`, currently always `unknown`
    #
    - '{__name__="cluster:console_auth_login_failures_total:sum"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_auth_logout_requests_total:sum gives the total number of logout requests sent from the web console.
    # Labels:
    # * `reason`, currently always `unknown`
    #
    - '{__name__="cluster:console_auth_logout_requests_total:sum"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_usage_users:max contains the number of web console users splitten into the roles.
    # Labels:
    # * `role`: `kubeadmin`, `cluster-admin` or `developer`. The value is based on whether or not the user can list all namespaces.
    #
    - '{__name__="cluster:console_usage_users:max"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_plugins_info:max reports information about the web console plugins and their state.
    # Labels:
    # * `name`: `redhat`, `demo` or `other`.
    # * `state`: `enabled`, `disabled` or `notfound`
    #
    - '{__name__="cluster:console_plugins_info:max"}'
    #
    # owners: (@openshift/hybrid-application-console-maintainers)
    # cluster:console_customization_perspectives_info:max reports information about customized web console perspectives.
    # Labels:
    # * `name`, one of `admin`, `dev`, `acm` or `other`
    # * `state`, one of `enabled`, `disabled`, `only-for-cluster-admins`, `only-for-developers` or `custom-permissions`
    #
    - '{__name__="cluster:console_customization_perspectives_info:max"}'
    #
    # owners: (@openshift/networking)
    #
    # ovnkube_master_egress_routing_via_host" informs if the OVN-K cluster's gateway mode is
    # `routingViaOVN` (0), `routingViaHost` (1) or invalid (2).
    - '{__name__="cluster:ovnkube_master_egress_routing_via_host:max"}'
    #
    # owners: (@openshift/networking)
    #
    # cluster:network_attachment_definition_instances:max" gives max no of instance
    # in the cluster that are annotated with k8s.v1.cni.cncf.io/networks, labelled by networks.
    - '{__name__="cluster:network_attachment_definition_instances:max"}'
    #
    # owners: (@openshift/networking)
    #
    # cluster:network_attachment_definition_enabled_instance_up  informs (1 or 0) if the cluster has
    # at least max of one instance with  k8s.v1.cni.cncf.io/networks annotation, labelled by networks (any or sriov).
    - '{__name__="cluster:network_attachment_definition_enabled_instance_up:max"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:ingress_controller_aws_nlb_active:sum informs how many NLBs are active in AWS.
    # Zero would indicate ELB (legacy). This metric is only emitted on AWS.
    - '{__name__="cluster:ingress_controller_aws_nlb_active:sum"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:route_metrics_controller_routes_per_shard:min tracks the minimum number of routes
    # admitted by any of the shards.
    - '{__name__="cluster:route_metrics_controller_routes_per_shard:min"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:route_metrics_controller_routes_per_shard:max tracks the maximum number of routes
    # admitted by any of the shards.
    - '{__name__="cluster:route_metrics_controller_routes_per_shard:max"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:route_metrics_controller_routes_per_shard:avg tracks the average value for the
    # route_metrics_controller_routes_per_shard metric.
    - '{__name__="cluster:route_metrics_controller_routes_per_shard:avg"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:route_metrics_controller_routes_per_shard:median tracks the median value for the
    # route_metrics_controller_routes_per_shard metric.
    - '{__name__="cluster:route_metrics_controller_routes_per_shard:median"}'
    #
    # owners: (@openshift/network-edge)
    #
    # cluster:openshift_route_info:tls_termination:sum tracks the number of routes for each tls_termination
    # value. The possible values for tls_termination are edge, passthrough and reencrypt.
    - '{__name__="cluster:openshift_route_info:tls_termination:sum"}'
    #
    # owners: (https://github.com/openshift/insights-operator/blob/master/OWNERS)
    #
    # insightsclient_request_send tracks the number of metrics sends.
    - '{__name__="insightsclient_request_send_total"}'
    #
    # owners: (@openshift/openshift-team-app-migration)
    #
    # cam_app_workload_migrations tracks number of app workload migrations
    # by current state. Tracked migration states are idle, running, completed, and failed.
    - '{__name__="cam_app_workload_migrations"}'
    #
    # owners: (@openshift/openshift-team-master)
    #
    # cluster:apiserver_current_inflight_requests:sum:max_over_time:2m gives maximum number of requests in flight
    # over a 2-minute window. This metric is a constant 4 time series that monitors concurrency of kube-apiserver and
    # openshift-apiserver with request type which can be either 'mutating' or 'readonly'.
    # We want to have an idea of how loaded our api server(s) are globally.
    - '{__name__="cluster:apiserver_current_inflight_requests:sum:max_over_time:2m"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # cluster:alertmanager_integrations:max tracks the total number of active alertmanager integrations sent via telemetry from each cluster.
    - '{__name__="cluster:alertmanager_integrations:max"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # cluster:telemetry_selected_series:count tracks the total number of series
    # sent via telemetry from each cluster.
    - '{__name__="cluster:telemetry_selected_series:count"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # openshift:prometheus_tsdb_head_series:sum tracks the total number of active series
    - '{__name__="openshift:prometheus_tsdb_head_series:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # openshift:prometheus_tsdb_head_samples_appended_total:sum tracks the rate of samples ingested
    # by prometheusi.
    - '{__name__="openshift:prometheus_tsdb_head_samples_appended_total:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # monitoring:container_memory_working_set_bytes:sum tracks the memory usage of the monitoring
    # stack.
    - '{__name__="monitoring:container_memory_working_set_bytes:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # namespace_job:scrape_series_added:topk3_sum1h tracks the top 3 namespace/job groups which created series churns in the last hour.
    - '{__name__="namespace_job:scrape_series_added:topk3_sum1h"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # namespace_job:scrape_samples_post_metric_relabeling:topk3 tracks the top 3 prometheus targets which produced more samples.
    - '{__name__="namespace_job:scrape_samples_post_metric_relabeling:topk3"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # monitoring:haproxy_server_http_responses_total:sum tracks the number of times users access
    # monitoring routes.
    - '{__name__="monitoring:haproxy_server_http_responses_total:sum"}'
    #
    # owners: (@openshift/openshift-team-monitoring)
    #
    # profile:cluster_monitoring_operator_collection_profile:max contains information about the configured
    # collection profile.
    # Possible label values are:
    #   profile: full|minimal (refer: cluster-monitoring-operator/pkg/manifests#SupportedCollectionProfiles)
    - '{__name__="profile:cluster_monitoring_operator_collection_profile:max"}'
    #
    # owners: (https://github.com/integr8ly, @david-martin)
    #
    # rhmi_status reports the status of an RHMI installation.
    # Possible values are bootstrap|cloud-resources|monitoring|authentication|products|solution-explorer|deletion|complete.
    # This metric is used by OCM to detect when an RHMI installation is complete & ready to use i.e. rhmi_status{stage='complete'}
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="rhmi_status"}'
    #
    # owners: (https://github.com/integr8ly, @boomatang)
    #
    # rhoam_state captures the currently installed/upgrading RHOAM versions.
    # Possible label values are:
    #   status= in progress|complete
    #   upgrading= true|false
    #   version= x.y.z
    # This metric is used by cs-SRE to gain insights into RHOAM version.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="status:upgrading:version:rhoam_state:max"}'
    #
    # owners: (https://github.com/integr8ly, @boomatang)
    #
    # rhoam_critical_alerts count of RHOAM specific critical alerts on a cluster
    # Possible label values are:
    #   state= pending|firing
    # This metric is used by CS-SRE to gain insights into critical alerts on RHOAM cluster.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="state:rhoam_critical_alerts:max"}'
    #
    # owners: (https://github.com/integr8ly, @boomatang)
    #
    # rhoam_warning_alerts count of RHOAM specific warning alerts on a cluster
    # Possible label values are:
    #   state= pending|firing
    # This metric is used by CS-SRE to gain insights into warning alerts on RHOAM cluster.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="state:rhoam_warning_alerts:max"}'
    #
    # rhoam_7d_slo_percentile:max Current cluster 7 day percentile
    # Possible labels: None
    # This metric is used by CS-SRE to monitor the SLO budget across the fleet.
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="rhoam_7d_slo_percentile:max"}'
    #
    # rhoam_7d_slo_remaining_error_budget:max Time in milliseconds of remaining error budget
    # Possible labels: None
    # This metric is used byt CS-SRE to monitor remaining error budget across the fleet
    #
    # consumers: (@openshift/openshift-team-cluster-manager)
    - '{__name__="rhoam_7d_slo_remaining_error_budget:max"}'
    #
    #
    # owners: (openshift/openshift-team-master, @openshift/openshift-group-b)
    #
    # cluster_legacy_scheduler_policy reports whether the scheduler operator is
    # configured with a custom Policy file. This value is a boolean 0|1
    - '{__name__="cluster_legacy_scheduler_policy"}'
    #
    # owners: (openshift/openshift-team-master, @openshift/openshift-group-b)
    #
    # cluster_master_schedulable reports whether mastersSchedulable=true in
    # the scheduler operator. This value is a boolean 0|1
    - '{__name__="cluster_master_schedulable"}'
    #
    # owners: (https://github.com/redhat-developer/codeready-workspaces, @ibuziuk)
    #
    # The number of workspaces with a given status STARTING|STOPPED|RUNNING|STOPPING. Type 'gauge'.
    - '{__name__="che_workspace_status"}'
    #
    # owners: (https://github.com/redhat-developer/codeready-workspaces, @ibuziuk)
    #
    # The number of started workspaces. Type 'counter'.
    - '{__name__="che_workspace_started_total"}'
    #
    # owners: (https://github.com/redhat-developer/codeready-workspaces, @ibuziuk)
    #
    # The number of failed workspaces.
    # Can be used with the 'while' label e.g. {while="STARTING"}, {while="RUNNING"}, {while="STOPPING"}.Type 'counter'.
    - '{__name__="che_workspace_failure_total"}'
    #
    # owners: (https://github.com/redhat-developer/codeready-workspaces, @ibuziuk)
    #
    # The time in seconds required for the startup of all the workspaces.
    - '{__name__="che_workspace_start_time_seconds_sum"}'
    #
    # owners: (https://github.com/redhat-developer/codeready-workspaces, @ibuziuk)
    #
    # The overall number of attempts for starting all the workspaces.
    - '{__name__="che_workspace_start_time_seconds_count"}'
    #
    # owners: (@openshift/openshift-team-hive)
    #
    # Track current mode the cloud-credentials-operator is functioning under.
    - '{__name__="cco_credentials_mode"}'
    #
    # owners: (@openshift/storage)
    #
    # Persistent Volume usage metrics: this is the number of volumes per plugin
    # and per volume type (filesystem/block)
    - '{__name__="cluster:kube_persistentvolume_plugin_type_counts:sum"}'
    #
    # owners: (https://github.com/open-cluster-management, @open-cluster-management/cluster-lifecycle-admin)
    #
    # acm_managed_cluster_info provides Subscription watch and other information for the managed clusters for an ACM Hub cluster.
    - '{__name__="acm_managed_cluster_info"}'
    #
    # owners: (https://github.com/orgs/stolostron/teams/search-admin, @acm-observability-search)
    #
    # acm_console_page_count:sum counts the total number of visits for each page in ACM console.
    - '{__name__="acm_console_page_count:sum", page=~"overview-classic|overview-fleet|search|search-details|clusters|application|governance"}'
    #
    # owners: (@openshift/storage)
    #
    # VMWare vCenter info: version of the vCenter where cluster runs
    - '{__name__="cluster:vsphere_vcenter_info:sum"}'
    #
    # owners: (@openshift/storage)
    #
    # The list of ESXi host versions used as host for OCP nodes.
    - '{__name__="cluster:vsphere_esxi_version_total:sum"}'
    #
    # owners: (@openshift/storage)
    #
    # The list of virtual machine HW versions used for OCP nodes.
    - '{__name__="cluster:vsphere_node_hw_version_total:sum"}'
    #
    # owners: (@openshift/team-build-api)
    #
    # openshift:build_by_strategy:sum measures total number of builds on a cluster, aggregated by build strategy.
    - '{__name__="openshift:build_by_strategy:sum"}'
    #
    # owners: (https://github.com/red-hat-data-services/odh-deployer, Open Data Hub team)
    #
    # This is (at a basic level) the availability of the RHODS system.
    - '{__name__="rhods_aggregate_availability"}'
    #
    # owners: (https://github.com/red-hat-data-services/odh-deployer, Open Data Hub team)
    #
    # The total number of users of RHODS using each component.
    - '{__name__="rhods_total_users"}'
    #
    # owners: (@openshift/team-etcd)
    #
    # 99th percentile of etcd WAL fsync duration.
    - '{__name__="instance:etcd_disk_wal_fsync_duration_seconds:histogram_quantile",quantile="0.99"}'
    #
    # owners: (@openshift/team-etcd)
    #
    # Sum by instance of total db size. Used for understanding and improving defrag controller.
    - '{__name__="instance:etcd_mvcc_db_total_size_in_bytes:sum"}'
    #
    # owners: (@openshift/team-etcd)
    #
    # 99th percentile of peer to peer latency.
    - '{__name__="instance:etcd_network_peer_round_trip_time_seconds:histogram_quantile",quantile="0.99"}'
    #
    # owners: (@openshift/team-etcd)
    #
    # Sum by instance of total db size in use.
    - '{__name__="instance:etcd_mvcc_db_total_size_in_use_in_bytes:sum"}'
    #
    # owners: (@openshift/team-etcd)
    #
    # 99th percentile of the backend commit duration.
    - '{__name__="instance:etcd_disk_backend_commit_duration_seconds:histogram_quantile",quantile="0.99"}'
    #
    # owners: (@tracing-team)
    #
    # Number of jaeger instances using certain storage type.
    - '{__name__="jaeger_operator_instances_storage_types"}'
    #
    # owners: (@tracing-team)
    #
    # Number of jaeger instances with certain strategy .
    - '{__name__="jaeger_operator_instances_strategies"}'
    #
    # owners: (@tracing-team)
    #
    # Number of jaeger instances used certain agent strategy
    - '{__name__="jaeger_operator_instances_agent_strategies"}'
    #
    # owners: (https://github.com/redhat-developer/application-services-metering-operator)
    #
    # The current amount of CPU used by Application Services products, aggregated by product name.
    - '{__name__="appsvcs:cores_by_product:sum"}'
    #
    # owners: (https://github.com/openshift/cluster-node-tuning-operator)
    #
    # Number of nodes using a custom TuneD profile not shipped by the Node Tuning Operator.
    - '{__name__="nto_custom_profiles:count"}'
    # owners: (@openshift/team-build-api)
    #
    # openshift_csi_share_configmap measures amount of config maps shared by csi shared resource driver.
    - '{__name__="openshift_csi_share_configmap"}'
    #
    # owners: (@openshift/team-build-api)
    #
    # openshift_csi_share_secret measures amount of secrets shared by csi shared resource driver.
    - '{__name__="openshift_csi_share_secret"}'
    #
    # owners: (@openshift/team-build-api)
    #
    # openshift_csi_share_mount_failures_total measures amount of failed attempts to mount csi shared resources into the pods.
    - '{__name__="openshift_csi_share_mount_failures_total"}'
    #
    # owners: (@openshift/team-build-api)
    #
    # openshift_csi_share_mount_requests_total measures total amount of attempts to mount csi shared resources into the pods.
    - '{__name__="openshift_csi_share_mount_requests_total"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of storages types used across the fleet.
    - '{__name__="eo_es_storage_info"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of redundancy policies used across the fleet.
    - '{__name__="eo_es_redundancy_policy_info"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of namespaces deleted per policy across the fleet.
    - '{__name__="eo_es_defined_delete_namespaces_total"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of clusters with misconfigured memory resources across the fleet.
    - '{__name__="eo_es_misconfigured_memory_resources_info"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of data nodes per cluster.
    - '{__name__="cluster:eo_es_data_nodes_total:max"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of documents created per cluster.
    - '{__name__="cluster:eo_es_documents_created_total:sum"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of documents deleted per cluster.
    - '{__name__="cluster:eo_es_documents_deleted_total:sum"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # Number of shards per cluster.
    - '{__name__="pod:eo_es_shards_total:max"}'
    #
    # elasticsearch operator metrics for Telemetry
    # owners: (@openshift/team-logging)
    #
    # es Management state used by the cluster.
    - '{__name__="eo_es_cluster_management_state_info"}'
    #
    # owners: (@openshift/openshift-team-image-registry)
    #
    # imageregistry:imagestreamtags_count:sum is the total number of existent image stream tags.
    - '{__name__="imageregistry:imagestreamtags_count:sum"}'
    #
    # owners: (@openshift/openshift-team-image-registry)
    #
    # imageregistry:operations_count:sum is the total number of image pushes and pulls executed in the internal registry.
    - '{__name__="imageregistry:operations_count:sum"}'
    #
    # owners: (@openshift/team-logging)
    #
    # log_logging_info gives cluster-logging-operator version, managedStatus, healthStatus specific info.
    - '{__name__="log_logging_info"}'
    #
    # owners: (@openshift/team-logging)
    #
    # log_collector_error_count_total gives cluster-logging-operator deployed collector's (e.g. default collector fluentd) total number of failures in standing it up part of logging pipeline.
    - '{__name__="log_collector_error_count_total"}'
    #
    # owners: (@openshift/team-logging)
    #
    # log_forwarder_pipeline_info gives cluster-logging-operator deployed logging pipelines info - healthStatus and pipelineInfo as no of total logging pipelines deployed.
    - '{__name__="log_forwarder_pipeline_info"}'
    #
    # owners: (@openshift/team-logging)
    #
    # log_forwarder_input_info gives cluster-logging-operator logging pipelines input types info - namely application, infra, audit type of log sources input.
    - '{__name__="log_forwarder_input_info"}'
    #
    # owners: (@openshift/team-logging)
    #
    # log_forwarder_output_info gives cluster-logging-operator logging pipelines output types info - namely to which output end point logs are being directed for further pushing them to a persistent storage.
    - '{__name__="log_forwarder_output_info"}'
    #
    # owners: (@openshift/team-logging)
    #
    # cluster:log_collected_bytes_total:sum gives total bytes collected by the collector and aggregated at each cluster level
    - '{__name__="cluster:log_collected_bytes_total:sum"}'
    #
    # owners: (@openshift/team-logging)
    #
    # cluster:log_logged_bytes_total:sum gives total bytes logged by the containers and aggregated at each cluster level
    - '{__name__="cluster:log_logged_bytes_total:sum"}'
    #
    # owners: (@openshift/sandboxed-containers-operator)
    #
    # cluster:kata_monitor_running_shim_count:sum provides the number of VM
    # running with kata containers on the cluster
    - '{__name__="cluster:kata_monitor_running_shim_count:sum"}'
    #
    # owners: (@openshift/team-hypershift-maintainers)
    #
    # platform:hypershift_hostedclusters:max is the total number of clusters managed by the hypershift operator by cluster platform
    - '{__name__="platform:hypershift_hostedclusters:max"}'
    #
    # owners: (@openshift/team-hypershift-maintainers)
    #
    # platform:hypershift_nodepools:max is the total number of nodepools managed by the hypershift operator by cluster platform
    - '{__name__="platform:hypershift_nodepools:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of unhealthy Object Bucket Claims in addon's namespace.
    - '{__name__="namespace:noobaa_unhealthy_bucket_claims:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of Object Bucket Claims in addon's namespace.
    - '{__name__="namespace:noobaa_buckets_claims:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of unhealthy namespace resources in addon's namespace.
    - '{__name__="namespace:noobaa_unhealthy_namespace_resources:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of namespace resources in addon's namespace.
    - '{__name__="namespace:noobaa_namespace_resources:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of unhealthy namespace buckets in addon's namespace.
    - '{__name__="namespace:noobaa_unhealthy_namespace_buckets:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of namespace buckets in addon's namespace.
    - '{__name__="namespace:noobaa_namespace_buckets:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Number of corresponding noobaa accounts in addon's namespace.
    - '{__name__="namespace:noobaa_accounts:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Total usage of the noobaa system storage resources in the addon's namespace.
    - '{__name__="namespace:noobaa_usage:max"}'
    #
    # owners: (https://github.com/red-hat-storage/mcg-osd-deployer, Data Federation team)
    #
    # Status of the noobaa service in the addon's namespace.
    - '{__name__="namespace:noobaa_system_health_status:max"}'
    #
    # owners: (https://github.com/red-hat-storage/ocs-operator, OCS Operator team)
    #
    # ocs_advanced_feature_usage shows whether the cluster is using any of the advanced
    # features, like external cluster mode or KMS/PV Encryption etc
    - '{__name__="ocs_advanced_feature_usage"}'
    #
    # owners: (https://github.com/openshift/machine-config-operator/)
    #
    # os_image_url_override:sum tells whether cluster is using default OS image or has been overridden by user
    - '{__name__="os_image_url_override:sum"}'
    #
    # owners: (https://github.com/openshift/vmware-vsphere-csi-driver-operator, @openshift/storage)
    #
    # cluster:vsphere_topology_tags:max shows how many vSphere topology tag categories are configured.
    - '{__name__="cluster:vsphere_topology_tags:max"}'
    #
    # owners: (https://github.com/openshift/vmware-vsphere-csi-driver-operator, @openshift/storage)
    #
    # cluster:vsphere_infrastructure_failure_domains:max shows how many vSphere failure domains, vCenters, datacenters and datastores are configured in a cluster.
    - '{__name__="cluster:vsphere_infrastructure_failure_domains:max"}'
    #
    # owners: (@openshift/openshift-team-api, @polynomial)
    #
    # apiserver_list_watch_request_success_total:rate:sum represents the rate of change for successful LIST and WATCH requests over a 5 minute period.
    - '{__name__="apiserver_list_watch_request_success_total:rate:sum", verb=~"LIST|WATCH"}'
    #
    # owners: (https://github.com/stackrox/stackrox, @stackrox/eng)
    #
    # rhacs:telemetry:rox_central_info provides information about a Central instance of a Red Hat Advanced
    # Cluster Security installation.
    # Expected labels:
    # - build: "release" or "internal".
    # - central_id: unique ID identifying the Central instance.
    # - central_version: the product's full version.
    # - hosting: "cloud-service" or "self-managed".
    # - install_method: "operator", "manifest" or "helm".
    - '{__name__="rhacs:telemetry:rox_central_info"}'
    #
    # owners: (https://github.com/stackrox/stackrox, @stackrox/eng)
    #
    # rhacs:telemetry:rox_central_secured_clusters provides the number of clusters secured by a Central instance of a
    # Red Hat Advanced Cluster Security installation.
    # Expected labels:
    # - central_id: unique ID identifying the Central instance.
    - '{__name__="rhacs:telemetry:rox_central_secured_clusters"}'
    #
    # owners: (https://github.com/stackrox/stackrox, @stackrox/eng)
    #
    # rhacs:telemetry:rox_central_secured_nodes provides the number of nodes secured by a Central instance of a
    # Red Hat Advanced Cluster Security installation.
    # Expected labels:
    # - central_id: unique ID identifying the Central instance.
    - '{__name__="rhacs:telemetry:rox_central_secured_nodes"}'
    #
    # owners: (https://github.com/stackrox/stackrox, @stackrox/eng)
    #
    # rhacs:telemetry:rox_central_secured_vcpus provides the number of vCPUs secured by a Central instance of a
    # Red Hat Advanced Cluster Security installation.
    # Expected labels:
    # - central_id: unique ID identifying the Central instance.
    - '{__name__="rhacs:telemetry:rox_central_secured_vcpus"}'
    #
    # owners: (https://github.com/stackrox/stackrox, @stackrox/eng)
    #
    # rhacs:telemetry:rox_sensor_info provides information about a Sensor instance of a Red Hat Advanced
    # Cluster Security installation.
    # Expected labels:
    # - build: "release" or "internal".
    # - central_id: unique ID identifying the Central instance.
    # - hosting: "cloud-service" or "self-managed".
    # - install_method: "operator", "manifest" or "helm".
    # - sensor_id: unique ID identifying the Sensor instance.
    # - sensor_version: the product's full version.
    - '{__name__="rhacs:telemetry:rox_sensor_info"}'
    #
    # owners: (https://github.com/openshift/cluster-storage-operator, @openshift/storage)
    #
    # cluster:volume_manager_selinux_pod_context_mismatch_total shows how many Pods have two or more containers that have each a different SELinux context. These containers will not be able to start when SELinuxMountReadWriteOncePod feature is extended to all volumes.
    - '{__name__="cluster:volume_manager_selinux_pod_context_mismatch_total"}'
    #
    # owners: (https://github.com/openshift/cluster-storage-operator, @openshift/storage)
    #
    # cluster:volume_manager_selinux_volume_context_mismatch_warnings_total shows how many Pods would not be able to start when SELinuxMountReadWriteOncePod feature is extended to all volumes, because they use a single volume and have a different SELinux contexts each.
    - '{__name__="cluster:volume_manager_selinux_volume_context_mismatch_warnings_total"}'
    #
    # owners: (https://github.com/openshift/cluster-storage-operator, @openshift/storage)
    #
    # cluster:volume_manager_selinux_volume_context_mismatch_errors_total shows how many Pods did not start because they use a single ReadWriteOncePod volume and have a different SELinux context.
    - '{__name__="cluster:volume_manager_selinux_volume_context_mismatch_errors_total"}'
    #
    # owners: (https://github.com/openshift/cluster-storage-operator, @openshift/storage)
    #
    # cluster:volume_manager_selinux_volumes_admitted_total shows how many Pods had set SELinux context and successfuly started.
    - '{__name__="cluster:volume_manager_selinux_volumes_admitted_total"}'
kind: ConfigMap
metadata:
  name: telemetry-config
  namespace: openshift-monitoring
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"

Cluster Samples Operator#

Cluster Samples Operator, работающий в namespace openshift, устанавливает и обновляет потоки образов DropApp Plus и шаблоны.

Во время установки Cluster Samples Operator создает для себя объект конфигурации по умолчанию, а затем формирует примеры потоков образов и шаблоны, включая шаблоны быстрого запуска.

Конфигурация Cluster Samples Operator является ресурсом всего кластера, и развертывание находится в namespace openshift-cluster-samples-operator.

Образ для Cluster Samples Operator содержит поток образов и определения шаблонов для соответствующей версии DropApp Plus. При создании или обновлении каждого образца оператор включает аннотацию, обозначающую версию DropApp Plus. Оператор использует эту аннотацию, чтобы убедиться, что каждый образец соответствует версии выпуска. Образцы, находящиеся за пределами его инвентаря, игнорируются, как и пропущенные образцы. Модификации любых образцов, которыми управляет Оператор, при изменении или удалении аннотации к версии автоматически возвращаются.

Ресурс конфигурации Cluster Samples Operator включает в себя средство завершения, которое удаляет следующее при удалении:

• потоки изображений, управляемые оператором;

• шаблоны, управляемые оператором;

• ресурсы конфигурации, созданные оператором;

• ресурсы состояния кластера.

После удаления Cluster Samples Operator воссоздает ресурс, используя конфигурацию по умолчанию.

Image Registry Operator#

Image Registry Operator управляет одноэлементным экземпляром registry DropApp Plus и всей конфигурацией registry, включая создание хранилища.

Он помогает создать и настроить локальный registry-образов, который может использоваться для хранения и распространения контейнерных образов внутри кластера.

При первоначальном запуске оператор создаст экземпляр ресурса registry-образов по умолчанию на основе конфигурации, обнаруженной в кластере. Например, какой тип облачного хранилища использовать в зависимости от поставщика облачных услуг.

Если для определения полного ресурса registry-образов недостаточно информации, будет определен неполный ресурс, и оператор обновит статус ресурса информацией о том, чего не хватает.

Image Registry Operator запускается в namespace openshift-image-registry и также управляет экземпляром registry в этом расположении. Все ресурсы конфигурации и рабочей нагрузки для registry находятся в этом namespace.

Основными функциями Image Registry Operator являются:

• установка и настройка registry-образов внутри кластера DropApp Plus;

• конфигурирование параметров registry-образов, таких как авторизация и доступ к registry;

• масштабирование и обновление registry-образов по мере необходимости;

• мониторинг и управление состоянием registry-образов;

• обеспечение безопасности registry-образов, включая авторизацию и шифрование данных.

CSI#

CSI (Container Storage Interface) - это стандарт для работы с внешними хранилищами данных в DropApp Plus Plus. CSI добавляет возможность управления хранилищами данных и настройки доступа к ним в DropApp Plus через внешние компоненты, поддерживающие стандарт CSI.

Компоненты CSI представляют собой внешние компоненты, которые не являются частью ядра DropApp Plus. Они делятся на драйверы, реализующие интерфейс CSI для работы с конкретными хранилищами, и связующие компоненты (внешние контроллеры CSI), обеспечивающие взаимодействие между драйвером и API сервером DropApp Plus. И те и другие поставляются в виде образов контейнеров.

Внешние контроллеры CSI это deployment, при котором осуществляется одновременное развертывание всех связующих компонентов в рамках одного pod на инфраструктурных узлах. Каждый компонент запускается в отдельном контейнере.

Список контейнеров, входящих в deployment внешних контроллеров CSI:

• csi-external-provisioner – компонент, следящий за хранилищами и управляющий динамическим выделением в них томов CSI;

• csi-external-attacher – компонент, обеспечивающий подключение и отключение томов CSI к нужным pods;

• csi-external-resizer – компонент, управляющий изменением размеров томов CSI;

• csi-external-snapshotter, csi-snapshot-controller и сsi-snapshot-validation-webhook – компоненты, управляющие созданием и восстановлением снимков (snapshot) томов CSI;

• csi-driver-volume-name – драйвер CSI (например, csi-manila-driver или csi-driver-nfs), реализующий API для работы с определенным хранилищем.

На рабочих узлах используется deployment, в состав которого входят следующие контейнеры (запускаются в рамках одного pod):

• csi-node-driver-registar - компонент, управляющий регистрацией драйверов для устройств хранения данных на узлах DropApp Plus;

• csi-driver-volume-name – драйвер CSI.

Перечень драйверов и операторов в DropApp Plus для работы с CSI-хранилищами:

• Manila:

  • csi-driver-manila;

  • csi-driver-manila-operator;

• Shared resource:

  • csi-driver-shared-resource;

  • csi-driver-shared-resource-operator;

• NFS: csi-driver-nfs.

Для мониторинга работоспособности драйвера в DropApp Plus можно использовать компонент csi-livenessprobe.

Подробные описания всех компонентов, драйверов и операторов представлены в разделах ниже.

Сsi-external-provisioner#

Сsi-external-provisioner - компонент управляет динамическим выделением томов CSI. Обеспечивает создание, монтирование и удаление томов CSI по запросу. Компонент предоставляет API для создания, удаления и монтирования томов и запускается в DropApp Plus в виде pod.

Рекомендуемые флаги приведены в таблице.

Таблица. Рекомендуемые флаги Сsi-external-provisioner.

Сsi-external-provisioner может работать в одном pod с другими внешними контроллерами CSI, такими как Сsi-external-attacher, Сsi-external-snapshotter и Сsi-external-resizer.

Сsi-external-provisioner не масштабируется с большим количеством реплик. Только один экземпляр Сsi-external-provisioner избирается в качестве главного процесса и работает. Новый главный процесс переизбирается через 15 секунд после завершения работы старого процесса.

Внешний поставщик можно использовать для создания объектов CSIStorageCapacity, которые содержат информацию о емкости хранилища, доступной через драйвер. Затем планировщик DropApp Plus использует эту информацию при выборе узлов для модулей с несвязанными томами, ожидающими первого потребителя.

Все объекты CSIStorageCapacity, созданные экземпляром Сsi-external-provisioner, имеют определенные метки:

• csi.storage.k8s.io/drivername имя драйвера CSI;

• csi.storage.k8s.io/managed-by Сsi-external-provisioner для централизованного предоставления, Сsi-external-provisioner для распределенного предоставления.

Они создаются в namespace, указанном в namespace переменной среды.

Каждый экземпляр Сsi-external-provisioner управляет именно теми объектами с метками, которые соответствуют экземпляру.

При необходимости все объекты CSIStorageCapacity, созданные экземпляром Сsi-external-provisioner, могут иметь владельца. Это гарантирует автоматическое удаление объектов при удалении драйвера CSI. Владелец определяется переменными среды POD_NAME/NAMESPACE и параметром --capacity-ownerref-level.

Если владение отключено, администратор хранилища отвечает за удаление потерянных объектов CSIStorageCapacity, и для очистки потерянных объектов драйвера можно использовать следующую команду:

oc delete csistoragecapacities -l csi.storage.k8s.io/drivername=my-csi.example.com

Следуйте последовательности действий, чтобы настроить поддержку емкости.

1. Установите переменные среды POD_NAME и NAMESPACE:

   env:
   - name: NAMESPACE
     valueFrom:
     fieldRef:
     fieldPath: metadata.namespace
   - name: POD_NAME
     valueFrom:
     fieldRef:
     fieldPath: metadata.name
   

2. Примените манифест:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: csi-provisioner
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: csi-provisioner
     template:
       metadata:
         labels:
           app: csi-provisioner
       spec:
         serviceAccount: csi-provisioner
         containers:
           - name: csi-provisioner
             image: dappregistry/1.2/csi-provisioner:v3.3.0
             args:
               - "--csi-address=$(ADDRESS)"
               - "--leader-election"
               - "--http-endpoint=:8080"
             env:
               - name: ADDRESS
                 value: /var/lib/csi/sockets/pluginproxy/mock.socket
             imagePullPolicy: "IfNotPresent"
             volumeMounts:
               - name: socket-dir
                 mountPath: /var/lib/csi/sockets/pluginproxy/
             ports:
               - containerPort: 8080
                 name: http-endpoint
                 protocol: TCP
             livenessProbe:
               failureThreshold: 1
               httpGet:
                 path: /healthz/leader-election
                 port: http-endpoint
               initialDelaySeconds: 10
               timeoutSeconds: 10
               periodSeconds: 20
           - name: mock-driver
             image: quay.io/k8scsi/mock-driver:canary
             env:
               - name: CSI_ENDPOINT
                 value: /var/lib/csi/sockets/pluginproxy/mock.socket
             volumeMounts:
               - name: socket-dir
                 mountPath: /var/lib/csi/sockets/pluginproxy/
         volumes:
           - name: socket-dir
             emptyDir:
   

3. Добавьте в командную строку флаг --enable-capacity.

4. Добавьте StorageCapacity: true в информационный объект CSIDriver.

5. Если Сsi-external-provisioner не развернут StatefulSet, настройте при помощи флага --capacity-ownerref-level какими объектами будет происходить управление CSIStorageCapacity.

6. Настройте частоту опроса драйвера для обнаружения измененной емкости с помощью флага --capacity-poll-interval.

7. Настройте количество рабочих потоков, используемых параллельно с помощью флага --capacity-threads.

8. Включите создание информации также для классов хранения, которые используют немедленную привязку тома с файлом --capacity-for-immediate-binding.

Csi-external-attacher#

Сsi-external-attacher - компонент управляет присоединением томов к pods. Он обеспечивает подключение томов к указанному pod. Компонент предоставляет API для присоединения томов и запускается в DropApp Plus в виде pod.

Параметры командной строки Сsi-external-attacher представлены в таблице.

Таблица. Параметры командной строки.

1. Создайте новую учетную запись службы и предоставьте ей права для запуска Сsi-external-attacher.

2. Разверните Сsi-external-attacher:

oc create deploy/deployment.yaml

Содержание манифеста будет следующим:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-attacher
  namespace: default

---

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: external-attacher-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "patch"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["csinodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["volumeattachments"]
    verbs: ["get", "list", "watch", "patch"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["volumeattachments/status"]
    verbs: ["patch"]

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csi-attacher-role
subjects:
  - kind: ServiceAccount
    name: csi-attacher
    # replace with non-default namespace name
    namespace: default
roleRef:
  kind: ClusterRole
  name: external-attacher-runner
  apiGroup: rbac.authorization.k8s.io

---

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # replace with non-default namespace name
  namespace: default
  name: external-attacher-cfg
rules:
- apiGroups: ["coordination.k8s.io"]
  resources: ["leases"]
  verbs: ["get", "watch", "list", "delete", "update", "create"]

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csi-attacher-role-cfg
  namespace: default
subjects:
  - kind: ServiceAccount
    name: csi-attacher
    namespace: default
roleRef:
  kind: Role
  name: external-attacher-cfg
  apiGroup: rbac.authorization.k8s.io

Этот файл содержит все объекты RBAC, необходимые для запуска Сsi-external-attacher.

Вышеприведенная команда - для создания развертывания в DropApp Plus. Deployment - это набор компонентов, которые запускаются вместе и выполняют определенную задачу. В данном случае, команда создает deployment, который запускает контейнер с драйвером DropApp Plus.

Сsi-external-attacher может работать в одном pod с другими внешними контроллерами CSI, такими как Csi-external-provisioner, Csi-external-snapshotter и Csi-external-resizer.

Csi-external-resizer#

Csi-external-resizer - компонент управляет изменением размеров томов. Он обеспечивает операцию изменения размеров томов CSI. Компонент предоставляет API для изменения размеров томов и запускается в DropApp Plus в виде pod.

Параметры командной строки Csi-external-resizer аналогичны приведенным в таблицах разделов Сsi-external-attacher и Сsi-external-provisioner.

1. Создайте новую учетную запись службы и предоставьте ей права для запуска Csi-external-resizer.

2. Разверните Csi-external-resizer:

oc create deploy/deployment.yaml

Содержание манифеста будет следующим:

kind: Deployment
apiVersion: apps/v1
metadata:
  name: csi-resizer
spec:
  replicas: 1
  selector:
    matchLabels:
      external-resizer: mock-driver
  template:
    metadata:
      labels:
        external-resizer: mock-driver
    spec:
      serviceAccount: csi-resizer
      containers:
        - name: csi-resizer
          image: dappregistry/1.2/csi-resizer:v1.6.0
          args:
            - "--v=5"
            - "--csi-address=$(ADDRESS)"
            - "--leader-election"
            - "--http-endpoint=:8080"
          env:
            - name: ADDRESS
              value: /var/lib/csi/sockets/pluginproxy/mock.socket
          imagePullPolicy: "IfNotPresent"
          ports:
            - containerPort: 8080
              name: http-endpoint
              protocol: TCP
          livenessProbe:
            failureThreshold: 1
            httpGet:
              path: /healthz/leader-election
              port: http-endpoint
            initialDelaySeconds: 10
            timeoutSeconds: 10
            periodSeconds: 20
          volumeMounts:
            - name: socket-dir
              mountPath: /var/lib/csi/sockets/pluginproxy/

        - name: mock-driver
          image: quay.io/k8scsi/mock-driver:canary
          imagePullPolicy: "IfNotPresent"
          env:
            - name: CSI_ENDPOINT
              value: /var/lib/csi/sockets/pluginproxy/mock.socket
          volumeMounts:
            - name: socket-dir
              mountPath: /var/lib/csi/sockets/pluginproxy/

      volumes:
        - name: socket-dir
          emptyDir: