Vagrant автоматическая установка и настройка виртуальных машин для ручной установки kubernetes кластера средствами kubeadm

 

Поднятие 3-х master-нод и 2-х worker-нод с автоматическим provisioning:
—  всех необходимых настроек для подготовки нод к установке k8s-кластера
—  установка Haproxy на master0{1..2}-нодах в качестве балансировщика нагрузки на транспортном уровне (Level 4)
а) балансировка входящих kube-api-запросов, поступающих от kubelet и других клиентов на все kube-api поды запущенные на master-нодах
б) балансировка входящих клиентских/пользовательских запросов на порт 80 на ingress-nginx поды, запущенные на worker-нодах
— установка keepalived на master0{1..2}-нодах в качестве реализации Linux Virtual Server(LVS) для работы с виртуальным/плавающим IP-адресом для kube-api и пользовательских-запроcов

Ручная установка k8s-кластера с помощью kubeadm на подготовленных Vagrant-ом виртуальных машинах

Структурная схема имеет вид

 

Репозитарий с vagrant-k8s  доступен по адресу:
https://bitbucket.org/kamaok/vagrant-k8s/src/master/

В Vagrant-файле указаны версии пакетов/программного обеспечения, которое будет установлено

kubeadm,kubelet,kubectl - 1.21.2 (при инициализации кластера командой kubeadm используется соответствующая версия через указание опции --kubernetes-version "1.21.2")
containerd - 1.4.6
В качестве container runtime interface (CRI) по дефолту используется containerd если необходимо использовать docker в качестве CRI, тогда в Vagrantfile необходимо внести изменения:

— закомментировать провизионинг contanerd

— раскомментировать провизионинг dockerd

Соответствие имени и IP-адреса, которые добавлены в /etc/hosts на всех серверах

Если необходимо добавить/удалить мастера/воркеры, тогда изменените соответствущие настройки/файлы

— в Vagrnatfile

в файле

в файле

HAproxy web-интерфейс будет доступен в локальном браузере через URL:

http://localhost:61001 — для HAproxy, запущенного на master01

http://localhost:61002 — для HAproxy, запущенного на master02

Ingres-nginx, который запущен на worker-нодах в режиме

host network: true

или через host port

доступен в локальном браузере через URL:

http://localhost:8021 — для Ingres-nginx, запущенного на node01

http://localhost:8022 — для Ingres-nginx, запущенного на node02

 

Подготовка нод кластера

Активация Vagrant-файла для нужной версии Centos (7/8)

В данном случае для Centos 8

Проверка синтаксиса конфигурационого файла Vagrant

Создание и автоматическая настройка всех нод кластера

Установка keepalived на master01

Установка keepalived на master02

Отключим активированный предыдущей командой provisioning keepalived

Проверка отработки всех provisioning-задач/скриптов: На master-ах(например, на master01)

На node-ах

 

Инициализация кластера

https://v1-21.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm
https://v1-21.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability

При инициализации кластера командой kubeadm используе следующие опции/флаги:

--apiserver-advertise-address "IP_ADDRESS_INTERFACE_FOR_NODE_COMMUNICATION"
В нашем случае --apiserver-advertise-address "192.168.66.11" IP-адрес, на котором api-сервер будет оповещать/уведомлять других членов кластера.

По дефолту виртуалка,созданная через наш Vagrantfile выходит в инет через интерфейс eth0, который имеет тип nat и настроен на динамическое получение сетевых настроек по dhcp с хоста вагранта

Нам же нужно,чтобы взаимодействие осуществлялось через подсеть 192.168.66.0/24 Поэтому принудительно указываем IP-адрес, который виртуалка имеет на интерфейса eth1, через который она будет общаться с другими компонентами и хостами k8s-кластере.

В нашем случае IP-адрес 192.168.66.11

--control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"

--control-plane-endpoint — указываем имя лоадбалансера, на котором настроен виртуальный плавающий IP-адрес(192.168.66.100)

В нашем случае --control-plane-endpoint "loadbalancer:8443"

В нашем случае имя loadbalancer — 192.168.66.100(на всех хостах добавлена соотвествующая запиcь в /etc/hosts-файл)

Порт 8843 — это порт,который слушает Haproxy на master0{1..2}-нодах т.к. на master-ах также будет запущен kube-api сервер, который слушает по дефолту на порту 6443, то используем отличный от 6443 порт для прослушивания Haproxy запросов к нему --kubernetes-version — указываем конкретную версию Kubernetes, которую хотим установить.

Рекомендуется использовать такую же версию, как и версия kubeadm,kubelet,kubectl

В нашем случае 1.21.2 --kubernetes-version "1.21.2"

--upload-certs — загрузить сертификаты в k8s-секрет с именем kubeadm-certs в namespace kube-system, которые будут расшарены/подложены на все master-ноды кластера.

Этот секрет будет автоматически удален через 2 часа Альтернативным вариантом может быть ручное или автоматическиое с помощью систем управления конфигурациями подкладывание/копирование этих сертификатов на master-ноды.

Тогда этот флаг использовать не нужно

https://v1-21.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/#manual-certs

--pod-network-cidr — указываем подсеть, которая будет использоваться для подов

Эта подсеть будет разбита/разделена на подсети и такие подсети будут назанчены на все хосты(как master, так и worker) кластера

В качестве CNI(Container Network Interface) будем использовать Calico, который по умочанию использует подсеть 192.168.0.0/16

Во избежания совпадения подсетей между Calico и внутренней сети вагранта (192.168.66.0/24 в нашем случае)

Принудительно укажем подсеть, которую нужно использовать для подов при инициализации кластера через параметр --pod-network-cidr

При установке Calico, он будет учитывать,что нужно использовать подсеть, которую мы указали при инициализаици кластера и не будет использоват свою дефолтную подсеть Например, возьмем подсеть: 10.200.0.0/16

--pod-network-cidr "10.200.0.0/16"

Итого команда по инициализации кластера имеет вид

Инициализация кластера

Настройка файла для аутентификации и авторизации в k8s для master01-ноды

 

Установка calico в качестве Container Network Interface

И только после того, как поднялись контейнеры с coredns и calico добавляем остальные мастера в кластер

Дополнительно к команде по добавлению ноды в кластер, я принудительно добавил параметр --apiserver-advertise-address со значением IP-адреса ноды, через который должно происходить взаимодействие с остальными членами кластера в нашем случае 192.168.66.12

Добавление второго мастера в k8s-кластер

Настройка файла для аутентификации и авторизации в k8s для master02-ноды

Добавление третьего мастера в k8s-кластер

Настройка файла для аутентификации и авторизации в k8s для master03-ноды

Добавление первой рабочей ноды в k8s-кластер

Добавление второй рабочей ноды в k8s-кластер

После запуска master-ов проверяем поднятие всех мастеровых компонентов k8s включая haproxy

На рабочих нодах провереям поднятие kubelet и kube-proxy

Также требуется вручную настроить конфигурационный файл crictl.yaml для работы с подами/контейнерами/образами (взаимодействия с сri containerd)

Проверяем доступ к подам,контейнерам,образам при использовании crictl

 

Установка и настройка Ingress-nginx в качестве Ingress-контроллера

Добавить метку на role1=ingress на перые две worker-ноды k8s-кластера

Проверить наличие установленных меток на нодах

Деплой Ingress-controller

Настройки, которые изменены пос равнению с дефолтными настройками

Раздеплоим Ingress-nginx

Проверяем состояние подов в namspace ingress-nginx

Источник:

https://github.com/rotoro-cloud/hardway-cluster/blob/main/Vagrantfile
https://kubernetes.io/docs/setup/production-environment/container-runtimes
https://v1-21.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm
https://v1-21.docs.kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика