Вузли

Kubernetes виконує ваше навантаження шляхом розміщення контейнерів у Podʼах для запуску на Вузлах. Вузол може бути віртуальною або фізичною машиною, залежно від кластера. Кожен вузол керується панеллю управління і містить необхідні служби для запуску Podʼів.

Зазвичай в кластері є кілька вузлів; в умовах навчання чи обмежених ресурсів може бути всього один вузол.

Компоненти на вузлі включають kubelet, середовище виконання контейнерів та kube-proxy.

Управління

Є два основних способи додавання Вузлів до API-сервера:

1. kubelet на вузлі самостійно реєструється в панелі управління.
2. Ви (або інший користувач) вручну додаєте обʼєкт Node.

Після створення обʼєкта Node, або якщо kubelet на вузлі самостійно реєструється, панель управління перевіряє, чи новий обʼєкт Node є дійсним. Наприклад, якщо ви спробуєте створити Вузол з наступним JSON-маніфестом:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes внутрішньо створює обʼєкт Node. Kubernetes перевіряє чи kubelet зареєструвався в API-сервері, що відповідає полю metadata.name Node. Якщо вузол є справним (тобто всі необхідні служби працюють), то він може запускати Podʼи. В іншому випадку цей вузол ігнорується для будь-якої діяльності кластера доки він не стане справним.

Назва обʼєкта Node повинно бути дійсним імʼям DNS-піддомену.

Унікальність назв Вузлів

Назва ідентифікує Node. Два Вузли не можуть мати однакову назву одночасно. Kubernetes також припускає, що ресурс з такою ж назвою — це той самий обʼєкт. У випадку Вузла припускається неявно, що екземпляр, який використовує ту ж назву, матиме той самий стан (наприклад, мережеві налаштування, вміст кореневого диска) та атрибути, такі як мітки вузла. Це може призвести до невідповідностей, якщо екземпляр був змінений без зміни його назви. Якщо Вузол потрібно замінити або значно оновити, наявний обʼєкт Node повинен бути видалений з API-сервера спочатку і знову доданий після оновлення.

Самореєстрація Вузлів

Коли прапорець kubelet --register-node є true (типово), kubelet спробує зареєструвати себе в API-сервері. Цей підхід використовується більшістю дистрибутивів.

Для самореєстрації kubelet запускається з наступними параметрами:

• --kubeconfig — Шлях до облікових даних для автентифікації на API-сервері.

• --cloud-provider — Як взаємодіяти з хмарним постачальником для отримання метаданих про себе.

• --register-node — Автоматична реєстрація в API-сервері.

• --register-with-taints — Реєстрація вузла з заданим списком позначок (розділених комами <ключ>=<значення>:<ефект>).

  Нічого не відбувається, якщо register-node є false.

• --node-ip — Необовʼязковий розділений комами список IP-адрес вузла. Можна вказати лише одну адресу для кожного роду адрес. Наприклад, у кластері з одним стеком IPv4 ви встановлюєте це значення як IPv4-адресу, яку повинен використовувати kubelet для вузла. Див. налаштування подвійного стека IPv4/IPv6 для отримання відомостей з запуску кластера з подвійним стеком.

  Якщо ви не вказали цей аргумент, kubelet використовує стандартну IPv4-адресу вузла, якщо є; якщо у вузла немає адреси IPv4, тоді kubelet використовує стандартну IPv6-адресу вузла.

• --node-labels - Мітки для додавання при реєстрації вузла в кластері (див. обмеження міток, що накладаються втулком доступу NodeRestriction).

• --node-status-update-frequency — Вказує, як часто kubelet публікує свій статус вузла на API-сервері.

Коли увімкнено режим авторизації Вузла та втулок доступу NodeRestriction, kubelets мають право створювати/змінювати лише свій власний ресурс Node.

Ручне адміністрування Вузлів

Ви можете створювати та змінювати обʼєкти Node за допомогою kubectl.

Коли ви хочете створювати обʼєкти Node вручну, встановіть прапорець kubelet --register-node=false.

Ви можете змінювати обʼєкти Node незалежно від налаштувань --register-node. Наприклад, ви можете встановлювати мітки на наявному Вузлі або позначати його як незапланований.

Ви можете використовувати мітки на Вузлах разом із селекторами вузлів на Podʼах для управління плануванням. Наприклад, ви можете обмежити Pod лише можливістю запуску на підмножині доступних вузлів.

Позначення вузла як незапланованого перешкоджає планувальнику розміщувати нові Podʼи на цьому Вузлі, але не впливає на наявні Podʼи на Вузлі. Це корисно як підготовчий крок перед перезавантаженням вузла чи іншим обслуговуванням.

Щоб позначити Вузол як незапланований, виконайте:

kubectl cordon $NODENAME

Див. Безпечне очищення вузла для деталей.

Статус Вузла

Статус Вузла містить наступну інформацію:

• Адреси
• Умови
• Місткість та Розподіленість
• Інформація

Ви можете використовувати kubectl, щоб переглядати статус Вузла та інші деталі:

kubectl describe node <вставте-назву-вузла-тут>

Див. Статус Вузла для отримання додаткової інформації.

Сигнали Вузлів

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

Для вузлів існують дві форми сигналів:

• Оновлення в .status Вузла.
• Обʼєкти Оренди (Lease) у просторі імен kube-node-lease. Кожен Вузол має асоційований обʼєкт Lease.

Контролер вузлів

Контролер вузлів — це компонент панелі управління Kubernetes, який керує різними аспектами роботи вузлів.

У контролера вузла є кілька ролей у житті вузла. По-перше, він призначає блок CIDR вузлу при його реєстрації (якщо призначення CIDR увімкнено).

По-друге, він підтримує актуальність внутрішнього списку вузлів контролера зі списком доступних машин хмарного провайдера. У разі, якщо вузол несправний, контролер вузла перевіряє у хмарному провайдері, чи ще доступний віртуальний компʼютер (VM) для цього вузла. Якщо ні, контролер вузла видаляє вузол зі свого списку вузлів.

По-третє, контролер відповідає за моніторинг стану вузлів і:

• У випадку, якщо вузол стає недоступним, оновлення умови Ready у полі .status Вузла. У цьому випадку контролер вузла встановлює умову Ready в Unknown.
• Якщо вузол залишається недоступним: запускає виселення ініційоване API для всіх Podʼів на недосяжному вузлі. Типово контролер вузла чекає 5 хвилин між позначенням вузла як Unknown та Podʼанням першого запиту на виселення.

Стандартно контролер вузла перевіряє стан кожного вузла кожні 5 секунд. Цей період можна налаштувати за допомогою прапорця --node-monitor-period у компоненті kube-controller-manager.

Обмеження швидкості виселення

У більшості випадків контролер вузла обмежує швидкість виселення на --node-eviction-rate (типово 0,1) в секунду, що означає, що він не буде виводити Podʼи з більше, ніж 1 вузла кожні 10 секунд.

Поведінка виселення вузла змінюється, коли вузол в певній доступності стає несправним. Контролер вузла перевіряє, яка частина вузлів в зоні є несправною (умова Ready — Unknown або False) у той самий час:

• Якщо частка несправних вузлів становить принаймні --unhealthy-zone-threshold (типово 0,55), тоді швидкість виселення зменшується.
• Якщо кластер малий (тобто має менше або дорівнює --large-cluster-size-threshold вузлів — типово 50), тоді виселення припиняється.
• У іншому випадку швидкість виселення зменшується до --secondary-node-eviction-rate (типово 0,01) в секунду.

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

Однією з ключових причин розподілу вузлів за зонами доступності є можливість переміщення навантаження в справні зони, коли одна ціла зона виходить з ладу. Таким чином, якщо всі вузли в зоні несправні, контролер вузла виводить навантаження зі звичайною швидкістю --node-eviction-rate. Крайній випадок — коли всі зони повністю несправні (жоден вузол в кластері не є справним). У такому випадку контролер вузла припускає, що існує якась проблема зі зʼєднанням між панеллю управління та вузлами, і не виконує жодних виселень. (Якщо стався збій і деякі вузли відновились, контролер вузла виводить Podʼи з решти вузлів, які є несправними або недосяжними).

Контролер вузла також відповідає за виселення Podʼів, що працюють на вузлах із позначками NoExecute, якщо ці Podʼи дозволяють таке. Контролер вузла також додає taint, відповідні проблемам вузла, таким як недосяжність вузла або неготовність вузла. Це означає, що планувальник не розміщуватиме Podʼи на несправних вузлах.

Відстеження місткості ресурсів

Обʼєкти Node відстежують інформацію про ресурсну місткість вузла: наприклад, кількість доступної памʼяті та кількість процесорів. Вузли, які реєструються самостійно, повідомляють про свою місткість під час реєстрації. Якщо ви додаєте вузол вручну, то вам потрібно встановити інформацію про місткість вузла при його додаванні.

Планувальник Kubernetes scheduler забезпечує, що на вузлі є достатньо ресурсів для всіх Podʼів. Планувальник перевіряє, що сума запитів контейнерів на вузлі не перевищує місткості вузла. Ця сума запитів включає всі контейнери, керовані kubelet, але не включає жодні контейнери, запущені безпосередньо середовищем виконання контейнерів, а також виключає будь-які процеси, які працюють поза контролем kubelet.

Топологія вузла

Якщо ви увімкнули feature gate ресурсу TopologyManager, то kubelet може використовувати підказки топології при прийнятті рішень щодо призначення ресурсів. Див. Керування політиками топології на вузлі для отримання додаткової інформації.

Керування swapʼом

Щоб увімкнути swap на вузлі, feature gate NodeSwap повинен бути активований у kubelet (типово так), і прапорець командного рядка --fail-swap-on або параметр конфігурації failSwapOn повинен бути встановлений в значення false. Для того, щоб дозволити Podʼам використовувати swap, swapBehavior не повинен мати значення NoSwap (яке є стандартним) у конфігурації kubelet.

Користувач також може налаштувати memorySwap.swapBehavior, щоб вказати, як вузол буде використовувати swap. Наприклад,

memorySwap:
  swapBehavior: LimitedSwap

• NoSwap (стандартно): Робочі навантаження Kubernetes не використовуватимуть swap.
• LimitedSwap: Використання робочими навантаженнями Kubernetes swap обмежено. Тільки Podʼи Burstable QoS мають право використовувати swap.

Якщо конфігурація для memorySwap не вказана, і feature gate увімкнено, типово kubelet застосовує ту ж саму поведінку, що й налаштування NoSwap.

З LimitedSwap, Podʼам, які не відносяться до класифікації Burstable QoS (тобто Podʼи QoS BestEffort/Guaranteed), заборонено використовувати swap. Для забезпечення гарантій безпеки і справності вузла цим Podʼам заборонено використовувати swap при включеному LimitedSwap.

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

• nodeTotalMemory: Загальна кількість фізичної памʼяті, доступної на вузлі.
• totalPodsSwapAvailable: Загальний обсяг swap на вузлі, доступний для використання Podʼами (деякий swap може бути зарезервовано для системного використання).
• containerMemoryRequest: Запит на памʼять для контейнера.

Ліміт swap налаштовується так: (containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable.

Важливо враховувати, що для контейнерів у Podʼах Burstable QoS можна відмовитися від використання swap, вказавши запити на памʼять, рівні лімітам памʼяті. Контейнери, налаштовані таким чином, не матимуть доступу до swap.

Swap підтримується тільки з cgroup v2, cgroup v1 не підтримується.

Для отримання додаткової інформації, а також для допомоги у тестуванні та надання зворотного звʼязку, будь ласка, перегляньте блог-пост Kubernetes 1.28: NodeSwap виходить у Beta1, KEP-2400 та його проєкт концепції.

Що далі

Дізнайтеся більше про наступне:

• Компоненти, з яких складається вузол.
• Визначення API для вузла.
• Node у документі з дизайну архітектури.
• Відповідне/невідповідне вимкнення вузлів.
• Автомаштабування кластера для керування кількістю та розміром возлів у вашому кластері.
• Заплямованість та Толерантність.
• Менеджери ресурсів вузла.
• Управління ресурсами для вузлів з операційною системою Windows.