Управление компонентами 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. Обеспечивает всегда актуальную конфигурацию для работы kubectl. Генерирует, продлевает, обновляет kubeconfig с правами cluster-admin и создает symlink пользователю root, чтобы kubeconfig использовался по умолчанию.

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

Управляет 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, который размещен с ним на одном узле;
  • kube-apiserver отвечает на localhost.

В конфигурации 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-кластера.

Важно: при масштабировании узлов с 2-х до 1-го требуются ручные действия с etcd. В остальных случаях все необходимые действия происходят автоматически.

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

Обновление patch-версии какого-либо компонента control-plane (т.е. в рамках минорной версии, например с 1.19.3 на 1.19.8) происходит автоматически вместе с версией Deckhouse.

Обновление minor-версии какого-либо компонента control-plane происходит безопасным способом. Желаемая минорная версия указывается в настройках control-plane. Если указанная версия не соответствует текущей, то запускается умная стратегия изменения версий компонентов control-plane:

  • При upgrade:
    • Обновление происходит последовательно, по одной минорной версии: 1.19 -> 1.20, 1.20 -> 1.21, 1.21 -> 1.22.
    • Переход на следующий шаг невозможен до тех пор, пока все компоненты control-plane не обновились до текущего шага обновления.
    • Обновление происходит максимум на одну версию новее, чем версии kubelet на узлах.
  • При downgrade:
    • Обновление происходит последовательно, по одной минорной версии: 1.22 -> 1.21, 1.21 -> 1.20, 1.20 -> 1.19.
    • Версия мастера не может быть старше версии узла: downgrade не происходит, если версии kubelet на узлах еще не даунгрейднуты.
    • Версия компонента при обновлении вниз может быть только на одну меньше, чем максимальная minor-версия control plane компонентов, когда либо использовавшаяся в данном кластере:
      • Например, maxUsedControlPlaneVersion = 1.20. Минимально возможная версия control plane компонентов в кластере — 1.19.

Список поддерживаемых версий Kubernetes…

Аудит

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

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

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

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

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