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

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

Екипът Ops

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

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

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

Екипът Tools

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

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

DevOps

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

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

Отговорността на Ops започва от момента на пускане на приложението в продукция, но отговорността на Dev също не приключва - работим заедно и сме в един и същи кораб.

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

Между другото, нямаме монолит, само микросервиси. Броят им в момента колебае между 900 и 1000 в продуктивния k8s клъстер, ако се измерва по количество deployments. Броят на подовете колебае между 1700 и 2000. В продуктивния клъстер в момента има около 2000 пода.

Не мога да дам точни числа, тъй като следим ненужните микросервиси и ги премахваме в полуавтоматичен режим. Следенето на ненужните структури в k8s ни помага useless-operator, което значително спестява ресурси и средства.

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

Мониторинг

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

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

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

Ресурси на екипите в "Куба"

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

За да разберем кои екипи и в какви количества използват своите ресурси (процесор, памет, локален SSD), ние разпределяме на всеки екип своя namespace в "Куба" и ограничаваме максималните му възможности по процесор, памет и диск, предварително обсъждайки нуждите на екипите. Съответно, един екип, в общия случай, не може да блокира целия кластер за внедряване, като задели хиляди ядра и терабайти памет. Достъпите в namespace се дават чрез AD (използваме RBAC). Namespace-ите и техните лимити се добавят чрез пул-реквест в GIT репозитория, а след това всичко автоматично се разгръща чрез Ansible пайплайн.

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

namespaces:

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

Реквести и лимити

В "Куба" Request — това е количеството гарантирано резервирани ресурси за pod (един или повече Docker контейнери) в кластерa. Limit — това е негарантиран максимум. Често може да се види на графиките, как някой екип е задължил себе си с твърде много реквести за всички свои приложения и не може да внедри приложение в "Куб", тъй като всички request’и в техния namespace вече са „изразходвани“.

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

На скрийншотовете по-горе се вижда, че "запитаните" (Requested) CPU се приближават до реалното количество потоци, а Limits могат да надвишават реалното количество потоци на централните процесори =)

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

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

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

А ето и подовете, на които следва да се ограничат ресурсите:

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

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

Методологии

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

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

Използваме такива методологии, като: RED, USE и Златни сигнали, комбинирайки ги заедно. Стремим се да минимизираме броя на таблата, така че от един поглед да е ясно кой сервис в момента деградира (например, кодовете на отговори в секунда, времето за отговор в 99-ия процентил) и така нататък. Веднага щом се появят нови метрики за общите табла, ние веднага ги проектираме и добавяме.

Не съм рисувал графики от месец. Вероятно, това е добър знак: значи повечето "желания" вече са реализирани. Имало е случаи, когато за седмица рисувам нова графика поне веднъж на ден.

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

Внедряване Service Mesh не е далеч и трябва да облекчи живота на всички, колегите от Tools вече са близки до внедрението на абстрактния "Istio на здравия човек": жизненият цикъл на всяко HTTP(s) искане ще бъде видим в мониторинга, и винаги ще може да се разбере "на кой етап всичко е счупено" при междусервизното (и не само) взаимодействие. Абонирайте се за новините от хаба на компания ДомКлик. =)

Поддръжка на Kubernetes инфраструктура

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

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

• Вземаме Kubespray от Southbridge, съпоставяме с нашата клонка, мерджим.
• Пускаме обновлението в Stress-"Куб".
• Пускаме обновлението по една нода (в Ansible това е "serial: 1") в Dev-"Куб".
• Обновяваме Prod в събота вечер по една нода.

В бъдеще имаме планове да заменим Kubespray с нещо по-бързо и да преминем на kubeadm.

Общо имаме три "Куба": Stress, Dev и Prod. Планираме да стартираме още един (hot standby) Prod-"Куб" във втория ЦОД. Stress и Dev живеят в "виртуалки" (oVirt за Stress и VMWare cloud за Dev). Prod-"Куб" живее на "голо желязо" (bare metal): това са еднакви ноди с 32 CPU нишки, 64-128 Гб памет и 300 Гб SSD RAID 10 — общо 50 на брой. Три "тънки" ноди са отделени за "мастера" Prod-"Куба": 16 Гб памет, 12 CPU нишки.

За производството предпочитаме да използваме "голо желязо" и избягваме излишни слоеве като OpenStack: не ни трябват "шумни съседи" и CPU steal timeСложността на администрирането нараства почти двойно в случай на in-house OpenStack.

За CI/CD „Кубовите“ и други инфраструктурни компоненти използваме отделен GIT-сървър, Helm 3 (прехвърлянето от Helm 2 беше доста болезнено, но сме много доволни от опцията atomic), Jenkins, Ansible и Docker. Обичаме feature-bранчове и деплой в различни среди от едно хранилище.

Заключение

Така, в общи линии, в компанията ДомКлик изглежда процесът DevOps от страна на инженера по експлоатация. Статията се получи по-малко техническа, отколкото очаквах: затова, следете новините на ДомКлик в Хабра: ще има по-"хардкорни" статии за Kubernetes и не само.

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