Управление control plane

Управление компонентами control plane кластера осуществляется с помощью модуля control-plane-manager, который запускается на всех master-узлах кластера (узлы с лейблом node-role.kubernetes.io/control-plane: "").

Функции управления control plane:

• Управление сертификатами, необходимыми для работы control-plane, в том числе продление, выпуск при изменении конфигурации и т. п. Позволяет автоматически поддерживать безопасную конфигурацию control plane и быстро добавлять дополнительные SAN для организации защищенного доступа к API Kubernetes.
• Настройка компонентов. Автоматически создает необходимые конфигурации и манифесты компонентов control-plane.
• Upgrade/downgrade компонентов. Поддерживает в кластере одинаковые версии компонентов.
• Управление конфигурацией etcd-кластера и его членов. Масштабирует master-узлы, выполняет миграцию из single-master в multi-master и обратно.
• Настройка kubeconfig. Обеспечивает актуальные файлы kubeconfig на узлах control-plane. Генерирует, продлевает и обновляет kubeconfig для компонентов control-plane и admin kubeconfig (admin.conf). По умолчанию создаёт символическую ссылку для root-пользователя (/root/.kube/config -> admin.conf). При включённом модуле user-authz симлинк можно отключить параметром rootKubeconfigSymlink в модуле control-plane-manager (см. FAQ). Также ужесточает права доступа к файлам admin.conf и super-admin.conf.
• Расширение работы планировщика, за счет подключения внешних плагинов через вебхуки. Управляется ресурсом KubeSchedulerWebhookConfiguration. Позволяет использовать более сложную логику при решении задач планирования нагрузки в кластере. Например:
  • размещение подов приложений организации хранилища данных ближе к самим данным,
  • приоритизация узлов в зависимости от их состояния (сетевой нагрузки, состояния подсистемы хранения и т. д.),
  • разделение узлов на зоны, и т. п.

Управление сертификатами

Управляет SSL-сертификатами компонентов control-plane:

• Серверными сертификатами для kube-apiserver и etcd. Они хранятся в Secret’е d8-pki пространства имен kube-system:
  • корневой CA kubernetes (ca.crt и ca.key);
  • корневой CA etcd (etcd/ca.crt и etcd/ca.key);
  • RSA-сертификат и ключ для подписи Service Account’ов (sa.pub и sa.key);
  • корневой CA для extension API-серверов (front-proxy-ca.key и front-proxy-ca.crt).
• Клиентскими сертификатами для подключения компонентов control-plane друг к другу. Выписывает, продлевает и перевыписывает, если что-то изменилось (например, список SAN). Следующие сертификаты хранятся только на узлах:
  • серверный сертификат API-сервера (apiserver.crt и apiserver.key);
  • клиентский сертификат для подключения kube-apiserver к kubelet (apiserver-kubelet-client.crt и apiserver-kubelet-client.key);
  • клиентский сертификат для подключения kube-apiserver к etcd (apiserver-etcd-client.crt и apiserver-etcd-client.key);
  • клиентский сертификат для подключения kube-apiserver к extension API-серверам (front-proxy-client.crt и front-proxy-client.key);
  • серверный сертификат etcd (etcd/server.crt и etcd/server.key);
  • клиентский сертификат для подключения etcd к другим членам кластера (etcd/peer.crt и etcd/peer.key);
  • клиентский сертификат для подключения kubelet к etcd для helthcheck’ов (etcd/healthcheck-client.crt и etcd/healthcheck-client.key).

Также позволяет добавить дополнительные SAN в сертификаты, это дает возможность быстро и просто добавлять дополнительные «точки входа» в API Kubernetes.

При изменении сертификатов также автоматически обновляется соответствующая конфигурация kubeconfig.

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

Поддерживается работа control-plane в конфигурации как single-master, так и multi-master.

В конфигурации single-master:

• kube-apiserver использует только тот экземпляр etcd, который размещен с ним на одном узле;
• На узле настраивается прокси-сервер, отвечающий на localhost,kube-apiserver отвечает на IP-адрес master-узла.

В конфигурации multi-master компоненты control-plane автоматически разворачиваются в отказоустойчивом режиме:

• kube-apiserver настраивается для работы со всеми экземплярами etcd.
• На каждом master-узле настраивается дополнительный прокси-сервер, отвечающий на localhost. Прокси-сервер по умолчанию обращается к локальному экземпляру kube-apiserver, но в случае его недоступности последовательно опрашивает остальные экземпляры kube-apiserver.

Масштабирование master-узлов

Масштабирование узлов control-plane осуществляется автоматически, с помощью лейбла node-role.kubernetes.io/control-plane="":

• Установка лейбла node-role.kubernetes.io/control-plane="" на узле приводит к развертыванию на нем компонентов control-plane, подключению нового узла etcd в etcd-кластер, а также перегенерации необходимых сертификатов и конфигурационных файлов.
• Удаление лейбла node-role.kubernetes.io/control-plane="" с узла приводит к удалению всех компонентов control-plane, перегенерации необходимых конфигурационных файлов и сертификатов, а также корректному исключению узла из etcd-кластера.

Динамическое пороговое значение удаления выселенных подов

Автоматически настраивает оптимальное значение --terminated-pod-gc-threshold в зависимости от размера кластера:

• Малые кластеры (менее 100 узлов): 1000 завершенных подов.
• Средние кластеры (от 100 до 300 узлов): 3000 завершенных подов.
• Крупные кластеры (от 300 узлов): 6000 завершенных подов.

Управление версиями

Обновление patch-версии компонентов control plane (то есть в рамках минорной версии, например с 1.31.13 на 1.31.14) происходит автоматически вместе с обновлением версии Deckhouse. Управлять обновлением patch-версий нельзя.

Обновлением минорной-версии компонентов control plane (например, с 1.31.* на 1.32.*) можно управлять с помощью параметра kubernetesVersion, в котором можно выбрать автоматический режим обновления (значение Automatic) или указать желаемую минорную версию control plane. Версию control plane, которая используется по умолчанию (при kubernetesVersion: Automatic), а также список поддерживаемых версий Kubernetes можно найти в документации.

Обновление control plane выполняется безопасно и для single-master-, и для multi-master-кластеров. Во время обновления может быть кратковременная недоступность API-сервера. На работу приложений в кластере обновление не влияет и может выполняться без выделения окна для регламентных работ.

Если указанная для обновления версия (с параметром kubernetesVersion) не соответствует текущей версии control plane в кластере, запускается умная стратегия изменения версий компонентов:

• Общие замечания:
  • Обновление в разных NodeGroup выполняется параллельно. Внутри каждой NogeGroup узлы обновляются последовательно, по одному.
• При upgrade:
  • Обновление происходит последовательными этапами, по одной минорной версии: 1.31 -> 1.32, 1.32 -> 1.33, 1.33 -> 1.34.
  • На каждом этапе сначала обновляется версия control plane, затем происходит обновление kubelet на узлах кластера.
• При downgrade (не поддерживается для редакций CSE):
  • Успешное понижение версии гарантируется только на одну версию вниз от максимальной минорной версии control plane, когда-либо использовавшейся в кластере.
  • Сначала на узлах кластера выполняется понижение версии kubelet, после чего производится понижение версии компонентов control plane.

Аудит

Если требуется журналировать операции с API или отдебажить неожиданное поведение, для этого в Kubernetes предусмотрен Auditing. Его можно настроить путем создания правил Audit Policy, а результатом работы аудита будет лог-файл /var/log/kube-audit/audit.log со всеми интересующими операциями.

В установках Deckhouse по умолчанию созданы базовые политики, которые отвечают за логирование событий, которые:

• связаны с операциями создания, удаления и изменения ресурсов;
• совершаются от имен сервисных аккаунтов из системных Namespace kube-system, d8-*;
• совершаются с ресурсами в системных пространствах имен kube-system, d8-*.

Для выключения базовых политик установите флаг basicAuditPolicyEnabled в false.

При настройке OIDC-аутентификации в аудит-логах дополнительно включается информация о пользователе в поле user.extra:

• user-authn.deckhouse.io/name — отображаемое имя пользователя
• user-authn.deckhouse.io/preferred_username — предпочитаемое имя пользователя
• user-authn.deckhouse.io/dex-provider — идентификатор провайдера Dex (требует scope federated:id)

Настройка политик аудита подробнее рассмотрена в одноименной секции FAQ.

Feature Gates

Управление feature gates осуществляется с помощью параметра enabledFeatureGates ModuleConfig control-plane-manager.

Изменение списка feature gates вызывает перезапуск соответствующего компонента (например, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet).

Пример включения feature gates ComponentFlagz и ComponentStatusz:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 2
  enabled: true
  settings:
    enabledFeatureGates:
      - ComponentFlagz
      - ComponentStatusz

Если feature gate не поддерживается или имеет статус deprecated, в системе мониторинга будет сгенерирован алерт D8ProblematicFeatureGateInUse, информирующий о том, что feature gate не будет применен.

Описание feature gates доступно в документации Kubernetes.

Защита чувствительных полей кастомных ресурсов

Feature gate CRDSensitiveData обеспечивает защиту чувствительных данных на уровне полей в ресурсах, помеченных маркером x-kubernetes-sensitive-data: true. Функция реализована в виде патча к kube-apiserver (apiextensions-apiserver) и поддерживается, начиная с версии Kubernetes 1.31.

Маркер x-kubernetes-sensitive-data проверяется kube-apiserver при применении ресурса:

• маркер требует, чтобы был включен feature gate CRDSensitiveData (включается автоматически, когда apiserver.encryptionEnabled равен true);
• маркер не допускается устанавливать на корне схемы (на самом узле openAPIV3Schema). Чтобы защитить все поля ресурса, добавьте маркер на свойство spec (или на поддерево ниже него), а не на корень схемы — на корне также находятся системные поля (apiVersion, kind, metadata), которые невозможно зашифровать;
• тип поля должен быть одним из типов OpenAPI v3: string, integer, number, boolean, object или array. Маркер на object или array делает чувствительным всё поддерево;
• поддерживаются поля, объявленные как x-kubernetes-int-or-string: true;
• маркер запрещён внутри веток anyOf, oneOf, allOf и not (это проверяет валидатор структурной схемы).

Если хотя бы одно поле в схеме ресурса помечено x-kubernetes-sensitive-data: true, ко всем кастомным ресурсам этого типа применяются следующие меры защиты:

• Шифрование в etcd — весь ресурс шифруется с помощью того же механизма, что и Kubernetes Secrets. Требует включения параметра apiserver.encryptionEnabled.
• Фильтрация полей на основе RBAC — при выполнении запросов get, list, или watch чувствительные поля удаляются из ответа API, если у вызывающей стороны нет прав get, list или watch на субресурс <resource>/sensitive.
• Маскировка в журнале аудита — значения чувствительных полей всегда заменяются на "******" в журнале аудита, независимо от прав RBAC и уровня аудита.

Чтобы включить защиту чувствительных полей, установите параметр apiserver.encryptionEnabled в true. Feature gate CRDSensitiveData включается автоматически при активации шифрования, его не следует указывать вручную:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: control-plane-manager
spec:
  version: 2
  enabled: true
  settings:
    apiserver:
      encryptionEnabled: true

За подробностями обратитесь к следующим разделам:

• «FAQ» — инструкция по включению защиты чувствительных полей;
• «Примеры» — примеры конфигурации и результатов.

Внешние компоненты

Список стороннего программного обеспечения, используемого в модуле control-plane-manager (информация представлена на английском языке):

• Kubernetes

  License: Apache License 2.0

  An open source system for managing containerized applications across multiple hosts.

• Etcd 3.6.10

  License: Apache License 2.0

  A distributed reliable key-value store for the most critical data of a distributed system.