Выделяемая в Облаке квота для кластера
| Тип кластера | Количество нод (master/worker) | Ресурсы для 1 ноды (CPU/RAM/SSD) |
|---|---|---|
| Тестовый | 1 / 2 (min) 3* | 8 / 16Gb / 50Gb |
| Продуктивный | 3 / 3 (min) >3 | 8 / 16Gb / 50Gb и более |
*-рекомендованное значение
"Если у нас есть две больших воркер ноды и одна их них упадет, то мы потеряем половину всех ресурсов кластера. Если вы не предусмотрели 100% запас ресурсов, то это приведет к катастрофе, так как оставшаяся нода не сможет выдержать двойную нагрузку. Наличие множества воркеров снижает эти риски на n. К примеру, если у вас есть 10 нод в кластере и выключится одна, то вы потеряете только 10% от всей мощности кластера" https://habr.com/ru/companies/nixys/articles/573316/
Для корректного расчета квоты необходимо учесть:
- Принцип построения отказоустойчивого кластера требует создания кворума состоящего из трёх “master” нод, который рассчитывается по формуле (n/2)+1 нода, где n – количество нод (если кластер потеряет 2 ноды, работа продолжится на оставшейся);
Пример расчета квоты:
- Требуемая конфигурация worker-ноды – 8 CPU \ 16 GB RAM \ 100 GB SSD
- Требуемое количество worker – нод = 5
- Требуемое количество master – нод для создания кворума = 3
- Требуемое количество service – нод = 2
- Общее количество требуемых нод = 10
Итого: (8 CPUx10)+(16 RAMx10)+(100 GB SSDx10) = 80 CPU \ 160 GB RAM \ 1 TB SSD
Лимиты
| Параметр | Значение |
|---|---|
| Максимальное количество нод в 1 группе | 15 |
| Максимальное количество подов на 1 ноде | 100 |
| Максимальное количество балансировщиков в 1 проекте | 100 |
| Максимальное количество persistent volume на одной ноде | 26 |
| Минимальный размер одного persistent volume | 1 Gb |
| Максимальное количество vRAM 1 ноды | 128 Gb |
| Максимальное количество vCPU 1 ноды | 32 |
| Максимальный размер загрузочного диска ноды | 1 Tb |
Компоненты и состав кластера
- Версия kubernates: 1.29.5 (https://kubernetes.io/releases/)
- Операционная система для всех нод кластера: Ubuntu 22.04 LTS
- CNI – flannel by default (VxLAN) or Calico
- ETCD
- Cert-manager
- DNS service – CoreDNS
- GitOPS – ArgoCD
- Мониторинг – Prometheus, Grafana
- Безопасность – Aqua Trivy
- Dashboard
Компоненты возможно менять и добавлять согласно техническому заданию.
Однако, поддерживаемой и проверенной версией, является кластер описываемой конфигурации.
Запрос кластера
При обращении в поддержку важно предоставить следующие данные:
| Тип | Пример | Описание |
|---|---|---|
| Префикс кластера* | Kube-cluster | Желаемый префикс (имя) для сущностей кластера (названия инстансов, сетей, маршрутизатора e.t.c. будут начинаться с этого имени) |
| Тип кластера | Закрытый, Закрытый с LB для API, Открытый | Описание и отличие см. ниже таблицы |
| Количество worker-нод | >=2 | Минимальное значение 2. Ноды для рабочей нагрузки |
| DNS-сервера | 77.88.8.8 / 77.88.8.1 | Указать предпочтительные DNS сервера, в ином случае, конфигурируются публичные (Yandex DNS) |
| Сеть для внутренней адресации | 192.168.192.0/24 | Необходимо самостоятельно подключить данную сеть в маршрутизатор с инстансами |
| CNI | Flannel, Calico | По-умолчанию установлен Flannel (VxLAN) |
| Мониторинг | Grafana + Prometheus | Идёт по-умолчанию. В случае отсутствия необходимости, не указывать |
| Безопасность | Aqua Trivy | По-умолчанию не установлен. Указать, если требуется |
| GitOPS | Argo CD | Идёт по-умолчанию. В случае отсутствия необходимости, не указывать |
- Закрытый кластер – в данной инсталляции мастер-ноды кластера не имеют внешних адресов и находятся в приватной сети. Доступ до мастер-нод и API k8s осуществляется с выделенной ноды;
- Закрытый кластер с Load Balancer для API – в данной инсталляции мастер-ноды кластера не имеют внешних адресов и находятся в приватной сети. Доступ до мастер-нод по SSH осуществляется с выделенной ноды. Доступ до API осуществляется через “белый” адрес Loadbalancer;
- Кластер открытого типа с floating IP на мастер-нодах – в данной инсталляции мастер-ноды кластера имеют floating IP. Все доступы на мастер-ноды (SSH/API) через “белый” адрес, по группам безопасности (минимальный набор правил – 22, 6443, icmp).
Ответственность
Мы отвечаем за:
- создание и доступность мастер-нод;
- создание рабочих нод;
- оперативное добавление ресурсов к кластеру (при соответствующей заявке заказчика);
- обновление версий кластера k8s;
- мониторинг работы мастер-нод;
- регулярное резервное копирование ETCD кластера;
- возможность автовосстановления нод;
- техническую поддержку в рамках установленного SLA;
- актуальность и своевременное пополнение базы знаний – https://wiki.inferit.cloud.
Мы не несём ответсвенности за:
- управление рабочими нодами;
- создание и работу приложения внутри кластера;
- добавление persistent volume;
- инициирование масштабирования и обновления кластера;
- настройки безопасности внутри кластера;
- корректность работы заказчика с кластером k8s (прямое или косвенное влияние на работоспособность и отказоустойчивость кластера).
