Приведённые ниже рекомендации могут быть неактуальны для тестового кластера или кластера разработки, но важны для production-кластера.
Канал и режим обновлений
Используйте канал обновлений EarlyAccess или Stable. Установите окно автоматических обновлений или ручной режим.
Выберите канал обновлений и режим обновлений, который соответствует вашим ожиданиям. Чем стабильнее канал обновлений, тем позже до него доходит новая функциональность.
По возможности используйте разные каналы обновлений для кластеров. Для кластера разработки используйте менее стабильный канал обновлений, нежели для тестового или stage-кластера (pre-production-кластер).
Используйте канал обновлений EarlyAccess или Stable для production-кластеров. Если в production-окружении более одного кластера, используйте для них разные каналы обновлений. Например, EarlyAccess для одного, а Stable — для другого. Если использовать разные каналы обновлений по каким-либо причинам невозможно, установите для кластеров непересекающиеся окна обновлений.
Даже в очень нагруженных и критичных кластерах не стоит отключать использование канала обновлений. Лучшая стратегия — плановое обновление. В инсталляциях Deckhouse Platform (DP), которые не обновлялись полгода или более, могут присутствовать ошибки. Как правило, эти ошибки давно устранены в новых версиях. В этом случае оперативно решить возникшую проблему будет непросто.
Управление окнами обновлений позволяет планово обновлять релизы DP в автоматическом режиме в периоды «затишья», когда нагрузка на кластер далека от пиковой.
Версия Kubernetes
Используйте автоматический выбор версии Kubernetes либо установите версию явно.
В большинстве случаев используйте автоматический выбор версии Kubernetes. В DP такое поведение установлено по умолчанию, но его можно изменить с помощью параметра kubernetesVersion. Обновление версии Kubernetes в кластере не оказывает влияния на приложения и проходит последовательно и безопасно.
Если указан автоматический выбор версии Kubernetes, DP может обновить версию Kubernetes в кластере при обновлении релиза DP (при обновлении минорной версии). Когда версия Kubernetes явно прописана в параметре kubernetesVersion, очередное обновление DP может завершиться неудачей, если окажется, что используемая в кластере версия Kubernetes более не поддерживается.
Если приложение использует устаревшие версии ресурсов или требует конкретной версии Kubernetes по какой-либо другой причине, проверьте, что эта версия поддерживается, и установите её.
Требования к ресурсам
Для production используйте кластер с тремя master-узлами или с разделением ролей узлов. Ресурсы узлов подбирайте по требованиям к ресурсам для выбранного варианта размещения и типа нагрузки.
Требования к ресурсам для каждого варианта размещения приведены на странице «Системные требования». Значения в таблицах учитывают только нагрузку компонентов Deckhouse Platform.
При подготовке production-кластера учитывайте следующее:
- Не используйте одноузловой кластер и кластер с одним master-узлом: они не отказоустойчивы.
- Для master-узлов и узлов мониторинга используйте быстрые диски с производительностью не менее 400 IOPS.
- Для компонентов Deckhouse Platform выделите отдельный StorageClass на быстрых дисках.
- Добавьте к ресурсам worker-узлов ресурсы под пользовательскую нагрузку.
- Проведите нагрузочное тестирование приложений и скорректируйте ресурсы узлов по его результатам.
Подробнее о подборе ресурсов в зависимости от нагрузки — в руководстве «Подбор ресурсов для кластера на bare metal».
Особенности конфигурации
Master-узлы
В кластере должно быть три master-узла с быстрыми дисками 400+ IOPS.
Всегда используйте три master-узла — такое количество обеспечит отказоустойчивость и позволит безопасно выполнять обновление master-узлов. В большем числе master-узлов нет необходимости, а два узла не обеспечат кворума.
Конфигурация master-узлов для облачных кластеров настраивается в параметре masterNodeGroup.
Может быть полезно:
Frontend-узлы
Выделите два или более frontend-узла.
Используйте инлет LoadBalancer для OpenStack и облачных сервисов, где возможен автоматический заказ балансировщика (Yandex Cloud, VK Cloud, Selectel Cloud, AWS, GCP, Azure и т. п.). Используйте инлет HostPort с внешним балансировщиком для bare metal или vSphere.
Frontend-узлы балансируют входящий трафик. На них работают Ingress-контроллеры. У NodeGroup frontend-узлов установлен лейбл node-role.deckhouse.io/frontend. Читайте подробнее про выделение узлов под определённый вид нагрузки…
Используйте более одного frontend-узла. Frontend-узлы должны выдерживать трафик при отказе как минимум одного frontend-узла.
Например, если в кластере два frontend-узла, то каждый frontend-узел должен справляться со всей нагрузкой на кластер в случае, если второй выйдет из строя. Если в кластере три frontend-узла, то каждый frontend-узел должен выдерживать увеличение нагрузки как минимум в полтора раза.
Выберите тип инлета (определяет способ поступления трафика).
При развёртывании кластера с помощью DP в облачной инфраструктуре, в которой поддерживается заказ балансировщиков (например, решения на базе OpenStack, сервисы Yandex Cloud, VK Cloud, Selectel Cloud, AWS, GCP, Azure и т. п.), используйте инлет LoadBalancer или LoadBalancerWithProxyProtocol.
В средах, в которых автоматический заказ балансировщиков недоступен (в bare-metal-кластерах, vSphere, некоторых решениях на базе OpenStack), используйте инлет HostPort или HostPortWithProxyProtocol. В этом случае можно либо добавить несколько A‑записей в DNS для соответствующего домена, либо использовать внешний сервис балансировки нагрузки (например, взять решения от Cloudflare, Qrator или настроить metallb).
Инлет HostWithFailover подходит для кластеров с одним frontend-узлом. Он позволяет сократить время недоступности Ingress-контроллера при его обновлении. Такой тип инлета подойдёт, например, для важных сред разработки, но не рекомендуется для production.
Алгоритм выбора инлета:
Узлы мониторинга
Для нагруженных кластеров выделите два узла мониторинга с быстрыми дисками.
Узлы мониторинга служат для запуска Grafana, Prometheus и других компонентов мониторинга. У NodeGroup узлов мониторинга установлен лейбл node-role.deckhouse.io/monitoring.
В нагруженных кластерах со множеством алертов и большими объёмами метрик выделите под мониторинг отдельные узлы. Если этого не сделать, компоненты мониторинга будут размещены на системных узлах.
При выделении узлов под мониторинг важно, чтобы на них были быстрые диски. Для этого можно привязать storageClass на быстрых дисках ко всем компонентам DP (глобальный параметр storageClass) или выделить отдельный storageClass только для компонентов мониторинга (параметры storageClass и longtermStorageClass модуля prometheus).
Если кластер изначально создаётся с узлами, выделенными под определённый вид нагрузки (системные узлы, узлы под мониторинг и т. п.), то для модулей, использующих тома постоянного хранилища (например, для модуля prometheus), явно укажите соответствующий nodeSelector в конфигурации модуля. Например, для модуля prometheus это параметр nodeSelector.
Системные узлы
Выделите два системных узла.
Системные узлы предназначены для запуска модулей DP. У NodeGroup системных узлов установлен лейбл node-role.deckhouse.io/system.
Выделите два системных узла. В этом случае модули DP будут работать на них, не пересекаясь с пользовательскими приложениями кластера. Читайте подробнее про выделение узлов под определённый вид нагрузки….
Выделите компонентам DP быстрые диски (глобальный параметр storageClass).
Уведомление о событиях мониторинга
Настройте отправку алертов через внутренний Alertmanager или подключите внешний.
Мониторинг будет работать сразу после установки DP, однако для production этого недостаточно. Чтобы получать уведомления об инцидентах, настройте встроенный в DP Alertmanager или подключите свой Alertmanager.
С помощью кастомного ресурса CustomAlertmanager можно настроить отправку уведомлений на электронную почту, в Slack, в Telegram, через webhook, а также другими способами.
Список всех доступных алертов системы мониторинга Deckhouse Platform приведён на отдельной странице документации.
Сбор логов
Настройте централизованный сбор логов.
Настройте централизованный сбор логов с системных и пользовательских приложений с помощью модуля log-shipper.
Достаточно создать кастомный ресурс с описанием того, что нужно собирать: ClusterLoggingConfig или PodLoggingConfig; кроме того, необходимо создать кастомный ресурс с данными о том, куда отправлять собранные логи: ClusterLogDestination.
Дополнительная информация:
Резервное копирование
Настройте резервное копирование etcd. Напишите план восстановления.
Важно. Обязательно настройте резервное копирование данных etcd — это ваша последняя возможность восстановить кластер в случае непредвиденных событий. Храните резервные копии как можно дальше от кластера.
Резервные копии не помогут, если они не работают или вы не знаете, как их использовать для восстановления. Составьте план восстановления на случай аварии (Disaster Recovery Plan, DRP), содержащий конкретные шаги и команды по развёртыванию кластера из резервной копии. Процедуры восстановления описаны в разделе «Резервное копирование и восстановление».
Этот план должен периодически актуализироваться и проверяться учебными тревогами.
Сообщество
Следите за новостями проекта в Telegram.
Вступите в сообщество, чтобы быть в курсе важных изменений и новостей. Вы сможете общаться с людьми, занятыми общим делом. Это позволит избежать многих типичных проблем.
Организация работы production-кластера в Kubernetes требует усилий. Поделитесь опытом работы с DP в сообществе, чтобы помочь другим с переходом в Kubernetes.