Во исчекување Виталиј Хабаров интервјуирани Дмитриј Столјаров (), технички директор и ко-основач на компанијата Флант. Виталиј го праша Дмитриј за тоа што работи Флант, за Кубернетес, развој на екосистемот, поддршка. Разговаравме зошто е потребен Kubernetes и дали е воопшто потребен. И, исто така, за микросервисите, Amazon AWS, пристапот „Ќе имам среќа“ кон DevOps, иднината на самиот Kubernetes, зошто, кога и како ќе го преземе светот, изгледите на DevOps и за што треба да се подготват инженерите во светла и блиска иднина со поедноставување и невронски мрежи.
слушајте како подкаст на DevOps Deflop - подкаст на руски јазик за DevOps, а подолу е текстуалната верзија.
Овде и подолу поставува прашања инженер од Express42.
За „Flant“
- Здраво Дима. Вие сте технички директор““, а исто така и нејзиниот основач. Ве молиме кажете ни што работи компанијата и што сте вие во неа?
Дмитриј: Однадвор се чини дека ние сме момците кои одат наоколу инсталирајќи Kubernetes за сите и прават нешто со него. Но, тоа не е вистина. Започнавме како компанија која се занимава со Linux, но долго време наша главна дејност беше сервисирање на производство и проекти со големо оптоварување клуч на рака. Обично ја градиме целата инфраструктура од нула и потоа сме одговорни за тоа долго, долго време. Затоа, главната работа што ја работи „Флант“ и за која добива пари е преземање одговорност и спроведување на производството со клуч на рака.
Јас, како технички директор и еден од основачите на компанијата, поминувам цел ден и ноќ обидувајќи се да сфатам како да ја зголемам достапноста на производството, да го поедноставам неговото работење, да го олеснам животот на администраторите, а животот на програмерите попријатен .
За Кубернетес
- Во последно време гледам многу извештаи од Флант и за Кубернетес. Како дојдовте до тоа?
Дмитриј: Веќе сум зборувал за ова многу пати, но воопшто не ми пречи да го повторувам. Мислам дека е правилно да се повтори оваа тема бидејќи има конфузија помеѓу причината и последицата.
Навистина ни требаше алатка. Се соочивме со многу проблеми, се мачевме, ги совладавме со разни патерици и почувствувавме потреба од алатка. Поминавме низ многу различни опции, направивме сопствени велосипеди и стекнавме искуство. Постепено стигнавме до точка каде што почнавме да го користиме Docker речиси веднаш штом се појави - околу 2013 година. Во времето на неговото појавување, веќе имавме многу искуство со контејнери, веќе имавме напишано аналог на „Докер“ - некои од нашите сопствени патерици во Пајтон. Со доаѓањето на Докер, стана возможно да се исфрлат патериците и да се користи сигурно и поддржано решение од заедницата.
Со Kubernetes приказната е слична. Кога почна да добива на интензитет - за нас ова е верзија 1.2 - веќе имавме еден куп патерици и на Шел и на Шеф, кои некако се обидовме да ги оркестрираме со Докер. Сериозно гледавме кон Ранчер и разни други решенија, но потоа се појави Кубернетес, во кој сè е имплементирано точно како што би направиле или уште подобро. Нема што да се жали.
Да, има некаква несовршеност овде, има некаква несовршеност таму - има многу несовршености, а 1.2 е генерално страшно, но... Кубернетес е како зграда во изградба - погледнете го проектот и разбирате дека ќе биде кул. Ако зградата сега има основа и два ката, тогаш разбирате дека е подобро да не се вселите сè уште, но нема такви проблеми со софтверот - веќе можете да го користите.
Немавме момент кога размислувавме дали да го користиме Кубернетес или не. Го чекавме долго пред да се појави и се обидовме самите да создадеме аналози.
За Кубернетес
- Дали сте директно вклучени во развојот на самиот Кубернетес?
Дмитриј: Просечно. Наместо тоа, ние учествуваме во развојот на екосистемот. Испраќаме одреден број барања за повлекување: до Прометеј, до разни оператори, до Хелм - до екосистемот. За жал, не можам да следам сè што правиме и може да грешам, но нема ниту еден базен од нас во јадрото.
- Во исто време, дали развивате многу од вашите алатки околу Кубернетес?
Дмитриј: Стратегијата е оваа: одиме и повлекуваме барања до сè што веќе постои. Ако барањата за повлекување не се прифатат таму, ние едноставно самите ги разбиваме и живееме додека не бидат прифатени со нашите градби. Потоа, кога ќе стигне до upstream, се враќаме на upstream верзијата.
На пример, имаме оператор Prometheus, со кој се префрливме напред-назад на спротиводно од нашиот склоп веројатно веќе 5 пати. Ни треба некаква функција, испративме барање за повлекување, треба да ја објавиме утре, но не сакаме да чекаме да биде пуштена нагоре. Соодветно на тоа, ние собираме за себе, го расфрламе нашето склопување со нашата карактеристика, која ни е потребна поради некоја причина, на сите наши кластери. Потоа, на пример, ни го превртуваат во возводно со зборовите: „Момци, да го направиме тоа за поопшт случај“, ние или некој друг го завршуваме и со текот на времето повторно се спојува.
Се трудиме да развиеме се што постои. Многу елементи кои сè уште не постојат, сè уште не се измислени или се измислени, но немале време да ги спроведат - ние тоа го правиме. И не затоа што ни се допаѓа процесот или изградбата на велосипеди како индустрија, туку едноставно затоа што ни е потребна оваа алатка. Често се поставува прашањето зошто го направивме ова или она нешто? Одговорот е едноставен - да, затоа што моравме да одиме понатаму, да решиме некој практичен проблем и го решивме со оваа тула.
Патеката е секогаш вака: бараме многу внимателно и, ако не најдеме решение како да направиме тролејбус од леб, тогаш правиме свој леб и сопствен тролејбус.
Flanta алатки
— Знам дека Flant сега има дополнителни оператори, оператори на школка и алатки dapp/werf. Како што разбирам, ова е истиот инструмент во различни инкарнации. Разбирам и дека има многу повеќе различни алатки во Flaunt. Ова е вистина?
Дмитриј: Имаме многу повеќе на GitHub. Од она што сега се сеќавам, имаме статус мапа - панел за Графана на кој сите наишле. Се споменува речиси во секоја втора статија за мониторингот на Кубернетес на Медиум. Невозможно е накратко да се објасни што е мапа на статус - потребна е посебна статија, но тоа е многу корисна работа за следење на статусот со текот на времето, бидејќи во Кубернетес честопати треба да го прикажуваме статусот со текот на времето. Имаме и LogHouse - ова е нешто засновано на ClickHouse и црна магија за собирање дневници во Kubernetes.
Многу комунални услуги! А ќе има уште повеќе, бидејќи оваа година ќе бидат пуштени низа интерни решенија. Од многу големите базирани на операторот за додатоци, има еден куп додатоци за Kubernetes, ала како правилно да се инсталира sert manager - алатка за управување со сертификати, како правилно да се инсталира Prometheus со куп додатоци - ова се околу дваесет различни бинарни датотеки што извезуваат податоци и собираат нешто, на овој Прометеј ги има најневеројатните графики и предупредувања. Сето ова е само еден куп додатоци на Kubernetes, кои се инсталирани во кластер и се претвора од едноставно во кул, софистицирано, автоматски, во кое веќе се решени многу прашања. Да, правиме многу.
Развој на екосистемот
„Ми се чини дека ова е многу голем придонес за развојот на овој инструмент и неговите методи на употреба“. Можете ли грубо да процените кој друг би го дал истиот придонес во развојот на екосистемот?
Дмитриј: Во Русија, од компаниите што работат на нашиот пазар, никој не е ни близок. Се разбира, ова е гласна изјава, бидејќи има големи играчи како Mail и Yandex - тие исто така прават нешто со Kubernetes, но дури и тие не се приближуваат до придонесот на компаниите во целиот свет кои прават многу повеќе од нас. Тешко е да се споредат Flant, кој има персонал од 80 луѓе, и Red Hat, кој има 300 инженери само по Кубернет, ако не се лажам. Тешко е да се споредува. Имаме 6 луѓе во одделот за RnD, вклучувајќи ме и мене, кои ни ги сечат сите алатки. 6 луѓе наспроти 300 инженери на Red Hat - некако е тешко да се спореди.
- Меѓутоа, кога и овие 6 луѓе можат да направат нешто навистина корисно и отуѓувачко, кога ќе се соочат со практичен проблем и ќе го дадат решението на заедницата - интересен случај. Разбирам дека во големите технолошки компании, каде што имаат свој тим за развој и поддршка на Kubernetes, во принцип, може да се развијат истите алатки. Ова е пример за нив за тоа што може да се развие и да се даде на заедницата, давајќи им поттик на целата заедница која користи Kubernetes.
Дмитриј: Ова е веројатно карактеристика на интеграторот, неговата особеност. Имаме многу проекти и гледаме многу различни ситуации. За нас главен начин да создадеме додадена вредност е да ги анализираме овие случаи, да најдеме заедништво и да ни ги направиме што е можно поевтини. Активно работиме на ова. Тешко ми е да зборувам за Русија и светот, но имаме околу 40 инженери DevOps во компанијата кои работат на Kubernetes. Мислам дека нема многу компании во Русија со споредлив број специјалисти кои го разбираат Кубернетес, ако воопшто ги има.
Разбирам сè за работното место инженер DevOps, секој разбира сè и е навикнат да ги нарекува инженерите DevOps инженери DevOps, нема да разговараме за ова. Сите овие 40 неверојатни инженери на DevOps се соочуваат и решаваат проблеми секој ден, ние само го анализираме ова искуство и се обидуваме да го генерализираме. Разбираме дека ако остане во нас, тогаш за година или две алатката ќе биде бескорисна, бидејќи некаде во заедницата ќе се појави готова Тула. Нема смисла да се акумулира ова искуство внатрешно - едноставно се троши енергија и време во dev/null. И воопшто не ни е жал за тоа. Ние објавуваме сè со големо задоволство и разбираме дека треба да се објави, развие, промовира, промовира, за луѓето да го користат и да го додадат своето искуство - тогаш сè расте и живее. Потоа по две години инструментот не оди во ѓубре. Не е тажно да продолжите да истурате сила, бидејќи е јасно дека некој ја користи вашата алатка, а по две години сите ја користат.
Ова е дел од нашата голема стратегија со dapp/werf. Не се сеќавам кога почнавме да го правиме, изгледа како пред 3 години. Првично, тоа беше генерално на школка. Тоа беше супер доказ за концепт, решивме некои од нашите конкретни проблеми - успеа! Но, има проблеми со школка, невозможно е да се прошири понатаму, програмирањето на школка е друга задача. Имавме навика да пишуваме во Руби, соодветно, преправивме нешто во Руби, развивме, развивме, развивме и наидовме на фактот дека заедницата, толпата што не вели „го сакаме или не го сакаме, “ го врти носот кон Руби, колку е тоа смешно? Сфативме дека треба да ги напишеме сите овие работи во Go само за да ја исполниме првата точка од списокот за проверка: Алатката DevOps треба да биде статична бинарна форма. Да се биде Go или не не е толку важно, но статичен бинарен напишан во Go е подобар.
Ја потрошивме нашата енергија, го преработивме дап во Го и го нарековме верф. Dapp веќе не е поддржан, не е развиен, работи во некоја најнова верзија, но има апсолутна патека за надградба до врвот и можете да ја следите.
Зошто е создаден дап?
— Можете ли накратко да ни кажете зошто е создаден дап, кои проблеми решава?
Дмитриј: Првата причина е во собранието. Првично, имавме сериозни проблеми со изградбата кога Docker немаше повеќестепени можности, па сами направивме повеќестепени. Потоа имавме уште еден куп проблеми со чистењето на сликата. Сите што прават CI/CD, порано отколку подоцна, се соочуваат со проблемот дека има куп собрани слики, треба некако да го исчистите она што не е потребно и да го оставите потребното.
Втората причина е распоредувањето. Да, има Helm, но решава само некои од проблемите. Доволно смешно, напишано е дека „Хелм е менаџер на пакети за Кубернетес“. Токму она што е „на“. Има и зборови „Управник со пакети“ - кое е вообичаеното очекување од менаџерот на пакети? Велиме: „Управувач со пакети - инсталирајте го пакетот!“ и очекуваме да ни каже: „Пакетот е испорачан“.
Интересно е што велиме: „Хелм, инсталирај го пакетот“, а кога тој ќе одговори дека го инсталирал, излегува дека штотуку ја започнал инсталацијата - тој го посочи Кубернетес: „Стани ја оваа работа!“, и дали започнала или не , без разлика дали работи или не, Хелм воопшто не го решава ова прашање.
Излегува дека Helm е само текстуален препроцесор кој вчитува податоци во Kubernetes.
Но, како дел од секое распоредување, сакаме да знаеме дали апликацијата е пуштена во производство или не? Префрлено во прод значи дека апликацијата е преместена таму, новата верзија е распоредена и барем таму не паѓа и реагира правилно. Хелм не го решава овој проблем на кој било начин. За да го решите, треба да потрошите многу напор, бидејќи треба да му дадете на Kubernetes командата да се појави и да следи што се случува таму - дали е распоредено или пуштено. Исто така, има многу задачи поврзани со распоредување, чистење и склопување.
Планови
Оваа година ќе започнеме со локален развој. Сакаме да го постигнеме она што беше претходно во Vagrant - напишавме „vagrant up“ и распоредивме виртуелни машини. Сакаме да дојдеме до точка каде што има проект во Git, пишуваме „werf up“ таму и се појавува локална копија од овој проект, распоредена во локален мини-Kub, со поврзани сите директориуми погодни за развој. . Во зависност од јазикот за развој, ова се прави поинаку, но сепак, така што локалниот развој може практично да се изврши под монтирани датотеки.
Следниот чекор за нас е инвестирајте во погодност за програмерите. За брзо распоредување на проект локално со една алатка, развијте го, турнете го во Git, а исто така ќе се појави во фаза или тестирање, во зависност од цевководите, а потоа користете ја истата алатка за да отидете на производство. Ова единство, обединување, репродуктивност на инфраструктурата од локалната средина до продажбата е многу важен момент за нас. Но, ова сè уште не е во верф - ние само планираме да го направиме тоа.
Но, патот до dapp/werf отсекогаш бил ист како кај Кубернетес на почетокот. Наидовме на проблеми, ги решивме со решенија - дојдовме до некои решенија за себе на школка, за било што. Потоа тие се обидоа некако да ги исправат овие решенија, да ги генерализираат и консолидираат во бинарни датотеки во овој случај, кои едноставно ги споделуваме.
Има и друг начин да се погледне целата оваа приказна, со аналогии.
Kubernetes е рамка за автомобил со мотор. Нема врати, стакло, радио, елка - ништо. Само рамката и моторот. И тука е Helm - ова е воланот. Кул - има волан, но ви треба и игла за волан, багажник, менувач и тркала, и не можете без нив.
Во случајот на верф, ова е уште една компонента на Кубернетес. Само сега во алфа верзијата на верфот, на пример, Helm е компајлиран внатре во верф, затоа што сме уморни сами да го правиме тоа. Има многу причини да го направите ова, ќе ви кажам детално зошто го составивме целото кормило заедно со бокал внатре во верф .
Сега верфот е поинтегрирана компонента. Добиваме готов волан, игла за волан - не сум многу добар во автомобили, но ова е голем блок што веќе решава прилично широк спектар на проблеми. Не треба сами да го поминуваме каталогот, да избираме еден дел за друг, да размислуваме како да ги навртуваме заедно. Добиваме готов комбајн кој решава голем број проблеми одеднаш. Но, внатре е изграден од истите компоненти со отворен код, сè уште користи Docker за склопување, Helm за дел од функционалноста, а има и неколку други библиотеки. Ова е интегрирана алатка за брзо и практично ослободување на CI/CD од кутијата.
Дали е тешко да се одржува Кубернетес?
— Зборувате за искуството што почнавте да го користите Kubernetes, ова е рамка за вас, мотор и дека можете да закачите многу различни работи на неа: каросерија, волан, завртки на педали, седишта. Се поставува прашањето - колку ви е тешка поддршката на Кубернетес? Имате големо искуство, колку време и ресурси трошите за поддршка на Кубернетес изолирано од се друго?
Дмитриј: Ова е многу тешко прашање и за да одговориме, треба да разбереме што е поддршка и што сакаме од Кубернетес. Можеби можеш да откриеш?
- Колку што знам и како што гледам, сега многу тимови сакаат да го пробаат Кубернетес. Секој се впрегнува во него, го става на колена. Имам чувство дека луѓето не секогаш ја разбираат сложеноста на овој систем.
Дмитриј: Така е.
— Колку е тешко да се земе и инсталира Kubernetes од почеток за да биде подготвен за производство?
Дмитриј: Што мислите, колку е тешко да се пресади срце? Разбирам дека ова е компромитирачко прашање. Да користите скалпел и да не направите грешка не е толку тешко. Ако ви кажат каде да сечете и каде да шиете, тогаш самата процедура не е комплицирана. Тешко е да се гарантира одвреме-навреме дека сè ќе успее.
Лесно е да се инсталира Kubernetes и да се работи: пиле! — инсталирано, има многу методи за инсталација. Но, што се случува кога ќе се појават проблеми?
Секогаш се поставуваат прашања - што сè уште не сме земале предвид? Што не сме направиле уште? Кои параметри на кернелот на Линукс беа наведени погрешно? Господи, дали воопшто ги спомнавме?! Кои компоненти на Кубернетес ги испорачавме, а кои не? Се појавуваат илјадници прашања, а за да одговорите на нив, треба да поминете 15-20 години во оваа индустрија.
Имам неодамнешен пример на оваа тема што може да го открие значењето на проблемот „Дали Кубернетс е тежок за одржување? Пред некое време сериозно размислувавме дали треба да се обидеме да го имплементираме Cilium како мрежа во Кубернетес.
Да објаснам што е тоа Cilium. Kubernetes има многу различни имплементации на потсистемот за вмрежување, а една од нив е многу кул - Cilium. Кое е неговото значење? Во кернелот, пред некое време стана возможно да се пишуваат куки за кернелот, кои на еден или друг начин го напаѓаат мрежниот потсистем и разни други потсистеми и ви дозволуваат да заобиколите големи делови во кернелот.
Линукс кернелот историски има ip рут, префилтер, мостови и многу различни стари компоненти кои се стари 15, 20, 30 години. Во глобала работат, се е супер, но сега натрупаа контејнери, и изгледа како кула од 15 тули една врз друга, а на едната нога стоиш на неа - чудно чувство. Овој систем историски се развивал со многу нијанси, како слепото црево во телото. Во некои ситуации има проблеми со перформансите, на пример.
Има прекрасен BPF и можност за пишување куки за јадрото - момците напишаа свои куки за кернелот. Пакетот доаѓа во кернелот на Линукс, го вадат токму на влезот, сами го обработуваат како што треба без мостови, без TCP, без стек IP - накратко, заобиколувајќи се што е напишано во кернелот на Линукс и потоа плукаат извадете го во контејнерот.
Што се случи? Многу кул изведба, одлични карактеристики - само кул! Но, ние го гледаме ова и гледаме дека на секоја машина има програма што се поврзува со Kubernetes API и, врз основа на податоците што ги добива од ова API, генерира C код и компајлира бинарни датотеки што ги вчитува во кернелот, така што овие куки работат во просторот на јадрото.
Што се случува ако нешто тргне наопаку? Ние не знаеме. За да го разберете ова, треба да го прочитате целиот овој код, да ја разберете целата логика и неверојатно е колку е тешко. Но, од друга страна, постојат овие мостови, мрежни филтри, рутирање на IP - не сум го прочитал нивниот изворен код, а не го имаат ниту 40-те инженери кои работат во нашата компанија. Можеби само малкумина разбираат некои делови.
И која е разликата? Излегува дека има ip рут, кернелот на Линукс и има нова алатка - каква разлика прави тоа, ние не го разбираме едното или другото. Но, ние се плашиме да користиме нешто ново - зошто? Затоа што ако алатката е стара 30 години, тогаш за 30 години сите грешки се пронајдени, сите грешки се нагазиле и не треба да знаете за сè - работи како црна кутија и секогаш работи. Секој знае кој дијагностички шрафцигер на кое место да залепи, кој tcpdump да работи во кој момент. Секој добро ги познава дијагностичките алатки и разбира како функционира овој сет на компоненти во кернелот на Linux - не како функционира, туку како да го користи.
И неверојатно кул Cilium нема 30 години, сè уште не е стар. Кубернетес го има истиот проблем, копирајте. Дека Cilium е совршено инсталиран, дека Kubernetes е инсталиран совршено, но кога нешто тргне наопаку во производството, дали можете брзо да разберете во критична ситуација што тргна наопаку?
Кога велиме дали е тешко да се одржува Кубернетес - не, тоа е многу лесно, и да, тоа е неверојатно тешко. Kubernetes работи одлично сам по себе, но со милијарда нијанси.
За пристапот „Ќе имам среќа“.
- Дали има компании каде што овие нијанси речиси гарантирано ќе се појават? Да претпоставиме дека Yandex одеднаш ги префрли сите услуги на Kubernetes, таму ќе има огромен товар.
Дмитриј: Не, ова не е муабет за товарот, туку за наједноставните работи. На пример, имаме Kubernetes, ја распоредивме апликацијата таму. Како знаеш дека работи? Едноставно нема готова алатка за да се разбере дека апликацијата не паѓа. Не постои готов систем што испраќа предупредувања; треба да ги конфигурирате овие предупредувања и секој распоред. И ние го ажурираме Kubernetes.
Имам Ubuntu 16.04. Може да се каже дека ова е стара верзија, но ние сè уште сме на неа бидејќи е LTS. Постои systemd, чија нијанса е дека не ги чисти C-групите. Kubernetes лансира подлоги, создава C-групи, потоа ги брише мешунките и некако испаѓа - не се сеќавам на деталите, извинете - остануваат системските парчиња. Ова води до фактот дека со текот на времето, секој автомобил почнува силно да успорува. Ова дури и не е прашање за highload. Ако се активираат постојани подлоги, на пример, ако постои Cron Job што постојано генерира подлоги, тогаш машината со Ubuntu 16.04 ќе почне да забавува по една недела. Ќе има постојано висок просек на оптоварување поради фактот што се создадени еден куп C-групи. Ова е проблемот со кој ќе се соочи секое лице кое едноставно инсталира Ubuntu 16 и Kubernetes на врвот.
Да речеме дека некако го ажурира системот или нешто друго, но во кернелот Линукс до 4.16 е уште посмешно - кога ги бришете C-групите, тие протекуваат во кернелот и всушност не се бришат. Затоа, по еден месец работа на оваа машина, ќе биде невозможно да се погледне статистиката за меморија за огништата. Извадиме датотека, ја превртуваме во програмата и една датотека се тркала 15 секунди, бидејќи на кернелот му треба многу време за да изброи милион C-групи во себе, кои изгледаат како да се избришани, но не - тие протекуваат .
Сè уште има многу такви ситници овде и таму. Ова не е проблем со кој гигантските компании понекогаш може да се соочат под многу тешки товари - не, тоа е прашање на секојдневни работи. Луѓето можат да живеат вака со месеци - инсталираа Kubernetes, ја распоредија апликацијата - изгледа дека функционира. За многу луѓе ова е нормално. Тие дури и нема да знаат дека оваа апликација ќе се сруши поради некоја причина, нема да добијат предупредување, но за нив ова е норма. Претходно, живеевме на виртуелни машини без мониторинг, сега се преселивме во Кубернетес, исто така без мониторинг - што е разликата?
Прашањето е дека кога одиме по мраз, никогаш не ја знаеме неговата дебелина освен ако не ја измериме однапред. Многу луѓе пешачат и не грижете се, затоа што пешачеле претходно.
Од моја гледна точка, нијансата и сложеноста на функционирањето на кој било систем е да се осигура дека дебелината на мразот е точно доволна за да ги решиме нашите проблеми. Ова е она за што зборуваме.
Во ИТ, ми се чини, има премногу пристапи „Ќе имам среќа“. Многу луѓе инсталираат софтвер и користат софтверски библиотеки со надеж дека ќе имаат среќа. Во принцип, многу луѓе имаат среќа. Веројатно затоа функционира.
— Според мојата песимистичка проценка, изгледа вака: кога ризиците се високи, а апликацијата мора да работи, тогаш потребна е поддршка од Flaunt, можеби од Red Hat, или потребен ви е сопствен внатрешен тим посветен специјално на Kubernetes, кој е подготвен да го извлечеш.
Дмитриј: Објективно, тоа е така. Самостојното влегување во приказната за Кубернетес за мал тим вклучува голем број ризици.
Дали ни требаат контејнери?
- Можете ли да ни кажете колку е распространет Kubernetes во Русија?
Дмитриј: Ги немам овие податоци и не сум сигурен дека некој друг ги има. Ние велиме: „Kubernetes, Kubernetes“, но има и друг начин на гледање на ова прашање. Исто така, не знам колку се распространети контејнерите, но знам бројка од извештаите на Интернет дека 70% од контејнерите се оркестрирани од Kubernetes. Тоа беше сигурен извор за прилично голем примерок ширум светот.
Потоа уште едно прашање - дали ни требаат контејнери? Моето лично чувство и целокупната позиција на компанијата Флант е дека Кубернетес е де факто стандард.
Нема да има ништо друго освен Кубернетес.
Ова е апсолутна промена на играта во областа на управувањето со инфраструктурата. Само апсолутно - тоа е тоа, нема повеќе Ansible, Шеф, виртуелни машини, Terraform. Не зборувам за старите методи на колективна фарма. Кубернетес е апсолутен менувач, а сега само вака ќе биде.
Јасно е дека на некого му требаат неколку години, а на други неколку децении за да го сфатат ова. Не се сомневам дека нема да има ништо друго освен Kubernetes и овој нов изглед: повеќе не го оштетуваме оперативниот систем, туку користиме инфраструктура како код, само не со код, туку со yml - декларативно опишана инфраструктура. Имам чувство дека секогаш ќе биде вака.
— Односно, оние компании кои сè уште не се префрлиле на Кубернетес дефинитивно ќе се префрлат на него или ќе останат во заборав. Те разбрав правилно?
Дмитриј: Ова исто така не е сосема точно. На пример, ако имаме задача да работиме DNS сервер, тогаш тој може да се работи на FreeBSD 4.10 и може да работи совршено 20 години. Само работете и тоа е тоа. Можеби за 20 години нешто ќе треба еднаш да се ажурира. Ако зборуваме за софтвер во форматот што го лансиравме и тој всушност работи многу години без никакви ажурирања, без да прави промени, тогаш, се разбира, нема да има Kubernetes. Тој не е потребен таму.
Сè што е поврзано со CI/CD - секаде каде што е потребна континуирана испорака, каде што треба да ажурирате верзии, да правите активни промени, секаде каде што треба да изградите толеранција на грешки - само Kubernetes.
За микросервисите
- Тука имам мала дисонанца. За да работите со Kubernetes, потребна ви е надворешна или внатрешна поддршка - ова е првата точка. Второ, кога штотуку почнуваме со развој, ние сме мал стартап, сè уште немаме ништо, развојот за Kubernetes или микросервисната архитектура воопшто може да биде сложен и не секогаш економски оправдан. Ме интересира вашето мислење - дали стартапите треба веднаш да почнат да пишуваат за Kubernetes од нула, или сè уште можат да напишат монолит, а потоа само да дојдат на Kubernetes?
Дмитриј: Убаво прашање. Имам муабет за микросервисите Многупати сум сретнал луѓе кои се обидуваат да зачукаат клинци со микроскоп. Самиот пристап е точен, ние самите го дизајнираме нашиот внатрешен софтвер на овој начин. Но, кога го правите ова, треба јасно да разберете што правите. Зборот што најмногу го мразам за микросервисите е „микро“. Историски гледано, овој збор потекнува од таму, и поради некоја причина луѓето мислат дека микро е многу мал, помалку од милиметар, како микрометар. Ова е погрешно.
На пример, постои монолит што го пишуваат 300 луѓе, а сите што учествувале во развојот разбираат дека таму има проблеми и треба да се скрши на микро-парчиња - околу 10 парчиња, од кои секоја е напишана од 30 луѓе. во минимална верзија. Ова е важно, неопходно и кул. Но, кога ќе ни дојде стартап, каде 3 многу кул и талентирани момци напишаа 60 микросервиси на колена, секој пат кога барам Corvalol.
Ми се чини дека за ова веќе се зборуваше илјадници пати - добивме дистрибуиран монолит во една или друга форма. Ова не е економски оправдано, општо е многу тешко во се. Само што го видов ова толку многу пати што навистина ме боли, па продолжувам да зборувам за тоа.
На првичното прашање, постои конфликт помеѓу фактот дека, од една страна, Kubernetes е страшен за употреба, бидејќи не е јасно што може да се скрши таму или да не работи, од друга страна, јасно е дека сè оди таму. и ништо друго освен Кубернетес нема да постои. Одговор - измерете ја количината на корист што доаѓа, количината на задачи што можете да ги решите. Ова е на едната страна од вагата. Од друга страна, постојат ризици поврзани со времето на застој или со намалување на времето на одговор, ниво на достапност - со намалување на индикаторите за перформанси.
Еве го - или се движиме брзо, а Kubernetes ни дозволува да правиме многу работи многу побрзо и подобро, или користиме сигурни решенија проверени со време, но се движиме многу побавно. Ова е избор што секоја компанија мора да го направи. Можете да го замислите како патека во џунглата - кога одите за прв пат, можете да сретнете змија, тигар или луд јазовец, а кога сте пешачеле 10 пати, сте ја изгазиле патеката, отстранети гранките и полесно одат. Секој пат кога патеката станува поширока. Потоа е асфалтен пат, а подоцна убав булевар.
Кубернетес не стои. Повторно прашање: Kubernetes, од една страна, е 4-5 бинарни, од друга страна, тоа е целиот екосистем. Ова е оперативниот систем што го имаме на нашите машини. Што е ова? Ubuntu или Curios? Ова е кернелот на Линукс, куп дополнителни компоненти. Сите овие работи овде, една змија отровна е исфрлена од патот, таму е подигната ограда. Kubernetes се развива многу брзо и динамично, а обемот на ризици, обемот на непознатото се намалува секој месец и, соодветно, овие скали се ребалансираат.
Одговарајќи на прашањето што треба да направи стартап, би рекол - дојди во Flaunt, плати 150 илјади рубли и добиј лесна услуга DevOps со клуч на рака. Ако сте мал стартап со неколку програмери, ова функционира. Наместо да ангажирате свои DevOps, кои ќе треба да научат како да ги решаваат вашите проблеми и да исплатат плата во овој момент, ќе добиете решение со клуч на рака за сите прашања. Да, има некои недостатоци. Ние како аутсорсер не можеме да бидеме толку вклучени и брзо да реагираме на промените. Но, имаме многу експертиза и готови практики. Гарантираме дека во секоја ситуација дефинитивно брзо ќе го сфатиме и ќе го подигнеме секој Кубернет од мртвите.
Силно препорачувам аутсорсинг на стартапи и етаблирани бизниси до големина до која можете да посветите тим од 10 луѓе на операции, бидејќи во спротивно нема смисла. Дефинитивно има смисла да се нарачува ова.
За Амазон и Гугл
— Може ли домаќин од решение од Амазон или Гугл да се смета за аутсорсинг?
Дмитриј: Да, се разбира, ова решава голем број прашања. Но, повторно има нијанси. Сè уште треба да разберете како да го користите. На пример, има илјада мали нешта во работата на Amazon AWS: Load Balancer треба да се загрее или мора однапред да се напише барање дека „момци, ќе добиеме сообраќај, загрејте го Load Balancer за нас! Треба да ги знаете овие нијанси.
Кога ќе се обратите до луѓе кои се специјализирани за ова, ќе ги затворите речиси сите типични работи. Сега имаме 40 инженери, до крајот на годината веројатно ќе бидат 60 - дефинитивно ги сретнавме сите овие работи. Дури и ако повторно наидеме на овој проблем на некој проект, брзо се прашуваме и знаеме како да го решиме.
Веројатно одговорот е - се разбира, хостирана приказна прави одреден дел полесен. Прашањето е дали сте подготвени да им верувате на овие хостери и дали тие ќе ви ги решат проблемите. Амазон и Гугл направија добро. За сите наши случаи - точно. Немаме повеќе позитивни искуства. Сите други облаци со кои се обидовме да работиме создаваат многу проблеми - Ager, и сè што е во Русија, и сите видови OpenStack во различни имплементации: Headster, Overage - што сакате. Сите тие создаваат проблеми кои не сакате да ги решите.
Затоа, одговорот е да, но, всушност, нема многу зрели хостирани решенија.
Кому му треба Кубернетес?
- А сепак, кому му треба Кубернетес? Кој веќе треба да се префрли на Kubernetes, кој е типичен клиент на Flaunt кој доаѓа специјално за Kubernetes?
Дмитриј: Ова е интересно прашање, бидејќи токму сега, во пресрет на Кубернетите, многу луѓе доаѓаат кај нас: „Момци, знаеме дека правите Кубернети, направете го тоа за нас! Ние им одговараме: „Господа, ние не правиме Кубернетес, ние правиме поттикнување и се што е поврзано со тоа“. Затоа што моментално е едноставно невозможно да се направи производ без да се направат сите CI/CD и целата оваа приказна. Сите се оддалечија од поделбата дека имаме развој по развој, а потоа експлоатација по експлоатација.
Нашите клиенти очекуваат различни работи, но сите чекаат некое добро чудо дека имаат одредени проблеми, а сега - хоп! — Кубернетес ќе ги реши. Луѓето веруваат во чуда. Во нивните умови тие разбираат дека нема да има чудо, но во нивните души се надеваат - што ако овој Кубернет сега ќе ни реши сè, толку многу зборуваат за тоа! Одеднаш тој сега - кивнете! - и сребрен куршум, кивави! - и имаме 100% време на работа, сите програмери можат да пуштат се што ќе влезе во производство 50 пати, и тоа не се урива. Во принцип, чудо!
Кога таквите луѓе доаѓаат кај нас, ние велиме: „Извинете, но не постои такво нешто како чудо“. За да бидете здрави, треба да јадете добро и да вежбате. За да имате сигурен производ, тој треба да се направи сигурно. За да имате погодно CI/CD, треба да го направите вака. Тоа е многу работа што треба да се заврши.
Одговарајќи на прашањето кому му треба Кубернет - никому не му треба Кубернет.
Некои луѓе имаат заблуда дека им требаат Кубернети. На луѓето им треба, тие имаат длабока потреба да престанат да размислуваат, учат и да се интересираат за сите проблеми на инфраструктурата и проблемите на водење на нивните апликации. Тие сакаат апликациите само да работат и само да се распоредат. За нив, Кубернетис е надежта дека ќе престанат да ја слушаат приказната дека „лежевме таму“, или „не можеме да излеземе“ или нешто друго.
Кај нас најчесто доаѓа техничкиот директор. Го прашуваат две работи: од една страна да ни даде карактеристики, од друга страна стабилност. Ви предлагаме да го преземете на себе и да го направите тоа. Сребрениот куршум, поточно обложен е тоа што ќе престанете да размислувате за овие проблеми и да губите време. Ќе имате посебни луѓе кои ќе го затворат ова прашање.
Формулацијата дека нам или на некој друг му треба Кубернетес е неточна.
На администраторите навистина им е потребен Kubernetes, бидејќи тоа е многу интересна играчка со која можете да си играте и да ја чепкате. Да бидеме искрени - сите сакаат играчки. Сите сме некаде деца и кога ќе видиме ново, сакаме да го играме. За некои, ова е обесхрабрено, на пример, во администрацијата, бидејќи тие веќе одиграа доволно и веќе се уморни до тој степен што едноставно не сакаат. Но, ова не е целосно изгубено за никого. На пример, ако долго време сум уморен од играчки во областа на системската администрација и DevOps, тогаш сè уште ги сакам играчките, сè уште купувам нови. Сите луѓе, вака или онака, сè уште сакаат некакви играчки.
Нема потреба да се игра со производство. Што и да препорачувам категорично да не го правите и она што сега масовно го гледам: „О, нова играчка!“ — трчаа да го купат, го купија и: „Ајде сега да го однесеме на училиште и да им го покажеме на сите наши пријатели“. Не правете го ова. Се извинувам, моите деца штотуку растат, постојано гледам нешто кај децата, го забележувам во себе, а потоа го генерализирам на другите.
Конечниот одговор е: не ви треба Кубернет. Треба да ги решите вашите проблеми.
Она што можете да го постигнете е:
- прод не паѓа;
- дури и ако се обиде да падне, ние однапред знаеме за тоа, и можеме да ставиме нешто во него;
- можеме да го промениме со брзината со која тоа го бара нашиот бизнис, и можеме да го направиме погодно; тоа не ни прави никакви проблеми.
Постојат две реални потреби: доверливост и динамичност/флексибилност на имплементацијата. Секој што моментално прави некакви ИТ проекти, без разлика во каков бизнис - мек за олеснување на светот, и кој го разбира ова, треба да ги реши овие потреби. Kubernetes со правилен пристап, со правилно разбирање и со доволно искуство ви овозможува да ги решите.
За без сервер
— Ако погледнете малку подалеку во иднината, а потоа обидувајќи се да го решите проблемот со отсуството на главоболки со инфраструктура, со брзината на воведување и брзината на промените на апликациите, се појавуваат нови решенија, на пример, без сервер. Дали чувствувате некаков потенцијал во оваа насока и, да речеме, опасност за Кубернетис и слични решенија?
Дмитриј: Еве повторно треба да направиме забелешка дека јас не сум гледач кој гледа напред и вели - вака ќе биде! Иако само го направив истото. Гледам во моите стапала и таму гледам еден куп проблеми, на пример, како функционираат транзисторите во компјутерот. Смешно е, нели? Наидуваме на некои грешки во процесорот.
Направете без сервери доста сигурен, евтин, ефикасен и удобен, решавајќи ги сите проблеми со екосистемот. Овде се согласувам со Илон Маск дека е потребна втора планета за да се создаде толеранција на грешки за човештвото. Иако не знам што вели, разбирам дека не сум подготвен самиот да летам на Марс и тоа нема да се случи утре.
Со без сервери, јасно е дека ова е идеолошки исправна работа, како толеранција на грешки за човештвото - подобро е да се има две планети од една. Но, како да се направи тоа сега? Испраќањето на една експедиција не е проблем ако ги концентрирате вашите напори на неа. Да се испратат неколку експедиции и да се населат таму неколку илјади луѓе, мислам дека е исто така реално. Но, тоа да биде целосно толерантно за да живее таму половина од човештвото, сега ми се чини невозможно, а да не се размислува.
Со еден на еден без сервер: работата е кул, но е далеку од проблемите од 2019 година. Поблиску до 2030 година - да живееме за да го видиме. Не се сомневам дека ќе живееме, дефинитивно ќе живееме (повторете пред спиење), но сега треба да решиме други проблеми. Тоа е како да веруваш во бајковитото пони Виножито. Да, пар посто од случаите се решени, и тие се решени совршено, но субјективно, без сервери е виножито... За мене оваа тема е премногу далечна и премногу несфатлива. Не сум подготвен да разговарам. Во 2019 година, не можете да напишете ниту една апликација без сервер.
Како Kubernetes ќе се развива
- Додека се движиме кон оваа потенцијално прекрасна далечна иднина, како мислите дека Кубернетес и екосистемот околу него ќе се развиваат?
Дмитриј: Многу размислував за ова и имам јасен одговор. Првиот е државен - на крајот на краиштата, без државјанство е полесно да се направи. Kubernetes првично инвестираше повеќе во ова, сè започна со тоа. Без државјанство работи речиси совршено во Кубернетес, едноставно нема за што да се жалите. Сè уште има многу проблеми, поточно, нијанси. Таму веќе се работи одлично за нас, но тоа сме ние. Ќе бидат потребни барем уште неколку години за ова да функционира за сите. Ова не е пресметан индикатор, туку мое чувство од мојата глава.
Накратко, државните треба - и ќе - се развиваат многу силно, бидејќи сите наши апликации го складираат статусот; нема апликации без државјанство. Ова е илузија, секогаш ви треба некаква база на податоци и нешто друго. Statefull е за исправување на сè што е можно, за поправање на сите грешки, за подобрување на сите проблеми со кои моментално се соочуваме - да го наречеме усвојување.
Нивото на непознатото, нивото на нерешени проблеми, нивото на веројатност да се сретнеме со нешто значително ќе падне. Ова е важна приказна. И оператори - сè што е поврзано со кодификацијата на логиката на администрацијата, контролната логика со цел да се добие лесна услуга: лесна услуга MySQL, лесна услуга RabbitMQ, лесна услуга Memcache - генерално, сите овие компоненти што треба да ни се гарантираат кутијата. Ова само ја решава болката што сакаме база на податоци, но не сакаме да ја администрираме, или сакаме Kubernetes, но не сакаме да ја администрираме.
Оваа приказна за развој на оператор во една или друга форма ќе биде важна во следните неколку години.
Мислам дека леснотијата на користење треба многу да се зголеми - кутијата ќе станува сè поцрна, сè посигурна, со се повеќе и повеќе едноставни копчиња.
Еднаш на Јутјуб во сабота навечер во живо слушав старо интервју со Исак Асимов од 80-тите - програма како Ургант, само интересна. Го прашаа за иднината на компјутерите. Тој рече дека иднината е во едноставноста, исто како и радиото. Радио-приемникот првично беше сложена работа. За да фатите бран, требаше да ги вртите копчињата 15 минути, да ги вртите ражничките и генерално да знаете како функционира сè, да ја разберете физиката на пренос на радио бранови. Како резултат на тоа, остана само едно копче во радиото.
Сега во 2019 какво радио? Во автомобилот, радио приемникот ги наоѓа сите бранови и имињата на станиците. Физиката на процесот не е променета за 100 години, но леснотијата на користење се промени. Сега, и не само сега, веќе во 1980 година, кога имаше интервју со Азимов, сите го користеа радиото и никој не размислуваше како функционира. Секогаш функционираше - тоа е дадено.
Азимов тогаш рече дека истото ќе биде и со компјутерите - леснотијата на користење ќе се зголеми. Додека во 1980 година требаше да бидете обучени да притискате копчиња на компјутер, тоа нема да биде случај во иднина.
Имам чувство дека со Kubernetes и со инфраструктурата исто така ќе има огромно зголемување на леснотијата на користење. Ова, според мое мислење, е очигледно - лежи на површината.
Што да се прави со инженерите?
- Што тогаш ќе се случи со инженерите и системските администратори кои го поддржуваат Кубернетес?
Дмитриј: Што се случи со сметководителот по појавата на 1C? Отприлика истото. Пред ова, тие сметаа на хартија - сега во програмата. Продуктивноста на трудот се зголеми по редови на големина, но самиот труд не исчезна. Ако претходно беа потребни 10 инженери да навртуваат сијалица, сега еден ќе биде доволен.
Количината на софтвер и бројот на задачи, ми се чини, сега расте со побрзо темпо отколку што се појавуваат новите DevOps, а ефикасноста се зголемува. Во моментов има специфичен недостиг на пазарот и ќе трае долго. Подоцна, сè ќе се врати во некаква нормалност, во која ќе се зголеми ефикасноста на работата, ќе има се повеќе и повеќе без сервери, ќе биде прикачен неврон на Кубернетес, кој ќе ги избира сите ресурси точно по потреба и воопшто ќе направете сè само по себе, како што треба - лицето само тргнете се настрана и не се мешајте.
Но, некој сепак ќе треба да носи одлуки. Јасно е дека нивото на квалификации и специјализација на оваа личност е повисоко. Во денешно време во сметководство не треба 10 вработени да водат книги за да не им се заморат рацете. Едноставно не е потребно. Многу документи автоматски се скенираат и препознаваат од електронскиот систем за управување со документи. Доволен е еден паметен главен сметководител, веќе со многу поголеми вештини, со добро разбирање.
Во принцип, ова е начинот на кој треба да се оди во сите индустрии. Така е и со автомобилите: претходно доаѓаше автомобил со механичар и тројца возачи. Во денешно време, возењето автомобил е едноставен процес во кој сите учествуваме секојдневно. Никој не мисли дека автомобилот е нешто комплицирано.
DevOps или системското инженерство нема да исчезнат - работата и ефикасноста на високо ниво ќе се зголемат.
- Слушнав и една интересна идеја дека работата всушност ќе се зголеми.
Дмитриј: Се разбира, сто проценти! Бидејќи количината на софтвер што пишуваме постојано расте. Бројот на проблеми што ги решаваме со софтвер постојано расте. Обемот на работа расте. Сега пазарот на DevOps е ужасно прегреан. Тоа може да се види во очекувањата за плата. На добар начин, без да навлегуваме во детали, треба да има јуниори кои сакаат X, средни кои сакаат 1,5X и сениори кои сакаат 2X. И сега, ако го погледнете пазарот на плати во Москва DevOps, помладиот сака од X до 3X, а постариот сака од X до 3X.
Никој не знае колку чини. Нивото на плата се мери според вашата самодоверба - целосна лудница, искрено кажано, страшно прегреан пазар.
Се разбира, оваа ситуација ќе се промени многу наскоро - треба да дојде до одредена заситеност. Ова не е случај со развојот на софтвер - и покрај фактот дека на сите им требаат програмери, а на сите им требаат добри програмери, пазарот разбира кој колку вреди - индустријата се смири. Тоа не е случај со DevOps овие денови.
- Од она што го слушнав, заклучив дека сегашниот системски администратор не треба да се грижи премногу, но време е да ги надгради своите вештини и да се подготви за фактот дека утре ќе има повеќе работа, но ќе биде поквалификувана.
Дмитриј: Сто проценти. Генерално, живееме во 2019 година и правилото на животот е ова: доживотно учење - учиме во текот на животот. Ми се чини дека сега сите веќе го знаат и го чувствуваат ова, но не е доволно да се знае - треба да го направиш тоа. Секој ден мора да се менуваме. Ако не го направиме ова, тогаш порано или подоцна ќе бидеме отфрлени на маргините на професијата.
Бидете подготвени за остри вртења од 180 степени. Не исклучувам ситуација кога нешто радикално се менува, се измислува нешто ново - тоа се случува. Хоп! - и сега постапуваме поинаку. Важно е да бидете подготвени за ова и да не се грижите. Може да се случи утре сè што правам да испадне непотребно - ништо, цел живот учев и сум подготвен да научам нешто друго. Тоа не е проблем. Нема потреба да се плашите од безбедноста на работата, туку треба да бидете подготвени постојано да учите нешто ново.
Желби и минута реклама
- Дали имате некоја желба?
Дмитриј: Да, имам неколку желби.
Прво и меркантилно - претплатете се на . Почитувани читатели, одете на YouTube и претплатете се на нашиот канал. За околу еден месец ќе започнеме активно проширување на видео сервисот. Ќе имаме многу едукативни содржини за Kubernetes, отворени и разновидни: од практични работи, па до лаборатории, до длабоки фундаментални теоретски работи и како да се користи Kubernetes на ниво на принципи и модели.
Втората меркантилна желба - оди на и ставаме ѕвезди затоа што се храниме со нив. Ако не ни дадете ѕвезди, нема да имаме што да јадеме. Тоа е како мана во компјутерска игра. Правиме нешто, правиме, се трудиме, некој вели дека тоа се страшни велосипеди, некој дека се е сосема погрешно, но ние продолжуваме и постапуваме апсолутно искрено. Гледаме проблем, го решаваме и го споделуваме нашето искуство. Затоа, дај ни ѕвезда, таа нема да ти тргне, туку ќе ни дојде, затоа што се храниме со нив.
Трета, важна и веќе не меркантилна желба - престанете да верувате во бајките. Вие сте професионалци. DevOps е многу сериозна и одговорна професија. Престанете да играте на работното место. Нека кликне за тебе и ќе го разбереш. Замислете дека доаѓате во болница, а таму докторот експериментира врз вас. Разбирам дека ова може да биде навредливо за некого, но, најверојатно, ова не е за вас, туку за некој друг. Кажете им и на другите да престанат. Ова навистина го уништува животот на сите нас - многумина почнуваат да ги третираат операциите, администраторите и DevOps како типови кои повторно скршиле нешто. Ова најчесто се „кршеше“ поради тоа што одевме да играме, а не гледавме со ладна свест што има овде и што има овде.
Ова не значи дека не треба да експериментирате. Треба да експериментираме, тоа го правиме сами. Да бидам искрен, ние самите понекогаш играме игри - ова, се разбира, е многу лошо, но ништо човечко не ни е туѓо. Да ја прогласиме 2019 година за година на сериозни, добро осмислени експерименти, а не за игри на производство. Веројатно е така.
- Ти благодарам многу!
Дмитриј: Ви благодарам Виталиј и за времето и за интервјуто. Почитувани читатели, многу ви благодарам ако одеднаш сте стигнале до оваа точка. Се надевам дека ви донесовме барем неколку размислувања.
Во интервјуто, Дмитриј го допре прашањето за верф. Сега ова е универзален швајцарски нож кој ги решава речиси сите проблеми. Но, не беше секогаш така. На на фестивалот Дмитриј Столјаров детално ќе ви каже за оваа алатка. во извештајот ќе има сè: проблеми и скриени нијанси на Kubernetes, опции за решавање на овие тешкотии и тековната имплементација на werf во детали. Придружете ни се на 27 и 28 мај, ќе ги создадеме совршените алатки.
Извор: www.habr.com