Міркування щодо великих кластерів

Кластер — це набір вузлів (фізичних або віртуальних машин), на яких працюють агенти Kubernetes, керовані через панель управління. Kubernetes v1.35 підтримує кластери розміром до 5,000 вузлів. Зокрема, Kubernetes розроблений для роботи з конфігураціями, які відповідають всім наступним критеріям:

• Не більше 110 Podʼів на вузол
• Не більше 5,000 вузлів
• Не більше 150,000 Podʼів загалом
• Не більше 300,000 контейнерів загалом

Ви можете масштабувати свій кластер, додаючи чи видаляючи вузли. Спосіб залежить від того, як ваш кластер розгорнутий.

Обмеження ресурсів у хмарних постачальників

Щоб уникнути проблем із квотами хмарного постачальника при створенні кластера із багатьма вузлами, розгляньте наступне:

• Запит на збільшення квоти ресурсів хмари, таких як:
  • Кількість компʼютерів
  • Центральні процесори (CPU)
  • Томи зберігання
  • Використані IP-адреси
  • Набори правил фільтрації пакетів
  • Кількість балансувальників навантаження
  • Підмережі
  • Потоки логів
• Керування діями масштабування кластера для введення нових вузлів партіями, з паузою між партіями, оскільки деякі хмарні постачальники обмежують швидкість створення нових екземплярів.

Компоненти панелі управління

Для великого кластера вам потрібна панель управління з достатніми обчислювальними та іншими ресурсами.

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

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

Наприклад, використовуючи керований балансувальник навантаження, ви налаштовуєте його на надсилання трафіку, який походить з kubelet та Podʼів у зоні відмови A, і направляєте цей трафік лише до хостів панелі управління, які також знаходяться в зоні A. Якщо один хост панелі управління або зона відмови точки доступу А виходить з мережі, це означає, що весь трафік панелі управління для вузлів у зоні А тепер надсилається між зонами. Запуск декількох хостів панелі управління в кожній зоні зменшує ймовірність цього результату.

Сховище etcd

Для покращення продуктивності великих кластерів ви можете зберігати обʼєкти подій (Event) в окремому відділеному екземплярі etcd.

При створенні кластера ви можете (за допомогою власних інструментів):

• запускати та налаштовувати додаткові екземплярти etcd
• налаштовувати API сервер для використання його для зберігання подій

Деталі з налаштування та управління etcd для великого кластера наведено в розділах Управління кластерами etcd для Kubernetes та Налаштування високодоступного кластера etcd за допомогою kubeadm.

Ресурси надбудов

Обмеження ресурсів Kubernetes допомагають мінімізувати вплив витоків памʼяті та інших способів, якими поди та контейнери можуть впливати на інші компоненти. Ці обмеження ресурсів стосуються ресурсів надбудов так само як вони стосуються робочих навантажень застосунків.

Наприклад, ви можете встановити обмеження CPU та памʼяті для компонента логування:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Типові обмеження для надбудов, як правило, базуються на даних, зібраних з досвіду роботи кожної надбудови на невеликих або середніх кластерах Kubernetes. При роботі на великих кластерах надбудови часто споживають більше деяких ресурсів, ніж встановлено типовими обмеженнями. Якщо великий кластер розгортати без налаштування цих значень, надбудови можуть постійно не штатно завершувати роботу через досягнення обмеження памʼяті. З іншого боку, надбудова може працювати, але з поганою продуктивністю через обмеження часу CPU.

Щоб уникнути проблем з ресурсами надбудов у кластері з багатьма вузлами, розгляньте наступне:

• Деякі надбудови масштабуються вертикально — є одна репліка надбудови для кластера чи обслуговування всієї зони відмов. Для таких надбудов збільшуйте запити та обмеження при масштабуванні вашого кластера.
• Багато надбудов масштабуються горизонтально — ви додаєте можливості, запускаючи більше Podʼів, але з дуже великим кластером вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті. Vertical Pod Autoscaler може працювати в режимі recommender, щоб надати запропоновані цифри для запитів та обмежень.
• Деякі надбудови працюють як одна копія на вузол, керована DaemonSet: наприклад, агрегатор логів рівня вузла. Так само як і у випадку горизонтально масштабованих надбудов, вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті.

Пріоритетність компонентів, необхідних для кластера

Щоб забезпечити, що компоненти, необхідні для кластера (такі як CoreDNS, metrics-server та інші критичні надбудови) плануються раніше за інші робочі навантаження і не витісняються подами з нижчим пріоритетом, запускайте їх із системним PriorityClass, таким як system-cluster-critical або system-node-critical.

Що далі

• VerticalPodAutoscaler — це власний ресурс, який ви можете розгортати у свій кластер, щоб допомогти управляти запитами та обмеженнями ресурсів для Podʼів. Дізнайтеся більше про Vertical Pod Autoscaler та як ви можете використовувати його для масштабування компонентів кластера, включаючи критичні для кластера надбудови.

• Автомасштабування вузлів

• Надбудова Resizer допомагає автоматично змінювати розміри надбудов при зміні масштабу вашого кластера.