Моје име је Виктор Јагофаров и развијам Кубернетес платформу у ДомЦлицк-у као менаџер техничког развоја у Опс (оперативном) тиму. Желео бих да говорим о структури наших Дев <-> Опс процеса, карактеристикама рада једног од највећих к8с кластера у Русији, као и о ДевОпс/СРЕ праксама које наш тим примењује.
Опс Теам
Оперативни тим тренутно има 15 људи. Троје од њих је одговорно за канцеларију, двоје раде у другој временској зони и доступни су, укључујући и ноћу. Тако је неко из Опс увек на монитору и спреман да одговори на инцидент било које сложености. Немамо ноћне смене, што чува нашу психу и свима даје могућност да се довољно наспају и проведу слободно време не само за рачунаром.
Сви имају различите компетенције: мрежни људи, ДБА, стручњаци за ЕЛК стек, Кубернетес администратори/програмери, надгледање, виртуелизација, стручњаци за хардвер, итд. Једно све уједињује – свако може донекле заменити било кога од нас: на пример, увести нове чворове у к8с кластер, ажурирати ПостгреСКЛ, написати ЦИ/ЦД + Ансибле цевовод, аутоматизовати нешто у Питхон/Басх/Го, повезати хардвер на Центар за податке. Јаке компетенције у било којој области не спречавају вас да промените правац активности и почнете да се усавршавате у некој другој области. На пример, придружио сам се компанији као стручњак за ПостгреСКЛ, а сада су моја главна област одговорности Кубернетес кластери. У тиму је свака висина добродошла и осећај полуге је веома развијен.
Иначе, ми ловимо. Услови за кандидате су прилично стандардни. За мене лично је важно да се човек уклопи у тим, да је неконфликтан, али и да уме да брани своје гледиште, жели да се развија и не плаши се да уради нешто ново, нуди своје идеје. Такође, потребне су вештине програмирања у скрипт језицима, познавање основа Линук-а и енглеског језика. Енглески је потребан једноставно да би човек у случају факапа могао да изгугла решење проблема за 10 секунди, а не за 10 минута. Сада је веома тешко пронаћи стручњаке са дубоким познавањем Линука: смешно је, али два од три кандидата не могу да одговоре на питање „Шта је просечно оптерећење? Од чега је направљен?“, а питање „Како саставити думп језгра из Ц програма“ сматра се нечим из света надљуди... или диносауруса. Морамо да се помиримо са овим, пошто људи обично имају високо развијене друге компетенције, али ми ћемо предавати Линук. Одговор на питање „зашто ДевОпс инжењер треба да зна све ово у савременом свету облака” мораће да остане ван оквира чланка, али у три речи: све ово је потребно.
Тимски алати
Тим Тоолс игра значајну улогу у аутоматизацији. Њихов главни задатак је креирање практичних графичких и ЦЛИ алата за програмере. На пример, наша интерна развојна конференција вам омогућава да буквално уведете апликацију у Кубернетес са само неколико кликова мишем, конфигуришете њене ресурсе, кључеве из трезора итд. Раније је постојао Јенкинс + Хелм 2, али сам морао да развијем сопствени алат да елиминишем цопи-пасте и унесем униформност у животни циклус софтвера.
Оперативни тим не пише цевоводе за програмере, али може да саветује о свим питањима у њиховом писању (неки људи још увек имају Хелм 3).
ДевОпс
Што се тиче ДевОпс-а, видимо га овако:
Дев тимови пишу код, избацују га преко Цонфер то дев -> ка/стаге -> прод. Одговорност за обезбеђивање да се код не успорава и да не садржи грешке лежи на тимовима Дев и Опс. Дању, дежурни из Опс тима треба пре свега да одговори на инцидент својом апликацијом, а увече и ноћу дежурни администратор (Опс) треба да пробуди дежурног програмера ако зна за сигуран да проблем није у инфраструктури. Сви показатељи и упозорења у надгледању се појављују аутоматски или полуаутоматски.
Опсова област одговорности почиње од тренутка када је апликација пуштена у производњу, али Дев-ова одговорност се ту не завршава - радимо исту ствар и у истом смо чамцу.
Програмери саветују администраторе ако им је потребна помоћ при писању админ микросервиса (на пример, Го бацкенд + ХТМЛ5), а администратори саветују програмере о свим инфраструктурним проблемима или проблемима у вези са к8с.
Узгред, ми уопште немамо монолит, само микросервисе. Њихов број до сада варира између 900 и 1000 у групи прод к8с, ако се мери бројем распоређивања. Број махуна варира између 1700 и 2000. Тренутно постоји око 2000 махуна у производном кластеру.
Не могу да дам тачне бројке, пошто пратимо непотребне микросервисе и полуаутоматски их исечемо. К8с нам помаже да пратимо непотребне ентитете , што штеди много средстава и новца.
Управљање ресурсима
Праћење
Добро структуиран и информативан мониторинг постаје камен темељац у раду великог кластера. Још увек нисмо пронашли универзално решење које би покрило 100% свих потреба за праћењем, тако да периодично креирамо различита прилагођена решења у овом окружењу.
- Заббик. Стари добри мониторинг, који је намењен првенствено праћењу укупног стања инфраструктуре. Говори нам када чвор умре у смислу обраде, меморије, дискова, мреже и тако даље. Ништа натприродно, али имамо и посебан ДаемонСет агената, уз помоћ којих, на пример, пратимо стање ДНС-а у кластеру: тражимо глупе цореднс подове, проверавамо доступност спољних хостова. Чини се да зашто се трудити са овим, али са великим обимом саобраћаја ова компонента је озбиљна тачка квара. Раније сам већ , како сам се мучио са перформансама ДНС-а у кластеру.
- Прометхеус Оператор. Скуп различитих извозника даје велики преглед свих компоненти кластера. Затим све ово визуелизујемо на великим контролним таблама у Графани и користимо алертманагер за упозорења.
Још једно корисно средство за нас је било . Написали смо га након што смо неколико пута наишли на ситуацију у којој је један тим преклапао улазне путање другог тима, што је резултирало 50к грешака. Сада пре постављања у продукцију, програмери проверавају да нико неће бити погођен, а за мој тим ово је добар алат за почетну дијагнозу проблема са Ингрессес-има. Смешно је што је у почетку био написан за администраторе и изгледао је прилично „неспретно“, али након што су се тимови за развојне програмере заљубили у алат, много се променио и почео да не изгледа као „админ је направио веб лице за администраторе. ” Ускоро ћемо напустити овај алат и такве ситуације ће бити потврђене чак и пре него што се цевовод покрене.
Тимски ресурси у коцки
Пре него што пређемо на примере, вреди објаснити како додељујемо ресурсе за микросервис.
Да би разумели који тимови и у којим количинама користе своје ресурсы (процесор, меморија, локални ССД), свакој команди додељујемо своју простор имена у „Коцки” и ограничити њене максималне могућности у погледу процесора, меморије и диска, претходно разговарајући о потребама тимова. Сходно томе, једна команда, генерално, неће блокирати цео кластер за примену, додељујући хиљаде језгара и терабајта меморије. Приступ именском простору се одобрава преко АД-а (користимо РБАЦ). Простори имена и њихова ограничења се додају преко захтева за повлачење у ГИТ спремиште, а затим се све аутоматски преноси кроз Ансибле цевовод.
Пример доделе ресурса тиму:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Захтеви и ограничења
коцкасто" Рекуест је број гарантованих резервисаних ресурса за махуна (један или више доцкер контејнера) у кластеру. Лимит је незагарантовани максимум. Често можете видети на графиконима како је неки тим себи поставио превише захтева за све своје апликације и не може да примени апликацију на „Коцку“, пошто су сви захтеви у њиховом именском простору већ „потрошени“.
Исправан излаз из ове ситуације је да се погледа стварна потрошња ресурса и упореди са траженим износом (Захтев).
На горњим снимцима екрана можете видети да се „Захтевани“ процесори подударају са стварним бројем нити, а ограничења могу да премаше стварни број ЦПУ нити =)
Сада погледајмо детаљније неки простор имена (ја сам изабрао именски простор кубе-систем - системски именски простор за компоненте саме „Коцке“) и видимо однос стварно коришћеног процесорског времена и меморије према траженом:
Очигледно је да је много више меморије и ЦПУ-а резервисано за системске услуге него што се стварно користи. У случају кубе-система, ово је оправдано: дешавало се да нгинк ингресс контролер или ноделоцалднс на свом врхунцу ударе у ЦПУ и потроше много РАМ-а, па је овде таква резерва оправдана. Поред тога, не можемо се ослонити на графиконе за последња 3 сата: пожељно је видети историјске метрике током дужег временског периода.
Развијен је систем „препорука“. На пример, овде можете видети које ресурсе би било боље да подигнете „ограничења“ (горња дозвољена трака) како не би дошло до „пригушења“: тренутак када је ресурс већ потрошио ЦПУ или меморију у додељеном временском одсеку и чека да се „одмрзне“:
А ево и махуна које би требало да обуздају њихов апетит:
О томе пригушивање + праћење ресурса, можете написати више од једног чланка, па постављајте питања у коментарима. У неколико речи, могу рећи да је задатак аутоматизације оваквих метрика веома тежак и захтева много времена и балансирања са „прозорским“ функцијама и „ЦТЕ“ Прометхеус / ВицториаМетрицс (ови термини су под наводницима, пошто је скоро ништа слично овоме у ПромКЛ-у, и морате да поделите страшне упите на неколико екрана текста и да их оптимизујете).
Као резултат тога, програмери имају алате за надгледање својих именских простора у Цубе-у, и они су у могућности да сами бирају где и у које време које апликације могу да „исеку“ своје ресурсе и којим серверима се може дати цео ЦПУ током целе ноћи.
Методологије
У друштву какво је сада модеран, придржавамо се ДевОпс- и СРЕ-практичар Када компанија има 1000 микросервиса, око 350 програмера и 15 администратора за целокупну инфраструктуру, морате бити „модерни”: иза свих ових „базвора” постоји хитна потреба да се аутоматизује све и свакога, а администратори не би требало да буду уско грло у процесима.
Као Опс, ми пружамо различите метрике и контролне табле за програмере у вези са стопама одговора услуге и грешкама.
Користимо методологије као што су: , и њиховим комбиновањем. Трудимо се да минимизирамо број контролних табли тако да на први поглед буде јасно која услуга тренутно деградира (на пример, кодови одговора у секунди, време одговора за 99. перцентил) и тако даље. Чим неке нове метрике постану неопходне за опште контролне табле, одмах их цртамо и додајемо.
Нисам цртао графиконе месец дана. Ово је вероватно добар знак: то значи да је већина „жеља“ већ остварена. Дешавало се да током недеље бар једном дневно нацртам неки нови графикон.
Добијени резултат је вредан јер сада програмери прилично ретко иду код администратора са питањима „где да погледају неку врсту метрике“.
Увод Сервице Месх је одмах иза угла и требало би да свима олакша живот, колеге из Тоолс-а су већ близу имплементације апстрактног „Истио оф а здраве особе“: животни циклус сваког ХТТП(с) захтева ће бити видљив у праћењу, и увек ће бити могуће разумети „у којој фази се све покварило“ током интеракције између служби (и не само). Претплатите се на вести из ДомЦлицк чворишта. =)
Подршка за Кубернетес инфраструктуру
Историјски гледано, користимо закрпљену верзију Кубеспраи — Могућа улога за примену, проширење и ажурирање Кубернетеса. У неком тренутку, подршка за не-кубеадм инсталације је уклоњена из главне гране, а процес преласка на кубеадм није предложен. Као резултат тога, компанија Соутхбридге је направила сопствену виљушку (са подршком за кубеадм и брзим решењем за критичне проблеме).
Процес ажурирања свих к8с кластера изгледа овако:
- Хајде да га узмемо Кубеспраи са Соутхбридгеа, провери у нашој теми, Мерјим.
- Уводимо ажурирање за Стрес- „Коцка“.
- Уводимо ажурирање један по један чвор (у Ансибле-у је ово „серијски: 1“). дев- „Коцка“.
- Ми ажурирамо Прод у суботу увече један по један чвор.
У будућности се планира његова замена Кубеспраи за нешто брже и иди у кубеадм.
Укупно имамо три „коцке“: Стресс, Дев и Прод. Планирамо да покренемо још једну (хот стандби) Прод-“Цубе” у другом дата центру. Стрес и дев живе у „виртуелним машинама“ (оВирт за Стресс и ВМВаре облак за Дев). Прод- „Коцка“ живи на „голом металу“: ово су идентични чворови са 32 ЦПУ нити, 64-128 ГБ меморије и 300 ГБ ССД РАИД 10 - укупно их је 50. Три „танка“ чвора посвећена су „мајсторима“ Прод- „Куба“: 16 ГБ меморије, 12 нити за процесор.
За продају радије користимо „голи метал“ и избегавамо непотребне слојеве као што су ОпенСтацк: не требају нам „бучни суседи“ и ЦПУ краде време. А сложеност администрације се приближно удвостручује у случају унутрашњег ОпенСтацк-а.
За ЦИ/ЦД “Цубиц” и друге инфраструктурне компоненте користимо посебан ГИТ сервер, Хелм 3 (био је то прилично болан прелаз са Хелм 2, али смо веома задовољни опцијама атомски), Јенкинс, Ансибле и Доцкер. Волимо гране функција и примену у различитим окружењима из једног спремишта.
Закључак
Овако, уопштено говорећи, изгледа како ДевОпс процес изгледа у ДомЦлицк-у из перспективе оперативног инжењера. Испоставило се да је чланак мање технички него што сам очекивао: стога пратите вести ДомЦлицк-а на Хабре-у: биће више „тврдих“ чланака о Кубернетесу и још много тога.
Извор: ввв.хабр.цом