Kubernetes Вузол: Великі вузли проти Малих вузлів

Ця стаття вперше була опублікована на блозі PerfectScale автором Taniaduggal

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

У цій статті ми обговоримо переваги та недоліки використання великих і малих вузлів у ваших кластерах.

Давайте заглибимося!

Що таке вузол в Kubernetes?

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

Компоненти вузлів Kubernetes

В Kubernetes є різні компоненти вузлів. Давайте розглянемо:

1. Kubelet: Цей агент забезпечує, щоб контейнери працювали в поді. Він отримує специфікації подів від контрольного плану та керує їх життєвим циклом на вузлі.

2. Container Runtime: Відповідає за виконання контейнерів. Kubernetes підтримує різні контейнерні рантайми, такі як containerd і CRI-O.

3. Kube-proxy: Мережевий проксі, який підтримує мережеві правила на вузлах. Він сприяє комунікації між подами та сервісами, керуючи маршрутизацією мережевого трафіку.

Властивості вузлів в Kubernetes

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

1. Мітка вузла

Мітки в Kubernetes — це пари ключ-значення, які використовуються для організації та ідентифікації вузлів. Вони допомагають планувати поди на конкретні вузли на основі їх міток.

Щоб додати мітку до вузлів за допомогою команди kubectl label:

kubectl label node node05 env=dev

Ви можете переглянути мітки вузлів:

kubectl get nodes --show-labels

Мітки також можна додавати безпосередньо до конфігураційного файлу вузла:

apiVersion: v1   
kind: Node   
metadata:   
 name: node01   
 labels:   
 env: test   
 region: us-east-1

2. Анотації вузла

Анотації — це ще один спосіб додавання метаданих до вузлів. На відміну від міток, анотації зберігають неідентифікаційну інформацію, яку Kubernetes не використовує для планування.

Анотації можуть бути визначені наступним чином:

metadata:   
 name: node01   
 annotations:   
 maintenance: "planned on 2025-01-10"   
 owner: "ops-team"

3. Розподіл та потужність вузла

Кожен вузол в Kubernetes має певну кількість CPU, пам'яті та сховища. Потужність представляє загальні ресурси, доступні на вузлі, в той час як allocatable ресурси — це ті, які Kubernetes може використовувати для робочих навантажень після резервування деяких для системних процесів.

Ви можете переглянути потужність вузла та allocatable ресурси:

kubectl describe node node01

Цю інформацію також можна побачити у маніфесті вузла:

metadata:   
 name: node01   
status:   
 capacity:   
 cpu: "8"   
 memory: "32Gi"   
 pods: "110"   
 allocatable:   
 cpu: "7"   
 memory: "30Gi"   
 pods: "100"

4. Умови вузла

Умови вузла показують статус різних компонентів вузла. Умови такі:

a. Ready: Показує, чи готовий вузол до хостингу робочих навантажень.

b. MemoryPressure: Вказує, чи є на вузлі дефіцит пам'яті.

c. DiskPressure: Вказує, чи заповнений або майже заповнений диск на вузлі.

d. PIDPressure: Показує, чи є надмірна кількість процесів, що виконуються на вузлі.

status:   
 conditions:   
 - type: Ready   
 status: "True"   
 lastHeartbeatTime: "2025-01-01T10:00:00Z"   
 - type: MemoryPressure   
 status: "False"   
 lastHeartbeatTime: "2025-01-01T10:00:00Z"

## Інформація про вузол

Інформація про вузол включає деталі про апаратне та програмне середовище вузла, такі як апаратна архітектура (наприклад, x86_64), версія контейнерного рантайму, версія операційної системи, що працює на вузлі, версії компонентів Kubernetes.

status:
nodeInfo:
architecture: "x86_64"
containerRuntimeVersion: "containerd://1.6.20"
operatingSystem: "linux"
osImage: "Ubuntu 22.04 LTS"
kubeletVersion: "v1.27.4"
kubeProxyVersion: "v1.27.4"
```

Статус вузла

Статус вузла надає інформацію про мережу та IP-адреси, присвоєні вузлу.

status:   
 addresses:   
 - type: InternalIP   
 address: "192.168.1.10"   
 - type: ExternalIP   
 address: "203.0.113.20"   
 - type: Hostname   
 address: "node01"

Що ми маємо на увазі під великими та маленькими вузлами?

Великі вузли: Це великі інстанції з високою потужністю, з великою кількістю CPU, пам'яті та сховища. Наприклад, в хмарі AWS це можуть бути m5.8xlarge (32 vCPU, 128 GiB пам'яті, $1.536 на годину в режимі On-Demand) або c5.18xlarge (72 vCPU, 144 GiB пам'яті, $3.06 на годину в режимі On-Demand), це можуть бути потужні фізичні сервери. Великі вузли можуть обробляти багато подів, тому ви можете розмістити більше робочих навантажень на меншій кількості вузлів.

Малі вузли: Це менші інстанції з обмеженими ресурсами, такі як AWS t3.small (2 vCPU, 2 GiB пам'яті, $0.0208 на годину в режимі On-Demand) або m5.large (2 vCPU, 8GiB пам'яті, $0.096 на годину в режимі On-Demand). Малі вузли дешевші, і їх використання означає, що у вас буде набагато більше вузлів у кластері.

Переваги великих вузлів

1. Ефективність витрат:

Великі вузли можуть забезпечити кращу ефективність витрат на одиницю ресурсу. Коли ви запускаєте високопродуктивні робочі навантаження або вимагаєте великих та постійних алокацій CPU та пам'яті, великі вузли можуть бути більш економічними, ніж запуск еквівалентної потужності за допомогою багатьох малих вузлів. Менша кількість вузлів також означає менше мережевих стрибків, що може знизити латентність та підвищити продуктивність в залежності від типу робочих навантажень.

1. Спрощене управління

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

1. Менше навантаження на API сервер

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

1. Кращий розподіл ресурсів

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

Недоліки великих вузлів

1. Вищий ризик відмов

Коли великий вузол виходить з ладу, це може вплинути на значно більшу кількість подів, ніж відмова маленького вузла. Це часто називають "радіусом вибуху" — чим більший вузол, тим більший вплив, якщо щось йде не так. Що стосується планування, то також може бути важче перенести ці поди на інші вузли, якщо на залишкових вузлах немає достатньо потужності для обробки навантаження. Це може призвести до простоїв додатків, поки не буде відновлений зламаний вузол.

1. Збільшений час простою під час оновлень

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

1. Витрати ресурсів для малих робочих навантажень

Якщо ви запускаєте малі робочі навантаження на великих вузлах, ви можете отримати не використану потужність — частини CPU або пам'яті, які не використовуються, оскільки вони не можуть бути заповнені дрібнішими завданнями.
Kubernetes не завжди ефективно "упаковує" робочі навантаження на великих вузлах, тому деякі ресурси можуть залишатися не використовуваними, якщо робочі навантаження не підходять за розміром до вузла.

Переваги малих вузлів

1. Висока стійкість

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

1. Гнучкість

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

1. Ефективний розподіл ресурсів для різних робочих навантажень

У кластерах з різними робочими навантаженнями (наприклад, додатками, що інтенсивно використовують CPU, і додатками з великими вимогами до пам'яті), малі вузли дозволяють ефективно "упаковувати" робочі навантаження. Менші одиниці ресурсів полегшують для планувальника Kubernetes відповідність робочих навантажень до вузлів без значних залишкових ресурсів. У мульти-орендарних кластерах, де різні команди чи додатки потребують ізольованих ресурсів, малі вузли допомагають уникнути конфліктів і конкуренції за ресурси.

Недоліки малих вузлів

1. Збільшене навантаження на управління

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

1. Вищі мережеві витрати

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

1. Неекономне використання ресурсів

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

Вибір правильного розміру вузла

Ваш вибір між великими вузлами і малими вузлами залежатиме від характеру ваших робочих навантажень та ваших пріоритетів. Ось кілька моментів, які варто врахувати:

1. Використовуйте великі вузли, коли:

a. У вас є постійні високі навантаження, які потребують стабільних і великих ресурсів.

b. Оптимізація витрат на великій шкалі важливіша за максимальну стійкість.

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

2. Використовуйте малі вузли, коли:

a. Ви хочете запускати різноманітні, динамічні робочі навантаження з частими вимогами до масштабування.

b. Висока доступність важлива, і ви хочете мінімізувати радіус вибуху при відмові вузла.

c. Гнучкість, стійкість до відмов та поступове масштабування — це основні пріоритети для ваших робочих навантажень.

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

Управління вузлами з PerfectScale

PerfectScale із плагіном InfraFit спрощує визначення розміру вузлів, надаючи практичні поради щодо використання ресурсів. Ось як це допомагає:

1. Аналіз використання ресурсів: Infrafit визначає недовикористовувані або перевищені вузли, що дозволяє ефективно розподіляти робочі навантаження.

2.

Оптимізація вузлів

1. Оптимізація вузлів: PerfectScale пропонує коригування типів і розмірів вузлів, забезпечуючи найкращу продуктивність при найменших витратах.

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

Ось покрокова інструкція з використання InfraFit для керування вузлами:

1. Отримайте деталі групи вузлів

InfraFit

• Натисніть на розділ InfraFit в PerfectScale.
• Виберіть конкретну групу вузлів, щоб відкрити її детальний перегляд.

2. Аналіз використання ресурсів

InfraFit

• Використовуйте фільтр Utilization для перегляду використання CPU та пам'яті (виділені, запитувані та використані) на бажаному відсотилі.
• Ідентифікуйте недовикористовувані або перевищені вузли на основі Idle Cost та метрик використання.

3. Перегляньте рекомендації з оптимізації

InfraFit

• У таблиці даних групи вузлів перевірте стовпці Avg Cost/h, Total Cost та Idle Cost для отримання корисних порад.
• PerfectScale надає рекомендації щодо зміни розміру або заміни вузлів, включаючи варіанти для економії витрат.

4. Моніторинг тенденцій використання

InfraFit

• Використовуйте графіки Cost per Node Type та Utilization charts для відстеження тенденцій використання ресурсів протягом часу.
• Увімкніть безперервний моніторинг, щоб отримувати сповіщення в реальному часі та оновлені рекомендації.

5. Експорт даних

• Легко експортуйте дані у форматі .csv для подальшого аналізу та співпраці в команді.

Інтегруючи PerfectScale, команди можуть досягти до 30–50% додаткової економії витрат завдяки більш розумному, орієнтованому на дані прийняттю рішень щодо розміру вузлів. Зареєструйтесь або Запишіться на демонстрацію з PerfectScale сьогодні!

Перекладено з: Kubernetes Node: Huge Nodes vs. Small Nodes