Подсистема Kubernetes & Scheduling

В данном подразделе описывается архитектура модулей, входящих в подсистему Kubernetes & Scheduling платформы Deckhouse Kubernetes Platform (DKP).

В подсистему Kubernetes & Scheduling входят следующие модули:

• control-plane-manager — основной модуль подсистемы, с помощью которого осуществляется управление компонентами control plane кластера;
• descheduler — анализирует состояние кластера и выполняет вытеснение подов в соответствии с активными стратегиями;
• vertical-pod-autoscaler — автоматически корректирует запросы и лимиты ресурсов контейнеров в подах на основе фактического потребления. Архитектура модуля описана на соответствующей странице.

В подразделе также описывается архитектура control plane и агента kubelet.

В Deckhouse Kubernetes Platform (DKP) используется стандартный («vanilla») кластер Kubernetes. Control plane кластера включает в себя следующие базовые компоненты:

1. kube-apiserver — API-сервер Kubernetes. Обрабатывает REST-запросы, предоставляет интерфейс доступа к общему состоянию кластера, через который взаимодействуют все остальные компоненты, валидирует ресурсы Kubernetes API и сохраняет их в хранилище etcd. Включает следующие контейнеры:

• kube-apiserver — основной контейнер;
• kube-apiserver-healthcheck — сайдкар-контейнер, который позволяет проверять работоспособность kube-apiserver без включения анонимной аутентификации и без открытия порта, не прошедшего проверку подлинности. Использует клиентский сертификат для аутентификации на API-сервере. Является Open Source-продуктом.

2. etcd — распределённое хранилище типа «ключ-значение», где хранится вся конфигурация и ресурсы Kubernetes-кластера.

3. kube-scheduler — планировщик Kubernetes. Анализирует ресурсы узлов и размещает поды с учетом ограничений и правил, таких как affinity и taints.

4. kube-controller-manager — диспетчер контроллеров Kubernetes. Запускает циклы контроллеров, которые отслеживают и корректируют состояние стандартных ресурсов Kubernetes, приводя их к желаемому состоянию. Примеры контроллеров, которые поставляются с Kubernetes: replication controller, endpoints controller, namespace controller и ServiceAccount controller.

Взаимодействие компонентов control plane Kubernetes изображено на схеме архитектуры модуля control-plane-manager.

Kubelet не является компонентом control plane, но играет ключевую роль в работе Kubernetes-кластера.

Kubelet — это агент, который работает на каждом узле Kubernetes-кластера. Он обеспечивает запуск контейнеров в подах и их работу в соответствии со спецификациями. Kubelet непрерывно взаимодействует с kube-apiserver, проверяя и поддерживая состояние узлов и контейнеров. Kubelet также отвечает за запуск компонентов control plane.

Взаимодействия kubelet изображены на схеме архитектуры модуля control-plane-manager.

Kubelet взаимодействует со следующими компонентами:

1. kubernetes-api-proxy — проксирует запросы к kube-apiserver, отправляемые на адрес localhost. Входит в состав модуля control-plane-manager.

2. kube-apiserver-healthcheck — проверяет состояние kube-apiserver.

C kubelet взаимодействуют следующие компоненты:

1. kube-apiserver:

• получение логов с подов (обработка команды kubectl logs);
• подключение к запущенным подам (обработка команды kubectl exec);
• переадресация портов (обработка команды kubectl port-forward).

2. prometheus-main — собирает метрики kubelet.

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

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

• Управление сертификатами — выпуск, продление и обновление сертификатов, необходимых для работы control plane. Позволяет автоматически поддерживать безопасную конфигурацию control plane и оперативно добавлять дополнительные альтернативные имена субъекта (Subject Alternative Name, SAN) для организации защищенного доступа к API Kubernetes.
• Настройка компонентов — автоматическое создание необходимых конфигураций и манифестов компонентов control plane.
• Обновление и откат версий компонентов (upgrade/downgrade) — поддержание в кластере согласованных версий компонентов.
• Управление конфигурацией etcd-кластера и его членов — масштабирование master-узлов и миграция между одномастерными и мультимастерными конфигурациями.
• Настройка kubeconfig — поддержание актуальной конфигурации для работы kubectl на узлах кластера. Генерация, продление и обновление kubeconfig с правами cluster-admin, а также создание символьной ссылки для пользователя root, чтобы kubeconfig использовался по умолчанию.
• Расширение работы планировщика — подключение внешних плагинов через вебхуки с использованием ресурса KubeSchedulerWebhookConfiguration. Позволяет использовать продвинутую логику при решении задач планирования нагрузки в кластере, например:

- размещение подов приложений организации хранилища данных ближе к самим данным;

- приоритизация узлов в зависимости от их состояния (сетевой нагрузки, состояния подсистемы хранения и т. д.);

- разделение узлов на зоны, и т. п.

Архитектура модуля control-plane-manager на уровне 2 модели C4 и его взаимодействия с другими компонентами изображены на следующей диаграмме:

Модуль состоит из следующих компонентов:

1. d8-control-plane-manager (DaemonSet) — управляет компонентами control plane кластера и запускается на всех master-узлах. Состоит из следующих контейнеров:

• control-plane-manager — основной контейнер. Является разработкой компании «Флант».
• Набор сайдкар-контейнеров для предварительного скачивания образов соответствующих компонентов control plane. Контейнеры стоят на паузе и выполняют только функцию хранения образов:
• image-holder-kube-apiserver;
• image-holder-kube-apiserver-healthcheck;
• image-holder-kube-controller-manager;
• image-holder-kube-scheduler;
• image-holder-etcd.

2. kubernetes-api-proxy (статические поды) — на каждом master-узле настраивается дополнительный прокси-сервер, отвечающий на запросы к localhost. По умолчанию проксирует запросы к локальному экземпляру kube-apiserver, а в случае его недоступности последовательно опрашивает остальные экземпляры kube-apiserver. Включает в себя следующие контейнеры:

• kubernetes-api-proxy — прокси-сервер на базе NGINX;
• kubernetes-api-proxy-reloader — сайдкар-контейнер, перезапускающий прокси-сервер при изменении конфигурации. Является разработкой компании «Флант».

3. d8-etcd-backup (CronJob) — периодически выполняет резервное копирование базы данных etcd кластера. Состоит из контейнера:

• backup — контейнер с shell-скриптом, который через утилиту etcdctl создает снимок базы данных и сохраняет его в каталог /var/lib/etcd на master-узле (каталог по умолчанию, может быть изменен через параметры модуля).

Модуль взаимодействует со следующими компонентами:

1. kube-apiserver:

• управление компонентами control-plane кластера;
• проксирование и балансировка запросов к kube-apiserver, отправляемых на адрес localhost.

2. etcd:

• управление конфигурацией etcd-кластера и его членов;
• периодическое резервное копирование базы данных.

С модулем взаимодействуют следующие внешние компоненты:

1. kubelet — запросы к kube-apiserver, отправляемые на адрес localhost, проксируются компонентом kubernetes-api-proxy модуля.

Мониторинг control plane кластера осуществляется с помощью модуля monitoring-kubernetes-control-plane, который обеспечивает безопасный сбор метрик и предоставляет базовый набор правил мониторинга следующих компонентов кластера:

• kube-apiserver;
• kube-controller-manager;
• kube-scheduler;
• etcd.

Модуль состоит из одного компонента:

1. control-plane-proxy (DaemonSet) — запускается на всех master-узлах кластера и состоит из одного контейнера:

• kube-rbac-proxy — авторизующий прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам.

Control-plane-proxy взаимодействует со следующими компонентами:

1. kube-apiserver — авторизация запросов на получение метрик.

2. Компоненты control plane кластера — control-plane-proxy пересылает авторизованные запросы на метрики до:

• kube-controller-manager;
• kube-scheduler;
• etcd.

С control-plane-proxy взаимодействует prometheus-main для сбора метрик компонентов control plane.

Взаимодействие модуля monitoring-kubernetes-control-plane с control plane кластера изображено на приведенной выше схеме архитектуры модуля control-plane-manager.

Метрики kube-apiserver собираются prometheus-main напрямую. Модуль monitoring-kubernetes-control-plane добавляет правила сбора этих метрик в конфигурацию prometheus-main.

VPA может работать в двух режимах:

• Автоматическое изменение запросов ресурсов:
• InPlaceOrRecreate (по умолчанию в Kubernetes, начиная с версии 1.33) — VPA пытается изменить ресурсы без пересоздания подов. Если обновить ресурсы «на месте» (in-place) невозможно, VPA переходит к схеме, аналогичной режиму Recreate: под, для которого невозможно обновить ресурсы, вытесняется, и вместо него контроллер создает новый под с обновленными ресурсами.

Чтобы использовать режим InPlaceOrRecreate в Kubernetes до версии 1.33, включите экспериментальную функцию (feature gate) InPlacePodVerticalScaling в настройках модуля control-plane-manager.

• Auto (по умолчанию в Kubernetes до версии 1.33) — VPA изменяет ресурсы без пересоздания подов, но при необходимости действует аналогично режиму Recreate и перезапускает под. Это устаревший режим, и его поддержка будет прекращена в будущих версиях Deckhouse Kubernetes Platform (DKP).
• Recreate — VPA может изменять ресурсы у работающих подов, перезапуская их. В случае одного пода (replicas: 1) это приведет к недоступности сервиса на время перезапуска. VPA не пересоздает поды, если они были созданы без контроллера.
• Только рекомендации, без изменения ресурсов:
• Initial — ресурсы подов изменяются только при их создании, но не в процессе работы.
• Off — VPA не меняет ресурсы автоматически. Однако, с его помощью можно просматривать рекомендуемые ресурсы с помощью команды d8 k describe vpa.

При использовании VPA и включении соответствующего режима, запрашиваемые ресурсы устанавливаются автоматически на основе данных из Prometheus. 

Перед использованием вертикального масштабирования (VPA) необходимо учитывать ряд ограничений:

• Перезапуск подов при изменении ресурсов:

- Обновление запрашиваемых ресурсов — экспериментальная функция, каждый раз при изменении ресурсов VPA пересоздаёт под, и он может быть назначен на другой узел;

- Поды могут пересоздаваться на других узлах.

• Совместимость с HPA:

- VPA не рекомендуется использовать совместно с HPA по CPU и памяти;

- VPA можно использовать с HPA с custom/external метриками.

• Проблемы с большими кластерами — VPA может работать и в больших кластерах, но нагрузка на VPA возрастает при росте числа подов.
• Проблемы с Pending-подами — VPA может рекомендовать ресурсы выше доступных в кластере, из-за чего поды могут застрять в статусе Pending.
• Проблемы при удалении VPA — если удалить VPA или отключить его (режим Off), ресурсы останутся в последнем измененном значении. Это может привести к путанице, когда в Helm указаны одни ресурсы, в контроллере — другие, а у подов — третьи.
• Использование нескольких VPA-ресурсов на один под — может привести к непредсказуемому поведению.

При использовании VPA рекомендуется настроить Pod Disruption Budget.

VPA состоит из 3 компонентов:

• Recommender — мониторит настоящее (делая запросы в Metrics API, который реализован в модуле prometheus-metrics-adapter) и прошлое потребление ресурсов (делая запросы в Trickster перед Prometheus) и предоставляет рекомендации по CPU и памяти для контейнеров.
• Updater — проверяет, что у подов с VPA выставлены корректные ресурсы, если нет — убивает эти поды, чтобы контроллер пересоздал поды с новыми запрашиваемыми ресурсами.
• Admission Plugin — задает запрашиваемые ресурсы при создании новых подов (контроллером или из-за активности Updater’а).

При изменении ресурсов компонентом Updater это происходит с помощью Eviction API, поэтому учитываются Pod Disruption Budget для обновляемых подов.