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

Привет, Хабр! Меня зовут Катя Низовцева, я системный администратор в Selectel. В этой статье мы подробно рассмотрим, как с помощью Kubespray быстро и эффективно развернуть работоспособный Kubernetes-кластер, а также интегрировать с ним систему мониторинга VictoriaMetrics. Этот подход особенно полезен, когда необходимо оперативно создать тестовое окружение или подготовить базовую инфраструктуру для дальнейшего развития.

Что вы узнаете

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

Вы узнаете, как подготовить инфраструктуру для развертывания, какие настройки Kubespray требуют особого внимания, а также — как правильно установить и настроить VictoriaMetrics. Все это будет полезно системным администраторам, осваивающим контейнерные технологии, DevOps-инженерам, которые ищут способы ускорения развертывания инфраструктуры, и разработчикам.

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

Схема развертывания K8s-кластера через Kubespray

Kubespray — это набор готовых сценариев (playbooks) для Ansible, которые автоматизируют установку и настройку Kubernetes-кластера. Вместо того чтобы вручную настраивать каждую ноду, вы описываете конфигурацию в файлах, а Kubespray делает всю работу за вас.

Что мы здесь видим? Первое — вспомогательную ВМ, на которой у нас будет установлен Ansible. Это может быть также ваш локальный хост. Тестовый кластер же будет состоять из одной мастер-ноды и воркер-ноды. 

Мастер-нода (control plane) — это «мозг» кластера, управляющий всеми процессами. Она отвечает за принятие решений о размещении подов, отслеживание состояния кластера, обработку API-запросов и хранение конфигурации в etcd.

Воркер-нода — это нода, на которой непосредственно запускаются ваши приложения (поды).

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

Предварительно подготовим инфраструктуру в панели управления.

Облачный сервер с криперами и порталом в Незер. Добывайте ресурсы, стройте объекты, исследуйте мир Selectel в Minecraft и получайте призы.

Исследовать →

Шаг 1. Создаем сеть для будущего кластера

Создаем новую приватную сеть в интересующем пуле, с интересующим CIDR. Эта подсеть будет использоваться для нод, входящих в состав кластера. Для этого переходим во вкладку Продукты → Облачная платформа → Облачные серверы → Сеть → Приватные сети.

Внимание! DHCP лучше выключить, так как по истечению DHCP-lease IP-адрес с ноды может пропасть, что повлечет за собой проблемы в сети.

Отлично. Далее создаем облачный роутер в том же пуле и подключаем его к внешней сети. Это можно сделать во вкладке Продукты → Облачная платформа → Облачные серверы → Сеть → Облачные роутеры.

Затем подключаем ранее созданную приватную сеть к этому роутеру.

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

Далее перейдем во вкладку Продукты → Облачная платформа → Облачные серверы и нажмем кнопку Создать сервер.

На всех ВМ в качестве ОС выбрана Ubuntu 24.04. Используемые конфигурации для ВМ под разные функциональности описаны ниже. При этом они именно рекомендуемые для тестовой среды, но могут быть изменены в зависимости от нагрузки.

• Виртуальная машина с Ansible: 1 vCPU, 2 ГБ RAM, 20 ГБ диска.

• Мастер-нода кластера: 2 vCPU, 4 ГБ RAM, 20 ГБ диска.

• Воркер-нода кластера: 1 vCPU, 2 ГБ RAM, 10 ГБ диска.

В качестве приватной сети выбираем созданную ранее нами подсеть. 

Ниже — пример создания мастер-ноды:

В разделе Доступ добавляем свой SSH-ключ, так как вместе с Ubuntu 24.04 LTS 64-bit необходимо использовать SSH-ключ.

По аналогии повторяем процесс для воркер-ноды (kubernetes-worker) и ВМ с Ansible (ansible).

О безопасности. По умолчанию ВМ получает публичный IP, но его можно заменить на доступ через облачный роутер с опциональным файрволом. Файрвол — это важный шаг для защиты кластера. Подробнее о межсетевом экране на облачном роутере можно почитать в документации.

Шаг 3. Подготовка ВМ с Ansible

1. Для начала нам нужно обновить и установить необходимые пакеты, а также сгенерировать SSH-ключ для безопасного подключения к нодам.

sudo apt update
sudo apt install python3.12-venv python3.12-dev -y
sudo apt install ansible
sudo apt install python3-pip

ssh-keygen 

2. На хостах будущего Kubernetes-кластера добавляем ключ этой ВМ в авторизованные:

# Просмотр локального ключа
cat /root/.ssh/название ключа.pub 

# Добавление ключа на ВМ от других ВМ
mkdir -p ~/.ssh
echo "ssh-..." >> ~/.ssh/authorized_keys

3. Далее снова переходим к ВМ с Ansible, клонируем официальный репозиторий Kubepsray. 

Внимание! Версия Kubespray может меняться — стоит проверить актуальный стабильный релиз на GitHub.

sudo apt install git
git clone https://github.com/kubernetes-sigs/kubespray.git --branch release-2.27

4. Зададим переменные окружения, создадим и запустим виртуальное окружение Python, а также установим необходимые зависимости для проекта, которые указаны в файле requirements.txt.

С помощью виртуального окружения зависимости проекта не конфликтуют с глобальными пакетами системы.

cd kubespray/

VENVDIR=kubespray-venv
KUBESPRAYDIR=kubespray

python3 -m venv $VENVDIR
source $VENVDIR/bin/activate

pip install -U -r requirements.txt
cp -rfp inventory/sample inventory/mycluster

Примечание. Если же вы используете хост в другой подсети, то вам необходимо обеспечить сетевую связность между ВМ c Ansible и будущими нодами вашего Kubernetes-кластера. Если ВМ находятся в одном пуле, то достаточно будет эти две сети подключить к одному облачному роутеру. А если ВМ будут находиться  в разных пулах, то связность обеспечивается через глобальный роутер.

Далее заполняем файл hosts.yaml в папке /inventory/mycluster для описания IP-адресов всех серверов и их ролей в кластере Kubernetes.

apt install vim # Вы можете воспользоваться любым другим удобным редактором файлов для Linux, в рамках данной статьи мы работаем с vim

cd inventory/mycluster/
vim hosts.yaml

Файл будет такого вида:

all:
  hosts:
    master:
      ansible_host: 10.233.22.2
      ip: 10.233.22.2
      access_ip: 10.233.22.2
    node1:
      ansible_host: 10.233.22.3
      ip: 10.233.22.3
      access_ip: 10.233.22.3
  children:
    kube_control_plane:
      hosts:
        master:
    kube_node:
      hosts:
        node1:
    etcd:
      hosts:
        master:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:
    calico_rr:
      hosts: {}

В файле выше мы обозначили, что на мастер-ноде устанавливаются компоненты для control-panel и ETCD запускается также на нем. ETCD — это хранилище, где Kubernetes держит все настройки и данные о работе кластера.

Далее отредактируем файл all.yml в папке group_vars/all, где укажем NTP и DNS upstream-серверы для корректной работы кластера.

cd group_vars/all
vim all.yml 

В этом файле можно поменять настройки перед установкой (зависит от требований к кластеру), например, включить NTP и настроить использование DNS-серверов Selectel:

ntp_enabled: true
ntp_servers:
  - "0.pool.ntp.org iburst"
  - "1.pool.ntp.org iburst"
  - "2.pool.ntp.org iburst"
  - "3.pool.ntp.org iburst"
...
upstream_dns_servers:
  - 188.93.16.19
  - 188.93.17.19

Обратите внимание: в качестве upstream DNS серверов указываются серверы Selectel. Их IP-адреса можно найти в документации.

Опционально. Вы можете внести некоторые изменения еще в файлы:

cd ..
cd k8s_cluster/
vim k8s-cluster.yml 
vim addons.yml

В файле k8s-cluster.yaml можно указать, например, желаемый CNI (Container Network Interface), сеть для подов, а также включить настройку компонентов для PV (Persistent Volumes) и многое другое.

В файле addons.yaml прописано включение ArgoCD, Helm, Ingress Nginx и другое. Изменять настройки по умолчанию мы, конечно, не будем.

Шаг 4. Запуск создания Kubernetes кластера

Далее на ВМ с Ansible выходим в папку /kubespray, из которой запустим уже непосредственно создание кластера через ansible-playbook:

cd
cd kubespray
ansible-playbook -i inventory/mycluster/hosts.yaml --become cluster.yml --become-user=root

Ждем около 15-20 минут. И проверяем состояние нод, например с мастер-ноды, специальной kubectl-командой. Ноды должны быть в статусе Ready:

root@kubernetes-master:~# kubectl get node
NAME     STATUS   ROLES           AGE     VERSION
master   Ready    control-plane   6m40s   v1.31.9
node1    Ready    <none>          6m3s    v1.31.9

Шаг 5. Развертывание кластера VictoriaMetrics

В рамках данной статьи развернем кластер VictoriaMetrics, состоящей из одной виртуальной машины.

Почему VictoriaMetrics? Это легковесная, но мощная альтернатива Prometheus для хранения метрик, с низким потреблением ресурсов и полной совместимостью с PromQL. Вместе они позволяют быстро развернуть кластер с эффективной системой мониторинга, подходящей как для тестов, так и для продакшена.

1. Создаем новую ВМ. Конфигурация в тестовой среде следующая: 1 vCPU, 2 ГБ RAM, 10 ГБ универсального SSD-диска. Конфигурация сервера с VictoriaMetrics зависит от того, сколько метрик вы будете собирать.

2. Для упрощения инфраструктуры и настройки сейчас помещаем виртуальную машину в ту же приватную подсеть, где у нас располагается кластер, в нашем случае — в сеть kubernetes-cluster.

3. Выполняем на новой виртуальной машине команды:

# Обновление и установка нужных пакетов
apt update
apt install tar wget curl

4. Далее ищем желаемый релиз на ресурсе и, например, если выбираем версию 1.120.0, то устанавливаем такой командой:

wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.120.0/victoria-metrics-linux-amd64-v1.120.0.tar.gz

Версия VictoriaMetrics может меняться — стоит проверить актуальный стабильный релиз на GitHub.

# Распаковка архива:
tar zxf victoria-metrics-linux-amd64-*.tar.gz -C /usr/local/bin/

5. Следующим шагом создаем и настраиваем systemd-юнит:

# Создание нового пользователя по соображениям безопасности
useradd -r -c 'VictoriaMetrics' victoriametrics

# Создание каталога для хранения данных
mkdir -p /var/lib/victoriametrics /run/victoriametrics

# Создание systemd-юнита
vim /etc/systemd/system/victoriametrics.service

[Unit]
Description=VictoriaMetrics
After=network.target

[Service]
Type=simple
User=victoriametrics
PIDFile=/run/victoriametrics/victoriametrics.pid
ExecStart=/usr/local/bin/victoria-metrics-prod -storageDataPath /var/lib/victoriametrics -retentionPeriod 12
ExecStop=/bin/kill -s SIGTERM $MAINPID
StartLimitBurst=5
StartLimitInterval=0
Restart=on-failure
RestartSec=1

[Install]
WantedBy=multi-user.target

# -retentionPeriod 12 - означает срок хранения метрик в месяцах.

# Обновление конфигурации systemd после изменения юнита:
systemctl daemon-reload

# Включение нашего юнита
systemctl enable victoriametrics

# Проверка его статуса
systemctl status victoriametrics

5. Проверяем доступность ноды с VictoriaMetrics, например, с воркер-ноды кластера — и готово.

root@node1:~# curl http://10.234.56.144:8428
<h2>Single-node VictoriaMetrics</h2>

VictoriaMetrics по умолчанию слушает запросы на порту 8428. Если вы захотите настроить файрвол, оставьте доступ для подключения по TCP по этому порту к ВМ.

Заключение

Теперь у вас есть работающий Kubernetes-кластер и VictoriaMetrics для сбора метрик. В следующих статьях мы расскажем, как настроить сбор метрик с помощью VMAgent и обеспечить безопасность инфраструктуры.

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