Під час створення кластера Kubernetes можуть виникати питання: скільки налаштувати робочих вузлів та якого типу? Що краще для кластера on-premise: купити кілька потужних серверів чи задіяти десяток старих машин у вашому дата-центрі? А в хмарі краще взяти вісім одноядерних чи дві чотириядерні інстанси?
Відповіді на ці запитання – у статті у перекладі команди .
Місткість кластера
Загалом кластер Kubernetes можна розглядати як великий «супервузол». Його загальна обчислювальна потужність є сумою потужностей всіх складових вузлів.
Існує кілька способів досягти бажаної цільової ємності кластера. Наприклад, нам потрібен кластер із загальною ємністю 8 процесорних ядер та 32 ГБ оперативної пам'яті, тому що набір додатків потребує такої кількості ресурсів. Тоді можна встановити два вузли по 16 ГБ пам'яті або чотири вузли по 8 ГБ пам'яті, два чотириядерні процесори або чотири двоядерні.
Ось тільки два можливі способи створення кластера:
Обидві опції дають кластер з однаковою ємністю, але в конфігурації знизу встановлено чотири менші вузли, а в конфігурації зверху - два великі.
Який варіант кращий?
Щоб відповісти на це питання, розглянемо переваги обох варіантів. Ми звели їх у таблицю.
Декілька великих вузлів
Багато маленьких вузлів
Простіше управління кластером (якщо він on-premise)
Плавне автомасштабування
Дешевше (якщо on-premise)
Ціна мало відрізняється (у хмарі)
Можна запускати ресурсомісткі програми
Повноцінна реплікація
Ресурси використовуються ефективніше (менше зверху на системні демони
Вище відмовостійкість кластера
Зверніть увагу, що ми говоримо лише про робочі вузли. Вибір кількості та розміру головних вузлів – зовсім інша тема.
Отже, докладніше обговоримо кожен пункт з таблиці.
Перший варіант: кілька великих вузлів
Найбільш екстремальний варіант – один робочий вузол на всю ємність кластера. У прикладі вище це був один робочий вузол з 16 ядрами ЦП і 16 ГБ оперативної пам'яті.
Плюси
Плюс № 1. Простіше управління
Простіше керувати кількома машинами, ніж цілим парком. Швидше накочувати оновлення та виправлення, простіше синхронізувати. Кількість збоїв в абсолютних цифрах також менша.
Зверніть увагу, що все вищесказане відноситься до свого заліза, своїх серверів, а не до хмарних інстансів.
У хмарі інша ситуація. Там керуванням займається постачальник хмарних послуг. Таким чином, управління десятьма вузлами у хмарі особливо не відрізняється від керування одним вузлом.
Маршрутизація трафіку та розподіл навантаження між подами у хмарі : трафік, що приходить з інтернету, направляється на основний балансувальник навантаження, той направляє трафік на порт одного з вузлів (сервіс NodePort виставляє порт в діапазоні 30000-32767 в кожному вузлі кластера). Правила, встановлені kube-proxy, перенаправляють трафік із вузла на під. Ось як це виглядає для десяти подів на двох вузлах:
Плюс №2. Менше витрат на вузол
Потужна машина дорожча, але зростання ціни не обов'язково лінійне. Іншими словами, один десятиядерний сервер з 10 ГБ пам'яті зазвичай дешевше, ніж десять одноядерних із тією ж кількістю пам'яті.
Але зверніть увагу, що це правило зазвичай не працює у хмарних сервісах. У поточних схемах ціноутворення у всіх основних постачальників хмарних послуг ціни зростають лінійно зі збільшенням ємності.
Таким чином, у хмарі зазвичай не можна заощадити на потужніших серверах.
Плюс № 3. Можна запускати ресурсоємні програми
Деякі програми необхідні потужні сервери в кластері. Наприклад, якщо система машинного навчання вимагає 8 ГБ пам'яті, ви не зможете запустити її на вузлах по 1 ГБ, а лише за наявності хоча б одного великого робочого вузла.
Мінуси
Мінус №1. Багато pod'ів на вузол
Якщо те саме завдання виконується на меншій кількості вузлів, то на кожному з них, природно, буде більше pod'ів.
Це може стати проблемою.
Причина в тому, що кожен модуль вносить деякі накладні витрати на середовище виконання контейнера (наприклад, Docker), а також kubelet та cAdvisor.
Наприклад, kubelet регулярно зондує на живучість усі контейнери на вузлі – чим більше контейнерів, тим більше роботи у kubelet.
CAdvisor збирає статистику використання ресурсів всіх контейнерів на вузлі, а kubelet регулярно запитує цю інформацію та надає її через API. Знову ж таки, чим більше контейнерів, тим більше роботи і для Cadvisor, і для Kubelet.
Якщо кількість модулів зросте, це може сповільнити систему та навіть підірвати її надійність.
У репозиторії Kubernetes деякі , Що вузли скачуть між статусами Ready/NotReady, оскільки регулярні перевірки kubelet всіх контейнерів на вузлі займають занадто багато часу.
З цієї причини Kubernetes . Залежно від продуктивності вузла ви можете запускати більше подів на вузол, але важко передбачити, чи виникнуть проблеми, чи все буде працювати добре. Варто наперед протестувати роботу.
Мінус №2. Обмеження на реплікацію
Занадто мала кількість вузлів обмежує ефективний рівень реплікації додатків. Наприклад, якщо у вас програма високої доступності з п'яти реплік, але тільки два вузли, то ефективний рівень реплікації програми зменшується до двох.
П'ять реплік можна розподілити лише на два вузли, і якщо один з них не працює, він одразу виводить із ладу кілька реплік.
Якщо у вас п'ять або більше вузлів, кожна репліка буде виконуватися на окремому вузлі, а збій одного вузла видалить не більше однієї репліки.
Таким чином, вимоги високої доступності можуть вимагати наявності певної мінімальної кількості вузлів у кластері.
Мінус № 3. Гірші наслідки збою
При невеликій кількості вузлів кожен збій несе більш серйозні наслідки. Наприклад, якщо у вас всього два вузли, і один з них виходить з ладу, зникає одразу половина ваших модулів.
Звичайно, Kubernetes перенесе робоче навантаження з вузла, що відмовив, на інші. Але якщо їх мало, то вільної ємності може вистачити. В результаті частина ваших програм будуть недоступні, поки ви не піднімете вузол, що відмовив.
Таким чином, чим більше вузлів – тим менший вплив апаратних збоїв.
Мінус № 4. Більше кроків автомасштабування
У Kubernetes працює система автомасштабування кластера для хмарної інфраструктури, що дозволяє автоматично додавати або видаляти вузли в залежності від поточних потреб. З великими вузлами автомасштабування стає різкішим і незграбнішим. Наприклад, на двох вузлах додавання додаткового вузла збільшить ємність кластера відразу на 50%. І вам доведеться заплатити за ці ресурси, навіть якщо вони вам не потрібні.
Таким чином, якщо ви плануєте використовувати автоматичне масштабування кластера, то чим менше вузли – тим більш гнучке та економічне масштабування ви отримаєте.
Тепер розглянемо переваги та недоліки великої кількості маленьких вузлів.
Другий варіант: безліч маленьких вузлів
Переваги цього підходу, по суті, випливають із недоліків протилежного варіанта з кількома великими вузлами.
Плюси
Плюс №1. Менше наслідки збою
Чим більше вузлів, тим менше pod'ів на кожному вузлі. Наприклад, якщо у вас сто модулів на десять вузлів, то на кожному вузлі буде в середньому десять модулів.
Таким чином, якщо один із вузлів виходить з ладу, ви втрачаєте всього 10% робочого навантаження. Є ймовірність, що торкнеться лише невеликої кількості реплік, а програми в цілому залишаться в робочому стані.
Крім того, на вузлах, що залишилися, швидше за все, вистачить вільних ресурсів для робочого навантаження вузла, що відмовив, так що Kubernetes може вільно перепланувати pod'и, і ваші програми відносно швидко повернуться у функціональний стан.
Плюс №2. Хороша реплікація
Якщо вузлів достатньо, планувальник Kubernetes може призначити всім реплікам різні вузли. Таким чином, у разі збою вузла торкнеться всього одна репліка, а додаток залишиться доступним.
Мінуси
Мінус №1. Важке управління
Великою кількістю вузлів важче керувати. Наприклад, кожен вузол Kubernetes повинен взаємодіяти з рештою, тобто число зв'язків зростає квадратично, і всі ці зв'язки потрібно відстежувати.
Контролер вузлів у менеджері контролерів Kubernetes регулярно обходить усі вузли в кластері для перевірки працездатності – чим більше вузлів, тим більше навантаження на контролер.
Зростає навантаження і базу даних etcd — кожен kubelet і kube-proxy викликає для etcd (через API), якому etcd має транслювати оновлення об'єкта.
Загалом кожен робочий вузол накладає додаткове навантаження на системні компоненти головних вузлів.
Офіційно Kubernetes підтримує кластери з . Однак на практиці вже 500 вузлів .
Для управління великою кількістю робочих вузлів слід вибирати найбільш продуктивні основні вузли. Наприклад, kube-up правильний розмір VM для головного вузла залежно кількості робочих вузлів. Тобто чим більше робочих вузлів, тим більш продуктивними мають бути головні вузли.
Для вирішення цих специфічних проблем є спеціальні розробки, такі як . Ця система дозволяє обійти обмеження та будувати кластери з величезною кількістю робочих вузлів.
Мінус № 2. Більше накладних витрат
На кожному робочому вузлі Kubernetes запускає набір системних демонів - до них відносяться середовище виконання контейнера (наприклад, Docker), kube-proxy та kubelet, включаючи cAdvisor. Всі разом вони споживають певну фіксовану кількість ресурсів.
Якщо у вас багато невеликих вузлів, то частка цих накладних витрат на кожному вузлі більша. Наприклад, уявіть, що всі системні демони одного вузла разом використовують 0,1 ядра ЦП та 0,1 ГБ пам'яті. Якщо у вас один десятиядерний вузол з 10 ГБ пам'яті, демони споживають 1% ємності кластера. З іншого боку, на десяти одноядерних вузлах по 1 ГБ пам'яті демони заберуть 10% місткості кластера.
Таким чином, що менше вузлів, то ефективніше використовується інфраструктура.
Мінус №3. Неефективне використання ресурсів
На маленьких вузлах може скластися ситуація, що фрагменти ресурсів, що залишилися, занадто малі, щоб призначити їм якесь робоче навантаження, тому вони залишаються невикористовуваними.
Наприклад, кожен pod вимагає 0,75 ГБ пам'яті. Якщо у вас десять вузлів, і на кожному по 1 ГБ пам'яті, можна запустити десять pod'ів - у результаті на кожному вузлі залишиться 0,25 ГБ пам'яті, що не використовується.
Це означає, що 25% пам'яті всього кластера витрачається марно.
На великому вузлі з 10 ГБ пам'яті ви можете запустити 13 таких модулів - і залишиться лише один фрагмент 0,25 ГБ, який не використовується.
І тут марно витрачається лише 2,5% пам'яті.
Таким чином, на великих вузлах оптимальніше витрачаються ресурси.
Декілька великих вузлів чи багато маленьких?
Отже, що краще: кілька великих вузлів у кластері чи багато маленьких? Як завжди, однозначної відповіді немає. Багато залежить від типу програми.
Наприклад, якщо програма потребує 10 ГБ пам'яті, очевидний вибір на користь великих вузлів. А якщо програма вимагає десятикратної реплікації для високої доступності, навряд чи варто ризикувати, розміщуючи репліки всього на двох вузлах — у кластері має бути щонайменше десять вузлів.
У проміжних ситуаціях робіть вибір, виходячи з переваг та недоліків кожного варіанта. Можливо, якісь аргументи є більш актуальними для вашої ситуації, ніж інші.
І не обов'язково робити всі вузли однакового розміру. Ніщо не заважає експериментувати спочатку з вузлами одного розміру, потім додати до них вузли іншого розміру, поєднуючи їх у кластері. Робочі вузли кластера Kubernetes можуть бути гетерогенними. Тож можна спробувати поєднати переваги обох підходів.
Єдиного рецепту не існує, а кожна ситуація має свої нюанси, і тільки продакшн покаже правду.
Переклад підготовлений командою хмарної платформи .
Ще про Kubernetes: .
Джерело: habr.com