Kubernetes в DomClick: как да спите спокойно, управлявайки клъстер от 1000 микроуслуги

Казвам се Виктор Ягофаров и разработвам платформата Kubernetes в DomClick като мениджър техническо развитие в екипа Ops (operation). Бих искал да говоря за структурата на нашите процеси Dev <-> Ops, характеристиките на работата на един от най-големите k8s клъстери в Русия, както и практиките DevOps/SRE, които нашият екип прилага.

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

В момента екипът на Ops има 15 души. Трима от тях отговарят за офиса, двама работят в различна часова зона и са на разположение, включително и през нощта. По този начин някой от Ops е винаги на монитора и е готов да реагира на инцидент с всякаква сложност. Нямаме нощни смени, което запазва психиката ни и дава възможност на всеки да спи достатъчно и да прекарва свободното си време не само пред компютъра.

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

Между другото, ние сме на лов. Изискванията към кандидатите са стандартни. За мен лично е важно човек да се вписва в екипа, да е неконфликтен, но и да знае как да отстоява своята гледна точка, да иска да се развива и да не се страхува да прави нещо ново, да предлага своите идеи. Също така са необходими умения за програмиране на скриптови езици, познания по основи на Linux и английски език. Английският е необходим просто, за да може човек при факап да гугълне решение на проблема за 10 секунди, а не за 10 минути. Сега е много трудно да се намерят специалисти с дълбоки познания по Linux: смешно е, но двама от трима кандидати не могат да отговорят на въпроса „Какво е средно натоварване? От какво е направен?“, а въпросът „Как да сглобя core dump от C програма“ се смята за нещо от света на супермените... или динозаврите. Трябва да се примирим с това, тъй като обикновено хората имат силно развити други компетенции, но ние ще преподаваме Linux. Отговорът на въпроса „защо един DevOps инженер трябва да знае всичко това в съвременния свят на облаци“ ще трябва да остане извън обхвата на статията, но с три думи: всичко това е необходимо.

Екипни инструменти

Екипът на Инструменти играе важна роля в автоматизацията. Основната им задача е да създават удобни графични и CLI инструменти за разработчиците. Например нашата вътрешна разработка Confer ви позволява буквално да внедрите приложение в Kubernetes само с няколко кликвания на мишката, да конфигурирате неговите ресурси, ключове от трезора и т.н. Преди това имаше Jenkins + Helm 2, но трябваше да разработя свой собствен инструмент, за да премахна копирането и поставянето и да внеса еднаквост в жизнения цикъл на софтуера.

Екипът на Ops не пише тръбопроводи за разработчици, но може да съветва относно всякакви проблеми в писането им (някои хора все още имат Helm 3).

DevOps

Що се отнася до DevOps, ние го виждаме така:

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

Областта на отговорност на Ops започва от момента, в който приложението бъде пуснато в производство, но отговорността на Dev не свършва дотук – ние правим едно и също нещо и сме в една и съща лодка.

Разработчиците съветват администраторите, ако имат нужда от помощ при написването на административна микроуслуга (например Go backend + HTML5), а администраторите съветват разработчиците относно всякакви инфраструктурни проблеми или проблеми, свързани с k8s.

Между другото, ние изобщо нямаме монолит, а само микроуслуги. Техният брой досега варира между 900 и 1000 в клъстера prod k8s, ако се измерва по брой внедрявания. Броят на шушулките варира между 1700 и 2000. В момента има около 2000 шушулки в производствения клъстер.

Не мога да дам точни числа, тъй като наблюдаваме ненужните микроуслуги и ги изрязваме полуавтоматично. K8s ни помага да следим ненужните обекти безполезен-оператор, което спестява много ресурси и средства.

Управление на ресурси

мониторинг

Добре структурираният и информативен мониторинг става крайъгълен камък в работата на голям клъстер. Все още не сме намерили универсално решение, което да покрива 100% от всички нужди за наблюдение, така че периодично създаваме различни персонализирани решения в тази среда.

• Zabbix. Добрият стар мониторинг, който е предназначен предимно за проследяване на цялостното състояние на инфраструктурата. Той ни казва кога даден възел умира по отношение на обработка, памет, дискове, мрежа и т.н. Нищо свръхестествено, но имаме и отделен DaemonSet от агенти, с помощта на който например наблюдаваме състоянието на DNS в клъстера: търсим глупави coredns pods, проверяваме наличието на външни хостове. Изглежда защо да се занимавате с това, но при големи обеми трафик този компонент е сериозна точка на повреда. Аз вече описано, как се борих с производителността на DNS в клъстер.
• Оператор Прометей. Набор от различни износители дава широк преглед на всички компоненти на клъстера. След това визуализираме всичко това на големи табла за управление в Grafana и използваме alertmanager за предупреждения.

Друг полезен инструмент за нас беше list-ingress. Написахме го, след като няколко пъти се сблъскахме със ситуация, при която един отбор припокрива входните пътища на друг отбор, което води до 50 пъти грешки. Сега, преди внедряване в производство, разработчиците проверяват дали никой няма да бъде засегнат и за моя екип това е добър инструмент за първоначална диагностика на проблеми с Ingresses. Странно е, че първоначално беше написано за администратори и изглеждаше доста „тромаво“, но след като екипите на разработчиците се влюбиха в инструмента, той се промени много и започна да не изглежда като „админ направи уеб лице за администратори. ” Скоро ще изоставим този инструмент и такива ситуации ще бъдат валидирани дори преди тръбопроводът да бъде пуснат.

Екипни ресурси в Cube

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

За да разберете кои екипи и в какви количества използват своите ресурсы (процесор, памет, локален SSD), ние разпределяме всяка команда собствена пространство от имена в “Cube” и ограничаване на максималните му възможности по отношение на процесор, памет и диск, като предварително са обсъдени нуждите на екипите. Съответно една команда като цяло няма да блокира целия клъстер за внедряване, разпределяйки хиляди ядра и терабайти памет. Достъпът до пространството на имената се предоставя чрез AD (ние използваме RBAC). Пространствата от имена и техните ограничения се добавят чрез заявка за изтегляне към хранилището на GIT и след това всичко автоматично се разпространява през конвейера Ansible.

Пример за разпределяне на ресурси към екип:

namespaces:

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

Заявки и ограничения

на кубчета" Поискайте е броят на гарантираните резервирани ресурси за шушулка (един или повече докер контейнери) в клъстер. Лимитът е негарантиран максимум. Често можете да видите на графиките как някой екип си е задал твърде много заявки за всичките си приложения и не може да разположи приложението в „Куба“, тъй като всички заявки под тяхното пространство от имена вече са „изразходвани“.

Правилният изход от тази ситуация е да се погледне действителното потребление на ресурси и да се сравни с исканото количество (Заявка).

На екранните снимки по-горе можете да видите, че „Исканите“ процесори са съпоставени с реалния брой нишки, а ограниченията могат да надхвърлят реалния брой нишки на процесора =)

Сега нека разгледаме подробно пространството от имена (избрах пространство от имена kube-system - пространството от имена на системата за компонентите на самия „Куб“) и да видим съотношението на действително използваното процесорно време и памет към исканото:

Очевидно е, че много повече памет и процесор са запазени за системни услуги, отколкото реално се използват. В случая на kube-системата това е оправдано: случи се, че nginx ingress controller или nodelocaldns в пика си удариха процесора и консумираха много RAM, така че тук такъв резерв е оправдан. Освен това не можем да разчитаме на графики за последните 3 часа: желателно е да виждаме исторически показатели за голям период от време.

Разработена е система от „препоръки“. Например, тук можете да видите за кои ресурси би било по-добре да повишите „лимитите“ (горната позволена лента), така че да не настъпи „дроселиране“: моментът, когато даден ресурс вече е изразходвал CPU или памет в определения отрязък от време и изчаква, докато бъде „размразен“:

А ето и шушулките, които трябва да обуздаят апетита им:

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

В резултат на това разработчиците разполагат с инструменти за наблюдение на техните пространства от имена в Cube и те могат сами да избират къде и по кое време ресурсите на кои приложения могат да бъдат „отрязани“ и на кои сървъри може да бъде предоставен целият процесор цяла нощ.

Методологии

Във фирмата, каквато е сега мода, ние се придържаме към DevOps- и SRE- практик Когато една компания има 1000 микроуслуги, около 350 разработчици и 15 администратори за цялата инфраструктура, вие трябва да сте „модерни“: зад всички тези „базули“ стои спешна необходимост от автоматизиране на всичко и всички, а администраторите не трябва да са пречка в процеси.

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

Използваме методологии като: RED, ИЗПОЛЗВАЙТЕ и Златни сигналикато ги комбинирате заедно. Опитваме се да минимизираме броя на таблата за управление, така че с един поглед да е ясно коя услуга в момента се влошава (например кодове за отговор за секунда, време за отговор с 99-ия процентил) и т.н. Веднага щом някои нови показатели станат необходими за общи табла за управление, ние незабавно ги чертаем и добавяме.

От месец не съм чертал графики. Това вероятно е добър знак: означава, че повечето от „желанията“ вече са реализирани. Случвало се е през седмицата поне веднъж на ден да чертая нова графика.

Полученият резултат е ценен, защото сега разработчиците доста рядко отиват при администраторите с въпроси „къде да гледам някакъв вид показател“.

Внедрение Сервизна мрежа е точно зад ъгъла и трябва да направи живота много по-лесен за всички, колегите от Tools вече са близо до прилагането на абстрактния „Istio на здрав човек“: жизненият цикъл на всяка HTTP(s) заявка ще бъде видим в мониторинга и винаги ще бъде възможно да се разбере „на какъв етап всичко се е счупило“ по време на взаимодействие между службите (и не само). Абонирайте се за новини от центъра DomClick. =)

Инфраструктурна поддръжка на Kubernetes

Исторически, ние използваме закърпената версия Kubespray — Възможна роля за внедряване, разширяване и актуализиране на Kubernetes. В даден момент поддръжката за не-kubeadm инсталации беше отрязана от основния клон и процесът на преминаване към kubeadm не беше предложен. В резултат на това компанията Southbridge направи свой собствен разклонител (с поддръжка на kubeadm и бързо решение за критични проблеми).

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

• предприеме Kubespray от Southbridge, проверете в нашата нишка, Merjim.
• Пускаме актуализацията на Стрес- „Куб“.
• Разгръщаме актуализацията един възел наведнъж (в Ansible това е „serial: 1“) в Дев- „Куб“.
• Ние актуализираме Ръгане в събота вечер един възел наведнъж.

Има планове за замяната му в бъдеще Kubespray за нещо по-бързо и отидете на kubeadm.

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

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

За CI/CD „Cubic“ и други инфраструктурни компоненти използваме отделен GIT сървър, Helm 3 (беше доста болезнен преход от Helm 2, но сме много доволни от опциите атомен), Дженкинс, Ansible и Docker. Ние обичаме разклонения на функции и внедряване в различни среди от едно хранилище.

Заключение

Това е, в общи линии, как изглежда процесът DevOps в DomClick от гледна точка на оперативен инженер. Статията се оказа по-малко техническа, отколкото очаквах: затова следете новините на DomClick на Habré: ще има повече „хардкор“ статии за Kubernetes и други.

Източник: www.habr.com