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

Функционал управления 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. Они хранятся в секрете d8-pki namespace 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;
  • На каждом мастер-узле настраивается дополнительный прокси-сервер, отвечающий на localhost. Прокси-сервер по умолчанию обращается к локальному экземпляру kube-apiserver, но в случае его недоступности последовательно опрашивает остальные экземпляры kube-apiserver.

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

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

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

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

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

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

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

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

Поддерживаемые версии Kubernetes

Версия Kubernetes Обновление с нее Приведение кластера к версии
1.16 Да Да
1.17 Да Да
1.18 Да Да
1.19 Да Да
1.20 Да Да
1.21 Нет Да