Здраво на сите! Јас се викам Павел Агалецки. Работам како тимски лидер во тим кој го развива системот за испорака на Ламода. Во 2018 година, зборував на конференцијата HighLoad++, а денес би сакал да презентирам препис од мојот извештај.

Мојата тема е посветена на искуството на нашата компанија во распоредувањето системи и услуги во различни средини. Почнувајќи од нашите праисториски времиња, кога ги распоредивме сите системи во обични виртуелни сервери, завршувајќи со постепен премин од Номад до распоредување во Кубернетес. Ќе ви кажам зошто го направивме тоа и какви проблеми имавме во процесот.

Распоредување на апликации на VM

Да почнеме со фактот дека пред 3 години сите системи и услуги на компанијата беа распоредени на редовни виртуелни сервери. Технички, тој беше организиран на таков начин што целиот код за нашите системи беше зачуван и склопен со помош на алатки за автоматско склопување, користејќи џенкинс. Користејќи го Ansible, тој беше пренесен од нашиот систем за контрола на верзии на виртуелни сервери. Покрај тоа, секој систем што го имаше нашата компанија беше распореден на најмалку 2 сервери: еден од нив на главата, вториот на опашката. Овие два системи беа апсолутно идентични еден со друг во сите нивни поставки, моќност, конфигурација итн. Единствената разлика меѓу нив беше тоа што главата добиваше кориснички сообраќај, додека опашката никогаш не добиваше кориснички сообраќај.

За што беше?

Кога ги распоредивме новите изданија на нашата апликација, сакавме да обезбедиме непречено ширење, односно без забележливи последици за корисниците. Ова беше постигнато поради фактот што следното компајлирано издание со помош на Ansible беше истурено до опашката. Таму, луѓето кои беа вклучени во распоредувањето можеа да проверат и да се уверат дека сè е во ред: сите метрики, секции и апликации функционираат; се лансираат потребните скрипти. Дури откако се увериле дека се е во ред, сообраќајот бил сменет. Почна да оди на серверот кој претходно беше опаш. А онаа што претходно беше глава остана без кориснички сообраќај, додека на неа сè уште ја имаше претходната верзија на нашата апликација.

Така беше беспрекорно за корисниците. Бидејќи префрлувањето е моментално, бидејќи тоа е едноставно префрлување на балансерот. Можете многу лесно да се вратите на претходната верзија со едноставно префрлање на балансерот назад. Можевме и да потврдиме дека апликацијата е способна да се произведува дури и пред да добие кориснички сообраќај, што беше доста погодно.

Какви предности видовме во сето ова?

1. Како прво, доволно е тоа само функционира. Секој разбира како функционира таквата шема за распоредување, бидејќи повеќето луѓе некогаш се распоредиле на редовни виртуелни сервери.
2. Ова е доволно сигурно, бидејќи технологијата на распоредување е едноставна, тестирана од илјадници компании. Милиони сервери се распоредени на овој начин. Тешко е да се скрши нешто.
3. И конечно можевме да добиеме атомски распоредувања. Распоредувања кои се случуваат истовремено за корисниците, без забележлива фаза на префрлување помеѓу старата и новата верзија.

Но, во сето ова видовме и неколку недостатоци:

1. Во прилог на производствената средина, развојната средина, постојат и други средини. На пример, qa и предпродукција. Во тоа време имавме многу сервери и околу 60 сервиси. Поради оваа причина беше неопходно за секоја услуга, одржувајте ја најновата верзија за неа Виртуелна машина. Покрај тоа, ако сакате да ги ажурирате библиотеките или да инсталирате нови зависности, треба да го направите ова во сите средини. Исто така, требаше да го синхронизирате времето кога ќе ја распоредите следната нова верзија на вашата апликација со времето кога devops ги извршува потребните поставки за околината. Во овој случај, лесно е да се дојде во ситуација кога нашата средина ќе биде малку поинаква во сите средини одеднаш. На пример, во опкружување QA ќе има некои верзии на библиотеки, а во производствена средина ќе има различни, што ќе доведе до проблеми.
2. Тешкотии при ажурирање на зависностите вашата апликација. Не зависи од вас, туку од другиот тим. Имено, од тимот на devops кој ги одржува серверите. Мора да им дадете соодветна задача и опис на она што сакате да го направите.
3. Во тоа време, сакавме да ги поделиме и големите големи монолити што ги имавме на посебни мали сервиси, бидејќи разбравме дека ќе ги има се повеќе и повеќе. Во тоа време, веќе имавме повеќе од 100. За секоја нова услуга, беше неопходно да се создаде посебна нова виртуелна машина, која исто така требаше да се одржува и распореди. Покрај тоа, не ви треба еден автомобил, туку најмалку два. На сето ова додадена е и QA околината. Ова предизвикува проблеми и ви го отежнува градењето и водење на нови системи. сложен, скап и долг процес.

Затоа, решивме дека ќе биде попогодно да се префрлиме од распоредување на редовни виртуелни машини до распоредување на нашите апликации во докер контејнер. Ако имате докер, потребен ви е систем што може да ја изврши апликацијата во кластер, бидејќи не можете само да подигнете контејнер. Обично сакате да следите колку контејнери се подигнати за да се подигнат автоматски. Поради оваа причина, требаше да избереме контролен систем.

Долго размислувавме кој да го земеме. Факт е дека во тоа време овој оџак за распоредување на редовните виртуелни сервери беше нешто застарен, бидејќи тие ги немаа најновите верзии на оперативни системи. Во одреден момент, имаше дури и FreeBSD, што не беше многу погодно за поддршка. Разбравме дека треба да мигрираме на докер што е можно побрзо. Нашите Deops го разгледаа нивното постоечко искуство со различни решенија и избраа систем како Nomad.

Префрлете се на Номад

Номад е производ на HashiCorp. Тие се познати и по нивните други решенија:

„Конзул“ е алатка за откривање услуга.

„Тераформ“ - систем за управување со сервери кој ви овозможува да ги конфигурирате преку конфигурација, таканаречена инфраструктура-како-код.

„скитник“ ви овозможува да распоредите виртуелни машини локално или во облакот преку специфични конфигурациски датотеки.

Номад во тоа време изгледаше како прилично едноставно решение на кое можеше брзо да се префрли без да се промени целата инфраструктура. Покрај тоа, тоа е прилично лесно да се научи. Затоа го избравме како систем за филтрирање за нашиот контејнер.

Што ви е потребно за да го распоредите вашиот систем на Номад?

1. Прво на сите ви треба докерска слика вашата апликација. Треба да го изградите и да го ставите во складиштето за слики на докер. Во нашиот случај, ова е артефабрика - систем кој ви овозможува да туркате разни артефакти од различни типови во него. Може да складира архиви, докер слики, композиторски PHP пакети, NPM пакети итн.
2. Исто така се бара конфигурациска датотека, кој ќе му каже на Номад што, каде и во колкава количина сакате да распоредите.

Кога зборуваме за Nomad, тој го користи јазикот HCL како формат на информативна датотека, што значи Јазик за конфигурација на HashiCorp. Ова е суперсет на Yaml што ви овозможува да ја опишете вашата услуга со термини на Номад.

Ви овозможува да кажете колку контејнери сакате да распоредите, од кои слики да им пренесат различни параметри за време на распоредувањето. Така, ја нахранувате оваа датотека на Nomad, и таа лансира контејнери во производство според неа.

Во нашиот случај, сфативме дека едноставно пишување апсолутно идентични датотеки HCL за секоја услуга нема да биде многу погодно, бидејќи има многу услуги и понекогаш сакате да ги ажурирате. Се случува една услуга да биде распоредена не во еден пример, туку во различни различни. На пример, еден од системите што ги имаме во производство има повеќе од 100 примероци во производството. Тие работат од истите слики, но се разликуваат во поставките за конфигурација и конфигурациските датотеки.

Затоа, решивме дека ќе ни биде погодно да ги складираме сите наши конфигурациски датотеки за распоредување во едно заедничко складиште. На овој начин тие беа видливи: беа лесни за одржување и можевме да видиме какви системи имаме. Доколку е потребно, исто така е лесно да се ажурира или промени нешто. Додавањето нов систем исто така не е тешко - само треба да креирате конфигурациска датотека во новиот директориум. Внатре во него се следните датотеки: service.hcl, кој содржи опис на нашата услуга, и некои env-датотеки кои овозможуваат конфигурирање на оваа услуга, која е распоредена во производството.

Сепак, некои од нашите системи се распоредени во производството не во една копија, туку во неколку одеднаш. Затоа, решивме дека би било погодно да ги складираме конфигурациите не во нивната чиста форма, туку во нивната шаблонска форма. И ние избравме џинџа 2. Во овој формат, ги складираме и конфигурациите на самата услуга и датотеките env потребни за неа.

Дополнително, поставивме во складиштето скрипта за распоредување заедничка за сите проекти, која ви овозможува да ја стартувате и распоредите вашата услуга во производство, во посакуваното опкружување, во саканата цел. Во случај кога ја претворивме нашата конфигурација HCL во шаблон, тогаш датотеката HCL, која претходно беше редовна конфигурација на Nomad, во овој случај почна да изгледа малку поинаку.

Односно, заменивме некои променливи за локација за конфигурација со вметнати променливи кои се преземени од env датотеки или други извори. Дополнително, добивме можност динамично да собираме датотеки HCL, односно можеме да користиме не само обични вметнувања на променливи. Бидејќи jinja поддржува циклуси и услови, можете да креирате и конфигурациски датотеки таму, кои се менуваат во зависност од тоа каде точно ги распоредувате вашите апликации.

На пример, сакате да ја распоредите вашата услуга за претпродукција и производство. Да речеме дека во претпродукцијата не сакате да извршувате скрипти за cron, туку само сакате да ја видите услугата на посебен домен за да бидете сигурни дека таа функционира. За секој кој ја распоредува услугата, процесот изгледа многу едноставен и транспарентен. Сè што треба да направите е да ја извршите датотеката deploy.sh, да наведете која услуга сакате да ја распоредите и на која цел. На пример, сакате да распоредите одреден систем во Русија, Белорусија или Казахстан. За да го направите ова, едноставно сменете еден од параметрите и ќе ја имате точната конфигурациска датотека.

Кога услугата Номад е веќе распоредена во вашиот кластер, изгледа вака.

Прво, потребен ви е некој вид балансер надвор, кој ќе го прима целиот кориснички сообраќај. Ќе работи заедно со конзулот и од него ќе дознае каде, на кој јазол, на која IP адреса се наоѓа одредена услуга што одговара на одредено име на домен. Услугите во Конзул доаѓаат од самиот Номад. Бидејќи се работи за производи од иста компанија, тие се доста поврзани еден со друг. Можеме да кажеме дека Номад надвор од кутијата може да ги регистрира сите услуги лансирани во него во конзулот.

Откако вашиот преден балансер на оптоварување знае на која услуга да испрати сообраќај, го препраќа до соодветниот контејнер или повеќе контејнери што одговараат на вашата апликација. Секако, неопходно е да се размислува и за безбедноста. Иако сите услуги работат на истите виртуелни машини во контејнери, ова обично бара да се спречи бесплатен пристап од која било услуга до која било друга. Тоа го постигнавме преку сегментација. Секоја услуга беше лансирана во сопствена виртуелна мрежа, на која беа пропишани правила за рутирање и правила за дозволување/одбивање пристап до други системи и услуги. Тие би можеле да бидат лоцирани и внатре во овој кластер и надвор од него. На пример, ако сакате да спречите поврзување на услуга со одредена база на податоци, тоа може да се направи преку сегментација на ниво на мрежа. Тоа е, дури и по грешка, не можете случајно да се поврзете од околината за тестирање со вашата база на податоци за производство.

Колку не чинеше транзицијата од аспект на човечки ресурси?

Преминот на целата компанија во Номад траеше приближно 5-6 месеци. Се движевме на база услуга по услуга, но со прилично брзо темпо. Секој тим мораше да создаде свои контејнери за услугите.

Усвоивме таков пристап што секој тим е одговорен за докер сликите на нивните системи независно. DevOps ја обезбедуваат општата инфраструктура неопходна за распоредување, односно поддршка за самиот кластер, поддршка за системот CI итн. И во тоа време, имавме повеќе од 60 системи преместени во Номад, што изнесуваше околу 2 илјади контејнери.

Devops е одговорен за општата инфраструктура на сè што е поврзано со распоредувањето и серверите. И секој тим за развој, пак, е одговорен за имплементација на контејнери за неговиот специфичен систем, бидејќи тимот е тој што знае што генерално му треба во одреден контејнер.

Причини за напуштање на Номад

Кои предности ги добивме со префрлување на распоредување користејќи Nomad и docker, меѓу другото?

1. Ние обезбеди еднакви услови за сите средини. Во развојот, QA околина, пред-продукција, производство, се користат исти слики од контејнери, со исти зависности. Според тоа, практично немате шанси дека она што ќе заврши во производството не е она што претходно сте го тестирале локално или во вашата средина за тестирање.
2. Откривме и дека е доволно лесно да додадете нова услуга. Од гледна точка на распоредување, сите нови системи се лансираат многу едноставно. Само одете во складиштето што ги складира конфигурациите, додадете друга конфигурација за вашиот систем таму и сè е подготвено. Можете да го распоредите вашиот систем на производство без дополнителен напор од devops.
3. сите конфигурациски датотеки во едно заедничко складиште испадна дека е на преглед. Во времето кога ги распоредивме нашите системи користејќи виртуелни сервери, користевме Ansible, во кој конфигурациите беа во истото складиште. Сепак, за повеќето програмери ова беше малку потешко да се работи. Овде обемот на конфигурации и код што треба да ги додадете за да ја распоредите услугата стана многу помал. Плус, на devop е многу лесно да го поправат или променат. Во случај на транзиции, на пример, на нова верзија на Nomad, тие можат да ги преземат и масовно да ги ажурираат сите оперативни датотеки лоцирани на истото место.

Но, наидовме и на неколку недостатоци:

Се испостави дека ние не можеше да постигне беспрекорно распоредување во случајот Номад. Кога се тркалаат контејнери под различни услови, може да се испостави дека работи, а Номад го сфатил како контејнер подготвен да прими сообраќај. Ова се случи пред апликацијата во неа да има шанса да се стартува. Поради оваа причина, системот почна да произведува 500 грешки за краток временски период, бидејќи сообраќајот почна да оди до контејнер кој сè уште не беше подготвен да го прифати.

Наидовме на некои покрај мочуриштата. Најзначајната грешка е тоа што Nomad не се справува многу добро со голем кластер ако имате многу системи и контејнери. Кога сакате да извадите еден од серверите што е вклучен во кластерот Nomad за одржување, постои прилично голема веројатност кластерот да не се чувствува многу добро и да се распадне. Некои контејнери може, на пример, да паднат и да не се издигнат - ова ќе ве чини многу подоцна ако сите ваши системи за производство се наоѓаат во кластер управуван од Nomad.

Затоа решивме да размислиме каде да одиме понатаму. Во тој момент станавме многу посвесни за тоа што сакаме да постигнеме. Имено: сакаме доверливост, малку повеќе функции отколку што обезбедува Номад и позрел, постабилен систем.

Во овој поглед, нашиот избор падна на Kubernetes како најпопуларна платформа за лансирање кластери. Особено со оглед на тоа што големината и бројот на нашите контејнери беа доволно големи. За такви цели, Kubernetes се чинеше дека е најсоодветен систем што можевме да го погледнеме.

Транзиција кон Кубернетес

Ќе ви кажам малку за основните концепти на Kubernetes и како тие се разликуваат од Nomad.

Како прво, најосновниот концепт во Кубернетес е концептот на под. Pod е група од еден или повеќе контејнери кои секогаш работат заедно. И тие секогаш работат како строго на една виртуелна машина. Тие се достапни меѓу себе преку IP 127.0.0.1 на различни порти.

Да претпоставиме дека имате PHP апликација која се состои од nginx и php-fpm - класичната шема. Најверојатно, ќе сакате постојано да ги чувате контејнерите nginx и php-fpm заедно. Kubernetes ви овозможува да го постигнете ова со опишување на нив како една заедничка подлога. Токму тоа не можевме да го добиеме со Номад.

Вториот концепт е распоредување. Факт е дека самата мешунка е ефемерна работа, почнува и исчезнува. Дали сакате прво да ги убиете сите ваши претходни контејнери, а потоа да лансирате нови верзии одеднаш или сакате постепено да ги пуштате во продажба? Ова е процес за кој е одговорен концептот на распоредување. Опишува како ги распоредувате вашите мешунки, во која количина и како да ги ажурирате.

Третиот концепт е Сервис. Вашата услуга е всушност вашиот систем, кој прима одреден сообраќај и потоа го препраќа до еден или повеќе подлоги што одговараат на вашата услуга. Односно, ви овозможува да кажете дека целиот дојдовен сообраќај до таква и таква услуга со такво и такво име мора да се испрати до овие специфични подлоги. И во исто време ви овозможува балансирање на сообраќајот. Односно, можете да стартувате два пода од вашата апликација и целиот дојдовен сообраќај ќе биде рамномерно избалансиран помеѓу подлогите поврзани со оваа услуга.

И четвртиот основен концепт е Целосно. Ова е услуга која работи на кластерот Kubernetes. Дејствува како надворешен баланс на оптоварување кој ги презема сите барања. Користејќи го Kubernetes API, Ingress може да одреди каде треба да се испратат овие барања. Покрај тоа, тој го прави ова многу флексибилно. Може да кажете дека сите барања до овој домаќин и такви и такви URL се испраќаат до оваа услуга. И овие барања кои доаѓаат до овој хост и до друг URL се испраќаат до друга услуга.

Најкул работа од гледна точка на некој што развива апликација е тоа што можете сами да управувате со сето тоа. Со поставување на конфигурацијата Ingress, можете да го испратите целиот сообраќај што доаѓа до такво и такво API до одделни контејнери напишани, на пример, во Go. Но, овој сообраќај, кој доаѓа до истиот домен, но на различен URL, треба да се испрати во контејнери напишани во PHP, каде што има многу логика, но тие не се многу брзи.

Ако ги споредиме сите овие концепти со Nomad, можеме да кажеме дека првите три концепти се сите заедно Service. А последниот концепт е отсутен во самиот Номад. Користивме надворешен балансер како него: може да биде хапрокси, nginx, nginx+ итн. Во случај на коцка, не треба посебно да го воведувате овој дополнителен концепт. Меѓутоа, ако го погледнете Ingress внатрешно, тоа е или nginx, хапрокси или траефик, но некако вградено во Kubernetes.

Сите концепти што ги опишав се, всушност, ресурси кои постојат во кластерот Кубернет. За да се опишат во коцката, се користи формат yaml, кој е почитлив и попознат од датотеките HCL во случајот на Nomad. Но, структурно тие го опишуваат истото во случај на, на пример, под. Тие велат - сакам да распоредам такви и такви мешунки таму, со такви и такви слики, во такви и такви количини.

Дополнително, сфативме дека не сакаме рачно да го создаваме секој поединечен ресурс: распоредување, услуги, Ingress итн. Наместо тоа, сакавме да го опишеме секој наш систем во смисла на Kubernetes за време на распоредувањето, за да не мораме рачно да ги пресоздаваме сите потребни зависности од ресурси во правилен редослед. Хелм беше избран како систем кој ни го овозможи тоа.

Основни концепти во Helm

Кормилото е менаџер на пакети за Кубернетес. Тоа е многу слично на тоа како работат менаџерите на пакети во програмските јазици. Тие ви дозволуваат да складирате услуга која се состои од, на пример, распоредување nginx, распоредување php-fpm, конфигурација за Ingress, configmaps (ова е ентитет што ви овозможува да поставите env и други параметри за вашиот систем) во форма на т.н. наречени графикони. Во исто време Хелм трча на врвот на Кубернетес. Односно, ова не е некој вид систем што стои настрана, туку само уште една услуга лансирана внатре во коцката. Вие комуницирате со него преку неговото API преку команда на конзолата. Неговата практичност и убавина е што дури и ако кормилото се скрши или го отстраните од кластерот, вашите услуги нема да исчезнат, бидејќи кормилото во суштина служи само за стартување на системот. Самиот Kubernetes тогаш е одговорен за перформансите и состојбата на услугите.

Тоа го сфативме и ние шаблонизација, што претходно бевме принудени сами да го направиме со воведување џинџа во нашите конфигурации, е една од главните карактеристики на кормилото. Сите конфигурации што ги креирате за вашите системи се зачувани во кормилото во форма на шаблони, малку слични на џинџа, но, всушност, користејќи го шаблонот на јазикот Go, на кој е напишано кормилото, како Кубернетес.

Хелм додава уште неколку концепти за нас.

Графикон - ова е опис на вашата услуга. Во другите менаџери на пакети тоа би се нарекувало пакет, пакет или нешто слично. Тука се вика графикон.

Вредности се променливите што сакате да ги користите за да ги изградите вашите конфигурации од шаблони.

Ослободување. Секој пат кога услугата што е распоредена со помош на кормилото добива дополнителна верзија на изданието. Хелм се сеќава што беше конфигурацијата на услугата во претходното издание, изданието пред тоа итн. Затоа, ако треба да се вратите назад, само извршете ја командата за повратен повик на кормилото, насочувајќи ја кон претходната верзија. Дури и ако соодветната конфигурација во вашето складиште не е достапна во моментот на враќање назад, кормилото сепак ќе се сеќава што беше и ќе го врати вашиот систем во состојбата во која беше во претходното издание.

Во случај кога користиме кормило, редовните конфигурации за Kubernetes исто така се претвораат во шаблони во кои е можно да се користат променливи, функции и да се применат условни искази. На овој начин можете да ја соберете конфигурацијата на вашата услуга во зависност од околината.

Во пракса, решивме да ги правиме работите малку поинаку отколку што правевме со Номад. Ако во Nomad и конфигурациите за распоредување и n-променливите што беа потребни за распоредување на нашата услуга беа складирани во едно складиште, овде решивме да ги поделиме на две посебни складишта. Складиштето „deploy“ складира само n-променливи потребни за распоредување, а складиштето „helm“ складира конфигурации или графикони.

Што ни даде ова?

И покрај фактот што не складираме навистина чувствителни податоци во самите конфигурациски датотеки. На пример, лозинки за бази на податоци. Тие се чуваат како тајни во Kubernetes, но сепак, таму сè уште има одредени работи до кои не сакаме да им дадеме пристап на сите. Затоа, пристапот до складиштето за „распоредување“ е поограничен, а складиштето „кормило“ едноставно содржи опис на услугата. Поради оваа причина, до него може безбедно да се пристапи од поширок опсег на луѓе.

Бидејќи имаме не само производство, туку и други средини, благодарение на ова одвојување можеме повторно да ги користиме нашите табели на кормилото за да ги распоредиме услугите не само во производството, туку и, на пример, во околина за QA. Дури и да ги распореди локално користејќи Миникубе - ова е работа за локално водење на Кубернетес.

Внатре во секое складиште, оставивме поделба на посебни директориуми за секоја услуга. Односно, во секој директориум има шаблони поврзани со соодветната табела и ги опишуваат ресурсите што треба да се распоредат за да се стартува нашиот систем. Оставивме само envs во складиштето „deploy“. Во овој случај, не користевме шаблон користејќи џинџа, бидејќи самиот кормило обезбедува шаблон надвор од кутијата - ова е една од неговите главни функции.

Оставивме скрипта за распоредување - deploy.sh, која го поедноставува и стандардизира стартувањето за распоредување со помош на кормилото. Значи, за секој што сака да се распореди, интерфејсот за распоредување изгледа сосема исто како што изгледаше при распоредувањето преку Nomad. Истиот deploy.sh, името на вашата услуга и каде сакате да ја распоредите. Ова предизвикува кормилото да се вклучи внатрешно. Тој, пак, собира конфигурации од шаблони, ги вметнува датотеките со потребните вредности во нив, потоа ги распоредува, лансирајќи ги во Кубернет.

Наоди

Се чини дека услугата Kubernetes е посложена од Nomad.

Овде појдовниот сообраќај доаѓа до Ingress. Ова е само предниот контролер, кој ги презема сите барања и последователно ги испраќа до услугите што одговараат на податоците за барањето. Ги одредува врз основа на конфигурации кои се дел од описот на вашата апликација во кормилото и кои програмерите ги поставуваат сами. Услугата испраќа барања до своите подлоги, односно специфични контејнери, балансирајќи го дојдовниот сообраќај помеѓу сите контејнери што припаѓаат на оваа услуга. И, се разбира, не треба да заборавиме дека не треба да одиме никаде од безбедноста на ниво на мрежа. Затоа, сегментацијата работи во кластерот Kubernetes, кој се заснова на означување. Сите услуги имаат одредени ознаки на кои се поврзани правата за пристап на услугите до одредени надворешни/внатрешни ресурси во или надвор од кластерот.

Како што ја правевме транзицијата, видовме дека Kubernetes ги има сите можности на Nomad, кои претходно ги користевме, а исто така додаде и многу нови работи. Може да се прошири преку приклучоци, а всушност преку сопствени типови на ресурси. Односно, имате можност не само да користите нешто што доаѓа со Kubernetes надвор од кутијата, туку да креирате сопствен ресурс и услуга што ќе го чита вашиот ресурс. Ова ви дава дополнителни опции за проширување на вашиот систем без да мора повторно да го инсталирате Kubernetes и без да барате модификации.

Пример за таква употреба е Прометеј, кој работи во нашиот кластер Kubernetes. За да почне да собира метрика од одредена услуга, треба да додадеме дополнителен тип на ресурс, таканаречениот сервисен монитор, во описот на услугата. Prometheus, поради фактот што може да чита приспособен тип на ресурси кога ќе биде лансиран во Kubernetes, автоматски започнува со собирање метрики од новиот систем. Тоа е доста погодно.

Првото распоредување на Кубернетес беше во март 2018 година. И за ова време никогаш не доживеавме никакви проблеми со тоа. Работи доста стабилно без значителни грешки. Покрај тоа, можеме дополнително да го прошириме. Денес имаме доволно можности што ги има, и навистина ни се допаѓа темпото на развој на Kubernetes. Во моментов, повеќе од 3000 контејнери се во Кубернетес. Кластерот зафаќа неколку Јазли. Во исто време, тој е услужлив, стабилен и многу контролиран.

Извор: www.habr.com