Multi-Cluster Kubernetes в облаке Yandex Cloud или гибридный Cloud.

Продолжение статьи о Kubernetes сейчас поговорим о мегакластере который будет отвечать за контур разработки и DEV & PROD.
Статья будет полезна тем кто работает с Kubernetes в обоих средах или тем кто только начал свою деятельность как разработчик и желает попробовать все возможности.

Для начала ответим на вопрос почему Yandex Cloud, а не что то иное? Просто у меня с этим облаком именно такая связка, а построить аналог в том же TimeWeb как бы проблем нет.

Начнем про архитектуру нашего кластера.

Из прошлой статьи наша конфигурация дома

MASTER NODE (1 шт)

• 2 CPU / vCPU
• 2 GB RAM
• 100 GB HDD

WORKER NOD (2 шт, может быть бесконечно с ресурсами по возможности)

• 8 CPU / vCPU
• 16 GB RAM
• 100 GB HDD

Архитектура kubernetes в облаке Yandex Cloud при создании кластера делал вот так:

Скрин экрана из личного кабинета

Для того чтоб экономить денежки при настройке ставьте минимальные ресурсы, но "Тим мастера" сразу задаем на 3 хоста. Это объясняется тем что в зонах доступности у нас будет 3 сети, как на скрине ниже.

Это обеспечит максимальную доступность в рамках облака и не только.

Скрикрин из личного кабинета при настройке тарифа.

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

Теперь наступает эра теории. Ее будет много но, не зная ее лучше в гибридные облака не соваться от слова совсем, даже просто поиграть.

Ключевые концепции, которые нужно понять и запомнить:

1. Независимость Control Plane: Мастеры каждого кластера управляют только своими нодами. Не существует нативного способа заставить мастера из кластера А управлять нодами из кластера Б. Мы работаем на уровне приложений и сервисов.
2. Сетевой connectivity: Самое важное требование — между подами в разных кластерах должно быть сетевое соединение. Это часто достигается с помощью VPN (например, WireGuard, OpenVPN, мы рассмотрим еще одну технологию доступную на Яндекс облаке) или VPC Peering (если оба кластера в одном облаке, но разных VPC - это не наша тема). Для локального и облачного кластера вам нужен VPN-туннель между вашей локальной сетью и облачной VPC.
3. Единая точка входа: Пользователи и системы не должны знать, в каком кластере работает их приложение. Им нужен один домен или IP-адрес. Вот тут уже надо начинать думать о своем домене служебного характера, а так же промышленной среды. Рекомендую их иметь разные.

Подходы к связыванию кластеров

1. С помощью GitOps и единой точки управления (Наиболее современный, оптимальный по трудозатратам настройки и поддержки способ)
Это не создает "волшебного" единого кластера, а предоставляет единый центр управления для развертывания приложений и политик в оба кластера одновременно.

Как это работает:

• Вы настраиваете инструмент GitOps (например, ArgoCD или FluxCD) в одном из кластеров, лучше на отдельной виртуальной машине зарезервированной в 2-х.
• Этот инструмент подключается к обоим кластерам (с помощью их kubeconfig файлов которые рассмотрим позже).
• В Git-репозитории у вас описаны манифесты для всех приложений. Трудоемкий процесс, но сделав один раз голова не болит полжизни.
• ArgoCD/FluxCD автоматически развертывает эти приложения одновременно в оба кластера.
• Для сервисов, которые должны быть доступны извне, вы используете Ingress-контроллеры и менеджер сертификатов (например, cert-manager) в каждом кластере можно прикрутить и cerbot но там бубен надо применить.

Как решается вопрос доступа к сервисам:

• Вариант А: Использование Global Load Balancer. Сервисы в обоих кластерах связываются через Ingress (например, Nginx Ingress Controller). А Yandex Cloud при помощи своего сервиса ALB решает вопрос доступа или продвинутое решение (например, MetalLB в локальном кластере + BGP) настраивается на проверку здоровья эндпоинтов в обоих кластерах и распределяет трафик между ними. Опять же MetalLB доступно в Yandex Cloud, но цена кусается на мой взгляд.
• Вариант Б: Использование Service Mesh (Самый продвинутый). Вы внедряете Istio или Linkerd в оба кластера и настраиваете Multi-Cluster Service Mesh. Это позволяет сервисам из одного кластера transparently общаться с сервисами в другом кластере, как если бы они были в одной сети. Это решает проблему network connectivity и discovery. Рассматривать не буду, сложно и не бесплатно, но в работе идеально.

Какие плюсы:

• Истинная GitOps-практика, где достигается высокая автоматизация.
• Отказоустойчивость: если один кластер падает, второй продолжает работать. Мы теряем грань между Prod & Dev но зато у нас мегаструктура.
• Гибкость: можно легко тестировать в одном кластере, а продакшен держать в другом и возвращаясь на пункт выше, мы управляем всем.

Ну вот и минусы:

• Требует глубоких знаний и настройки. Причем знания не только самого кубера, но и GIT и инструментов которые позволяют это настраивать.
• Service Mesh — это сложная тема сама по себе. Ее надо начинать с сетевых основ.

2. С помощью инструментов вроде Liqo (Создание иллюзии единого кластера)

Liqo — это интересный проект, который реализует концепцию Kubernetes Peering. Он создает виртуальные ноды в вашем локальном кластере, которые на самом деле являются отражением нод из облачного кластера (и наоборот).

Как это работает:

• Вы устанавливаете Liqo в оба кластера.
• Кластеры "знакомятся" друг с другом.
• В вашем локальном кластере появляются новые "виртуальные" ноды, которые представляют вычислительные ресурсы облачного кластера.
• Когда вы развертываете pod, вы можете с помощью labels и taints указать, где он должен запуститься: на локальных нодах или на "виртуальных" (т.е. фактически в облаке).

Плюсы подхода:

• Создает магическую иллюзию одного большого кластера, но требует Х2 ресурсов.
• Не нужно думать о сетевой маршрутизации между сервисами — Liqo ее организует, как понимаете подходит для не очень опытных.
• Можно легко "переливать" нагрузки между кластерами, ну не очень легко но можно :).

Минусы:

• Молодой и развивающийся проект (потенциально менее стабильный), а так же не подходит для больших проектов.
• Добавляет уровень абстракции, который может усложнить дебаггинг, ну и в целом усложняет систему утяжеляя логи и работу.

3. С помощью Federation (Устаревший, подход но мы протеорию)

Kubernetes Cluster Federation (KubeFed) — это проект, который раньше был под эгидой SIG, но сейчас считается устаревшим и не рекомендуется к использованию в продакшене. Он пытался быть стандартным способом управления несколькими кластерами, но был очень сложным и не получил широкого распространения. Его преемником можно считать GitOps-подход. На заре совей эры работы с Kubernetes, я игрался с этим инструментом, но как и многие не осилил в виду сложности.

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

ArgoCD - основно Multi-Cluster Kubernetes.

ArgoCD — это мощный и удобный для меня инструмент в реализации GitOps для Kubernetes. Ниже подробное пошаговое руководство, как использовать ArgoCD для управления развертываниями в двух наших кластерах (локальном и облачном), мой личный опыт.

Архитектура решения

Схема Multi-Cluster Kubernetes собранная в моем решении

Мы устанавливаем ArgoCD в один из кластеров (я это сделал локально, как более управляемый и доступный мне по ресурсам). Этот экземпляр ArgoCD будет управлять приложениями в обоих кластерах, синхронизируя их с состояниями, описанными в моем Git-репозитории.

Обязательная сборка предварительных требований

1. Сетевой доступ: Убедитесь, что ваша рабочая станция (где установлен kubectl) имеет доступ к API-серверам обоих кластеров. У вас должны быть настроены контексты kubectl. В прошлой статье для этого я готовил виртуалку и скрипты. Проверяем через: kubectl config get-contexts. Вы должны видеть оба ваших кластера.
2. Доступ кластеров друг к другу: Для Multi-Cluster общения сервисов нужен VPN, как обсуждалось ранее. Для самого ArgoCD это не обязательно, так как он общается с API-серверами кластеров.
3. Git-репозиторий: У вас должен быть Git-реpo (на GitHub, GitLab или др.), где вы будете хранить манифесты ваших приложений. Для начала можно использовать простые YAML-файлы.

Когда все проверили приступаем к самой захватывающей теме, установка.

Пошаговая инструкция установки ArgoCD

Еще раз напомню, что для установки ArgoCD я выбираю локальный кластер!

1. Переключитесь на контекст локального кластера

kubectl config use-context <указываем имя вашего кластера>

2.Создайте namespace для ArgoCD

kubectl create namespace argocd

3.Установите ArgoCD

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Этим действием мы установим все необходимое для ArgoCD

4. Дождитесь запуска всех подов. Скорость зависит от железа.

После окончания (сообщит вам кластер), проверяем командой состояние подов. Они все должны быть в состоянии Runing.

kubectl get pods -n argocd --watch

Мало вероятно, что будут проблемы, но если будут смотрим логи кубера. Что может пойти не так:
- Не хватит ресурсов (места, процессора, памяти и так далее) если железка слабовата.
- Не хватило пользователю прав. Если в настройке кластера были какие то проблемы с правами (не верно запущенные поды, или системные службы, то ArgoCD не стартанет).

Теперь о ArgoCD Web UI

Смотреть красивые картинки приятно

1.Измените тип сервиса на LoadBalancer/NodePort (для доступа извне).

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Замечания к команде

• По умолчания ArgoCD получит внутренний IP, если нет то назначаем руками (в офицальной документации все есть и просто).
• Для локального кластера можно использовать NodePort, я же все закрутил на Ingress! Это упрощенный способ но для меня приемлем так как мой локальный кластер спрятан за шлюзом

2. Получите пароль для пользователя admin
Пароль генерируется автоматически и хранится в хэшированом виде

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

3. Посмотреть как смотрится наружу на ArgoCD

kubectl get svc -n argocd argocd-server

Открываем браузер и идем по адресу http://ваш ИП из команды (порт по умолчанию 80). Войдите под admin и полученным паролем.

Добавляем второй кластер в ArgoCD

Теперь нам нужно дать ArgoCD, работающему в локально, разрешения на управление вашим облачным кластером.

1.Переключитесь на контекст вашего локального кластера

kubectl config use-context имя вашего внешнего кластера

2.Создайте ServiceAccount и привяжите к ней роль cluster-admin (такой подхот только для тестов, в рабочей среде все надо делать серьезней)

- Создаем ServiceAccount 'argocd-manager' в namespace 'kube-system'
kubectl create serviceaccount argocd-manager -n kube-system

- Привязываем роль cluster-admin к этому ServiceAccount
kubectl create clusterrolebinding argocd-manager-rolebinding --clusterrole=cluster-admin --serviceaccount=kube-system:argocd-manager

3. Получаем токен для созданного ServiceAccoun

- Найдите имя секрета, связанного с ServiceAccount
kubectl get secrets -n kube-system | grep argocd-manager

- Получите токен из этого секрета
kubectl describe secret <secret-name> -n kube-system

4.Получите адрес API-сервера и CA сертификат вашего облачного кластера

- Получить адрес API-сервера
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

- Получить CA сертификат (обычно он уже в конфиге kubectl)
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d

Работу в консоли закончили, теперь идем в GUI

1. Добавьте кластер через ArgoCD UI

- В веб-интерфейсе ArgoCD перейдите в Settings -> Clusters.
- Нажмите Add Cluster.
- Введите данные:
Cluster Name: Придумайте понятное имя (например, on-ya01-cluster).
Server URL: Вставьте адрес API-сервера
Cluster Resources Namespace: Оставьте пустым.
Config: Выберите "Use bearer token for authentication".
Bearer Token: Вставьте токен из шага 3. (ServiceAccoun)
Skip server verification: Будьте осторожны! Поставьте галочку, только если у вас проблемы с сертификатами (например, самоподписанные в локальном кластере). Лучше правильно настроить CA.
Если не ставите галочку, вам нужно будет добавить CA сертификат в соответствующее поле.

-Нажмите Create.

Теперь ваш облачный кластер появится в списке кластеров, которыми управляет ArgoCD.

Создайте Application для развертывания в оба кластера (простейший пример)

1. Подготовьте манифесты в Git

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

MyApp/
|── kustomize/
│ |── base/
│ │ |── deployment.yaml
│ │ |── service.yaml
│ │ └── kustomization.yaml
│ └── overlays/
│ |── cloud/
│ │ └── kustomization.yaml
│ └── local/
│ └── kustomization.yaml
└── argo-apps/
└── my-app-project.yaml

- base/ содержит общие манифесты для приложения.

- overlays/cloud/ и overlays/local/ могут содержать специфические настройки для каждого кластера (например, разные переменные окружения или ресурсы).

- argo-apps/my-app-project.yaml — манифест Application ArgoCD.

2. Создайте Application через UI или YAML

- В интерфейсе ArgoCD нажмите New App.

- Application Name: MyApp-ya01

- Project: default

- Sync Policy: Automatic (для автоматической синхронизации при пуше в Git)

- Repository URL: URL вашего Git-реpo

- Path: kustomize/overlays/cloud (путь к конфигам для облака)

- Cluster: Выберите ваш облачный кластер из списка

- Namespace: default (или создайте свой)

- Нажмите Create.

Повторите те же шаги для создания второго приложения MyApp-ya01-local, указав:

• Path: kustomize/overlays/local
• Cluster: Выберите ваш локальный кластер из списка.

Или создайте один ApplicationSet, который автоматически создаст приложения для всех кластеров, описанных в репозитории. Это более продвинутый и рекомендуемый способ.

3. Наслаждайтесь!

А вот теперь пришла пора и проверить что мы насоздавали. Теперь, когда вы сделаете git push в ваш репозиторий, ArgoCD автоматически обнаружит изменения и развернет обновленную версию вашего приложения в оба кластера одновременно. В веб-интерфейсе вы можете видеть статус развертывания, состояние подов и логов для каждого кластера.

Это и есть сила GitOps: ваша инфраструктура и конфигурация версионируются в Git, а ArgoCD гарантирует, что реальное состояние кластеров всегда соответствует описанному в репозитории.

Итоги.

Что можно сказать в завершение, Multi-Cluster Kubernetes и ArgoCD - это конечно серьезный инструмент о котором можно много чего сказать и написать. Я создавал эту пошаговую инструкцию без лишних картинок и консолей, дабы не отвлекать от самой сути.

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

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

Если вам нужна консультация по архитектуре, сопровождение команды профессионалов, вы можете писать в комментари или мне в TG будем на связи!

Продолжение будет! Подписывайтесь.