Привіт, Хабре!
Ми представляємо команду платформи Exness. Раніше наші колеги вже писали статтю про . Сьогодні ми хочемо поділитися досвідом міграції сервісів Kubernetes.
Для початку пропонуємо вам трохи цифр для більшого розуміння того, про що йтиметься:
- Наш відділ розробки це 100+ чоловік, серед яких понад 10 різних команд із самодостатніми процесами QA, DevOps та Scrum. Стек розробки – Python, PHP, C++, Java та Golang.
- Розмір тестового та продуктового середовища - близько 2000 контейнерів у кожній. Знаходяться вони під керуванням Rancher v1.6 на своїй віртуалізації та під VMware.
Мотивація
Як кажуть, ніщо не вічне під місяцем, і Rancher вже досить давно оголосив про припинення підтримки версії 1.6. Так, ми більш ніж за три роки навчилися його готувати і вирішувати проблеми, але все частіше ми стикалися з проблемами, які ніколи не будуть виправлені. Також Rancher 1.6 має закостенілій системі видачі прав, де ти або можеш майже все, або нічого.
Власна віртуалізація хоч і надавала більший контроль над зберіганням даних та їх безпекою, але накладала операційні витрати, з якими важко миритися при постійному зростанні компанії, кількості проектів і вимог до них.
Нам хотілося дотримуватися стандартів IaC і за необхідності отримати потужності швидко, у будь-якій географічній локації та без вендор локу, а також мати можливість швидко від них відмовитись.
Перші кроки
Насамперед ми хотіли спиратися на сучасні технології та рішення, які дозволили б командам мати швидший цикл розробки та знижувати до мінімуму операційні витрати на взаємодію з платформою, що надає потужності.
Звичайно ж, перше, що спало нам на думку - це Kubernetes, але ми не стали гарячкувати і провели невелике дослідження на предмет вірності вибору. Ми оцінювали тільки Opensource рішення, і в нечесній сутичці беззастережно переміг Kubernetes.
Далі постало питання вибору інструменту для створення кластерів. Ми порівняли найпопулярніші рішення: kops, kubespray, kubeadm.
Для старту kubeadm здався нам надто складним шляхом, швидше, якимось винахідником «велосипеда», а kops не вистачало гнучкості.
І переможцем вийшов:
Ми почали ставити експерименти на власній віртуалізації та AWS, намагаючись відтворити зразкову подобу нашого попереднього патерну управління ресурсами, де всі використовують один і той самий «кластер». І ось у нас з'явився перший кластер розміром 10 невеликих віртуальних машин, пара з яких знаходиться в AWS. Ми почали пробувати мігрувати туди команди, начебто все стало «добре», і розповідь можна було б закінчити, але…
Перші проблеми
Ansible — те, на чому побудований kubespray, це не той інструмент, який дозволяє слідувати IaC: при введенні/виведенні нод з експлуатації постійно щось йшло не так, і вимагалося якесь втручання, а при використанні різних ОС плейбук поводився по- різному. Зі зростанням кількості команд та нід у кластері ми стали помічати, що плейбук виконувався все довше і довше, у результаті наш рекорд 3,5 години, а ваш? 🙂
І начебто kubespray це просто Ansible, і все зрозуміло на перший погляд, але:
На початку шляху стояло завдання запускати потужності тільки в AWS і на віртуалізації, але потім, як часто буває, вимоги змінилися.
У світлі цього стало зрозуміло, що наш старий патерн об'єднання ресурсів в одну систему оркестрації не підходив — у разі коли кластери сильно видалені і знаходяться під управлінням різних провайдерів.
Дальше більше. Коли всі команди працюють у межах одного кластера, різні сервіси з неправильно встановленими NodeSelector могли прилетіти на «чужий» хост іншої команди і там утилізувати ресурси, а у разі виставлення taint — з'являлися постійні звернення про те, що той чи інший сервіс не працює, розподіляється правильно через людський фактор. Ще однією проблемою виявився розрахунок вартості, особливо з огляду на проблеми при розподілі сервісів за нодами.
Окремою історією йшла видача прав співробітникам: кожна команда хотіла бути «на чолі» кластера і повністю ним управляти, що могло викликати повний колапс, оскільки команди переважно одна від одної незалежні.
Як бути?
Враховуючи вищеописане та побажання команд бути незалежнішими, ми зробили простий висновок: одна команда – один кластер.
Так у нас з'явився другий:
А потім і третій кластер:
Тут ми почали думати: припустимо, за рік у наших команд буде не один кластер? У різних географічних зонах, наприклад, чи під керуванням різних провайдерів? А хтось із них захоче мати можливість швидко розгорнути тимчасовий кластер для будь-яких тестів.
Настав би повний Кубернетес! Це якийсь MultiKubernetes, виходить.
При цьому всім нам треба буде якимось чином підтримувати всі ці кластери, мати можливість легко керувати доступом до них, а також створювати нові та виводити старі з експлуатації без ручного втручання.
З моменту початку нашого шляху в світі Кубернетеса пройшов деякий час, і ми вирішили зробити повторне вивчення доступних рішень. Виявилося, що на ринку воно вже є Rancher 2.2.
На першому етапі наших досліджень Rancher Labs вже зробили перший реліз версії 2, але хоч його і можна було дуже швидко підняти, запустивши контейнер без зовнішніх залежностей із парою параметрів або використовуючи офіційний HELM Chart, вона нам здалася сирою, і ми не знали, чи можемо покластися на це рішення, чи розвиватимуть його, чи швидко закинуть. Сама парадигма кластер = кліки в UI нам також не підходила, і ми не хотіли прив'язуватися до RKE, оскільки це досить вузьконаправлений інструмент.
Версія Rancher 2.2 вже мала більш працездатний вигляд і разом з попередніми мала купу цікавих можливостей з коробки таких, як інтеграція з багатьма зовнішніми провайдерами, єдина точка дистрибуції прав і kubeconfig файлів, запуск образу kubectl з твоїми правами в UI.
Також навколо Rancher 2 вже сформувалося комьюніті, і був створений провайдер HashiCorp Terraform для управління ним, який допоміг нам зібрати все докупи.
Що вийшло
У результаті у нас вийшов один маленький кластер, в якому запущений Rancher, доступний всім іншим кластерам, а також багато кластерів з ним пов'язаних, доступ до будь-якого з яких можна видати також просто, як додати користувача в каталог ldap незалежно від того, де він знаходиться і ресурси якого провайдера використовує.
За допомогою gitlab-ci та Terraform була створена система, що дозволяє створити кластер будь-якої конфігурації у хмарних провайдерах або нашій власній інфраструктурі та підключити їх до Rancher. Все це виконано в стилі IaC, де кожен кластер описаний репозиторієм, яке стан версіонується. При цьому більшість модулів підключаються із зовнішніх репозиторіїв так, що залишається лише передати змінні або описати свою кастомну конфігурацію для інстансів, що допомагає зменшити відсоток повторюваності коду.
Звичайно, наша подорож далеко не закінчена і попереду ще багато цікавих завдань таких як єдина точка роботи з логами та метриками будь-яких кластерів, service mesh, gitops для управління навантаженнями в мультикластері та багато іншого. Сподіваємось, вам буде цікавий наш досвід!
Статтю писали А. Антіпов, А. Гануш, Platform Engineers.
Джерело: habr.com