В кінці травня провели онлайн-мітап на тему . Поговорили про контейнери, Kubernetes та оркестрації у принципі, про критерії вибору інфраструктури та багато іншого. Учасники поділилися кейсами із власної практики.
Учасники:
- Євген Потапов, CEO «ITSumma». Більше половини його клієнтів або вже переходять або хочуть перейти на Kubernetes.
- Дмитро Столяров, CTO "Флант". Має 10+ років досвіду роботи з контейнерними системами.
- Денис Ремчуков (aka Eric Oldmann), COO argotech.io, ex-РАО ЄЕС. Пообіцяв розповісти про кейси у «кривавому» ентерпрайзі.
- Андрій Федоровський, CTO News360.comПісля покупки компанії іншим гравцем відповідає за ряд ML та AI проектів та за інфраструктуру.
- Іван Круглов, системний інженер, ex-Booking.com.Та сама людина, яка своїми руками зробила з Kubernetes дуже багато.
теми:
- Інсайти учасників про контейнери та оркестрацію (Docker, Kubernetes та інше); що пробували практично чи аналізували.
- Кейс: У компанії будують план розвитку інфраструктури на роки. Як ухвалюється рішення, будувати (або переводити поточну) інфраструктуру на контейнерах і Кубер чи ні?
- Проблеми у світі cloud-native, чого не вистачає, пофантазуємо, що буде завтра.
Почалася цікава дискусія, думки учасників виявилися настільки різними та викликали стільки коментарів, що хочеться поділитися ними з вами. Є , а нижче – вичавки з дискусії.
Kubernetes це вже стандарт чи відмінний маркетинг?
«Ми до нього (Kubernetes. – Ред.) прийшли тоді, коли про нього ще ніхто не знав. Ми прийшли до нього ще тоді, коли його не було. Ми його хотіли до цього». Дмитро Столяров
Фото з Reddit.com
Років 5-10 тому існувало безліч інструментів, і не було єдиного стандарту. Щопівроку з'являвся новий продукт, а то й не один. Спочатку Vagrant, потім Salt, Chef, Puppet, … «і ти кожні півроку перебудовуєш свою інфраструктуру. Ти маєш п'ять адмінів, які постійно зайняті тим, що переписують конфіги» — згадує Андрій Федоровський. Він вважає, що Docker та Kubernetes «задавили» решту. Docker став стандартом протягом останніх п'яти років, Kubernetes - останні два роки. І це добре для промисловості.
Дмитро Столяров та його команда люблять Кубер. Вони хотіли такий інструмент до того, як він з'явився, і прийшли до нього, коли про нього ще ніхто не знав. На даний момент, з міркувань зручності вони не беруть клієнта, якщо розуміють, що не впровадять у нього Kubernetes. При цьому, за словами Дмитра, у компанії «безліч гігантських success story з переробки страшного legacy».
Kubernetes – це не тільки контейнерна оркестрація, це система управління конфігурацією з розвиненим API, компонентом роботи з мережею, L3 балансуванням та Ingress контролерами, що дозволяє відносно легко керувати ресурсами, масштабуватись та абстрагуватися від нижніх шарів інфраструктури.
На жаль, у нашому житті за все треба платити. І цей податок великий, особливо якщо говорити про перехід на Kubernetes компанії з розвиненою інфраструктурою, вважає Іван Круглов. Він вільно міг би працювати як у компанії з традиційною інфраструктурою, так і з Кубером. Головне, розуміти особливості компанії та ринку. Але, наприклад, для Євгена Потапова, який би узагальнив Kubernetes до будь-якого інструменту оркестрації контейнерів, таке питання не стоїть.
Євген провів аналогію із ситуацією в 1990-х роках, коли з'явилося об'єктно-орієнтоване програмування як спосіб програмування складних додатків. На той момент не припинялися дебати та з'являлися нові інструменти, що підтримують ОВП. Потім з'явилися мікросервіси як спосіб уникнути монолітної концепції. Це, своєю чергою, призвело до появи контейнерів та інструментів їхнього управління. «Я думаю, що скоро ми прийдемо до того часу, коли не буде стояти питання про те, чи варто писати мікросервісно маленький додаток, його писатимуть дефолтом мікросервісом», — вважає він. Аналогічно, Docker та Kubernetes згодом стануть стандартним рішенням без необхідності вибору.
Проблема баз у stateless
Фото
В наш час знайдеться багато рецептів запуску баз даних у Kubernetes. Навіть як відокремлювати частину, що працює з диском I/O від, умовно, application - частини бази. Чи можливо, що в майбутньому бази даних видозміняться настільки, що будуть поставлятися в коробці, де одна частина буде оркеструватися через Docker і Kubernetes, а в іншій частині інфраструктури через окремий софт буде надаватися частина storage? Основи видозміняться як продукт?
Цей опис схожий на менеджмент черг, але вимоги до надійності та синхронності інформації в традиційних базах даних висуваються набагато вищими, вважає Андрій. Cache hit ratio у нормальних базах тримається на рівні 99%. Якщо worker лягає, запускається новий, і кеш розігрівається з нуля. Поки кеш не розігрітий, worker працює повільно, значить на нього не можна пускати навантаження користувача. Поки немає навантаження користувача, кеш не розігрівається. Це замкнуте коло.
Дмитро докорінно не згоден, — кворуми та шардування вирішують проблему. Але Андрій наполягає, що рішення підходить не всім. У деяких ситуаціях підійде кворум, але він дає додаткове навантаження на мережу. База NoSQL підходить не завжди.
Учасники мітапу розділилися на два табори.
Денис та Андрій стверджують, що все, що пише на диск — бази та інше, — у поточній екосистемі Кубера зробити неможливо. Неможливо зберегти цілісність та консистентність продуктивних даних у Kubernetes. Це є фундаментальна особливість. Рішення: гібридна інфраструктура.
Навіть сучасні cloud native бази, такі як MongoDB і Cassandra, або черги повідомлень, як Kafka або RabbitMQ, потребують постійних сховищ даних поза Kubernetes.
Євген заперечує: "Бази в Кубері - травма навколоросійська, або навколоентерпрайзна, яка пов'язана з тим, що в Росії Cloud Adoption немає". Малі або середні компанії на Заході – це Cloud. Бази Amazon RDS використовувати простіше, ніж самим возитися з Kubernetes. У Росії використовують Кубер "on-premise" і переносять у нього бази, коли намагаються позбутися зоопарку.
Дмитро теж не погодився із твердженням, що ніякі бази не можна тримати в Kubernetes: «База базі не відрізняється. І якщо пхати гігантську реляційну базу — то в жодному разі. Якщо пхати щось невелике і cloud native, що морально готове до напівефемерного життя, все буде добре. Дмитро згадав також, що інструменти управління базами не готові ні до Docker, ні Kuber, тому виникають великі складнощі.
Іван, у свою чергу, упевнений, що навіть якщо абстрагуватися від понять stateful і stateless, екосистема ентерпрайзних рішень у Kubernetes ще не готова. З Кубер складно підтримувати вимоги законодавчих і регулюючих органів. Наприклад, неможливо зробити рішення про надання identity, де потрібні суворі гарантії ідентифікації сервера, аж до заліза, яке вставляється в сервери. Ця сфера розвивається, але поки що рішення немає.
Учасникам не вдалося домовитися, тому в цій частині висновків не буде. Краще наведемо кілька практичних прикладів.
Кейс 1. Кібербезпека «мегарегулятора» з базами поза Кубером
У разі розвиненої системи кібербезпеки, використання контейнерів та оркестрації дозволяє відбиватися від атак та вторгнень. Наприклад, в одному мегарегуляторі Денис та його команда реалізували зв'язку оркестратора з навченим SIEM-сервісом, який аналізує логи в реальному часі та визначає процес атаки, злому чи збою. У разі атаки, спроби щось покласти, або при вторгненні вірусу-здирника, він через оркестратор піднімає контейнери з application'ами швидше, ніж вони заражаються, або швидше, ніж їх атакує зловмисник.
Кейс 2. Частковий переїзд баз даних Booking.com у Kubernetes
У Booking.com основна база даних – це MySQL з асинхронною реплікацією – є master та ціла ієрархія слейвів. До моменту відходу Івана з компанії було запущено проект із перенесення cлейвів, які можна «відстрілити» з певною шкодою.
Крім основної бази є інсталяція Cassandra з самописною оркестрацією, яку писали ще до того, як Кубер вийшов у мейнстрім. Проблем у цьому плані немає, але в неї persistent на локальних SSD. Віддалені сховища, навіть у рамках одного дата-центру, не використовуються через проблему з високою затримкою.
Третій клас баз даних — пошуковий сервіс Booking.com, де кожна нода сервісу є базою даних. Спроби перенести пошуковий сервіс у Кубер не вдалися, тому що кожна нода — це 60—80 Гб локального storage, яке складно «підняти» та «розігріти».
У результаті пошуковий двигун в Kubernetes не перенесли, і Іван не вважає, що будуть нові спроби найближчим часом. Базу MySQL було перенесено наполовину: лише Слейви, які не страшно «відстрілити». Cassandra «прижилася» добре.
Вибір інфраструктури як завдання без спільного вирішення
Фото
Припустимо, у нас є нова компанія або компанія, де частина інфраструктури побудована по-старому. У ній будують план розвитку інфраструктури на роки. Як ухвалюється рішення, будувати інфраструктуру на контейнерах і Кубер чи ні?
Компанії, які б'ються за наносекунди, виключені з дискусії. Здоровий консерватизм окупається з міркувань надійності, проте є компанії, яким варто розглянути нові підходи.
Іван: "Я б зараз, безумовно, стартував компанію в сloud, просто тому, що це швидше", хоча не обов'язково дешевше. З розвитком венчурного капіталізму стартапи з грошима великих проблем не мають, і основне завдання — завоювати ринок.
Іван дотримується погляду, що розвиненість поточної інфраструктури є критерієм вибору. Якщо минулого були серйозні вкладення, і це працює, то немає сенсу переробляти. Якщо ж інфраструктура не розвинена, і є проблеми з інструментами, безпекою та моніторингом, то є сенс подивитися на розподілену інфраструктуру.
Податок заплатити доведеться у будь-якому разі, і Іван платив би той, який дозволив йому в майбутньому платити менше. «Тому що просто за рахунок того, що я їду в поїзді, який рухають інші, я проїду набагато далі, ніж якщо сяду в інший поїзд, в який мені доведеться закидати паливо самому.»- Каже Іван. Коли компанія нова і вимоги до latency — десятки мілісекунд, то Іван дивився б у бік «операторів», у які сьогодні «загортають» класичні бази даних. Вони піднімають replication chain, котрий сам перемикається у випадку failover тощо…
Для маленької компанії з парою серверів у Кубері немає сенсу, — стверджує Андрій. Але якщо вона планує зрости до сотні серверів і більше, то потрібна автоматизація та система керування ресурсами. 90% випадків виправдовують витрати. Причому незалежно від рівня навантаження та ресурсів. Усім, починаючи від стартапів, закінчуючи великими компаніями з мільйонною аудиторією, має сенс поступово дивитися на продукти для оркестрації контейнерів. «Так, це справді майбутнє», — упевнений Андрій.
Денис окреслив два головні критерії. масштабованість та стійкість роботи. Він вибере ті інструменти, які найкраще підходять для цього завдання. Це може бути на коліні зібраний ноунейм, і на ньому Nutanix Community Edition. Це може бути друга лінія як application на Kuber з базою даних на бекенді, яка реплікується і має задані параметри RTO і RPO» (recovery time/point objectives — прим).
Євген окреслив можливу проблему з кадрами. На даний момент на ринку не так багато висококласних фахівців, які знаються на «кишках». Справді, якщо обрана технологія стара, то складно найняти когось, окрім немолодих людей, які нудьгують і втомилися. Хоча інші учасники вважають, що це питання підготовки кадрів.
Якщо поставити питання вибору: запускати невелику компанію в Public Cloud з базами в Amazon RDS або on premise з базами в Kubernetes, то незважаючи на деякі недоліки, вибором учасників став Amazon RDS.
Оскільки більшість слухачів мітапу не з «кривавого» ентерпрайзу, то розподілені рішення — це те, чого треба прагнути. Системи зберігання даних повинні бути розподіленими, надійними, і створювати latency, що вимірюються одиницями мілісекунд, максимум десятками, – резюмував Андрій.
Оцінка використання Kubernetes
Слухач Антон Жбанков поставив питання-західню апологетам Kubernetes: як обирали та проводили техніко-економічне обґрунтування? Чому Kubernetes, чому не віртуальні машини, наприклад?
Фото
На нього відповіли Дмитро та Іван. В обох випадках методом спроб і помилок, була зроблена послідовність рішень, в результаті якої обидва учасники прийшли до Kubernetes. Зараз бізнес починає самостійно розробляти софт, який має сенс переносити до Кубера. Не йдеться про класичні сторонні системи, типу 1С. Kubernetes допомагає, коли розробникам потрібно оперативно робити релізи, при безперервному Continuous Improvement.
Команда Андрія пробувала робити масштабований кластер на основі віртуальних машин. Ноди падали як доміно, що іноді спричиняло падіння кластера. «Теоретично можна доробити та підтримувати руками, але нудно. І якщо на ринку є рішення, яке дозволяє працювати із коробки, то ми із задоволенням йдемо до нього. І ми перейшли в результаті», — розповідає Андрій.
Стандарти для такого аналізу та розрахунку є, але ніхто не скаже, наскільки вони вірні на реальному залізі в експлуатації. Для розрахунків також важливо розбиратися в кожному інструменті та екосистемі, але це неможливо.
Що на нас чекає
Фото
Коли технології розвиваються, з'являється дедалі більше розрізнених шматочків, та був відбувається фазовий перехід, з'являється вендор, який убив достатньо «бабла», щоб усе з'єдналося разом у єдиному інструменті.
Чи не здається вам, що настане момент, коли з'явиться інструмент, яким стала Ubuntu для світу Linux? Можливо, єдиний інструмент контейнеризації та оркестрації включає і Кубер. З ним буде просто будувати on-premise хмари.
Відповідь дав Іван: «Google зараз будує Anthos — це їхня пакетна пропозиція, яка розгортає хмару і включає Kuber, Service Mesh, моніторинг, — всю обв'язку, яка потрібна для мікросервісів в «on-premise». Ми майже в майбутньому.
Денис також згадав Nutanix та VMWare з продуктом vRealize Suite, які можуть справлятися з подібним завданням без контейнеризації.
Дмитро поділився думкою, що зменшення «болю» та зниження податку — це два напрямки, де варто очікувати покращень.
Підсумовуючи дискусії, виділимо такі проблеми сучасної інфраструктури
- Відразу троє учасників окреслили проблему зі stateful.
- Різного роду проблеми підтримки безпеки, включаючи ймовірність того, що в результаті в Docker виявляться кілька версій Python, application-серверів і компонентів.
Перевитрата, про яку краще зробити окремий мітап.
Проблема навчання, оскільки оркестрація є складною екосистемою.
Загальна проблема галузі – використання інструментів не за призначенням.Інші висновки робити вам. Поки що залишається відчуття, що зв'язці Docker+Kubernetes непросто стати «центральною» частиною системи. Наприклад, операційні системи ставляться на залізницю першими, чого не можна сказати про контейнери та оркестрацію. Можливо, у майбутньому зростуться операційні системи та контейнери з cloud management софтом.
ФотоКористуючись нагодою, хочу передати привіт мамі нагадаю, що у нас є фейсбук-група. , канал з цікавими публікаціями із різних техно-блогів. І мій канал де я розповідаю про управління розробкою в продуктових компаніях.
Джерело: habr.com