Що таке Kubernetes

Kubernetes (відома також як K8s) — це платформа з відкритим кодом, яка використовується для запуску та керування контейнерами та службами. K8s може використовуватись на фізичних або віртуальних кластерах у локальних, публічних, приватних і гібридних хмарах. Платформа автоматизує складні завдання протягом життєвого циклу контейнера – ініціалізація, розгортання, створення мережі, масштабування, балансування навантаження тощо. Це спрощує оркестровку в хмарних середовищах.

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

Для чого використовується Kubernetes?

Основною перевагою використання контейнерів над віртуальними машинами для архітектури мікросервісів є їхній малий розмір і продуктивність. Їх можна розгортати та згортати набагато швидше і вони мають миттєвий доступ до системних ресурсів. Це звільняє ресурси і робить інфраструктуру більш компактною. Інші переваги включають скорочені конвеєри CI/CD, ефективне використання ресурсів, високу доступність, безперебійну роботу незалежно від середовища та самовідновлення системи шляхом автоматичного перезапуску або реплікації контейнерів.
Kubernetes вам підійде, якщо ви маєте будь-яку з наступних проблем:• Повільна відокремлена розробка перешкоджає розкладу релізів• Нездатність досягти масштабованості, необхідної для задоволення зростаючого попиту клієнтів• Відсутність кадрів у компанії, які спеціалізуються на управлінні контейнерними програмами• Високі витрати при оптимізації ресурсів існуючої інфраструктури
Kubernetes допомагає подолати всі ці обмеження. Нижче перелік хмарних провайдерів, які надають Kubernetes-платформу як керований сервіс:
• Azure Kubernetes (AKS)• Amazon Elastic Kubernetes (EKS)• IBM Cloud Kubernetes• Red Hat OpenShift• Google Cloud Kubernetes Engine (GKE)
Хмарні провайдери дають змогу використовувати Kubernetes підприємствам будь-якої інфраструктури та масштабу.
Якщо ж у компанії немає можливості чи необхідності використовувати хмарну інфраструктуру, Kubernetes можна розгорнути наземно. Нижче перелік популярних дистрибутивів, які дають можливість організаціям розмістити Kubernetes на власних ресурсах:
• Red Hat OpenShift Container Platform• Rancher Kubernetes Engine• Mirantis Docker Kubernetes Service (formerly Docker EE)• VMWare Tanzu Kubernetes Grid (раніше Pivotal Container Service – PKS)• D2iQ Konvoy
Гнучкість та портативність контейнерів – це великий плюс, але не все так просто. Використання мікросервісної архітектури разом з технологіями контейнеризації створює нові виклики для DevOps-команд:
• Архітектура стає більш розгалуженою, її важче контролювати і аналізувати під час збоїв чи проблем з продуктивністю• Кількість і типи мета-даних, які необхідно аналізувати для діагностики стають неймовірно великими
Автоматизація і скорочення циклів релізів створює постійний тиск на IT-команди та Operations. Мікросервіси та контейнеризація відкривають можливості для використання новітніх фреймворків. Стає все важче підтримувати нові технології через нестачу відповідної компетенції та постійних часових обмежень
Аби здолати дані виклики, компаніям потрібно забезпечити автоматичний аналіз даних та повну видимість того, що відбувається в їх Kubernetes-інфраструктурі. Це потрібно для того, аби спростити роботу спеціалістів та прискорити IT-трансформацію всіх процесів паралельно. Досягнути цього результату можна завдяки правильно обраному рішенню для моніторингу.
Нижче поговоримо більш детально про методи моніторингу, вимоги, можливості різних підходів та рішень.

Вимоги до моніторингу або «повної видимості» інфраструктури

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

1. Видимість повного стеку.
Перехід на мікросервіси – це автоматично розгалуження та збільшення інфраструктури. Аби нічого не пропустити, потрібно мати можливість повністю відслідковувати все, що відбувається в оновленому стеку.
2. Контроль процесів та коду.
Невчасно виправлена помилка має властивість з часом ставати масштабнішою. Моніторинг процесів та коду на продуктивність та наявність помилок є одним з ключових факторів для зменшення часу, затраченого на пошук тих самих помилок та покращення показників.
3. Простота використання.
Моніторинг імплементується для того, аби витрати часу стали меншими, а ефективність, відповідно, зросла. Тому тут головне не попасти в пастку «фіктивних покращень» коли, з одного боку, моніторинг працює і оптимізує CI/CD процеси, а з іншого – вимагає час на постійні налаштування, розширення, оновлення і тд.
4. Автоматичне масштабування.
Мікросервіси спростили та прискорили розробку, але ускладнили контроль оновленого стеку. Потрібно мати рішення, яке матиме змогу автоматично масштабуватися разом зі змінами в інфраструктурі, а не яке потребуватиме постійного контролю та ручного налаштування.
5. Можливість моніторингу як хмари, так і наземної інфраструктури.
Все залежить від масштабів інфраструктури та швидкості розвитку компанії. Динаміка показує, що рано чи пізно всі повністю або частково перейдуть на хмарні сервіси, а це означає, що потрібно наперед враховувати можливість гібридного моніторингу.
6. Автоматичний аналіз проблем.
Моніторинг не повинен перетворювати одні проблеми на інші. Отримувати сповіщення про помилку недостатньо, особливо коли таких помилок десятки-сотні-тисячі. Обране рішення повинно не лише визначати наявність помилок, але і вказувати конкретно на місце та причину походження помилки без зайвих критичних спрацювань. Тільки в такому разі ви дійсно зможете оцінити, яким саме повинен бути моніторинг і його переваги.
7. Моніторинг клієнтського досвіду.
Бізнес відслідковує конверсії в додатках та веб-ресурсах, а тому клієнтський досвід є одним з ключових КРІ. Без розуміння поведінки користувача та аналізу його сесій, неможливо реалізовувати правильні покращення. Наприклад, поки ваш користувач буде чекати оновлення з покращенням часу відповіді сервісу, ви буде займатись зміною кольору кнопок. В такому випадку пріоритети в розробці матимуть не гіпотетичний, а наочний характер. Моніторинг клієнтського досвіду – технічна перевага для бізнесу сьогодні.
8. Оптимальна вартість володіння.
Побудувати «платформу видимості» на базі open source-рішень чи придбати готовий моніторинг? Прорахуйте вартість обслуговування різних підходів у довгостроковій перспективі. У першому випадку ваші витрати – це вартість часу ваших спеціалістів + час на пошук проблем + втрачені можливості, яких ви б досягли маючи більше часу на інновації. У абсолютній більшості випадків оптимальним виявляється комерційний моніторинг, так як підхід з open source ніхто ніколи не рахує. хибно вважаючи, що це єдине правильне рішення.

Маючи перелік вимог можна більш предметно проаналізувати інструменти перед вибором. Нижче ми порівняємо можливості моніторингу Kubernetes на прикладі можливостей Prometheus та комерційного рішення Dynatrace. Та спершу ознайомимося з рішеннями.

Prometheus для моніторингу Kubernetes

З переходом у хмару, Prometheus став одним з перших інструментів для моніторингу Kubernetes.

Prometheus ¬– це моніторингова система з відкритим вихідним кодом. Вона являє собою багатовимірну модель даних, з часовими рядами, що ідентифікуються назвою метрики та парою ключ-значення. Система працює за pull-моделлю: сервер опитує власноруч кожен вузол, що потребує моніторингу. Prometheus зберігає всю зібрану інформацію локально та запускає правила для цих даних – агрегує та записує нові часові ряди з наявних даних або створює сповіщення за налаштованими попередньо правилами.


Архітектура Prometheus і деякі компоненти його екосистеми: 

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

Prometheus дійсно хороший інструмент, якщо постійно виділяти час на його підтримку та розвиток, адже, як і будь-який open source, він потребує постійної залученості: розширення, оновлення, масштабування. Окрім того, робота з Prometheus має обмеження, які варто враховувати.
Все, що вам потрібно знати про Prometheus описано тут.

Корпоративна платформа моніторингу Dynatrace для Kubernetes

Dynatrace – моніторинг-платформа на базі штучного інтелекту (Davis AI). Вона забезпечує видимість всієї інфраструктури незалежно від того, чи вона знаходиться наземно, чи у хмарі, чи є гібридною. Dynatrace дає можливість автоматично, без зайвих налаштувань та інтеграцій, відслідковувати залежності мікросервісів, продуктивність додатків, їх працездатність та споживання ресурсів.

*структура моніторингу Kubernetes Dynatrace.

В рамках інтеграції Dynatrace з Kubernetes існує два підходи: 
1. Віддати моніторинг повністю платформі без необхідності реалізовувати open source рішення. В такому випадку платформа автоматично визначить інфраструктуру та встановить агенти на всі кластери Kubernetes та інші елементи інфраструктури за лічені хвилини.2. Якщо моніторинг на базі того ж Prometheus вже реалізований, необхідно буде просто налаштувати інтеграцію завдяки модулю Dynatrace Prometheus OpenMetric і всі значення будуть автоматично передаватися в єдиний центр обробки інформації та аналізуватися завдяки AI. Таким чином, більше не буде необхідності збирати та аналізувати дані з різних ресурсів і зʼявиться більше можливостей для контролю загального стану інфраструктури та оперативного вирішення проблем.
В кожному з цих підходів встановлення відбувається автоматично, як і масштабування. Весь необхідний функціонал вже входить в рішення, не потрібно налаштовувати додаткові інтеграції тощо. Навіть існує широкий вибір попередньо налаштованих дашбордів, яких цілком вистачає для більшості кейсів задач. І найголовніше – ви отримаєте детальний аналіз проблеми до самої її першопричини, що позбавить ІТ-команду великої кількості часу та сил на марну боротьбу з пошуком реальних проблем та їх аналізом.
А тепер проведемо короткий аналіз двох підходів та дамо коментарі.

Порівняння можливостей Open Source та Dynatrace для моніторингу Kubernetes

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

Якщо у компанії немає подібного переліку вимог, про який було згадано вище, то Open Source підхід може цілком забезпечити базові потреби по моніторингу Kubernetes та інфраструктури. Звісно ж, при умові, що витрати ресурсів на підтримку обраного рішення для бізнесу не є критичними. Якщо ж масштаби вимагають більш зваженого підходу, який буде в першу чергу розрахований та посилення та масштабування ролі ІТ в бізнесі, тоді потрібно розглядати комерційні рішення з урахуванням всіх їх можливостей. В першу чергу важливо детально ознайомитися з можливостями того чи іншого корпоративного моніторингу, адже вони теж суттєво відрізняються між собою.
У випадку моніторингу Kubernetes Dynatrace максимально спрощує управління та роботу з мікросервісами. Завдяки AI в основі, всі ті задачі, які потребують великої кількості людського ресурсу, можуть бути вирішені автоматично в режимі реального часу.

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

Керування складністю Kubernetes з Davis AI

Отже, як Dynatrace допомагає розумно керувати Kubernetes?
БачитиІнформаційна панель надає огляд усього робочого навантаження Kubernetes, показуючи всі існуючі контейнери та їх поточні показники. Далі вона в динаміці оцінює актуальний розмір робочого навантаження Kubernetes: недостатні та надмірні робочі навантаження. Таким чином, управління кластерами Kubernetes з допомогою Dynatrace перестає містили «сліпі» зони для контролю та стає більш економним як в питаннях затрат ресурсів, так і часу команд. 
ВідстежуватиAI, заснований на причинно-наслідкових зв’язках, детально визначає час відгуку та пропускну здатність сервісів. Звідти Davis виявляє конкретні проблеми (наприклад, погіршення часу відгуку) та пов’язує ці проблеми з конкретними наслідками для бізнесу та аномаліями показників. Таким чином, одна проблема є однією проблемою, а не шквалом повідомлень від всіх дотичних сервісів. Найважливіше те, що Davis AI визначає ключову причину проблем, що дає змогу виправити її максимально оперативно, без витрат зайвих ресурсів.

Наприклад, він може вказати, як недостатнє виділення ресурсів уповільнило роботу служб. Рішення підкреслює, як уповільнення роботи однієї служби мало величезний вплив на всю систему. Це може призвести до поганої взаємодії сервісу з користувачем. Davis — це єдиний механізм штучного інтелекту, який з’єднує точки між службами та розуміє, як невеликі зміни можуть мати серйозний вплив на складні системи.
АвтоматизуватиМаючи повний комплексний доступ до всієї інфраструктури, наземно чи в хмарі, та будучи інтегрованим в CI/CD процеси, Davis AI може виконувати базові автовиправлення чи самовідновлення. Так, наприклад, при перевантаженні ЦП штучний інтелект може самостійно додати новий сервіс аби перевантаження не створювало проблем для користувачів. Після останнього релізу користувачі мали проблеми з сервісом і вдалося це визначити аж через 2 дні? В такому випадку, AI, при виявленні проблеми, може здійснити відкат до попередньої версії аби клієнти і надалі користувалися робочим сервісом, а команда змогла виправити помилку. Таким чином, бізнес позбувається зайвого стресу, а ІТ – зайвого клопоту.

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