Kubernetes в НСПК

Kate

Administrator
Команда форума
Всем привет! Меня зовут Назаров Алексей, я работаю в отделе развития инфраструктурных систем автоматизации Мир Plat.Form (НСПК) и сегодня расскажу о том, как устроены наши кластеры Kubernetes и как мы ими управляем.

Допустим у вас имеются проекты, построенные на микросервисной архитектуре, и несколько команд разработчиков под какой-либо проект. Вы хотите быстро поднимать различные окружения (test, UAT, prod) или даже давать такую возможность пользователям. Тогда вам нужен Kubernetes. Поэтому Kubernetes нужен и нам.

1294e79531800acd287edd380853a462.jpg

Для начала надо сказать, что мы используем ванильный Kubernetes на своих серверах. Никаких облаков, только bare metal. Изначально наши кластеры были на CentOS + docker, однако сейчас наша команда заканчивает их перенос на Ubuntu + cri-o. Обновление самого Kubernetes и остальных компонентов мы проводим на постоянной основе и стараемся не отставать от актуальных версий.

У нас есть продовые, тестовые и бета-тестовые кластеры.

Продовых кластеров у нас два, они расположены в разных ЦОДах, имеют сетевую связанность, но независимы друг от друга. Кластеры дублируют все namespace и инфраструктурные настройки. Мы считаем, что надо связывать не кластеры, а сервисы. Входящий трафик поступает в кластеры с балансировщиков, поэтому сервисы могут быть активны сразу в двух кластерах. На продовых кластерах у нас располагаются боевые и UAT-окружения.

На тестовых кластерах настроены тестовые namespace для проектов, где разработчики и админы тестируют приложения и новые решения.

На бета-тестовых кластерах мы исследуем новые версии и виды Kubernetes, Container Runtime, операторов, etc. Помимо этого, на них мы тестируем наши роли ansible для настройки и установки новых кластеров. Готовые роли из «интернетов», вроде kuberspray, мы не рассматриваем. Мы за то, чтобы понимать, как устроен и работает Kubernetes.

Как происходит доступ к кластерам​

В Kubernetes нет объектов, представляющих обычные учетные записи пользователей. А предоставления прав через токены и сертификаты неудобны для централизованного управления во всех кластерах. Поэтому для аутентификации мы решили использовать auth-proxy (OIDC). Для этого у нас настроен кластер Keycloak, который импортирует учетные записи из LDAP.

Примечание: Как настроить такую схему, вы можете посмотреть в статье "Прикручиваем LDAP-авторизацию к Kubernetes".
В LDAP, в свою очередь, у нас имеются группы пользователей, которым мы выдаем те или иные права в кластерах Kubernetes.

Для управления кластерами мы используем Kubernetes Dashboard и kubectl. Второй вариант предпочтительный, поскольку предоставляем настроенные серверы управления. Мы нарекли их mkc (manager kubernetes clusters).

Данными серверами мы управляем через ansible. Через плейбук устанавливаются и настраиваются kubectl, плагины для kubectl, helm, скрипты авторизации через OIDC и другие инструменты.

Часть полезных плагинов на наш взгляд:

  • kubectx - инструмент для переключения между кластерами
  • kubens - инструмент для переключения между namespace
  • kube-ps1 - инструмент для отображения в консоли кластера и namespace, в которых вы сейчас находитесь
  • kubectl-capacity - инструмент для отображения используемых ресурсов кластера
  • kubectl-images - инструмент для получения сведений об используемых образах контейнеров
  • rakkess - инструмент для просмотра различных прав

Все в курсе​

44375b752ddf125c43929e3ea9d4fb24.jpg

Коммуникация между командами важна, необходимо делиться опытом и знаниями. Без этого не будет дальнейшего развития. У нас есть общая группа между пользователями и админами Kubernetes, в которой мы оповещаем об изменениях и обновлениях кластеров. В группе можно попросить помощи, и тебе помогут.

Также у нас имеется пространство во внутреннем wiki, в котором пишутся инструкции для команд разработки и эксплуатации. А еще в ближайшем будущем планируется внутреннее обучение сотрудников основам Kubernetes.

Зачем мы написали свой оператор​

Для управления кластерами обычно используют объекты ClusterRole, Role, RoleBinding, ClusterRoleBinding, ResourceQuotas, LimitRange, NetworkPolicy. При использовании оператора можно уместить все эти объекты в одном yaml-файле для каждого namespace. Так удобнее и нагляднее. Можно быстро объяснить и показать, как настроен тот или иной кластер в данный момент. Ямлики хранятся в гите и применяются после одобрения merge request. Удобно же, ну. С помощью оператора мы прозрачно настраиваем лимиты и реквесты, выдаем права, добавляем labels и аннотации, используя которые можно распределять объекты определенного namespace на нужные ноды.

Примечание: В Kubernetes одна из фич — это labels. Её можно и нужно использовать не только в подах, но и нодах. Возможно, кто-то не знает, но в Kubernetes можно включить плагин PodNodeSelector. Он позволяет принудительно запускать поды на нужных нодах через labels.
Сначала мы написали оператор на Ansible Operator и за основу взяли team-operator. Но сейчас мы его переписываем на Kopf (потому что любим python) и планируем расширять функционал.

Что еще используем​

Argo CD мы используем для централизованной доставки некоторых операторов, кастомных ClusterRole, Role и других объектов, которые требуются всем кластерам. Для CD продовых микросервисов мы используем Ansible Tower AWX. Этот выбор был сделан как единый инструмент доставки в рамках всей компании, но после ухода RedHat из России мы стали задумываться перейти на Argo CD в Kubernetes.

Kube-prometheus установлен в каждом кластере, по просьбе пользователей мы настраиваем ServiceMonitor для сбора метрик микросервисов. В операторе прописываем правила для remote_write для отправки метрик долгого хранения и централизованного мониторинга (используем Victoria metrics и Grafana).

Изначально мы рассматривали Open Policy Agent в качестве Policy Management решения. Но язык rego показался нам неудобным, в качестве языка описания политик. Поэтому мы сделали выбор в пользу Kyverno с нативным yaml.

Filebeat-daemonset для доставки логов в нашу ELK. Также с помощью Filebeat мы отправляем логи с определенных namespace для разработчиков в другие системы хранения логов. В ELK мы также отправляем логи аудита.

В Cert-manager мы используем Trust CA (созданный через центр сертификации) для кластеров, чтобы можно было автоматически выпускать валидные сертификаты для микросервисов.

Vault agent injector для доставки секретов из HashiCorp Vault в поды. Если по каким-либо причинам требуется доставить в объекты Secret, то используется vault-secret.

Для доступа к сервисам кластеров мы используем MetalLB и Nginx-controller. Стоит отметить, для достижения определенного уровня защищенности в продуктивных кластерах мы разносим namespace для UAT и prod в разные подсети. Поэтому мы используем два Ingress-контроллера.

154a7b05a9986c6567ac6cc33544aec6.jpg

Примечание: В кластере можно использовать несколько nginx controller. Почитать подробнее об этом можно тут - Multiple Ingress controllers
OpenTracing на данный момент тестируем в наших бета-тестовых кластерах распределенную трассировку. Также изучаем возможность внедрения Service Mesh, но от наших пользователей запросов еще не поступало, а мы пока не планируем менять подход и добавлять еще один дополнительный слой.

Trident Operator и nfs-provisioner - управление постоянными томами разрешаем только в тестовых кластерах. В продовых кластерах постоянные тома доступны только для хранения статических файлов и отчетов.

Velero – ежедневно резервируем прикладные и системные namespace. Уже был случай, когда он нам пригодился для восстановления.

Зачем нужны инфра админы Kubernetes​

Мы настроили наши кластеры таким образом, что отдаем разработчикам, по сути, on-premises managed Kubernetes. Они могут использовать существующие ноды или прийти к нам со своими серверами, под свой проект. Мы можем добавить сервера команды в кластер и настроить их так, чтобы там работали поды только данного проекта.

Kubernetes – конструктор, собрать его можно по-разному.

 
Сверху