Привет, я Кирилл Шаталаев, инженер инфраструктуры и автоматизации в X5 Tech.

Я в курсе, что статей на эту тему достаточно, в том числе и на Habr. И когда у меня возникла задача поднять кластер, я их все перечитал. Где-то очень подробно рассказывается, как ставить виртуалки с убунтой на Windows под virtualbox, и очень скудно про сам кубер. Где-то досконально описано, как это всё круто можно провернуть с terraform в Яндекс.Облаке. Где-то про сам kubespray скупо пару слов, зато куча скриншотов прометея с кибаной.

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

Небольшое введение

В настоящее время существует большое количество способов поднять локальный kubernetes быстро и грязно. Официальная документация рекомендует использовать для этого minikube. Canonical продвигает свой MicroK8s. Есть ещё k0s, k3s, kind — в общем, инструменты на любой вкус.

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

Тут выход один — поднять нормальный кластер на виртуалках.

Плюсов такого решения — масса. Можно играться с кластером как угодно, делать с нодами drain и cordon, ковыряться с LoadBalancer, можно имитировать сетевые проблемы и смотреть, что будет происходить с kubernetes при этом. Можно даже поднять рядом в виртуалке, допустим, Gitlab CE, подцепить к нему ваш кластер и обкатывать CI/CD.

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

Краткое описание решения

Виртуальные машины:

Мастер-ноды - 2 ядра, 4 Гб памяти, 20 Гб HDD

master0 — 192.198.122.10

master1 — 192.168.122.11

master2 — 192.168.122.12

Воркер-ноды - 4 ядра, 16 Гб памяти, 20 Гб HDD

worker0 — 192.198.122.20

worker1 — 192.168.122.21

worker2 — 192.168.122.22

ОС - Ubuntu 20.04.3

Инструмент разворачивания кластера — kubespray

Инструменты управления кластером (локальные) — kubectl, k9s

Шаг 1. Гипервизор

Я кратко опишу развёртывание виртуалок на моей локальной машине при помощи qemu и virt-manager. Если вы предпочитаете другой гипервизор, у вас уже есть виртуалки где-то в облаке или у вас есть, ну, я не знаю, отдельный сервер proxmox для экспериментов — пропустите шаги 1 и 2 и делайте по-своему.

Хост-система - Ubuntu 20.04, CPU AMD Ryzen 7 3700X, оперативной памяти - 128 Гб. Конфигурация средняя, за исключением памяти (да, я маньяк) — но память нынче дёшевая, в отличие от видеокарт. Плюс ко всему, с учётом аппетита современных приложений, многие уже 32Гб считают минимально достаточным количеством оперативки. Хотя лучше в наших реалиях всё же иметь 64Гб.

Устанавливаем необходимые пакеты:

sudo apt install qemu qemu-kvm libvirt-clients libvirt-daemon-system virtinst bridge-utils virt-manager libguestfs-tools

Добавляем себя в группу kvm, чтобы управлять виртуалками без использования прав суперпользователя:

sudo usermod -aG kvm ksh

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

Ключевой момент тут один — виртуальная сеть.

При установке libvirt уже создана виртуальная сеть default, которая при помощи NAT транслирует трафик виртуальных машин во внешнюю сеть. Виртуалки гостей при этом цепляются к bridge-интерфейсу хоста. Хост также выполняет роль DHCP и DNS-серверов. Для этих целей выделена подсеть 192.168.122.0/24, адрес 192.168.122.1 назначается на bridge-интерфейс хоста, этот адрес является шлюзом по умолчанию и основным DNS-сервером для виртуалок.

Все интерфейсы наших виртуалок, подключенных к одной виртуальной сети, находятся в одном l2-сегменте. Эта информация нам важна для будущей настройки балансировщика.

Вы также можете настроить новые виртуальные сети, можете сделать их маршрутизируемыми или даже связать сеть с физическим интерфейсом хоста (в этом случае виртуалки будут подключены ко внешней сети напрямую). В рамках данной задачи это нам не нужно.

Шаг 2. Создание виртуальных машин

Мы сделаем только первую виртуалку master0, а затем просто склонируем её.

Создаётся машина вообще проще простого, я сделал несколько скриншотов в важных моментах.

Важные моменты при установке системы

Установка завершена, дальше дожидаемся перезагрузки и добавляем на машину свой ssh-ключ и пробуем зайти на неё по ssh:

ssh-copy-id user@192.168.122.10
ssh user@192.168.122.10

На свежесозданной виртуалке добавляем наш ключ к учетной записи root:

sudo cp /home/user/.ssh/authorized_keys /root/.ssh/

Выходим и пробуем зайти под root по ssh. Должно пустить.

ssh root@192.168.122.10

После этих тривиальных настроек мы выключаем нашу виртуалку и приступаем к клонированию.

Теперь важный момент номер два — клонирование создаёт полную копию машины, со всеми ключами, UUID и прочим. Чтобы заново инициализировать каждую из виртуалок, выполняем команду virt-sysprep для склонированной виртуалки:

virt-sysprep --operations defaults,-ssh-userdir,customize -d k8s-master-1

пустит, т.к. предыдущая команда снесла все ключи, а как заставить sysprep сгенерировать их сразу, я не нашёл).

Выполняем команды:

sudo ssh-keygen -A
sudo systemctl restart sshd

Проверяем, что сервер ssh успешно запущен:

systemctl status sshd

Последним этапом мы меняем IP в настройках сетевого интерфейса и устанавливаем правильный hostname

Настройки сети содержатся в файле /etc/netplan/00-installer-config.yaml

network:
  ethernets:
    enp1s0:
      addresses:
      - 192.168.122.10/24
      gateway4: 192.168.122.1
      nameservers:
        addresses:
        - 192.168.122.1
        search:
        - k8s-lab.internal
  version: 2

Здесь нам нужно поменять единственную строчку - ip-адрес с 192.168.122.10/24 на 192.168.122.11/24

sudo sed -i 's/192.168.122.10\/24/192.168.122.11\/24/' /etc/netplan/00-installer-config.yaml

На всякий случай проверяем содержимое файла, после чего выполняем команду:

sudo netplan apply

В завершение — hostname:

sudo hostnamectl set-hostname master1
sudo sed -i 's/master0/master1/' /etc/hosts

Перезагружаем виртуалку и пробуем залогиниться под root:

ssh root@192.168.122.11

Дальше повторяем эту процедуру для оставшихся нод — master2, worker0, worker1, worker2. Не забудьте, что для worker-нод надо будет установить нужное количество ядер и памяти. Делается это элементарно — через интерфейс управления виртуальными машинами.

Да, такие вещи неплохо автоматизировать, но мне не пришло в голову сходу, как это сделать. Конечно, можно было использовать для этих целей vagrant, но не хотелось, так как там куча своих заморочек и в итоге потратил бы гораздо больше времени. Если у вас есть идеи — буду рад услышать в комментариях.

Шаг 3. Собственно кубер

Кубер мы будем разворачивать при помощи kubespray. Это набор ansible-ролей, которые позволяют с минимальными усилиями получить готовый продакшн кластер. Тут всё ещё проще.

Ещё раз обращаю внимание, что дополнительно ничего на машинах делать не надо — ни править hosts, ни отключать swap. Достаточно стандартной установки дистрибутива. Обо всём позаботится kubespray.

Клонируем себе репозиторий:

git clone https://github.com/kubernetes-sigs/kubespray.git && cd kubespray

На момент написания статьи стабильный выпуск у нас 2.17.1. В репозитории релизы отмечены соответствующими тегами:

git checkout v2.17.1

Репозиторий содержит образец конфигурации в директории inventory/sample. Мы создадим копию и будем её портить.

cp -rfp inventory/sample inventory/lab

Итак, первый файл, который нам нужно исправить — это inventory.ini. В принципе, он снабжён комментариями и понятен.

Приводим его к следующему виду. Тут всё ясно — определяем, кто у нас будет мастером, а кто воркером:

[all]
master0 ansible_host=192.168.122.10 ansible_user=root etcd_member_name=etcd0
master1 ansible_host=192.168.122.11 ansible_user=root etcd_member_name=etcd1
master2 ansible_host=192.168.122.12 ansible_user=root etcd_member_name=etcd2
worker0 ansible_host=192.168.122.20 ansible_user=root
worker1 ansible_host=192.168.122.21 ansible_user=root
worker2 ansible_host=192.168.122.22 ansible_user=root

[kube_control_plane]
master0
master1
master2

[etcd]
master0
master1
master2

[kube_node]
worker0
worker1
worker2

[calico_rr]

[k8s_cluster:children]
kube_control_plane
kube_node
calico_rr

Теперь, собственно, настройки кластера. Я укажу те переменные, которые нужно поменять.

inventory/lab/group_vars/k8s_cluster/k8s-cluster.yml

Здесь меняем только одну переменную для того, чтобы работал балансировщик:

kube_proxy_strict_arp: true

inventory/lab/group_vars/k8s_cluster/addons.yml

Включаем метрики:

metrics_server_enabled: true
metrics_server_kubelet_insecure_tls: true
metrics_server_metric_resolution: 15s
metrics_server_kubelet_preferred_address_types: "InternalIP"

Включаем nginx ingress controller:

ingress_nginx_enabled: true
ingress_nginx_host_network: false
ingress_publish_status_address: ""
ingress_nginx_nodeselector:
  kubernetes.io/os: "linux"
ingress_nginx_namespace: "ingress-nginx"
ingress_nginx_insecure_port: 80
ingress_nginx_secure_port: 443
ingress_nginx_configmap:
  map-hash-bucket-size: "128"
  ssl-protocols: "TLSv1.2 TLSv1.3"

Включаем MetalLB. Для балансировщика выделяем диапазон IP из нашей виртуальной сети default:

metallb_enabled: true
metallb_speaker_enabled: true
metallb_ip_range:
   - "192.168.122.50-192.168.122.99"

Provisioning для PV не включаем. Можно это сделать потом, по желанию, но надо поменять конфигурацию ваших нод и сделать хотя бы одну с достаточным дисковым пространством.

Можно поднимать кластер.

Команды такие:

mkdir venv
python3 -m venv ./venv
source ./venv/bin/activate
pip install -r requirements.txt
ansible-playbook -i ./inventory/lab/inventory.ini --become --become-user=root cluster.yml

Роль должна отработать без всяких ошибок. По времени это занимает минут 15.

Проверяем, что всё поднялось. Заходим на любую из мастер-нод и выполняем:

root@master0:~# kubectl get nodes
NAME      STATUS   ROLES                  AGE     VERSION
master0   Ready    control-plane,master   15m     v1.21.6
master1   Ready    control-plane,master   15m     v1.21.6
master2   Ready    control-plane,master   15m     v1.21.6
worker0   Ready    <none>                 15m     v1.21.6
worker1   Ready    <none>                 15m     v1.21.6
worker2   Ready    <none>                 15m     v1.21.6

Отлично, кластер работает. Утаскиваем себе на локальную машину kubeconfig:

scp root@192.168.122.10:/root/.kube/config /tmp/kubeconfig

На локальной машине в файле меняем строчку:

server: https://127.0.0.1:6443

На:

server: https://192.168.122.10:6443

Дальше либо копируем его себе в ~/.kube/ целиком, либо правим существующий там файл, если есть уже настроенные кластеры. И пробуем приконнектиться, например, k9s

Шаг 4 — последние штрихи

Теперь несколько неочевидный момент.

kubespray выкатывает ingress-nginx в виде daemonset-а. Как известно, в kubernetes есть разные способы публикации сервисов. Можно было не заморачиваться и включить в файле inventory/lab/group_vars/k8s_cluster/addons.yml

ingress_nginx_host_network: true

но это некрасиво. Красиво — это MetalLB в режиме Layer2. Почти как на настоящем продакшне.

Как работает MetalLB? Если коротко, он берёт адрес из указанного ему диапазона, назначает его одной из нод и сообщает об этом окружающим посредством ARP (может и по BGP, но это не для игрушечных кластеров). Все запросы, приходящие на заданный адрес, он направляет соответствующему сервису kubernetes. Если нода внезапно подохнет, то MetalLB переназначает IP другой ноде.

Создаём манифест под названием ingress-nginx-service.yaml со следующим содержимым:

apiVersion: v1
kind: Service
metadata:
  annotations:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  loadBalancerIP: 192.168.112.50
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
      appProtocol: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
      appProtocol: https
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

И применяем его:

kubectl apply -f ingress-nginx-service.yaml

Проверяем:

kubectl get svc ingress-nginx-controller --namespace ingress-nginx
NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE
ingress-nginx-controller   LoadBalancer   10.233.55.8   192.168.112.50   80:31783/TCP,443:31029/TCP   5m

curl -I http://192.168.112.50
HTTP/1.1 404 Not Found
Date: Thu, 23 Dec 2021 13:21:35 GMT
Content-Type: text/html
Content-Length: 146
Connection: keep-alive

Nginx отвечает по указанному адресу.

А если нужно что-то поменять?

В большинстве случаев меняете соответствующие переменные и запускаете роль снова. Повторный прогон kubespray кластер не сломает.

Заключение

Надеюсь, статья вам поможет, и вы потратите на задачу «поднять кластер на поиграться» не так много времени, сколько пришлось потратить мне.