Күтуде Виталий Хабаров сұхбат алды Дмитрий Столяров (), техникалық директор және Flant компаниясының тең құрылтайшысы. Виталий Дмитрийден Флант немен айналысатынын, Кубернетес, экожүйені дамыту, қолдау туралы сұрады. Біз Кубернетес не үшін қажет екенін және ол қажет пе екенін талқыладық. Сондай-ақ микросервистер туралы, Amazon AWS, DevOps-қа «мен бақытты боламын» тәсілі, Кубернетестің болашағы, оның әлемді неге, қашан және қалай жаулап алатыны, DevOps перспективалары және инженерлер бұл жұмыста қандай дайындыққа баруы керек. жеңілдету және нейрондық желілер арқылы жарқын және жақын болашақ.
DevOps Deflop-та подкаст ретінде тыңдаңыз - DevOps туралы орыс тіліндегі подкаст, төменде мәтіндік нұсқасы берілген.
Мұнда және төменде сұрақтар қояды Express42 инженері.
«Флант» туралы
- Сәлем Дима. Сіз техникалық директорсыз»«және оның негізін қалаушы. Компания немен айналысады және сіз немен айналысасыз?
Дмитрий: Сырттай қарағанда, біз барлығына Кубернеттерді орнатып, онымен бірдеңе жасайтын жігіттер сияқтымыз. Бірақ бұл олай емес. Біз Linux-пен айналысатын компания ретінде жұмыс істей бастадық, бірақ өте ұзақ уақыт бойы біздің негізгі қызметіміз өндіріске және жоғары жүкті кілт тапсыратын жобаларға қызмет көрсету болды. Әдетте біз барлық инфрақұрылымды нөлден саламыз, содан кейін оған ұзақ, ұзақ уақыт жауап береміз. Сондықтан «Фланттың» ақша алатын негізгі жұмысы жауапкершілікті өз мойнына алу және кілт тапсыру өндірісін енгізу.
Мен, техникалық директор және компанияның негізін қалаушылардың бірі ретінде, күндіз-түні өндірістің қолжетімділігін арттыру, оның жұмысын жеңілдету, әкімшілер өмірін жеңілдету, ал әзірлеушілердің өмірін жағымды ету жолын анықтауға тырысамын. .
Кубернетес туралы
— Соңғы кездері мен Флант пенден көптеген есептерді көріп жүрмін Кубернетес туралы. Оған қалай келдіңіз?
Дмитрий: Мен бұл туралы бірнеше рет айтқанмын, бірақ оны қайталауға мүлдем қарсы емеспін. Себеп пен салдардың арасында шатасу болғандықтан бұл тақырыпты қайталау дұрыс деп ойлаймын.
Бізге шынымен құрал керек болды. Талай қиындыққа тап болдық, күресіп, түрлі балдақпен жеңіп, құралдың қажеттігін сезіндік. Біз көптеген түрлі нұсқалардан өттік, өз велосипедтерімізді жасап, тәжірибе алдық. Бірте-бірте біз Docker пайда болған бойда – шамамен 2013 жылы қолдана бастайтын деңгейге жеттік. Ол пайда болған кезде бізде контейнерлермен көп тәжірибе болды, біз «Docker» аналогын жазған болатынбыз - Python-дағы кейбір өзіміздің балдақ. Докердің пайда болуымен балдақтарды лақтырып, сенімді және қоғамдастық қолдайтын шешімді пайдалану мүмкін болды.
Кубернетеспен оқиға ұқсас. Ол қарқын ала бастаған кезде - біз үшін бұл 1.2 нұсқасы - бізде Shell-де де, Chef-те де көптеген балдақтар болды, біз оларды қандай да бір түрде Docker-пен бірге ұйымдастыруға тырыстық. Біз Ранчерге және басқа да шешімдерге шындап қарадық, бірақ содан кейін Кубернетес пайда болды, онда бәрі дәл біз жасағандай немесе одан да жақсырақ орындалады. Шағымданатын ештеңе жоқ.
Иә, бұл жерде қандай да бір жетілмегендік бар, ол жерде қандай да бір кемшіліктер бар - ол жерде көптеген кемшіліктер бар, ал 1.2 жалпы қорқынышты, бірақ... Кубернетес салынып жатқан ғимарат сияқты - жобаға қарап, түсінесіз. бұл салқын болады. Егер ғимараттың қазір іргетасы және екі қабаты болса, онда сіз әлі кірмегеніңіз жақсы екенін түсінесіз, бірақ бағдарламалық қамтамасыз етуде мұндай проблемалар жоқ - сіз оны қазірдің өзінде пайдалана аласыз.
Бізде Кубернетесті пайдалану немесе қолданбау туралы ойлаған сәтіміз болмады. Біз оны пайда болғанға дейін көп күттік және аналогтарын өзіміз жасауға тырыстық.
Кубернетес туралы
— Сіз Кубернетестің өзін дамытуға тікелей қатысыңыз ба?
Дмитрий: Орташа. Керісінше, біз экожүйені дамытуға қатысамыз. Біз тарту сұрауларының белгілі бір санын жібереміз: Прометейге, әртүрлі операторларға, Helm-ге - экожүйеге. Өкінішке орай, мен біз жасаған барлық әрекеттерді қадағалай алмаймын және қателесуім мүмкін, бірақ бізден өзекке бірде-бір пул жоқ.
— Сонымен қатар, сіз көптеген құралдарыңызды Kubernetes айналасында дамытасыз ба?
Дмитрий: Стратегия мынада: біз барамыз және бұрыннан бар барлық нәрселерге сұраныстарды аламыз. Егер тарту сұраулары қабылданбаса, біз оларды жай ғана өзіміз айырамыз және олар біздің құрылыстармен қабылданғанша өмір сүреміз. Содан кейін, ол жоғары ағынға жеткенде, біз жоғары ағын нұсқасына қайта ораламыз.
Мысалы, бізде Prometheus операторы бар, онымен біз 5 рет ассамблеяның жоғары ағынына ауыстық. Бізге қандай да бір мүмкіндік қажет, біз тарту сұрауын жібердік, оны ертең шығаруымыз керек, бірақ біз оның жоғарыда шығарылуын күткіміз келмейді. Тиісінше, біз өзіміз үшін жинаймыз, қандай да бір себептермен қажет болатын мүмкіндігімізбен жиынымызды барлық кластерлерімізге таратамыз. Содан кейін, мысалы, олар оны бізге: «Жігіттер, мұны жалпы жағдай үшін жасайық» деген сөздермен бізге аударады, біз немесе басқа біреу оны аяқтайды және уақыт өте келе ол қайтадан біріктіріледі.
Біз бар нәрсені дамытуға тырысамыз. Әлі жоқ, әлі ойлап табылмаған немесе ойлап табылған, бірақ іске асыруға үлгермеген көптеген элементтер – біз мұны істеп жатырмыз. Бізге индустрия ретінде процесті немесе велосипед жасауды ұнатқандықтан емес, бұл құрал бізге қажет болғандықтан. Сұрақ жиі қойылады, неге біз бұл немесе басқа нәрсе істедік? Жауап қарапайым - иә, өйткені біз одан әрі өтуге, кейбір практикалық мәселені шешуге тура келді және біз оны осы туламен шештік.
Жол әрқашан осылай: біз өте мұқият ізденеміз, егер біз бір бөлке наннан троллейбус жасаудың шешімін таппасақ, өз нан мен троллейбус жасаймыз.
Фланта құралдары
— Мен қазір Flant-та қосымша операторлары, қабық операторлары және dapp/werf құралдары бар екенін білемін. Менің түсінуімше, бұл әртүрлі инкарнациялардағы бір аспап. Мен сонымен қатар Flaunt ішінде көптеген басқа құралдар бар екенін түсінемін. Бұл осылай?
Дмитрий: Бізде GitHub-та көп нәрсе бар. Қазір есімде қалғаны, бізде статус картасы бар - барлығы кездестірген Grafana панелі. Бұл ортадағы Kubernetes мониторингі туралы әрбір екінші мақалада айтылған. Күй картасының не екенін қысқаша түсіндіру мүмкін емес - оған жеке мақала қажет, бірақ бұл уақыт өте келе күйді бақылау үшін өте пайдалы нәрсе, өйткені Кубернетесте біз уақыт өте келе күйді көрсетуіміз керек. Бізде LogHouse да бар - бұл ClickHouse негізіндегі нәрсе және Kubernetes-те журналдарды жинауға арналған қара сиқыр.
Көптеген коммуналдық қызметтер! Және одан да көп болады, өйткені осы жылы бірқатар ішкі шешімдер шығарылады. Addon операторына негізделген өте үлкендердің ішінде Kubernetes үшін көптеген қосымшалар бар, ала серт менеджерін қалай дұрыс орнату керек - сертификаттарды басқару құралы, көптеген керек-жарақтармен Prometheus қалай дұрыс орнату керек - бұл шамамен жиырма түрлі деректерді экспорттайтын және бірдеңе жинайтын екілік файлдар, бұл Прометейде ең керемет графика мен ескертулер бар. Мұның бәрі кластерде орнатылған Kubernetes қосымшаларының жиынтығы және ол қарапайымнан салқын, күрделі, автоматтыға ауысады, онда көптеген мәселелер шешілген. Иә, біз көп нәрсе жасаймыз.
Экожүйенің дамуы
«Менің ойымша, бұл осы құралды және оны қолдану әдістерін дамытуға үлкен үлес қосқан сияқты». Экожүйені дамытуға тағы кім үлес қосатынын шамамен есептей аласыз ба?
Дмитрий: Ресейде біздің нарықта жұмыс істейтін компаниялардың ешкімі тіпті жақын емес. Әрине, бұл қатты мәлімдеме, өйткені Mail және Yandex сияқты ірі ойыншылар бар - олар да Kubernetes-пен бірдеңе істеп жатыр, бірақ олар тіпті бізден әлдеқайда көп жұмыс істейтін бүкіл әлемдегі компаниялардың үлесіне жақындамайды. Қателеспесем, штаты 80 адамнан тұратын Flant пен бір кубернетеде 300 инженері бар Red Hat-ті салыстыру қиын. Салыстыру қиын. Бізде RnD бөлімінде 6 адам бар, оның ішінде мені де қоса алғанда, барлық құралдарымызды кесіп тастады. 6 адам 300 Red Hat инженерімен салыстырғанда - салыстыру қиын.
– Дегенмен, осы 6 адамның өзі шын мәнінде пайдалы және жат нәрсе жасай алатын кезде, олар практикалық мәселеге тап болып, қоғамға шешімін бергенде - қызық жағдай. Мен өздерінің Kubernetes әзірлеу және қолдау тобы бар ірі технологиялық компанияларда, негізінен, бірдей құралдарды жасауға болатынын түсінемін. Бұл олар үшін Kubernetes-ті қолданатын бүкіл қауымдастыққа серпін беріп, қоғамға нені дамытуға және беруге болатынының үлгісі.
Дмитрий: Бұл интегратордың ерекшелігі, оның ерекшелігі болса керек. Бізде көптеген жобалар бар және біз әртүрлі жағдайларды көреміз. Біз үшін қосымша құнды құрудың негізгі жолы – осы жағдайларды сараптап, ортақ тұстарын тауып, біз үшін барынша арзанға жеткізу. Біз бұл бағытта белсенді жұмыс істеп жатырмыз. Мен үшін Ресей және әлем туралы айту қиын, бірақ компанияда Kubernetes-те жұмыс істейтін 40-қа жуық DevOps инженерлері бар. Менің ойымша, Ресейде Кубернетесті түсінетін мамандардың салыстырмалы саны бар компаниялар көп емес, егер бар болса.
Мен DevOps инженері лауазымы туралы бәрін түсінемін, барлығы бәрін түсінеді және DevOps инженерлерін DevOps инженерлері деп атауға дағдыланған, біз бұл туралы талқыламаймыз. Барлық осы 40 таңғажайып DevOps инженерлері күн сайын қиындықтарға тап болып, оларды шешеді, біз бұл тәжірибені талдап, жалпылауға тырысамыз. Біз түсінеміз, егер ол біздің ішімізде қалса, онда бір-екі жылдан кейін құрал жарамсыз болады, өйткені қоғамда бір жерде дайын Тула пайда болады. Бұл тәжірибені ішкі жинақтаудың қажеті жоқ - бұл жай ғана энергия мен уақытты dev/null ішіне ағызу. Ал біз оған мүлдем өкінбейміз. Біз барлығын үлкен қуанышпен жариялаймыз және оны адамдар пайдаланып, тәжірибесін қосуы үшін басып шығару, дамыту, насихаттау, насихаттау керек екенін түсінеміз - сонда бәрі өседі және өмір сүреді. Содан кейін екі жылдан кейін құрал қоқыс жәшігіне түспейді. Күшті жалғастыра беру өкінішті емес, өйткені біреу сіздің құралыңызды пайдаланып жатқаны анық, ал екі жылдан кейін бәрі оны пайдаланады.
Бұл dapp/werf-пен үлкен стратегиямыздың бір бөлігі. Біз оны қашан бастағанымыз есімде жоқ, 3 жыл бұрын болған сияқты. Бастапқыда ол негізінен қабықшада болды. Бұл тұжырымдаманың керемет дәлелі болды, біз кейбір мәселелерімізді шештік - ол жұмыс істеді! Бірақ қабықпен проблемалар бар, оны одан әрі кеңейту мүмкін емес, қабықшада бағдарламалау басқа міндет. Бізде Ruby тілінде жазу әдеті бар еді, сәйкесінше, біз Ruby тілінде бірдеңені қайта жасадық, дамыттық, дамыттық, дамыттық және қоғамдастық, тобыр «біз оны қалаймыз немесе қаламаймыз» демейтін фактілерге тап болдық. ” деп мұрнын Рубиге бұрды, бұл қаншалықты күлкілі? Бақылау парағындағы бірінші тармақты орындау үшін біз Go қолданбасында осының барлығын жазу керек екенін түсіндік: DevOps құралы статикалық екілік болуы керек. Go болу немесе болмау соншалықты маңызды емес, бірақ Go тілінде жазылған статикалық екілік жақсырақ.
Біз күшімізді жұмсадық, Go бағдарламасында даппты қайта жазып, оны werf деп атадық. Dapp қолданбасына енді қолдау көрсетілмейді, әзірленбейді, кейбір соңғы нұсқаларында жұмыс істейді, бірақ жоғарғы деңгейге абсолютті жаңарту жолы бар және оны орындауға болады.
Dapp не үшін жасалды?
— Дапп не үшін жасалды, қандай мәселелерді шешеді, қысқаша айта аласыз ба?
Дмитрий: Бірінші себеп – жиналыста. Бастапқыда бізде Docker көп сатылы мүмкіндіктері болмаған кезде құрастыруда күрделі мәселелер болды, сондықтан біз өз бетімізше көп сатылы жасадық. Содан кейін бізде кескінді тазалауға қатысты көптеген мәселелер туындады. CI/CD-мен айналысатын әрбір адам, кешіктірмей, жиналған суреттердің көптігі бар мәселеге тап болады, қажет емес нәрсені тазартып, қажет нәрсені қалдыру керек.
Екінші себеп - орналастыру. Иә, Helm бар, бірақ ол кейбір мәселелерді шешеді. Бір қызығы, «Helm - Kubernetes үшін пакет менеджері» деп жазылған. Дәл «не». Сондай-ақ «Пакет менеджері» деген сөздер бар - Пакет менеджерінен әдеттегідей не күтеді? Біз айтамыз: «Package Manager - пакетті орнатыңыз!» және біз оның бізге: «Пакет жеткізілді» деп айтуын күтеміз.
Бір қызығы, біз: «Штурвал, пакетті орнатыңыз» деп айтамыз және ол оны орнатты деп жауап бергенде, ол орнатуды енді бастағаны белгілі болды - ол Кубернетеске: «Мына нәрсені іске қосыңыз!» Деп көрсетті және ол басталды ма, жоқ па? , ол жұмыс істей ме, жоқ па, Helm бұл мәселені мүлдем шешпейді.
Helm тек Kubernetes-ке деректерді жүктейтін мәтіндік препроцессор екені белгілі болды.
Бірақ кез келген орналастыру бөлігі ретінде біз қолданбаның өндіріске шығарылғанын немесе шығарылмағанын білгіміз келеді ме? Өндіріске шығарылды деген сөз қолданбаның сол жерге көшкенін, жаңа нұсқаның орналастырылғанын және кем дегенде ол жерде бұзылмай, дұрыс жауап беретінін білдіреді. Helm бұл мәселені ешқандай жолмен шешпейді. Оны шешу үшін сізге көп күш жұмсау керек, өйткені Кубернетеске тарату және онда не болып жатқанын - ол орналастырылған немесе шығарылған ба бақылау пәрменін беру керек. Сондай-ақ орналастыру, тазалау және жинауға қатысты көптеген тапсырмалар бар.
жоспарлары
Биыл жергілікті жерді дамытуды бастаймыз. Біз Vagrant-те бұрын болған нәрсеге қол жеткізгіміз келеді - біз «vagrant up» деп теріп, виртуалды машиналарды орналастырдық. Біз Git-те жоба бар нүктеге жеткіміз келеді, біз сол жерде «werf up» деп жазамыз және ол осы жобаның жергілікті шағын Кубта орналастырылған, әзірлеуге ыңғайлы барлық каталогтары қосылған жергілікті көшірмесін шығарады. . Әзірлеу тіліне байланысты бұл басқаша орындалады, бірақ соған қарамастан жергілікті даму бекітілген файлдардың астында ыңғайлы түрде жүзеге асырылуы мүмкін.
Біз үшін келесі қадам әзірлеушілерге ыңғайлы болу үшін инвестициялаңыз. Жобаны бір құралмен жергілікті жерде жылдам орналастыру үшін оны дамытыңыз, оны Git ішіне итеріңіз, сонымен қатар ол құбырларға байланысты кезеңге немесе сынақтарға шығады, содан кейін өндіріске өту үшін сол құралды пайдаланыңыз. Бұл біртұтастық, біріздендіру, инфрақұрылымның жергілікті ортадан сатуға дейінгі қайталануы біз үшін өте маңызды сәт. Бірақ бұл әлі werf-те жоқ - біз мұны жасауды жоспарлап отырмыз.
Бірақ dapp/werf жолы әрқашан басында Кубернетеспен бірдей болды. Біз проблемаларға тап болдық, оларды уақытша шешімдермен шештік - біз қабықшада, кез келген нәрседе өзіміз үшін кейбір шешімдерді таптық. Содан кейін олар бұл шешімдерді қандай да бір жолмен түзетуге, оларды жалпылауға және екілік файлдарға біріктіруге тырысты, біз оны жай бөлісеміз.
Бұл оқиғаны аналогиямен қараудың тағы бір жолы бар.
Кубернетес - қозғалтқышы бар автомобиль жақтауы. Ешқандай есік, әйнек, радио, шырша - мүлде жоқ. Тек рама мен қозғалтқыш. Ал Руль бар - бұл руль. Салқын - руль бар, бірақ сізге рульдік түйреуіш, руль сөресі, беріліс қорабы және доңғалақтар қажет және оларсыз жасай алмайсыз.
Верф жағдайында бұл Kubernetes-тің басқа құрамдас бөлігі. Тек қазір ғана werf альфа нұсқасында, мысалы, Helm werf ішінде құрастырылған, өйткені біз оны өзіміз жасаудан шаршадық. Мұны істеудің көптеген себептері бар, мен сізге бүкіл рульді werf ішіндегі өңдегішпен бірге құрастырғанымызды егжей-тегжейлі айтып беремін. .
Енді werf біріктірілген құрамдас болып табылады. Біз дайын руль дөңгелегін, рульдік түйреуішті аламыз - мен көліктерді жақсы білмеймін, бірақ бұл үлкен блок, ол қазірдің өзінде көптеген мәселелерді шешеді. Каталогты өзіміз қарап шығудың, бір бөлікті екіншісіне таңдаудың, оларды қалай бұрау керектігін ойластырудың қажеті жоқ. Біз бірден көптеген мәселелерді шешетін дайын комбайн аламыз. Бірақ оның ішінде бірдей ашық бастапқы құрамдас бөліктерден құрастырылған, ол әлі де құрастыру үшін Docker, кейбір функционалдылық үшін Helm пайдаланады және бірнеше басқа кітапханалар бар. Бұл қораптан салқын CI/CD дискісін жылдам және ыңғайлы түрде шығаруға арналған біріктірілген құрал.
Кубернеттерді күтіп ұстау қиын ба?
— Сіз Kubernetes-ті қолдана бастаған тәжірибеңіз туралы айтасыз, бұл сізге арналған жақтау, қозғалтқыш және оған көптеген әртүрлі заттарды іліп қоюға болады: корпус, руль, педальдардағы бұрандалар, орындықтар. Сұрақ туындайды - Kubernetes қолдауы сізге қаншалықты қиын? Сізде үлкен тәжірибе бар, сіз Кубернетесті басқа нәрселерден оқшаулауға қанша уақыт пен ресурстарды жұмсайсыз?
Дмитрий: Бұл өте қиын сұрақ және оған жауап беру үшін біз қолдаудың не екенін және Кубернетестен не қалайтынымызды түсінуіміз керек. Мүмкін сіз аша аласыз ба?
— Менің білуімше, қазір көптеген командалар Кубернетесті сынап көргісі келеді. Әркім соған күш-қуат салып, тізе бүктіреді. Менің ойымша, адамдар бұл жүйенің күрделілігін әрдайым түсінбейді.
Дмитрий: Дәл солай.
— Кубернеттерді нөлден бастап алып, оны өндіруге дайын болу үшін орнату қаншалықты қиын?
Дмитрий: Қалай ойлайсыз, жүректі ауыстыру қаншалықты қиын? Мен бұл компромат сұрақ екенін түсінемін. Скальпельді қолдану және қателеспеу соншалықты қиын емес. Егер олар сізге қай жерде кесіп, қай жерде тігу керектігін айтса, онда процедураның өзі күрделі емес. Уақыт өте келе бәрі жақсы болатынына кепілдік беру қиын.
Kubernetes орнату және оны іске қосу оңай: балапан! — орнатылған, орнату әдістері өте көп. Бірақ проблемалар туындаған кезде не болады?
Сұрақтар әрқашан туындайды - біз әлі нені ескермедік? Біз әлі не істемедік? Қандай Linux ядросының параметрлері қате көрсетілді? Раббым, біз оларды еске түсірдік пе?! Біз қандай Kubernetes құрамдастарын жеткіздік, ал қайсысын жеткізбедік? Мыңдаған сұрақтар туындайды және оларға жауап беру үшін бұл салада 15-20 жыл уақытыңызды жұмсау керек.
Менде осы тақырып бойынша жақында мысал бар, ол «Кубернетесті қолдау қиын ба?» Мәселесінің мағынасын ашуы мүмкін. Біраз уақыт бұрын біз Cilium-ды Кубернетесте желі ретінде енгізуге тырысу керек пе деп ойладық.
Cilium деген не екенін түсіндірейін. Kubernetes-те желілік ішкі жүйенің көптеген әртүрлі іске асырулары бар және олардың бірі өте керемет - Cilium. Оның мағынасы қандай? Ядрода біраз уақыт бұрын желілік ішкі жүйеге және әртүрлі басқа ішкі жүйелерге қандай да бір жолмен басып кіретін және ядродағы үлкен бөліктерді айналып өтуге мүмкіндік беретін ядроға арналған ілмектерді жазу мүмкін болды.
Linux ядросында тарихи түрде IP маршруты, артық сүзгі, көпірлер және 15, 20, 30 жастағы көптеген ескі компоненттер бар. Жалпы, олар жұмыс істейді, бәрі тамаша, бірақ қазір олар контейнерлерді үйіп тастады, және ол бір-бірінің үстіне 15 кірпіштен тұратын мұнараға ұқсайды, ал оның үстіне бір аяғыңызбен тұрасыз - біртүрлі сезім. Бұл жүйе тарихи түрде денедегі қосымша сияқты көптеген нюанстармен дамыды. Кейбір жағдайларда өнімділік мәселелері бар, мысалы.
Керемет BPF және ядроға арналған ілмектерді жазу мүмкіндігі бар - жігіттер ядроға өздерінің ілмектерін жазды. Пакет Linux ядросына түседі, олар оны тікелей кірісте шығарып алады, оны көпірсіз, TCPсіз, IP стексіз өңдейді - қысқасы, Linux ядросында жазылғанның бәрін айналып өтіп, содан кейін түкіреді. оны контейнерге салыңыз.
Не болды? Өте керемет өнімділік, керемет мүмкіндіктер - керемет! Бірақ біз бұған қарап, әрбір машинада Kubernetes API-ге қосылатын бағдарлама бар екенін көреміз және ол осы API-ден алатын деректер негізінде C кодын жасайды және ядроға жүктейтін екілік файлдарды құрастырады, осылайша бұл ілмектер жұмыс істейді. ядро кеңістігінде.
Бірдеңе дұрыс болмаса не болады? Біз білмейміз. Мұны түсіну үшін сіз осы кодтың бәрін оқып, логиканы түсінуіңіз керек және бұл қаншалықты қиын екені таңқаларлық. Бірақ, екінші жағынан, бұл көпірлер, таза сүзгілер, IP маршруттары бар - мен олардың бастапқы кодын оқыған жоқпын және біздің компанияда жұмыс істейтін 40 инженерде де жоқ. Кейбір бөліктерді санаулысы ғана түсінетін шығар.
Ал айырмашылығы неде? IP rout, Linux ядросы бар және жаңа құрал бар - оның айырмашылығы неде, біз біреуін немесе екіншісін түсінбейміз. Бірақ біз жаңа нәрсені қолдануға қорқамыз - неге? Өйткені егер құрал 30 жаста болса, онда 30 жыл ішінде барлық қателер табылды, барлық қателер жойылды және сізге бәрі туралы білудің қажеті жоқ - ол қара жәшік сияқты жұмыс істейді және әрқашан жұмыс істейді. Қандай диагностикалық бұрауышты қай жерге жабыстыру керек, қай tcpdump қай сәтте іске қосу керек екенін бәрі біледі. Барлығы диагностикалық утилиталарды жақсы біледі және бұл компоненттер жиынтығы Linux ядросында қалай жұмыс істейтінін түсінеді - ол қалай жұмыс істейтінін емес, оны қалай пайдалану керектігін түсінеді.
Ал керемет Cilium 30 жаста емес, ол әлі қарталмаған. Кубернетесте бірдей мәселе бар, көшіру. Бұл Cilium тамаша орнатылған, Kubernetes тамаша орнатылған, бірақ өндірісте бірдеңе дұрыс емес болғанда, сіз қиын жағдайда ненің дұрыс емес екенін тез түсіне аласыз ба?
Kubernetes-ті ұстау қиын деп айтсақ - жоқ, бұл өте оңай және иә, бұл керемет қиын. Кубернетес өздігінен керемет жұмыс істейді, бірақ миллиардтаған нюанстармен.
«Мен бақытты боламын» тәсілі туралы
— Бұл нюанстардың пайда болуына кепілдік беретін компаниялар бар ма? Яндекс кенеттен барлық қызметтерді Кубернетеске ауыстырды делік, онда үлкен жүктеме болады.
Дмитрий: Жоқ, бұл жүк туралы емес, ең қарапайым нәрселер туралы әңгіме. Мысалы, бізде Kubernetes бар, біз қолданбаны сонда орналастырдық. Оның жұмыс істеп тұрғанын қайдан білесіз? Қолданба бұзылмайтынын түсіну үшін жай ғана дайын құрал жоқ. Ескертулерді жіберетін дайын жүйе жоқ, бұл ескертулерді және әрбір кестені конфигурациялау қажет. Біз Kubernetes-ті жаңартып жатырмыз.
Менде Ubuntu 16.04 бар. Сіз бұл ескі нұсқа деп айта аласыз, бірақ біз оны әлі де қолданамыз, өйткені бұл LTS. Systemd бар, оның нюансы С-топтарды тазартпайды. Кубернетес подкасттарды іске қосады, C-топтарын жасайды, содан кейін подкасттарды жояды және қалай болғанда да белгілі болды - мәліметтер есімде жоқ, кешіріңіз - жүйелік бөліктер қалады. Бұл уақыт өте келе кез келген көліктің қатты баяулай бастайтынына әкеледі. Бұл тіпті жоғары жүктеме туралы мәселе емес. Тұрақты подкасттар іске қосылса, мысалы, үнемі подводтарды жасайтын Cron Job болса, Ubuntu 16.04 жүйесі бар құрылғы бір аптадан кейін баяулай бастайды. С-топтарының шоғыры құрылғандықтан, тұрақты жоғары жүктеме орташа болады. Бұл Ubuntu 16 және Kubernetes-ті жай ғана орнатқан кез келген адам тап болатын мәселе.
Ол қандай да бір түрде systemd немесе басқа нәрсені жаңартады делік, бірақ Linux ядросында 4.16 дейін бұл одан да қызық - C-топтарды жойған кезде, олар ядрода ағып кетеді және іс жүзінде жойылмайды. Сондықтан, бұл машинада бір ай жұмыс істегеннен кейін, ошақтардың жады статистикасын қарау мүмкін болмайды. Біз файлды шығарамыз, оны бағдарламада айналдырамыз және бір файл 15 секундқа айналады, өйткені ядро өз ішіндегі миллион C-топтарын санау үшін өте ұзақ уақыт алады, олар жойылған сияқты, бірақ жоқ - олар ағып жатыр. .
Ондай ұсақ-түйектер әлі де көп. Бұл алпауыт компаниялар кейде өте ауыр жүктемелермен бетпе-бет келуі мүмкін мәселе емес - жоқ, бұл күнделікті мәселелер. Адамдар осылай айлар бойы өмір сүре алады - олар Kubernetes орнатты, қолданбаны орналастырды - бұл жұмыс істейтін сияқты. Көптеген адамдар үшін бұл қалыпты жағдай. Олар бұл қолданбаның қандай да бір себептермен бұзылатынын білмейді, олар ескерту алмайды, бірақ олар үшін бұл қалыпты жағдай. Бұрын біз виртуалды машиналарда мониторингсіз өмір сүрдік, енді біз Кубернетеске көштік, сонымен қатар бақылаусыз - айырмашылығы неде?
Мәселе мынада, біз мұзбен жүргенде, оны алдын ала өлшемейінше, оның қалыңдығын ешқашан білмейміз. Көптеген адамдар жүреді және алаңдамайды, өйткені олар бұрын жүріп өткен.
Менің көзқарасым бойынша, кез келген жүйені пайдаланудың нюансы мен күрделілігі - мұздың қалыңдығы біздің проблемаларды шешуге жеткілікті болуын қамтамасыз ету. Бұл туралы айтып отырмыз.
Менің ойымша, IT саласында «мен бақытты боламын» деген тәсілдер тым көп. Көптеген адамдар бағдарламалық жасақтаманы орнатады және бағдарламалық жасақтама кітапханаларын пайдаланады, олардың жолы болады деп үміттенеді. Жалпы, көптеген адамдар бақытты. Сондықтан да болар.
— Менің пессимистік бағалауым бойынша, бұл былай көрінеді: тәуекелдер жоғары болғанда және қолданба жұмыс істеуі керек болса, Flaunt-тан, мүмкін Red Hat-тен қолдау қажет немесе сізге Кубернетеске арнайы бөлінген ішкі командаңыз қажет, ол дайын. оны тартып алу үшін.
Дмитрий: Объективті түрде солай. Кішкентай команда үшін Кубернетес тарихына жеке кіру бірқатар тәуекелдерді қамтиды.
Бізге контейнерлер керек пе?
— Кубернетестің Ресейде қаншалықты таралғанын айта аласыз ба?
Дмитрий: Менде бұл деректер жоқ және басқа біреуде бар екеніне сенімді емеспін. Біз: «Кубернетес, Кубернетес» дейміз, бірақ бұл мәселені қарастырудың басқа жолы бар. Мен контейнерлердің қаншалықты кең таралғанын білмеймін, бірақ мен Интернеттегі есептер бойынша контейнерлердің 70% -ын Кубернетес ұйымдастырғанын білемін. Бұл бүкіл әлем бойынша жеткілікті үлкен үлгі үшін сенімді дереккөз болды.
Содан кейін тағы бір сұрақ - бізге контейнерлер керек пе? Менің жеке сезімім және Flant компаниясының жалпы ұстанымы - Kubernetes - бұл іс жүзінде стандарт.
Кубернетестен басқа ештеңе болмайды.
Бұл инфрақұрылымды басқару саласындағы абсолютті ойын өзгертуші. Тек абсолютті - бұл енді Ansible, Chef, виртуалды машиналар, Terraform. Бұрынғы колхоз әдістерін айтып отырғаным жоқ. Кубернетес - абсолютті өзгертуші, ал енді тек осылай болады.
Мұны жүзеге асыру үшін біреуге бір-екі жыл, ал біреуге бірнеше онжылдық қажет екені анық. Мен Kubernetes және осы жаңа көріністен басқа ештеңе болмайтынына күмәнім жоқ: біз енді операциялық жүйеге зиян келтірмейміз, бірақ инфрақұрылым код ретінде, тек кодпен емес, yml-мен - декларациялық сипатталған инфрақұрылым. Әрқашан осылай болады деген сезім бар.
— Яғни, Kubernetes-ке әлі ауыспаған компаниялар оған міндетті түрде ауысады немесе ұмытып қалады. Мен сені дұрыс түсіндім бе?
Дмитрий: Бұл да мүлде дұрыс емес. Мысалы, егер бізде DNS серверін іске қосу міндеті болса, оны FreeBSD 4.10 жүйесінде іске қосуға болады және ол 20 жыл бойы тамаша жұмыс істей алады. Тек жұмыс жасаңыз және солай. Мүмкін 20 жылдан кейін бірдеңені бір рет жаңарту керек шығар. Егер біз іске қосқан пішімдегі бағдарламалық жасақтама туралы айтатын болсақ және ол көптеген жылдар бойы ешқандай жаңартуларсыз, өзгерістерсіз жұмыс істейтін болса, онда, әрине, Kubernetes болмайды. Ол жерде керек емес.
CI/CD-ге қатысты барлығы - Үздіксіз жеткізу қажет жерде, нұсқаларды жаңарту, белсенді өзгертулер енгізу, ақауларға төзімділікті орнату қажет жерде - тек Kubernetes.
Микросервис туралы
– Бұл жерде менде аздап диссонанс бар. Kubernetes-пен жұмыс істеу үшін сізге сыртқы немесе ішкі қолдау қажет - бұл бірінші нүкте. Екіншіден, біз әзірлеуді енді бастаған кезде, біз кішкентай стартаппыз, бізде әлі ештеңе жоқ, Kubernetes немесе микросервис архитектурасын әзірлеу күрделі болуы мүмкін және әрқашан экономикалық тұрғыдан негізделмейді. Мені сіздің пікіріңіз қызықтырады - стартаптар дереу Кубернетес үшін жазуды нөлден бастауы керек пе, әлде олар әлі де монолит жазып, содан кейін Кубернетеске келе ала ма?
Дмитрий: Керемет сұрақ. Менде микросервистер туралы әңгіме бар Мен микроскоппен шеге соғуға тырысатын адамдарды талай рет кездестірдім. Тәсілдің өзі дұрыс, біз өзіміздің ішкі бағдарламалық жасақтаманы осылайша құрастырамыз. Бірақ мұны істегенде, сіз не істеп жатқаныңызды анық түсінуіңіз керек. Микросервистерге қатысты ең жек көретін сөз – «микро». Тарихи тұрғыдан бұл сөз сол жерде пайда болған және неге екені белгісіз, адамдар микро өте кішкентай, микрометр сияқты миллиметрден аз деп ойлайды. Бұл олай емес.
Мысалы, монолит бар, оны 300 адам жазады, әзірлеуге қатысқандардың бәрі ол жерде проблемалар бар екенін түсінеді және оны микро бөліктерге бөлу керек - шамамен 10 дана, олардың әрқайсысын 30 адам жазады. ең аз нұсқада. Бұл маңызды, қажетті және керемет. Бірақ бізге стартап келгенде, 3 өте керемет және талантты жігіт тізелеріне 60 микросервис жазған, мен Корвалолды іздеген сайын.
Менің ойымша, бұл туралы мыңдаған рет айтылған - біз бір немесе басқа түрде бөлінген монолитті алдық. Бұл экономикалық тұрғыдан ақталған жоқ, жалпы алғанда, бұл өте қиын. Мен мұны бірнеше рет көргенім сонша, бұл мені қатты ауыртады, сондықтан мен бұл туралы айтуды жалғастырамын.
Бастапқы сұраққа, бір жағынан, Кубернетесті пайдалану қорқынышты екендігі арасында қайшылық бар, өйткені ол жерде не бұзылып, не жұмыс істемейтіні белгісіз, екінші жағынан, бәрі сонда болатыны анық. және Кубернетестен басқа ештеңе болмайды. Жауап - келетін пайданың мөлшерін, сіз шеше алатын тапсырмалардың мөлшерін өлшеңіз. Бұл шкаланың бір жағында. Екінші жағынан, тоқтап қалумен немесе жауап беру уақытының қысқаруымен, қолжетімділік деңгейімен – өнімділік көрсеткіштерінің төмендеуімен байланысты тәуекелдер бар.
Міне, біз жылдам қозғаламыз, ал Кубернетес бізге көп нәрсені әлдеқайда жылдам және жақсырақ орындауға мүмкіндік береді немесе біз сенімді, уақытпен тексерілген шешімдерді қолданамыз, бірақ әлдеқайда баяу қозғаламыз. Бұл әрбір компанияның таңдауы. Сіз оны джунглидегі жол деп санай аласыз - сіз алғаш рет жүргенде жылан, жолбарыс немесе ессіз борсықты кездестіре аласыз, ал 10 рет жүргенде, сіз жолды басып өттіңіз, жойылды. бұтақтар мен жүру оңайырақ. Әр жолы жол кеңейеді. Одан кейін асфальт жол, кейін әдемі бульвар.
Кубернетес бір орында тұрмайды. Тағы да сұрақ: Кубернетес, бір жағынан, 4-5 екілік, екінші жағынан, бұл бүкіл экожүйе. Бұл біздің машиналарда бар операциялық жүйе. Бұл не? Ubuntu немесе Curios? Бұл Linux ядросы, қосымша компоненттер тобы. Осының бәрі осында, бір улы жылан жолдан лақтырылды, сол жерде қоршау тұрғызылды. Кубернетес өте жылдам және серпінді дамып келеді, ал тәуекелдердің көлемі, белгісіз көлемі ай сайын азайып келеді және сәйкесінше бұл таразылар теңгерімделуде.
Стартап не істеуі керек деген сұраққа жауап бере отырып, мен айтар едім - Flaunt-қа келіңіз, 150 мың рубль төлеңіз және DevOps оңай сервисін кілтпен алыңыз. Егер сіз бірнеше әзірлеушілері бар шағын стартап болсаңыз, бұл жұмыс істейді. Осы уақытта сіздің мәселелеріңізді қалай шешуге және жалақы төлеуге болатынын білуі керек өзіңіздің DevOps-ті жалдаудың орнына, сіз барлық мәселелердің кілт шешімін аласыз. Иә, кейбір кемшіліктер бар. Біз аутсорсинг ретінде олайша тартыла алмаймыз және өзгерістерге тез жауап бере алмаймыз. Бірақ бізде көптеген тәжірибелер мен дайын тәжірибелер бар. Біз кез келген жағдайда оны тез арада анықтап, кез келген кубернеттерді өлілерден тірілтетінімізге кепілдік береміз.
Мен стартаптар мен құрылған бизнеске 10 адамнан тұратын команданы операцияларға арнауға болатын мөлшерге дейін аутсорсингті ұсынамын, өйткені әйтпесе мағынасы жоқ. Мұны аутсорсингке алудың мағынасы бар.
Amazon және Google туралы
— Amazon немесе Google шешімдерінің хостын аутсорсинг ретінде қарастыруға бола ма?
Дмитрий: Иә, әрине, бұл бірқатар мәселелерді шешеді. Бірақ тағы да нюанстар бар. Сіз оны қалай пайдалану керектігін әлі де түсінуіңіз керек. Мысалы, Amazon AWS жұмысында мыңдаған ұсақ-түйектер бар: Load Balancer қыздыру керек немесе «жігіттер, біз трафикті аламыз, біз үшін Load Balancer жылытыңыз!» деп алдын ала өтініш жазу керек. Сіз бұл нюанстарды білуіңіз керек.
Осыған маманданған адамдарға жүгінгенде, сіз барлық дерлік типтік нәрселерді жауып аласыз. Қазір бізде 40 инженер бар, жыл соңына дейін олардың саны 60-қа жетуі мүмкін – біз мұның бәріне тап болдық. Қандай да бір жобада бұл мәселеге қайта тап болсақ та, біз бір-бірімізден тез сұрап, оны қалай шешуге болатынын білеміз.
Мүмкін жауап - әрине, орналастырылған оқиға кейбір бөлікті жеңілдетеді. Мәселе сіз бұл хосттерге сенуге дайынсыз ба және олар сіздің мәселелеріңізді шеше ме? Amazon және Google жақсы жұмыс жасады. Біздің барлық жағдайларымыз үшін - дәл. Бізде бұдан артық оң тәжірибе жоқ. Біз жұмыс істеуге тырысқан барлық басқа бұлттар көптеген проблемаларды тудырады - Ager және Ресейдегі барлық нәрселер және әртүрлі енгізулердегі OpenStack барлық түрлері: Headster, Overage - қалағаныңызша. Олардың барлығы сіз шешкіңіз келмейтін мәселелерді тудырады.
Сондықтан, жауап иә, бірақ, шын мәнінде, жетілген хост шешімдері өте көп емес.
Кубернетес кімге керек?
— Сонда да Кубернетес кімге керек? Кубернетеске кім ауысуы керек, ол Кубернетес үшін арнайы келетін әдеттегі Flaunt клиенті кім?
Дмитрий: Бұл қызық сұрақ, өйткені дәл қазір, Кубернетестің артынан бізге көптеген адамдар келеді: «Жігіттер, сіз Кубернетеспен айналысып жатқаныңызды білеміз, мұны біз үшін жасаңыз!» Біз оларға жауап береміз: «Мырзалар, біз кубернетеспен айналыспаймыз, біз өндірісті және онымен байланысты барлық нәрсені жасаймыз». Өйткені қазіргі уақытта барлық CI/CD және осы оқиғаны жасамай өнім жасау мүмкін емес. Даму арқылы даму, сосын қанау арқылы қанау деген бөлуден бәрі де алыстап кетті.
Біздің клиенттер әртүрлі нәрселерді күтеді, бірақ бәрі олардың белгілі бір проблемалары бар жақсы ғажайыпты күтеді, ал қазір - хоп! — Оларды Кубернетес шешеді. Адамдар ғажайыптарға сенеді. Олардың ойларында олар ғажайып болмайтынын түсінеді, бірақ олардың жан-дүниелерінде олар үміттенеді - егер бұл Кубернетес енді біз үшін бәрін шешсе ше, олар бұл туралы көп айтады! Кенет ол қазір - түшкірді! - және күміс оқ, түшкір! — және бізде 100% жұмыс уақыты бар, барлық әзірлеушілер өндіріске 50 рет кіретін кез келген нәрсені шығара алады және ол бұзылмайды. Жалпы, керемет!
Ондай адамдар бізге келгенде: «Кешіріңіз, бірақ ғажайып нәрсе жоқ» дейміз. Дені сау болу үшін дұрыс тамақтану және жаттығу керек. Сенімді өнімге ие болу үшін оны сенімді түрде жасау керек. Ыңғайлы CI/CD болуы үшін оны осылай жасау керек. Бұл көп жұмыс істеу керек.
Кубернетес кімге керек деген сұраққа жауап беру – Кубернетес ешкімге керек емес.
Кейбір адамдарда Кубернетес керек деген қате түсінік бар. Адамдарға қажет, олар инфрақұрылымның барлық мәселелеріне және олардың қосымшаларын іске қосу мәселелеріне ойлауды, оқуды және қызығушылықты тоқтатуды қажет етеді. Олар қолданбалардың жай ғана жұмыс істеп, жай ғана орналастырылғанын қалайды. Олар үшін Кубернетес «біз сол жерде жаттык» немесе «біз шыға алмаймыз» немесе басқа нәрсе туралы әңгімені тыңдауды тоқтатады деген үміт.
Бізге әдетте техникалық директор келеді. Олар одан екі нәрсені сұрайды: бір жағынан бізге ерекшелік беріңіз, екінші жағынан тұрақтылық. Біз сізге мұны өзіңізге алып, жасауды ұсынамыз. Күміс оқ, дәлірек айтқанда, күміс жалатылған, сіз бұл мәселелер туралы ойлауды және уақытты босқа кетіруді тоқтатасыз. Сізде бұл мәселені жауып тастайтын арнайы адамдар болады.
Бізге немесе басқаларға Кубернетес қажет деген тұжырым дұрыс емес.
Әкімшілерге шынымен де Кубернетес қажет, өйткені бұл өте қызықты ойыншық, онымен ойнауға және онымен айналысуға болады. Шынын айтайық - бәрі ойыншықтарды жақсы көреді. Біз бәріміз бір жерде баламыз, жаңасын көргенде ойнағымыз келеді. Кейбіреулер үшін бұл, мысалы, әкімшілікте, көңілі қалды, өйткені олар жеткілікті ойнады және қазірдің өзінде шаршады, олар жай қаламайды. Бірақ бұл ешкімге толығымен жоғалған жоқ. Мысалы, егер мен ұзақ уақыт бойы жүйелік басқару және DevOps саласындағы ойыншықтардан шаршаған болсам, мен әлі де ойыншықтарды жақсы көремін, мен әлі де жаңаларын сатып аламын. Барлық адамдар, қалай болғанда да, ойыншықтардың бір түрін қалайды.
Өндіріспен ойнаудың қажеті жоқ. Мен не істемеуді ұсынамын және қазір жаппай көретінім: «О, жаңа ойыншық!» — деп жүгіріп барып сатып алды да: «Қазір оны мектепке апарып, достарымызға көрсетейік». Мұны істеме. Кешірім сұраймын, балаларым енді ғана өсіп келеді, үнемі балалардан бірдеңені көріп, оны өз бойымнан байқаймын, сосын басқаларға жалпылаймын.
Соңғы жауап: сізге Кубернетес қажет емес. Сіз өз мәселелеріңізді шешуіңіз керек.
Сіз қол жеткізе алатын нәрсе:
- өнім құлап кетпейді;
- ол құлап қалмақ болса да, біз бұл туралы алдын ала білеміз және оған бірдеңе салуға болады;
- біз оны бизнесіміз талап ететін жылдамдықта өзгерте аламыз және біз оны ыңғайлы түрде жасай аламыз, бұл бізге ешқандай қиындық тудырмайды.
Екі нақты қажеттілік бар: сенімділік және шығару динамизмі/икемділігі. Қазіргі уақытта қандай да бір IT-жобалармен айналысатын кез келген адам, бизнестің қандай түріне қарамастан - әлемді жеңілдету үшін жұмсақ және мұны түсінетін адам осы қажеттіліктерді шешуі керек. Кубернетес дұрыс көзқараспен, дұрыс түсінігімен және жеткілікті тәжірибесімен оларды шешуге мүмкіндік береді.
Серверсіз туралы
— Егер сіз болашаққа сәл ілгері қарайтын болсаңыз, онда инфрақұрылыммен бас ауруларының жоқтығы мәселесін шешуге тырыссаңыз, шығару жылдамдығымен және қолданбаларды өзгерту жылдамдығымен жаңа шешімдер пайда болады, мысалы, серверсіз. Сіз бұл бағытта қандай да бір әлеуетті сезінесіз бе және айталық, Кубернетес және ұқсас шешімдер үшін қауіп бар ма?
Дмитрий: Осы жерде тағы бір ескертпе айтуымыз керек, мен алға қарап, былай болады деп айтатын көріпкел емеспін! Мен дәл солай істедім. Мен аяғыма қарап, онда көптеген проблемалар бар, мысалы, транзисторлар компьютерде қалай жұмыс істейді. Бұл күлкілі, солай ма? Біз процессорда кейбір қателерге тап болдық.
Барлық экожүйе мәселелерін шеше отырып, серверсіз сенімді, арзан, тиімді және ыңғайлы етіп жасаңыз. Бұл жерде мен Илон Маскпен келісемін, екінші планета адамзатқа қателерге төзімділікті қалыптастыру үшін қажет. Мен оның не айтып жатқанын білмесем де, Марсқа өзім ұшуға дайын емес екенімді және ертең болмайтынын түсінемін.
Серверсіз бұл идеологиялық тұрғыдан дұрыс нәрсе екені анық, мысалы, адамзат үшін қателерге төзімділік - екі планетаның болуы біреуден жақсы. Бірақ қазір мұны қалай жасауға болады? Егер сіз күш-жігеріңізді соған шоғырландырсаңыз, бір экспедиция жіберу қиын емес. Бірнеше экспедиция жіберіп, бірнеше мың адамды сонда орналастыру да шындыққа жақын деп ойлаймын. Бірақ адамзаттың жартысы сонда өмір сүретіндей етіп, оны толығымен қателікке төзімді ету, менің ойымша, қазір мүмкін емес сияқты.
Серверсіз бір-бірден: бәрі жақсы, бірақ бұл 2019 жылғы проблемалардан алыс. 2030 жылға жақын – оны көру үшін өмір сүрейік. Біздің өмір сүретінімізге күмәнім жоқ, біз міндетті түрде өмір сүреміз (ұйқыға жатар алдында қайталаңыз), бірақ енді басқа мәселелерді шешу керек. Бұл кемпірқосақ пони ертегісіне сенгендей. Иә, істердің бір-екі пайызы шешіледі және олар тамаша шешіледі, бірақ субъективті түрде серверсіз - кемпірқосақ... Мен үшін бұл тақырып тым алыс және тым түсініксіз. Мен сөйлесуге дайын емеспін. 2019 жылы серверсіз бір қолданбаны жаза алмайсыз.
Кубернетес қалай дамиды
— Біз осы әлеуетті тамаша алыс болашаққа қарай жылжып келе жатқанда, Кубернетес пен оның айналасындағы экожүйе қалай дамиды деп ойлайсыз?
Дмитрий: Мен бұл туралы көп ойладым және менің нақты жауабым бар. Біріншісі – мемлекеттік – ақыр соңында, азаматтығы жоқ істеу оңайырақ. Кубернетес бастапқыда бұған көбірек ақша салды, бәрі содан басталды. Азаматтығы жоқ адамдар Кубернетесте тамаша жұмыс істейді, шағымданатын ештеңе жоқ. Әлі де көптеген мәселелер, дәлірек айтсақ, нюанстар бар. Онда бәрі қазірдің өзінде біз үшін тамаша жұмыс істейді, бірақ бұл біз. Мұның барлығына жұмыс істеуі үшін кемінде бір-екі жыл қажет. Бұл есептелген көрсеткіш емес, менің басымнан алған сезімім.
Бір сөзбен айтқанда, мемлекеттік ақпарат өте күшті дамып кетуі керек және болады, өйткені біздің барлық қолданбалар күйді сақтайды; азаматтығы жоқ қолданбалар жоқ. Бұл иллюзия; сізге әрқашан қандай да бір дерекқор және басқа нәрсе қажет. Statefull - бұл мүмкін болатынның бәрін түзету, барлық қателерді түзету, қазіргі кезде кездесетін барлық мәселелерді жақсарту - оны қабылдау деп атаймыз.
Белгісіз деңгейі, шешілмеген мәселелер деңгейі, бір нәрсеге тап болу ықтималдығы деңгейі айтарлықтай төмендейді. Бұл маңызды оқиға. Ал операторлар – оңай қызмет алу үшін басқару логикасын кодификациялаумен, басқару логикасымен байланысты барлығы: MySQL оңай сервисі, RabbitMQ оңай сервисі, Memcache оңай сервисі – жалпы алғанда, біз жұмыс істеуге кепілдік беруіміз керек осы компоненттердің барлығы. қорап. Бұл жай ғана дерекқорды қалайтын мәселені шешеді, бірақ біз оны басқарғымыз келмейді немесе біз Кубернетесті қалаймыз, бірақ оны басқарғымыз келмейді.
Оператордың бір немесе басқа түрде дамуының бұл тарихы алдағы екі жылда маңызды болады.
Менің ойымша, пайдаланудың қарапайымдылығы айтарлықтай артуы керек - қорап барған сайын қара болады, барған сайын сенімдірек, қарапайым тұтқалары бар.
Мен бір рет YouTube сайтында Saturday Night Live бағдарламасында 80-ші жылдардағы Исаак Азимовпен ескі сұхбатты тыңдадым - Ургант сияқты бағдарлама, тек қызықты. Олар одан компьютерлердің болашағы туралы сұрады. Болашақ радио сияқты қарапайымдылықта екенін айтты. Радиоқабылдағыш бастапқыда күрделі нәрсе болды. Толқынды ұстау үшін тұтқаларды 15 минутқа айналдырып, шашлықты бұрып, барлығының қалай жұмыс істейтінін білу керек, радиотолқындарды беру физикасын түсіну керек. Нәтижесінде радиода бір ғана тұтқа қалды.
Енді 2019 жылы қандай радио? Автокөлікте радиоқабылдағыш барлық толқындар мен станциялардың атауларын табады. Процестің физикасы 100 жылда өзгерген жоқ, бірақ пайдаланудың қарапайымдылығы болды. Қазір, қазір ғана емес, 1980 жылы Азимовпен сұхбат болған кезде бәрі радионы пайдаланды және оның қалай жұмыс істейтіні туралы ешкім ойлаған жоқ. Бұл әрқашан жұмыс істеді - бұл берілген.
Азимов содан кейін компьютерлермен де солай болатынын айтты - пайдалану жеңілдігі артады. 1980 жылы компьютердегі түймелерді басуға үйрету керек болса, болашақта олай болмайды.
Мен Kubernetes-пен және инфрақұрылыммен бірге пайдаланудың қарапайымдылығында үлкен өсім болады деп ойлаймын. Бұл, менің ойымша, анық - бұл бетінде жатыр.
Инженерлермен не істеу керек?
— Сонда Кубернетесті қолдайтын инженерлер мен жүйелік әкімшілермен не болады?
Дмитрий: 1С пайда болғаннан кейін бухгалтерге не болды? Шамамен бірдей. Бұған дейін олар қағазбен санады - енді бағдарламада. Еңбек өнімділігі еселеп өсті, бірақ еңбектің өзі жойылған жоқ. Бұрын электр шамын бұрау үшін 10 инженер қажет болса, енді біреуі жетеді.
Бағдарламалық жасақтаманың көлемі мен тапсырмалардың саны, менің ойымша, қазір жаңа DevOps пайда болғаннан және тиімділік артып келе жатқаннан гөрі жылдамырақ өсуде. Дәл қазір нарықта белгілі бір тапшылық бар және ол ұзақ уақытқа созылады. Кейінірек бәрі қалыпты жағдайға оралады, онда жұмыс тиімділігі артады, серверсіз болады, Кубернетеске нейрон қосылады, ол барлық ресурстарды қажетінше таңдайды және жалпы бәрін өзіңіз жасаңыз, солай істеу керек - адам жай ғана кетіп қалады және араласпайды.
Бірақ біреу әлі де шешім қабылдауы керек. Бұл кісінің біліктілігі мен мамандану деңгейі жоғары екені анық. Қазір бухгалтерияда қолы шаршамас үшін кітап жүргізетін 10 қызметкердің керегі жоқ. Бұл жай ғана қажет емес. Көптеген құжаттар электронды құжат айналымы жүйесі арқылы автоматты түрде сканерленеді және танылады. Бір ақылды бас есепші жеткілікті, қазірдің өзінде әлдеқайда жоғары дағдылары бар, жақсы түсінеді.
Жалпы, барлық салада осылай жүру керек. Көліктерде де солай: бұрын көлік механик пен үш жүргізушімен келетін. Қазіргі уақытта көлік жүргізу – бәріміз күнделікті қатысатын қарапайым процесс. Көлікті күрделі нәрсе деп ешкім ойламайды.
DevOps немесе жүйелік инженерия жойылмайды - жоғары деңгейдегі жұмыс пен тиімділік артады.
— Жұмыс шын мәнінде артады деген қызық ой да естідім.
Дмитрий: Әрине, жүз пайыз! Өйткені біз жазатын бағдарламалық жасақтаманың көлемі үнемі өсіп келеді. Біз бағдарламалық қамтамасыз ету арқылы шешетін мәселелер саны үнемі өсіп келеді. Жұмыс көлемі артып келеді. Қазір DevOps нарығы қатты қызып кетті. Мұны жалақы күтулерінен көруге болады. Жақсы мағынада, егжей-тегжейлі айтпай-ақ, X-ті қалайтын кішілер, 1,5X-ті қалайтын орталар және 2X-ті қалайтын ересектер болуы керек. Ал енді, егер сіз Мәскеудегі DevOps жалақы нарығына қарасаңыз, кіші оқушы X-тен 3X-ке дейін, ал аға буын X-тен 3X-ке дейін қалайды.
Оның қанша тұратынын ешкім білмейді. Жалақы деңгейі сіздің сенімділігіңізбен өлшенеді - толық жындыхана, шынын айтқанда, өте қызып кеткен нарық.
Әрине, бұл жағдай өте жақын арада өзгереді - кейбір қанықтыру орын алуы керек. Бағдарламалық жасақтаманы әзірлеуде бұлай емес – барлығына әзірлеушілер керек, ал жақсы әзірлеушілер барлығына керек болса да, нарық кімнің не нәрсеге тұрарлық екенін түсінеді – сала орнықты. Бұл күндері DevOps-та олай емес.
— Естуім бойынша, қазіргі жүйелік әкімші көп уайымдамауы керек, бірақ оның біліктілігін арттырып, ертең жұмыс көп болатынына, бірақ оның біліктілігі жоғарырақ болатынына дайындалу керек деген қорытындыға келдім.
Дмитрий: Жүз пайыз. Жалпы, біз 2019 жылы өмір сүріп жатырмыз және өмір ережесі мынау: өмір бойы оқыту - біз өмір бойы үйренеміз. Менің ойымша, қазір бәрі мұны біледі және сезінеді, бірақ білу жеткіліксіз - мұны істеу керек. Біз күн сайын өзгеруіміз керек. Осылай жасамасақ, ерте ме, кеш пе кәсіптің шетіне қаламыз.
180 градустық күрт бұрылыстарға дайын болыңыз. Мен бірдеңе түбегейлі өзгеретін, жаңа нәрсе ойлап табылған жағдайды жоққа шығармаймын - бұл болады. Хоп! - ал біз қазір басқаша әрекет етеміз. Бұған дайын болу және алаңдамау маңызды. Ертең менің істегенімнің бәрі қажетсіз болып шығуы мүмкін - ештеңе, мен өмір бойы оқыдым және басқа нәрсені үйренуге дайынмын. Бұл мәселе емес. Жұмыс қауіпсіздігінен қорқудың қажеті жоқ, бірақ сіз үнемі жаңа нәрсені үйренуге дайын болуыңыз керек.
Тілектер мен бір минуттық жарнама
- Тілегің бар ма?
Дмитрий: Иә, менің бірнеше тілегім бар.
Бірінші және коммерциялық - жазылыңыз . Құрметті оқырмандар, YouTube сайтына кіріп, арнамызға жазылыңыз. Шамамен бір айдан кейін біз бейне сервисті белсенді түрде кеңейтуді бастаймыз. Бізде Kubernetes туралы ашық және әртүрлі білім беру мазмұны болады: практикалық заттардан бастап зертханаларға дейін, терең іргелі теориялық нәрселерге және Kubernetes-ті компьютерде қалай пайдалануға болады. принциптер мен үлгілердің деңгейі.
Екінші сауда тілек - барыңыз және жұлдыздарды қойыңыз, өйткені біз олармен қоректенеміз. Бізге жұлдыз бермесең, жейтін ештеңеміз болмайды. Бұл компьютер ойынындағы мана сияқты. Біз бірдеңе жасаймыз, жасаймыз, тырысамыз, біреу бұл қорқынышты велосипедтер дейді, біреу бәрі мүлдем дұрыс емес деп айтады, бірақ біз жалғастырамыз және мүлдем адал әрекет етеміз. Біз проблеманы көріп, оны шешеміз және тәжірибемізбен бөлісеміз. Сондықтан бізге жұлдыз беріңіз, ол сізден кетпейді, бірақ ол бізге келеді, өйткені біз олармен қоректенеміз.
Үшіншіден, маңызды және енді коммерциялық емес тілек - ертегілерге сенуді доғар. Сіз кәсіби мамандарсыз. DevOps - бұл өте маңызды және жауапты мамандық. Жұмыс орнында ойнауды тоқтатыңыз. Сіз үшін басуға рұқсат етіңіз және сіз оны түсінесіз. Сіз ауруханаға келгеніңізді елестетіп көріңіз, сонда дәрігер сізге тәжірибе жасап жатыр. Мен бұл біреуді қорлауы мүмкін екенін түсінемін, бірақ, мүмкін, бұл сіз туралы емес, басқа біреу туралы. Басқаларға да тоқтауды айт. Бұл бәріміз үшін өмірді бұзады - көбісі операцияларды, әкімшілерді және DevOps-ті қайтадан бірдеңені бұзған жігіттер ретінде қарастыра бастайды. Көбінесе «бұзылған» ойын ойнауға барғандықтан, былай, былай деп салқынқандылықпен қарамаған едік.
Бұл эксперимент жасамау керек дегенді білдірмейді. Тәжірибе жасау керек, өзіміз жасаймыз. Шынымды айтсам, біз өзіміз кейде ойын ойнаймыз - бұл, әрине, өте жаман, бірақ бізге ештеңе де жат емес. 2019 жылды өндірістегі ойындар емес, байыпты, ойластырылған эксперименттер жылы деп жариялайық. Мүмкін солай шығар.
- Үлкен рахмет!
Дмитрий: Виталий, уақыт бөлгеніңіз үшін де, сұхбат бергеніңіз үшін де рахмет. Құрметті оқырмандар, егер сіз кенеттен осы деңгейге жеткен болсаңыз, сізге көп рахмет. Біз сізге кем дегенде бір-екі ой әкелдік деп үміттенемін.
Сұхбатта Дмитрий верф мәселесіне тоқталды. Енді бұл барлық дерлік мәселелерді шешетін әмбебап швейцар пышағы. Бірақ әрқашан олай болған жоқ. Қосулы фестивальде Дмитрий Столяров сізге бұл құрал туралы егжей-тегжейлі айтып береді. есепте бәрі болады: Кубернетестің проблемалары мен жасырын нюанстары, осы қиындықтарды шешу нұсқалары және werf-тің ағымдағы орындалуы егжей-тегжейлі. 27 және 28 мамырда бізге қосылыңыз, біз тамаша құралдарды жасаймыз.
Ақпарат көзі: www.habr.com