Документация находится в разработке, может содержать неполную информацию.

Компоненты управляющего слоя

Компоненты управляющего слоя (control plane) отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый под, когда количество реплик в конфигурации Deployment не соответствует запущенному количеству реплик).

Компоненты управляющего слоя могут быть запущены на любой машине в кластере. Однако для упрощения настройки и поддержки кластера все компоненты управляющего слоя запускают на выделенных узлах, где запрещают запуск пользовательских контейнеров. Если компоненты запущены на одном узле, это конфигурация single-master. Если компоненты запустить на нескольких узлах, то это переводит управляющий слой в режим высокой доступности multi-master.

kube-apiserver

Сервер API — компонент Kubernetes управляющего слоя, который предоставляет API Kubernetes клиентам.

Основной реализацией API-сервера Kubernetes является kube-apiserver. kube-apiserver может быть горизонтально масштабирован, то есть развёрнут на несколько экземпляров. Можно запускать несколько экземпляров kube-apiserver и балансировать трафик между этими экземплярами на разных узлах.

Модуль control-plane-manager упрощает настройку kube-apiserver для включения режима аудита.

etcd

Распределённое и высоконадёжное хранилище данных в формате ключ-значение, которое используется как основное хранилище всех данных кластера в Kubernetes.

Как и kube-apiserver, для обеспечения высокой доступности поддерживает запуск в нескольких экземплярах, образуя etcd-кластер.

kube-scheduler

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

При планировании развёртывания подов на узлах учитываются множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными или программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождения данных, предельных сроков.

В случаях, когда общего алгоритма не хватает (например, нужно учитывать storageClass подключаемых PVC), алгоритм планировщика можно расширить за счёт плагинов.

Подробнее об алгоритме работы планировщика и подключении плагинов описано в разделе Планировщик.

kube-controller manager

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

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

  • Контроллер узла (Node Controller): уведомляет и реагирует на сбои узла.
  • Контроллер репликации (Replication Controller): поддерживает правильное количество подов для каждого объекта контроллера репликации в системе.
  • Контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (Endpoints), то есть связывает сервисы (Services) и поды.
  • Контроллеры учетных записей и токенов (Account & Token Controllers): создают стандартные учетные записи и токены доступа API для новых пространств имен.

cloud-controller manager

cloud-controller manager запускает контроллеры, которые взаимодействуют с основными облачными провайдерами. В рамках документации на DVP не рассматривается.

TODO нужна какая-то ссылка про cloud-controller-manager, например на какой-то модуль?

Управление компонентами управляющего слоя

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

Функции модуля control-plane-manager:

  • Управление сертификатами, необходимыми для работы компонентов, в том числе продление, выпуск при изменении конфигурации и т.п. Позволяет автоматически поддерживать безопасную конфигурацию управляющего слоя и быстро добавлять дополнительные имена (SAN) для организации защищенного доступа к API Kubernetes.
  • Настройка компонентов. Автоматически создает необходимые конфигурации и манифесты компонентов управляющего слоя.
  • Upgrade или downgrade компонентов. Поддерживает в кластере одинаковые версии компонентов.
  • Управление конфигурацией etcd-кластера и его узлов. Масштабирует etcd по количеству master-узлов, выполняет миграцию из конфигурации кластера с одним master-узлом в мультикластерный и наоборот.
  • Настройка kubeconfig. Обеспечивает всегда актуальную конфигурацию для работы kubectl. Генерирует, продлевает, обновляет kubeconfig с правами cluster-admin и создает симлинк пользователю root, чтобы kubeconfig использовался по умолчанию.
  • Расширение работы планировщика, за счет подключения внешних плагинов через вебхуки. Управляется ресурсом KubeSchedulerWebhookConfiguration. Позволяет использовать более сложную логику при решении задач планирования нагрузки в кластере. Например:
    • размещение подов приложений организации хранилища данных ближе к самим данным,
    • приоретизация узлов в зависимости от их состояния (сетевой нагрузки, состояния подсистемы хранения и т. д.),
    • разделение узлов на зоны, и т. п.
  • Резервные копии настроек сохраняются в директории /etc/kubernetes/deckhouse/backup.

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

Модуль control-plane-manager обеспечивает жизненный цикл SSL-сертификатов управляющего слоя:

  • Корневые сертификаты для kube-apiserver и etcd. Они хранятся в секрете 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).
  • Клиентские и серверные сертификаты для подключения компонентов управляющего слоя друг к другу. Сертификаты выписываются, продлеватся и перевыписываются, если что-то изменилось (например, список 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.

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

Модуль настраивает работу компонентов управляющего слоя в конфигурациях как single-master, так и multi-master.

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

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

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

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

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

Масштабирование узлов управляющего слоя осуществляется автоматически, с помощью метки 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. В остальных случаях все необходимые действия происходят автоматически. Обратите внимание, что при масштабировании с любого количества master-узлов до 1 рано или поздно на последнем шаге возникнет ситуация масштабирования узлов с 2 до 1.

Другие операции с master-узлами рассмотрены в разделе работа с master-узлами.

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

Обновление patch-версии компонентов управляющего слоя (то есть в рамках минорной версии, например с 1.27.3 на 1.27.5) происходит автоматически вместе с обновлением версии Deckhouse. Управлять обновлением patch-версий нельзя.

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

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

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

  • Общие замечания:
    • Обновление в разных NodeGroup выполняется параллельно. Внутри каждой NodeGroup узлы обновляются последовательно, по одному.
  • При upgrade:
    • Обновление происходит последовательными этапами, по одной минорной версии: 1.26 -> 1.27, 1.27 -> 1.28, 1.28 -> 1.29.
    • На каждом этапе сначала обновляется версия control plane, затем происходит обновление kubelet на узлах кластера.
  • При downgrade:
    • Успешный downgrade гарантируется только на одну версию вниз от максимальной минорной версии control plane, когда-либо использовавшейся в кластере.
    • Сначала происходит downgrade kubelet’a на узлах кластера, затем — downgrade компонентов control plane.

Аудит

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

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

  • логирование операций создания, удаления и изменения ресурсов; TODO здесь какие ресурсы имеются в виду? Надо бы уточнить.
  • логирование действий, совершаемых от имени сервисных аккаунтов из системных пространств имён: kube-system, d8-*;
  • логирование действий, совершаемых с ресурсами в системных пространствах имён: kube-system, d8-*.

Отключить сбор логов по базовым политикам можно установив флаг basicAuditPolicyEnabled в false.

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