В Напередодні Віталій Хабаров взяв інтерв'ю у Дмитра Столярова (), технічного директора та співзасновника компанії «Флант». Віталій розпитав Дмитра про те, чим займається «Флант», про Kubernetes, розвиток екосистеми, підтримку. Обговорили, навіщо потрібний Kubernetes і чи потрібний взагалі. А ще про мікросервіси, Amazon AWS, підхід «Мені пощастить» у DevOps, майбутнє самого Kubernetes, чому, коли і як він захопить світ, перспективи DevOps і до чого готуватися інженерам у світлому та близькому майбутньому зі спрощенням та нейромережами.
у вигляді подкасту послухайте на DevOps Дефлопі - російськомовному подкасті про DevOps, а нижче - текстова версія.
Тут і далі запитання ставить інженер з Express42.
Про «Флант»
- Діма, привіт. Ти - технічний директорі його засновник. Розкажи, будь ласка, чим займається компанія, і ти в ній?
Дмитро: Зовні здається, ніби ми такі хлопці, які ходять, усім ставлять Kubernetes і щось із ним роблять Але це не так. Ми починали як компанія, яка займається Linux, але вже дуже давно основна наша діяльність — обслуговування продакшн та highload-проектів під ключ. Зазвичай ми будуємо всю інфраструктуру з нуля і потім довго за неї відповідаємо. Тому основна робота, яку виконує «Флант», за що й отримує гроші, — це взяття відповідальності та реалізація продакшн під ключ.
Я, як технічний директор і один із засновників компанії, цілодобово займаюся тим, що вигадую, як би підвищити доступність продакшн, спростити його експлуатацію, полегшити життя адмінів, а життя розробників зробити приємнішим.
Про Kubernetes
— Останнім часом від «Фланту» бачу багато доповідей та про Kubernetes. Як ви прийшли до нього?
Дмитро: Я вже розповідав про це багато разів, але мені зовсім не шкода повторити Вважаю, що правильно повторювати цю тему, бо виникає плутанина між причиною та наслідком.
Нам дуже потрібний був інструмент. Ми стикалися з купою проблем, боролися, долали їх різними милицями і відчували потребу в інструменті. Перебирали багато різних варіантів, будували велосипеди, накопичували досвід. Поступово дійшли до того, що почали використовувати Docker майже відразу, як він з'явився приблизно в 2013 році. У момент його появи у нас вже було багато досвіду з контейнерами, ми вже написали аналог Docker - якісь свої милиці на Python. З появою Docker з'явилася можливість милиці викинути і використовувати надійне та підтримуване співтовариством рішення.
З Kubernetes історія аналогічна. До моменту, коли він почав набирати обертів, - для нас це версія 1.2, - у нас вже була купа милиць і на Shell, і на Chef, які ми намагалися оркеструвати Docker. Ми серйозно дивилися в бік Rancher і різних інших рішень, але тут з'явився Kubernetes, в якому все реалізовано так, як зробили б ми або навіть краще. Причепитися нема до чого.
Так, тут є якась недоробка, там якась недоробка — багато недоробок, а 1.2 взагалі жах, але….Kubernetes як будівля, що будується — дивишся на проект і розумієш, що це буде круто. Якщо будівля зараз має фундамент і два поверхи, то розумієш, що краще поки що не заселятися, а з софтом таких проблем немає — користуватися вже можна.
Ми не мали моменту, що ми думали використовувати Kubernetes чи ні. Ми на нього чекали задовго до того, як він з'явився, і намагалися самі городити аналоги.
Біля Kubernetes
— Ви берете участь безпосередньо в розробці самого Kubernetes?
Дмитро: Середньо. Швидше беремо участь у розвитку екосистеми. Ми відправляємо певну кількість pull requests: у Prometheus, у всякі оператори, в Helm — в екосистему. На жаль, я не можу стежити за всім, що ми робимо і можу помилятися, але від нас немає жодного пулу в ядро.
— При цьому ви розробляєте багато своїх інструментів навколо Kubernetes?
Дмитро: Стратегія така: ми йдемо і пулл-реквестимо у все, що вже є Якщо там не приймаються pull requests, ми просто форкаємо їх собі і живемо, поки вони не прийняті з нашими білдами. Потім, коли це долітає до upstream, ми повертаємося назад на upstream'ову версію.
Наприклад, у нас є Prometheus-оператор, з яким ми туди-сюди перемикалися на upstream нашої збірки вже разів 5, мабуть. Нам потрібна якась фіча, ми надіслали pull request, нам треба її завтра викотити, а чекати, поки її релізнуть в upstream, не хочемо. Відповідно, ми збираємо собі, котимо нашу збірку з нашою фічею, яка нам навіщось потрібна, на всі свої кластери. Потім це, наприклад, у upstream нам загортають зі словами: «Хлопці, давайте, зробимо для більш загального випадку», ми, чи хтось інший, це доробляємо, і згодом знову зливається.
Все, що існує, ми намагаємося розвивати. Багато елементів, яких ще немає, ще не придумали чи придумали, але не встигли реалізувати ми робимо. І не тому, що нам подобається сам процес чи велосипедобудування як галузь, а просто тому, що нам потрібний цей інструмент. Часто запитують, навіщо ми зробили ту чи іншу річ? Відповідь проста – та тому, що нам треба було йти далі, вирішити якусь практичну проблему, і ми її вирішили цією тулою.
Шлях завжди такий: ми дуже ретельно шукаємо і, якщо не знаходимо жодного рішення, як із буханця хліба зробити тролейбус, то робимо свій буханець і свій тролейбус.
Інструменти «Фланту»
— Мені відомо, що зараз «Флант» має addon-операторів, shell-операторів, інструментів dapp/werf. Як я розумію, це той самий інструмент у різних інкарнаціях. Також я розумію, що всередині «Фланту» є ще багато різних інструментів. Це так?
Дмитро: У нас на GitHub ще багато чого є З того, що я зараз згадаю, ми маємо statusmap — панель для Grafana, яка зайшла всім. Вона згадується майже в кожній другій статті про моніторинг Kubernetes на Медіум. Неможливо коротко розповісти, що таке statusmap — потрібна окрема стаття, але це дуже корисна річ для моніторингу статусу в часі, тому що в Kubernetes часто нам потрібно показувати статус у часі. Ще у нас є LogHouse – це штука на базі ClickHouse та чорної магії для збирання логів у Kubernetes.
Багато утиліт! І буде ще більше, тому що деяка кількість внутрішніх рішень релізуватиметься цього року. З дуже великих на базі addon-оператора є купа addons до Kubernetes аля як правильно поставити sert manager - інструмент для управління сертифікатами, як правильно поставити Prometheus з купою обважування - це штук двадцять різних бінарників, які експортують дані і щось збирають, до цього Prometheus шикарна графіка та алерти. Все це просто купа addons до Kubernetes, які ставляться в кластер, і він перетворюється з простого на крутий, наворочений, автоматичний, в якому багато питань вже вирішено. Так, багато що робимо.
Розвиток екосистеми
— Мені здається, це дуже великий внесок у розвиток цього інструменту та його методів використання. Чи можеш ти приблизно прикинути, хто б ще зробив такий самий внесок у розвиток екосистеми?
Дмитро: У Росії з тих компаній, які діють на нашому ринку, ніхто й близько. Звичайно, це гучна заява, бо є великі гравці, як Mail з Яндексом — вони теж щось роблять з Kubernetes, але навіть вони не підібралися до вкладу компаній загалом у світ, які роблять набагато більше, ніж ми. Складно порівнювати «Флант» зі штатом у 80 осіб та Red Hat, у якому лише на один Kubernetes 300 інженерів, якщо не помиляюся. Важко порівнювати. У нас у відділі RnD 6 чоловік включаючи мене, які пиляють усі наші туловища. 6 осіб проти 300 інженерів Red Hat якось складно порівнювати.
— Тим не менш, коли навіть ці 6 осіб можуть зробити щось справді корисне та відчужуване, коли вони стикаються із практичним завданням і віддають рішення до спільноти — цікавий кейс. Розумію, що у великих технологічних компаніях, де є своя розробка та команда підтримки Kubernetes, у принципі можуть розроблятися такі ж тули. Це для них приклад, який можна розробити і віддати до спільноти, дати поштовх усьому співтовариству, яке використовує Kubernetes.
Дмитро: Напевно, це фішка інтегратора, його особливість У нас багато проектів і ми бачимо багато різних ситуацій. Для нас основний спосіб створення доданої вартості – це проаналізувати ці кейси, знайти спільне та максимально здешевити їх для нас. Цим ми активно займаємось. Мені складно говорити про Росію та світ, але у нас приблизно 40 DevOps-інженерів у компанії, які займаються Kubernetes. Я не думаю, що в Росії багато компаній з порівнянною кількістю фахівців, які розуміються на Kubernetes, якщо вони взагалі є.
Я розумію все про назву посади DevOps-інженер, усі все розуміють і звикли називати DevOps-інженерів DevOps-інженерами, ми не обговорюватимемо це. Всі ці 40 чудових DevOps-інженерів щодня стикаються з проблемами та вирішують їх, ми просто аналізуємо цей досвід та намагаємось узагальнити. Ми розуміємо, що якщо він залишиться у нас усередині, то через рік чи два інструменти непотрібні, тому що десь у community з'явиться готова тула. Немає сенсу накопичувати цей досвід усередині – це просто злив сил та часу в dev/null. А так нам зовсім не шкода. Ми з великим задоволенням все публікуємо та розуміємо, що це треба публікувати, розвивати, піарити, розкручувати, щоб люди користувалися та додавали свій досвід – тоді все росте та живе. Тоді через два роки інструмент не йде на смітник. Не шкода продовжувати вливати сили, бо видно, що твоїм інструментом хтось користується, а за два роки ним користуються вже всі.
Це частина нашої великої стратегії з dapp/werf. Не пам'ятаю, коли ми почали його робити, здається, 3 роки тому. Спочатку він був узагалі на shell. Це був супер proof of concept, ми вирішили якісь наші приватні завдання – вийшло! Але з shell там проблеми, далі це нарощувати неможливо, програмувати на shell — ще заняття. У нас була звичка писати на Ruby, відповідно, на Ruby ми щось переробили, розвивали, розвивали, розвивали, і вперлися в те, що community, натовп, який не каже «ми хочемо чи не хочемо», верне носа від Ruby, як це не смішно. Зрозуміли, що повинні все це добро писати на Go, щоби просто відповідати першому пункту в чек-листі: DevOps-тула має бути статичним бінарником. На Go чи не Go не так важливо, але краще статичний бінарник, написаний на Go.
Витратили сили, переписали dapp на Go та назвали його werf. Dapp більше не підтримується, не розвивається, працює в якійсь останній версії, але є абсолютний upgrade-шлях нагору, і йому можна наслідувати.
Навіщо створювався dapp
— Можеш коротко розповісти, навіщо створювався dapp, які проблеми він вирішує?
Дмитро: Перша причина у складанні Спочатку ми мали сильні проблеми зі збіркою, коли Docker не вмів multi-stage, і ми зробили multi-stage самотужки. Потім у нас була ще купа питань із очищенням image. Всі, хто роблять CI/CD, швидше за раніше, ніж пізніше, стикаються з проблемою, що є купа зібраних images, потрібно якось вичищати те, що не потрібно, і залишати те, що потрібно.
Друга причина у деплої. Так, є Helm, але він вирішує лише частину завдань. Як не смішно, написано, що Helm - the Package Manager for Kubernetes. Саме «the». Ще є слова "Package Manager" - яке очікування зазвичай від Package Manager? Ми говоримо: "Package Manager - постав пакет!" і очікуємо, що він скаже: «Пакет поставлений».
Цікаво, що ми говоримо: "Helm, постав пакет", а коли він відповідає, що поставив, то з'ясовується, що він тільки почав установку - вказав Kubernetes: "От цю штуку запусти!", А запустилася вона чи ні, працює чи ні , Helm це питання взагалі не вирішує.
Виходить, що Helm — це просто текстовий препроцесор, який завантажує дані в Kubernetes.
Але ми в рамках будь-якого деплою хочемо знати — додаток викотився на прод чи ні? Викотилося на прод означає, що програма туди виїхала, розгорнулася нова версія розгорнулася, і вона там хоча б не падає і коректно відповідає. Helm це завдання ніяк не вирішує. Щоб її вирішити, треба витратити багато сил, тому що необхідно віддати Kubernetes команду викочувати і стежити за тим, що там відбувається — чи розвернулося воно, чи викотилося. А ще є купа завдань, пов'язаних із деплом, з очищенням, зі збиранням.
Плани
Ще цього року ми підемо у локальну розробку. Ми хочемо прийти до того, що раніше було в Vagrant — набрали vagrant up і у нас розгорнулися віртуалки. Ми хочемо прийти до такого стану, що є проект у Git, ми там пишемо «werf up», і він піднімає локальну копію цього проекту, розгорнуту в локальному міні-Kub, з усіма підключеними директоріями, зручними для розробки. Залежно від мови розробки це виконується по-різному, проте, щоб можна було зручно вести локальну розробку під монтованими файлами.
Наступний крок для нас – сильно вкладатися у зручність для розробників. Щоб одним інструментом швидко локально розгорнути проект, подевелопіті, пушнуть в Git, і він точно також викотиться на stage або на тести, залежно від пайплайнов, і потім тим самим інструментом поїхати на прод. Це єдність, уніфікація, відтворюваність інфраструктури від локального оточення до продажу для нас дуже важливий момент. Але цього поки що немає в werf – тільки плануємо робити.
Але шлях dapp/werf завжди був такий же, як з Kubernetes на початку. Ми стикалися з проблемами, вирішували їх обхідними шляхами – вигадували для себе якісь рішення на shell, на чому завгодно. Потім ці обхідні шляхи намагалися якось спрямувати, узагальнити та консолідувати у бінарники у разі, якими просто ділимося.
Є ще інший погляд на всю цю історію з аналогіями.
Kubernetes - це каркас автомобіля з двигуном. Немає дверей, шибок, радіоприймача, ялинки — взагалі нічого немає. Тільки рама та двигун. І є Helm – це кермо. Класно - кермо є, але потрібні ще кермовий штифт, рульова рейка, КПП та колеса, а без них ніяк.
У випадку з werf це ще один компонент до Kubernetes. Тільки зараз у нас в альфа-версії werf, наприклад, Helm вкомпилюється взагалі всередину werf, тому що нам набридло це робити самим. Багато причин так робити, докладно про те, навіщо ми зібрали helm повністю разом з tiller всередину werf, я розповім тільки .
Зараз werf – це більш вбудований компонент. У нас виходить готове кермо, кермовий штифт — я не дуже добре в автомобілях знаюся, але це великий блок, який вирішує досить великий спектр завдань. Нам не потрібно самим лазити каталогом, підбирати одну деталь до іншої, думати, як їх прикрутити один до одного. Ми отримуємо готовий комбайн, який вирішує одразу велику пачку завдань. Але всередині він влаштований все з тих же опенсорсних компонентів, все також використовує Docker для збирання, Helm для частини функціоналу, і є ще кілька інших бібліотек. Це інтегрований інструмент, щоб отримати швидко та зручно крутий CI/CD з коробки.
Чи важко підтримувати Kubernetes?
— Ти розповідаєш про досвід, що почали використовувати Kubernetes, це для вас рама, двигун, і що на нього можна багато чого різного навісити: корпус, кермо, прикрутити педальки, сидіння. Виникає питання – наскільки складно вам надається підтримка Kubernetes? У вас багатий досвід, скільки у вас йде часу та ресурсів саме на підтримку Kubernetes у відриві від решти?
Дмитро: Це дуже складне питання і щоб відповісти, треба зрозуміти, що таке підтримка, і що ми хочемо від Kubernetes Може, ти розкриєш?
— Наскільки мені відомо і як я бачу зараз багато команд хочуть спробувати Kubernetes. Усі в нього впрягаються, ставлять навколішки. Я маю відчуття, що люди не завжди розуміють складність цієї системи.
Дмитро: Все так.
— Наскільки складно взяти та поставити Kubernetes з нічого, щоб це було production ready?
Дмитро: Як думаєш, наскільки складно пересадити серце? Розумію, питання компрометуюче. Возити скальпелем і не помилитися це не так складно. Якщо тобі кажуть десь відрізати, а десь зашити, то сама по собі процедура нескладна. Складно гарантувати щоразу, що все вийде.
Поставити Kubernetes і змусити працювати просто: чик! - Поставився, є купа способів інсталяції. Але що буде, коли виникнуть проблеми?
Завжди постають питання - що ми ще не врахували? Що ми ще не зробили? Які параметри Linux-ядра вказали неправильно? Господи, а ми взагалі їх вказували? Які компоненти Kubernetes ми встановили, а які ні? Виникають тисячі питань, і щоб відповісти на них, потрібно 15-20 років варитись у цій індустрії.
У мене є свіжий приклад на цю тему, який може розкрити сенс проблеми «Чи важко підтримувати Kubernetes?». Деякий час тому ми серйозно розглядали чи не спробувати нам впровадити Cilium як мережа у Kubernetes.
Поясню, що таке Cilium. У Kubernetes є багато різних реалізацій мережевої підсистеми, і одна з них дуже крута – це Cilium. У чому її зміст? В ядрі деякий час тому з'явилася можливість писати хуки для ядра, які так чи інакше вторгаються в мережеву підсистему та різні інші підсистеми, і дозволяють обійти великі шматки в ядрі.
У Linux-ядрі є історично ip rout, надфільтр, бриджі і багато різних старих компонентів, яким по 15, 20 30 років. Загалом вони працюють, все класно, але зараз нагородили контейнерів, і це виглядає як вежа з 15 цегли один на одному, а ти стоїш на ній на одній нозі — дивне відчуття. Ця система історично розвивалася з безліччю нюансів, як апендикс в організмі. У деяких ситуаціях є проблеми з performance, наприклад.
Є чудовий BPF та можливість писати хуки для ядра – хлопці написали свої хуки для ядра. Пакет приходить в Linux-ядро, вони його прямо на вході виймають, обробляють самі як треба без бриджів, без TCP, без IP-стека - коротше, в обхід всього, що написано в Linux-ядрі, і відразу випльовують в контейнер.
Що вийшло? Дуже крутий performance, круті фічі просто класно! Але ми дивимося на це і бачимо, що на кожній машині стоїть прога, яка підключається до API Kubernetes і за даними, які отримує з цього API, генерує C-код і компіліт бінарники, які завантажують у ядро, щоб у kernel space ці хуки працювали .
Що буде, якщо щось піде не так? Ми не знаємо. Щоб це зрозуміти, треба прочитати весь цей код, зрозуміти всю логіку, а це очманіти, як складно. Але, з іншого боку, є ці бриджі, net-фільтри, ip rout — я не читав їхніх вихідників, і 40 інженерів, які працюють у нашій компанії теж. Можливо, якісь шматки розуміють одиниці.
І яка різниця? Виходить, що є ip rout, ядро Linux і є новий інструмент — яка різниця, ми жодну, ні іншу не розуміємо. Але боїмося використати нове – чому? Бо якщо інструменту 30 років, то за 30 років усі баги знайшли, на всі граблі настали і знати про все не потрібно — працює, як чорна скринька, і працює завжди. Всі знають, яку діагностичну викрутку в яке місце встромити, який tcpdump коли запустити. Всі добре знають діагностичні утиліти та розуміють, як цей набір компонентів працює в ядрі Linux — не як він влаштований, а як ним користуватися.
А офігенно класному Cilium не 30 років, він ще не витриманий. З Kubernetes така ж проблема, копія. Що Cilium ставиться чудово, що Kubernetes ставиться чудово, але коли щось не так піде в проді, чи здатні ви в критичній ситуації швидко зрозуміти, що пішло не так?
Коли ми говоримо, чи складно підтримувати Kubernetes — ні дуже просто, і так, неймовірно складно. Kubernetes чудово працює сам по собі, але з мільярдом нюансів.
Про підхід «Мені пощастить»
— Чи є компанії, де ці нюанси майже гарантовано з'являться? Припустимо, Яндекс раптом поголовно переведе всі сервіси на Kubernetes, там буде якесь навантаження.
Дмитро: Ні, це ж розмова не про навантаження, а про найпростіші речі Наприклад, є у нас Kubernetes, ми задеплоїли туди програму. Як зрозуміти, що воно працює? Готового інструменту, щоб зрозуміти, що програма не падає, просто немає. Готової системи, яка шле алерти — ні, треба налаштувати ці алерти і кожен графік. А ми ось оновлюємо Kubernetes.
Є Ubuntu 16.04. Можна сказати, що це стара версія, але ми все ще на ній, тому що там LTS. Там є systemd, нюанс якого полягає в тому, що він не чистить C-групи. Kubernetes запускає поди, створює C-групи, потім піди видаляє, і якось так виходить - я не пам'ятаю деталей, вибачте, що залишаються слайси systemd. Це призводить до того, що згодом будь-яка машина починає сильно гальмувати. Це навіть питання не про високуload. Якщо запускаються постійні поди, наприклад, якщо є Cron Job, який постійно генерує поди, машина з Ubuntu 16.04 через тиждень почне гальмувати. Там буде постійно високий load average через те, що створено купу C-груп. Це проблема, з якою стикається будь-яка людина, яка просто поставить Ubuntu 16 та зверху Kubernetes.
Припустимо, він якось оновить systemd або ще щось, але в ядрі Linux до 4.16 ще смішніше - при видаленні C-груп вони в ядрі підтікають і фактично не видаляються. Тому через місяць роботи на цій машині неможливо буде подивитися статистику з пам'яті за подами. Ми дістаємо файлик, катаємо в прозі, і один файлик катається 15 секунд, тому що ядро дуже довго вважає в собі по мільйону C-груп, які начебто видалені, але ні - вони підтікають.
Таких дрібниць досі дуже багато там і тут. Це не питання, з яким компанії-гіганти можуть іноді зіткнутися за дуже великих навантажень — ні, це питання щоденних речей. Люди можуть місяцями так жити – поставили Kubernetes, задеплоїли додаток – начебто працює. Багатьом так нормально. Про те, що колись ця програма чомусь впаде, вони навіть не дізнаються, алерт не прийде, але для них це норма. Раніше жили на віртуалках без моніторингу, зараз переїхали до Kubernetes також без моніторингу — яка різниця?
Питання в тому, що коли ми ходимо льодом, ніколи не знаємо його товщину, якщо не виміряли заздалегідь. Багато хто ходить і не париться, бо й раніше ходив.
На мій погляд, нюанс та складність експлуатації будь-якої системи в тому, щоб гарантувати, що товщини льоду точно вистачить, щоб вирішити наші завдання. Мова про це.
В ІТ, мені здається, надто багато підходів «Мені пощастить». Багато хто ставить софт, використовують програмні бібліотеки в надії, що їм пощастить. Загалом щастить багатьом. Напевно, тому це і працює.
— З моєї песимістичної оцінки це виглядає так: коли ризики великі, а програма має працювати, то потрібна підтримка від «Фланту», можливо, від Red Hat, або потрібна своя внутрішня команда, виділена саме на Kubernetes, яка готова його тягнути.
Дмитро: Об'єктивно це так Влазити самостійно в історію з Kubernetes невеликою командою - це кілька ризиків.
Чи потрібні нам контейнери?
— Чи можеш розповісти, наскільки Kubernetes взагалі поширений у Росії?
Дмитро: У мене немає цих даних, і я не впевнений, що вони є взагалі у будь-кого Ми говоримо: «Kubernetes, Kubernetes», а є інший погляд на це питання. Наскільки поширеними є контейнери, я теж не знаю, але знаю цифру зі звітів в інтернеті, що 70% контейнерів оркеструє Kubernetes. Це було достовірне джерело з досить великої вибірки у світі.
Далі інше питання — чи нам потрібні контейнери? У мене особисте відчуття і загалом позиція компанії «Флант» така, що Kubernetes – це стандарт де-факто.
Нічого, крім Kubernetes, не буде.
Це абсолютний game-changer у сфері управління інфраструктурою. Просто абсолютний - все більше ніяких Ansible, Chef, віртуальних машин, Terraform. Я вже не говорю про старі колгоспні методи. Kubernetes - це абсолютний changerі тепер буде тільки так.
Зрозуміло, що комусь потрібно кілька років, а комусь кілька десятків, щоб це усвідомити. У мене немає сумнівів, що не буде нічого, окрім Kubernetes і цього нового погляду: більше ми не поранимо операційну систему, а використовуємо infrastructure as code, Тільки не з кодом, а з yml - декларативно описану інфраструктуру. Я відчуваю, що так буде завжди.
— Тобто ті компанії, що ще не перейшли на Kubernetes, обов'язково перейдуть на нього або залишаться в забутті. Я правильно тебе зрозумів?
Дмитро: Це теж не зовсім правильно Наприклад, якщо у нас стоїть завдання запустити dns-сервер, його можна запустити на FreeBSD 4.10 і він може 20 років чудово працювати. Просто працювати і все. Можливо, за 20 років потрібно щось оновити один раз. Якщо ми говоримо про софт у форматі, що ми запустили, і він реально багато років працює без якихось оновлень, без внесення змін, то, звичайно, там не буде Kubernetes. Він там не потрібний.
Все, що стосується CI/CD - скрізь, де потрібен Continuous Delivery, де потрібно оновлювати версії, вести активні зміни, скрізь, де необхідно побудувати стійкість до відмови - тільки Kubernetes.
Про мікросервіси
— Тут у мене з'являється невеликий дисонанс. Щоб працювати з Kubernetes, потрібна зовнішня чи внутрішня підтримка – це перший момент. Другий — коли ми тільки-но починаємо розробку, ми маленький стартап, у нас ще нічого немає, розробка під Kubernetes або взагалі під мікросервісну архітектуру може бути складною, і не завжди виправдана економічно. Мені цікава твоя думка — чи потрібно стартапам з нуля одразу починати писати під Kubernetes чи можна таки написати моноліт, і потім тільки прийти до Kubernetes?
Дмитро: Круте питання У мене є доповідь про мікросервіси Я багато разів стикався з тим, що люди намагаються мікроскопом забивати цвяхи. Сам по собі правильний підхід, ми самі внутрішній софт проектуємо саме цим шляхом. Але коли це робиш, треба чітко розуміти, що ти робиш. Найбільше в мікросервісах я ненавиджу слово мікро. Історично склалося, що там виникло це слово, і чомусь люди думають, що мікро — це дуже маленький, менший за міліметр, як мікрометр. Це не так.
Наприклад, є моноліт, який пишуть 300 осіб, і всі, хто брав участь у розробці, розуміють, що там є проблеми, і його треба було б розбити на мікро-шматочки — штук на 10, кожен із яких пишуть 30 осіб у мінімальному варіанті. Це важливо, потрібне і класно. Але коли до нас приходить стартап, де 3 дуже крутих та талановитих пацана написали на коліні 60 мікросервісів, щоразу я шукаю корвалол.
Мені здається, про це вже говорили тисячі разів — отримали розподілений моноліт у тій чи іншій іпостасі. Це економічно не виправдано, дуже складно загалом у всьому. Просто я це стільки разів бачив, що мені аж боляче, тому я продовжую про це говорити.
До початкового питання, що є конфлікт між тим, що, з одного боку, Kubernetes страшно використати, бо незрозуміло, що там може зламатися чи не заробити, з іншого боку, зрозуміло, що все йде туди і нічого, крім Kubernetes, не буде . Відповідь зважувати обсяг користі, що надходить, обсяг завдань, який ви можете вирішити. Це з одного боку терезів. З іншого боку — ризики, пов'язані з простоєм чи зниженням часу відгуку, рівня доступності — зі зниженням показників роботи.
Тут так або нам швидко рухатися, і Kubernetes дозволяє багато речей виконувати набагато швидше і краще, або використовувати надійні, перевірені часом рішення, але рухатися набагато повільніше. Цей вибір має робити кожна компанія. Можна розглядати це як доріжку в джунглях — коли йдеш перший раз, можна зустріти змію, тигра чи шаленого борсука, а коли сходив 10 разів — протоптав стежку, прибрав гілки і легше ходити. Щоразу стежка ширша. Потім це вже асфальтована дорога, а згодом гарний бульвар.
Kubernetes не стоїть на місці. Знову питання: Kubernetes, з одного боку, це 4-5 бінарників, з іншого – це вся екосистема. Це операційна система, яка у нас стоїть на машинах. Що це? Ubuntu чи Curios? Це ядро Linux, купа додаткових компонентів. Всі ці штуки тут одну отруйну змію викинули з дороги, там паркан поставили. Kubernetes дуже швидко і динамічно розвивається, і обсяг ризиків, обсяг незвіданого з кожним місяцем зменшується і, відповідно, ці ваги перебалансуються.
Відповідаючи на запитання, що робити стартапу, я сказав би — приходьте до «Фланту», платіть 150 тисяч рублів і отримуйте під ключ DevOps easy service. Якщо ви невеликий стартап в кілька розробників це працює. Замість того, щоб наймати свого DevOps, якому потрібно буде вчитися вирішувати ваші проблеми та платити у цей час зарплату, ви отримаєте вирішення всіх питань під ключ. Так, є деякі мінуси. Ми, як аутсорсер, не можемо бути так залучені та швидко реагувати на внесення змін. Зате у нас купа експертизи, готові практики. Ми гарантуємо, що в будь-якій ситуації ми точно розберемося і піднімемо з того світу будь-який Kubernetes.
Я категорично рекомендую аутсорсинг стартапам і бізнесу, що склався до розміру, коли ви можете виділяти на експлуатацію команду з 10 осіб, тому що інакше немає сенсу. Це категорично має сенс аутсорсити.
Про Amazon та Google
— Чи можна розглядати як аутсорс хост від рішення від Amazon чи Google?
Дмитро: Так, звичайно, це вирішує кілька питань Але знову нюанси. Все одно треба розуміти, як це використати. Наприклад, є тисяча дрібниць у роботі Amazon AWS: Load Balancer треба прогрівати або заздалегідь писати заявку, що «хлопці, нам прийде трафік, прогрійте нам Load Balancer!» Ці нюанси треба знати.
Коли ви звертаєтеся до людей, які спеціалізуються на цьому, ви отримуєте майже всі типові речі закритими. У нас зараз 40 інженерів, до кінця року їх, напевно, буде 60 — ми з усіма цими речами стикалися. Навіть якщо на якомусь проекті ми ще раз стикаємося з цією проблемою, ми вже швидко питаємо один одного і знаємо, як вирішити.
Напевно, відповідь така - звичайно, hosted-історія полегшує якусь частину. Питання в тому, чи готові ви довіряти цим хостерам, і чи вирішать ваші проблеми. Amazon та Google зарекомендували себе добре. Для всіх наших кейсів точно. Більше ми жодних позитивних дослідів не маємо. Решта clouds, з якими ми намагалися працювати, створюють дуже багато проблем — і Ager, і все, що є в Росії, і всілякі OpenStack у різних реалізаціях: Headster, Overage — все, що хочете. Вони усі створюють проблеми, які не хочеться вирішувати.
Тому відповідь - так, але, за фактом, зрілих hosted-рішень не дуже багато.
Кому потрібний Kubernetes?
— І все-таки, кому потрібний Kubernetes? Хто вже повинен переходити на Kubernetes, хто типовий клієнт «Фланта», який приходить саме за Kubernetes?
Дмитро: Питання цікаве, тому що зараз якраз на хвилі Kubernetes до нас багато хто приходить: «Хлопці, ми знаємо, що ви робите Kubernetes, зробіть нам!». Ми їм відповідаємо: «Пане, ми не робимо Kubernetes, ми робимо прод і все, що з ним пов'язане». Тому що зробити прод, не зробивши весь CI/CD і всю цю історію, зараз просто неможливо. Всі уникнули поділу, що у нас розробка розробкою, а потім експлуатація експлуатацією.
Наші клієнти чекають на різне, але всі чекають деякого доброго дива, що у них є ті чи інші проблеми, а зараз — хоп! — Kubernetes їх вирішить. Люди вірять у дива. Розумом розуміють, що дива не буде, але душею сподіваються, а раптом цей Kubernetes зараз нам все вирішить, про нього стільки говорять! Раптом він зараз – чих! - І срібна куля, чих! — і у нас 100% uptime, всі розробники можуть по 50 разів релізувати будь-що, і воно не падає. Загалом, диво!
Коли такі люди до нас приходять, ми говоримо: «Вибачте, але дива не буває». Щоб бути здоровим, потрібно добре харчуватися та займатися спортом. Щоб мати надійний продукт, його потрібно зробити надійно. Щоб мати зручний CI/CD, потрібно зробити таким. Це багато роботи, яку потрібно робити.
Відповідаючи на запитання, кому потрібний Kubernetes – Kubernetes не потрібний нікому.
Деякі люди мають помилкове відчуття, що їм потрібен Kubernetes. Людям потрібно, у них просто глибока потреба перестати думати, займатися, цікавитися взагалі всіма проблемами інфраструктури та проблемами запуску їхніх додатків. Вони хочуть, щоб програми просто працювали і просто деплоїлися. Для них Kubernetes — це надія, що вони перестануть чути історію, що ми там валялися, або не можемо викотитися, або ще щось.
До нас зазвичай приходить технічний директор. З нього запитують дві речі: з одного боку, давай нам фічі, а з іншого боку — стабільність. Ми пропонуємо взяти це на себе та зробити. Срібна куля, точніше, срібна, в тому, що ти перестанеш думати про ці проблеми і витрачати час. У тебе будуть спеціальні люди, які закриють це питання.
Формулювання, що нам чи комусь потрібний Kubernetes – неправильне.
Kubernetes дуже потрібний адмінам, тому що це ж дуже цікава іграшка, з якою можна пограти, поколупатися. Давайте будемо чесні – усі люблять іграшки. Усі ми десь діти, і коли ми бачимо нову — хочемо пограти в неї. У когось це відбито, наприклад, в адмінстві, бо вже награлися і вже набридло до того, що просто не хочеться. Але ж це не відбито ні в кого повністю. Наприклад, якщо мені іграшки в галузі системного адміністрування і DevOps вже давно набридли, то іграшки я все одно люблю, якісь нові все одно купую. Всі люди так чи інакше однаково хочуть якісь іграшки.
Не треба грати з продакшном. Що б я категорично не рекомендував робити і що зараз бачу масово: «А, нова іграшка!» - побігли її купувати, купили і: "Давайте її зараз візьмемо до школи, покажемо всім друзям". Не робіть так. Перепрошую, у мене просто діти ростуть, я постійно бачу щось у дітях, помічаю це в собі, і потім ще узагальнюю на інших.
Остаточна відповідь: не потрібно вам Kubernetes. Ви повинні вирішити ваші проблеми.
Домогтися можна того, що:
- прод не падає;
- навіть якщо він намагається впасти, ми знаємо про це заздалегідь, і можемо щось підкласти;
- ми можемо його змінювати з тією швидкістю, з якою нам потрібно бізнес, і робити це зручно, нам це не викликає проблем.
Реальних потреб дві: надійність і динамічність / гнучкість викочування. Усім, хто зараз робить якісь IT-проекти, не має значення, в якомусь бізнесі — soft for easing the world, і хто це розуміє, потрібно вирішити ці потреби. Kubernetes з правильним підходом, з правильним розумінням та достатнім досвідом дозволяє їх вирішувати.
Про serverless
— Якщо подивитись трохи подалі в майбутнє, то намагаючись вирішити проблему відсутності головного болю з інфраструктурою, зі швидкістю викочування та швидкістю зміни програми, з'являються нові рішення, наприклад, serverless. Чи відчуваєш ти якийсь потенціал у цьому напрямку та, скажімо так, небезпека для Kubernetes та схожих рішень?
Дмитро: Тут потрібно знову зробити ремарку, що я не провидець, який дивиться вперед і каже - буде ось так! Хоча я щойно робив те саме. Я дивлюся під ноги і бачу там купу проблем, наприклад, як у комп'ютері працюють транзистори. До кумедного, так? Ми з якимись багами CPU стикаємося.
Зробити serverless досить надійно, дешево, ефективно та зручно, вирішивши всі екосистемні питання. Тут я згоден з Ілоном Маском, що потрібна друга планета, щоб зробити стійкість до відмови від людства. Хоча я не знаю, що він каже, але розумію, що не готовий летіти сам на Марс, і це не завтра буде.
З serverless чітко зрозуміло, що це ідеологічно правильна річ, як стійкість до відмови від людства — дві планети мати краще, ніж одну. Але як це зробити зараз? Одну експедицію надіслати — не проблема, якщо сконцентрувати на цьому зусилля. Відправити кілька експедицій і заселити там кілька тисяч людей, гадаю, теж реалістично. А от прямо відмовостійкість цілком зробити, щоб половина людства там жила, мені здається зараз неможливим, не розглядається.
З serverless один на один: штука класна, але вона далека від проблем 2019 року. Ближче до 2030 - давайте доживемо до нього. Я не маю сумніву, що доживемо, ми обов'язково доживемо (повторюйте перед сном), але зараз треба вирішувати інші проблеми. Це як вірити у казкового поні Веселку. Так, пара відсотків кейсів вирішуються, і вирішуються відмінно, але суб'єктивно serverless - це веселка ... Для мене ця тема занадто далека і незрозуміла. Я не готовий казати. У 2019 році з serverless жодного додатка не напишеш.
Як розвиватиметься Kubernetes
— Поки що ми йдемо до цього потенційно прекрасного далекого майбутнього, як ти вважаєш, як розвиватиметься Kubernetes та екосистема навколо нього?
Дмитро: Я багато про це думав і у мене є чітка відповідь Перше - statefull - все-таки stateless зробити легше. Kubernetes спочатку в це більше вкладав, з нього все починалося. Stateless працює практично ідеально в Kubernetes, просто нема до чого причепитися. По статевідосить ще купа проблем, вірніше, нюансів. У нас уже все там чудово працює, але це ми. На те, щоб це працювало у всіх, потрібно ще кілька років як мінімум. Це не розрахований показник, а моє відчуття із голови.
Коротше, statefull дуже сильно повинен і буде розвиватися, тому що всі додатки у нас зберігають статус, не буває stateless-додатків. Це ілюзія, завжди потрібна якась БД і ще щось. Statefull - це спрямування всього, чого можна, виправлення всіх багів, покращення всіх проблем, з якими зараз стикаються - назвемо це adoption.
Рівень незвіданого, рівень невирішених проблем, рівень ймовірності з чимось зіткнутися буде сильно падати. Це важлива історія. І оператори - все, що пов'язано з кодифікуванням логіки адміністрування, логіки управління, щоб отримати easy service: MySQL easy service, RabbitMQ easy service, Memcache easy service, - взагалі всі ці компоненти, які нам потрібні, щоб отримати працюючим з коробки гарантовано. Це саме вирішує той біль, що ми хочемо базу даних, але не хочемо її адмініструвати, або хочемо Kubernetes, але не хочемо його адмініструвати.
Ця історія з розвитком операторів у тому чи іншому прояві буде важливою у найближчі кілька років.
Я думаю сильно повинна зрости простота експлуатації - ящик ставатиме все більш і більш чорним, все більш і більш надійним, з дедалі більш простими крутилками.
Я якось слухав старе інтерв'ю Айзека Азімова 80-х років на YouTube у шоу Saturday Night Live – передача типу Урганта, лише цікава. Його там питали про майбутнє комп'ютерів. Він сказав, що майбутнє у простоті, як це було з радіоприймачем. Радіоприймач спочатку був складною штукою. Щоб упіймати хвилю, потрібно було 15 хвилин крутити крутилки, крутити роженки і взагалі знати, як усе влаштовано, розуміти фізику передачі радіохвиль. У результаті радіо залишилася одна крутилка.
Нині у 2019 році яке радіо? У машині радіоприймач знаходить усі хвилі, назву станцій. Фізика процесу не змінилася за 100 років, змінилася простота використання. Зараз, та й не тільки зараз, вже в 1980 році, коли було інтерв'ю з Азімовим, всі користувалися радіо і ніхто не замислювався, як воно влаштоване. Воно завжди працювало – це даність.
Азімов тоді казав, що з комп'ютерами буде аналогічно. простота використання зросте. Якщо у 1980 році потрібно здобути спеціальну освіту, щоб натискати кнопки на комп'ютері, то в майбутньому це буде не так.
У мене відчуття, що з Kubernetes та інфраструктурою теж буде дуже сильно зростати простота використання. Це, на мою думку, очевидно — лежить на поверхні.
Що робити з інженерами?
— А що тоді станеться з інженерами, системними адміністраторами, які підтримують Kubernetes?
Дмитро: А що стало з бухгалтером після появи 1С? Приблизно те саме. До цього рахували на папірці — тепер у програмі. Продуктивність праці зросла на порядки, а працю від цього не зник. Якщо раніше для вкручування лампи потрібно було 10 інженерів, то тепер буде достатньо одного.
Кількість софту та кількість завдань, мені здається, зараз зростає зі швидкістю більшою, ніж з'являються нові DevOps'и та збільшується ККД. Зараз на ринку конкретний дефіцит, і він триватиме довго. Пізніше все увійде в деяку норму, за якої ККД роботи зросте, буде все більше serverless, до Kubernetes прикрутять нейронку, яка підбиратиме всі ресурси прямо як треба, і взагалі все робить сама, як треба - людина відійди і не заважай.
Але рішення все одно треба буде комусь ухвалювати. Зрозуміло, що рівень кваліфікації та спеціалізованість цієї людини вищий. Зараз у відділі бухгалтерії вам не потрібні 10 співробітників, які ведуть бухгалтерські книги, щоб у них не втомлювалася рука. Це просто не потрібне. Багато документів автоматично скануються, розпізнаються системою електронного документообігу. Достатньо одного розумного головного бухгалтера, вже зі значно більшими скілами, з гарним розумінням.
Загалом такий шлях у всіх галузях. З автомобілями так само: раніше до автомобіля додавались автомеханік та три водії. Зараз водіння автомобіля – це найпростіший процес, у якому ми всі беремо участь щодня. Ніхто не замислюється, що автомобіль це щось складне.
DevOps або системна інженерія нікуди не подінуться – високорівневість та ефективність роботи зростатимуть.
— Я ще чув цікаву ідею, що насправді робота збільшиться.
Дмитро: Звичайно, сто відсотків! Тому що кількість софту, яку ми пишемо, невпинно зростає. Кількість питань, які вирішуємо софтом, постійно зростає. Кількість роботи зростає. Зараз ринок DevOps дуже перегрітий. Це видно з зарплатних очікувань. По-хорошому, не вдаючись до деталей, мають бути джуніори, які хочуть Х, міддли, які хочуть 1,5Х, та сеньйори, які хочуть 2Х. А зараз, якщо дивитися московський ринок зарплат DevOps'ів, джуніор хоче від Х до 3Х та сеньйор хоче від Х до 3Х.
Ніхто не знає, скільки коштує. Рівень зарплати вимірюється твоєю впевненістю — повний дурдом, якщо чесно, моторошно перегрітий ринок.
Звичайно, ця ситуація зміниться дуже скоро — має настати деяке насичення. З розробкою софту ж не так — незважаючи на те, що розробники всім потрібні, і всім потрібні хороші розробники, ринок розуміє, хто скільки коштує, — галузь устаканилася. З DevOps зараз не так.
— З того, що я почув, я зробив висновок, що сильно турбуватися поточному системному адміністратору не варто, але настав час качати скіли і готуватися до того, що завтра роботи буде більше, але вона буде більш висококваліфікованою.
Дмитро: Стовідсотково. Загалом ми живемо у 2019 році і правило життя таке: lifetime learning - ми вчимося все життя. Мені здається, зараз це вже всі знають і відчувають, але мало знати треба робити. Щодня ми маємо змінюватися. Якщо ми цього не робимо, то раніше чи пізніше нас висадять на узбіччі професії.
Будьте готові до різких розворотів на 180 градусів. Я не виключаю ситуації, коли щось кардинально зміниться, вигадають щось нове — таке буває. Гоп! - І ми тепер діємо по-іншому. Важливо бути готовим і не паритися. Може так статися, що завтра все, що я роблю, виявиться непотрібним — нічого, я все життя вчився і готовий вчитися чогось іншого. Це не проблема. Боятися job security не варто, але потрібно бути готовим до того, щоб постійно вчитися чогось нового.
Побажання та хвилинка реклами
— Чи буде в тебе якесь бажання?
Дмитро: Так, у мене кілька побажань
Перше та меркантильне - підпишіться на . Шановні читачі, зайдіть на YouTube та підпишіться на наш канал. Десь через місяць ми почнемо активну експансію на відеосервіс у нас буде купа навчального контенту про Kubernetes, відкрите і різне: від практичних речей, аж до лабораторок, до глибоких принципових теоретичних речей і як застосовувати Kubernetes на рівні принципів та патернів.
Друге меркантильне побажання - зайдіть на і поставте зірочки, бо ми ними харчуємось. Якщо ви нам зірочки не поставите, нам їсти нічого. Це як мана у комп'ютерній грі. Ми щось робимо, робимо, намагаємося, хтось каже, що це моторошні велосипеди, хтось, що все взагалі неправильно, а ми продовжуємо та діємо абсолютно чесно. Ми бачимо проблему, її вирішуємо та ділимося досвідом. Тому поставте нам зірочку, від вас не зменшиться, а нам прибуде, бо ми ними харчуємося.
Третє, важливе, і вже не меркантильне побажання. перестаньте вірити у казки. Ви професіонали. DevOps – це дуже серйозна та відповідальна професія. Перестаньте грати на робочому місці. Нехай вас клацне, і ви зрозумієте це. Уявіть, що ви прийдете до лікарні, а там лікар на вас експериментує. Розумію, що комусь це може бути прикро, але, швидше за все, це не про вас, а про когось іншого. Скажіть іншим, щоби вони теж перестали. Це реально псує життя всім нам — багато хто починає ставитися до експлуатації, до адмінів і до DevOps'ів, як до чуваків, які знову щось поламали. Це «поломали» найчастіше через те, що ми пішли грати, а не холодною свідомістю подивилися, що тут так, а тут так.
Це не означає, що не треба експериментувати. Експериментувати треба, ми самі так робимо. Якщо бути чесним, ми самі ще й граємось іноді — це, звичайно, дуже погано, але ніщо людське нам не далекі. Давайте 2019 оголосимо роком серйозних продуманих експериментів, а не ігор на проді. Напевно так.
- Велике дякую!
Дмитро: Тобі спасибі, Віталію, і за час, і за інтерв'ю Дорогі читачі, вам дякую, якщо ви раптом дійшли до цього моменту. Сподіваюся, що хоч пару думок ми вам принесли.
В інтерв'ю Дмитро торкнувся питання werf. Нині це універсальний швейцарський ніж, який вирішує майже всі завдання. Але так не завжди. на на фестивалі Дмитро Столяров розповість про цей інструмент докладно. У доповіді буде все: проблеми та приховані нюанси Kubernetes, варіанти вирішення цих труднощів та поточна реалізація werf у подробицях. Приєднуйтесь 27 та 28 травня, створюватимемо ідеальні інструменти.
Джерело: habr.com