Меня заинтересовала тема Kubernetes, и я решил освоить его. На начальном этапе все шло хорошо, пока я изучал теорию. Однако как только дело дошло до практики внезапно выяснилось что по каким то причинам самое быстрое и распространённое решение minikube просто отказывается разворачиваться на моей Fedora. Разворачивание просто зависало на одном из этапов. Причина подозреваю была в не отключенном по умолчанию swap разделе, но на тот момент я не додумал.  Попробовав несколько вариантов с разными виртуальными машинами, я решил что раз не работает minikube, значит надо развернуть более комплексное решение. Подумал и полез в интернет. После прочтения нескольких статей на нашем ресурсе я решил остановиться на этой:  @imbasoft   "Гайд для новичков по установке Kubernetes"    В ней было всё разложено по полочкам, все шаги выполнялись легко и непринуждённо. В конце получался замечательный стенд для тренировок. Причем стенд вариативный, с разными движками контейнеризации, и вариантами запуска как аналог миникуба, так и пяти хостовый вариант с управляющими и рабочими нодами. Но смущал меня один момент, в статье было описано развёртывание со многими снапшотами, чтобы можно было вернуться и переиграть по‑новому.Каждый раз откатываться по нескольким машинам мне не хотелось. А развернуть хотелось.Решение пришло быстро. Ansible. Можно раскатываться и перераскатываться относительно быстро. В любой момент можно удалить стенд и начать заново.  До этого не работал с ansible, поэтому это так же показалось мне вполне неплохой практикой. Возможно решение не самое правильное, надеюсь люди в комментариях меня поправят или подскажут более удачные варианты решений. Но пока представляю на суд то что получилось в итоге. Я знаю что существуют готовые варианты типа kubespray, но тут больше хотелось поработать именно с ansible, так что я решил не упускать возможности. В любом случае не ошибается тот, кто ничего не делает, так что лучше я допущу десяток ошибок новичка, на которые мне может даже укажут, чем вообще не попробую. Итак, с чего начать? Во‑первых надо было выбрать виртуализацию. KVM показался мне нормальным решением, он можно сказать родной для linux, есть возможность рулить из командной строки. Я не буду описывать как настраивать KVM на машине и устанавливать ansible, статья не об этом. Предположим что у вас уже всё установлено. Как я уже написал, опыта с ansible у меня не много, но даже с ним я понимаю что писать одну большую простыню кода не особо удобно, а отлаживать и того хуже. Было решено разбить её на несколько простыней поменьше посредством ролей. В целом если прочитать оригинальную статью то можно выделить 3 этапа: Подготовка виртуальных машин Установка движка контейнеризации Установка all_in_one/ha_cluster Исходя из этого будем готовить 4 роли со своими тасками. vm_provision driver_provision k8s_all_in_one k8s_ha_cluster  Создаём каталог, у меня он называется kvmlab, и в нем файл setup_k8s.yaml Это будет главный playbook, из него будут подтягиваться остальные по мере необходимости. Tак же нам понадобится inventory и файл с переменными которыми мы будем управлять развёртыванием. Ну и конечно же роли.  В каталоге выполним, для создания ролей. Файл inventory описывает наши ansible_host для подключения: my_vars.yml как видно из названия описывает переменные, параметры развертывания, параметры виртуальных машин, каталоги хранения iso и дисков VM: Рассмотрим переменные чуть подробнее: variant - это наш вариант установки будем ли мы устанавливать кластер или ограничимся одной машиной и сделаем аналог minikube. engine - собственно движок контейнеризации libvirt_pool_dir и libvirt_pool_images каталоги хранения дисков виртуальных машин и скачанных образов соответственно. vm_net - имя создаваемой сети для ваших машин. ssh_key - ваш публичный ключ, подкидывается   на ВМ в процессе подготовки и дальнейшие действия выполняются вашим логином из под root. ansible_ssh_common_args - отключение проверки хеша ключа. Теперь вернемся к setup_k8s.yaml: Первый play выполняется на localhost, требует повышенных прав и состоит из 6 task: Подготовка окружения - на этом этапе мы устанавливаем необходимые пакеты для управления libvirt. Настройка сети - машины будут использовать свою сеть, но её надо предварительно создать. Подготовка шаблона для ВМ - все машины будут с одинаковой OS, в моём случае с debian 11, у них будет одинаковый набор начальных пакетов. Каждый раз разворачивать с нуля долго, поэтому надо подготовить шаблон VM и переиспользовать его при необходимости. Создание ВМ нод из шаблонного образа. Создание нужного количества VM для развертывания. Перезагрузка созданных машин. Создание снапшота. Эта таска опциональна, при дальнейшем развёртывании часто случались ошибки и надо было начинать сначала, снапшот решал эту проблему. в целом сейчас он уже не нужен, но я оставил. Для подготовки будем использовать роль vm_provision о ней чуть позже, а сейчас посмотрим на то что получилось:  kvmlab/setup_k8s.yaml: Визуально не много, давай разберём что скрывается под include_role.  А под ролью у нас скрывается: Дефолтные настройки на случай если какие то переменные не заполнены, по иерархии если не ошибаюсь стоят в самом низу, т.е. если эти переменные прилетят откуда от еще, их приоритет будет выше: kvmlab/roles/vm_provision/defaults/main.yml: 2 шаблона: roles/vm_provision/templates/ vm-template.xml.j2 - Шаблон по которому создается виртуальная машина в xml формате. при создании параметры заполняются из заданных переменных. vm_network.xml.j2  - Шаблон для создания сети которую будут использовать VM. Я не буду их приводить, вы сможете забрать их в репозитории. Ну и наконец roles/vm_provision/tasks/ create_network.yml - набор задач для создания сети create_nodes.yml - набор задач для создания нод create_snapshot.yml - создание снапшотов prepare_images_for_cluster.yml - подготовка шаблона Начнем с подготовки шаблона:состоит из 4 задач: Создание каталога для хранения исходного образа(если конечно он не существует). Скачивание и проверка базового образа. Каждый раз качать его нет смысла, поэтому скачивается один раз, при повторном запуске, если файл уже лежит на месте эта часть скипается. Базовый образ уже можно подключить к ВМ и работать с ним, однако тогда он перестанет быть базовым, а уже будет кастомизированным. Оставим его как есть, но скопируем его как шаблон для ВМ. первичная настройка шаблона. Часть библиотек и ПО для любого варианта развертывания будет одна и та же. Поэтому проще накатить их сразу в шаблон. Так же заполним hosts, по-хорошему его бы заполнять динамически в зависимости от количества нод, но я прописал 5 штук сразу. Сильно не мешает.  kvmlab/roles/vm_provision/tasks/prepare_images_for_cluster.yml: Отлично, шаблон готов. далее на очереди создание сети, ибо сеть используется в шаблоне создания ВМ, и если её не будет, то чуда не случится. Тут все просто, используя virsh мы проверяем создавалась ли сеть ранее. если да, то скипаем, если же нет, то используя шаблон в который будет подставлено имя сети из переменных средствами всё той же virsh будет создана, запущена и выставлена в автозапуск сеть. kvmlab/roles/vm_provision/tasks/create_network.yml: Так. Шаблон ВМ есть, сеть есть. Ничего не мешает нам создать ноду или ноды: Создание нод запускается циклом по переменным. (vm_info.vm_names) ноды создаются по одной и проходят следующие этапы: Опять же создается каталог для хранения дисков виртуальных машин, если он не существует. Каждая машина перед созданием проверяется на наличие её в уже существующих, если она есть, то создание пропускается, так что если у вас осталась машина с прошлого стенда то лучше её пересоздать. Копируется шаблонный образ диска и переименовывается в соответствии с именем ВМ. Изменяется размер диска, расширяется до 10 GB, этого объема мне хватило для установки всех вариантов. Значение захардкожено, но при желании его можно так же параметризовать. Начальное конфигурирование ноды. Тут у нод появляется индивидуальность, имя, ip и свой ssh ключ. Когда все составные части готовы, создается машина из шаблона xml. Запуск ВМ.  kvmlab/roles/vm_provision/tasks/create_nodes.yml: Отлично, машины созданы. теперь перезагрузим их, дождемся пока все загрузятся и сделаем снапшоты. kvmlab/roles/vm_provision/tasks/create_snapshot.yml: Если ничего не забыл, то первый этап выполнен. У вас есть одна или пять нод, все готовы к дальнейшей работе.  Причем если удалить все ВМ и запустить создание повторно, то из за наличия готового шаблона процесс пройдёт гораздо быстрее. Отлично. переходим к установке движка: вернемся в setup_k8s.yaml и добавим следующий play: В целом всё просто, используем роль driver_provision, но в зависимости от установленных параметров запускаем одну из трех последовательностей.  Вся последовательность действий для каждого из движков была взята из статьи указанной вначале.  Я не буду подробно комментировать таски, в целом их имена отражают суть всех действий.приведём все три варианта: kvmlab/roles/driver_provision/tasks/install_container_d.yml: kvmlab/roles/driver_provision/tasks/install_crio.yml: kvmlab/roles/driver_provision/tasks/install_docker_cri.yml: Так, готово. после этапа установки движка идёт еще один play для localhost для создания снапшота. В целом так же опциональный, можно удалить. Bтак, осталось самое важное, ради чего всё это начиналось. Инициализация кубера! возвращаемся в setup_k8s.yaml и дописываем следующий play. Тут для установки используются две роли (можно было и одной обойтись но так нагляднее). Начнем пожалуй с all‑in‑one варианта установки, он самый простой: roles/k8s_all_in_one/tasks/all_in_one.yml: Что в нем происходит. Проверяем есть ли файл конфига. логика проста, если файл есть то с большой долей вероятности инициализация уже была и отчасти успешна. в этом случае если не работает, то лучше убить ноду и собрать заново. Если же файла нет, то в зависимости от движка идёт команда инициализации (для докера она идёт с доп параметрами). Устанавливается сетевой плагин, снимаются ограничения и проверяется установка. Всё, стенд готов. Теперь давай пробежимся по ha_cluster. Тут всё немного сложнее. Первое что надо сделать это подготовить ноды, а именно настроить keepalived и haproxy, для обеспечения отказоустойчивости и балансировки нагрузки. roles/k8s_ha_cluster/tasks/ha_cluster_prepare_managers.yml Вторым шагом удет установка первой ноды. важный процесс, ибо после инициализации кубера он выдает команды для добавления новых хостов, которые нам надо будет передать на выполнение следующим нодам. В целом суть та же, проверяем конфиг, если его нет, то делаем инициализацию. для docker команда чуть побольше. После инициализации фильтруем вывод регуляркой и сохраняем для передачи остальным нодам. экспортируем конфиг, устанавливаем сетевой плагин и идём дальше. После успешной инициализации кластера и получения команд для добавления нод, мы используем эти команды чтобы добавить управляющие и рабочие ноды.  И снова ветвление ибо у докера есть доп параметры при установке. Есть нюанс, управляющие ноды иногда по неизвестной мне причине не добавлялись. при этом при повторном запуске команды всё проходило нормально. Поэтому я добавил 5 попыток подключения. обычно хватает двух. С воркерами такого не наблюдалось, однако я всё равно добавил те же 5 попыток. Воркер или управляющая нода определяется из группы в inventory. Готово, перезагружаем все машины и ждем загрузки. Последний play скопирует конфиг с первой ноды на вашу локальную машину. чтобы можно было управлять кластером непосредственно с хоста. он так же опционален, можно просто зайти на первую ноду и запускать деплои оттуда. Бонусом идёт удаление стенда. раз он быстро создаётся то должен быстро и исчезать. Удаляются только ВМ их диски и снапшоты, шаблоны и образы остаются в каталогах хранения. remove_stand.yml: В целом всё готово. можно запускать. Установка стенда: Удаление стенда: В общем и целом я просто перенёс готовый гайд на рельсы автоматизации, отсебятины я добавил по минимуму. где то иначе добавляются репозитории и ключи, где то запускаю синхронизацию времени, из за того что при восстановлении со снапшота у меня начинались проблемы с ключами из за неверной текущей даты. Добавляю ссылку на репозиторий со всем этим добром.  В решении я попробовал много различных элементов управления ansible, создание каталогов, циклы, ветвления, установки и прочие кирпичи из которых вырастает система. Буду рад если вы подскажете какие решения были удачными, а какие не очень. эта информация будет очень полезна для меня. Спасибо что осилили и прочли до конца!)  Отдельное спасибо @imbasoft за отличную и понятную статью.  Системный Администратор