Привет! Меня зовут Денис, и я отвечаю за контейнерную инфраструктуру в Тензоре. Начну с начала. Когда-то Kubernetes-кластеров у нас не было. Зато были 2 дата-центра и 20 тыс. виртуальных машин на тысяче железных серверов. На этом великолепии и «крутились» продукты компании Тензор.
И появилась задача — перенести весь софт в контейнеры и в кубер.
На старте были определены базовые потребности, вроде сетевой связности, внутреннего DNS и хранения данных. Естественно, мы осознавали не весь функционал, который, в итоге, потребовался. Если ваша задача схожа с нашей или вам интересно из каких кубиков собирают кубер, коллеги — добро пожаловать и приятного чтения)
Ах, да, на данный момент у нас 30 K8s-кластеров на 4 площадках, 350+ нод. И мы активно мигрируем приложения с ВМ в K8s.
Как мы подошли к задаче
Выявили несколько базовых принципов:
Модульность. Структурируем функционал и даем инженерам параллельно работать с разными модулями.
Экземпляр из шаблона. Кластеров много, но все построены идентично, можно лишь выключить второстепенные модули.
Кластер — это runtime-сущность. Все данные, что чувствительны к потере, лежат за пределами кластера. С кластерами расстаемся легко.
Самодостаточность кластера. Каждый кластер — это мини-инфраструктура, в нем есть все для работы приложений.
Потом был опытный образец k8s-кластера, работа над ошибками и вот он — наш набор модулей на сегодняшний день.
Ядро кластера
К ядру относим всё, что реализует API и стандартные ресурсы Kubernetes — весь ванильный control plane k8s. Для отказоустойчивости перед control plane мы поставили Keepalived, а для балансировки запросов — HAProxy. Осознав необходимость следить за сроками действия сертификатов, добавили в подсистему X.509 Certificate Exporter и написали триггеры.
Среда запуска контейнеров
Начинали с docker, но, однажды, при обновлении k8s, перешли на containerd.
Сеть передачи данных
Начали с Cisco ACI CNI-plugin, ибо были планы строить на Cisco ACI сеть ЦОД. Хорошо, что не успели. Не понравилось — изменения из k8s-кластера доходили до ACI-фабрики почти с минутной задержкой, да и багов хватало. Стали искать альтернативный CNI-плагин, выбирали между Cilium и Calico. Задумали в каждом кластере выделить router-ноды с двумя функциями:
анонсировать во внешнюю СПД маршруты к кластеру,
балансировать трафик, предназначенный LoadBalancer-сервисам.
От внешнего маршрутизатора требовалось принимать BGP-анонсы и раскидывать трафик по router-нодам (ECMP).
Ключевое требование — выход из строя или плановый вывод router-ноды не должны отражаться на приложениях. Для нашего облака массовая переустановка TCP-сессий — это большая проблема. И тут Cilium "заиграл" благодаря поддержке алгоритма балансировки Maglev. При распределении входящих соединений по эндпоинтам router-ноды независимо друг от друга принимают одинаковые решения. При выходе одной из router-нод из строя оставшиеся будут направлять пакеты так же, как это делала бы упавшая. Поэтому TCP-сессии не рвутся.
Через 300 миллисекунд, после падения router-ноды, внешний маршрутизатор перестает направлять на нее трафик, так как у нас настроен BFD. Встроенный в Cilium механизм BGP не поддерживает BFD, поэтому используем Bird с самописным конфигуратором.
DNS
Наш Kubernetes встроен в существующую схему DNS компании. В ее центре — кэширующие серверы. Они хранят данные из всех наших DNS-зон. Это позволяет ослабить зависимость от DNS-серверов, обслуживающих отдельные DNS-зоны и при необходимости "холодного" старта ЦОД иметь работающий DNS уже на раннем этапе.
Изначально для интеграции с кэшами использовали связку ExternalDNS↔PowerDNS↔кэши. Почему? Она быстро взлетела. Позже в плагинах CoreDNS появилась поддержка zone-transfer и работы с views. Мы смогли работать из CoreDNS с кэшами напрямую. Для этого разработали плагин, который добавил возможность экспорта/импорта DNS-зон вместе с DNS-записями Ingress'ов.
Балансировка HTTP-трафика
Без изысков — используем стандартный Kubernetes Ingress NGINX Controller. Аннотации на Ingress позволяют многое сделать. Нам, например, пригодилась маршрутизация по заголовкам и аутентификация через ADFS. Так что пока не стали переходить на более модные варианты.
Интеграция с СХД
Для приложений с высокими требованиями к дисковой системе используем FC-тома. Для этого «подружили» k8s с СХД от IBM через проприетарный provisioner. Для приложений попроще — Kubernetes NFS Subdir External Provisioner.
Предоставление прав пользователям
По нашему опыту, чтобы не погрязнуть в раздаче прав, нужно сразу продумать кто и с какими целями будет приходить в кластер. У нас, в итоге, получился список ролей, и пользователи получают права только из этого предопределённого списка.
Кстати, стоит обратить внимание на возможности по агрегации ролей в K8s. Агрегатные роли сами по себе не содержат никаких прав, а только собирают в себя «фрагменты» (сниппеты). Разработчику модуля достаточно подготовить сниппеты и указать в какие роли их надо агрегировать.
В качестве OIDC-провайдера используем Active Directory + ADFS.
Интерфейсы управления ресурсами
Для широкого круга пользователей эксплуатируем штатный Kubernetes Dashboard. Через связку "oauth2-proxy ↔ ADFS ↔ AD" реализовали прозрачную аутентификацию. Для инженеров — kubectl. С плагинами krew и kubelogin можно аутентифицироваться через тот же ADFS. Так как кластеров много, написали интерфейс, который позволяет инженеру быстро настроить подключения к нужным.
Проверка манифестов ресурсов
По началу неочевидный, но в итоге очень мощный модуль! Во-первых, позволяет задавать правила для манифестов, чтобы автоматически выявлять манифесты-нарушители. Это помогает избежать попадания в k8s-кластер «неправильной» нагрузки. Например, запретить использовать для приложений hostPath, а образы разрешить использовать только из внутреннего хранилища. Во-вторых, позволяет автоматизировать процедуры — избавляет от рутинного труда. Например, мы автоматически создаём VPA-ресурс для всех ресурсов вроде Deployment и StatefulSet (далее расскажу зачем).
Для реализации выбрали Kyverno. Дополнительно написали GUI, где разработчик видит нарушения только по своим ресурсам, а администратор безопасности — по всем.
Новую политику сначала включаем в режиме уведомления (audit) и через GUI выявляем нарушителей. Как только все нарушения устранены, переводим политику в принудительный (enforce) режим, после чего новые нарушители уже не могут попасть в кластер.
Масштабирование приложений
Для горизонтального используем HPA, для вертикального — VPA. Сперва про HPA. Не устраивает пока только то, что для масштабирования вниз максимальное время оценки - 1 час. Хотелось бы 1 месяц и даже более, ибо циклы нагрузки у нас меряются кварталами и годами. Будем искать замену стандартному HPA. В качестве источника метрик с MetricsServer перешли на Prometheus Adapter, чтобы иметь возможность принимать решение на основании любой метрики.
Теперь про VPA. При развёртывании Deployment, StatefulSet и подобных ресурсов "автоматом" создаём для них VPA-ресурс в режиме рекомендаций. Для удобной визуализации разработали GUI, где разработчик приложения может быстро понять сколько ресурсов надо добавить или убавить его приложению. А администратор ресурсов легко находит тех, кто создает overbooking в кластере
Управление пулами нод
Поначалу можно не обратить внимания, что в k8s нет встроенных средств группировки нод. Есть метки. Но, во-первых, чтобы ими оперировать, нужны права на ноды, а во-вторых, ввод текста руками — это место для очепяток. Мы решили хранить состав пула в custom-ресурсе, туда органично вписались и параметры пула (например, границы для триггров по пулам). Разработали оператора, который по данным CR изменяет атрибуты нод. Без интерфейса не обошлось.
Секреты
Секреты храним в Vault. В кластере используем External Secrets Operator. Ему на входе в ресурсе ExternalSecret надо сообщить откуда брать секретные данные и в какой ресурс Secret их поместить. А дальше он сам. Начиная с версии 0.7.0 у этого оператора появилась возможность не только получать секреты из Vault, но и загружать в него свои. Планируем использовать этот метод для интеграции внешних систем с K8s.
Управление настройками компонентов кластера
По мере роста количества кластеров встала задача централизованного управления их конфигурациями. Мы пошли по пути "экземпляр следует рожать из шаблона". Шаблон содержит объявление и дефолтные настройки всех возможных модулей. Описание экземпляра индивидуализирует шаблон до конкретного кластера (имя, адресация и т.п.) и может его переопределить (отключить модуль, к примеру). Все храним в git, а доставляем в кластеры через ArgoCD.
Архитектор рулит платформой через шаблон (1), CI/CD "копипастит" шаблон в конфигурации (2), администратор может уточнить конфигурацию (3), ArgoCD следит за изменениями и применяет настройки в кластере (4).
Данное решение обеспечило нам единую точку правды о конфигурациях, все прелести git и уверенность, что все наши кластеры настроены единообразно.
Изменения в шаблон вносим через релизный цикл. Релизим раз в неделю, в основе что-то близкое к GitFlow.
Мониторинг и алертинг
Для сбора и хранения метрик в кластере используем достаточно распространённую пару Prometheus и VictoriaMetrics.
Дабы сберечь ресурсы, мы препятствуем попыткам пересылать бессмысленные метрики уже на этапе их сбора: каждая метрика должна быть явно описана в PodMonitor/ServiceMonitor-ресурсе и снабжена комментариями (по ним мы автоматически создаём документацию на метрики).
У нас есть отдельные Prometheus для инфраструктурных и прикладных метрик — так изменения прикладной нагрузки не влияют на сбор системных метрик.
Основное хранилище — долгосрочное. А ещё есть краткосрочное, оно хранит данные в ОЗУ на случай критических сбоев в долгосрочном. Ещё есть шлюз, который позволяет из Grafana получить доступ к метрикам сразу группы k8s-кластеров, не прописывая при этом каждый источник метрик в Grafana. Количество кластеров непостоянно, поэтому мы добавили в систему компонент, который актуализирует список кластеров на шлюзе.
Для алертинга используем не слишком распространенное решение Bosun. Триггеры храним как код. Для этого написали оператора, он переносит определения триггеров из custom-ресурсов в конфигурацию Bosun. От самого Bosun мы не в восторге. Так сложилось, что на старте пришлось использовать именно его. Ищем замену.
Логирование
Временным решением была связка Filebeat с внешним кластером Elasticsearch. Но недавно всё изменилось: перешли на Loki. Теперь логи можно смотреть прямо в Grafana вместе с метриками. Без доработок не обошлось:
мы не нашли готового решения, чтобы показывать логи только тем, у кого есть доступ к namespace. Поэтому написали свой компонент — он по заголовкам HTTP-запросов от Grafana проверяет, есть ли у данного пользователя права;
решили задавать ограничения на объём хранения и поток логов по приложениям — для этого написали k8s-оператора. Он записывает fluentbit'у в throttleFilter желаемый rate, а в конфиг Loki передает время хранения логов для Namespace.
Резервное копирование
Используем Velero и пока нам его хватает на 100% :)
Сбор дампов
Через DaemonSet запускаем Core Dump Handler на всех нодах. Он собирает дампы и закидывает их в S3-хранилище, а триггер уведомляет об этом эксплуатацию. Его мы немного пропатчили — запретили снимать более 1 дампа одновременно, поскольку это сильно загружало ноду и бывало, пока один дамп отправлялся, второй уже записывался на его место — получали битые дампы. После патча работает ровно.
Управление приложениями
Приложения заказчика мы запускаем по SaaS-модели. Для этого у нас есть несколько модулей, в основе которых CR и операторы. Но эта тема тянет на отдельную статью :)
Итак, теперь вы знаете как мы строили (и построили) "свой Кубер". Но, как говорится "бесконечность - не предел" и у нас уже много новых планов, например:
Интегрировать платформу с NetBox, который мы используем как CMDB для всей инфраструктуры. Планируем написать контроллер, который при обнаружении изменений в CMDB создаст merge request в конфигурацию кластера. Администратору кластера останется проверить и принять изменения.
Реализовать идею эфемерности нод: на ноде оставить минималистичную read-only ОС, шаблон конфигурации хранить в git, а конфигурацию в CMDB.
Перейти с морально устаревшего NFS на Linstor.
Так что не переключайтесь, друзья :)
