Технічна підтримка Kubernetes: підняти кластер – це найлегши

Блог WebDisk · категорія: Публічна хмара · час читання: ~7 хвилин

Коротко:- Кластер Kubernetes виглядає найкраще в день запуску. Справжня робота починається пізніше: три релізи на рік, копії бази etcd, моніторинг, безпека і хтось, хто прийме сигнал тривоги вночі.- Хороша технічна підтримка – це не «допомога, коли щось перестане працювати», а постійний процес: оновлення, перевірений бекап, розуміння того, що відбувається в кластері (спостережуваність), і чіткі правила реагування.- У хмарі WebDisk ви запустите керований кластер Kubernetes (WebDisk K8s) або побудуєте власний на інфраструктурі IaaS – а в плануванні міграції та налаштуванні допоможе наша команда. >Не працюєте з терміналом? Пропустіть єдиний блок команд у статті – уся решта обходиться без нього.

Kubernetes став стандартом запуску застосунків, побудованих із мікросервісів – невеликих сервісів, які розгортають незалежно один від одного, – також у компаніях, які зовсім не починали «з хмари». Типова картина в компаніях, які розвивають своє програмне забезпечення роками, виглядає так: частина систем працює на класичних віртуальних машинах, частина – у контейнерах Docker або в Docker Swarm (старішому, простішому способі запуску контейнерів на багатьох серверах), і лише найновіші проєкти – у кластері Kubernetes. Таке гібридне середовище – це не заборгованість, яку треба надолужити, а природний наслідок послідовних, розважливих рішень, ухвалюваних протягом років.

Є в цьому, однак, пастка, про яку говорять рідше, ніж про саму міграцію: піднятий кластер – це не те саме, що кластер, який утримують. Запустити Kubernetes ніколи не було простіше; зберігати його в доброму стані впродовж наступних років досі вимагає праці, знань і чергувань. У цій статті ми показуємо, у чому полягає ця робота, що повинна охоплювати хороша технічна підтримка Kubernetes і як виглядає Kubernetes у хмарі WebDisk.

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

Чому підняти кластер Kubernetes – це лише початок?

Підняти кластер сьогодні – справа кількох годин: інсталятори та хмарні платформи зняли з адміністраторів більшість колишньої складності. Труднощі перемістилися в інше місце: до всього, що відбувається після запуску. Чотири приклади:

Цикл релізів. Kubernetes публікує три релізи на рік, і кожен отримує виправлення – зокрема виправлення безпеки – протягом приблизно 14 місяців. Кластер, який не оновлювали трохи більше року, випадає з цього вікна, а надолуження відставання не є одним стрибком: версії підвищують по черзі, без перескакування.
Виведені з ужитку API. Наступні релізи видаляють застарілі інтерфейси. Маніфест розгортання, який бездоганно працював два роки, після оновлення може перестати застосовуватися – тому перегляд використовуваних API є елементом кожного запланованого оновлення.
Сертифікати. Компоненти кластера автентифікуються між собою TLS-сертифікатами з обмеженим терміном дії – у типових інсталяціях це один рік. Прострочений сертифікат шару керування (control plane) здатний за один ранок відрізати адміністраторів від кластера.
etcd. Це база даних, у якій кластер зберігає весь свій стан: визначення розгортань, конфігурацію, секрети. Без регулярної копії etcd – і без перевіреного відновлення – серйозна аварія control plane означає відбудову кластера з нуля.

Жоден із цих пунктів не є екзотичним; це звичайне, повторюване адміністрування. Питання лише в тому, чи має це хтось в організації у своїх обов'язках – чи радше воно відбувається «принагідно», доки відбувається.

Що повинна охоплювати хороша технічна підтримка Kubernetes?

Коли ви оцінюєте пропозицію підтримки – зовнішню або можливості власної команди – перевірте, чи закриває вона п'ять сфер:

Оновлення та життєвий цикл. Заплановані вікна оновлення control plane і вузлів, перегляд виведених з ужитку API перед кожним підвищенням версії, контроль терміну дії сертифікатів. Нудьга – і саме тому це перша річ, яка випадає з календаря перевантаженої команди.
Бекап і тест відновлення. Регулярна копія etcd та – окремо – даних застосунків на томах. Копія, яку ніхто ніколи не відновлював, – це не копія, а надія; правила розумного бекапу ми ширше описали у статті Резервна копія в хмарі – основа сучасної IT-безпеки.
Моніторинг і сповіщення. Метрики control plane, вузлів і самих застосунків, а також сповіщення, які доходять до чергового – на боці постачальника або на вашому; це один із найчастіше пропущених пунктів договору, тож узгодьте його завчасно. Важливе також налаштування: система, яка без причини б'є на сполох сто разів на день, привчає людей ігнорувати сигнали тривоги.
Безпека. Керування доступом на основі ролей (RBAC – механізм Kubernetes, який вирішує, хто може виконати яку операцію), оновлення систем на вузлах, сканування образів контейнерів на відомі вразливості, мережеві політики між сервісами. Про те, як ми самі укладаємо шари захисту нашої платформи, розповідаємо у статті Стек безпеки open source у WebDisk.
Реагування на інциденти. Визначений шлях звернень, чіткий розподіл відповідальності між постачальником і клієнтом та процедури для аварійних сценаріїв – записані ще до того, як стануть потрібні.

Якщо ви хочете швидко перевірити стан власного кластера, почніть із трьох команд:

# яка версія сервера API – порівняйте її з календарем релізів Kubernetes (виправлення ~14 місяців)
kubectl version

# стан вузлів та узгодженість їхніх версій
kubectl get nodes -o wide

# попередження з усього кластера
kubectl get events -A --field-selector type=Warning

І одне запитання, на яке не відповість жодна команда: коли востаннє хтось відновлював копію etcd у тестовому середовищі? Якщо відповідь звучить «ніколи» – це перший пункт до списку завдань, ще перед розмовою про розширення кластера.

Міграція – це процес, а не переїзд за вихідні

Хороша підтримка починається, зрештою, ще до створення кластера. Міграція до Kubernetes рідко буває одноразовим стрибком – це послідовність етапів: інвентаризація (що вже працює в контейнерах, що зберігає стан, що залишається на віртуальних машинах), вибір перших кандидатів, перенесення, спостереження, наступна партія. Частиною чесного плану є також перелік застосунків, які не варто переносити: моноліт, що стабільно працює на одній віртуальній машині, після контейнеризації не стане раптом масштабованим мікросервісом – натомість здобуде новий шар складності.

Допомагаємо, зокрема, у двох сценаріях: перенесення середовищ із Docker Swarm до Kubernetes та міграції цілих середовищ віртуалізації до нашої хмари – цю другу тему описуємо у статті Міграція з VMware до WebDisk Cloud Computing.

Kubernetes у WebDisk: керований кластер або власний на IaaS

У нашій публічній хмарі Kubernetes доступний двома шляхами:

Керований кластер Kubernetes (WebDisk K8s) – послуга, доступна для користувачів WebDisk Cloud. Платформа (побудована на Apache CloudStack) створює кластер автоматично, а кількість вузлів ви змінюєте в панелі (cloud.dco.webdisk.io), без ручного втручання в кожну машину; оновлення версії кластера плануємо разом із вами, бо Kubernetes оновлюють по черзі, реліз за релізом. «Керований» означає тут: платформа створює кластер і масштабує його за вас. Копія etcd, оновлення сертифікатів, оновлення системи на вузлах і моніторинг ваших застосунків залишаються на боці власника кластера – хіба що ми домовимося інакше.
Власний кластер на IaaS – для команд, які хочуть повного контролю над дистрибутивом і конфігурацією. IaaS (Infrastructure as a Service) означає, що ви орендуєте в нас віртуальні машини та мережу, а середовище будуєте на них інструментами, які знаєте; досвідчені команди можуть скористатися Cluster API з провайдером для CloudStack (автоматичне створення та відтворення кластерів) або CloudStack Kubernetes Provider, який пов'язує готовий кластер із мережею та балансувальниками навантаження платформи.

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

Чого технічна підтримка Kubernetes не вирішить?

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

Рішення «чи взагалі Kubernetes». Не кожен застосунок виграє від оркестрації контейнерів. Для багатьох навантажень віртуальна машина залишається простішим і дешевшим в експлуатації вибором – про відмінності між моделями хмарних послуг ми писали у статті Хмара як послуга, а про витрати на публічну хмару – у статті Публічна хмара за розумною ціною.
Межі слова «керований». Керована послуга Kubernetes створює кластер і масштабує його за вас. Копія etcd, оновлення сертифікатів, оновлення системи на вузлах і моніторинг ваших застосунків не відбуваються самі – хтось мусить мати їх у своїх обов'язках: ваша команда або наша, на підставі договору.
Зміни в самому застосунку. Підтримка утримає кластер, але не перепише архітектуру застосунку, який не готовий до роботи в контейнерах.
Відповідальність за дані. Бекап інфраструктури кластера – це не те саме, що політика резервного копіювання даних застосунків; цю другу треба свідомо спроєктувати і регулярно тестувати.
Складність як така. Kubernetes додає шар абстракції, який має свою ціну. Хороша підтримка цією складністю керує – але її не ліквідує.

Часті запитання

Чи мушу я використовувати Kubernetes, щоб користуватися хмарою WebDisk? Ні. Kubernetes – це один із варіантів, поряд із класичними віртуальними машинами, VPS і файловими послугами. Якщо ваші навантаження добре працюють на VM, міграція до контейнерів не є умовою користування нашою платформою.

Я підняв кластер самостійно. Чи можу розраховувати на підтримку? Так – допомогою можна скористатися на будь-якому етапі: під час планування міграції, після самостійного впровадження, а також для застосунків, які працюють у нашій хмарі від початку. Обсяг узгоджуємо індивідуально, у договорі.

Що означає «керований» кластер Kubernetes і що залишається на моєму боці? У WebDisk K8s «керований» означає: платформа створює кластер і масштабує його за вас – кількість вузлів ви змінюєте в панелі. Копія etcd, оновлення сертифікатів, оновлення системи на вузлах і моніторинг ваших застосунків залишаються на боці власника кластера, хіба що ми домовимося інакше. Цей розподіл відповідальності варто мати записаним у договорі, ще до того, як він стане потрібен.

Як часто треба оновлювати кластер Kubernetes? Kubernetes публікує три релізи на рік, і кожен отримує виправлення – зокрема виправлення безпеки – протягом приблизно 14 місяців. Кластер, який не оновлювали трохи більше року, випадає з цього вікна, а відставання надолужують версія за версією, без перескакування. Елементом кожного запланованого оновлення має бути також перегляд виведених з ужитку API.

Чи копія etcd – це повний бекап кластера? Ні. Копія etcd захищає стан кластера: визначення розгортань, конфігурацію, секрети. Дані застосунків – бази даних, файли на томах – потребують окремої стратегії резервного копіювання, з окремим тестом відновлення.

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

Підсумок

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

Технічна підтримка Kubernetes: підняти кластер – це найлегший етап