В очакване Виталий Хабаров интервюиран Дмитрий Столяров (), технически директор и съосновател на компанията Flant. Виталий попита Дмитрий какво прави Flant, за Kubernetes, развитие на екосистемата, поддръжка. Обсъдихме защо е необходим Kubernetes и дали изобщо е необходим. А също и за микроуслугите, Amazon AWS, подхода „Ще имам късмет“ към DevOps, бъдещето на самия Kubernetes, защо, кога и как ще превземе света, перспективите на DevOps и за какво трябва да се подготвят инженерите в светло и близко бъдеще с опростяване и невронни мрежи.
слушайте като подкаст на DevOps Deflop - подкаст на руски език за DevOps, а по-долу е текстовата версия.
Тук и по-долу задава въпроси инженер от Express42.
Относно "Flant"
- Здравей Дима. Вие сте технически директор"“, а също и негов основател. Моля, кажете ни какво прави компанията и какво сте в нея?
Дмитрий: Отвън изглежда, че ние сме момчетата, които обикалят, инсталират Kubernetes за всички и правят нещо с него. Но това не е вярно. Започнахме като компания, която се занимава с Linux, но от много дълго време основната ни дейност е обслужване на производствени и високонатоварени проекти до ключ. Обикновено изграждаме цялата инфраструктура от нулата и след това сме отговорни за нея дълго, дълго време. Следователно основната работа, която "Флант" върши, за която получава пари, е поемане на отговорност и изпълнение на производство до ключ.
Аз, като технически директор и един от основателите на компанията, прекарвам цял ден и нощ, опитвайки се да разбера как да повиша достъпността на производството, да опростя работата му, да направя живота на администраторите по-лесен и живота на разработчиците по-приятен .
Относно Kubernetes
— Напоследък виждам много репортажи от Flant и относно Kubernetes. Как стигнахте до него?
Дмитрий: Вече съм говорил за това много пъти, но изобщо нямам нищо против да го повторя. Мисля, че е редно да повторя тази тема, защото има объркване между причина и следствие.
Наистина ни трябваше инструмент. Сблъскахме се с много проблеми, борихме се, преодоляхме ги с различни патерици и почувствахме нужда от инструмент. Преминахме през много различни варианти, построихме собствени велосипеди и натрупахме опит. Постепенно стигнахме до там, че започнахме да използваме Docker почти веднага след като се появи - около 2013 г. По време на появата му вече имахме много опит с контейнери, вече бяхме написали аналог на „Docker“ - някои от нашите собствени патерици в Python. С появата на Docker стана възможно да се изхвърлят патериците и да се използва надеждно и поддържано от общността решение.
С Kubernetes историята е подобна. По времето, когато започна да набира скорост - за нас това е версия 1.2 - вече имахме куп патерици както на Shell, така и на Chef, които по някакъв начин се опитахме да организираме с Docker. Гледахме сериозно към Rancher и различни други решения, но тогава се появи Kubernetes, в който всичко е имплементирано точно както ние бихме го направили или дори по-добре. Няма от какво да се оплача.
Да, има някакво несъвършенство тук, има някакво несъвършенство там - има много несъвършенства и 1.2 като цяло е ужасен, но... Kubernetes е като сграда в строеж - гледаш проекта и разбираш че ще е яко. Ако сега сградата има фундамент и два етажа, разбирате, че е по-добре да не се нанасяте още, но със софтуера няма такива проблеми - вече можете да го използвате.
Нямахме момент, в който да мислим дали да използваме Kubernetes или не. Чакахме го много преди да се появи и се опитахме сами да създадем аналози.
Относно Kubernetes
— Участвате ли пряко в разработката на самия Kubernetes?
Дмитрий: Посредствено. По-скоро участваме в развитието на екосистемата. Изпращаме определен брой заявки за изтегляне: към Prometheus, към различни оператори, към Helm – към екосистемата. За съжаление, не мога да следя всичко, което правим, и може да греша, но няма нито един пул от нас в ядрото.
— В същото време разработвате ли много от вашите инструменти около Kubernetes?
Дмитрий: Стратегията е следната: отиваме и изтегляме заявки към всичко, което вече съществува. Ако заявките за изтегляне не се приемат там, ние просто ги разклоняваме сами и живеем, докато не бъдат приети с нашите компилации. След това, когато достигне upstream, ние се връщаме към upstream версията.
Например, имаме оператор Prometheus, с който превключихме напред и назад към нагоре по веригата на нашия монтаж вероятно вече 5 пъти. Имаме нужда от някаква функция, изпратихме заявка за изтегляне, трябва да я пуснем утре, но не искаме да чакаме да бъде пусната нагоре по веригата. Съответно, ние сглобяваме за себе си, разгръщаме нашето събрание с нашата функция, която ни е необходима по някаква причина, на всички наши клъстери. След това, например, те ни го връщат нагоре с думите: „Момчета, нека да го направим за по-общ случай“, ние или някой друг го довършваме и след време отново се слива.
Стараем се да развиваме всичко, което съществува. Много елементи, които все още не съществуват, все още не са измислени или са били измислени, но не са имали време да бъдат внедрени - ние го правим. И не защото харесваме процеса или производството на велосипеди като индустрия, а просто защото имаме нужда от този инструмент. Често се задава въпросът защо направихме това или онова нещо? Отговорът е прост - да, защото трябваше да отидем по-далеч, да решим някакъв практически проблем и го решихме с тази тула.
Пътят винаги е такъв: търсим много внимателно и ако не намерим решение как да направим тролейбус от един хляб, правим собствен хляб и собствен тролейбус.
Инструменти Flanta
— Знам, че Flant вече има оператори за добавки, оператори на обвивка и инструменти dapp/werf. Доколкото разбирам, това е един и същ инструмент в различни превъплъщения. Разбирам също, че има много повече различни инструменти в Flaunt. Това е вярно?
Дмитрий: Имаме много повече в GitHub. Доколкото се сещам сега, имаме statusmap - панел за Grafana, който всеки е срещал. Споменава се в почти всяка втора статия за мониторинга на Kubernetes в Medium. Невъзможно е накратко да се обясни какво представлява картата на състоянието - тя се нуждае от отделна статия, но е много полезно нещо за наблюдение на състоянието във времето, тъй като в Kubernetes често трябва да показваме състояние във времето. Имаме и LogHouse - това е нещо, базирано на ClickHouse и черна магия за събиране на логове в Kubernetes.
Много помощни програми! И ще има още повече, защото тази година ще бъдат пуснати редица вътрешни решения. От много големите, базирани на оператора на добавките, има куп добавки за Kubernetes, ала как правилно да инсталирате sert manager - инструмент за управление на сертификати, как правилно да инсталирате Prometheus с куп аксесоари - това са около двадесет различни двоични файлове, които експортират данни и събират нещо, за това Prometheus има най-невероятните графики и сигнали. Всичко това е просто куп добавки към Kubernetes, които се инсталират в клъстер и той се превръща от прост в готин, усъвършенстван, автоматичен, в който много проблеми вече са решени. Да, правим много.
Развитие на екосистемата
„Струва ми се, че това е много голям принос за развитието на този инструмент и методите му за използване.“ Можете ли грубо да прецените кой друг би допринесъл със същия принос за развитието на екосистемата?
Дмитрий: В Русия, от компаниите, които работят на нашия пазар, никой не е дори близо. Разбира се, това е гръмко изявление, защото има големи играчи като Mail и Yandex – те също правят нещо с Kubernetes, но дори те не се доближават до приноса на компании в целия свят, които правят много повече от нас. Трудно е да се сравняват Flant, който има персонал от 80 души, и Red Hat, който има 300 инженери само на Kubernetes, ако не греша. Трудно е за сравнение. Имаме 6 души в RnD отдела, включително и аз, които режем всички наши инструменти. 6 души срещу 300 инженери на Red Hat - някак си е трудно да се сравнява.
- Когато обаче дори тези 6 души могат да направят нещо наистина полезно и отчуждаващо, когато са изправени пред практически проблем и дават решението на общността - интересен случай. Разбирам, че в големите технологични компании, където имат собствен екип за разработка и поддръжка на Kubernetes, по принцип могат да се разработват същите инструменти. Това е пример за тях какво може да се развие и даде на общността, давайки тласък на цялата общност, която използва Kubernetes.
Дмитрий: Това вероятно е характеристика на интегратора, негова особеност. Имаме много проекти и виждаме много различни ситуации. За нас основният начин за създаване на добавена стойност е да анализираме тези случаи, да намерим сходства и да ги направим възможно най-евтини за нас. Работим активно по въпроса. Трудно ми е да говоря за Русия и света, но имаме около 40 DevOps инженери в компанията, които работят върху Kubernetes. Не мисля, че има много компании в Русия със сравним брой специалисти, които разбират Kubernetes, ако изобщо има такива.
Разбирам всичко за длъжността инженер DevOps, всеки разбира всичко и е свикнал да нарича инженерите DevOps инженери DevOps, няма да обсъждаме това. Всички тези 40 невероятни инженери на DevOps се сблъскват и решават проблеми всеки ден, ние просто анализираме този опит и се опитваме да обобщим. Разбираме, че ако остане вътре в нас, тогава след година или две инструментът ще бъде безполезен, защото някъде в общността ще се появи готова Тула. Няма смисъл да трупате този опит вътрешно - това е просто източване на енергия и време в dev/null. И изобщо не съжаляваме за това. Публикуваме всичко с голямо удоволствие и разбираме, че трябва да се публикува, развива, популяризира, популяризира, така че хората да го използват и да добавят своя опит - тогава всичко расте и живее. След това след две години инструментът не отива в кошчето. Не е жалко да продължите да наливате сила, защото е ясно, че някой използва вашия инструмент и след две години всички го използват.
Това е част от нашата голяма стратегия с dapp/werf. Не помня кога започнахме да го правим, струва ми се преди 3 години. Първоначално беше по принцип на черупката. Това беше супер доказателство за концепцията, ние решихме някои от нашите конкретни проблеми - проработи! Но има проблеми с обвивката, невъзможно е да я разширите допълнително, програмирането върху обвивката е друга задача. Имахме навика да пишем в Ruby, съответно преработихме нещо в Ruby, развихме, развихме, развихме и се натъкнахме на факта, че общността, тълпата, която не казва „искаме го или не го искаме“, ” вирна носа си към Руби, колко смешно е това? Разбрахме, че трябва да напишем всички тези неща в Go само за да изпълним първата точка от контролния списък: Инструментът DevOps трябва да бъде статичен двоичен файл. Да бъде Go или не не е толкова важно, но статичен двоичен файл, написан на Go, е по-добър.
Прекарахме енергията си, пренаписахме dapp в Go и го нарекохме werf. Dapp вече не се поддържа, не е разработен, работи в най-нова версия, но има абсолютен път за надграждане до върха и можете да го следвате.
Защо е създадено приложението?
— Можете ли да ни кажете накратко защо е създадено dapp, какви проблеми решава?
Дмитрий: Първата причина е в монтажа. Първоначално имахме сериозни проблеми с изграждането, когато Docker нямаше многоетапни възможности, така че направихме многоетапни сами. След това имахме още куп проблеми с почистването на изображението. Всеки, който прави CI/CD, рано или късно се сблъсква с проблема, че има куп събрани изображения, трябва по някакъв начин да изчистите това, което не е необходимо, и да оставите това, което е необходимо.
Втората причина е разгръщането. Да, има Helm, но той решава само част от проблемите. Странно е, че е написано, че „Helm е мениджърът на пакети за Kubernetes.“ Точно какво „на“. Има и думите „Мениджър на пакети“ - какво е обичайното очакване от мениджър на пакети? Ние казваме: "Мениджър на пакети - инсталирайте пакета!" и очакваме той да ни каже: „Пакетът е доставен.“
Интересно е, че казваме: „Helm, инсталирай пакета“, а когато той отговори, че го е инсталирал, се оказва, че току-що е стартирал инсталацията - той посочи Kubernetes: „Стартирайте това нещо!“ и дали е стартирало или не , независимо дали работи или не, Helm изобщо не решава този проблем.
Оказва се, че Helm е просто текстов препроцесор, който зарежда данни в Kubernetes.
Но като част от всяко внедряване, ние искаме да знаем дали приложението е пуснато за производство или не? Разгърнато до прод означава, че приложението е преместено там, новата версия е внедрена и поне не се срива там и реагира правилно. Helm не решава този проблем по никакъв начин. За да го разрешите, трябва да положите много усилия, защото трябва да дадете на Kubernetes командата за разгръщане и да наблюдавате какво се случва там - дали е разгърнат или разгърнат. Освен това има много задачи, свързани с внедряването, почистването и сглобяването.
Планове
Тази година ще започнем местно развитие. Искаме да постигнем това, което беше преди във Vagrant - написахме „vagrant up“ и внедрихме виртуални машини. Искаме да стигнем до точката, в която има проект в Git, пишем „werf up“ там и това извежда локално копие на този проект, разположено в локален мини-Kub, с всички свързани директории, удобни за разработка . В зависимост от езика за разработка, това се прави по различен начин, но въпреки това, така че локалната разработка да може да се извършва удобно под монтирани файлове.
Следващата стъпка за нас е инвестирайте в удобство за разработчиците. За бързо разгръщане на проект локално с един инструмент, разработете го, бутнете го в Git и той също ще бъде пуснат на етап или тестове, в зависимост от тръбопроводите, и след това използвайте същия инструмент, за да преминете към производство. Това единство, обединение, възпроизводимост на инфраструктурата от местната среда до продажбите е много важен момент за нас. Но това все още не е в werf - ние просто планираме да го направим.
Но пътят към dapp/werf винаги е бил същият като при Kubernetes в началото. Срещнахме проблеми, решихме ги със заобиколни решения - измислихме някои решения за себе си за обвивката, за всичко. След това те се опитаха по някакъв начин да коригират тези заобикалящи решения, да ги обобщят и консолидират в двоични файлове в този случай, които ние просто споделяме.
Има и друг начин да се погледне цялата тази история, с аналогии.
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 маршрут, свръхфилтър, мостове и много различни стари компоненти, които са на 15, 20, 30 години. Като цяло работят, всичко е супер, но сега са натрупали контейнери и изглежда като кула от 15 тухли една върху друга и стоиш на един крак - странно усещане. Тази система се е развила исторически с много нюанси, като апендикса в тялото. В някои ситуации има проблеми с производителността, например.
Има прекрасен BPF и възможност за писане на кукички за ядрото - момчетата са написали свои собствени кукички за ядрото. Пакетът влиза в ядрото на Linux, те го изваждат точно на входа, обработват го сами както трябва без мостове, без TCP, без IP стек - накратко, заобикаляйки всичко, което е написано в ядрото на Linux, и след това плюят го извадете в контейнера.
Какво стана? Много страхотно представяне, страхотни функции - просто страхотно! Но ние разглеждаме това и виждаме, че на всяка машина има програма, която се свързва с Kubernetes API и въз основа на данните, които получава от този API, генерира C код и компилира двоични файлове, които зарежда в ядрото, така че тези куки да работят в пространството на ядрото.
Какво се случва, ако нещо се обърка? Ние незнаем. За да разберете това, трябва да прочетете целия този код, да разберете цялата логика и е удивително колко трудно е това. Но, от друга страна, има тези мостове, мрежови филтри, ip rout - не съм чел изходния им код, както и 40-те инженери, които работят в нашата компания. Може би само малцина разбират някои части.
И каква е разликата? Оказва се, че има ip rout, ядрото на Linux и има нов инструмент - каква разлика има, не разбираме нито едното, нито другото. Но се страхуваме да използваме нещо ново - защо? Защото, ако инструментът е на 30 години, тогава за 30 години всички бъгове са открити, всички грешки са настъпени и не е нужно да знаете за всичко - работи като черна кутия и винаги работи. Всеки знае коя диагностична отвертка на кое място да залепи, кой tcpdump в кой момент да пусне. Всеки познава добре диагностичните помощни програми и разбира как работи този набор от компоненти в ядрото на Linux - не как работи, а как да го използва.
А невероятно готиният Cilium не е на 30 години, още не е остарял. Kubernetes има същия проблем, копирайте. Че Cilium е инсталиран перфектно, че Kubernetes е инсталиран перфектно, но когато нещо се обърка в производството, можете ли бързо да разберете в критична ситуация какво се е объркало?
Когато казваме трудно ли е да се поддържа Kubernetes – не, много е лесно и да, невероятно трудно е. Kubernetes работи чудесно сам по себе си, но с милиард нюанси.
За подхода „ще имам късмет“.
— Има ли фирми, при които почти гарантирано ще се появят тези нюанси? Да предположим, че Yandex внезапно прехвърли всички услуги на Kubernetes, там ще има огромно натоварване.
Дмитрий: Не, това не е разговор за натоварването, а за най-простите неща. Например, имаме Kubernetes, внедрихме приложението там. Откъде знаеш, че работи? Просто няма готов инструмент, за да разберете, че приложението не се срива. Няма готова система, която да изпраща предупреждения; трябва да конфигурирате тези предупреждения и всеки график. И ние актуализираме Kubernetes.
Имам Ubuntu 16.04. Можете да кажете, че това е стара версия, но все още сме на нея, защото е LTS. Има systemd, чийто нюанс е, че не почиства C-групи. Kubernetes стартира pods, създава C-групи, след това изтрива pods и някак си се оказва - не помня подробностите, съжалявам - че остават срезове systemd. Това води до факта, че с течение на времето всяка кола започва да се забавя силно. Това дори не е въпрос за високо натоварване. Ако се стартират постоянни подове, например, ако има Cron Job, който постоянно генерира подове, тогава машината с Ubuntu 16.04 ще започне да се забавя след една седмица. Ще има постоянно високо средно натоварване поради факта, че са създадени куп C-групи. Това е проблемът, с който ще се сблъска всеки човек, който просто инсталира Ubuntu 16 и Kubernetes отгоре.
Да кажем, че той по някакъв начин актуализира systemd или нещо друго, но в ядрото на Linux до 4.16 е още по-смешно - когато изтриете C-групи, те изтичат в ядрото и всъщност не се изтриват. Следователно, след месец работа на тази машина, ще бъде невъзможно да се погледне статистиката на паметта за огнищата. Изваждаме файл, въртим го в програмата и един файл се върти за 15 секунди, защото ядрото отнема много време, за да преброи милион C-групи в себе си, които изглеждат изтрити, но не - текат .
Все още има много такива малки неща тук и там. Това не е проблем, с който гигантските компании понякога могат да се сблъскат при много големи натоварвания - не, това е въпрос на ежедневни неща. Хората могат да живеят така с месеци - инсталираха Kubernetes, внедриха приложението - изглежда, че работи. За много хора това е нормално. Те дори няма да знаят, че това приложение ще се срине по някаква причина, няма да получат предупреждение, но за тях това е норма. Преди това живеехме на виртуални машини без мониторинг, сега се преместихме в Kubernetes, също без мониторинг - каква е разликата?
Въпросът е, че когато ходим по лед, никога не знаем дебелината му, освен ако не я измерим предварително. Много хора ходят и не се притесняват, защото са ходили и преди.
От моя гледна точка, нюансът и сложността на работата на всяка система е да се гарантира, че дебелината на леда е точно достатъчна, за да реши нашите проблеми. Ето за какво говорим.
Струва ми се, че в ИТ има твърде много подходи „Ще имам късмет“. Много хора инсталират софтуер и използват софтуерни библиотеки с надеждата, че ще имат късмет. Като цяло много хора са късметлии. Сигурно затова работи.
— От моята песимистична оценка изглежда така: когато рисковете са високи и приложението трябва да работи, тогава е необходима поддръжка от Flaunt, може би от Red Hat, или имате нужда от собствен вътрешен екип, посветен специално на Kubernetes, който е готов да го издърпам.
Дмитрий: Обективно е така. Самостоятелното навлизане в историята на Kubernetes за малък екип включва редица рискове.
Имаме ли нужда от контейнери?
— Можете ли да ни кажете колко разпространен е Kubernetes в Русия?
Дмитрий: Нямам тези данни и не съм сигурен, че някой друг ги има. Ние казваме: „Kubernetes, Kubernetes“, но има и друг начин за разглеждане на този въпрос. Също така не знам колко широко разпространени са контейнерите, но знам цифра от доклади в Интернет, че 70% от контейнерите са оркестрирани от Kubernetes. Това беше надежден източник за доста голяма извадка по целия свят.
Тогава друг въпрос - имаме ли нужда от контейнери? Моето лично усещане и цялостната позиция на компанията Flant е, че Kubernetes е де факто стандарт.
Няма да има нищо друго освен Kubernetes.
Това е абсолютна промяна в играта в областта на управлението на инфраструктурата. Просто абсолютно - това е, няма повече Ansible, Chef, виртуални машини, Terraform. Не говоря за старите колхозни методи. Kubernetes е абсолютен променящ фактор, а сега ще е само така.
Ясно е, че за някои са необходими няколко години, а за други няколко десетилетия, за да осъзнаят това. Не се съмнявам, че няма да има нищо друго освен Kubernetes и този нов облик: вече не увреждаме операционната система, а използваме инфраструктура като код, само че не с код, а с yml - декларативно описана инфраструктура. Имам чувството, че винаги ще бъде така.
— Тоест тези компании, които все още не са преминали към Kubernetes, определено ще преминат към него или ще останат в забрава. правилно ли те разбрах?
Дмитрий: Това също не е съвсем вярно. Например, ако имаме задачата да стартираме DNS сървър, тогава той може да бъде стартиран на FreeBSD 4.10 и може да работи перфектно в продължение на 20 години. Просто работа и това е. Може би след 20 години нещо ще трябва да се актуализира веднъж. Ако говорим за софтуер във формата, който стартирахме и той действително работи много години без никакви актуализации, без да прави промени, тогава, разбира се, няма да има Kubernetes. Той не е нужен там.
Всичко свързано с CI/CD - навсякъде, където е необходима непрекъсната доставка, където трябва да актуализирате версии, да правите активни промени, където трябва да изградите толерантност към грешки - само Kubernetes.
Относно микроуслугите
- Тук имам лек дисонанс. За да работите с Kubernetes, имате нужда от външна или вътрешна поддръжка - това е първата точка. Второ, когато тепърва започваме разработката, ние сме малък стартъп, все още нямаме нищо, разработката за Kubernetes или архитектурата на микросервизи като цяло може да бъде сложна и не винаги икономически оправдана. Интересувам се от вашето мнение - трябва ли стартиращите компании незабавно да започнат да пишат за Kubernetes от нулата или все пак могат да напишат монолит и след това да дойдат само в Kubernetes?
Дмитрий: Готин въпрос. Имам разговор за микроуслуги Много пъти съм срещал хора, които се опитват да забиват пирони с микроскоп. Самият подход е правилен, ние сами проектираме вътрешния си софтуер по този начин. Но когато правите това, трябва ясно да разберете какво правите. Думата, която мразя най-много за микроуслугите, е „микро“. Исторически тази дума произхожда от там и по някаква причина хората смятат, че микро е много малко, по-малко от милиметър, като микрометър. Това е грешно.
Например, има монолит, който е написан от 300 души и всеки, който е участвал в разработката, разбира, че има проблеми и трябва да бъде разбит на микро парчета - около 10 парчета, всяко от които е написано от 30 души в минимална версия. Това е важно, необходимо и готино. Но когато при нас дойде стартъп, където 3 много готини и талантливи момчета са написали 60 микроуслуги на колене, всеки път търся Corvalol.
Струва ми се, че това вече е говорено хиляди пъти - имаме разпределен монолит под една или друга форма. Това не е икономически оправдано, много е трудно като цяло във всичко. Виждал съм това толкова много пъти, че наистина ме боли, така че продължавам да говоря за това.
На първоначалния въпрос има конфликт между факта, че от една страна Kubernetes е плашещ за използване, защото не е ясно какво може да се счупи там или да не работи, от друга страна е ясно, че всичко отива там и нищо освен Kubernetes няма да съществува. Отговор - претеглете количеството полза, което идва, количеството задачи, които можете да решите. Това е от едната страна на скалата. От друга страна, съществуват рискове, свързани с престой или с намаляване на времето за реакция, ниво на достъпност - с намаляване на показателите за ефективност.
Ето го - или се движим бързо и Kubernetes ни позволява да правим много неща много по-бързо и по-добре, или използваме надеждни, изпитани във времето решения, но се движим много по-бавно. Това е избор, който всяка компания трябва да направи. Можете да си го представите като пътека в джунглата - когато тръгнете за първи път, можете да срещнете змия, тигър или язовец, а когато сте ходили 10 пъти, сте утъпкали пътеката, премахната клоните и ходи по-лесно. Всеки път пътеката става все по-широка. След това е асфалтов път, а по-късно красив булевард.
Kubernetes не стои на едно място. Отново въпрос: Kubernetes, от една страна, е 4-5 бинарни файлове, от друга страна, това е цялата екосистема. Това е операционната система, която имаме на нашите машини. Какво е това? Ubuntu или Curios? Това е ядрото на Linux, куп допълнителни компоненти. Всички тези неща тук, една отровна змия беше изхвърлена от пътя, там беше поставена ограда. Kubernetes се развива много бързо и динамично, а обемът на рисковете, обемът на неизвестното намалява всеки месец и съответно тези везни се балансират.
Отговаряйки на въпроса какво трябва да направи един стартиращ бизнес, бих казал - елате в Flaunt, платете 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, кой е типичният клиент на Flaunt, който идва специално за Kubernetes?
Дмитрий: Това е интересен въпрос, защото точно сега, в началото на Kubernetes, много хора идват при нас: „Момчета, знаем, че правите Kubernetes, направете го за нас!“ Ние им отговаряме: „Господа, ние не правим Kubernetes, ние правим prod и всичко свързано с него.“ Защото в момента е просто невъзможно да се направи продукт, без да се направят всички CI/CD и цялата тази история. Всички се отдалечиха от разделението, че имаме развитие след развитие, а след това експлоатация след експлоатация.
Нашите клиенти очакват различни неща, но всеки чака някое добро чудо, че има определени проблеми, а сега - хоп! — Kubernetes ще ги реши. Хората вярват в чудеса. В ума си те разбират, че чудо няма да има, но в душата си се надяват - ами ако този Кубернетес сега ще реши всичко вместо нас, толкова много говорят за това! Изведнъж той сега - кихане! - и сребърен куршум, кихане! — и имаме 100% ъптайм, всички разработчици могат да пуснат всичко, което влезе в производство 50 пъти, и то не се срива. Изобщо чудо!
Когато такива хора дойдат при нас, ние казваме: „Съжалявам, но няма такова нещо като чудо“. За да сте здрави, трябва да се храните добре и да спортувате. За да имате надежден продукт, той трябва да бъде направен надеждно. За да имате удобен CI/CD, трябва да го направите така. Това е много работа, която трябва да се свърши.
Отговаряйки на въпроса кой се нуждае от Kubernetes - никой не се нуждае от Kubernetes.
Някои хора имат погрешното схващане, че се нуждаят от Kubernetes. Хората се нуждаят, имат дълбока нужда да спрат да мислят, да учат и да се интересуват от всички проблеми на инфраструктурата и проблемите с изпълнението на техните приложения. Те искат приложенията просто да работят и да се разгръщат. За тях Kubernetes е надеждата, че ще спрат да чуват историята, че „лежахме там“ или „не можем да разгърнем“ или нещо друго.
Техническият директор обикновено идва при нас. Искат от него две неща: от една страна, да ни даде характеристики, от друга страна, стабилност. Предлагаме ви да се заемете сами и да го направите. Сребърният куршум, или по-скоро посребреният, е, че ще спрете да мислите за тези проблеми и да губите време. Ще имате специални хора, които ще затворят този въпрос.
Формулировката, че ние или някой друг се нуждаем от Kubernetes, е неправилна.
Администраторите наистина се нуждаят от Kubernetes, защото това е много интересна играчка, с която можете да играете и да бърникате. Нека бъдем честни – всеки обича играчки. Всички сме деца някъде и когато видим нова, искаме да я играем. За някои това е обезкуражено, например в администрацията, защото вече са играли достатъчно и вече са уморени до степен, че просто не искат. Но това не е напълно загубено за никого. Например, ако отдавна съм уморен от играчки в областта на системната администрация и DevOps, тогава все още обичам играчките, все още купувам нови. Всички хора, по един или друг начин, все още искат някакви играчки.
Няма нужда да си играете с производството. Каквото и да препоръчвам категорично да не правя и това, което виждам сега масово: "О, нова играчка!" — изтичаха да го купят, купиха го и: „Хайде сега да го занесем в училище и да го покажем на всички наши приятели.“ не прави това Извинявам се, децата ми просто растат, постоянно виждам нещо в децата, забелязвам го в себе си и след това го обобщавам за другите.
Крайният отговор е: нямате нужда от Kubernetes. Трябва да разрешите проблемите си.
Това, което можете да постигнете е:
- прод не пада;
- дори ако се опита да падне, ние знаем за това предварително и можем да вложим нещо в него;
- можем да го променим със скоростта, с която нашият бизнес го изисква, и можем да го направим удобно; това не ни създава проблеми.
Има две реални нужди: надеждност и динамика/гъвкавост на внедряването. Всеки, който в момента прави някакви ИТ проекти, независимо в какъв бизнес - софт за улесняване на света, и който разбира от това, трябва да реши тези нужди. Kubernetes с правилния подход, с правилното разбиране и с достатъчно опит ви позволява да ги разрешите.
Относно без сървър
— Ако погледнете малко по-далеч в бъдещето, опитвайки се да решите проблема с липсата на главоболия с инфраструктурата, със скоростта на внедряване и скоростта на промените в приложенията, се появяват нови решения, например без сървър. Чувствате ли някакъв потенциал в тази посока и, да кажем, опасност за Kubernetes и подобни решения?
Дмитрий: Тук отново трябва да отбележа, че аз не съм гледач, който гледа напред и казва - така ще бъде! Въпреки че току-що направих същото. Гледам си в краката и виждам куп проблеми там, например как работят транзисторите в компютъра. Смешно е, нали? Срещаме някои грешки в процесора.
Направете сървър без сървър доста надежден, евтин, ефективен и удобен, решавайки всички проблеми на екосистемата. Тук съм съгласен с Илон Мъск, че е необходима втора планета, за да се създаде толерантност към грешки за човечеството. Въпреки че не знам какво казва, разбирам, че не съм готов сам да летя до Марс и това няма да се случи утре.
При без сървър е ясно, че това е идеологически правилно нещо, като толерантността към грешки за човечеството - да имаш две планети е по-добре от една. Но как да го направя сега? Изпращането на една експедиция не е проблем, ако концентрирате усилията си върху нея. Изпращането на няколко експедиции и настаняването на няколко хиляди души, мисля, също е реалистично. Но да го направя напълно устойчив на грешки, така че половината от човечеството да живее там, сега ми се струва невъзможно, не се обмисля.
С безсървърен един към един: нещото е готино, но е далеч от проблемите на 2019 г. По-близо до 2030 г. - да доживеем. Не се съмнявам, че ще живеем, определено ще живеем (повторете преди лягане), но сега трябва да решим други проблеми. Все едно да повярваш в приказното пони Дъга. Да, няколко процента от казусите се решават и то идеално, но субективно без сървър е дъга... За мен тази тема е твърде далечна и твърде неразбираема. Не съм готов да говоря. През 2019 г. не можете да напишете нито едно приложение без сървър.
Как ще се развива Kubernetes
— Докато се придвижваме към това потенциално прекрасно далечно бъдеще, как смятате, че ще се развият Kubernetes и екосистемата около него?
Дмитрий: Мислил съм много за това и имам ясен отговор. Първият е със състояние - в крайна сметка, без състояние е по-лесно. Kubernetes първоначално инвестира повече в това, всичко започна с него. Stateless работи почти перфектно в Kubernetes, просто няма какво да се оплачете. Все още има много проблеми или по-скоро нюанси. Всичко там вече работи чудесно за нас, но това сме ние. Ще отнеме поне още няколко години, за да проработи това за всички. Това не е изчислен показател, а мое усещане от главата ми.
Накратко, statefull трябва - и ще се развива много силно, защото всички наши приложения съхраняват статус; няма приложения без състояние. Това е илюзия, винаги се нуждаете от някаква база данни и нещо друго. Statefull е за изправяне на всичко, което е възможно, коригиране на всички грешки, подобряване на всички проблеми, с които се сблъскваме в момента - нека го наречем осиновяване.
Нивото на неизвестното, нивото на нерешените проблеми, нивото на вероятността да срещнете нещо ще спадне значително. Това е важна история. И оператори - всичко, свързано с кодирането на административната логика, контролната логика, за да получим лесна услуга: MySQL лесна услуга, RabbitMQ лесна услуга, Memcache лесна услуга - като цяло всички тези компоненти, за които трябва да сме гарантирани, че работим кутията. Това просто решава болката, че искаме база данни, но не искаме да я администрираме, или искаме Kubernetes, но не искаме да я администрираме.
Тази история за развитието на оператора под една или друга форма ще бъде важна през следващите няколко години.
Мисля, че лекотата на използване трябва да се увеличи значително - кутията ще става все по-черна, все по-надеждна, с все по-прости копчета.
Веднъж слушах старо интервю с Айзък Азимов от 80-те години в YouTube в Saturday Night Live - програма като Urgant, само интересна. Попитаха го за бъдещето на компютрите. Той каза, че бъдещето е в простотата, както и радиото. Първоначално радиоприемникът беше сложно нещо. За да хванете вълна, трябваше да завъртите копчетата за 15 минути, да завъртите шишовете и като цяло да знаете как работи всичко, да разберете физиката на предаването на радиовълните. В резултат на това в радиото остана само едно копче.
Сега през 2019 г. какво радио? В колата радиоприемникът намира всички вълни и имената на станциите. Физиката на процеса не се е променила от 100 години, но лекотата на използване е. Сега, и не само сега, още през 1980 г., когато имаше интервю с Азимов, всички използваха радиото и никой не се замисли как работи. Винаги е работело - това е даденост.
Тогава Азимов каза, че същото ще бъде и с компютрите - лекотата на използване ще се увеличи. Докато през 1980 г. трябваше да бъдете обучени да натискате бутони на компютър, това няма да е така в бъдеще.
Имам чувството, че с Kubernetes и с инфраструктурата също ще има огромно увеличение на лекотата на използване. Това според мен е очевидно - лежи на повърхността.
Какво да правим с инженерите?
— Какво тогава ще се случи с инженерите и системните администратори, които поддържат Kubernetes?
Дмитрий: Какво се случи със счетоводителя след появата на 1C? За същото. Преди това са броили на хартия - сега в програмата. Производителността на труда се е увеличила с порядъци, но самият труд не е изчезнал. Ако преди бяха нужни 10 инженера, за да завият една електрическа крушка, сега един ще бъде достатъчен.
Количеството софтуер и броят на задачите, струва ми се, сега нарастват с по-бързи темпове, отколкото се появяват нови DevOps и ефективността се увеличава. В момента има специфичен дефицит на пазара и той ще продължи дълго време. По-късно всичко ще се върне към някаква нормалност, в която ефективността на работа ще се повиши, ще има все повече безсървърни сървъри, към Kubernetes ще бъде прикрепен неврон, който ще избира всички ресурси точно колкото е необходимо и като цяло ще направи всичко сам, както трябва - човекът просто се отдръпни и не се намесвай.
Но някой все пак ще трябва да взема решения. Ясно е, че нивото на квалификация и специализация на този човек е по-високо. В днешно време в счетоводството не са нужни 10 служители да водят книги, за да не им се изморяват ръцете. Просто не е необходимо. Много документи се сканират автоматично и се разпознават от системата за управление на електронни документи. Достатъчен е един умен главен счетоводител, вече с много по-големи умения, с добро разбиране.
Общо взето така трябва да се върви във всички индустрии. Същото е и с колите: преди кола идваше с механик и трима шофьори. В днешно време шофирането на автомобил е прост процес, в който всички участваме всеки ден. Никой не мисли, че колата е нещо сложно.
DevOps или системното инженерство няма да изчезнат – работата на високо ниво и ефективността ще се увеличат.
— Чух също интересна идея, че работата всъщност ще се увеличи.
Дмитрий: Разбира се, сто процента! Тъй като количеството софтуер, който пишем, непрекъснато нараства. Броят на проблемите, които решаваме със софтуер, непрекъснато нараства. Обемът на работа расте. Сега пазарът на DevOps е ужасно прегрял. Това може да се види в очакванията за заплати. В добрия смисъл, без да навлизаме в подробности, трябва да има младши, които искат X, средни, които искат 1,5X, и старши, които искат 2X. И сега, ако погледнете московския пазар на заплати на DevOps, младшият иска от X до 3X, а старшият иска от X до 3X.
Никой не знае колко струва. Нивото на заплатата се измерва с доверието ви - пълна лудница, честно казано, ужасно прегрял пазар.
Разбира се, тази ситуация ще се промени много скоро - трябва да настъпи известно насищане. Това не е така при разработката на софтуер - въпреки факта, че всеки има нужда от разработчици и всеки има нужда от добри разработчици, пазарът разбира кой колко струва - индустрията се уталожи. Това не е случаят с DevOps в наши дни.
— От това, което чух, заключих, че сегашният системен администратор не трябва да се притеснява много, но е време да надгради уменията си и да се подготви за факта, че утре ще има повече работа, но ще бъде по-високо квалифицирана.
Дмитрий: Сто процента. Като цяло живеем в 2019 г. и правилото на живота е следното: учене през целия живот – ние учим през целия си живот. Струва ми се, че сега всички вече знаят и чувстват това, но не е достатъчно да знаете - трябва да го направите. Всеки ден трябва да се променяме. Ако не го направим, рано или късно ще останем в кулоарите на професията.
Бъдете готови за резки завои на 180 градуса. Не изключвам ситуация, в която нещо се променя радикално, измисля се нещо ново - това се случва. хоп! - и сега действаме по различен начин. Важно е да сте подготвени за това и да не се притеснявате. Може да се случи утре всичко, което правя, да се окаже ненужно – нищо, цял живот съм учил и съм готов да науча още нещо. Не е проблем. Няма нужда да се страхувате за сигурността на работата, но трябва да сте готови постоянно да научавате нещо ново.
Пожелания и минутка реклама
- Имате ли желание?
Дмитрий: Да, имам няколко желания.
Първи и меркантилен - абонирайте се . Уважаеми читатели, отидете в YouTube и се абонирайте за нашия канал. След около месец ще започнем активно разширяване на видео услугата. Ще имаме много образователно съдържание за Kubernetes, отворено и разнообразно: от практически неща, чак до лаборатории, до дълбоки фундаментални теоретични неща и как да използвате Kubernetes в ниво на принципи и модели.
Второто меркантилно желание - отидете на и слагаме звезди, защото се храним с тях. Ако не ни дадете звезди, няма да имаме какво да ядем. Това е като мана в компютърна игра. Правим нещо, правим, опитваме, някой казва, че това са ужасни велосипеди, някой, че всичко е напълно погрешно, но ние продължаваме и действаме абсолютно честно. Виждаме проблем, решаваме го и споделяме опита си. Затова дайте ни звезда, тя няма да си отиде от вас, но ще дойде при нас, защото ние се храним с тях.
Трето, важно и вече не меркантилно желание - спрете да вярвате в приказките. Вие сте професионалисти. DevOps е много сериозна и отговорна професия. Спрете да играете на работното място. Нека щракне за вас и ще го разберете. Представете си, че идвате в болницата и там лекарят експериментира с вас. Разбирам, че това може да е обидно за някого, но най-вероятно не става въпрос за вас, а за някой друг. Кажете и на другите да спрат. Това наистина съсипва живота на всички нас - мнозина започват да третират операциите, администраторите и DevOps като пичове, които отново са счупили нещо. Това се „разваляше“ най-често поради факта, че отивахме да играем, а не гледахме със студено съзнание, че това е така и това е така.
Това не означава, че не трябва да експериментирате. Трябва да експериментираме, ние го правим сами. Честно казано, ние самите понякога играем игри - това, разбира се, е много лошо, но нищо човешко не ни е чуждо. Нека обявим 2019 г. за година на сериозни, добре обмислени експерименти, а не на игри в производството. Вероятно е така.
- Благодаря ти много!
Дмитрий: Благодаря ви, Виталий, както за времето, така и за интервюто. Уважаеми читатели, много ви благодаря, ако внезапно сте стигнали дотук. Надяваме се, че сме ви донесли поне няколко мисли.
В интервюто Дмитрий засегна въпроса за werf. Сега това е универсален швейцарски нож, който решава почти всички проблеми. Но не винаги е било така. На на фестивала Дмитрий Столяров ще ви разкаже подробно за този инструмент. в доклада ще има всичко: проблеми и скрити нюанси на Kubernetes, опции за решаване на тези трудности и текущото изпълнение на werf в детайли. Присъединете се към нас на 27 и 28 май, ние ще създадем перфектните инструменти.
Източник: www.habr.com