Разворачиваем кластер K8S при помощи kubespray

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

Описание проекта и полезные ссылки

В рамках модернизации своего персоналного комплекса приложений для тестирования, разработки совместной работы, базы знаний и т.п. я все же пришел к пониманию, что его необходимо перенести в кластер кубика. Для этого я подготовил три узла для кубика с одним мастером и двумя воркерами, распределенным файловым хранилищем на базе GlusterFS.

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

А сейчас немного полезных ссылок:

• Основной GitHub репозитарий cubespray: https://github.com/kubernetes-sigs/kubespray

Подготовка окружения

На данный момент у меня есть:

• Три виртуальные машины с унифицированным окружением, подготовленные скриптами автоматизации (один для мастера и два для вокеров)
• Гитлаб где будет храниться Cubespray и его настройки
• Образ для запуска Ansible скриптов и playbook-ов

Первым этапом, мы создаем репозитарий где будут храниться скрипты создания и обслуживания кластера, а так-же его конфигурация.

За основу нашего репозитария берем текущий стабильный релиз Cubespray (а не git-репозитарий) и в моем случае это 2.23.1 https://github.com/kubernetes-sigs/kubespray/archive/refs/tags/v2.23.1.tar.gz

Для работы с данной версией Cubespray нам требуется Python 3.9. Установим необходимую версию:

# aptitude install python3.9 python3.9-venv

Нам для работы с необходимой версией Ansible рекомендуется использовать виртуальное окружение и список библиотек которые указаны в зависимостях requirements.txt:

$ python3.9 -m venv venv
$ source ./venv/bin/activate
$ pip3 install -r ./requirements.txt

Копируем и подготавливаем шаблонный Inventory:

$ cp -rfp inventory/sample inventory/interlan
$ declare -a IPS=(10.240.250.20 10.240.250.50 10.240.250.51)
$ CONFIG_FILE=inventory/interlan/hosts.yaml python3 contrib/inventory_builder/inventory.py ${IPS[@]}

Получаем конфигурацию по-умолчанию которая нас не устраивает:

DEBUG: Adding group all
DEBUG: Adding group kube_control_plane
DEBUG: Adding group kube_node
DEBUG: Adding group etcd
DEBUG: Adding group k8s_cluster
DEBUG: Adding group calico_rr
DEBUG: adding host node1 to group all
DEBUG: adding host node2 to group all
DEBUG: adding host node3 to group all
DEBUG: adding host node1 to group etcd
DEBUG: adding host node2 to group etcd
DEBUG: adding host node3 to group etcd
DEBUG: adding host node1 to group kube_control_plane
DEBUG: adding host node2 to group kube_control_plane
DEBUG: adding host node1 to group kube_node
DEBUG: adding host node2 to group kube_node
DEBUG: adding host node3 to group kube_node

Приводим файл inventory/interlan/hosts.yaml к требуемой конфигурации:

all:
  hosts:
    node1:
      ansible_host: 10.240.250.20
      ip: 10.240.250.20
      access_ip: 10.240.250.20
    node2:
      ansible_host: 10.240.250.50
      ip: 10.240.250.50
      access_ip: 10.240.250.50
    node3:
      ansible_host: 10.240.250.51
      ip: 10.240.250.51
      access_ip: 10.240.250.51
  children:
    kube_control_plane:
      hosts:
        node1:
    kube_node:
      hosts:
        node1:
        node2:
        node3:
    etcd:
      hosts:
        node1:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:
    calico_rr:
      hosts: {}

Удаляем из .gitignore исключения для каталога inventory, так-как конфигурация у нас будет храниться в git и в идеале деплой при помощи gitlab-ci и делаем git push в репозитарий.

Удаляем старый кластер при помощи команды:

$ ansible-playbook -i inventory/interlan/hosts.yaml --user=root  --become --become-user=root reset.yml

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

Настройки кластера находятся в каталоге inventory и мы изменим некоторые из них.

Тип работы кластера меняем с containerd на docker

В файле group_vars/k8s_cluster/k8s-cluster.yml 

container_manager: docker

Инициализируем кластер.

$ ansible-playbook -i inventory/interlan/hosts.yaml --user=root --become --become-user=root cluster.yml

Если кластер успешно инициализирован и работает то делаем push в наш репозитарий.

Обновление кластера

Инициализация кластера с нуля это конечно здорово, но иногда нам надо просто поменять несколько параметров. Что мы сейчас и попробуем.

Первое, что приходит в голову, это оживить наш сервис блокировки шлака на уровне DNS и как взрослые люди указать ипользование внутренних DNS. И этот функционал у нас в файле inventory/interlan/group_vars/all/all.yml.

## Upstream dns servers
upstream_dns_servers:
  - 8.8.8.8
  - 8.8.4.4

Давайте попробуем применить эти изменения и тут все аналогично инициализации кластера, но ансибл-скрипт уже другой.

$ ansible-playbook -i inventory/interlan/hosts.yaml --user=root --become --become-user=root ./upgrade-cluster.yml

В свете последних событий, разумно так-же указать и прокси сервер вне РФ (inventory/interlan/group_vars/all/all.yml).

## Set these proxy values in order to update package manager and docker daemon to use proxies and custom CA for https_proxy if needed
# http_proxy: ""
# https_proxy: ""
# https_proxy_cert_file: ""