Platform Engineering
Наткнулся на очень интересную газетку от puppet The 2020 State of DevOps и понял, что многое из нее очень коррелируется с вопросами, которые я задаю на интервью соискателям (да, я сейчас участвую в найме).
У нас есть очень абстрактный вопрос, который звучит из раза в раз по-разному, но суть примерно следующая:
Quote
Если бы для вас стояла задача построить HA кластер kubernetes на baremetal или в публичном облаке, заточенный по highload, который в последствии можно было бы масштабировать, в том числе и как решение в разные команды разработки - как бы вы это делали? Интересуют мысли и рассуждения, и как бы это реализовывалось на практике, начиная с самых первых шагов.
Т.е. мы хотим предоставлять Platform-у по нажатию кнопки. Тут нужен IaC , ну, и не только. Я бы разделил процесс на 3 шага, но между ними должна быть синергия, чтобы осуществить развертывание платформы ~одной кнопкой:
-
compute bootstrapping- нам нужно получить железки / виртуалки, сети и прочие ресурсы, на которых будет установлена ОС, поверх которой уже можно устанавливать компоненты k8s. В большинстве случаев это должен решать terraform и aws / gcp / vmware / open-stack провайдеры. -
provisioning- настройка os, установка HA кластера kubernetes на compute ресурсах из предыдущего шага силами систем управления конфигурациями. Этот шаг может опускаться при использовании managed kubernetes в публичных облаках -
конфигурация кластера- сам из себя kubernetes кластер мало что представляет. Нужны решения для публикации веб приложений в мир, сбора метрик и логов, хранения и доставки секретов и т.д. По сути есть 2 пути установки приложений в кластер:CiOps- мы храним описание инфраструктурных приложений в Git, запускаем пайплайн, раннер, имеющий доступ к кластеру, применяет манифесты / устанавливает чарты. Хоть kubernetes и декларативная платформа, это по сути императивная операция и идемпотентность может быть не достигнута.GitOps- после третьего шага мы устанавливаем в кластер GitOps контроллер, который смотрит на манифесты / helm чарты в git репозитории и таким образом развертывает инфраструктурные приложения. Причем это полностью декларативная операция, так же исключается configuration drift - расхождения описание инфры в git и реального ее состояния.
Вывод: Как нам кажется, такой способ построения kubernetes инфраструктуры сейчас является наиболее перспективным, возможно стоит в это погрузиться.
Ссылки: - Один из примеров реализации такой платформы - репозитоирй на github - Совсем недавно услышал, что kubespray, kubeadm и подобные решения уже не котируются. Кластер хочется получать опять же декларативно. С подобным, кажется, может помочь ранчер, cluster-api.