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

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

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

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

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

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

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

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

Версия Kubernetes

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

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

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

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

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

Выделяйте от 4 CPU / 8 ГБ RAM на инфраструктурные узлы. Для мастер-узлов и узлов мониторинга используйте быстрые диски.

Рекомендуются следующие минимальные ресурсы для инфраструктурных узлов в зависимости от их роли в кластере:

  • Мастер-узел — 4 CPU, 8 ГБ RAM, 60 ГБ дискового пространства на быстром диске (400+ IOPS);
  • Frontend-узел — 2 CPU, 4 ГБ RAM, 50 ГБ дискового пространства;
  • Узел мониторинга (для нагруженных кластеров) — 4 CPU, 8 ГБ RAM; 50 ГБ дискового пространства на быстром диске (400+ IOPS).
  • Системный узел:
    • 2 CPU, 4 ГБ RAM, 50 ГБ дискового пространства — если в кластере есть выделенные узлы мониторинга;
    • 4 CPU, 8 ГБ RAM, 60 ГБ дискового пространства на быстром диске (400+ IOPS) — если в кластере нет выделенных узлов мониторинга.
  • Worker-узел — требования аналогичны требованиям к master-узлу, но во многом зависят от характера запускаемой на узле (узлах) нагрузки.

Примерный расчет ресурсов, необходимых для кластера:

  • Типовой кластер: 3 мастер-узла, 2 frontend-узла, 2 системных узла. Такая конфигурация потребует от 24 CPU и 48 ГБ RAM, плюс быстрые диски с 400+ IOPS для мастер-узлов.
  • Кластер с повышенной нагрузкой (с выделенными узлами мониторинга): 3 мастер-узла, 2 frontend-узла, 2 системных узла, 2 узла мониторинга. Такая конфигурация потребует от 28 CPU и 64 ГБ RAM, плюс быстрые диски с 400+ IOPS для мастер-узлов и узлов мониторинга.
  • Для компонентов Deckhouse желательно выделить отдельный storageClass на быстрых дисках.
  • Добавьте к этому worker-узлы с учетом характера полезной нагрузки.

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

Мастер-узлы

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

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

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

Может быть полезно:

Frontend-узлы

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

Используйте inlet LoadBalancer для OpenStack и облачных сервисов, где возможен автоматический заказ балансировщика (Yandex Cloud, VK Cloud, Selectel Cloud, AWS, GCP, Azure и т. п.). Используйте inlet HostPort с внешним балансировщиком для bare metal или vSphere.

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

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

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

Выберите тип inlet’а (определяет способ поступления трафика).

При развертывании кластера с помощью Deckhouse в облачной инфраструктуре, в которой поддерживается заказ балансировщиков (например, решения на базе OpenStack, сервисы Yandex Cloud, VK Cloud, Selectel Cloud, AWS, GCP, Azure и т. п.), используйте inlet LoadBalancer или LoadBalancerWithProxyProtocol.

В средах, в которых автоматический заказ балансировщиков недоступен (в bare-metal-кластерах, vSphere, некоторых решениях на базе OpenStack), используйте inlet HostPort или HostPortWithProxyProtocol. В этом случае можно либо добавить несколько A‑записей в DNS для соответствующего домена, либо использовать внешний сервис балансировки нагрузки (например, взять решения от Cloudflare, Qrator или настроить metallb).

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

Алгоритм выбора inlet’а:

Алгоритм выбора inlet'а

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор логов

Настройте централизованный сбор логов.

Настройте централизованный сбор логов с системных и пользовательских приложений с помощью модуля log-shipper.

Достаточно создать custom resource с описанием того, что нужно собирать: ClusterLoggingConfig или PodLoggingConfig; кроме того, необходимо создать custom resource с данными о том, куда отправлять собранные логи: ClusterLogDestination.

Дополнительная информация:

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

Настройте резервное копирование etcd. Напишите план восстановления.

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

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

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

Сообщество

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

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

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