Введение: почему мы решили открыть свои наработки

Каждая компания, которая серьёзно занимается инфраструктурой, рано или поздно накапливает собственный набор инструментов, скриптов и практик. Что-то создаётся для решения сиюминутных задач, что-то вырастает в полноценные внутренние продукты. И в какой-то момент возникает вопрос: оставить это внутри компании или поделиться с партнёрским сообществом?

Компания СТАРКОВ Групп, генеральный партнёр Directum, всегда выбирает второй путь. Мы представляем сообществу свой Ansible-плейбук для развертывания отказоустойчивых Kubernetes кластеров и выкладываем его в открытый доступ на GitHub.

Почему мы приняли такое решение? Ответ прост: мы искренне верим, что экспертизой нужно делиться. За годы работы наша команда прошла через множество проектов, набила немало шишек и выработала подходы, которые реально работают. Этот опыт может быть полезен коллегам по отрасли, и было бы неправильно держать его под замком.

Наш плейбук открыт для всех. Если вы наш клиент, партнёр Directum или просто специалист в поисках действенного инструмента — берите и используйте его для своих проектов.

Проблема, с которой сталкивается каждый

Давайте поговорим о том, с чем приходится иметь дело инженерам, когда речь заходит о развертывании Kubernetes в production.

Ручная установка — дело хоть и интересное, но затратное, если рассчитывать это в человеко-часах, да и к тому же, никто не застрахован от ошибок.

Kubespray — мощное решение, ставшее своеобразным стандартом в индустрии. Это действительно впечатляющий проект с огромными возможностями. Такая мощность, однако, требует внимательного подхода: работа с сотнями переменных конфигурации, сложная иерархия ролей, а также значительное время выполнения процессов. Чтобы по-настоящему разобраться в Kubespray, понять логику его работы и научиться эффективно кастомизировать под свои нужды, требуются дни, а то и недели погружения.

Но есть ещё один важный момент, который часто остаётся за кадром. Задачи импортозамещения сегодня стоят перед многими организациями. Всё больше компаний, особенно в государственном секторе и в смежных отраслях, переходят на RedOS, Astra Linux и другие отечественные операционные системы. И вот тут возникает неприятный сюрприз: готовых, проверенных инструментов для развертывания Kubernetes на этих ОС практически не существует. Kubespray их не поддерживает из коробки.

Именно эта ситуация подтолкнула нас к созданию собственного инструмента. Нам нужно было что-то простое, понятное и поддерживаемое. Что-то, что решает реальные задачи здесь и сейчас, а не заставляет тратить время на изучение документации и разборы полётов.

Наша философия: честный разговор о простоте и прагматизме

Прежде чем рассказывать о возможностях плейбука, мы хотим поговорить о подходе, который лежит в его основе. И здесь нам важно быть максимально честными.

Мы выбрали простоту вместо догматичного следования всем правилам.

Что это означает на практике? Плейбук местами использует модуль shell/command вместо специализированных Ansible-модулей. Для пуриста это может выглядеть как нарушение канонов. Но давайте посмотрим на это с другой стороны.

Когда инженер открывает наш плейбук, он видит понятные shell-команды — те самые, которые можно взять и выполнить руками в терминале. Любой специалист, знакомый с Linux и bash, сразу поймёт, что происходит в каждой таске. Не нужно лезть в документацию Ansible, изучать десятки специфичных модулей и разбираться в их особенностях. Минимум «магии» — максимум прозрачности.

Вот реальный пример из нашего плейбука:

ansible.builtin.shell: kubeadm token create -print-join-command

Одна строка. Понятная команда. Любой инженер сразу видит, что здесь происходит: создаётся токен и генерируется команда для подключения воркеров. Можно скопировать эту команду, выполнить вручную, убедиться что всё работает. Никакой магии, никаких скрытых абстракций.

Какие преимущества даёт такой подход?

• Простой для понимания даже для тех, кто не глубоко знает Ansible. Достаточно базового понимания YAML и опыта работы с Linux.

• Минимум зависимостей. Весь плейбук требует всего две внешние коллекции: community.general и ansible.posix. Никаких десятков зависимостей, которые могут конфликтовать между собой или устаревать.

• Легко отлаживать. Если что-то не работает, можно взять команду из shell и выполнить её руками, чтобы понять причину проблемы, если дефолтного вывода ansible недостаточно.

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

Честное признание: да, это не идеальный код по всем канонам Ansible. Да, опытные разработчики могут найти к чему придраться. Но это работает, это понятно, и это легко поддерживать. Мы выбрали прагматизм вместо перфекционизма. И считаем это правильным выбором для инструмента, который должен решать реальные задачи в реальных проектах.

Что умеет наш плейбук: возможности без маркетингового тумана

Теперь давайте поговорим о конкретных возможностях. Мы постараемся рассказать о них без преувеличений — просто факты о том, что инструмент умеет делать.

Поддержка операционных систем

Одна из главных особенностей плейбука — поддержка импортозамещённых ОС, таких как: Astra Linux (Orel), RedOS 8, но также есть ещё и знакомые всем debian/ubuntu. Почему нет поддержки Astra Linux SE? Ответ довольно простой: для того чтобы Kubernetes корректно заработал в редакции SE, приходится все навороты от SE отключать — и какой в этом тогда смысл-то?

Важно отметить, что это не теоретическая поддержка «на бумаге», а проверенные с помощью десятков тестов варианты установки.

Сетевые плагины (CNI) на выбор

Выбор сетевого плагина — важное архитектурное решение, и здесь нет универсального «лучшего» варианта. Поэтому плейбук поддерживает несколько CNI, каждый со своими сильными сторонами:

• Flannel — простой и надёжный. Отличный выбор для тех, кто только начинает работу с Kubernetes или не нуждается в сложных сетевых политиках. Минимум настроек, предсказуемое поведение.
• Calico — более функциональный вариант. Поддерживает сетевые политики, обеспечивает высокую производительность. Хороший выбор для production-окружений с требованиями к сетевой безопасности.
• Cilium — современный подход на базе eBPF. Для тех, кто хочет использовать передовые технологии и готов к более сложной настройке.

Хранилища данных

Без персистентного хранилища Kubernetes-кластер подходит только для stateless-приложений. Наш плейбук пока что поддерживает два варианта:

• local-path-provisioner от Rancher — простое решение, которое использует локальные диски нод. Подходит для разработки, тестирования и простых production-сценариев.
• Longhorn — распределённое блочное хранилище. Обеспечивает репликацию данных между нодами, поддерживает снапшоты и бэкапы. Серьёзный выбор для production-окружений, где важна сохранность данных.

Высокая доступность: два подхода на выбор

Отказоустойчивость — ключевое требование для production-кластеров. Плейбук поддерживает два режима организации HA, и каждый имеет свои преимущества.

Классический подход: HAProxy + Keepalived

Это проверенная временем комбинация, знакомая большинству инженеров. HAProxy выступает в роли балансировщика нагрузки и распределяет трафик между API-серверами Kubernetes. Keepalived обеспечивает отказоустойчивый Virtual IP: если основная нода выходит из строя, IP-адрес автоматически переезжает на резервную.

Современный подход: kube-vip

Более элегантное решение, которое работает как static pod прямо внутри Kubernetes. Virtual IP обеспечивается через ARP с механизмом leader election. Главное преимущество — меньше внешних компонентов, проще архитектура, меньше точек отказа.

Объективное сравнение с альтернативами

Мы не будем утверждать, что наш плейбук — лучший инструмент на свете. У каждого решения есть своя ниша. Но давайте всё же сравним подходы.

В сравнении с Kubespray

• Простота конфигурации. Вся настройка нашего плейбука умещается в одном файле hosts. В Kubespray вам придётся работать с сотнями переменных, разбросанных по множеству файлов.

• Зависимости. Наш плейбук требует две Ansible-коллекции. Kubespray тянет за собой десятки зависимостей.

• Время на освоение. Структуру нашего плейбука можно понять за час-два. На освоение Kubespray закладывайте, как минимум, неделю.

• Поддержка отечественных ОС. RedOS и Astra Linux поддерживаются нативно. В Kubespray такой поддержки без «костылей» нет.

• Скорость выполнения. Наш плейбук работает быстрее за счёт отсутствия избыточных проверок и универсальных абстракций.

При этом нужно признать: Kubespray более гибкий и функциональный инструмент. Если вам нужны экзотические конфигурации или поддержка десятков различных сценариев, то, возможно, Kubespray подойдёт лучше. Наш плейбук покрывает типовые сценарии, но не претендует на универсальность.

В сравнении с ручной установкой

Если вы всё ещё разворачиваете кластеры руками, автоматизация даст очевидные преимущества:

• Идемпотентность. Плейбук можно безопасно запускать повторно. Если что-то прервалось посередине, просто запустите снова.

• Экономия времени. Хотите руками крутить кубик на ~10 нодах, вас никто не останавливает. Но сколько вы потратите на это времени? А если нод не 10, а 20? А если вообще 100?

• Кластер из любых ОС. Данный плейбук создан, чтобы вы могли собрать любой кластер, из любых ОС. Хотите 3 мастера/воркера, но каждый с разными ОС? Пожалуйста! Просто укажите их ip в hosts файле, а плейбук сделает всё остальное, сам определит ОС, сам выполнит нужные шаги, вам остаётся только наблюдать за процессом!

• Единообразие. Все серверы настраиваются одинаково.

Импортозамещение: не галочка, а реальная работа

Тема импортозамещения часто превращается в маркетинговый шум. Компании заявляют о поддержке отечественных ОС, но на практике оказывается, что эта поддержка существует только в презентациях, или в крайне «костыльных» решениях. Мы подходим к этому иначе. Поддержка RedOS и Astra Linux в нашем плейбуке — результат реальной работы и множества тестов. Но нюансы, конечно есть:

• RedOS: Kubernetes доступен в стандартных репозиториях этой операционной системы, что упрощает установку и обновление.
• Astra Linux: здесь ситуация немного сложнее, так как Kubernetes нет в штатных репозиториях. Плейбук выполняет установку из официальных бинарников, автоматически создаёт systemd-сервисы для всех компонентов и обходит известные ограничения ОС, которые могут мешать работе кластера.

Это не теоретическая поддержка — это проверенное на практике решение.

Быстрый старт: от нуля до работающего кластера

Одна из целей, которую мы ставили при создании плейбука — минимизировать время от «хочу попробовать» до «у меня работает кластер». Вот как выглядит процесс.

Конфигурация

Вся настройка выполняется в одном файле hosts. Вот пример типовой конфигурации:

[all:vars]

ansible_user=user

#Username для аутентификации на серверах

ansible_python_interpreter=/usr/bin/python3

# Kubernetes Configuration

kubernetes_cni=calico

# Варианты: flannel, calico, cilium, none

kubernetes_storage=longhorn

# Варианты: none, local-path, longhorn

kubernetes_repo_mirror=tsinghua

# Варианты: official, tsinghua

kubernetes_version=1.32.0

# Версия Kubernetes для установки (формат: X.Y.Z, например 1.32.0)

kubernetes_install_method=repo

# Метод установки Kubernetes:

# repo - из репозиториев (по умолчанию для Debian/Ubuntu/RedOS)

# binary - из бинарников (обязательно для Astra Linux, опционально для других)

# Для Astra Linux автоматически используется binary независимо от этой настройки

ha_type=kubevip

# Варианты: legacy (haproxy+keepalived), kubevip

# При kubevip используется дефолтный порт 6443, при legacy - 6444 (за HAProxy)

#enable_worker_on_cp=true

# Разрешить запуск workloads на control-plane нодах (снять taint, добавить метку worker)

# По умолчанию: true

[master_node]

master0 ansible_host=10.0.10.101 keepalived_priority=100

# Нода на которой будет производиться первоначальная инициализация, единственная обязательная нода в плейбуке.

[other_masters]

master1 ansible_host=10.0.10.102 keepalived_priority=99

master2 ansible_host=10.0.10.103 keepalived_priority=98

#master3 ansible_host...

#masterN ..

[worker_nodes]

worker1 ansible_host=10.0.10.104

worker2 ansible_host=10.0.10.105

#worker3 ansible_host...

#workerN

[control_plane:children]

master_node

other_masters

[control_plane:vars]

keepalived_virtual_ip=10.0.10.10

Всё понятно с первого взгляда: указываем версию Kubernetes, выбираем CNI и хранилище, перечисляем ноды с их IP-адресами, задаём Virtual IP для HA. Никаких сотен переменных, никаких вложенных файлов конфигурации за которые стоит беспокоиться инженеру.

И да — вас никто не заставляет разворачивать кластер из определенного количества нод, хотите кластер из 1 ноды? Удалите все master и worker записи, оставьте только master0 и запускайте!

Три команды для повседневной работы

• Развернуть кластер: ansible-playbook -i hosts k8s.yml

• Полностью удалить кластер: ansible-playbook -i hosts k8s-cleanup.yml

• Выполнить только определённые шаги: ansible-playbook -i hosts k8s.yml -tags "storage"

Техническая структура

Плейбук состоит из 8 основных ролей: common, containerd, kubernetes-common, haproxy_keepalived, kubevip, kubernetes-master, kubernetes-con-node, kubernetes-storage. Поддерживается работа через китайские зеркала репозиториев (официальные репы могут блокироваться провайдерами). Pod CIDR по умолчанию настроен как 10.244.0.0/16, но легко меняется при необходимости.

Планы развития: мы здесь надолго

Выложить код в open source — это только начало. Мы планируем активно поддерживать и развивать плейбук.

• Поддержка новых версий Kubernetes. По мере выхода новых релизов мы будем обновлять плейбук. В данный момент, плейбук позволяет развернуть Kubernetes версией старше 1.29.

• Расширение списка ОС. Если появится потребность в поддержке других операционных систем — мы готовы её добавить. Но нужно время.

• Поддержка добавление новых нод, к уже существующему кластеру. Изначально такой сценарий не закладывался, но вполне реализуем в рамках одного плейбука.

• Расширение возможностей установки. В будущем появится возможность использования FQDN вместо IP, для controlplaneendpoint, что даст возможность использовать дефолтный порт 6443, при использовании legacy-метода HA.

• И многое другое!

Заключение: попробуйте сами

Мы создали инструмент, который решает реальные задачи: развертывание отказоустойчивых кластеров Kubernetes просто, понятно и с полноценной поддержкой отечественных операционных систем. И решили поделиться им с вами, потому что верим: так правильно.

Плейбук доступен на GitHub: https://github.com/EgorovEA/k8s-ansible 

Мы приглашаем вас попробовать его в деле. Разверните тестовый кластер, посмотрите как всё работает, оцените подход. Если что-то не понравится или вы увидите возможность для улучшения — напишите нам. Любая обратная связь помогает делать продукт лучше.

И если вашей организации нужна помощь с внедрением Kubernetes, настройкой DevOps-практик или автоматизацией инфраструктуры, компания "СТАРКОВ Групп" готова помочь. Мы не просто выкладываем код в open source, мы реально работаем с этими технологиями каждый день и знаем их не по документации, а по опыту реальных проектов.