ALT Container OS подветка K8S. Создание HA кластера


ALT Container OS подветка K8S. Создание HA кластера

K8s cluster.png

Vmnetconfig1.png

Для выделения IP-адресов узлов кластера в рамках IP-адресов локальной сети необходимо в интерфейсе создания сетевых интерфейсов создать в HOST-системе создать мост (например br0) и связать с ним основной ethernet-интерфейс локальной сети. В нашем примере примем IP-адрес HOST-системы – 10.150.0.4/24 в подсети 10.150.0.0/24.

В дальнейшем при создании виртуальных машин в пункте конфигурирования сетевого интерфейса укажите:

  • Создать на базе: Устройство моста
  • Название устройства: br0
  • Состояние связи: активно

Vmnetconfig.png

При развертывания виртуальных машин им будут присваиваться статические адреса из подсети 10.150.0.0/24.

Конфигурирование параметров ядра [ править ]

Проверьте в sysctl настройку переменных ядра :

Перечисленные переменные должны иметь нулевое значение, иначе связь между виртуальными может фильтроваться правилами iptables, arptables.

Если вывод команду пустой, подключите модуль br_netfilter:

и обеспечьте загрузку этого модуля после перезагрузки.

Если часть переменных имеет ненулевые значения, сформируйте файл /etc/sysctl.d/99-sysctl.conf:

и запустите команду:

Конфигурирование балансировшика [ править ]

Для работы высоко-доступного (Highly Available) kubernetes-кластера необходимо на всех трех узлах поднять балансировщик, распределяющий входящие запросы между мастер-узлами кластера. Для поддержки отказоустойчивости самого балансировщика на HOST-системах запускаются балансировщики. Одному их балансировщику присваивается виртуальный адрес 10.150.0.160. При выходе из строя или потери доступности основного балансировщика виртуальный адрес присваивается другому доступному балансировщику.

Для создания балансировщика установите пакеты:

Конфигурирование haproxy [ править ]

Создайте файл конфигурации haproxy /etc/haproxy/haproxy.cfg:

В секции balance roundrobin укажите список имен, IP-адресов и портов 6443 API-интерфейсов мастер-узлов.

haproxy будет принимать входящие соединения на порту 8443 и передавать их на один из перечисленных master-серверов на порт 6443.

Конфигурирование keepalived [ править ]

Создайте файл конфигурации ‘keepalived’ /etc/keepalived/keepalived.conf:

На одном из узлов установите параметр state в значение MASTER и параметр priority в значение 101. На остальных параметр state в значение BACKUP и параметр priority в значение 100.

Скрипт /etc/keepalived/check_apiserver.sh проверяет доступность балансировщика haproxy:

Параметр APISERVER_DEST_PORT задает порт балансировщиков haproxy, параметр APISERVER_VIP виртуальный адрес, через который будут взаимодействовать master (control plane) узлы кластера k8s.

Скрипт проверяет работоспособность haproxy на локальной машине. А если в настоящее время виртуальный адрес принадлежит текущему узлу, то и работоспособность haproxy через виртуальный адрес.

Добавьте флаг на выполнение скрипта:

При работающем балансировщике и хотя бы одному доступному порту 6443 на master-узлах скрипт должен завершаться с кодом 0.

Запуск сервисов [ править ]

Для запуска сервисов наберите команды:

Так как master-узлы k8s еще не подняты haproxy выведет на консоль сообщение

Конфигурирование и запуск кластера [ править ]

Получение qcow2 образов ветки kubetnetes [ править ]

В настоящее время реализованы несколько образов QCOW2 подветки altcos/x86_64/Sisyphus/k8s. Скачать последний образ от 23.12.2021 его можно по следующим ссылкам: [Полный] [Сжатый]

Описание базовых butane YML-файлов [ править ]

На основе базовых butane YML-файлов программой butane создаются ignition-файлы, используемые для создания конечных ‘master_NN.ign’, ‘worker_NN.jgn’ ignition-файлов для разворачивания master и worker узлов кластера.

Файл users.yml описания пользователя altcos [ править ]

yml описания пользователя altcos имеет следующую структуру:

В поле password_hash помещается хеш-пароля, сгенерированный командой

В поле ssh_authorized_keys – массив открытых ключей пользователей для которых необходим беспарольный доступ к пользователю altcos виртуалной машины.

В файл /etc/sudoers.d/altcos записывается строка, обеспечивающая беспарольный доступ пользователя altcos к sudo.

Файл hosts.yml описания имен и IP-адресов узлов [ править ]

Файл hosts.yml содержит строки привязки имен и IP-адресов виртуальных машин в файле /etc/hosts:

Файл btrfs.yml инициализации btrfs тома [ править ]

В текущей версии пакета cri-o-1.22.1-alt1.x86_64 файл конфигурации /etc/cni/net.d/100-crio-bridge.conf задает адрес подсети для интерфейса cni0. Для корректной работы сетевого плугина flannel необходимо исключить определение подсети, так как flannel самостоятельно на основе полученной конфигурации сети конфигурирует IP-адрес интерфейса cni0.

Plugin flannel конфигурирования cni-интерфайса в образе rancher/mirrored-flannelcni-flannel-cni-plugin располагается в каталоге /opt/cni/bin/. В обычной Linux-системе при запуске POD’а это plugin копируется в каталог /usr/libexec/cni откуда он загружается plugin’ом CRI (Container Runtime Interface). В ALTCOS каталог /usr смонтирован в режиме только не чтение и копирование не производится. Для решения этой проблемы в подключаемых узлах добавляется файл конфигурации /etc/crio/crio.conf.d/00-btrfs.conf. Он настраивает `cri-o` на использование файловой системы btrfs и в параметре plugin_dirs для подключения plugins кроме стандартного каталога /usr/libexec/cni использует каталог /opt/cni/bin/.

Файл initk8s.yml описания сервиса инициализации кластера k8s с сетью flannel [ править ]

Файл описывает сервис initk8s инициализации кластера и может быть включен только в YML-файл 1-го master-узла кластера master01.

Если вы разворачиваете кластер в локальной сети без доступа или с низкоскоростным доступом в Интернет, то необходимо оставить вызов скрипта loadDockerArchiveImages.sh разворачивания архивов docker-образов, хранящихся в ostree-образе.

Если Вы планируете загрузить docker-образы из Интернет, то строку ExecStartPre можно удалить.

В отличие от варианта разворачивания кластера с одним master-узлом в команду kubeadm init добавлены параметры:

  • control-plane-endpoint в котором указан URL основного haproxy-сервера, работающего на виртуальном адресе 10.150.0.160 и предоставляющий доступ на порту 8443.
  • upload-certs, обеспечивающий загрузку сгенерированных сертификатов и раздачу их другим master-узлам.

Сетевой драйвер flannel обеспечивает выделение адресов для POD’ов и роутинг в рамках подсети 10.244.0.0/16. Данная подсеть при инициализации кластера указывается параметром pod-network-cidr.

При подключении узла к кластеру сетевой драйвер flannel запрашивает у планировщика подсетку “10.244.x.0/24 и согласно полученной подсетке он

  • создает интерфейс flannel.x и присваевает ему адрес “10.244.x.0/32
  • при создании первого POD’а конфирурирует интерфейс cni0 с адресом 10.244.x.1/32.

Все создаваемые на этом узле POD’ы получают IP-адреса 10.244.x.2-255/32.

Файл k8senv.yml создание profile инициализации kubernetes-среды [ править ]

Файл обеспечивает создание профайла /etc/profile.d/kube.sh. Для привелигированного пользователя (sudo -i bash) в среду добавляется переменная KUBECONFIG. Для непривилигиванного пользователя обеспечивается формирование каталога .kube.

Файл mastersUsers.yml описания открытых ключей мастер-узлов кластера [ править ]

Данный файл обеспечивает для пользователя altcos беспарольный доступ с master-узлов на ‘worker’-узлы. Структура файла следующая:

В него помещаются открытые ключи пользователей altcos master-узлов кластера.

Конфигурирование и запуск мастер-узлов [ править ]

Создание butane-YML файлов описания конфигурации master-узлов [ править ]

YML-файл master_01.yml для первого узла master01:

В элементе 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 указываются имена узлов master02 и master03 соответственно;
  • в файле ‘/etc/systemd/network/20-wired.network в поле Address указываются IP-адреса master-узлов 10.150.0.162 и 10.150.0.163 соответственно.

Пример YML-файл master_02.yml для первого узла master02:

Скрипт createNode.sh запуска master и worker узлов [ править ]

Исходный код скрипта:

Скрипт принимает три параметра:

  1. Тип узла – master или worker.
  2. Номер узла (1, 2, 3, . ).
  3. Тропа до файла qcow2-образа.

Скрипт на основе типа виртуальной машины и ее номера формирует prefix $_$ (например master_01) который используется для определения:

  • имен основных yml и ignition файлов;
  • имен основного (/dev/sda) и дополнительного btrfs (/dev/sdb) qcow2-файла дисков;
  • имен виртуальных машин.

Далее производятся следующие действия:

  • Указанный 3-м параметром файл-образ копируется в файл загрузочного qcow2-образа.
  • Команда qemu-img create . создает образ btrfs-диска указанного размера.
  • Команда virt-install –name $prefix . создает виртуальную машину, передавая ignition файл конфигурации $.ign.

Запуск виртуальных машин master-узлов [ править ]

В HOST-системах NODE3 10.140.0.3, NODE4 10.140.0.4, NODE5 10.140.0.5 запустите виртуальные машины командами:

Генерация ssh-ключей и их использование [ править ]

Дождитесь запуска виртуальных машин (несколько минут) и зайдите под пользователем altcos на них:

Сгенерируйте ssh-ключи командой:

Передайте открытые ключи на остальные master-узлы:

  • master01 (10.150.0.161):
  • master02 (10.150.0.162):
  • master03 (10.150.0.163):

Добавьте открытый ключи из файла ~altcos/.ssh/id_rsa.pub в файл mastersUsers.yml описания открытых ключей мастер-узлов кластера.

Иниализация кластера на первом узле master01 [ править ]

На узле master01 (10.150.0.161) запустите сервис initk8s:

Инициализация кластера производится несколько минут. После окончания проверьте наличие одного узла в кластере:

Подключение остальных master-узлов [ править ]

На узле master01 (10.150.0.161) запустите сервис initk8s:

Найдите в логах строки подключения master-узлов:

добавьте к ним параметр –cri-socket=/var/run/crio/crio.sock и запишите полученную команду в переменную

Загрузите необходимые docker-образы на узлах master02, master03:

Подключите дополнительные master-узлы командами:

Подключение master’ов происходит за пару минут.

После подключения проверьте список узлов кластера:

Конфигурирование и запуск рабочих (worker) узлов [ править ]

Создание butane-YML файлов описания конфигурации worker-узлов [ править ]

YML-файл для первого узла worker01:

Отличие он конфигурации master-файлов:

  • отсутствует подключение ignition-файлов k8senv.ign, initk8s.ign;
  • подключается файл mastersUsers.ign описания открытых ключей мастер-узлов кластера.

Аналогичным образом конфигурируются файлы для worker02, worker03.

Запуск виртуальных машин worker-узлов [ править ]

В HOST-системах NODE3 10.140.0.3, NODE4 10.140.0.4, NODE5 10.140.0.5 запустите виртуальные worker-машины командами:

Подключение worker-узлов [ править ]

Зайдите на один из master-узлов. например на master01. Запишите в переменную joinworker строку подключения:

Подключите дополнительные worker-узлы командами:

Подключение worker’ов происходит менее минуты.

После подключения проверьте на одном из master-узлов список узлов кластера:


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *