Приведённые ниже рекомендации важны для production-кластера и могут быть неактуальны для тестового кластера или кластера разработки.

Канал и режим обновлений

Используйте канал обновлений Early Access или Stable. Установите окно автоматических обновлений или ручной режим.

Выберите канал обновлений и режим обновлений в соответствии с вашими требованиями. Чем стабильнее канал обновлений, тем позже в нём появляется новая функциональность.

По возможности используйте разные каналы обновлений для разных кластеров. Для кластера разработки используйте менее стабильный канал обновлений, чем для тестового или stage-кластера (pre-production-кластер).

Мы рекомендуем использовать канал обновлений Early Access или Stable для production-кластеров. Если в production-окружении больше одного кластера, предпочтительно использовать для них разные каналы обновлений. Например, Early Access для одного, а Stable — для другого. Если использовать разные каналы обновлений по каким-либо причинам невозможно, рекомендуется устанавливать разные окна обновлений.

Даже в очень нагруженных и критичных кластерах не стоит отключать использование канала обновлений. Лучшая стратегия — плановое обновление. В кластерах, которые не обновлялись полгода и более, могут присутствовать ошибки, которые, как правило, уже устранены в новых версиях. В этом случае оперативно решить возникшую проблему будет непросто.

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

Версия Kubernetes

Используйте автоматический выбор версии Kubernetes либо установите версию явно.

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

Если включён автоматический выбор версии Kubernetes, платформа может обновить версию Kubernetes в кластере при обновлении релиза платформы (при обновлении минорной версии).

Если версия Kubernetes явно указана в параметре kubernetesVersion, обновление платформы может завершиться неудачей, если используемая в кластере версия Kubernetes более не поддерживается.

Если приложение использует устаревшие версии ресурсов или требует конкретной версии Kubernetes по какой-либо другой причине, проверьте, что эта версия поддерживается, и установите ее явно.

Выбор архитектуры кластера

Deckhouse Virtualization Platform поддерживает несколько вариантов архитектуры кластера — от одноузловых до распределённых конфигураций. Выбор конкретного варианта зависит от требований: необходимости быстрого тестового развёртывания, обеспечения высокой доступности или изоляции системных сервисов от пользовательских нагрузок.

Одноузловой кластер (Single Node / Edge) — все компоненты управления, служебные сервисы и виртуальные машины размещаются на одном сервере. Подходит для тестовых окружений и edge-сценариев. Требует минимального объёма ресурсов, но не обеспечивает отказоустойчивость.

Кластер с одним master-узлом и worker-узлами — один узел выполняет функции управления, виртуальные машины размещаются на выделенных worker-узлах. Подходит для небольших кластеров, где требуется разделение системных сервисов и пользовательских нагрузок. Отказоустойчивость отсутствует.

Трёхузловой кластер (High Availability) — компоненты управления распределяются по трём master-узлам, что обеспечивает отказоустойчивость control plane и продолжение работы при сбое одного из узлов. Пользовательская нагрузка может выполняться как на этих же серверах, так и на выделенных worker-узлах. Рекомендуется для production-окружений.

Высокодоступный распределённый кластер — компоненты управления развёртываются на трёх выделенных master-узлах, при необходимости системные сервисы, мониторинг и ingress выносятся на отдельные system- или frontend-узлы. Пользовательские виртуальные машины выполняются исключительно на worker-гипервизорах. Обеспечивает высокую доступность, масштабируемость и изоляцию пользовательских нагрузок от системных сервисов. Применяется в крупных кластерах.

Дополнительная информация об архитектурных решениях приведена в разделе Архитектурные решения.

Требования к ресурсам

Прежде чем приступить к развёртыванию кластера, необходимо провести планирование ресурсов, которые могут потребоваться для его работы. Для этого следует ответить на несколько вопросов:

  • Какая нагрузка планируется на кластер?
  • Сколько виртуальных машин планируется запускать?
  • Требуется ли кластеру режим высокой доступности?
  • Какой тип хранилища будет использоваться (SDS или внешнее)?

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

При использовании программно-определяемых хранилищ (SDS) на узлах, которые участвуют в организации хранилища, необходимо предусмотреть дополнительные диски сверх указанных минимальных требований. Эти диски будут использоваться SDS для хранения данных виртуальных машин.

В зависимости от архитектуры, для корректной работы платформы требуются следующие минимальные ресурсы:

Архитектура Запуск нагрузки Master-узел Worker-узел Системный узел Frontend-узел
Одноузловая платформа
(Single Node / Edge)		 На одном узле 3 vCPU
10 ГБ ОЗУ		 — — —
Многоузловая платформа
(1 master-узел + worker-узлы)		 На всех узлах 6 vCPU
6 ГБ ОЗУ		 2 vCPU
4 ГБ ОЗУ		 — —
Трёхузловая платформа
(3 master-узла, High Availability)		 На всех узлах 6 vCPU
14 ГБ ОЗУ		 — — —
Платформа с выделенными worker-узлами
(3 master-узла + worker-узлы)		 Только на worker-узлах 5 vCPU
11 ГБ ОЗУ		 2 vCPU
5 ГБ ОЗУ		 — —
Распределённая архитектура Только на worker-узлах 4 vCPU
9 ГБ ОЗУ		 1 vCPU
2 ГБ ОЗУ		 4 vCPU
10 ГБ ОЗУ		 1 vCPU
2 ГБ ОЗУ

Количество виртуальных машин, которые можно запускать на узлах, ограничивается параметром maxPods в свойствах ресурса NodeGroup. При планировании количества ВМ учитывайте, что лимит maxPods включает все поды на узле: системные поды, контейнеризированную нагрузку и виртуальные машины. Каждая виртуальная машина занимает один под в кластере.

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

Особенности конфигурации

Планирование подсетей кластера

Все подсети кластера не должны пересекаться друг с другом.

Определите подсети IP-адресов для кластера:

  • Подсеть узлов — используется узлами для связи между собой. Это единственная подсеть, которая физически существует в сети организации и маршрутизируется в вашей инфраструктуре. Должна быть реальной сетью вашего датацентра.
  • Подсеть для подов (podSubnetCIDR) — виртуальная сеть внутри кластера, используется для назначения IP-адресов подам Kubernetes (включая системные поды и контейнеризированную нагрузку).
  • Подсеть для сервисов (serviceSubnetCIDR) — виртуальная сеть внутри кластера, используется для назначения IP-адресов сервисам Kubernetes типа ClusterIP для внутрикластерного взаимодействия.
  • Подсети адресов для виртуальных машин (virtualMachineCIDRs) — виртуальные сети внутри кластера, используются для назначения IP-адресов виртуальным машинам. Поддерживается указание нескольких подсетей.

Дополнительная информация о настройке сетей виртуальных машин приведена в разделе Сети виртуальных машин.

Master-узлы

В кластере должно быть три master-узла с быстрыми дисками 400+ IOPS.

Всегда используйте три master-узла — такое количество обеспечит отказоустойчивость и позволит безопасно выполнять обновление master-узлов. В большем числе master-узлов нет необходимости, а два узла не обеспечат кворума.

Если на узлах control plane нужно запускать рабочую нагрузку (виртуальные машины), что характерно для конфигураций Одноузловой кластер (Single Node / Edge) и Трёхузловой кластер (High Availability), необходимо настроить допуски (tolerations) в конфигурации виртуальных машин или в классе виртуальных машин, чтобы разрешить размещение ВМ на master-узлах.

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

Frontend-узлы

Выделите два или более frontend-узла.

Используйте инлет HostPort с внешним балансировщиком.

Frontend-узлы балансируют входящий трафик. На них работают Ingress-контроллеры. У NodeGroup frontend-узлов установлен лейбл node-role.deckhouse.io/frontend. Подробнее о выделении узлов под определённый вид нагрузки.

Используйте более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного frontend-узла.

Например, если в кластере два frontend-узла, каждый frontend-узел должен обрабатывать всю нагрузку на кластер в случае выхода из строя второго узла. Если в кластере три frontend-узла, каждый frontend-узел должен выдерживать увеличение нагрузки как минимум в полтора раза.

Платформа поддерживает три способа поступления трафика из внешнего мира:

  • HostPort — устанавливается Ingress-контроллер, который доступен на портах узлов через hostPort;
  • HostPortWithProxyProtocol — устанавливается Ingress-контроллер, который доступен на портах узлов через hostPort и использует proxy-protocol для получения настоящего IP-адреса клиента;
  • HostWithFailover — устанавливаются два Ingress-контроллера (основной и резервный).

Инлет HostWithFailover подходит для кластеров с одним frontend-узлом. Он позволяет сократить время недоступности Ingress-контроллера при его обновлении. Такой тип инлета подойдет, например, для важных сред разработки, но не рекомендуется для production.

Узлы мониторинга

Для нагруженных кластеров выделите два узла мониторинга с быстрыми дисками.

Узлы мониторинга служат для запуска Grafana, Prometheus и других компонентов мониторинга. У NodeGroup узлов мониторинга установлен лейбл node-role.deckhouse.io/monitoring.

В нагруженных кластерах со множеством алертов и большими объёмами метрик рекомендуется выделить отдельные узлы для мониторинга. Если этого не сделать, компоненты мониторинга будут размещены на системных узлах.

При выделении узлов под мониторинг важно, чтобы на них были быстрые диски. Для этого можно привязать storageClass на быстрых дисках ко всем компонентам платформы (глобальный параметр storageClass) или выделить отдельный storageClass только для компонентов мониторинга (параметры storageClass и longtermStorageClass модуля prometheus).

Если кластер изначально создаётся с узлами, выделенными под определённый вид нагрузки (системные узлы, узлы под мониторинг и т. п.), то для модулей, использующих тома постоянного хранилища (например, для модуля prometheus), рекомендуется явно указывать соответствующий nodeSelector в конфигурации модуля. Например, для модуля prometheus это параметр nodeSelector.

Системные узлы

Выделите два системных узла.

Системные узлы предназначены для запуска модулей платформы. У NodeGroup системных узлов установлен лейбл node-role.deckhouse.io/system.

Выделение двух системных узлов обеспечивает работу модулей платформы без пересечения с пользовательскими приложениями кластера. Подробнее о выделении узлов под определённый вид нагрузки.

Компонентам платформы желательно выделить быстрые диски (глобальный параметр storageClass).

Конфигурирование хранилища

Настройте одно или несколько хранилищ для дисков виртуальных машин:

  • Программно-определяемые хранилища (SDS):
    • [sds-local-volume](../../../modules/sds-local-volume/stable/) — локальное хранилище на основе LVM. Высокая производительность, но без репликации. Подходит для временных данных или при наличии внешнего бэкапа.
    • [sds-replicated-volume](../../../modules/sds-replicated-volume/stable/) — реплицируемое хранилище на основе DRBD. Обеспечивает отказоустойчивость за счет репликации между узлами. Рекомендуется для production.
  • Внешние хранилища: Ceph, NFS, TATLIN.UNIFIED (Yadro), Huawei Dorado, HPE 3par, iSCSI. Подключаются через соответствующие CSI-драйверы.

При использовании SDS на узлах, участвующих в организации хранилища, необходимо предусмотреть дополнительные диски сверх минимальных требований к ресурсам узлов. Размер дополнительных дисков зависит от планируемого объёма данных виртуальных машин.

Дополнительная информация о настройке хранилищ приведена в разделе Настройка хранилищ.

Конфигурирование классов виртуальных машин

Создайте собственный класс виртуальной машины (один или несколько).

Класс generic по умолчанию не рекомендуется использовать в production.

Настройте политики управления ресурсами ВМ:

  • используйте type: Host для одинаковых узлов (одинаковая архитектура процессора);
  • используйте type: Discovery для разных типов процессоров.

Политики сайзинга ограничивают допустимые конфигурации ресурсов ВМ (количество ядер, память, доля использования ядра) и предотвращают создание ВМ с неоптимальными конфигурациями. Параметр coreFractions управляет переподпиской (overcommit) по CPU: задавая минимальную долю использования ядра, вы гарантируете каждой ВМ соответствующую часть CPU и тем самым ограничиваете максимально допустимый уровень переподписки ресурсов.

Дополнительная информация о настройках VirtualMachineClass приведена в разделе Настройки VirtualMachineClass.

Разграничение доступа

Настройте аутентификацию пользователей и разграничение доступа. Для production рекомендуется использовать проекты с настройкой ролевой модели.

Платформа поддерживает управление внутренними пользователями и группами, а также интеграцию с внешними провайдерами аутентификации:

  • Внутренние пользователи и группы — создаются через ресурсы User и Group модуля user-authn.
  • Внешние провайдеры аутентификации — LDAP, OIDC, GitHub, GitLab, Crowd, Bitbucket Cloud. Можно подключить несколько провайдеров одновременно.

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

Настройте проекты и права доступа в соответствии с планируемым использованием кластера. Проекты (ресурс Project) обеспечивают изолированные окружения для создания ресурсов пользователя. Настройки проекта позволяют задать квоты для ресурсов, ограничить сетевое взаимодействие и настроить профиль безопасности.

Разграничение доступа настраивается через ролевую модель с использованием стандартного подхода RBAC Kubernetes. Можно использовать существующие роли или создать свои:

  • Manage-роли — для администраторов платформы. Позволяют конфигурировать кластер, управлять виртуальными машинами на уровне всей платформы и создавать проекты (тенанты) для пользователей.
  • Use-роли — для пользователей проектов. Позволяют управлять ресурсами (включая виртуальные машины) внутри назначенных проектов.

Дополнительная информация о настройке проектов и ролевой модели приведена в разделах Проекты и Ролевая модель.

Уведомление о событиях мониторинга

Настройте отправку алертов через внутренний Alertmanager или подключите внешний.

Мониторинг будет работать сразу после установки платформы, однако для production этого недостаточно. Чтобы получать уведомления об инцидентах, настройте встроенный в платформе Alertmanager или подключите свой Alertmanager.

С помощью custom resource CustomAlertmanager можно настроить отправку уведомлений на электронную почту, в Slack, в Telegram, через webhook, а также другими способами.

Список всех доступных алертов системы мониторинга приведён на отдельной странице документации.

Резервное копирование

Обязательно настройте резервное копирование данных etcd — это ваша последняя возможность восстановить кластер в случае непредвиденных событий. Храните резервные копии как можно дальше от кластера.

Резервные копии не помогут, если они не работают или вы не знаете, как их использовать для восстановления. Рекомендуем составить план восстановления на случай аварии (Disaster Recovery Plan), содержащий конкретные шаги и команды по развертыванию кластера из резервной копии.

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

Сообщество

Следите за новостями проекта в Telegram.

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

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