[DevOps, Kubernetes] Kubernetes в ДомКлик: как спать спокойно, управляя кластером на 1000 микросервисов

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
07-Авг-2020 14:39

Цитировать

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

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

Компетенции у всех разные: сетевики, DBA, специалисты по стеку ELK, Kubernetes-админы/разработчики, специалисты по мониторингу, виртуализации, железу и т.д. Объединяет всех одно — каждый может заменить в какой-то степени любого из нас: например, ввести новые ноды в кластер k8s, обновить PostgreSQL, написать pipeline CI/CD + Ansible, автоматизировать что-нибудь на Python/Bash/Go, подключить железку в ЦОД. Сильные компетенции в какой-либо области не мешают сменить направление деятельности и начать прокачиваться в какой-нибудь другой области. Например, я устраивался в компанию как специалист по PostgreSQL, а сейчас моя главная зона ответственности — кластеры Kubernetes. В команде любой рост только приветствуется и очень развито чувство плеча.
Кстати, мы хантим. Требования к кандидатам довольно стандартные. Лично для меня важно, чтобы человек вписывался в коллектив, был неконфликтным, но также умел отстаивать свою точку зрения, желал развиваться и не боялся делать что-то новое, предлагал свои идеи. Также, обязательны навыки программирования на скриптовых языках, знание основ Linux и английского языка. Английский нужен просто для того, чтобы человек в случае факапа мог загуглить решение проблемы за 10 секунд, а не за 10 минут. Со специалистами с глубоким знанием Linux сейчас очень сложно: смешно, но два кандидата из трех не могут ответить на вопрос «Что такое Load Average? Из чего он складывается?», а вопрос «Как собрать core dump из сишной программы» считают чем-то из мира сверхлюдей… или динозавров. С этим приходится мириться, так как обычно у людей сильно развиты другие компетенции, а «линуксу» мы научим. Ответ на вопрос «зачем это всё нужно знать 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 backend + HTML5), а админы консультируют разработчиков по любым инфраструктурным вопросам, или вопросам, связанным с k8s.
Кстати, у нас вообще нет монолита, только микросервисы. Их количество пока что колеблется между 900 и 1000 в prod k8s-кластере, если измерять по количеству deployments. Количество подов колеблется между 1700 и 2000. Подов в prod-кластере сейчас около 2000.
Точные числа назвать не могу, так как мы следим за ненужными микросервисами и выпиливаем их в полуавтоматическом режиме. Следить за ненужными сущностями в k8s нам помогает useless-operator, что здорово экономит ресурсы и деньги.
Управление ресурсами
Мониторинг
Краеугольным камнем в эксплуатации большого кластера становится грамотно выстроенный и информативный мониторинг. Мы пока не нашли универсального решения, которое покрыло бы 100 % всех «хотелок» по мониторингу, поэтому периодически клепаем разные кастомные решения в этой среде.

Zabbix. Старый добрый мониторинг, который предназначен, в первую очередь, для отслеживания общего состояния инфраструктуры. Он говорит нам, когда нода умирает по процу, памяти, дискам, сети и так далее. Ничего сверхъестественного, но также у нас есть отдельный DaemonSet из агентов, с помощью которых, например, мы мониторим состояние DNS в кластере: ищем тупящие поды coredns, проверяем доступность внешних хостов. Казалось бы, зачем ради этого заморачиваться, но на больших объемах трафика этот компонент является серьезной точкой отказа. Ранее я уже описывал, как боролся с производительностью DNS в кластере.
Prometheus Operator. Набор различных экспортеров даёт большой обзор всех компонентов кластера. Далее визуализируем всё это на больших дашбордах в Grafana, а для оповещений используем alertmanager.

Еще одним полезным инструментом для нас стал list-ingress. Мы написали его после того, как несколько раз столкнулись с ситуацией, когда одна команда перекрывает своими путями Ingress другой команды, из-за чего возникали ошибки 50x. Сейчас перед деплоем на прод разработчики проверяют, что никого не заденут, а для моей команды это хороший инструмент для первичной диагностики проблем с Ingress'ами. Забавно, что сначала его написали для админов и выглядел он довольно «топорно», но после того, как инструмент полюбился dev-командам, он сильно преобразился и стал выглядеть не как «админ сделал веб-морду для админов». Скоро мы откажемся от этого инструмента и подобные ситуации будут валидироваться еще до выкатки пайплайна.
Ресурсы команд в «Кубе»
Прежде чем приступить к примерам, стоит объяснить, как у нас работает выделение ресурсов для микросервисов.
Чтобы понимать, какие команды и в каких количествах используют свои ресурсы (процессор, память, локальный 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 (один или более докер-контейнеров) в кластере. Limit — это негарантированный максимум. Часто можно увидеть на графиках, как какая-то команда выставила себе слишком много реквестов для всех своих приложений и не может задеплоить приложение в «Куб», так как под их namespace все request'ы уже «потрачены».
Правильный выход из такой ситуации: смотреть реальное потребление ресурсов и сравнивать с запрошенным количеством (Request).

На скриншотах выше видно, что «запрошенные» (Requested) CPU подбираются к реальному количеству потоков, а Limits могут превышать реальное количество потоков центральных процессоров =)
Теперь подробно разберём какой-нибудь namespace (я выбрал namespace kube-system — системный namespace для компонентов самого «Куба») и посмотрим соотношение реально использованного процессорного времени и памяти к запрошенному:

Очевидно, что памяти и ЦПУ зарезервировано под системные службы намного больше, чем используется реально. В случае с kube-system это оправдано: бывало, что nginx ingress controller или nodelocaldns в пике упирались в CPU и отъедали очень много RAM, поэтому здесь такой запас оправдан. К тому же, мы не можем полагаться на графики за последние 3 часа: желательно видеть исторические метрики за большой период времени.
Была разработана система «рекомендаций». Например, здесь можно увидеть, каким ресурсам лучше бы поднять «лимиты» (верхняя разрешенная планка), чтобы не происходило «троттлинга» (throttling): момента, когда под уже потратил CPU или память за отведенный ему квант времени и находится в ожидании, пока его «разморозят»:

А вот поды, которым следовало бы умерить аппетиты:

Про троттлинг + мониторинг ресурсов можно написать не одну статью, поэтому задавайте вопросы в комментариях. В нескольких словах могу сказать, что задача автоматизации подобных метрик весьма непростая и требует много времени и эквилибристики с «оконными» функциями и «CTE» Prometheus / VictoriaMetrics (эти термины взяты в кавычки, так как в PromQL почти что нет ничего подобного, и приходится городить страшные запросы на несколько экранов текста и заниматься их оптимизацией).
В итоге, у разработчиков есть инструменты для мониторинга своих namespaces в «Кубе», и они способны сами выбирать, где и в какое время у каких приложений можно «подрезать» ресурсы, а каким подам можно на всю ночь отдать весь CPU.
Методологии
В компании, как сейчас модно, мы придерживаемся DevOps- и SRE-практик. Когда в компании 1000 микросервисов, около 350 разработчиков и 15 админов на всю инфраструктуру, приходится «быть модным»: за всеми этими «базвордами» скрывается острая необходимость в автоматизации всего и вся, а админы не должны быть бутылочным горлышком в процессах.
Как Ops, мы предоставляем различные метрики и дашборды для разработчиков, связанные со скоростью ответа сервисов и их ошибками.
Мы используем такие методологии, как: RED, USE и Golden Signals, комбинируя их вместе. Стараемся минимизировать количество дашбордов так, чтобы с одного взгляда было понятно, какой сервис сейчас деградирует (например, коды ответов в секунду, время ответа по 99-перцентилю), и так далее. Как только становятся нужны какие-то новые метрики для общих дашбордов, мы тут же их рисуем и добавляем.
Я не рисовал графики уже месяц. Наверное, это хороший знак: значит большинство «хотелок» уже реализованы. Бывало, что за неделю я хотя бы раз в день рисовал какой-нибудь новый график.

Получившийся результат ценен тем, что теперь разрабы довольно редко ходят к админам с вопросами «где посмотреть какую-то метрику».
Внедрение Service Mesh не за горами и должно сильно облегчить всем жизнь, коллеги из Tools уже близки к внедрению абстрактного «Istio здорового человека»: жизненный цикл каждого HTTP(s)-запроса будет виден в мониторинге, и всегда можно будет понять «на каком этапе всё сломалось» при межсервисном (и не только) взаимодействии. Подписывайтесь на новости хаба компании ДомКлик. =)
Поддержка инфраструктуры Kubernetes
Исторически сложилось так, что мы используем патченную версию Kubespray — Ansible-роль для разворачивания, расширения и обновления Kubernetes. В какой-то момент из основной ветки была выпилена поддержка non-kubeadm инсталляций, а процесс перехода на kubeadm предложен не был. В итоге, компания Southbridge сделала свой форк (с поддержкой 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 threads, 64-128 Гб памяти и 300 Гб SSD RAID 10 — всего их 50 штук. Три «тонкие» ноды выделены под «мастера» Prod-«Куба»: 16 Гб памяти, 12 CPU threads.
Для прода предпочитаем использовать «голое железо» и избегаем лишних прослоек вроде OpenStack: нам не нужны «шумные соседи» и CPU steal time. Да и сложность администрирования возрастает примерно вдвое в случае in-house OpenStack.
Для CI/CD «Кубовых» и других инфраструктурных компонентов используем отдельный GIT-сервер, Helm 3 (перешли довольно болезненно с Helm 2, но очень рады опции atomic), Jenkins, Ansible и Docker. Любим feature-бранчи и деплой в разные среды из одного репозитория.
Заключение

Вот так, в общих чертах, в компании ДомКлик выглядит процесс DevOps со стороны инженера эксплуатации. Статья получилась менее технической, чем я ожидал: поэтому, следите за новостями ДомКлик на Хабре: будут более «хардкорные» статьи о Kubernetes и не только.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_devops, #_kubernetes, #_kubernetes, #_domclick, #_devops, #_ops, #_sre, #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_devops, #_kubernetes

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 23:56
Часовой пояс: UTC + 5