Управление компонентами 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
).
- корневой CA kubernetes (
- Клиентскими сертификатами для подключения компонентов
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
).
- Серверный сертификат API-сервера (
Также позволяет добавить дополнительные 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.23.3
на 1.23.5
) происходит автоматически вместе с обновлением версии Deckhouse. Управлять обновлением patch-версий нельзя.
Обновлением минорной-версии компонентов control plane (например, с 1.23.*
на 1.25.*
) можно управлять с помощью параметра kubernetesVersion, в котором можно выбрать автоматический режим обновления (значение Automatic
) или указать желаемую минорную версию control plane. Версию control plane которая используется по умолчанию (при kubernetesVersion: Automatic
), а также список поддерживаемых версий Kubernetes можно найти в документации.
Обновление control plane выполняется безопасно и для single-master и для multi-master-кластеров. Во время обновления может быть кратковременная недоступность API-сервера. На работу приложений в кластере обновление не влияет и может выполняться без выделения окна для регламентных работ.
Если указанная для обновления версия (параметр kubernetesVersion) не соответствует текущей версии control plane в кластере, то запускается умная стратегия изменения версий компонентов:
- Общие замечания
- Обновление в разных NodeGroup выполняется параллельно. Внутри каждой NogeGroup узлы обновляются последовательно, по одному.
- При upgrade:
- Обновление происходит последовательными этапами, по одной минорной версии: 1.22 -> 1.23, 1.23 -> 1.24, 1.24 -> 1.25.
- На каждом этапе сначала обновляется версия control plane, затем — обновление kubelet на узлах кластера.
- При downgrade:
- Успешный downgrade гарантируется только на одну версию вниз от максимальной минорной версии control plane, когда-либо использовавшейся в кластере.
- Сначала происходит downgrade kubelet’a на узлах кластера, затем — downgrade компонентов control plane.
Аудит
Если требуется журналировать операции с API или отдебажить неожиданное поведение — для всего этого в Kubernetes предусмотрен Auditing. Его можно настроить путём создания правил Audit Policy, а результат работы аудита будет лог-файл /var/log/kube-audit/audit.log
со всеми интересующими операциями.
В установках Deckhouse по умолчанию созданы базовые политики, они отвечают за логирование событий:
- связанных с операциями создания, удаления и изменения ресурсов;
- совершаемых от имён сервисных аккаунтов из системных Namespace
kube-system
,d8-*
; - совершаемых с ресурсами в системных пространствах иимен
kube-system
,d8-*
.
Для выключения базовых политик установите флаг basicAuditPolicyEnabled в false
.
Настройка политик аудита подробно рассмотрена в одноимённой секции FAQ.