В очакване на Виталий Хабаров взе интервю от Дмитрий Столяров (), техническия директор и съосновател на компанията „Флант“. Виталий разпита Дмитрия за това, с какво се занимава „Флант“, за Kubernetes, развитието на екосистемата, поддръжката. Обсъдиха защо е необходим Kubernetes и дали всъщност е нужен. И още за микросервизите, Amazon AWS, подхода „Ще ми се получи“ в DevOps, бъдещето на самия Kubernetes, защо, кога и как той ще завладее света, перспективите на DevOps и за какво да се подготвят инженерите в светлото и близко бъдеще с опростяването и невронните мрежи.
в подкаст формат можете да чуете на DevOps Дефлопа — рускоезичен подкаст за DevOps, а по-долу — текстовата версия.
Тук и нататък въпросите задава инженер от Express42.
За „Флант“
— Дима, привет. Ти си технически директор на „“ и също негов основател. Разкажи, моля, с какво се занимава компанията и ти в нея?
Дмитрий: Отстрани изглежда, че сме такива момчета, които ходят и на всеки слагат Kubernetes и нещо правят с него. Но не е така. Започнахме като компания, която се занимава с Linux, но вече от много време основната ни дейност е обслужването на production и highload проекти на ключ. Обикновено изграждаме цялата инфраструктура от нулата и след това дълго време отговаряме за нея. Затова основната работа, която изпълнява „Флант“, за която и получава пари, е поемането на отговорност и реализиране на production на ключ.
Аз, като технически директор и един от учредителите на компанията, круглосуточно се занимавам с това как да повиша достъпността на production, да опростя експлоатацията му, да улесня живота на админите и да направя живота на разработчиците по-приятен.
За 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 за всичко, което вече съществува. Ако там pull requests не се приемат, просто го форкаме за себе си и живеем, докато не бъдат одобрени с нашите билдове. След това, когато това достигне до upstream, ние се връщаме обратно към upstream версията.
Например, имаме Prometheus оператор, с който вече 5 пъти сменяме версията на нашата сборка. Нуждаем се от нова функционалност, изпратихме pull request и трябва да я пуснем утре, а не искаме да чакаме, докато я пуснат в upstream. Следователно, създаваме своя версия и я внедряваме във всички свои клъстери. После, в upstream, ни казват: «Хайде, да направим нещо по-общо», и ние, или друг някой, я доразвиваме, и с времето отново се интегрира обратно.
Всичко, което съществува, се опитваме да развиваме.Много елементи, които все още не съществуват, не са измислени или са измислени, но не са реализирани – ние ги правим. Не защото ни харесва самият процес или строителството на велосипеди, а просто защото имаме нужда от този инструмент. Често питат защо сме направили това или онова? Отговорът е прост – защото трябваше да продължим напред, да решим някакъв практически проблем, и го решихме с този инструмент.
Пътят винаги е такъв: много внимателно търсим и, ако не намерим решение как да направим тролейбус от хляб, правим своя хляб и своя тролейбус.
Инструменти на «Фланта»
Знам, че в момента «Фланта» има addon оператори, shell оператори и инструменти dapp/werf. Както разбирам, това е един и същ инструмент в различни мутации. Също така разбирам, че в «Фланта» има много различни инструменти. Вярно ли е?
Дмитрий: В GitHub имаме още много неща. От това, което сега се сещам, имаме statusmap – панел за Grafana, който е много популярен. Той се споменава почти във всяка втора статия за мониторинг на Kubernetes в Medium. Невъзможно е да се обясни накратко какво е 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 инженери всеки ден се сблъскват с проблеми и ги решават, ние просто анализираме този опит и се опитваме да го обобщим. Разбираме, че ако остане при нас, след година или две инструментът ще бъде безполезен, защото някъде в общността ще се появи готова инструмент. Няма смисъл да натрупваме този опит вътре — това е просто преливане на усилия и време в dev/null. По този начин не съжаляваме. С голямо удоволствие всичко публикуваме и разбираме, че трябва да го публикуваме, развиваме, рекламираме, за да могат хората да използват и да добавят своя опит — тогава всичко расте и живее. Тогава след две години инструментът не отива на сметището. Не е жалко да продължаваш да влагаш усилия, защото виждаш, че някой ползва инструмента ти, а след две години вече всички го ползват.
Това е част от нашата голяма стратегия с dapp/werf. Не помня кога започнахме да го правим, май преди 3 години. Първоначално беше изцяло на shell. Това беше супер proof of concept, решихме някои от нашите частни задачи - успяхме! Но с shell там имаше проблеми, невъзможно е да се развива по-нататък, програмирането на shell е истинско занимание. Имахме навик да пишем на Ruby, съответно, на Ruby направихме някои промени, развивахме, развивахме и стигнахме до това, че общността, тълпата, която не казва „искаме или не искаме“, се отвращава от 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 и той да бъде точно също така внедрен на етапите или тестовете, в зависимост от пайплайните, и след това с този същия инструмент да отидем на продукция. Това единство, унификация и възпроизводимост на инфраструктурата от локалната среда до продукцията е много важен аспект за нас. Но това все още не е налично в 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 от нулата, за да е готов за производство?
Дмитрий: Как мислиш, колко е сложно да се трансплантира сърце? Разбирам, че въпросът компрометира. Да носиш скалпел и да не сбъркаш - това не е толкова сложно. Ако ти кажат къде да режеш, а къде да зашиеш, самата процедура не е сложна. Сложно е да се гарантира, че всеки път всичко ще проработи.
Да инсталирате Kubernetes и да го накарате да работи е лесно: чик! - инсталира се, има много начини за инсталиране. Но какво ще стане, когато възникнат проблеми?
Винаги възникват въпроси - какво още не сме взели предвид? Какво още не сме направили? Какви параметри на Linux ядрото сме указали неправилно? Господи, а ние изобщо ги указвахме?! Какви компоненти на Kubernetes сме инсталирали, а какви не? Възникват хиляди въпроси и, за да им отговорим, са необходими 15-20 години опит в тази индустрия.
Имам свеж пример по тази тема, който може да разкрие същността на проблема "Трудно ли е да се поддържа Kubernetes?" Преди време сериозно обмисляхме дали да не опитаме да внедрим Cilium като мрежа в Kubernetes.
Нека обясня какво е Cilium. В Kubernetes има много различни реализации на мрежовата подсистема, и една от тях е наистина страхотна – това е Cilium. Какъв е нейният смисъл? В ядрото преди време се появи възможност да се пишат хукове за ядрото, които по един или друг начин нахлуват в мрежовата подсистема и в различни други подсистеми и позволяват да се заобиколят големи части от ядрото.
В Linux ядрото исторически съществуват ip rout, netfilter, мрежови мостове и много различни стари компоненти, на по 15, 20 или 30 години. Като цяло те работят, всичко е наред, но в днешно време имаме много контейнери, и това изглежда като кула от 15 тухли една върху друга, а ти стоиш на нея на един крак – странно усещане. Тази система исторически е развивана с много нюанси, като апендикса в тялото. В някои ситуации има проблеми с производителността, например.
Има чудесен BPF и възможност да се пишат хукове за ядрото – момчетата написаха своите хукове за ядрото. Пакетът влиза в Linux ядрото, те го изваждат веднага на входа, обработват го както трябва без мостове, без TCP, без IP стек – накратко, заобикаляйки всичко, което е написано в Linux ядрото, и го изкарват в контейнера.
Какво се получи? Много добра производителност, страхотни функции – просто класно! Но ние гледаме на това и виждаме, че на всяка машина има програма, която се свързва с API на Kubernetes и на базата на данните, които получава от това API, генерира C код и компилира бинарни файлове, които зарежда в ядрото, за да работят тези хукове в kernel space.
Какво ще стане, ако нещо не тръгне както трябва? Не знаем. За да разберем това, трябва да прочетем целия този код, да разберем цялата логика, а това е ужасно трудно. Но от друга страна, имаме тези мостове, netfilter, 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. Това води до това, че с времето всяка машина започва да забавя. Това не е дори въпрос за highload. Ако постоянно се стартират подове, например, ако има Cron Job, който постоянно генерира подове, то машината с Ubuntu 16.04 след седмица ще започне да забавя. Постоянно ще има висок load average заради това, че е създадена купчина C-групи. Това е проблем, с който всеки, който просто инсталира Ubuntu 16 и след това Kubernetes, ще се сблъска.
Да предположим, че по някакъв начин той ще актуализира systemd или нещо друго, но в ядрото на Linux до 4.16 е дори по-смехотворно — при изтриване на C-групите те в ядрото пропускат и всъщност не се изтриват. Следователно след месец работа на тази машина няма да може да се види статистиката за паметта по подовете. Изваждаме файл, въртим го в прога и един файл се върти 15 секунди, защото ядрото много дълго смята вътре в себе си около милион C-групи, които уж са изтрити, но не — те пропускат.
Има много подобни дреболии и там и тук. Това не е въпрос, с който компаниите-гиганти понякога могат да се сблъскат при много големи натоварвания — не, това е въпрос за ежедневни неща. Хората могат месеци да живеят така — инсталирали са Kubernetes, деплойнали са приложение — изглежда работи. На много хора им е добре. За това, че някога това приложение по някаква причина ще се срине, дори не се досещат, аларма не идва, но за тях това е норма. Преди живееха на виртуалки без мониторинг, сега са преминали в Kubernetes също без мониторинг — каква разлика?
Въпросът е, че когато ходим по леда, никога не знаем дебелината му, ако не сме я измерили предварително. Много хора ходят и не се притесняват, защото и преди са ходили.
От моята гледна точка, нюансът и сложността при експлоатацията на всяка система е да гарантираме, че дебелината на леда със сигурност е достатъчна, за да реши нашите задачи. Става въпрос именно за това.
В IT, ми се струва, че има твърде много подходи с "Ще ми провърви". Много хора инсталират софтуер и използват програмни библиотеки с надеждата, че ще им провърви. На общо, на много им провървява. Вероятно затова това работи.
— Според моята песимистична оценка, това изглежда така: когато рисковете са големи, а приложението трябва да работи, е необходима подкрепа от "Флант", възможно от 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 лесна услуга "на ключ". Ако сте малък стартъп с няколко разработчици - това работи. Вместо да наемате свой DevOps, който трябва да учи как да решава вашите проблеми и да получава заплата в това време, вие ще получите решение на всички въпроси "на ключ". Да, има определени недостатъци. Ние, като аутсорсър, не можем да бъдем толкова ангажирани и бързо да реагираме на изменения. Но затова имаме много експертиза, готови практики. Гарантираме, че в коя да е ситуация, ние точно и бързо ще се справим и ще възстановим от "онзи свят" всяка инстанция на Kubernetes.
Категорично препоръчвам аутсорсинг на стартъпи и утвърдени бизнеси до момента, в който можете да отделите екип от 10 души за експлотация, защото в противен случай няма смисъл. Това категорично има смисъл да се аутсорсва.
За Amazon и Google
— Може ли да се разглежда хост от решенията на Amazon или Google като аутсорс?
Дмитрий: Да, разбира се, това решава някои въпроси. Но пак, нюанси. Винаги трябва да разбирате как да го използвате. Например, има хиляда детайли в работата с Amazon AWS: Load Balancer трябва да се 'прогрее' или предварително да подадете заявка, че "хората, ще получим трафик, моля прогрейте ни Load Balancer!" Тези нюанси трябва да се знаят.
Когато се обръщате към хора, които се специализират в това, получавате почти всички стандартни неща покрити. В момента имаме 40 инженера, до края на годината вероятно ще бъдат 60 - ние със сигурност сме се сблъсквали с всички тези неща. Дори ако на някой проект отново се сблъскаме с този проблем, ние вече бързо питаме един друг и знаем как да решим.
Сигурно отговорът е такъв - разбира се, хостваната история улеснява част от процесите. Въпросът е дали сте готови да се доверите на тези хостинг компании и дали те ще решат вашите проблеми. Amazon и Google са се утвърдили добре. За всички наши случаи - определено. Нямаме повече положителен опит. Всички останали облаци, с които се опитвахме да работим, създават много проблеми - и Ager, и всичко, което се намира в Русия, и всякакви OpenStack реализации: Headster, Overage - всичко, което искате. Те всички предизвикват проблеми, които не искате да решавате.
Затова отговорът е - да, но на практика, зрели хоствани решения не са много.
Кому е нужен 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 проекти, без значение в какъв бизнес – софтуер за улесняване на света, и които разбират това, им е необходимо да разрешат тези потребности. Kubernetes с правилния подход, правилното разбиране и достатъчно опит може да ги реши.
За serverless
- Ако погледнеш малко по-далеч в бъдещето, опитвайки се да решиш проблема с главоболията, свързани с инфраструктурата, скоростта на внедряване и скоростта на промяна на приложението, се появяват нови решения, например serverless. Чувстваш ли някакъв потенциал в тази посока и, така да се каже, опасност за Kubernetes и подобни решения?
Дмитрий: Тук отново трябва да направя забележка, че не съм пророк, който гледа напред и казва - ще бъде така! Въпреки че току-що направих същото. Гледам под краката си и виждам куп проблеми, например как работят транзисторите в компютрите. Смехотворно, нали? С някои бъгове в CPU се сблъскахме.
Да направим serverless достатъчно надеждно, евтино, ефективно и удобно, решавайки всички екосистемни въпроси. Тук съм съгласен с Илон Мъск, че е нужна втора планета, за да осигурим отказоустойчивост за човечеството. Въпреки че не знам какво казва, разбирам, че не съм готов да летя сам на Марс и това няма да се случи утре.
С serverless е ясно, че това е идеологически правилна концепция, както отказоустойчивост за човечеството - по-добре да имаме две планети, отколкото една. Но как да го направим сега? Да изпратим една експедиция - не е проблем, ако се концентрираме върху това усилие. Да изпратим няколко експедиции и да населим там няколко хиляди души, мисля, също е реалистично. Но да осигурим пълна отказоустойчивост, така че половината от човечеството да живее там, ми се струва в момента невъзможно, недопустимо.
С serverless е същото: готина концепция, но далеч от проблемите на 2019 година. По-близо до 2030 - нека доживеем до него. Не се съмнявам, че ще доживеем, задължително ще доживеем (повтаряйте преди сън), но сега трябва да решаваме други проблеми. Това е като да вярваме в приказен пони Дъга. Да, няколко процента от случаите се решават и то отлично, но субективно serverless - това е дъга... За мен тази тема е твърде далечна и твърде неясна. Не съм готов да говоря. През 2019 година с serverless не можеш да напишеш нито едно приложение.
Как ще се развива Kubernetes
— Докато вървим към това потенциално прекрасно далечно бъдеще, как мислиш, как ще се развива Kubernetes и екосистемата около него?
Дмитрий: Мислих много за това и имам ясен отговор. Първото — statefull — всъщност е по-лесно да стане stateless. Kubernetes първоначално вложи много усилия в това, от него всичко започна. Stateless работи практически идеално в Kubernetes, просто няма с какво да се заяжда. По statefull все още има куп проблеми, дори нюанси. При нас всичко там работи прекрасно, но това сме ние. За да работи при всички, ще са нужни поне още няколко години. Това не е изчислен показател, а моето усещане.
Накратко, statefull много трябва да се развива — и ще се развива — защото всичките ни приложения съхраняват статус, няма stateless-приложения. Това е илюзия, винаги е нужна някаква база данни и нещо още. Statefull — това е опростяване на всичко, което може, поправяне на всички бъгове, подобряване на всички проблеми, с които в момента се сблъскваме — да го наречем adoption.
Нивото на неизследваното, нивото на нерешените проблеми, нивото на вероятността да се сблъскаш с нещо, ще падне значително. Това е важна история. И операторите — всичко, свързано с кодифициране на логиката на администриране, логиката на управление, за да получим лесна услуга: MySQL лесна услуга, RabbitMQ лесна услуга, Memcache лесна услуга — въобще всичките тези компоненти, от които се нуждаем, за да получим работещо решение от кутията. Това точно решава тези болки, че искаме база данни, но не искаме да я администрираме, или искаме 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 градуса. Не изключвам ситуации, в които нещо коренно ще се промени, ще измислят нещо ново - такова нещо се случва. Хоп! - и сега действаме по различен начин. Важно е да сте подготвени за това и да не се притеснявате. Може да се случи, че утре всичко, което правя, да се окаже ненужно - нищо, научих се да уча и съм готов да уча нещо различно. Това не е проблем. Не трябва да се страхувате от сигурността на работното място, но е нужно да бъдете готови постоянно да учите нещо ново.
Пожелания и минутка реклама
— Има ли някакво пожелание от твоя страна?
Дмитрий: Да, имам няколко пожелания.
Първото и меркантилно - абонирайте се за . Уважаеми читатели, посетете YouTube и се абонирайте за нашия канал. След около месец ще започнем активна експанзия на видеосервиза и ще имаме много учебно съдържание за Kubernetes, отворено и различно: от практически неща до лабораторни упражнения, до дълбоки принципни теоретични неща и как да прилагате Kubernetes на ниво принципи и патерни.
Второ меркантилно пожелание - посетете и поставете звездички, защото ние се храним с тях. Ако не ни поставите звездички, няма да имаме с какво да се храним. Това е като мана в компютърна игра. Правим нещо, правим, стараем се, някой казва, че това са ужасни велосипедчета, някой, че всичко е изобщо неправилно, а ние продължаваме и действаме абсолютно честно. Виждаме проблема, решаваме го и споделяме опит. Затова поставете ни звездичка, от вас няма да намалее, а на нас ще се увеличи, защото ние се храним с тях.
Трето, важно и вече не меркантилно пожелание - престанете да вярвате в приказки. Вие сте професионалисти. DevOps е много сериозна и отговорна професия. Престанете да играете на работното място. Нека ви осенят прозрението и да разберете това. Представете си, че влизате в болница, а там лекарят експериментира с вас. Разбирам, че на някого това може да е обидно, но най-вероятно не става дума за вас, а за някой друг. Кажете на другите да спрат също. Това наистина разваля живота на всички – много започват да се отнасят към експлоатацията, администраторите и DevOps-ите, като към хора, които пак нещо са опорочили. Това „опорочили“ най-често е защото ние сме се забавлявали, а не сме погледнали с冷на осъзнатост какво става тук и тук.
Това не означава, че не трябва да експериментираме. Нужно е да експериментираме, ние самите го правим. Ако трябва да бъдем честни, понякога дори си играем — разбира се, това е много лошо, но нищо човешко не ни е чуждо. Нека 2019 година обявим за година на сериозни обмислени експерименти, а не на игри на продакшън. Вероятно така.
— Голямо благодаря!
Дмитрий: Благодаря ти,Vitaliy, и за времето, и за интервюто. Скъпи читатели, голямо благодаря и на вас, ако сте стигнали до този момент. Надявам се, че поне няколко мисли сме донесли на вас.
В интервюто Дмитрий засегна въпроса относно werf. В момента това е универсален швейцарски нож, който решава почти всички задачи. Но не винаги е било така. На фестивала Дмитрий Столяров ще говори подробно за този инструмент. В доклада ще бъде всичко: проблеми и скритите нюанси на Kubernetes, варианти за решения на тези трудности и настоящата реализация на werf в подробности. Присъединете се на 27 и 28 май, ще създадем идеални инструменти.
Източник: habr.com
