Приведенные ниже рекомендации могут быть неактуальны для тестового кластера или кластера разработки, но важны для 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 по какой-либо другой причине, проверьте, что эта версия поддерживается, и установите ее явно.

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

Выделяйте от 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 для мастер-узлов и узлов мониторинга.
  • Для компонентов платформы желательно выделить отдельный storageClass на быстрых дисках.
  • Добавьте к этому worker-узлы с учетом характера полезной нагрузки.

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

Мастер-узлы

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

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

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

Frontend-узлы

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

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

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

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

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

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

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

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

Подробнее про настройку сети: управление сетью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщество

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

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

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