INSTALLATION

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

Содержание

Введение
Что будет установлено
Требования к системе
Предварительные требования
Подготовка окружения
Шаг 0.1: Клонирование репозитория
Шаг 0.2: Копирование и настройка .env файла
Шаг 0.3: Сборка Docker образа
Настройка базовой инфраструктуры
Шаг 1: Проверка подключения к нодам
Шаг 2: Настройка firewall
Шаг 3: Настройка WireGuard full-mesh
Шаг 4: Проверка WireGuard связности
Установка Kubernetes кластера
Шаг 5: Полная установка Kubernetes кластера
Шаг 6: Проверка кластера
Шаг 7: Настройка kubeconfig на локальной машине
Шаг 8: Установка Metrics Server
Шаг 9: Подготовка нод (labels и taints)
Шаг 9.1: Установка кластерных ресурсов
Шаг 9.2: Добавление меток на узлы
Установка Storage (Longhorn)
Шаг 10: Подготовка worker нод для Longhorn
Шаг 11: Установка Longhorn
Шаг 12: Проверка Longhorn
Установка базовых операторов
Шаг 13: Установка PostgreSQL Operator
Шаг 14: Установка Kafka Operator
Шаг 14: Установка Redis Operator
Шаг 16: Установка MinIO Operator
Шаг 17: Установка Vault Operator
Шаг 17: Установка Nexus Operator
Шаг 19: Установка GitLab Runner Operator
Создание базовых инстансов/кластеров
Шаг 20: Создание PostgreSQL кластера
Шаг 20: Создание Kafka кластера
Шаг 22: Создание Redis кластера
Шаг 23: Создание MinIO tenant
Шаг 24: Установка Logging Stack (Loki + Fluent Bit)
Шаг 25: Создание Vault инстанса
Шаг 26: Создание Nexus инстанса
Установка приложений
Шаг 27: Установка Ingress NGINX и Cert-Manager
Шаг 28: Установка Monitoring Stack (VictoriaMetrics, Prometheus, Grafana)
Шаг 29: Установка Authentik
Шаг 30: Установка SonarQube
Шаг 31: Установка GlitchTip
Шаг 32: Установка Kubernetes Dashboard
Настройка WireGuard Client VPN (опционально)
Шаг 33: Настройка VPN gateway
Шаг 34: Генерация клиентской конфигурации
Проверка и верификация
Troubleshooting
Следующие шаги

Введение

Что будет установлено

Данный гайд описывает установку полной инфраструктуры AIOps платформы, включающей:

Kubernetes кластер (HA, multi-master)
Longhorn - распределенное хранилище
PostgreSQL - база данных (через Crunchy PGO)
Kafka - message broker (через Strimzi Operator)
Redis - кэш и очереди (через Opstree Operator)
MinIO - S3-совместимое хранилище
Vault - секреты и шифрование (через Bank-Vaults Operator)
Nexus - репозиторий артефактов
SonarQube - анализ кода
Authentik - SSO и аутентификация
GlitchTip - мониторинг ошибок (Sentry-совместимый)
GitLab Runner - CI/CD runner
Kubernetes Dashboard - веб-интерфейс для кластера
Logging - централизованный сбор логов (Loki + Fluent Bit)
Monitoring - мониторинг метрик (VictoriaMetrics + Prometheus + Grafana + Alertmanager)
Ingress NGINX - ingress controller
Cert-Manager - управление сертификатами

Требования к системе

Минимальные требования: - Ноды: минимум 3 (1 master + 2 workers) для базовой установки - Рекомендуется: 6 нод (3 masters + 3 workers) для HA - CPU: минимум 2 cores на ноду, рекомендуется 4+ cores - RAM: минимум 4 GiB на ноду, рекомендуется 8+ GiB - Диск: минимум 50 GiB на ноду, рекомендуется 100+ GiB - Сеть: все ноды должны быть доступны друг другу

Общие ресурсы кластера: - CPU: ~9.5 cores (requests), ~37 cores (limits) - RAM: ~16 GiB (requests), ~36 GiB (limits) - Storage: ~600 GiB (с учетом репликации) - Поды: ~75 подов

Подробнее о ресурсах см. k8s/README.md.

Предварительные требования

На локальной машине: - Docker и Docker Compose - SSH доступ ко всем нодам - SSH ключи для подключения к нодам - Git (для клонирования репозитория)

На нодах: - Ubuntu/Debian Linux (рекомендуется) - SSH доступ с root или sudo правами - Доступ к интернету для загрузки образов и пакетов - Открытые порты для WireGuard (51820/udp) и Kubernetes API (6443/tcp)

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

Шаг 0.1: Клонирование репозитория

git clone <repository-url>
cd ai-ops/infra

Шаг 0.2: Копирование и настройка .env файла

1	`cp env.example .env`

Откройте файл .env в редакторе и заполните следующие параметры:

SSH конфигурация

ANSIBLE_SSH_USER=root
SSH_KEY_DIR=/path/to/ssh-keys

WireGuard конфигурация

WIREGUARD_INTERFACE=wg0
WIREGUARD_NETWORK_CIDR=10.99.0.0/24
WIREGUARD_PORT=51820

# Опционально: для клиентского VPN
WIREGUARD_CLIENT_NAME=alex
WIREGUARD_CLIENT_IP=10.99.0.100
WIREGUARD_CLIENT_PUBLIC_IP=your.public.ip.or.domain
INTERNAL_DNS_IP=10.110.0.10

Важно: - WIREGUARD_NETWORK_CIDR - приватная сеть для WireGuard (не должна пересекаться с другими сетями) - WIREGUARD_CLIENT_IP - должен быть в пределах WIREGUARD_NETWORK_CIDR и не конфликтовать с IP нод

Kubernetes конфигурация

KUBERNETES_VERSION=1.31.0
CONTAINERD_VERSION=1.7.11
POD_NETWORK_CIDR=10.244.0.0/16
SERVICE_CIDR=10.96.0.0/12

Важно: - POD_NETWORK_CIDR и SERVICE_CIDR не должны пересекаться с WIREGUARD_NETWORK_CIDR - Версии Kubernetes и Containerd должны быть совместимы

Конфигурация нод

Для каждой ноды укажите:

# Master нода 1
NODE_1_NAME=master1
NODE_1_IP=192.168.1.10
NODE_1_TYPE=master
NODE_1_WIREGUARD_IP=10.99.0.11
NODE_1_SSH_KEY=/path/to/your/private/key
NODE_1_SSH_PASSPHRASE=
NODE_1_NODE_TYPE=control-plane
NODE_1_DISK_TYPE=ssd
NODE_1_DISK_SIZE=200gb
NODE_1_MASTER_NODE=master-1

# Worker нода 1
NODE_2_NAME=worker1
NODE_2_IP=192.168.1.11
NODE_2_TYPE=worker
NODE_2_WIREGUARD_IP=10.99.0.21
NODE_2_SSH_KEY=/path/to/your/private/key
NODE_2_SSH_PASSPHRASE=
NODE_2_NODE_TYPE=compute
NODE_2_MEMORY_TYPE=highmem
NODE_2_DISK_SIZE=100gb

# Добавьте остальные ноды (NODE_3_NAME, NODE_4_NAME, и т.д.)

Важно: - NODE_X_IP - реальный IP адрес ноды в вашей сети - NODE_X_WIREGUARD_IP - IP адрес ноды в WireGuard сети (должен быть уникальным) - NODE_X_SSH_KEY - путь к приватному SSH ключу для подключения к ноде - Для master нод обязательно укажите NODE_X_MASTER_NODE (например, master-1, master-2)

Пример полной конфигурации для 6 нод (3 masters + 3 workers):

# Master 1
NODE_1_NAME=master1
NODE_1_IP=192.168.1.10
NODE_1_TYPE=master
NODE_1_WIREGUARD_IP=10.99.0.11
NODE_1_SSH_KEY=/home/user/.ssh/id_rsa
NODE_1_MASTER_NODE=master-1

# Master 2
NODE_2_NAME=master2
NODE_2_IP=192.168.1.11
NODE_2_TYPE=master
NODE_2_WIREGUARD_IP=10.99.0.12
NODE_2_SSH_KEY=/home/user/.ssh/id_rsa
NODE_2_MASTER_NODE=master-2

# Master 3
NODE_3_NAME=master3
NODE_3_IP=192.168.1.12
NODE_3_TYPE=master
NODE_3_WIREGUARD_IP=10.99.0.13
NODE_3_SSH_KEY=/home/user/.ssh/id_rsa
NODE_3_MASTER_NODE=master-3

# Worker 1
NODE_4_NAME=worker1
NODE_4_IP=192.168.1.20
NODE_4_TYPE=worker
NODE_4_WIREGUARD_IP=10.99.0.21
NODE_4_SSH_KEY=/home/user/.ssh/id_rsa

# Worker 2
NODE_5_NAME=worker2
NODE_5_IP=192.168.1.21
NODE_5_TYPE=worker
NODE_5_WIREGUARD_IP=10.99.0.22
NODE_5_SSH_KEY=/home/user/.ssh/id_rsa

# Worker 3
NODE_6_NAME=worker3
NODE_6_IP=192.168.1.22
NODE_6_TYPE=worker
NODE_6_WIREGUARD_IP=10.99.0.23
NODE_6_SSH_KEY=/home/user/.ssh/id_rsa

Шаг 0.3: Сборка Docker образа

1	`make build`

Ожидаемый результат: Docker образ собран успешно.

Проверка:

docker images | grep ansible

Настройка базовой инфраструктуры

Шаг 1: Проверка подключения к нодам

Команда:

1	`make ping`

Ожидаемый результат: Все ноды отвечают pong.

Что проверять: - Все ноды из .env файла доступны по SSH - SSH ключи работают корректно

Примечание: Если какая-то нода не отвечает, проверьте: - Правильность IP адресов в .env - Доступность нод по сети - Корректность SSH ключей

Шаг 2: Настройка firewall

Команда:

1	`make firewall`

Ожидаемый результат: Firewall настроен на всех нодах, необходимые порты открыты.

Что проверять: - Firewall активен на всех нодах - Порты для WireGuard (51820/udp) и Kubernetes (6443/tcp, 10250/tcp, и т.д.) открыты

Время выполнения: ~2-5 минут

Примечание: Если нужно настроить firewall только на определенных нодах:

make firewall-limit limit=master
make firewall-limit limit=worker1

Шаг 3: Настройка WireGuard full-mesh

Команда:

1	`make wireguard`

Ожидаемый результат: WireGuard настроен на всех нодах, создана full-mesh сеть.

Что проверять: - WireGuard интерфейс wg0 создан на всех нодах - Все ноды видят друг друга в WireGuard сети

Время выполнения: ~5-10 минут

Примечание: WireGuard создает полносвязную сеть между всеми нодами. Количество туннелей = n × (n-1) / 2, где n - количество нод.

Шаг 4: Проверка WireGuard связности

Команда:

1	`make wireguard-test`

Ожидаемый результат: Все ноды могут связаться друг с другом через WireGuard сеть.

Что проверять: - Ping между всеми нодами через WireGuard IP работает - Все туннели установлены

Примечание: Если тесты не проходят, проверьте: - Статус WireGuard: make wireguard-status - Логи на нодах: wg show на каждой ноде

Установка Kubernetes кластера

Шаг 5: Полная установка Kubernetes кластера

Команда:

1	`make k8s-full-install`

Ожидаемый результат: Kubernetes кластер установлен и готов к работе.

Что происходит: 1. Подготовка всех нод (отключение swap, установка containerd, kubeadm, kubelet, kubectl) 2. Инициализация первого master нода 3. Установка Calico CNI 4. Присоединение остальных master нод 5. Присоединение worker нод 6. Верификация кластера

Время выполнения: ~15-30 минут (зависит от количества нод и скорости интернета)

Что проверять: - Все ноды в статусе Ready - Все системные поды в namespace kube-system в статусе Running

Примечание: Если установка прерывается, можно выполнить шаги по отдельности:

make k8s-prerequisites  # Подготовка нод
make k8s-init           # Инициализация первого master
make k8s-cni            # Установка CNI
make k8s-join-masters   # Присоединение остальных masters
make k8s-join-workers   # Присоединение workers
make k8s-verify         # Верификация

Шаг 6: Проверка кластера

Команда:

1	`make k8s-status`

Ожидаемый результат: Все ноды в статусе Ready, системные поды работают.

Дополнительная проверка:

1	`make k8s-verify`

Что проверять: - Все ноды: kubectl get nodes - все в статусе Ready - Системные поды: kubectl get pods -n kube-system - все в статусе Running - CoreDNS работает: kubectl get pods -n kube-system -l k8s-app=kube-dns

Шаг 7: Настройка kubeconfig на локальной машине

Команда:

# Скопируйте kubeconfig с первого master нода
scp root@<master1-ip>:/root/.kube/config ./kubeconfig

Или используйте kubeconfig из репозитория (если он уже настроен):

# Убедитесь, что путь к kubeconfig правильный
export KUBECONFIG=$(pwd)/kubeconfig
kubectl get nodes

Ожидаемый результат: kubectl работает с вашего локального компьютера.

Что проверять:

kubectl get nodes
kubectl get pods -A

Примечание: Если kubeconfig находится в другом месте, обновите путь в infra/k8s/common/Makefile (переменная KUBECONFIG).

Шаг 8: Установка Metrics Server

Команда:

1	`make k8s-addons`

Ожидаемый результат: Metrics Server установлен и работает, метрики доступны через kubectl top.

Что происходит: 1. Проверка наличия Metrics Server в кластере 2. Скачивание манифеста Metrics Server с GitHub 3. Патч манифеста для работы с self-signed сертификатами kubelet (добавление флага --kubelet-insecure-tls) 4. Применение манифеста в кластер 5. Ожидание готовности Metrics Server 6. Тестирование работы через kubectl top nodes

Время выполнения: ~2-3 минуты

Что проверять:

# Проверка статуса Metrics Server
kubectl get deployment metrics-server -n kube-system
kubectl get pods -n kube-system -l k8s-app=metrics-server

# Проверка работы метрик
kubectl top nodes
kubectl top pods -A

Конфигурация: - Версия Metrics Server настраивается через переменную окружения METRICS_SERVER_VERSION в файле .env (по умолчанию v0.8.0) - Установка управляется переменной install_metrics: true в group_vars/all.yml (генерируется автоматически)

Примечание: - Metrics Server необходим для работы kubectl top и Kubernetes Dashboard (отображение метрик ресурсов) - Также требуется для работы Horizontal Pod Autoscaler (HPA) - Если Metrics Server не установлен, Dashboard будет показывать "metrics are not available due to missing or invalid config"

Если установка не требуется: Установите в .env:

# Отключить установку Metrics Server (не рекомендуется)
# install_metrics: false

Шаг 9: Подготовка нод (labels и taints)

Команда:

1	`make k8s-prepare-nodes`

Ожидаемый результат: На всех нодах установлены правильные labels и taints.

Что происходит: - На master нодах: label node-role.kubernetes.io/control-plane=true и taint node-role.kubernetes.io/control-plane:NoSchedule - На worker нодах: label node-role.kubernetes.io/worker=true

Что проверять:

kubectl get nodes --show-labels
kubectl describe node <node-name> | grep Taints

Примечание: Эта команда должна быть выполнена перед установкой компонентов, которые используют nodeSelector или tolerations.

Шаг 9.1: Установка кластерных ресурсов

Команда:

cd k8s
make install-cluster-resources

Ожидаемый результат: PriorityClasses и default-deny NetworkPolicies установлены в кластере.

Что происходит: 1. Установка PriorityClasses (infra-critical, critical-apps, important-apps, standard-apps) 2. Применение default-deny NetworkPolicies для изоляции namespace (tech-postgres-databases, tech-kafka-clusters, tech-redis-clusters, tech-vault-instances)

Время выполнения: ~1 минута

Что проверять:

kubectl get priorityclass
kubectl get networkpolicy -A

Примечание: - PriorityClasses используются для управления приоритетом подов при нехватке ресурсов - NetworkPolicies обеспечивают базовую изоляцию между namespace - Эти ресурсы также автоматически применяются при выполнении make install-namespaces

Шаг 9.2: Добавление меток на узлы

Команда:

cd k8s
make label-nodes

Ожидаемый результат: На всех узлах добавлены пользовательские метки (node-type, disk-type, memory-type, disk-size).

Что происходит: 1. Создание Job для добавления меток на узлы 2. На master нодах: node-type=control-plane, disk-type=ssd, disk-size=200gb 3. На worker нодах: node-type=compute, memory-type=highmem, disk-size=100gb

Время выполнения: ~1-2 минуты

Что проверять:

kubectl get nodes --show-labels | grep -E "node-type|disk-type|memory-type|disk-size"

Примечание: - Метки используются для nodeSelector и nodeAffinity в подах - Job автоматически удаляется через 5 минут после завершения (TTL) - Если нужно обновить метки, просто запустите команду снова

Установка Storage (Longhorn)

Шаг 10: Подготовка worker нод для Longhorn

Команда:

1	`make longhorn-prepare-nodes`

Ожидаемый результат: На worker нодах установлены open-iscsi и nfs-common.

Что происходит: - Установка open-iscsi - для iSCSI подключений volumes между нодами - Установка nfs-common - для NFS поддержки - Установка util-linux - системные утилиты

Время выполнения: ~2-5 минут

Что проверять: - На worker нодах установлены пакеты: dpkg -l | grep -E 'open-iscsi|nfs-common'

Примечание: Longhorn требует эти зависимости для работы с persistent volumes. Без них volumes будут доступны только локально на ноде.

Шаг 11: Установка Longhorn

Команда:

cd k8s
make longhorn-install-all

Ожидаемый результат: Longhorn установлен, все поды работают, Storage Classes созданы.

Что происходит: 1. Проверка зависимостей (open-iscsi, nfs-common) 2. Создание namespace longhorn-system (через install-namespaces) 3. Установка Longhorn через helmfile 4. Создание Storage Classes: - longhorn - стандартный StorageClass (1 реплика, Delete reclaim policy) - longhorn-retain - с Retain reclaim policy (для критичных данных) - longhorn-2replicas - с 2 репликами для повышенной надежности - longhorn-3replicas - с 3 репликами для максимальной надежности 5. Ожидание готовности всех компонентов

Время выполнения: ~5-10 минут

Что проверять: - Все поды Longhorn в статусе Running - Storage Classes созданы: kubectl get storageclass | grep longhorn - Должно быть 4 StorageClass: longhorn, longhorn-retain, longhorn-2replicas, longhorn-3replicas

Примечание: Longhorn должен быть установлен перед всеми компонентами, которые используют persistent storage.

Шаг 12: Проверка Longhorn

Команда:

1	`make longhorn-status`

Ожидаемый результат: Все компоненты Longhorn работают, ноды готовы.

Что проверять: - Manager DaemonSet работает на всех нодах - UI Deployment работает - CSI drivers работают - Storage Classes доступны

Дополнительно: Проверьте доступное место для storage:

kubectl get nodes.longhorn.io -n longhorn-system

Установка базовых операторов

Все операторы устанавливаются независимо друг от друга, но требуют готовности Longhorn для работы с persistent storage.

Важно: При установке операторов автоматически применяются следующие манифесты: - limitrange.yaml - ограничения ресурсов для namespace - resourcequota.yaml - квоты ресурсов для namespace - pdb.yaml - Pod Disruption Budget для высокой доступности - networkpolicy.yaml - политики сетевой изоляции - storageclass.yaml - StorageClass для компонента (если требуется)

Шаг 13: Установка PostgreSQL Operator

Команда:

cd k8s
make postgres-install-operator

Ожидаемый результат: PostgreSQL Operator и UI установлены и работают.

Время выполнения: ~3-5 минут

Что проверять:

1	`make postgres-status`

Примечание: PostgreSQL Operator управляет PostgreSQL кластерами через Custom Resources.

Шаг 14: Установка Kafka Operator

Команда:

1	`make kafka-install-operator`

Ожидаемый результат: Strimzi Kafka Operator установлен и работает.

Время выполнения: ~3-5 минут

Что проверять:

1	`make kafka-status`

Шаг 14: Установка Redis Operator

Команда:

1	`make redis-install-operator`

Ожидаемый результат: Opstree Redis Operator установлен и работает.

Время выполнения: ~3-5 минут

Что проверять:

1	`make redis-status`

Шаг 16: Установка MinIO Operator

Команда:

1	`make minio-install-operator`

Ожидаемый результат: MinIO Operator установлен и работает.

Время выполнения: ~3-5 минут

Что проверять:

1	`make minio-status`

Шаг 17: Установка Vault Operator

Команда:

1	`make vault-install-operator`

Ожидаемый результат: Bank-Vaults Vault Operator установлен и работает.

Время выполнения: ~3-5 минут

Что проверять:

1	`make vault-status`

Примечание: Перед созданием Vault инстанса нужно создать RBAC ресурсы.

Шаг 17: Установка Nexus Operator

Команда:

1	`make nexus-install-operator`

Ожидаемый результат: Nexus Operator установлен и работает.

Время выполнения: ~2-3 минуты

Что проверять:

1	`make nexus-status`

Примечание: Nexus Operator устанавливается через манифесты, а не через Helm.

Шаг 19: Установка GitLab Runner Operator

Команда:

1	`make gitlab-runner-olm-install`

Ожидаемый результат: GitLab Runner Operator установлен и работает.

Время выполнения: ~2-3 минуты

Что проверять:

1	`make gitlab-runner-status`

Примечание: GitLab Runner Operator устанавливается через манифесты, а не через Helm.

Создание базовых инстансов/кластеров

Шаг 20: Создание PostgreSQL кластера

Команда:

1	`make postgres-create-cluster`

Ожидаемый результат: PostgreSQL кластер pg-public создан и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, pdb, networkpolicy, storageclass) 2. Создание PostgreSQL Custom Resource 3. Ожидание готовности кластера (2-3 минуты)

Время выполнения: ~3-5 минут

Что проверять:

make postgres-status
kubectl get postgresql -n tech-postgres-databases
kubectl get pods -n tech-postgres-databases

Примечание: PostgreSQL кластер создается с 2 инстансами (1 primary + 1 replica) и connection poolers.

Шаг 20: Создание Kafka кластера

Команда:

1	`make kafka-create-cluster`

Ожидаемый результат: Kafka кластер kafka-cluster создан и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, pdb для Kafka и Zookeeper, networkpolicy, storageclass) 2. Создание Kafka Custom Resource 3. Создание Zookeeper (3 реплики) 4. Создание Kafka brokers (3 реплики) 5. Создание Entity Operator, Cruise Control, Kafka Exporter

Время выполнения: ~5-10 минут

Что проверять:

make kafka-status
kubectl get kafka -n tech-kafka-clusters
kubectl get pods -n tech-kafka-clusters

Примечание: Kafka кластер требует значительных ресурсов. Убедитесь, что в кластере достаточно CPU и памяти.

Шаг 22: Создание Redis кластера

Команда:

# Сначала создайте секрет для Redis
make redis-create-secret

# Затем создайте кластер
make redis-create-cluster

Ожидаемый результат: Redis кластер redis-cluster создан и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, pdb, networkpolicy, storageclass) 2. Создание Redis Custom Resource

Время выполнения: ~3-5 минут

Что проверять:

make redis-status
kubectl get rediscluster -n tech-redis-clusters
kubectl get pods -n tech-redis-clusters

Примечание: Redis кластер создается с 3 нодами (минимальный HA кластер).

Шаг 23: Создание MinIO tenant

Команда:

# Сначала создайте секрет для MinIO
make minio-create-secret

# Затем создайте tenant
make minio-create-tenant

Ожидаемый результат: MinIO tenant s3-public создан и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, pdb, storageclass) 2. Создание MinIO Tenant Custom Resource

Время выполнения: ~3-5 минут

Что проверять:

make minio-status
kubectl get tenant -n tech-minio-tenants
kubectl get pods -n tech-minio-tenants

Примечание: MinIO tenant создается с 4 серверами для HA.

Шаг 24: Установка Logging Stack (Loki + Fluent Bit)

Команда:

cd k8s
# Сначала создайте S3 buckets для Loki
make logging-create-buckets

# Создайте S3 credentials secret
make logging-create-s3-secret

# Установите полный logging stack
make logging-install-all

Ожидаемый результат: Loki и Fluent Bit установлены и работают, логи собираются и хранятся в MinIO S3.

Что происходит: 1. Создание S3 buckets в MinIO (loki-chunks, loki-ruler, loki-admin) 2. Создание Kubernetes Secret с S3 credentials 3. Применение манифестов ресурсных политик (limitrange, resourcequota, networkpolicy, storageclass) 4. Установка Loki Single Binary через Helm (S3 storage, TSDB schema v13) 5. Установка Fluent Bit DaemonSet на всех нодах 6. Настройка сбора логов из /var/log/containers/*.log

Время выполнения: ~5-10 минут

Что проверять:

make logging-status
kubectl get pods -n tech-logging
kubectl get pvc -n tech-logging

Важно: - MinIO tenant s3-public должен быть создан и работать (см. Шаг 23) - Longhorn должен быть установлен (для PVC Loki) - Fluent Bit автоматически устанавливается на всех нодах (включая master) - Логи хранятся в S3 с retention 30 дней - Доступ к Loki возможен только изнутри кластера (через Service или port-forward)

Проверка работы:

# Port-forward для доступа к Loki API
make logging-port-forward

# В другом терминале - тест запроса
curl -G -s "http://localhost:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={namespace="kube-system"}' \
  --data-urlencode 'limit=10' | jq

Примечание: - Loki использует TSDB schema v13 для оптимизированного хранения логов Kubernetes - Fluent Bit добавляет Kubernetes metadata (namespace, pod, container, node) с низкой кардинальностью - Multiline логи (Java, Python, Go stacktraces) автоматически объединяются - Для веб-интерфейса используйте Grafana с Loki datasource

Шаг 25: Создание Vault инстанса

Команда:

1	`make vault-create-instance`

Ожидаемый результат: Vault инстанс vault создан и работает в HA режиме (3 реплики).

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, networkpolicy, storageclass) 2. Создание RBAC ресурсов 3. Создание Vault Custom Resource 4. Автоматическая инициализация и unseal через Kubernetes

Время выполнения: ~3-5 минут

Что проверять:

make vault-status
kubectl get vaults -n tech-vault-instances
kubectl get pods -n tech-vault-instances

Примечание: Vault использует Kubernetes auto-unseal, поэтому не требуется ручной unseal.

Получение root token:

1	`make vault-unseal-keys`

Шаг 26: Создание Nexus инстанса

Команда:

1	`make nexus-create-instance`

Ожидаемый результат: Nexus инстанс nexus-tech создан и работает.

Время выполнения: ~5-10 минут (Nexus долго запускается)

Что проверять:

make nexus-status
kubectl get nexus -n tech-nexus-instances
kubectl get pods -n tech-nexus-instances

Примечание: Nexus может долго запускаться при первом создании. Подождите 5-10 минут после создания.

Установка приложений

Шаг 27: Установка Ingress NGINX и Cert-Manager

Команда:

cd infra/k8s/ingress
make ingress-install-all

Ожидаемый результат: Ingress NGINX Controller и Cert-Manager установлены и работают. ClusterIssuer создан автоматически.

Что происходит: 1. Установка Ingress NGINX Controller (hostNetwork на master1, порты 80/443) 2. Установка Cert-Manager 3. Автоматическое создание ClusterIssuer letsencrypt-http для Let's Encrypt (HTTP-01 challenge)

Время выполнения: ~5-10 минут

Что проверять:

make ingress-status
kubectl get pods -n ingress-nginx
kubectl get pods -n cert-manager
kubectl get clusterissuer letsencrypt-http

Важно: - Ingress NGINX использует hostNetwork для доступа к портам 80/443 на master1 ноде - ClusterIssuer создается автоматически при установке cert-manager - TLS сертификаты будут автоматически созданы cert-manager при применении ingress ресурсов с аннотацией cert-manager.io/cluster-issuer: "letsencrypt-http" - Для работы HTTP-01 challenge необходимо, чтобы домены были доступны из интернета на порту 80 (DNS записи должны указывать на IP master1)

Шаг 28: Установка Monitoring Stack (VictoriaMetrics, Prometheus, Grafana)

Команда:

cd k8s
# Полная установка стека мониторинга
make monitoring-install-all

Ожидаемый результат: VictoriaMetrics, Prometheus, Grafana и Alertmanager установлены и работают.

Что происходит: 1. Создание namespace tech-monitoring с ресурсными политиками (limitrange, resourcequota) 2. Установка VictoriaMetrics Single (TSDB для долгосрочного хранения метрик, 90 дней retention) 3. Установка Prometheus Stack (Prometheus Operator, Prometheus, Alertmanager, kube-state-metrics, node-exporter) 4. Применение PrometheusRule с базовыми алертами для кластера и мониторинга 5. Установка Grafana с pre-installed Kubernetes dashboards

Время выполнения: ~10-15 минут

Предварительные требования: - Longhorn должен быть установлен (для persistent storage) - Ноды должны быть подготовлены (labels и taints): cd ../.. && make k8s-prepare-nodes

Что проверять:

make monitoring-status
kubectl get pods -n tech-monitoring
kubectl get pvc -n tech-monitoring

Создание Telegram secret для Alertmanager (опционально, но рекомендуется):

1	`make monitoring-create-telegram-secret`

Следуйте инструкциям для создания Telegram бота: 1. Откройте Telegram и найдите @BotFather 2. Отправьте /newbot и следуйте инструкциям 3. Скопируйте bot token 4. Добавьте бота в группу 5. Получите chat ID из: https://api.telegram.org/bot<TOKEN>/getUpdates

Применение Ingress для внешнего доступа:

kubectl apply -f monitoring/manifests/ingress/

После применения Ingress будут доступны: - Grafana: https://grafana.internal.ai-ops.tech (admin/admin - изменить при первом входе) - VictoriaMetrics: https://victoriametrics.internal.ai-ops.tech - Prometheus: https://prometheus.internal.ai-ops.tech - Alertmanager: https://alertmanager.internal.ai-ops.tech

Локальный доступ через port-forward:

# Grafana
make monitoring-port-forward-grafana
# http://localhost:3000

# VictoriaMetrics
make monitoring-port-forward-vm
# http://localhost:8428

# Prometheus
make monitoring-port-forward-prometheus
# http://localhost:9090

# Alertmanager
make monitoring-port-forward-alertmanager
# http://localhost:9093

Примечание: - Мониторинг использует opt-in подход: метрики собираются только с подов/сервисов, у которых явно указана annotation prometheus.io/scrape: "true" или создан ServiceMonitor/PodMonitor - Prometheus хранит метрики локально 2 часа, затем отправляет в VictoriaMetrics для долгосрочного хранения (90 дней) - Grafana по умолчанию использует VictoriaMetrics как datasource - Pre-installed dashboards: Kubernetes Cluster Monitoring, Node Exporter Full, VictoriaMetrics Stats, Prometheus Stats, Alertmanager - Для включения сбора метрик с ваших приложений добавьте annotation на Deployment/Pod:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "9090"
  prometheus.io/path: "/metrics"

Дополнительные команды:

make monitoring-help                    # Справка по командам
make monitoring-logs-victoria-metrics  # Логи VictoriaMetrics
make monitoring-logs-prometheus        # Логи Prometheus
make monitoring-logs-alertmanager      # Логи Alertmanager
make monitoring-logs-grafana           # Логи Grafana
make monitoring-test-scrape            # Проверка scrape targets
make monitoring-test-remote-write      # Проверка remote_write в VM
make monitoring-test-alerts            # Отправка тестового алерта

Шаг 29: Установка Authentik

Команда:

# Сначала создайте секрет для Authentik
make authentik-create-secret

# Затем установите Authentik
make authentik-install

Ожидаемый результат: Authentik установлен и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota) 2. Создание секрета с паролями и ключами 3. Установка Authentik через helmfile 4. Подключение к внешнему PostgreSQL кластеру pg-public

Время выполнения: ~5-10 минут

Что проверять:

make authentik-status
kubectl get pods -n tech-authentik

Примечание: Authentik использует внешний PostgreSQL кластер, поэтому PostgreSQL должен быть установлен и работать.

Шаг 30: Установка SonarQube

Команда:

# Сначала создайте секреты для SonarQube
make sonarqube-create-secret
make sonarqube-create-monitoring-secret

# Затем установите SonarQube
make sonarqube-install

Ожидаемый результат: SonarQube установлен и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, storageclass) 2. Создание секретов для PostgreSQL и мониторинга 3. Установка SonarQube через helmfile 4. Подключение к внешнему PostgreSQL кластеру pg-public

Время выполнения: ~5-10 минут

Что проверять:

make sonarqube-status
kubectl get pods -n tech-sonarqube

Примечание: SonarQube использует внешний PostgreSQL кластер, поэтому PostgreSQL должен быть установлен и работать.

Шаг 31: Установка GlitchTip

Команда:

# Сначала создайте секрет для GlitchTip
make glitchtip-create-secret

# Затем установите GlitchTip
make glitchtip-install

Ожидаемый результат: GlitchTip установлен и работает.

Что происходит: 1. Применение манифестов ресурсных политик (limitrange, resourcequota, storageclass) 2. Создание секрета с паролями и ключами 3. Установка GlitchTip через helmfile 4. Подключение к внешнему PostgreSQL кластеру pg-public 5. Установка встроенного Valkey (Redis-совместимый)

Время выполнения: ~5-10 минут

Что проверять:

make glitchtip-status
kubectl get pods -n tech-glitchtip

Примечание: GlitchTip использует внешний PostgreSQL кластер, поэтому PostgreSQL должен быть установлен и работать.

Шаг 32: Установка Kubernetes Dashboard

Команда:

1	`make dashboard-install`

Ожидаемый результат: Kubernetes Dashboard установлен и работает.

Время выполнения: ~3-5 минут

Что проверять:

make dashboard-status
kubectl get pods -n tech-dashboard

Создание токена для доступа:

1	`make dashboard-create-token`

Примечание: Сохраните токен в безопасном месте. Он нужен для входа в Dashboard.

Настройка WireGuard Client VPN (опционально)

Шаг 33: Настройка VPN gateway

Команда:

cd ../..
make wireguard-client-setup

Ожидаемый результат: WireGuard client VPN настроен на первом master ноде.

Что происходит: 1. Настройка WireGuard client интерфейса на master1 2. Настройка маршрутизации для клиентского трафика 3. Подключение к Internal DNS

Время выполнения: ~2-3 минуты

Что проверять:

1	`make wireguard-client-status`

Шаг 34: Генерация клиентской конфигурации

Команда:

1	`make wireguard-client-config`

Ожидаемый результат: Создан файл с конфигурацией WireGuard клиента.

Что происходит: 1. Генерация ключей для клиента 2. Создание конфигурационного файла WireGuard 3. Сохранение файла на локальной машине

Где находится конфигурация: - Файл будет создан в директории проекта или указан в выводе команды

Использование: 1. Скопируйте конфигурационный файл на ваш клиент 2. Импортируйте в WireGuard клиент 3. Подключитесь к VPN

Примечание: После подключения к VPN вы сможете: - Доступ к сервисам через внутренние домены (например, auth.internal.ai-ops.tech) - Использовать Internal DNS для разрешения имен - Доступ к Kubernetes Dashboard и другим сервисам

Проверка и верификация

Проверка всех компонентов

Команда:

cd k8s
make help

Проверьте статус каждого компонента:

make longhorn-status
make postgres-status
make kafka-status
make redis-status
make minio-status
make logging-status
make vault-status
make nexus-status
make sonarqube-status
make glitchtip-status
make authentik-status
make dashboard-status
make monitoring-status
make ingress-status

Проверка ресурсов

Команда:

1	`make get-pod-resources`

Ожидаемый результат: Отображается информация о запрошенных ресурсах всех подов и использовании ресурсов нодами.

Что проверять: - Общее использование CPU и памяти не превышает доступные ресурсы нод - Все поды имеют resource requests и limits

Проверка storage

Команда:

kubectl get pvc -A
kubectl get storageclass

Ожидаемый результат: Все PVC созданы и в статусе Bound, Storage Classes доступны.

Проверка сетевой связности

Команда:

# Проверка подов в разных namespace
kubectl get pods -A -o wide

# Проверка сервисов
kubectl get svc -A

# Проверка ingress
kubectl get ingress -A

# Проверка ClusterIssuer и сертификатов
kubectl get clusterissuer letsencrypt-http
kubectl get certificate -A
kubectl describe certificate <certificate-name> -n <namespace>  # для проверки статуса конкретного сертификата

Чеклист установки

[ ] Kubernetes кластер работает, все ноды Ready
[ ] Кластерные ресурсы установлены (PriorityClasses, NetworkPolicies)
[ ] Метки узлов добавлены (node-type, disk-type, memory-type, disk-size)
[ ] Longhorn установлен, все 4 Storage Classes доступны (longhorn, longhorn-retain, longhorn-2replicas, longhorn-3replicas)
[ ] Все операторы установлены и работают
[ ] Все инстансы/кластеры созданы и работают
[ ] PostgreSQL кластер работает, можно подключиться
[ ] Kafka кластер работает
[ ] Redis кластер работает
[ ] MinIO tenant работает
[ ] Logging stack работает (Loki + Fluent Bit), логи собираются
[ ] Vault работает, можно получить root token
[ ] Nexus работает
[ ] Authentik работает
[ ] SonarQube работает
[ ] GlitchTip работает
[ ] Kubernetes Dashboard работает, токен создан
[ ] Monitoring Stack работает (VictoriaMetrics, Prometheus, Grafana, Alertmanager)
[ ] VictoriaMetrics работает, PVC создан
[ ] Prometheus работает, метрики собираются
[ ] Grafana работает, доступен через ingress или port-forward
[ ] Alertmanager работает, Telegram secret создан (если настроен)
[ ] PrometheusRule с алертами применены
[ ] Ingress для мониторинга применены (Grafana, VictoriaMetrics, Prometheus, Alertmanager)
[ ] Ingress NGINX работает
[ ] Cert-Manager работает
[ ] ClusterIssuer letsencrypt-http создан и в статусе Ready
[ ] TLS сертификаты созданы для всех ingress ресурсов (проверить: kubectl get certificate -A)
[ ] Internal DNS работает
[ ] Все поды в статусе Running
[ ] Все PVC в статусе Bound
[ ] Ресурсные политики применены (limitrange, resourcequota, pdb, networkpolicy для всех компонентов)
[ ] Ресурсы не превышают доступные на нодах

Troubleshooting

Проблемы с подключением к нодам

Симптомы: make ping не работает

Решения: 1. Проверьте SSH ключи: ssh -i /path/to/key root@<node-ip> 2. Проверьте доступность нод по сети: ping <node-ip> 3. Проверьте правильность IP адресов в .env 4. Убедитесь, что SSH сервис работает на нодах

Проблемы с WireGuard

Симптомы: WireGuard не работает, ноды не видят друг друга

Решения: 1. Проверьте статус: make wireguard-status 2. Проверьте логи на нодах: wg show на каждой ноде 3. Убедитесь, что порт 51820/udp открыт в firewall 4. Проверьте, что IP адреса в WireGuard сети не конфликтуют

Проблемы с Kubernetes

Симптомы: Кластер не работает, поды не запускаются

Решения: 1. Проверьте статус нод: kubectl get nodes 2. Проверьте системные поды: kubectl get pods -n kube-system 3. Проверьте логи: kubectl logs <pod-name> -n <namespace> 4. Проверьте события: kubectl get events -A --sort-by='.lastTimestamp'

Проблемы с Longhorn

Симптомы: Longhorn не работает, PVC не создаются

Решения: 1. Проверьте зависимости: make longhorn-prepare-nodes должен быть выполнен 2. Проверьте статус: make longhorn-status 3. Проверьте ноды: kubectl get nodes.longhorn.io -n longhorn-system 4. Проверьте логи Manager: kubectl logs -n longhorn-system -l app=longhorn-manager

Проблемы с операторами

Симптомы: Оператор не работает, CR не создаются

Решения: 1. Проверьте статус оператора: kubectl get pods -n <operator-namespace> 2. Проверьте логи оператора: kubectl logs -n <operator-namespace> <operator-pod> 3. Убедитесь, что Longhorn установлен (для операторов, использующих storage) 4. Проверьте RBAC: kubectl get clusterrole,clusterrolebinding | grep <operator>

Проблемы с приложениями

Симптомы: Приложение не запускается или не работает

Решения: 1. Проверьте статус: kubectl get pods -n <app-namespace> 2. Проверьте логи: kubectl logs <pod-name> -n <app-namespace> 3. Проверьте события: kubectl describe pod <pod-name> -n <app-namespace> 4. Убедитесь, что зависимости установлены (например, PostgreSQL для Authentik/SonarQube/GlitchTip) 5. Проверьте секреты: kubectl get secrets -n <app-namespace>

Полезные команды для диагностики

# Просмотр всех подов
kubectl get pods -A

# Просмотр событий
kubectl get events -A --sort-by='.lastTimestamp' | tail -20

# Просмотр ресурсов нод
kubectl top nodes

# Просмотр ресурсов подов
kubectl top pods -A

# Просмотр логов пода
kubectl logs <pod-name> -n <namespace> --tail=100

# Описание пода (для просмотра событий и условий)
kubectl describe pod <pod-name> -n <namespace>

# Просмотр PVC
kubectl get pvc -A

# Просмотр Storage Classes
kubectl get storageclass

# Просмотр PriorityClasses
kubectl get priorityclass

# Просмотр NetworkPolicies
kubectl get networkpolicy -A

# Просмотр меток узлов
kubectl get nodes --show-labels | grep -E "node-type|disk-type|memory-type|disk-size"

# Просмотр сервисов
kubectl get svc -A

Следующие шаги

После успешной установки всех компонентов:

1. Настройка backup

Настройка backup для PostgreSQL
Настройка backup для Vault
Настройка backup для Longhorn volumes

3. Настройка безопасности

Настройка Network Policies
Настройка Pod Security Policies
Настройка RBAC
Регулярное обновление компонентов

4. Документация по компонентам

Подробная документация по каждому компоненту находится в соответствующих директориях: - Longhorn - PostgreSQL - Kafka - Redis - MinIO - Vault - Nexus - SonarQube - Authentik - GlitchTip - GitLab Runner - Dashboard - Logging - Monitoring - Ingress

5. Обновление компонентов

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

1	`make <component>-update`

Например:

make postgres-update-operator
make kafka-update-operator
make longhorn-update

6. Масштабирование

При необходимости можно масштабировать компоненты: - Добавление новых нод в кластер - Увеличение реплик приложений - Увеличение размера storage

Поздравляем! Ваша инфраструктура установлена и готова к работе. 🎉

Если у вас возникли вопросы или проблемы, обратитесь к документации конкретных компонентов или разделу Troubleshooting.

На странице