Всім привіт! Мене звуть Павло Агалєцький. Я працюю тимлідом у команді, яка розробляє систему доставки Lamoda. У 2018 році я виступав на конференції HighLoad++, а сьогодні хочу подати розшифровку своєї доповіді.

Моя тема присвячена досвіду нашої компанії з деплою систем та сервісів у різні середовища. Починаючи від наших доісторичних часів, коли ми деплоїли всі системи у звичайні віртуальні сервери, закінчуючи поступовим перехід від Nomad до деплою в Kubernetes. Розкажу про те, чому ми це зробили і які ми мали в процесі проблеми.

Деплой додатків на VM

Почнемо з того, що 3 роки тому всі системи та послуги компанії деплоїлися на звичайні віртуальні сервери. Технічно було організовано так, що весь код наших систем лежав і збирався за рахунок засобів автоматичного збирання за допомогою jenkins. За допомогою Ansible він із нашої системи контролю версій розкочувався вже на віртуальні сервери. При цьому кожна система, яка була в нашій компанії, деплоїлася як мінімум на 2 сервери: одна з них — на head, друга — на tail. Ці дві системи були абсолютно ідентичні між собою за всіма своїми налаштуваннями, потужністю, конфігурацією та іншим. Відмінність між ними була лише в тому, що head отримував трафік користувача, а tail ніколи трафік користувачів на себе не отримував.

Навіщо це було зроблено?

Коли ми деплоїли нові релізи нашої програми, то хотіли забезпечити можливість безшовного розкочування, тобто без помітних наслідків для користувачів. Досягалося це завдяки тому, що черговий зібраний реліз за допомогою Ansible викочувався на tail. Там люди, які займалися деплоєм, могли перевірити та переконатися, що все добре: усі метрики, розділи та додатки працюють; запускаються необхідні скрипти. Тільки після того, як вони переконувалися, що все ок, трафік перемикався. Він починав йти на той сервер, який раніше був tail. А той, який до цього був head-ом, залишався без користувальницького трафіку, при цьому з попередньою версією нашої програми, що є на ньому.

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

Які ми бачили у всьому цьому переваги?

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

Але в цьому всьому ми також бачили кілька недоліків:

1. Крім продакшн-середовища, середовища розробки, є й інші середовища. Наприклад, qa та preproduction. На той момент ми мали багато серверів і близько 60 сервісів. З цієї причини доводилось для кожного сервісу підтримувати актуальну для нього версію віртуальної машини. Причому якщо ви хочете оновити бібліотеки або поставити нові залежності, вам необхідно це зробити в усіх середовищах. Також потрібно було синхронізувати час, коли ви збираєтесь деплоїти чергову нову версію вашої програми, з часом, коли devops виконає необхідні налаштування оточення. У такому разі легко потрапити в ситуацію, коли оточення у нас дещо відрізнятиметься одразу у всіх середовищах поспіль. Наприклад, у QA-середовищі будуть одні версії бібліотек, а продакшн — інші, що призведе до проблем.
2. Складність у оновленні залежностей вашої програми. Це залежить не від вас, а від іншої команди. Зокрема, від команди devops, яка підтримує сервера. Ви повинні поставити для них відповідне завдання та дати опис того, що хочете зробити.
3. Тоді ми також хотіли розділити великі великі моноліти, які були у нас, на окремі маленькі сервіси, оскільки розуміли, що їх ставатиме все більше і більше. На той момент у нас вже було їх понад 100. Необхідно було для кожного нового сервісу створювати окрему нову віртуальну машину, яку треба обслуговувати і деплоїти. Крім цього, потрібна не одна машина, а як мінімум дві. До цього всього ще додається QA-середовище. Це викликає проблеми і робить для вас створення та запуск нових систем більше складним, дорогим та довгим процесом.

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

Ми довго розмірковували над тим, яку можна взяти. Справа в тому, що на той момент цей стек деплою на звичайні віртуальні сервери був у нас дещо застарілим, тому що там були не найсвіжіші версії операційних систем. Якоїсь миті там навіть FreeBSD стояла, яку було не дуже зручно підтримувати. Ми розуміли, що потрібно якнайшвидше мігрувати в docker. Наші девопс подивилися на свій досвід роботи з різними рішеннями і вибрали таку систему як Nomad.

Перехід на Nomad

Nomad – це продукт компанії HashiCorp. Також вони відомі іншими своїми рішеннями:

«Consul» - Це засіб для сервіс-дискаверінгу.

"Terraform" — система керування серверами, що дозволяє вам налаштовувати їх через конфігурацію, так звану infrastructure-as-a-code.

"Vagrant" дозволяє розгортати віртуальні машини локально або в хмарі шляхом певних файлів конфігурації.

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

Що потрібно для того, щоб взагалі задеплоїти вашу систему в Nomad?

1. Насамперед потрібен зображення докера вашої програми. Необхідно зібрати його та помістити у сховище образів docker. У нашому випадку це artifactory - така система, яка дозволяє пушити до неї різні артефакти різного типу. Вона вміє зберігати архіви, образи docker, пакети composer РНР, NРМ-пакети тощо.
2. Також необхідний конфігураційний файл, Який скаже Nomad, що, куди і в якій кількості ви хочете задеплоїти.

Коли ми говоримо про Nomad, то як формат інформаційного файлу він використовує мову HСL, що розшифровується як HashiCorp Configuration Language. Це така надмножина над Yaml, яка дозволяє вам описати ваш сервіс у термінах Nomad.

Він дозволяє сказати, скільки контейнерів хочете задеплоїти, з яких images передати їм різні параметри при депло. Таким чином, ви згодовує цей файл Nomad, а він запускає відповідно до нього контейнери в продакшн.

У нашому випадку ми зрозуміли, що просто писати під кожен сервіс абсолютно однакові, ідентичні файли HСL буде не дуже зручно, тому що сервісів багато і іноді хочеться їх оновити. Буває таке, що один сервіс задеплоен не в одному екземплярі, а в різних. Наприклад, одна із систем, яка у нас знаходиться у продакшн, має понад 100 інстансів у проді. Вони запускаються з тих самих образів, але відрізняються конфігураційними налаштуваннями і конфігураційними файлами.

Тому ми вирішили, що нам буде зручно зберігати всі конфігураційні файли для деплою в одному загальному репозиторії. Таким чином, вони ставали до огляду: їх було легко підтримувати і можна було побачити, які системи у нас є. У разі потреби також нескладно щось оновити чи змінити. Додати нову систему теж не важко — досить просто завести конфігураційний файл усередині нової директорії. Усередині неї лежать файли: service.hcl, який містить опис нашого сервісу, і деякі env-файли, які дозволяють цей самий сервіс, будучи задеплоєним у продакшн, налаштувати.

Однак деякі наші системи задеплоєні в проді не в одному екземплярі, а в кількох відразу. Тому ми вирішили, що нам зручно буде зберігати не конфіги у чистому вигляді, а їх шаблонизований вигляд. І як мову шаблонизації ми вибрали jinja 2. У такому форматі у нас зберігаються конфіги самого сервісу, так і env-файли, потрібні для нього.

Крім цього, ми помістили в репозиторій загальний для всіх проектів скрипт-деплой, який дозволяє запустити і задеплоїти ваш сервіс у продакшн, потрібний environment, потрібний таргет. У випадку, коли ми перетворили наш HCL-конфіг на шаблон, то той HСL-файл, який до цього був звичайним конфігом Nomad, у цьому випадку виглядав дещо інакше.

Тобто ми замінили якісь змінні місця конфігу на вставки змінних, які беруться з env-файлів або інших джерел. Крім цього, ми отримали можливість збирати HСL-файли динамічно, тобто ми можемо застосовувати не лише звичайні вставки змінних. Так як jinja підтримує цикли та умови, туди ж можна робити конфігураційні файли, які змінюються в залежності від того, куди саме ви деплоїть свої програми.

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

Коли сервіс Nomad вже виявляється у вас задеплоєним у кластер, він виглядає так.

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

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

У що нам обійшовся процес переходу у плані людських ресурсів?

Приблизно 5-6 місяців зайняв перехід усієї компанії в Nomad. Ми переходили посервісно, ​​але у досить швидкому темпі. Кожна команда мала створити власні контейнери для сервісів.

У нас прийнято такий підхід, що кожна команда відповідає за docker images своїх систем самостійно. Девопс надають загальну інфраструктуру, необхідну для деплою, тобто підтримку самого кластера, підтримку CI-системи і так далі. І на той момент у нас понад 60 систем переїхали до Nomad, вийшло близько 2 тисяч контейнерів.

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

Причини відмови від Nomad

Які переваги ми отримали, перейшовши на деплой за допомогою Nomad та docker у тому числі?

1. Ми забезпечили однакові умови для всіх середовищ. У девеломпенті, QA-середовищі, препродакшні, продакшні використовуються одні і ті ж образи контейнерів, з одними і тими ж залежностями. Відповідно у вас практично відсутній шанс того, що у продакшн виявиться не те, що ви до цього протестували у себе локально або на тестовому оточенні.
2. Також ми з'ясували, що достатньо легко додати новий сервіс. Будь-які нові системи з погляду деплою запускаються дуже просто. Достатньо піти до репозиторію, що зберігає конфіги, додати туди черговий конфіг для вашої системи, і у вас все готове. Ви можете деплоїти систему в продакшн без додаткових зусиль від девопс.
3. Усі конфігураційні файли в одному загальному репозиторії виявилися оглядані. У той момент, коли ми деплоїли наші системи за допомогою віртуальних серверів, ми використовували Ansible, в якому конфіги лежали в тому самому репозиторії. Однак для більшості розробників працювати з цим було дещо складніше. Тут обсяг конфігів та коду, який вам потрібно додати, щоб задеплоїти сервіс, став набагато меншим. Плюс для девопсу дуже легко поправити його або поміняти. У разі переходів, наприклад, на новій версії Nomad, вони можуть взяти та масово оновити всі операційні файли, що лежать в тому самому місці.

Але ми також зіткнулися і з декількома недоліками:

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

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

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

У цьому плані наш вибір впав на Kubernetes як найпопулярнішу платформу для запуску кластерів. Особливо за умови того, що розмір та кількість наших контейнерів був досить великий. Для таких цілей Kubernetes видався найвідповіднішою системою з тих, що ми могли подивитися.

Перехід у Kubernetes

Трішки розповім про те, які є основні поняття Kubernetes і чим вони відрізняються від Nomad.

Найперше базовим поняттям у Kubernetes є поняття pod. Стручок - Це група одного або декількох контейнерів, які завжди запускаються разом. І вони працюють начебто завжди строго на одній віртуальній машині. Вони доступні один одному за IP-адресою 127.0.0.1 на різних портах.

Припустимо, що у вас є РНР-додаток, який складається з nginx та php-fpm – класична схема. Швидше за все, ви захочете, щоб і nginx і php-fpm контейнери завжди були разом. Kubernetes дозволяє цього досягти, описавши їх як один загальний під. Саме це ми й не могли отримати за допомогою Nomad.

Другим поняттям є розгортання. Справа в тому, що pod сама по собі – це ефемерна річ, вона запускається та зникає. Чи хочете ви спочатку вбивати всі ваші попередні контейнери, а потім запускати відразу нові версії або ж ви хочете викочувати їх поступово - саме за цей процес відповідає поняття deployment. Він описує те, як ви деплоїть ваші podи, в якій кількості і, як їх оновлювати.

Третім поняттям є обслуговування. Ваш service – це фактично ваша система, яка бере на себе якийсь трафік, а потім спрямовує його на один або кілька podів, що відповідають вашому сервісу. Тобто він дозволяє сказати, що весь вхідний трафік на такий-то сервіс з таким ім'ям необхідно відправляти на ці піди. І при цьому він забезпечує вам балансування трафіку. Тобто ви можете запустити два podа вашого додатка, і весь вхідний трафік буде рівномірно балансуватися між відношеннями до цього сервісу podами.

І четверте основне поняття Вхід. Це сервіс, який запускається у кластері Kubernetes. Він постає як зовнішній балансувальник навантаження, який приймає він всі запити. За рахунок API Kubernetes Ingress може визначати, куди ці запити потрібно надіслати. Причому робить це дуже гнучко. Ви можете сказати, що всі запити на цей хост і URL відправляємо на цей сервіс. А ці запити, що приходять на цей хост та на інший URL, відправляємо на інший сервіс.

Найкрутіше з погляду того, хто розробляє додаток - це те, що ви здатні цим усім керувати самостійно. Задавши конфіг Ingress, можете весь трафік, що приходить на API, відправляти на окремі контейнери, прописані, наприклад, на Go. А ось цей трафік, що приходить на той самий домен, але на інший URL, відправлятимуть на контейнери, написані на РНР, де багато логіки, але вони не дуже швидкісні.

Якщо порівняти всі ці поняття з Nomad, можна сказати, що перші три поняття – це все разом Service. А останнє поняття у самому Nomad відсутнє. Ми використовували його як зовнішній балансувальник: це може бути haproxy, nginx, nginx+ і так далі. У разі куба вам не треба вводити це додаткове поняття окремо. Однак, якщо подивитися на Ingress всередині, то це або nginx, або haproxy, або traefik, але ніби вбудований у Kubernetes.

Всі описані мною поняття – це, по суті, ресурси, які існують усередині кластера Kubernetes. Для їх опису в кубі використовується yaml-формат, більш зчитуваний і звичний, ніж НСL-файли у випадку з Nomad. Але структурно вони описують у разі, наприклад, podа те саме. Вони кажуть – хочу задеплоїти такі піди туди, з такими імаджі, в такій кількості.

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

Основні поняття в Helm

Helm – це пакетний менеджер для Kubernetes. Він дуже подібний до того, як працюють пакетні менеджери в мовах програмування. Вони дозволяють вам зберігати сервіс, що складається з, наприклад, deployment nginx, deployment php-fpm, конфіга для Ingress, configmaps (це сутність, яка дозволяє задати env та інші параметри для вашої системи) у вигляді так званих чартів. При цьому Helm працює поверх Kubernetes. Тобто це не якась система, що стоїть осторонь, а ще один сервіс, що запускається всередині куба. Ви взаємодієте з ним через його API через консольну команду. Його зручність і принадність у тому, що навіть якщо helm зламається або ви його видалите з кластера, то ваші сервіси не зникнуть, оскільки helm служить по суті тільки для запуску системи. За працездатність та стан сервісів далі відповідає сам Kubernetes.

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

Helm додає нам ще кілька додаткових понять.

Графік - Це опис вашого сервісу. В інших пакетних менеджерах його назвали б пакет, bundle чи щось подібне. Тут це називається chart.

Цінності – це змінні, які ви хочете використовувати для збирання конфігів із шаблонів.

Відпустіть. Щоразу сервіс, який деплоїться за допомогою helm, отримує інкрементальну версію релізу. Helm пам'ятає, який був конфіг сервісу при попередньому позаминулому релізі і так далі. Тому, якщо потрібно відкотитись, достатньо виконати команду helm callback, вказавши йому попередню версію релізу. Навіть якщо в момент відкату відповідна конфігурація у вашому репозиторії не буде доступна, helm все одно пам'ятає, якою вона була, і відкотить вашу систему на стан, в якому вона була в попередньому релізі.

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

На практиці ми вирішили вчинити трохи інакше, ніж ми робили у випадку з Nomad. Якщо в Nomad в одному репозиторії зберігалися конфіги для деплою, і n-змінні, які потрібні для того, щоб задеплоїти наш сервіс, то тут ми вирішили їх розділити на два окремих репозиторія. У репозиторії «deploy» зберігаються лише n-змінні, необхідних деплоя, а репозиторії «helm» зберігаються конфіги чи чарти.

Що нам це дало?

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

Оскільки у нас є не тільки продакшн, але й інші середовища, то завдяки такому поділу ми можемо перевикористовувати наші helm-чарти, щоб деплоїти сервіси не тільки в продакшн, а й, наприклад, QA-середовище. Навіть для того, щоб розгортати їх локально, використовуючи Мінікубе - Це така штука для локального запуску Kubernetes.

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

Ми залишили скрипт для деплою – deploy.sh, який спрощує та стандартизує запуск для деплою за допомогою helm. Таким чином, для будь-кого, хто хоче задеплоїти, інтерфейс деплою виглядає так само, як він був у випадку деплою через Nomad. Такою ж є deploy.sh, назва вашого сервісу, і те, куди ви хочете його задеплоїти. Це призводить до того, що всередині запускається helm. Він у свою чергу збирає конфіги із шаблонів, підставляє в них необхідні values-файли, потім деплоїт, пускаючи їх у Kubernetes.

Висновки

Сервіс Kubernetes виглядає складнішим, ніж Nomad.

Тут вихідний трафік приходить до Ingress. Це якраз фронт-контролер, який приймає він всі запити і згодом відправляє в відповідні даним запиту сервіси. Визначає їх на основі конфігів, які є частиною опису вашого додатка в helm і які розробники задають самостійно. Сервіс же надсилає запити на свої podи, тобто конкретні контейнери, балансуючи вхідний трафік між усіма контейнерами, що відносяться до цього сервісу. Ну і, звичайно, не варто забувати про те, що від безпеки на рівні мережі ми нікуди не повинні йти. Тому в кластері Kubernetes працює сегментація, яка базується на тегуванні. Усі сервіси мають певні теги, яких прив'язані права доступів сервісів до тих чи іншим зовнішнім/внутрішнім ресурсам всередині або поза кластером.

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

Приклад такого використання є Prometheus, який запускається у нас усередині кластера Kubernetes. Для того щоб він почав збирати метрики з того чи іншого сервісу, нам потрібно додати в опис сервісу додатковий тип ресурсу, так званий сервіс-монітор. Prometheus за рахунок того, що вміє вичитувати, будучи запущеним у Kubernetes, кастомний тип ресурсів автоматично починає збирати метрики з нової системи. Це досить зручно.

Перший деплой, який ми зробили у Kubernetes був у березні 2018 року. І за цей час ми ніколи не мали з ним жодних проблем. Він досить стабільно працює без істотних багів. До того ж ми можемо його далі розширювати. На сьогоднішній день нам вистачає тих можливостей, які є, а темпи розвитку Kubernetes нам дуже подобаються. На даний момент більше 3000 контейнерів знаходяться у Kubernetes. Кластер займає кілька Node. При цьому він обслуговується, стабільний і контрольований.

Джерело: habr.com