Rancher: управление кластерами Kubernetes

Один кластер Kubernetes ещё можно вести вручную: kubectl, helm и десяток манифестов в репозитории. Когда кластеров становится пять, а команд — три, начинается путаница с доступами, версиями и обновлениями. Rancher — открытая платформа, которая собирает кластеры в единую панель: выдаёт доступы, разворачивает RKE2 и K3s, следит за мониторингом и обновлениями. Ниже — установка и повседневная работа без лишней магии.

Что даёт Rancher и чего он не делает

Rancher Manager — это control plane над кластерами, а не ещё один Kubernetes. Он хранит инвентарь, пользователей, роли и настройки, а рабочие нагрузки остаются в downstream-кластерах. Панель подключает готовые кластеры, создаёт новые через RKE2 или K3s, выдаёт kubeconfig, группирует пространства имён в проекты и централизованно применяет политики.

Важная граница: Rancher не заменяет kubectl и не чинит приложение. Если pod падает из-за нехватки памяти, панель покажет статус, но разбираться придётся в логах и метриках. И ещё: сам Rancher — критичный сервис. Его база и сертификаты должны попадать в резервные копии, иначе восстановление доступов превратится в ручную работу.

Установка на одну машину

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

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  --privileged \
  -v rancher-data:/var/lib/rancher \
  -e CATTLE_BOOTSTRAP_PASSWORD='change-me-now' \
  rancher/rancher:stable

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

Установка через Helm

Для продакшена ставят несколько реплик в отдельном кластере и собственный TLS. Нужен cert-manager или заранее подготовленный секрет с сертификатом. Ниже — вариант с выпуском сертификата и доменом.

helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
kubectl create namespace cattle-system
helm install rancher rancher-stable/rancher \
  --namespace cattle-system \
  --set hostname=rancher.example.com \
  --set replicas=3 \
  --set ingress.tls.source=letsEncrypt \
  --set letsEncrypt.email=admin@example.com

Несколько реплик требуют общего хранилища и настроенного ingress. Не ставьте Rancher в тот же кластер, которым он управляет, если это единственная площадка: падение кластера заберёт и панель. Проверьте, что DNS-имя указывает на балансировщик, а сертификат выпускается до первого входа.

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

В панели выберите Cluster Management, затем Import Existing. Rancher сгенерирует ссылку с одноразовым манифестом. Его применяют в целевом кластере, и там появляется агент cattle-cluster-agent.

kubectl apply -f https://rancher.example.com/v3/import/xxxxx.yaml
kubectl -n cattle-system get pods
kubectl -n cattle-system logs deploy/cattle-cluster-agent --tail=50

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

RKE2 и создание кластера из панели

Rancher может развернуть RKE2 на серверах, которые вы указали. Установка начинается с одного узла, остальные присоединяются токеном. Конфигурация лежит в файле, поэтому её удобно версионировать.

curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=stable sh -
systemctl enable --now rke2-server
cat /var/lib/rancher/rke2/server/node-token
cat /etc/rancher/rke2/rke2.yaml

В конфиге /etc/rancher/rke2/config.yaml задают server и token для дополнительных узлов, а также параметры etcd и сети. После установки kubeconfig лежит в /etc/rancher/rke2/rke2.yaml. Панель показывает версии компонентов и позволяет запускать обновление через System Upgrade Controller, но окно обслуживания всё равно выбирает человек.

Проекты, пространства имён и доступы

Проект — это группа пространств имён с общими квотами и ролями. Пользователь получает роль на кластер, проект или namespace, а не сырой набор прав в YAML. Аутентификацию подключают через OIDC, LDAP или локальных пользователей; для продакшена лучше внешний провайдер и группы.

• Cluster Owner — полный доступ, включая управление кластером.
• Project Member — работа внутри проекта без прав на инфраструктуру.
• Read Only — просмотр ресурсов и логов без изменений.
• Сервисные аккаунты — для CI, с токеном и минимальной ролью.

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

Мониторинг, обновления и резервные копии

Чарт rancher-monitoring ставит Prometheus, Grafana и Alertmanager в выбранный кластер. Для начала хватит встроенных дашбордов и алертов на недоступные узлы, заполнение диска и перезапуски pod. Обновления RKE2 выполняют контроллером плана, а etcd-снимки настраивают в конфиге.

helm repo add rancher-charts https://charts.rancher.io
helm install rancher-monitoring rancher-charts/rancher-monitoring \
  -n cattle-monitoring-system --create-namespace
kubectl -n cattle-monitoring-system get pods

Для etcd в RKE2 включают snapshot и задают расписание, например каждые шесть часов с хранением десяти копий. Отдельно ставят Rancher Backup: он сохраняет настройки панели, пользователей и проекты. Проверка восстановления обязательна — копия, которую ни разу не разворачивали, считается несуществующей.

Диагностика типичных сбоев

Порядок разбора почти всегда одинаков: смотрим pod в cattle-system, затем ingress и сертификат, затем агент в downstream-кластере. Ошибки авторизации чаще связаны с истёкшим сертификатом или рассинхронизацией времени, а не с базой.

kubectl -n cattle-system get pods,svc,ingress
kubectl -n cattle-system logs deploy/rancher --tail=100
kubectl get events -A --sort-by=.lastTimestamp | tail -20
kubectl -n cattle-fleet-system logs deploy/fleet-controller --tail=50

Если панель открывается, но кластеры показываются как Offline, проверяйте сеть от агента к серверу и валидность CA. Если падает webhook, новые ресурсы не создаются — отключайте его только для диагностики и сразу возвращайте. Пустой экран после входа часто означает проблему с ingress или путём до API.

Чек-лист перед продакшеном

• Отдельный кластер под Rancher, несколько реплик, снимки etcd.
• HTTPS с валидным сертификатом, порт 80 только для редиректа.
• SSO и группы вместо ручных пользователей, минимальные роли.
• Резервные копии панели и проверенное восстановление.
• Алерты на недоступность агентов, диски и сертификаты.

Итог

Rancher закрывает рутину управления парком кластеров: единый вход, роли, установка RKE2, мониторинг и обновления. Начинать стоит с тестовой панели и одного импортированного кластера, затем переносить доступы и бэкапы. Главное — относиться к самой панели как к продакшен-сервису: с резервной копией, TLS и понятным владельцем.