Прим. перев.: цей матеріал від освітнього проекту - Відповідь на популярне питання при проектуванні інфраструктури на базі Kubernetes. Сподіваємося, що досить розгорнуті описи плюсів та мінусів кожного з варіантів допоможуть зробити оптимальний вибір і для вашого проекту.
TL, д-р: один і той же набір робочих навантажень можна запустити на кількох великих кластерах (на кожен кластер припадатиме велика кількість workload'ів) або на безлічі дрібних (з малим числом навантажень у кожному кластері).
Нижче наведено таблицю, в якій оцінюються плюси та мінуси кожного підходу:
При використанні Kubernetes як платформа для експлуатації програм часто виникають кілька фундаментальних питань про тонкощі налаштування кластерів:
- Яка кількість кластерів використовувати?
- Наскільки великими їх робити?
- Що повинен містити кожен кластер?
У цій статті я спробую відповісти на всі ці питання, проаналізувавши плюси та мінуси кожного підходу.
Постановка питання
Як творець ПЗ, ви швидше за все паралельно розробляєте та експлуатуєте безліч додатків.
Крім того, безліч екземплярів цих додатків, напевно, запускаються в різних оточеннях — наприклад, це можуть бути DEV, тест и prod.
В результаті виходить ціла матриця з додатків та оточень:
Програми та оточення
У наведеному вище прикладі представлені 3 додатки та 3 оточення, що в результаті дає 9 можливих варіантів.
Кожен екземпляр програми є самодостатньою deployment-одиницею, з якою можна працювати незалежно від інших.
Зверніть увагу, що екземпляр програми може складатися з безлічі компонентів, таких як фронтенд, бекенд, база даних і т.д. У разі мікросервісної програми екземпляр буде включати всі мікросервіси.
У результаті у користувачів Kubernetes виникають кілька питань:
- Чи варто розміщувати всі екземпляри програми в одному кластері?
- Чи варто заводити окремий кластер під кожен екземпляр програми?
- Чи, можливо, слід скористатися комбінацією перерахованих вище підходів?
Всі ці варіанти є цілком життєздатними, оскільки Kubernetes — це гнучка система, яка не обмежує користувача в можливостях.
Ось деякі з можливих шляхів:
- один великий загальний кластер;
- безліч невеликих вузькоспеціалізованих кластерів;
- один кластер на кожну програму;
- один кластер на кожне оточення.
Як показано нижче, перші два підходи знаходяться на протилежних кінцях шкали варіантів:
Від кількох великих кластерів (ліворуч) до безлічі маленьких (праворуч)
У загальному випадку вважається, що один кластер «більше» іншого, якщо у нього більша сума вузлів і pod'ів. Наприклад, кластер з 10-ма вузлами та 100 pod'ами більше кластера з 1-м вузлом та 10-ма pod'ами.
Що ж, почнемо!
1. Один великий загальний кластер
Перший варіант - розмістити всі робочі навантаження в одному кластері:
Один великий кластер
В рамках цього підходу кластер використовується як універсальна інфраструктурна платформа - все необхідне ви просто розвертаєте в існуючому кластері Kubernetes.
Kubernetes дозволяють логічно відокремити частини кластера один від одного, так що для кожного екземпляра програми можна використовувати свій простір імен.
Давайте розглянемо плюси та мінуси цього підходу.
+ Ефективне використання ресурсів
У випадку єдиного кластера буде потрібна лише одна копія всіх ресурсів, необхідних для запуску кластера Kubernetes та управління ним.
Наприклад, це справедливо для майстер-вузлів. Зазвичай на кожен кластер Kubernetes припадає по 3 майстер-вузли, тому для одного кластера їх кількість таким і залишиться (для порівняння, 10 кластерам знадобляться 30 майстер-вузлів).
Вищевказана тонкість відноситься і до інших сервісів, що функціонують у масштабах всього кластера, таких як балансувальники навантаження, контролери Ingress, системи аутентифікації, логування та моніторингу.
У єдиному кластері всі ці послуги можна використовувати відразу всіх робочих навантажень (не потрібно створювати їх копії, як у кількох кластерів).
+ Дешевизна
Як наслідок вищевикладеного, менше кластерів зазвичай обходиться дешевше, оскільки відсутні витрати на надлишкові ресурси.
Це особливо справедливо для майстер-вузлів, які можуть коштувати значні гроші незалежно від способу розміщення (on-premises або у хмарі).
Деякі керовані (managed) сервіси Kubernetes, такі як або , надають керуючий шар безкоштовно. У разі питання витрат коштує менш гостро.
Також є managed-сервіси, що стягують фіксовану плату за роботу кожного кластера Kubernetes (наприклад, ).
+ Ефективне адміністрування
Керувати одним кластером простіше, ніж кількома.
Адміністрація може включати такі завдання:
- оновлення версії Kubernetes;
- налаштування конвеєра CI/CD;
- встановлення плагіна CNI;
- налаштування системи автентифікації користувачів;
- встановлення контролера допуску;
і багато інших…
У разі одного кластера займатися всім цим доведеться лише один раз.
Для безлічі кластерів операції доведеться повторювати багаторазово, що, ймовірно, вимагатиме деякої автоматизації процесів та інструментів, щоб забезпечити систематичність та однаковість процесу.
А тепер кілька слів про мінуси.
− Єдина точка відмови
У разі відмови єдиного кластери перестануть працювати відразу всі робочі навантаження!
Існує маса варіантів, коли щось може піти не так:
- оновлення Kubernetes призводить до несподіваних побічних ефектів;
- загальнокластерний компонент (наприклад, плагін CNI) починає працювати не так, як очікувалося;
- один із компонентів кластера налаштований неправильно;
- збій у нижчій інфраструктурі.
Один такий інцидент може завдати серйозної шкоди всім робочим навантаженням, розміщеним у загальному кластері.
− Відсутність жорсткої ізоляції
Робота в загальному кластері означає, що програми спільно використовують апаратне забезпечення, мережеві можливості та операційну систему на вузлах кластера.
У певному сенсі два контейнери з двома різними додатками, що працюють на тому самому вузлі, подібні до двох процесів, що працюють на одній і тій же машині під керуванням одного і того ж ядра ОС.
Контейнери Linux забезпечують деяку форму ізоляції, але вона далеко не така сильна, як та, яку забезпечують, скажімо, віртуальні машини. По суті, процес у контейнері – це той самий процес, запущений в операційній системі хоста.
Це може стати проблемою з погляду безпеки: подібна організація теоретично дозволяє незв'язаним додаткам взаємодіяти один з одним (навмисно чи випадково).
Крім того, всі робочі навантаження у кластері Kubernetes спільно використовують деякі загальнокластерні сервіси, такі як — це дозволяє програмам знаходити Service'и інших програм у кластері.
Всі перелічені вище пункти можуть мати різне значення в залежності від вимог, що пред'являються до безпеки додатків.
Kubernetes надає різні інструменти для запобігання проблемам у системі безпеки, такі як и . Однак для їх правильного налаштування потрібен певний досвід, крім того, вони не в змозі закрити абсолютно всі діри в безпеці.
Важливо завжди пам'ятати, що Kubernetes спочатку розроблений для спільного використання, а не для ізоляції та безпеки.
− Відсутність жорсткої multi-tenancy
Враховуючи велику кількість загальних ресурсів у кластері Kubernetes, існує безліч способів, якими різні програми можуть «наступати один одному на п'яти».
Наприклад, програма може монополізувати певний загальний ресурс (на зразок процесора або пам'яті) і позбавити інші програми, що працюють на тому ж вузлі, доступу до нього.
Kubernetes забезпечує різні механізми контролю за подібною поведінкою, такі як (див. також статтю «" - прим. перев.), и . Однак, як і в разі безпеки, їх налаштування досить нетривіальне і вони не здатні запобігти всім непередбаченим побічним ефектам.
− Велика кількість користувачів
Що стосується єдиного кластера доводиться відкривати доступом до нього безлічі людей. І чим значніша їх кількість, тим вищий ризик того, що вони щось «зламають».
Усередині кластера можна контролювати, хто і що може робити за допомогою (див. статтю «" - прим. перев.). Втім, воно не завадить користувачам «зламати» щось у межах своєї зони відповідальності.
− Кластери не можуть рости до нескінченності
Кластер, який використовується для всіх робочих навантажень, буде, ймовірно, дуже великим (за кількістю вузлів та pod'ів).
Але тут виникає інша проблема: кластери в Kubernetes не можуть зростати нескінченно.
Існує теоретична межа розмір кластера. У Kubernetes він становить приблизно .
Однак у реальному житті проблеми можуть початися набагато раніше - наприклад, всього при .
Справа в тому, що великі кластери надають високе навантаження на керуючий шар Kubernetes. Іншими словами, щоб підтримувати кластер у робочому стані та ефективно використовувати ресурси, потрібне ретельне налаштування.
Ця проблема вивчається у відповідній статті в оригінальному блозі під назвою «».
Але давайте розглянемо протилежний підхід: багато дрібних кластерів.
2. Безліч невеликих, спеціалізованих кластерів
При цьому підході ви використовуєте окремий кластер для кожного елемента, що розгортається:
Безліч дрібних кластерів
Для цілей цієї статті під елементом, що розгортається розуміється екземпляр програми - наприклад, dev-версія окремої програми.
У цій стратегії Kubernetes використовується як спеціалізована середовище виконання для окремих екземплярів програми.
Давайте розглянемо плюси та мінуси цього підходу.
+ Обмежений «радіус вибуху»
При «поломці» кластера негативні наслідки обмежуються лише тими робочими навантаженнями, які були розгорнуті у цьому кластері. Всі інші workload'и залишаються недоторканими.
+ Ізоляція
Робочі навантаження, розміщені в індивідуальних кластерах, немає загальних ресурсів, як-от процесор, пам'ять, операційна система, мережу чи інші сервіси.
В результаті ми отримуємо жорстку ізоляцію між незв'язаними програмами, що може сприятливо позначитися на їхній безпеці.
+ Невелика кількість користувачів
Враховуючи, що в кожному кластері міститься лише обмежений набір робочих навантажень, скорочується кількість користувачів із доступом до нього.
Чим менше людей мають доступ до кластера, тим нижчим є ризик того, що щось «зламається».
Погляньмо на мінуси.
− Неефективне використання ресурсів
Як згадувалося раніше, кожному кластеру Kubernetes потрібен певний набір ресурсів, що управляють: майстер-вузли, компоненти контрольного шару, рішення для моніторингу та ведення логів.
У разі великої кількості малих кластерів доводиться виділяти більшу частку ресурсів управління.
− Дорожнеча
Неефективне використання ресурсів автоматично спричиняє високі витрати.
Наприклад, зміст 30 майстер-вузлів замість трьох за тієї ж обчислювальної потужності обов'язково позначиться на витратах.
− Складності адміністрування
Адмініструвати безліч кластерів Kubernetes набагато складніше, ніж працювати з одним.
Наприклад, доведеться налаштовувати автентифікацію та авторизацію для кожного кластера. Оновлення версії Kubernetes також доведеться проводити кілька разів.
Швидше за все, доведеться застосувати автоматизацію, щоб підвищити ефективність усіх цих завдань.
Тепер розглянемо менш екстремальні сценарії.
3. Один кластер на кожну програму
В рамках цього підходу ви створюєте окремий кластер для всіх екземплярів конкретної програми:
Кластер на додаток
Такий шлях можна розглядати як узагальнення принципу.окремий кластер на команду», оскільки зазвичай команда інженерів займається розробкою одного чи кількох додатків.
Давайте розглянемо плюси та мінуси цього підходу.
+ Кластер можна підлаштувати під програму
Якщо програма має особливі потреби, їх можна реалізувати в кластері, не торкаючись інших кластерів.
Такі потреби можуть включати worker'и з GPU, певні плагіни CNI, service mesh або якийсь інший сервіс.
Кожен кластер можна підлаштувати під додаток, що працює в ньому, щоб він містив тільки те, що необхідно.
− Різні середовища в одному кластері
Недоліком цього підходу є те, що екземпляри додатків із різних оточень співіснують в одному кластері.
Наприклад, prod-версія програми працює в тому ж кластері, що і dev-версія. Це також означає, що розробники ведуть свою діяльність у тому кластері, в якому експлуатується production-версія додатка.
Якщо через дії розробників або глюків dev-версії у кластері відбудеться збій, то потенційно може постраждати і prod-версія – величезний недолік такого підходу.
Ну і нарешті останній сценарій у нашому списку.
4. Один кластер на кожне оточення
Цей сценарій передбачає виділення окремого кластера на кожне оточення:
Один кластер на оточення
Наприклад, у вас можуть бути кластери DEV, тест и prod, в яких ви запускатимете всі екземпляри програми, призначені для певного середовища.
Ось плюси та мінуси такого підходу.
+ Ізоляція prod-середовища
У рамках цього підходу всі оточення виявляються ізольованими один від одного. Однак на практиці це особливо важливо для prod-середовища.
Production-версії програми тепер не залежать від того, що відбувається в інших кластерах та середовищах.
Таким чином, якщо в dev-кластері раптово виникне проблема, prod-версії додатків продовжать працювати начебто нічого не сталося.
+ Кластер можна підлаштувати під середу
Кожен кластер можна підлаштувати під його оточення. Наприклад, можна:
- встановити в dev-кластері інструменти для розробки та налагодження;
- встановити тестові фреймворки та інструменти у кластері тест;
- використовувати більш потужне обладнання та мережеві канали в кластері prod.
Це дозволяє підвищити ефективність як розробки, і експлуатації додатків.
+ Обмеження доступу до production-кластеру
Необхідність працювати з prod-кластером безпосередньо виникає нечасто, тому можна значно обмежити коло осіб, які мають до нього доступ.
Можна піти ще далі і взагалі позбавити людей доступу до цього кластера, а розгортання виконувати за допомогою автоматизованого інструменту CI/CD. Подібний підхід дозволить максимально знизити ризик людських помилок саме там, де це є найбільш актуальним.
А тепер кілька слів про мінуси.
− Відсутність ізоляції між додатками
Основний недолік підходу - відсутність апаратної та ресурсної ізоляції між додатками.
Незв'язані програми спільно використовують ресурси кластера: системне ядро, процесор, пам'ять та інші служби.
Як згадувалося, це може бути потенційно небезпечним.
− Неможливість локалізувати залежності додатків
Якщо у додатка є особливі вимоги, їх доводиться задовольняти в усіх кластерах.
Наприклад, якщо програмі необхідний GPU, то кожен кластер повинен містити принаймні один worker з GPU (навіть якщо він використовується лише цим додатком).
В результаті ми ризикуємо отримати більш високі витрати та неефективне використання ресурсів.
Висновок
За наявності певного набору додатків їх можна розмістити у кількох великих кластерах чи безлічі малих.
У статті розглянуті плюси та мінуси різних підходів, починаючи від одного глобального кластера і закінчуючи кількома невеликими та вузькоспеціалізованими:
- один великий загальний кластер;
- безліч невеликих вузькоспеціалізованих кластерів;
- один кластер на кожну програму;
- один кластер на кожне оточення.
Отже, який підхід вибрати?
Як завжди, відповідь залежить від сценарію використання: потрібно зважити плюси і мінуси різних підходів і вибрати найоптимальніший варіант.
Однак вибір не обмежується наведеними вище прикладами — можна задіяти будь-яке їхнє поєднання!
Наприклад, можна організувати по парі кластерів на кожну команду: кластер для розробки (у якому будуть оточення DEV и тест) та кластер для виробництво (де перебуватиме production-среда).
Маючи інформацію з цієї статті, ви зможете відповідним чином оптимізувати плюси та мінуси під конкретний сценарій. Успіхів!
PS
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com