Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Архитектура узлов платформы

1. Об узлах платформы

Узлом в Nova Container Platform SE является виртуальная машина или физический сервер, на котором размещаются компоненты платформы и среды Kubernetes, а также пользовательские приложения. Для стабильной работы ваших приложений важно следить за состоянием узлов, их метриками, своевременно реагировать на возникающие ошибки.

В Nova Container Platform SE вы можете получить информацию об узле, его конфигурации и событиях через объект Node в Kubernetes. Для этого можно использовать как утилиту kubectl, так и веб-консоль Nova.

Следующие компоненты каждого узла непосредственно обеспечивают работу Pod в среде Kubernetes:

Среда исполнения контейнеров (Container Runtime): обеспечивает работу контейнеров в ОС. В Nova Container Platform SE используется среда Containerd, однако, существуют и альтернативные решения, например, cri-o, Docker.

Kubelet: Kubelet работает на каждом узле платформы, выполняет роль агента и промежуточного звена между Kubernetes и службами ОС, обрабатывает запросы на запуск, удаление или изменение контейнеров в составе Pod, контролирует состояние контейнеров, обслуживает задачи на настройке сетевых политик и форвардинга портов. Kubelet управляет только теми контейнерами, создание которых было выполнено через Kubernetes.

Kube-proxy: основной задачей компонента является отслеживание изменений объектов Service и Endpoints в Kubernetes API и трансляция изменений в сетевые правила ОС. В Nova Container Platform SE компонент Kube-proxy работает в режиме IPVS.

На диаграмме ниже схематично отображены компоненты Kubelet и Kube-proxy.

Компоненты Kubelet и Kube-proxy в Kubernetes
Рисунок 1. Компоненты Kubelet и Kube-proxy

2. Роли узлов

В Nova Container Platform SE узлы платформы могут иметь разные логические роли, а также объединяться в группы узлов.

Поскольку в Kubernetes роль определяется стандартной меткой (Label) узла, например, node-role.kubernetes.io/control-plane, то вы можете указать дополнительные метки, чтобы сгруппировать узлы кластера по определенному признаку.

При формировании групп узлов на этапе установки платформы вы также можете указать дополнительные параметры Labels, Taints и Tolerations.

Дополнительная информация по формированию групп узлов на этапе установки платформы представлена в разделе Описание процессов установки и обновления.

По умолчанию в Nova Container Platform SE используется несколько преднастроенных ролей:

  • control-plane: Мастер-узлы. Содержат ключевые компоненты Nova Container Platform SE и Kubernetes.

  • infra: Инфраструктурные узлы. Содержат служебные компоненты Nova Container Platform SE.

  • ingress: Выделенные узлы для балансировки входящего трафика. На узлах размещается дополнительный контроллер Ingress Nginx.

  • worker: Рабочие узлы для размещения пользовательских сервисов, приложений и различных нагрузок.

По имени роли определяется, какой набор базовых компонентов будет установлен на узел кластера. Ниже представлена обобщенная схема с указанием ролей узлов и их основными компонентами.

Роли узлов в Nova Container Platform SE
Рисунок 2. Роли узлов в Nova Container Platform SE

2.1. Мастер-узлы

В кластере Kubernetes мастер-узлы имеют специальную метку node-role.kubernetes.io/control-plane. Мастер узлы обеспечивают работу ключевых компонентов среды Kubernetes, таких как Kubernetes API, Etcd, Kubernetes controller manager, Kubernetes Scheduler и другие.

В таблице ниже представлен перечень компонентов Kubernetes на мастер-узлах.

Компонент Описание

Kubernetes API

Компонент, который предоставляет интерфейс взаимодействия (API) остальным компонентам кластера и пользователям.

Etcd

Основное хранилище данных Kubernetes. Множество компонентов кластера следят за состояниями объектов в Etcd через Kubernetes API и приводят данное состояние к описанному (желаемому).

Kubernetes controller manager

Компонент, обеспечивающий основные циклы управления Kubernetes. Controller Manager отслеживает конфигурации в Etcd через Kubernetes API и вносит необходимые изменения для достижения указанного состояния какого-либо компонента.

Kubernetes scheduler

Компонент, задача которого состоит в определении подходящих узлов для вновь создаваемых Pod.

Кроме компонентов Kubernetes Control Plane на мастер-узлах располагается хранилище секретов StarVault, локальный балансировщик Nginx, сервис автоматической разблокировки StarVault Unseal. Данные сервисы запускаются в ОС как службы systemd, в виде статических Pod и Deployment в Kubernetes.

В таблице ниже представлен перечень дополнительных компонентов Nova Container Platform SE на мастер-узлах.

Компонент Тип Описание

StarVault

Служба Systemd

Компонент Nova Container Platform SE для организации внешнего хранилища секретов, инфраструктуры PKI и OAuth-провайдера.

StarVault Unseal

Служба Systemd

Служба для автоматической разблокировки (распечатывания) хранилища секретов StarVault в случае его полного перезапуска или блокировки.

Nginx

Static Pod

Внутренний балансировщик нагрузки для обеспечения отказоустойчивого доступа к серверам Kubernetes API.

Secrets Store CSI

Kubernetes Deployment

Компонент Nova Container Platform SE, который позволяет переносить из StarVault ключи, секреты или сертификаты в кластер Kubernetes, сохранять их в объектах Secret или ConfigMap и монтировать в Pod в виде тома.

StarVault CSI

Kubernetes Deployment

Компонент кластера, который позволяет использовать StarVault в качестве провайдера секретов для Secrets Store CSI.

В Nova Container Platform SE поддерживается использование одного либо трех мастер-узлов. Для эксплуатации Nova Container Platform SE в продуктивных средах рекомендуется использовать три мастер-узла.

2.2. Инфраструктурные узлы

Отдельные инфраструктурные узлы в кластере Kubernetes предназначены для размещения платформенных сервисов Nova Container Platform SE, а также служебных сервисов пользователя. Это позволяет обеспечить работоспособность высоконагруженных сервисов без влияния на пользовательские сервисы и сервисы Control Plane.

Поскольку для платформенных и служебных сервисов может требоваться постоянное хранилище, на инфраструктурных узлах доступен компонент Local Path CSI, который обеспечивает работу Persistent Volumes в Kubernetes.

Данные томов (Persistent Volumes), предоставленных с помощью Local Path CSI на инфраструктурных узлах, хранятся на узлах локально и не защищаются репликацией. При размещении собственных служебных сервисов на инфраструктурных узлах убедитесь, что ваше ПО (сервис) поддерживает репликацию данных встроенными средствами.

Кроме этого, инфраструктурные узлы содержат отдельный балансировщик входящего трафика (сервис-прокси) Ingress Nginx, доступный через объект IngressClass nginx-internal. Данный подход позволяет полностью разделить потоки продуктивного и служебного трафика на уровне Ingress-контроллеров.

В кластере Kubernetes инфраструктурные узлы имеют специальную метку node-role.kubernetes.io/infra. Для ограничения запуска произвольных сервисов на данных узлах также установлены параметры Taints с значением node-role.kubernetes.io/infra:NoSchedule.

Большинство компонентов базового модуля Nova Container Platform SE, а также все дополнительные модули размещаются на инфраструктурных узлах платформы. Веб-интерфейсы платформенных сервисов доступны только через объект IngressClass nginx-internal.

В Nova Container Platform SE поддерживается использование одного и более инфраструктурных узлов. Для эксплуатации в продуктивных средах рекомендуется использовать три инфраструктурных узла. Платформенные сервисы в Nova Container Platform SE развертываются в кластерном (высокодоступном) режиме, когда используется три и более инфраструктурных узла. Дальнейшее увеличение количества узлов не влияет на конфигурацию платформенных сервисов.

2.3. Узлы балансировки

В Nova Container Platform SE опционально могут быть использованы отдельные узлы для балансировки входящего трафика. На данных узлах размещаются только компоненты контроллера Ingress Nginx, который доступен через объект IngressClass nginx-public.

Вы можете использовать данные узлы в случаях:

  • Когда вам необходимо вынести узлы, принимающие трафик от внешних клиентов, в отдельный сегмент (DMZ).

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

В кластере Kubernetes узлы балансировки имеют специальную метку node-role.kubernetes.io/ingress. Для ограничения запуска произвольных сервисов на данных узлах также установлены параметры Taints с значением node-role.kubernetes.io/ingress:NoSchedule.

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

2.4. Рабочие узлы

Рабочие узлы предназначены для размещения пользовательских нагрузок. Данные узлы не имеют ограничительных меток и допускают запуск любых сервисов и приложений.

В кластере Kubernetes рабочие узлы имеют специальную метку node-role.kubernetes.io/worker. В кластерах с использованием трех узлов либо установленных без выделенных узлов с ролью ingress, рабочие узлы имеют две метки node-role.kubernetes.io/worker и node-role.kubernetes.io/ingress.

3. Доступные операции

Администратор платформы может выполнять различные операции с узлами кластера Kubernetes: