Меня заинтересовала тема 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 и файл с переменными которыми мы будем управлять развёртыванием. Ну и конечно же роли.
В каталоге выполним, для создания ролей.
ansible-galaxy role init vm_provision
ansible-galaxy role init driver_provision
ansible-galaxy role init k8s_ha_cluster
ansible-galaxy role init k8s_all_in_oneФайл inventory описывает наши ansible_host для подключения:
all:
children:
management:
hosts:
node1:
ansible_host: 172.30.0.201
node2:
ansible_host: 172.30.0.202
node3:
ansible_host: 172.30.0.203
workers:
hosts:
node4:
ansible_host: 172.30.0.204
node5:
ansible_host: 172.30.0.205my_vars.yml как видно из названия описывает переменные, параметры развертывания, параметры виртуальных машин, каталоги хранения iso и дисков VM:
variant: all-in-one #[all-in-one, ha-cluster]
engine: cri-o #[container-d, cri-o, docker]
libvirt_pool_dir: "/home/alex/myStorage/storage_for_VMss"
libvirt_pool_images: "/home/alex/myStorage/iso_imagess"
vm_net: k8s_net
ssh_key: "/home/alex/.ssh/id_rsa.pub"
ansible_ssh_common_args: "-o StrictHostKeyChecking=no"
version: "1.26"
os: "Debian_11"
vm_info:
vm_names:
- name: node1
memory: 2048
cpu: 2
ipaddr: 172.30.0.201
- name: node2
memory: 2048
cpu: 2
ipaddr: 172.30.0.202
- name: node3
memory: 2048
cpu: 2
ipaddr: 172.30.0.203
- name: node4
memory: 3072
cpu: 4
ipaddr: 172.30.0.204
- name: node5
memory: 3072
cpu: 4
ipaddr: 172.30.0.205Рассмотрим переменные чуть подробнее:
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:
---
- name: Подготовка ВМ к развёртыванию k8s
hosts: localhost
gather_facts: yes
become: yes
tasks:
- name: Подготовка окружения
package:
name:
- libguestfs-tools
- python3-libvirt
state: present
- name: Настройка сети
include_role:
name: vm_provision
tasks_from: create_network.yml
- name: Подготовка шаблона для ВМ
include_role:
name: vm_provision
tasks_from: prepare_images_for_cluster.yml
- name: Создание ВМ нод из шаблонного образа.
include_role:
name: vm_provision
tasks_from: create_nodes.yml
vars:
vm_name: "{{ item.name }}"
vm_vcpus: "{{ item.cpu }}"
vm_ram_mb: "{{ item.memory }}"
ipaddr: "{{ item.ipaddr }}"
with_items: "{{ vm_info.vm_names }}"
when: variant == 'ha-cluster' or (variant == 'all-in-one' and item.name == 'node1')
- name: Ожидание загрузки всех ВМ из списка
wait_for:
host: "{{ hostvars[item].ansible_host }}"
port: 22
timeout: 300
state: started
when: variant == 'ha-cluster' or item == 'node1'
with_items: "{{ groups['all'] }}"
- name: Создаем снимок host_provision
include_role:
name: vm_provision
tasks_from: create_snapshot.yml
vars:
vm_name: "{{ item.name }}"
snapshot_name: "host_provision"
snapshot_description: "Нода подготовлена к установке движка"
when: variant == 'ha-cluster' or item.name == 'node1'
with_items: "{{ vm_info.vm_names }}"Визуально не много, давай разберём что скрывается под include_role.
А под ролью у нас скрывается:
Дефолтные настройки на случай если какие то переменные не заполнены, по иерархии если не ошибаюсь стоят в самом низу, т.е. если эти переменные прилетят откуда от еще, их приоритет будет выше:
kvmlab/roles/vm_provision/defaults/main.yml:
---
# defaults file for vm_provision
base_image_name: debian-11-generic-amd64-20230124-1270.qcow2
base_image_url: https://cdimage.debian.org/cdimage/cloud/bullseye/20230124-1270/{{ base_image_name }}
base_image_sha: 8db9abe8e68349081cc1942a4961e12fb7f94f460ff170c4bdd590a9203fbf83
libvirt_pool_dir: "/var/lib/libvirt/images"
libvirt_pool_images: "/var/lib/libvirt/images"
vm_vcpus: 2
vm_ram_mb: 2048
vm_net: vmnet
vm_root_pass: test123
ssh_key: /root/.ssh/id_rsa.pub2 шаблона:
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:
---
# tasks file vm_provision, создание шаблона ВМ
- name: Создание каталога {{ libvirt_pool_images }} если не существует.
file:
path: "{{ libvirt_pool_images }}"
state: directory
mode: 0755
- name: Скачивание базового образа если его нет в хранилище
get_url:
url: "{{ base_image_url }}"
dest: "{{ libvirt_pool_images }}/{{ base_image_name }}"
checksum: "sha256:{{ base_image_sha }}"
- name: Создание копии базового образа, для шаблона
copy:
dest: "{{ libvirt_pool_images }}/template_with_common_settings.qcow2"
src: "{{ libvirt_pool_images }}/{{ base_image_name }}"
force: no
remote_src: yes
mode: 0660
register: copy_results
- name: Первичная настройка шаблона.
command: |
virt-customize -a {{ libvirt_pool_images }}/template_with_common_settings.qcow2 \
--root-password password:{{ vm_root_pass }} \
--ssh-inject 'root:file:{{ ssh_key }}' \
--uninstall cloud-init \
--run-command 'apt update && apt install -y ntpdate gnupg gnupg2 curl software-properties-common wget keepalived haproxy' \
--append-line '/etc/hosts:172.30.0.201 node1.internal node1\n172.30.0.202 node2.internal node2\n172.30.0.203 node3.internal node3\n172.30.0.204 node4.internal node4\n172.30.0.205 node5.internal node5' \
--run-command 'curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --dearmour -o /etc/apt/trusted.gpg.d/cgoogle.gpg' \
--run-command 'apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"' \
--run-command 'apt update && apt install -y kubeadm kubectl' \
--run-command 'echo 'overlay' > /etc/modules-load.d/k8s.conf && echo 'br_netfilter' >> /etc/modules-load.d/k8s.conf' \
--run-command 'echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1\nnet.ipv4.ip_forward = 1" > /etc/sysctl.d/10-k8s.conf'
when: copy_results is changedОтлично, шаблон готов. далее на очереди создание сети, ибо сеть используется в шаблоне создания ВМ, и если её не будет, то чуда не случится.
Тут все просто, используя virsh мы проверяем создавалась ли сеть ранее. если да, то скипаем, если же нет, то используя шаблон в который будет подставлено имя сети из переменных средствами всё той же virsh будет создана, запущена и выставлена в автозапуск сеть.
kvmlab/roles/vm_provision/tasks/create_network.yml:
---
# tasks file for vm_provision, пересоздание сети
- name: Получение списка сетей KVM
command: virsh net-list --all
register: net_list_output
- name: Проверка наличия сети {{ vm_net }}
shell: echo "{{ net_list_output.stdout }}" | grep -w "{{ vm_net }}"
register: network_check
ignore_errors: true
- name: Создание и настройка сети {{ vm_net }}
block:
- name: Копирование шаблона сети
template:
src: vm_network.xml.j2
dest: /tmp/vm_network.xml
- name: Создание сети {{ vm_net }}
command: virsh net-define /tmp/vm_network.xml
- name: Запуск сети {{ vm_net }}
command: virsh net-start {{ vm_net }}
- name: Автостарт сети {{ vm_net }}
command: virsh net-autostart {{ vm_net }}
when: network_check.rc != 0Так. Шаблон ВМ есть, сеть есть. Ничего не мешает нам создать ноду или ноды:
Создание нод запускается циклом по переменным. (vm_info.vm_names)
ноды создаются по одной и проходят следующие этапы:
Опять же создается каталог для хранения дисков виртуальных машин, если он не существует.
Каждая машина перед созданием проверяется на наличие её в уже существующих, если она есть, то создание пропускается, так что если у вас осталась машина с прошлого стенда то лучше её пересоздать.
Копируется шаблонный образ диска и переименовывается в соответствии с именем ВМ.
Изменяется размер диска, расширяется до 10 GB, этого объема мне хватило для установки всех вариантов. Значение захардкожено, но при желании его можно так же параметризовать.
Начальное конфигурирование ноды. Тут у нод появляется индивидуальность, имя, ip и свой ssh ключ.
Когда все составные части готовы, создается машина из шаблона xml.
Запуск ВМ.
kvmlab/roles/vm_provision/tasks/create_nodes.yml:
---
# tasks file for vm_provision, создание нод
- name: Создание каталога {{ libvirt_pool_dir }} если не существует.
file:
path: "{{ libvirt_pool_dir }}"
state: directory
mode: 0755
- name: Получаем список существующих ВМ
community.libvirt.virt:
command: list_vms
register: existing_vms
changed_when: no
- name: Создание ВМ если её имени нет в списке
block:
- name: Копирование шаблонного образа в хранилище
copy:
dest: "{{ libvirt_pool_dir }}/{{ vm_name }}.qcow2"
src: "{{ libvirt_pool_images }}/template_with_common_settings.qcow2"
force: no
remote_src: yes
mode: 0660
register: copy_results
- name: Изменение размера виртуального диска
shell: "qemu-img resize {{ libvirt_pool_dir }}/{{ vm_name }}.qcow2 10G"
- name: Начальное конфигурирование hostname:{{ vm_name }}, ip:{{ ipaddr }}
command: |
virt-customize -a {{ libvirt_pool_dir }}/{{ vm_name }}.qcow2 \
--hostname {{ vm_name }}.internal \
--run-command 'echo "source /etc/network/interfaces.d/*\nauto lo\niface lo inet loopback\nauto enp1s0\niface enp1s0 inet static\naddress {{ ipaddr }}\nnetmask 255.255.255.0\ngateway 172.30.0.1\ndns-nameservers 172.30.0.1" > /etc/network/interfaces'
--run-command 'ssh-keygen -A'
when: copy_results is changed
- name: Создание ВМ из шаблона
community.libvirt.virt:
command: define
xml: "{{ lookup('template', 'vm-template.xml.j2') }}"
when: "vm_name not in existing_vms.list_vms"
- name: Включение ВМ
community.libvirt.virt:
name: "{{ vm_name }}"
state: running
register: vm_start_results
until: "vm_start_results is success"
retries: 15
delay: 2Отлично, машины созданы. теперь перезагрузим их, дождемся пока все загрузятся и сделаем снапшоты.
kvmlab/roles/vm_provision/tasks/create_snapshot.yml:
---
# tasks file for vm_provision, создание снапшотов
- name: Создание снапшота {{ snapshot_name }}
shell: "virsh snapshot-create-as --domain {{ vm_name }} --name {{ snapshot_name }} --description '{{ snapshot_description }}'"
register: snapshot_create_status
ignore_errors: trueЕсли ничего не забыл, то первый этап выполнен.
У вас есть одна или пять нод, все готовы к дальнейшей работе.
Причем если удалить все ВМ и запустить создание повторно, то из за наличия готового шаблона процесс пройдёт гораздо быстрее.
Отлично. переходим к установке движка:
вернемся в setup_k8s.yaml и добавим следующий play:
- name: Установка движка контейнеризации [cri-o, container-d, docker]
hosts: all
gather_facts: true
become: true
remote_user: root
tasks:
- name: Синхронизация даты/времени с NTP сервером
shell: ntpdate 0.europe.pool.ntp.org
- name: Установка cri-o
include_role:
name: driver_provision
tasks_from: install_crio.yml
when: engine == "cri-o"
- name: Установка container-d
include_role:
name: driver_provision
tasks_from: install_container_d.yml
when: engine == "container-d"
- name: Установка docker cri
include_role:
name: driver_provision
tasks_from: install_docker_cri.yml
when: engine == "docker"В целом всё просто, используем роль driver_provision, но в зависимости от установленных параметров запускаем одну из трех последовательностей.
Вся последовательность действий для каждого из движков была взята из статьи указанной вначале.
Я не буду подробно комментировать таски, в целом их имена отражают суть всех действий.
приведём все три варианта:
kvmlab/roles/driver_provision/tasks/install_container_d.yml:
---
# tasks file for driver_provision, установка container-d
- name: Скачиваем containerd
get_url:
url: "https://github.com/containerd/containerd/releases/download/v1.7.0/containerd-1.7.0-linux-amd64.tar.gz"
dest: "/tmp/containerd-1.7.0-linux-amd64.tar.gz"
- name: Распаковываем архив
unarchive:
src: /tmp/containerd-1.7.0-linux-amd64.tar.gz
dest: /usr/local
copy: no
- name: Удаляем скачаный архив за ненадобностю
file:
path: "/tmp/containerd-1.7.0-linux-amd64.tar.gz"
state: absent
- name: Создание директории для конфигурации containerd
file:
path: /etc/containerd/
state: directory
- name: Проверяем создан ли каталог
stat:
path: /etc/containerd
register: containerd_dir
- name: Создание конфиг файла containerd
become: true
command: "sh -c 'containerd config default > /etc/containerd/config.toml'"
when: containerd_dir.stat.exists
- name: конфигурирование cgroup driver
replace:
path: "/etc/containerd/config.toml"
regexp: "SystemdCgroup = false"
replace: "SystemdCgroup = true"
- name: Скачиваем containerd systemd service file
get_url:
url: "https://raw.githubusercontent.com/containerd/containerd/main/containerd.service"
dest: "/etc/systemd/system/containerd.service"
- name: Скачиваем и устанавливаем runc
get_url:
url: "https://github.com/opencontainers/runc/releases/download/v1.1.4/runc.amd64"
dest: "/usr/local/sbin/runc"
mode: "u+x"
- name: Скачиваем CNI plugins
get_url:
url: "https://github.com/containernetworking/plugins/releases/download/v1.2.0/cni-plugins-linux-amd64-v1.2.0.tgz"
dest: "/tmp/cni-plugins-linux-amd64-v1.2.0.tgz"
- name: Распаковываем CNI plugins archive
unarchive:
src: "/tmp/cni-plugins-linux-amd64-v1.2.0.tgz"
dest: "/opt/cni/bin"
copy: no
- name: Удаляем CNI plugins archive
file:
path: "/tmp/cni-plugins-linux-amd64-v1.2.0.tgz"
state: absent
- name: Перезагрузка systemd
systemd:
daemon_reload: yes
- name: Запуск и активация containerd service
systemd:
name: containerd
state: started
enabled: yeskvmlab/roles/driver_provision/tasks/install_crio.yml:
---
# tasks file for driver_provision, установка cri-o
- name: Установка ключа репозитория cri-o
apt_key:
url: https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/{{ version }}/{{ os }}/Release.key
state: present
- name: Установка репозитория cri-o
apt_repository:
repo: 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/{{ os }}/ /'
filename: devel:kubic:libcontainers:stable.list
- name: Установка репозитория cri-ostable/cri-o
apt_repository:
repo: 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/{{ version }}/{{ os }}/ /'
filename: 'devel:kubic:libcontainers:stable:cri-o:{{ version }}.list'
- name: Установка cri-o
apt:
name: ['cri-o', 'cri-o-runc']
state: latest
- name: Создание каталога /var/lib/crio
file:
path: /var/lib/crio
state: directory
- name: Перезагрузка systemd
systemd:
daemon_reload: yes
- name: запуск служб crio
systemd:
name: crio
enabled: yes
state: startedkvmlab/roles/driver_provision/tasks/install_docker_cri.yml:
---
# tasks file for driver_provision, установка docker + cri
- name: Create directory /etc/apt/keyrings
file:
path: /etc/apt/keyrings
state: directory
mode: '0755'
- name: Add GPG key Docker
ansible.builtin.shell: curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg --yes
- name: Get dpkg architecture
shell: "dpkg --print-architecture"
register: architecture
- name: Get lsb release
shell: "lsb_release -cs"
register: release_output
- name: Add Docker repository
apt_repository:
repo: "deb [arch={{ architecture.stdout_lines | join }} signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/debian {{ release_output.stdout_lines | join }} stable"
state: present
register: docker_repo
- name: Apt Update
ansible.builtin.apt:
update_cache: yes
- name: Install Docker
apt:
name:
- docker-ce
- docker-ce-cli
- containerd.io
- docker-compose-plugin
state: present
- name: Download plugin cri-dockerd
get_url:
url: "https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.1/cri-dockerd-0.3.1.amd64.tgz"
dest: "/tmp/cri-dockerd.tgz"
- name: Unpack cri-dockerd
unarchive:
src: "/tmp/cri-dockerd.tgz"
dest: "/tmp/"
copy: no
- name: Copy unpacked bin cri-dockerd
copy:
dest: "/usr/local/bin/"
src: "/tmp/cri-dockerd/cri-dockerd"
force: no
remote_src: yes
mode: 0660
register: copy_results
- name: change alc on cri-dockerd
file:
path: "/usr/local/bin/cri-dockerd"
mode: "0755"
- name: Download config file on cri-dockerd.service
get_url:
url: "https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.service"
dest: "/etc/systemd/system/cri-docker.service"
- name: Download config file on cri-dockerd.socket
get_url:
url: "https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.socket"
dest: "/etc/systemd/system/cri-docker.socket"
- name: Update cri-docker.service
ansible.builtin.shell: "sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service"
- name: daemon reload
systemd:
daemon_reload: yes
- name: enable cri-docker.service
systemd:
name: cri-docker.service
enabled: yes
state: started
- name: enable cri-dockerd.socket
systemd:
name: cri-docker.socket
enabled: yes
state: startedТак, готово. после этапа установки движка идёт еще один play для localhost для создания снапшота.
- name: Создаем снапшот driver_provision
hosts: localhost
become: yes
tasks:
- name: Создаем снимки
include_role:
name: vm_provision
tasks_from: create_snapshot.yml
vars:
vm_name: "{{ item.name }}"
snapshot_name: "driver_provision"
snapshot_description: "Движок установлен, нода подготовлена к инициализации k8s"
when: variant == 'ha-cluster' or item.name == 'node1'
with_items: "{{ vm_info.vm_names }}"В целом так же опциональный, можно удалить.
Bтак, осталось самое важное, ради чего всё это начиналось.
Инициализация кубера!
возвращаемся в setup_k8s.yaml и дописываем следующий play.
- name: Настройка kubernetes [all-in-one либо ha-cluster]
hosts: all
gather_facts: true
become: true
remote_user: root
tasks:
- name: Установка all-in-one
include_role:
name: k8s_all_in_one
tasks_from: all_in_one.yml
when: variant == "all-in-one" and inventory_hostname == 'node1'
- name: Подготовка нод для ha-cluster
include_role:
name: k8s_ha_cluster
tasks_from: ha_cluster_prepare_managers.yml
when: variant == "ha-cluster"
- name: Установка первой ноды
include_role:
name: k8s_ha_cluster
tasks_from: ha_cluster_first_node.yml
when: variant == "ha-cluster" and inventory_hostname == 'node1' and inventory_hostname in groups['management']
register: first_node_result
- name: Передача команд на остальные ноды
set_fact:
control_plane_join_command: "{{ hostvars['node1']['control_plane_join_command'] }}"
worker_join_command: "{{ hostvars['node1']['worker_join_command'] }}"
when: variant == "ha-cluster" and inventory_hostname != 'node1'
- name: вывод команд подключения
debug:
msg: |
control_plane_join_command: {{ control_plane_join_command }}
worker_join_command: {{ worker_join_command }}
when: variant == "ha-cluster" and inventory_hostname == 'node1'
- name: Использование команды control_plane_join_command
block:
- name: Подключение управляющих нод для ['container-d', 'cri-o']
ansible.builtin.shell:
cmd: "{{ control_plane_join_command }}"
until: result.rc == 0
register: result
retries: 5
delay: 30
when: engine in ['container-d', 'cri-o']
- name: Подключение управляющих нод для docker
ansible.builtin.shell:
cmd: "{{ control_plane_join_command }} --cri-socket unix:///var/run/cri-dockerd.sock"
until: result.rc == 0
register: result
retries: 5
delay: 30
when: engine == 'docker'
when: variant == "ha-cluster" and inventory_hostname != 'node1' and inventory_hostname in groups['management']
- name: Использование команды worker_join_command
block:
- name: Подключение рабочих нод для ['container-d', 'cri-o']
ansible.builtin.shell:
cmd: "{{ worker_join_command }}"
until: result.rc == 0
register: result
retries: 5
delay: 30
when: engine in ['container-d', 'cri-o']
- name: Подключение рабочих нод для docker
ansible.builtin.shell:
cmd: "{{ worker_join_command }} --cri-socket unix:///var/run/cri-dockerd.sock"
until: result.rc == 0
register: result
retries: 5
delay: 30
when: engine == 'docker'
when: variant == "ha-cluster" and inventory_hostname != 'node1' and inventory_hostname in groups['workers']
- name: Скачивание конфига с первой ноды (подходит для обоих вариантов all-in-one и ha-cluster)
ansible.builtin.fetch:
src: /etc/kubernetes/admin.conf
dest: /tmp/
flat: yes
force: yes
when: inventory_hostname == 'node1'
- name: Перезагрузка всех машин
ansible.builtin.reboot:
reboot_timeout: 300Тут для установки используются две роли (можно было и одной обойтись но так нагляднее).
Начнем пожалуй с all‑in‑one варианта установки, он самый простой:
roles/k8s_all_in_one/tasks/all_in_one.yml:
---
- name: Проверка наличия файла конфига
stat:
path: /etc/kubernetes/admin.conf
register: file_info
- name: Инициализация кластера если конфиг не обнаружен.
block:
- name: Инициализация кластера для движков ['container-d', 'cri-o']
shell: kubeadm init --pod-network-cidr=10.244.0.0/16
when: engine in ['container-d', 'cri-o']
register: kubeadm_output
- name: Инициализация кластера для движка docker
shell: |
kubeadm init \
--pod-network-cidr=10.244.0.0/16 \
--cri-socket unix:///var/run/cri-dockerd.sock
when: engine == 'docker'
register: kubeadm_output
- name: Установка KUBECONFIG в enviroment
become: true
lineinfile:
dest: /etc/environment
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'
- name: Установка KUBECONFIG в bashrc
become: true
lineinfile:
dest: '~/.bashrc'
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'
- name: Подождем пока всё запустится
wait_for:
host: localhost
port: 6443
timeout: 300
- name: Установка сетевого плагина Flannel
shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
- name: Снятие ограничения на запуск рабочих нагрузок c {{ ansible_hostname }}
shell: "kubectl taint nodes --all node-role.kubernetes.io/control-plane-"
become:roles/k8s_all_in_one/tasks/all_in_one.yml: true
register: taint_result
failed_when:
- "'error: taint \"node-role.kubernetes.io/control-plane\" not found' not in taint_result.stderr"
- "'node/' + ansible_hostname + '.internal untainted' not in taint_result.stdout"
when: not file_info.stat.exists
- name: Проверка инициализации
shell: "export KUBECONFIG=/etc/kubernetes/admin.conf && kubectl get nodes"
register: kubectl_output
ignore_errors: true
- name: Инициализация завершена.
debug:
msg: 'Инициализация завершена! выполните комманду export KUBECONFIG=/etc/kubernetes/admin.conf, проверьте вывод команды kubectl get nodes'
when: kubectl_output.rc == 0Что в нем происходит.
Проверяем есть ли файл конфига. логика проста, если файл есть то с большой долей вероятности инициализация уже была и отчасти успешна. в этом случае если не работает, то лучше убить ноду и собрать заново.
Если же файла нет, то в зависимости от движка идёт команда инициализации (для докера она идёт с доп параметрами).
Устанавливается сетевой плагин, снимаются ограничения и проверяется установка.
Всё, стенд готов.
Теперь давай пробежимся по ha_cluster.
Тут всё немного сложнее.
Первое что надо сделать это подготовить ноды, а именно настроить keepalived и haproxy, для обеспечения отказоустойчивости и балансировки нагрузки.
roles/k8s_ha_cluster/tasks/ha_cluster_prepare_managers.yml
- name: Синхронизация даты/времени с NTP сервером
shell: ntpdate 0.europe.pool.ntp.org
- name: Копируем настройку демона keepalived
template:
src: templates/keepalived.conf.j2
dest: /etc/keepalived/keepalived.conf
mode: '0644'
- name: Копируем скрипт check_apiserver.sh, предназначенный для проверки доступности серверов.
template:
src: templates/check_apiserver.sh.j2
dest: /etc/keepalived/check_apiserver.sh
mode: '0755'
- name: запуск службы keepalived
systemd:
name: keepalived
enabled: yes
state: restarted
- name: Копируем настройку демона haproxy
template:
src: templates/haproxy.cfg.j2
dest: /etc/haproxy/haproxy.cfg
mode: '0644'
- name: запуск службы haproxy
systemd:
name: haproxy
enabled: yes
state: restartedВторым шагом удет установка первой ноды. важный процесс, ибо после инициализации кубера он выдает команды для добавления новых хостов, которые нам надо будет передать на выполнение следующим нодам.
В целом суть та же, проверяем конфиг, если его нет, то делаем инициализацию. для docker команда чуть побольше.
После инициализации фильтруем вывод регуляркой и сохраняем для передачи остальным нодам. экспортируем конфиг, устанавливаем сетевой плагин и идём дальше.
ha_cluster_first_node.yml:
- name: Проверка наличия файла конфига
stat:
path: /etc/kubernetes/admin.conf
register: file_info
- name: Инициализация кластера если конфиг не обнаружен.
block:
- name: Инициализация кластера для движков ['container-d', 'cri-o']
shell: |
kubeadm init \
--pod-network-cidr=10.244.0.0/16 \
--control-plane-endpoint "172.30.0.210:8888" \
--upload-certs
register: init_output_containerd_crio
when: engine in ['container-d', 'cri-o']
- name: Инициализация кластера для движка ['docker']
shell: |
kubeadm init \
--cri-socket unix:///var/run/cri-dockerd.sock \
--pod-network-cidr=10.244.0.0/16 \
--control-plane-endpoint "172.30.0.210:8888" \
--upload-certs
register: init_output_docker
when: engine == 'docker'
- name: Сохранение значения init_output для дальнейшего использования
set_fact:
init_output: "{{ init_output_containerd_crio if init_output_containerd_crio is defined and init_output_containerd_crio.stdout is defined else init_output_docker }}"
- name: Фильтрация вывода kubeadm init
set_fact:
filtered_output: "{{ init_output.stdout | regex_replace('(\\n|\\t|\\\\n|\\\\)', ' ') }}"
- name: Фильтр комманд для добавления управляющих и рабочих нод
set_fact:
control_plane_join_command: "{{ filtered_output | regex_search('kubeadm join(.*?--discovery-token-ca-cert-hash\\s+sha256:[\\w:]+.*?--control-plane.*?--certificate-key.*?[\\w:]+)')}}"
worker_join_command: "{{ filtered_output | regex_search('kubeadm join(.*?--discovery-token-ca-cert-hash\\s+sha256:[\\w:]+)')}}"
- name: Установка KUBECONFIG в enviroment
lineinfile:
dest: /etc/environment
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'
- name: Установка KUBECONFIG в bashrc
lineinfile:
dest: '~/.bashrc'
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'
- name: Подождем пока всё запустится
wait_for:
host: localhost
port: 6443
timeout: 300
- name: Установка сетевого плагина Flannel
shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
when: not file_info.stat.existsПосле успешной инициализации кластера и получения команд для добавления нод, мы используем эти команды чтобы добавить управляющие и рабочие ноды.
И снова ветвление ибо у докера есть доп параметры при установке.
Есть нюанс, управляющие ноды иногда по неизвестной мне причине не добавлялись. при этом при повторном запуске команды всё проходило нормально. Поэтому я добавил 5 попыток подключения. обычно хватает двух.
С воркерами такого не наблюдалось, однако я всё равно добавил те же 5 попыток.
Воркер или управляющая нода определяется из группы в inventory.
Готово, перезагружаем все машины и ждем загрузки.
Последний play скопирует конфиг с первой ноды на вашу локальную машину. чтобы можно было управлять кластером непосредственно с хоста. он так же опционален, можно просто зайти на первую ноду и запускать деплои оттуда.
- name: Настройка хостовой машины, чтобы не лазить постоянно на виртуальные.
hosts: localhost
gather_facts: false
tasks:
- name: Переместить файл
ansible.builtin.file:
src: /tmp/admin.conf
dest: /etc/kubernetes/admin.conf
state: link
force: yes
become: true
- name: Установка KUBECONFIG в enviroment
lineinfile:
dest: /etc/environment
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'
- name: Установка KUBECONFIG в bashrc
lineinfile:
dest: '~/.bashrc'
line: 'export KUBECONFIG=/etc/kubernetes/admin.conf'Бонусом идёт удаление стенда. раз он быстро создаётся то должен быстро и исчезать.
Удаляются только ВМ их диски и снапшоты, шаблоны и образы остаются в каталогах хранения.
remove_stand.yml:
---
- name: Удаление стенда kubernetes
hosts: localhost
become: trueс
vars_files:
- my_vars.yml
tasks:
- name: Получаем список существующих ВМ
community.libvirt.virt:
command: list_vms
register: existing_vms
changed_when: no
- name: Удаление машин
block:
- name: Полностью останавливаем ВМ
community.libvirt.virt:
command: destroy
name: "{{ item.name }}"
loop: "{{ vm_info.vm_names }}"
when: "item.name in existing_vms.list_vms"
ignore_errors: true
- name: Удаляем снапшоты
shell: |
virsh snapshot-delete --domain {{ item.name }} --snapshotname host_provision
virsh snapshot-delete --domain {{ item.name }} --snapshotname driver_provision
ignore_errors: true
loop: "{{ vm_info.vm_names }}"
when: "item.name in existing_vms.list_vms"
- name: Отменяем регистрацию ВМ
community.libvirt.virt:
command: undefine
name: "{{ item.name }}"
loop: "{{ vm_info.vm_names }}"
when: "item.name in existing_vms.list_vms"
- name: Удаление диска виртуальной машины
ansible.builtin.file:
path: "{{libvirt_pool_dir}}/{{ item.name }}.qcow2"
state: absent
loop: "{{ vm_info.vm_names }}"
when: "item.name in existing_vms.list_vms"В целом всё готово. можно запускать.
Установка стенда:
ansible-playbook -K ./setup_k8s.yaml -i ./inventory --extra-vars "@my_vars.yml"Удаление стенда:
ansible-playbook -K ./remove_stand.ymlВ общем и целом я просто перенёс готовый гайд на рельсы автоматизации, отсебятины я добавил по минимуму. где то иначе добавляются репозитории и ключи, где то запускаю синхронизацию времени, из за того что при восстановлении со снапшота у меня начинались проблемы с ключами из за неверной текущей даты.
Добавляю ссылку на репозиторий со всем этим добром.
В решении я попробовал много различных элементов управления ansible, создание каталогов, циклы, ветвления, установки и прочие кирпичи из которых вырастает система.
Буду рад если вы подскажете какие решения были удачными, а какие не очень. эта информация будет очень полезна для меня.
Спасибо что осилили и прочли до конца!)
Отдельное спасибо @imbasoft за отличную и понятную статью.
say_TT_plz
Приветствую, сам пользуюсь ансиблом, но разворачиваю кубер через rancher. При прочих равных, одна команда для развертывания кластера лучше, чем куча ролей.
Eldalex Автор
Тут я конечно согласен, одна команда всегда веселей) Но у меня была еще и цель потыкать ansible, очень полезный инструмент и мне надо понимать как он работает, примитивы, циклы, переменные и прочее. я почитаю про rancher, посмотрю как работает)