Початок роботи з ArgoCD
Якщо у вашому кластері постійно з’являються рандомні правки, зроблені через kubectl edit, а ви вже не пам’ятаєте, чим відрізняється конфігурація на проді від того, що лежить у репозиторії — вам потрібен ArgoCD.
Простими словами: це розумний контролер, який робить ваш Kubernetes-кластер дзеркалом вашого репозиторію. Якщо в Git написано «має бути 3 репліки», а в кластері їх 2 — ArgoCD це виправить.
В основі лежить концепція GitOps. Це підхід, де ви не запускаєте команди в консолі вручну, а описуєте бажаний стан інфраструктури в коді (YAML, Helm, Kustomize). Git стає єдиним джерелом істини, а будь-яка зміна в кластері починається з git commit.
Чому всі обирають ArgoCD?
- Безпека: на відміну від класичних CI-систем (як Jenkins чи GitLab CI), ArgoCD не потребує зовнішнього доступу до вашого кластера. Він працює всередині периметра і сам тягне зміни з Git.
- Наочність та візуалізація: ви отримуєте вебінтерфейс із детальним деревом ресурсів. Це допомагає миттєво зрозуміти архітектуру застосунку.
- Повний аудит та легкі ролбеки: оскільки кожна зміна зафіксована в Git, ви завжди бачите історію: хто, коли та навіщо вніс правку. Якщо новий деплой виявився невдалим, ролбек — це просто git revert у репозиторії.
- Універсальність: ArgoCD однаково добре працює з чистими YAML-маніфестами, Helm-чартами та Kustomize.
Важливий момент: не плутайте ArgoCD з CI-інструментами (як-от GitHub Actions). ArgoCD не збирає ваш код і не створює Docker-образи. Його робота починається тоді, коли образ уже лежить у реєстрі, а оновлений маніфест — у Git. Це інструмент доставки (Continuous Delivery).
Швидкий старт в ArgoCD: встановлення та налаштування
Перш ніж ми перейдемо до команд, переконайтеся, що ваш фундамент готовий. Вам знадобляться:
- встановлений
kubectl; - налаштований kubeconfig (знаходиться в
~/.kube/config); - робочий CoreDNS у кластері.
1. Інсталяція ArgoCD
Ми рекомендуємо створювати виділений namespace (ізольований простір). Це дозволяє тримати всі системні ресурси ArgoCD в одному місці й не змішувати їх з вашими бізнес-застосунками.
kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
2. Налаштування доступу
Після встановлення сервіс argocd-server має внутрішній тип ClusterIP. Щоб відкрити панель керування у браузері, оберіть один із наступних варіантів залежно від вашого середовища:
- Port Forwarding (тимчасовий доступ)
Найшвидший спосіб, який не потребує змін у конфігурації кластера. Ви створюєте прямий тунель зі свого комп’ютера до сервісу ArgoCD.
Команда для запуску:
kubectl port-forward svc/argocd-server -n argocd 8080:443
Адмінка стане доступною за адресою: https://localhost:8080.
Примітка: цей метод працює лише поки запущена команда в терміналі.
- Service Type: LoadBalancer (для хмарних середовищ)
Якщо ви використовуєте керований Kubernetes у хмарі або локальний кластер із підтримкою балансувальників (наприклад, MetalLB), ви можете призначити ArgoCD зовнішню IP-адресу.
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
Як дізнатися адресу:
Зачекайте декілька хвилин, поки провайдер виділить IP, і перевірте статус:
kubectl get svc argocd-server -n argocd
Шукайте адресу в колонці EXTERNAL-IP.
- Ingress (для постійного доступу на домені)
Цей метод використовується у продакшені. Він дозволяє налаштувати доступ через зрозуміле ім’я (наприклад, argo.itedu.com) з використанням SSL-сертифікатів.
Приклад маніфесту для Ingress ↓
Створіть файл argocd-ingress.yaml та застосуйте його:
YAML
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: argocd-server-ingress
namespace: argocd
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
rules:
- host: argocd.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: argocd-server
port:
number: 443
Команда для застосування:
kubectl apply -f argocd-ingress.yaml
3. Авторизація: де взяти пароль?
ArgoCD при першому запуску сам генерує пароль для логіна admin. Це робиться для того, щоб ваш щойно встановлений інструмент не стояв відкритим для всіх.
Дістати пароль можна однією командою:
argocd admin initial-password -n argocd
Майте на увазі: цей пароль лише тимчасовий. Як тільки ви залогінилися, змініть його через команду:
argocd account update-password
Потім видаліть старий:
argocd-initial-admin-secret
Деплой першого застосунку
Для прикладу ми використаємо стандартний застосунок Guestbook із репозиторію розробників ArgoCD. Це допоможе зрозуміти механіку без необхідності писати власні маніфести на старті.
Крок 1. Створення об’єкта Application
Application — це кастомний ресурс Kubernetes (CRD), який каже ArgoCD: «Стеж за цією папкою в цьому репозиторії та синхронізуй її з цим кластером».
Виконайте команду для створення:
argocd app create guestbook \
--repo https://github.com/argoproj/argocd-example-apps.git \
--path guestbook \
--dest-server https://kubernetes.default.svc \
--dest-namespace default
Крок 2. Перевірка статусу
Відразу після створення застосунок матиме статус OutOfSync. Це абсолютно нормальна ситуація для першого запуску.
Що це означає: ArgoCD успішно прочитав маніфести в Git, але побачив, що в кластері Kubernetes ще немає відповідних об’єктів. Тобто бажаний стан (Git) не збігається з реальним (кластер).
Перевірити статус можна командою:
argocd app get guestbook
Крок 3. Синхронізація
Щоб ArgoCD нарешті створив усі ресурси в кластері, потрібно виконати синхронізацію:
argocd app sync guestbook
Що відбудеться після натискання Enter?
- ArgoCD викачає актуальні маніфести з Git.
- Автоматично запустить аналог kubectl apply для всіх файлів у папці.
- Промоніторить стан створених ресурсів.
Коли процес завершиться, статус зміниться на Synced (конфігурації збігаються) та Healthy (всі поди успішно запустилися і пройшли перевірки). Тепер ваш перший застосунок працює під повним контролем GitOps.
Замість висновків
ArgoCD значно спрощує життя, але на реальних проєктах ви обов’язково зіткнетеся з кількома нюансами, до яких краще підготуватися заздалегідь:
- Відсутність вбудованих ролбеків за метриками: ArgoCD синхронізує маніфести. Якщо ви задеплоїли кривий код, який успішно запустився (стан Running), але при цьому кладе базу або видає 500-ті помилки — ArgoCD сам його не відкотить. Для автоматичних ролбеків на основі SLO вам знадобиться додатковий інструмент, наприклад Argo Rollouts.
- Масштабування та мультикластерність: коли кількість кластерів зростає до десятків, керування ними через один екземпляр ArgoCD стає складним. Виникає навантаження на repo-server та питання до безпеки доступів.
- Початкове розгортання інфраструктури: хто деплоїть сам ArgoCD? Зазвичай для цього використовують окремі скрипти або Helm, щоб підняти базову інфраструктуру, яка вже потім почне тягнути все інше через GitOps.
- Дисципліна в Git: тепер ваш репозиторій — це «червона кнопка». Будь-який випадковий комміт у гілку, яку моніторить ArgoCD, миттєво полетить у кластер. Це вимагає суворого процесу рев’ю та тестування маніфестів.
Бажаємо успіхів!