ALT Container OS подветка K8S. Создание HA кластера: различия между версиями
Kaf (обсуждение | вклад) |
Kaf (обсуждение | вклад) |
||
Строка 404: | Строка 404: | ||
==== Конфигурирование и запуск мастер-узлов ==== | ==== Конфигурирование и запуск мастер-узлов ==== | ||
===== Создание butane-YML файлов описания конфигурации | ===== Создание butane-YML файлов описания конфигурации master-узлов ===== | ||
YML-файл для первого узла ''worker01'': | |||
variant: fcos | |||
version: 1.3.0 | |||
ignition: | |||
config: | |||
merge: | |||
- local: users.ign | |||
- local: hosts.ign | |||
- local: btrfs.ign | |||
- local: k8senv.ign | |||
- local: initk8s.ign | |||
storage: | |||
files: | |||
- path: /etc/hostname | |||
overwrite: true | |||
contents: | |||
inline: | |||
master01 | |||
- path: /etc/systemd/network/20-wired.network | |||
overwrite: true | |||
contents: | |||
inline: | | |||
[Match] | |||
Name=eth0 | |||
[Network] | |||
DHCP=no | |||
Address=10.150.0.161/24 | |||
Gateway=10.150.0.1 | |||
DNS=10.150.0.1 | |||
В элементе ''ignition.config.merge'' описываются ignition-файлы сгенерированные командой ''butane'' из вышеперечисленных YML_файлов. | |||
В файле ''/etc/hostname'' указывается имя узла ''master01''. | |||
В файле ''/etc/systemd/network/20-wired.network'' описываются адрес ''Address'' узла, шлюз ''Gateway'' и ''DNS'' для узла. | |||
Остальные YML-файлы конфигурации master-узлов ''master_02.yml'', ''master_03.yml'' описываются схожим образом за исключением: | |||
* файл описания сервиса ''local: initk8s.ign'' можно не подключать, так как инициализация кластера производится с узла ''master01''; | |||
* в файле ''/etc/hostname'' указываются имена узлов ''master01'' и ''master02'' соответственно; | |||
* в файле '/etc/systemd/network/20-wired.network'' в поле ''Address'' указываются IP-адреса master-узлов ''10.150.0.162'' и ''10.150.0.163'' соответственно. | |||
===== Скрипт запуска master и worker узлов ===== | ===== Скрипт запуска master и worker узлов ===== |
Версия от 15:36, 17 декабря 2021
Создание высоко-доступного (Highly Available) kubernetes-кластера с несколькими мастерами (control plane) в среде libvirt
Создание ethernet-моста (bridge)
Для выделения IP-адресов узлов кластера в рамках IP-адресов локальной сети необходимо в интерфейсе создания сетевых интерфейсов
создать в HOST-системе создать мост (например br0) и связать с ним основной ethernet-интерфейс локальной сети.
В нашем примере примем IP-адрес HOST-системы - 10.150.0.4/24 в подсети 10.150.0.0/24.
В дальнейшем при создании виртуальных машин в пункте конфигурирования сетевого интерфейса укажите:
- Создать на базе: Устройство моста
- Название устройства: br0
- Состояние связи: активно
При развертывания виртуальных машин им будут присваиваться статические адреса из подсети 10.150.0.0/24.
Конфигурирование параметров ядра
Проверьте в sysctl настройку переменных ядра :
sysctl -a | grep net.bridge.bridge-nf-call net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0
Перечисленные переменные должны иметь нулевое значение, иначе связь между виртуальными машинами не поддерживается.
Если вывод команду пустой, подключите модуль br_netfilter:
modprobe br_netfilter
и обеспечьте загрузку этого модуля после перезагрузки.
Если часть переменных имеет ненулевые значения, сформируйте файл /etc/sysctl.d/99-sysctl.conf:
# # Configure kernel parameters at boot. # See sysctl.d(5) for more details. # net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0
и запустите команду:
sysctl -f /etc/sysctl.d/99-sysctl.conf
Конфигурирование балансировшика
Для работы высоко-доступного (Highly Available) kubernetes-кластера необходимо на всех трех узлах поднять балансировщик, распределяющий входящие запросы между мастер-узлами кластера. Для поддержки отказоустойчивости самого балансировщика создают несколько HOST-систем на которых запускают балансировщики разделяющий один общий виртуальный адрес. В данном примере мы будем использовать один балансировщик, располагающийся в HOST-системе.
Для создания балансировщика установите пакеты:
apt-get install haproxy keepalived
Конфигурирование haproxy
Создайте файл конфигурации haproxy /etc/haproxy/haproxy.cfg:
# /etc/haproxy/haproxy.cfg #--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global log /dev/log local0 log /dev/log local1 notice daemon #--------------------------------------------------------------------- # common defaults that all the 'listen' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode http log global option httplog option dontlognull option http-server-close option forwardfor except 127.0.0.0/8 option redispatch retries 1 timeout http-request 10s timeout queue 20s timeout connect 5s timeout client 20s timeout server 20s timeout http-keep-alive 10s timeout check 10s #--------------------------------------------------------------------- # apiserver frontend which proxys to the control plane nodes #--------------------------------------------------------------------- frontend apiserver bind *:8443 mode tcp option tcplog default_backend apiserver #--------------------------------------------------------------------- # round robin balancing for apiserver #--------------------------------------------------------------------- backend apiserver option httpchk GET /healthz http-check expect status 200 mode tcp option ssl-hello-chk balance roundrobin server master01 10.150.0.161:6443 check server master02 10.150.0.162:6443 check server master03 10.150.0.163:6443 check
В секции balance roundrobin укажите список имен, IP-адресов и портов 6443 API-интерфейсов мастер-узлов.
HAPROXY будет принимать входящие соединения на порту 8443 и передавать их на один из перечисленных master-серверов на порт 6443.
Конфигурирование keepalived
Создайте файл конфигурации 'keepalived' /etc/keepalived/keepalived.conf:
! /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { router_id LVS_K8S } vrrp_script check_apiserver { script "/etc/keepalived/check_apiserver.sh" interval 3 weight -2 fall 10 rise 2 } vrrp_instance VI_1 { state MASTER interface br0 virtual_router_id 51 priority 101 authentication { auth_type PASS auth_pass 42 } virtual_ipaddress { 10.150.0.160 } track_script { check_apiserver } }
На одном из узлов установите параметр state в значение MASTER и параметр priority в значение 101. На остальных параметр state в значение BACKUP и параметр priority в значение 100.
Скрипт /etc/keepalived/check_apiserver.sh проверят доступность балансировщика 'haproxy':
#!/bin/sh errorExit() { echo "*** $*" 1>&2 exit 1 } APISERVER_DEST_PORT=8443 APISERVER_VIP=10.150.0.160 curl --silent --max-time 2 --insecure https://localhost:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://localhost:${APISERVER_DEST_PORT}/" if ip addr | grep -q ${APISERVER_VIP}; then curl --silent --max-time 2 --insecure https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/ -o /dev/null || errorExit "Error GET https://${APISERVER_VIP}:${APISERVER_DEST_PORT}/" fi
Параметр APISERVER_DEST_PORT задает порт балансировщиков haproxy, параметр APISERVER_VIP виртуальный адрес, через который будут взаимодействовать master (control plane) узлы кластера k8s.
Скрипт проверяет работоспособность haproxy на локальной машине. А если в настоящее время виртуальный адрес принадлежит текущему узлу, то и работоспособность haproxy через виртуальный адрес.
Добавьте флаг на выполнение скрипта:
chmod a+x /etc/keepalived/check_apiserver.sh
При работающем балансировщики скрипт должен завершаться с кодом 0.
Запуск сервисов
Для запуска сервисов наберите команды:
systemctl enable haproxy --now systemctl enable keepalived --now
Так как master-узлы k8s еще не подняты haproxy выведет на консоль сообщение
haproxy[nnnn]: backend apiserver has no server available!
Конфигурирование и запуск кластера
Описание базовых butane YML-файлов
На основе базовых butane YML-файлов программой butane создаются ignition-файлы, используемые для создания конечных 'master_NN.ign', 'worker_NN.jgn' ignition-файлов для разворачивания master и worker узлов кластера.
Файл users.yml описания пользователя altcos
yml описания пользователя altcos имеет следующую структуру:
variant: fcos version: 1.3.0 passwd: users: - name: altcos groups: - wheel - docker password_hash: ... ssh_authorized_keys: - ssh-rsa ... - ssh-rsa ... storage: files: - path: /etc/sudoers.d/altcos contents: inline: | altcos ALL=NOPASSWD: ALL
В поле password_hash помещается хеш-пароля, сгенерированный командой
mkpasswd --method=yescrypt
В поле ssh_authorized_keys массив открытых ключей пользователей для которых необходим беспарольный доступ к пользователю altcos виртуалной машины.
В файл /etc/sudoers.d/altcos записывается строка, обеспечивающая беспарольный доступ пользователя altcos к sudo.
Файл hosts.yml описания имен и IP-адресов узлов
Файл hosts.yml содержит строки привязки имен и IP-адресов виртуальных машин в файле /etc/hosts:
variant: fcos version: 1.3.0 storage: files: - path: /etc/hosts append: - inline: | 10.150.0.161 master01 10.150.0.162 master02 10.150.0.163 master03 10.150.0.171 worker01 10.150.0.172 worker02 10.150.0.173 worker03
Файл btrfs.yml инициализации btrfs тома
variant: fcos version: 1.3.0 storage: disks: - device: /dev/sdb # создадим на диске /dev/sdb партицию /dev/sdb1 wipe_table: true partitions: - number: 1 label: docker filesystems: - device: /dev/sdb1 # создадим в партиции /dev/sdb1 файловую систему BTRFS format: btrfs wipe_filesystem: true label: docker with_mount_unit: false directories: - path: /var/mnt/docker # создадим каталог монтирования тома overwrite: true files: - path: /etc/fstab # добавим строку монтирования btrfs-тома на каталог /var/mnt/docker append: - inline: | LABEL=docker /var/mnt/docker btrfs defaults 0 2 # заменим в конфигурации dockerd-демона: # тип storage-driver с overlay2 на btrfs # изменим каталог размещения данных docker-демона с /var/lib/docker на /var/mnt/docker/docker/ - path: /etc/docker/daemon.json overwrite: true contents: inline: | { "init-path": "/usr/bin/tini", "userland-proxy-path": "/usr/bin/docker-proxy", "default-runtime": "docker-runc", "live-restore": false, "log-driver": "journald", "runtimes": { "docker-runc": { "path": "/usr/bin/runc" } }, "default-ulimits": { "nofile": { "Name": "nofile", "Hard": 64000, "Soft": 64000 } }, "data-root": "/var/mnt/docker/docker/", "storage-driver": "btrfs" } # заменим в конфигурации CRI-O, podman: # тип driver с overlay2 на btrfs # изменим каталог размещения данных docker-демона с /var/lib/containers/storage на /var/mnt/docker/containers/storage - path: /etc/containers/storage.conf overwrite: true contents: inline: | [storage] driver = "btrfs" runroot = "/var/run/containers/storage" graphroot = "/var/mnt/docker/containers/storage" [storage.options] additionalimagestores = [ ] [storage.options.overlay] mountopt = "nodev,metacopy=on"
Файл initk8s.yml описания сервиса инициализации кластера k8s
Файл описывает сервис initk8s инициализации кластера и может быть включен только в YML-файл 1-го master-узла кластера master01.
variant: fcos version: 1.3.0 systemd: units: - name: initk8s.service enabled: false contents: | [Unit] Description=Start up kubernetes in master mode After=crio.service kube-proxy.service kubelet.service systemd-networkd.service systemd-resolved.service [Service] Type=oneshot RemainAfterExit=yes Environment="KUBECONFIG=/etc/kubernetes/admin.conf" ExecStartPre=loadDockerArchiveImages.sh ExecStart=kubeadm init --cri-socket=/var/run/crio/crio.sock \ --pod-network-cidr=10.244.0.0/16 \ --ignore-preflight-errors=SystemVerification \ --kubernetes-version=v1.20.12 \ --control-plane-endpoint 10.150.0.160:8443 \ --upload-certs [Install] WantedBy=multi-user.target
Если вы разворачиваете кластер в локальной сети без доступа или с низкоскоростным доступом в Интернет, то необходимо:
- оставить вызов скрипта loadDockerArchiveImages.sh разворачивания архивов docker-образов, хранящихся в ostree-образе;
- указать версию 'kubernetes' в параметре kubernetes-version (версию можно узнать вызвав команду rpm -qa --dbpath /lib/rpm/ | grep kubernetes или kubectl version);
Если Вы планируете загрузить docker-образы из Интернет, то ExecStartPre и --kubernetes-version= можно удалить.
В отличие от варианта разворачивания кластера с одним master-узлом в команду kubeadm init добалены параметры:
- control-plane-endpoint в котором указан URL основного haproxy-сервера, работающего на виртуальном адресе 10.150.0.160 и предоставляющий доступ на порту 8443.
- upload-certs, обеспечивающий загрузку сгенерированных сертификатов и раздачу их другим master-узлам.
Файл k8senv.yml создание profile инициализации kubernetes-среды
variant: fcos version: 1.3.0 storage: files: - path: /etc/profile.d/kube.sh mode: 0755 contents: inline: | # Set kube environment if [ `id -u ` = 0 ] then export KUBECONFIG=/etc/kubernetes/admin.conf else if [ -f /etc/kubernetes/admin.conf ] then if [ ! -d ~/.kube ] then mkdir -p ~/.kube sudo cp -i /etc/kubernetes/admin.conf ~/.kube/config sudo chown $(id -u):$(id -g) ~/.kube/config kubectl completion bash >> ~/.bashrc fi fi fi
Файл обеспечивает создание профайла /etc/profile.d/kube.sh. Для привелигированного пользователя (sudo -i bash) в среду добавляется переменная KUBECONFIG. Для непривилигиванного формирование каталога .kube.
Файл mastersUsers.yml описания открытых ключей мастер-узлов кластера
Данный файл обеспечивает под пользователем altcos беспарольный доступ с master-узлов на 'worker'-узлы. Структура файла следующая:
variant: fcos version: 1.3.0 passwd: users: - name: altcos ssh_authorized_keys: - ssh-rsa ... altcos@master01 - ssh-rsa ... altcos@master02 - ssh-rsa ... altcos@master03
В него помещаются открытые ключи пользователей altcos master-узлов.
Конфигурирование и запуск мастер-узлов
Создание butane-YML файлов описания конфигурации master-узлов
YML-файл для первого узла worker01:
variant: fcos version: 1.3.0 ignition: config: merge: - local: users.ign - local: hosts.ign - local: btrfs.ign - local: k8senv.ign - local: initk8s.ign storage: files: - path: /etc/hostname overwrite: true contents: inline: master01 - path: /etc/systemd/network/20-wired.network overwrite: true contents: inline: | [Match] Name=eth0 [Network] DHCP=no Address=10.150.0.161/24 Gateway=10.150.0.1 DNS=10.150.0.1
В элементе ignition.config.merge описываются ignition-файлы сгенерированные командой butane из вышеперечисленных YML_файлов.
В файле /etc/hostname указывается имя узла master01. В файле /etc/systemd/network/20-wired.network описываются адрес Address узла, шлюз Gateway и DNS для узла.
Остальные YML-файлы конфигурации master-узлов master_02.yml, master_03.yml описываются схожим образом за исключением:
- файл описания сервиса local: initk8s.ign можно не подключать, так как инициализация кластера производится с узла master01;
- в файле /etc/hostname указываются имена узлов master01 и master02 соответственно;
- в файле '/etc/systemd/network/20-wired.network в поле Address указываются IP-адреса master-узлов 10.150.0.162 и 10.150.0.163 соответственно.