Всем привет. Меня зовут Добрый Кот Telegram. В этой статье расскажем, как развернуть кластер в Yandex Cloud нашим модулем terraform. От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S. В предыдущей статье мы рассписали процес развертывания Kubernetes с использованием голых конфигов и базовых бинарных файлов - это рабочий вариант, но в наших реалиях этого недостаточно, мы хотим автоматизацию.  * Пока писали автоматизацию, испытали море эмоций как от специфики шаблонизации, так и  наследования ресурсов, но об это позже. Первая автоматизация с моей стороны была написана на Ansible. Все начиналось лампово, пара тасок там, пара тут и через месяц родилась первая версия IaC кубера на Ansible, но чем больше я писал на Ansible, тем больше понимал, что его недостаточно - нужно постоянно удалять и создавать окружения в облаке. Для создания окружения в облаке прекрасно подходит terraform, и первая мысль заключалась в том, чтобы скрестить ужа с ежом и получить первые 5 метров колючей проволки.  Получилось весьма неплохо, но в ходе эксплуатации я понял, что от Ansible можно  избавиться полностью и написать все на Terraform. Связано это было с тем, что самое важное для сборки kubernetes моим методом - требуется всего лишь один правильный Cloud-INIT и вот для него расчехлять Ansible не хотелось. Ну что, сказано - сделано! Пошли писать на Terraform. Больше всего нервов скушал модуль для Vault, именно его кодовая база является самой большой в нашей автоматизации. Самые трудоемкие части: Спецификация для будущих сертификатов. В ней содержится вся информация:  Описание для ролей. Описание для заказа Key-keeper. Описание сейфов и их CA. Мета применимости. Описание политик. Описание токенов и аппролей. В попытке решить базовую проблему безопасности - как передать в ВМ мастера временный токен через Cloud-Init - мы сотворили монстра. (На момент написания статьи Yandex Cloud наконец выпустил terraform provider для внутреннего сервиса LockBox, который позволяет решить проблему через IAM) - скоро пофиксим. Дальше пытались задизайнить максимально простую, но достаточно высокодоступную конфигурацию и пришли к вот такой схеме. Концепт простой, сделать так, чтобы виртуальные машины стали Stateless и не хранили никакой полезной нагрузки, и чтобы, в случае чего, их можно было без труда пересобрать (даже на другой тип операционной системы). Чтобы такое провернуть, требутся несколько моментов: База Etcd должна быть вынесена на внешние диски. Сертификаты должны заезжать на ноду сами (сертификаты заказывает key-keeper). Весь конфиг должен быть описан в Cloud-init. У ВМ должны быть статичные A записи. Мы решили все эти задачи и теперь можем работать с узлами мастеров достаточно гибко. Первая версия на терраформе выглядела как одна большая репка  с ресурсами из-за чего часто были проблемы с добавлением нового или дебага старого. Было принято решение распилить на модули все ресурсы, что вызывало много вопросов "а как лучше?". В основе лежит первый модуль yandex-cluster, в нем описывается спецификация будущего кластера и кастомизация входных аргументов модуля. vault_server - обязательный параметр, требуется для заказа сертификатов с ноды subnet_id_overwrite - необязательный, применяется если требуется мастера разнести по разным подсетям и зонам master_group - спецификация будущих мастеров Для инициализации Control Plane достаточно создать VPC и подсети для мастеров, а в Vault должен быть создан корневой сертификат компании. Дальше кастомные параметры попадают в модуль k8s-config-vars - в этом модуле формируются и растекаются по всем остальным модулям все переменные окружения кластера. После того, как переменные окружения сформированы, мы собираем для каждой будущей ноды Cloud-init окружение в Vault. От k8s-vault-master мы получаем токен и подкидываем в Coud-init. Последним действием мы создаем нужную инфраструктуру и узлы с нашими Cloud-Init конфигами. Как итог работы мы получили рабочий модуль для Yandex Cloud по созданию Control Plane Kubernetes. Когда я дописывал последние строки, я прям почувствовал себя Риком Огурчиком! Эмоций это приключение породило очень много и не все позитивные.  Самой большой проблемой было использование модулей внутри модуля, использование наследования переменных и шаблонизация самого терраформа. В перспективе, надеюсь, упростим конфигурацию.  В принципе, уже на данный момент кластер можно собрать по примеру этого флоу  Вы получите: Контрол Плейн K8S в HA режиме Развернутый ворклоуд Cilium, CoreDNS, YandexCSIDriver, YandexCloudController, Gatekeeper, Certmanager, ClusterMachineApprover В кластер добавится Worker узел - с сертификатами от волта, но выписанный кубом (Немного магии - расскажем позже) Перед собой ставим цели собрать минимальную коробку с бестпрактисами: Дописать модуль для Data-Plane (заказ workers). Добавить интеграцию с etcd-backup-restore и yandex s3. Настроить базовый мониторинг. Настроить SSO на базе Keycloak. Добавить Автоскейлер. Переписать на GO рендер cloud-init. Отрефакторить RBAC для мастеров. Переделать мастера c instances на group-instances После пересборки  Как обещал, налету можно сменить даже тип операционной системы. Ждем вас на обсуждения нашей работы в https://t.me/fr_solution_ru Kubernetes The Hard Way https://github.com/fraima/kuberneteshttps://github.com/fraima/key-keeper  Solution Architect