Kubernetes на DomClick: како да спиете мирно управувајќи со кластер од 1000 микроуслуги

Јас се викам Виктор Јагофаров и ја развивам платформата Kubernetes во DomClick како менаџер за технички развој во тимот на Ops (операција). Би сакал да зборувам за структурата на нашите процеси Dev <-> Ops, карактеристиките на работењето на еден од најголемите k8s кластери во Русија, како и за практиките DevOps/SRE што ги применува нашиот тим.

Оперативен тим

Тимот на Ops моментално има 15 луѓе. Тројца од нив се одговорни за канцеларијата, двајца работат во различна временска зона и се достапни, вклучително и ноќе. Така, некој од Ops е секогаш на мониторот и е подготвен да одговори на инцидент од секаква сложеност. Немаме ноќни смени, што ја зачувува нашата психа и им дава можност на сите да спијат доволно и да го поминуваат слободното време не само на компјутер.

Секој има различни компетенции: вмрежувачи, DBA, специјалисти за ELK stack, администратори/програмери на Kubernetes, мониторинг, виртуелизација, специјалисти за хардвер итн. Едно ги обединува сите - секој може да замени кој било од нас до одреден степен: на пример, воведете нови јазли во кластерот k8s, ажурирајте го PostgreSQL, напишете CI/CD + Ansible цевка, автоматизирајте нешто во Python/Bash/Go, поврзете хардвер со На Центарот за податоци. Силните компетенции во која било област не ве спречуваат да го промените правецот на вашата активност и да почнете да се подобрувате во некоја друга област. На пример, се приклучив на компанија како специјалист PostgreSQL, а сега мојата главна област на одговорност се кластерите на Kubernetes. Во тимот, секоја висина е добредојдена и чувството за потпора е многу развиено.

Патем, ловиме. Барањата за кандидатите се сосема стандардни. За мене лично е важно човек да се вклопи во тимот, да е неконфликтен, но и да знае да го брани своето гледиште, да сака да се развива и да не се плаши да направи нешто ново, да ги нуди своите идеи. Исто така, потребни се програмски вештини на јазици за скриптирање, познавање на основите на Linux и англискиот јазик. Англискиот јазик е потребен едноставно за да може човек во случај на факап да гугла решение за проблемот за 10 секунди, а не за 10 минути. Сега е многу тешко да се најдат специјалисти со длабоко познавање на Linux: смешно е, но двајца од тројца кандидати не можат да одговорат на прашањето „Што е Load Average? Од што е направен?“, а прашањето „Како да се состави core dump од програма C“ се смета за нешто од светот на супермените... или диносаурусите. Мораме да го трпиме ова, бидејќи обично луѓето имаат високо развиени други компетенции, но ние ќе го учиме Linux. Одговорот на прашањето „зошто инженерот DevOps треба да го знае сето ова во современиот свет на облаците“ ќе мора да биде оставен надвор од опсегот на статијата, но со три збора: сето ова е неопходно.

Тимски алатки

Тимот на Tools игра значајна улога во автоматизацијата. Нивната главна задача е да создадат пригодни графички и CLI алатки за програмерите. На пример, нашиот внатрешен развој Confer ви овозможува буквално да отворите апликација на Kubernetes со само неколку кликања на глувчето, да ги конфигурирате нејзините ресурси, клучеви од трезорот итн. Претходно, имаше Jenkins + Helm 2, но морав да развијам сопствена алатка за да го елиминирам copy-paste и да донесам униформност во животниот циклус на софтверот.

Тимот на Ops не пишува цевководи за програмери, но може да советува за какви било прашања во нивното пишување (некои луѓе сè уште имаат Helm 3).

DevOps

Што се однесува до DevOps, го гледаме вака:

Тимовите за развивачи пишуваат код, го пренесуваат преку Confer to dev -> qa/stage -> prod. Одговорноста за обезбедување дека кодот не забавува и не содржи грешки е на тимовите Dev и Ops. Во текот на денот, дежурниот од тимот на Ops треба најпрво да одговори на инцидент со неговата апликација, а навечер и ноќе дежурниот администратор (ОП) треба да го разбуди дежурниот програмер доколку знае за сигурни дека проблемот не е во инфраструктурата. Сите метрики и предупредувања во следењето се појавуваат автоматски или полуавтоматски.

Областа на одговорност на Ops започнува од моментот кога апликацијата ќе биде пуштена во производство, но одговорноста на Dev не завршува тука - ние го правиме истото и сме во истиот брод.

Програмерите ги советуваат администраторите доколку им треба помош за пишување административна микросервис (на пример, Go backend + HTML5), а администраторите ги советуваат програмерите за какви било инфраструктурни проблеми или проблеми поврзани со k8s.

Патем, ние воопшто немаме монолит, само микроуслуги. Нивниот број досега флуктуира помеѓу 900 и 1000 во кластерот prod k8s, ако се мери со број распоредувања. Бројот на мешунките варира помеѓу 1700 и 2000. Моментално има околу 2000 мешунки во кластерот на производи.

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

Менаџирање со ресурси

Мониторинг

Добро структурираниот и информативен мониторинг станува камен-темелник во работењето на голем кластер. Сè уште не најдовме универзално решение кое би покривало 100% од сите потреби за следење, па затоа периодично создаваме различни сопствени решенија во оваа средина.

• Zabbix. Добар стар мониторинг, кој првенствено е наменет за следење на целокупната состојба на инфраструктурата. Ни кажува кога некој јазол умира во однос на обработката, меморијата, дисковите, мрежата итн. Ништо натприродно, но имаме и посебен DaemonSet на агенти, со чија помош, на пример, ја следиме состојбата на DNS во кластерот: бараме глупави coredns pods, ја проверуваме достапноста на надворешни хостови. Се чини дека зошто да се мачиме со ова, но со големиот обем на сообраќај оваа компонента е сериозна точка на неуспех. Претходно јас веќе опишан, како се борев со перформансите на DNS во кластер.
• Оператор Прометеј. Збир на различни извозници дава голем преглед на сите компоненти на кластерот. Следно, сето ова го визуелизираме на големи контролни табли во Графана и користиме alertmanager за предупредувања.

Друга корисна алатка за нас беше список-влегување. Го напишавме откако неколку пати наидовме на ситуација кога еден тим ги преклопуваше патеките за влез на друг тим, што резултираше со 50x грешки. Сега, пред да се распоредат во производство, програмерите проверуваат дека никој нема да биде засегнат, а за мојот тим ова е добра алатка за првична дијагноза на проблеми со Ingresses. Смешно е што на почетокот беше напишана за администратори и изгледаше прилично „несмасно“, но откако тимовите на развивачи се заљубија во алатката, таа многу се промени и почна да не изгледа како „администратор направи веб-фаца за администратори. ” Наскоро ќе ја напуштиме оваа алатка и таквите ситуации ќе бидат потврдени дури и пред да се пушти нафтоводот.

Тимски ресурси во коцката

Пред да влеземе во примерите, вреди да се објасни како ги распределуваме ресурсите микроуслуги.

Да се ​​разбере кои тимови и во какви количини ги користат нивните ресурсы (процесор, меморија, локален SSD), секоја команда ја доделуваме своја именски простор во „Коцка“ и ги ограничи неговите максимални можности во однос на процесорот, меморијата и дискот, откако претходно разговаравме за потребите на тимовите. Според тоа, една команда, генерално, нема да го блокира целиот кластер за распоредување, алоцирајќи илјадници јадра и терабајти меморија. Пристапот до именскиот простор е даден преку AD (ние користиме RBAC). Просторите со имиња и нивните граници се додаваат преку барање за повлекување во складиштето на GIT, а потоа сè автоматски се пренесува преку гасоводот Ansible.

Пример за распределба на ресурси на тим:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

Барања и ограничувања

коцки" Побара е бројот на загарантирани резервирани ресурси за pod (еден или повеќе докер контејнери) во кластер. Лимитот е негарантиран максимум. Честопати можете да видите на графиконите како некој тим си поставил премногу барања за сите свои апликации и не може да ја распореди апликацијата на „Коцка“, бидејќи сите барања под нивниот именски простор се веќе „потрошени“.

Точниот излез од оваа ситуација е да се погледне вистинската потрошувачка на ресурси и да се спореди со бараниот износ (Барање).

На сликите од екранот погоре можете да видите дека „Бараните“ процесори се совпаѓаат со реалниот број на нишки, а Ограничувањата може да го надминат реалниот број на нишки на процесорот =)

Сега, ајде да погледнеме детално одреден простор за имиња (избрав именски простор kube-system - системскиот именски простор за компонентите на самиот „Cube“) и да го видиме односот на реално искористеното време на процесорот и меморијата со бараното:

Очигледно е дека многу повеќе меморија и процесор се резервирани за системските услуги отколку што всушност се користи. Во случајот со кубе-системот, ова е оправдано: се случи контролорот за влез на nginx или nodelocaldns на својот врв да го погодат процесорот и да потрошат многу RAM меморија, па овде таквата резерва е оправдана. Покрај тоа, не можеме да се потпреме на графиконите во последните 3 часа: пожелно е да се видат историските метрики во голем временски период.

Беше развиен систем на „препораки“. На пример, овде можете да видите кои ресурси би било подобро да ги подигнат „лимитите“ (горната дозволена лента) за да не дојде до „загушување“: моментот кога ресурсот веќе го потрошил процесорот или меморијата во доделениот временски дел и чека додека не се „одмрзне“:

А еве ги мешунките кои треба да им го скратат апетитот:

на пригушување + следење на ресурсите, можете да напишете повеќе од една статија, затоа поставувајте прашања во коментарите. Со неколку зборови, можам да кажам дека задачата за автоматизирање на таквите метрики е многу тешка и бара многу време и балансирање со функциите „прозорец“ и „CTE“ Prometheus / VictoriaMetrics (овие термини се во наводници, бидејќи има речиси ништо вакво во PromQL, и мора да поделите застрашувачки прашања на неколку екрани со текст и да ги оптимизирате).

Како резултат на тоа, програмерите имаат алатки за следење на нивните именски простори во Cube, и тие можат сами да изберат каде и во кое време на кои апликации може да им се „сечат“ ресурсите и на кои сервери може да им се даде целиот процесор цела ноќ.

Методологии

Во компанијата како што е сега модерен, ние се придржуваме до DevOps- и СРЕ- практичар Кога една компанија има 1000 микросервиси, околу 350 програмери и 15 администратори за целата инфраструктура, мора да бидеш „модерен“: зад сите овие „базбори“ има итна потреба да се автоматизира сè и секого, а администраторите не треба да бидат тесно грло. во процесите.

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

Ние користиме методологии како што се: Црвен, УПОТРЕБА и Златни сигналисо нивно комбинирање. Се обидуваме да го минимизираме бројот на контролните табли, така што на прв поглед ќе биде јасно која услуга моментално е понижувачка (на пример, кодови за одговор во секунда, време на одговор до 99-от перцентил) и така натаму. Штом некои нови метрики станат неопходни за општите контролни табли, веднаш ги цртаме и додаваме.

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

Резултатот е вреден затоа што сега програмерите ретко одат кај администраторите со прашања „каде да се погледне некој вид на метрика“.

Имплементација Сервисна мрежа е веднаш зад аголот и треба да им го олесни животот на сите, колегите од Tools веќе се блиску до имплементација на апстрактниот „Истио на здрава личност“: животниот циклус на секое барање HTTP(и) ќе биде видлив при мониторингот и секогаш ќе може да се разбере „во која фаза сè пукна“ за време на меѓусервисната (и не само) интеракцијата. Претплатете се на вести од центарот DomClick. =)

Поддршка на инфраструктурата на Кубернетес

Историски гледано, ние ја користиме закрпената верзија Кубеспреј - Одговорна улога за распоредување, проширување и ажурирање на Kubernetes. Во одреден момент, поддршката за не-kubeadm инсталации беше прекината од главната гранка, а процесот на префрлување на kubeadm не беше предложен. Како резултат на тоа, компанијата Southbridge направи сопствена вилушка (со поддршка за kubeadm и брзо решение за критичните проблеми).

Процесот за ажурирање на сите кластери k8s изгледа вака:

• Ајде да го земеме Кубеспреј од Саутбриџ, провери со нашата нишка, Мерџим.
• Го објавуваме ажурирањето на Стрес- „Коцка“.
• Ние го објавуваме ажурирањето еден по еден јазол (во Ansible ова е „сериски: 1“) во Dev- „Коцка“.
• Ние ажурираме Prod во сабота навечер еден по еден јазол.

Во иднина се планира негова замена Кубеспреј за нешто побрзо и оди на kubeadm.

Вкупно имаме три „Коцки“: Стрес, Дев и Прод. Планираме да лансираме уште еден (топло мирување) Прод-„Коцка“ во вториот центар за податоци. Стрес и Dev живеат во „виртуелни машини“ (oVirt за стрес и VMWare облак за Dev). Prod- „Cube“ живее на „гол метал“: ова се идентични јазли со 32 нишки на процесорот, 64-128 GB меморија и 300 GB SSD RAID 10 - вкупно има 50 од нив. Три „тенки“ јазли се посветени на „господарите“ Prod- „Куба“: 16 GB меморија, 12 нишки на процесорот.

За продажба, претпочитаме да користиме „гол метал“ и да избегнуваме непотребни слоеви како OpenStack: не ни требаат „бучни соседи“ и процесорот украде време. И комплексноста на администрацијата приближно се удвојува во случајот со внатрешен OpenStack.

За CI/CD „Cubic“ и други инфраструктурни компоненти користиме посебен GIT сервер, Helm 3 (тоа беше прилично болна транзиција од Helm 2, но ние сме многу задоволни со опциите атомски), Џенкинс, Ансибл и Докер. Сакаме гранки на функции и распоредување во различни средини од едно складиште.

Заклучок

Општо земено, вака изгледа процесот DevOps на DomClick од перспектива на оперативен инженер. Статијата се покажа како помалку техничка отколку што очекував: затоа, следете ги вестите на DomClick на Хабре: ќе има повеќе „тврдокорни“ написи за Kubernetes и многу повеќе.

Извор: www.habr.com