Вступление

Если вы работаете с Kubernetes, то, скорее всего, используете kubectl, kustomize или Helm для развёртывания сервисов в кластере. Про последнюю утилиту я уже писал статью — можно посмотреть тут. Тогда я рассказал о своём опыте внедрения этого инструмента для собственных нагрузок и сравнил подходы kubectl apply и helm install.

Управление конфигурацией в Kubernetes может осуществляться с помощью различных инструментов. Помимо Helm, можно использовать просто YAML-манифесты или же kustomize. Для каждого из этих инструментов предусмотрена своя команда.

В одном git репозитории вы можете хранить:

• yaml манифесты для kubectl;

• kustomization.yaml, yaml манифесты и патчи для kustomize;

• values.yaml для helm.

Такой подход называется GitOps. Он подразумевает, что вся конфигурация хранится декларативно в едином репозитории. Однако есть и недостатки: нужно вручную создавать и обновлять манифесты. Если кластером управляет не один сотрудник, важно убедиться, что все разработчики согласовывают изменения и вносят их в git-репозиторий. В таком случае мы не можем обеспечить концепцию единого источника истины (SSOT), которого требует GitOps подход.

Оглавление

Немного теории об Argo CD

Argo CD — инструмент непрерывной доставки ПО в Kubernetes. Argo CD полностью берет на себя задачи по синхронизации Git репозитория и кластера Kubernetes. Он сам отслеживает все изменения в коде и затем автоматически обновляет ресурсы в кластере.

Argo CD реализован в виде контроллера Kubernetes, который постоянно отслеживает запущенные приложения и сравнивает текущее состояние (live state) с целевым состоянием (desired state). Он имеет замечательный UI, с помощью которого можно управлять процессом синхронизации, просматривать разницу между состояниями, следить за ресурсами приложений.

Argo CD добавляет в кластер кастомные ресурсы (CRD), при помощи которых можно описывать его конфигурацию. Мы можем взаимодействовать с Argo CD при помощи консольной утилиты или через графический интерфейс. В данной статье будет использоваться второй способ.

Установка

Установим Argo CD в отдельное пространство имён:

# kubectl create namespace argocd
namespace/argocd created

# kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
<...>

Проверим, что все поды перешли в статус Running:

# kubectl -n argocd get pods
NAME                                                READY   STATUS    RESTARTS   AGE
argocd-application-controller-0                     1/1     Running   0          66s
argocd-applicationset-controller-744b76d7fd-nfl66   1/1     Running   0          67s
argocd-dex-server-5bf5dbc64d-tp9ms                  1/1     Running   0          67s
argocd-notifications-controller-84f5bf6896-h48pk    1/1     Running   0          67s
argocd-redis-74b8999f94-m6vsj                       1/1     Running   0          67s
argocd-repo-server-57f4899557-bnz46                 1/1     Running   0          66s
argocd-server-7bc7b97977-8wdxx                      1/1     Running   0          66s

У нас так же должен был появиться сервис argocd-server, при помощи которого мы можем получить доступ к API или UI Argo CD. По умолчанию его type: ClusterIP, но при необходимости (не советую) можно изменить на LoadBalancer или NodePort. В этой статье я буду открывать доступ посредством kubectl port-forward:

# kubectl -n argocd port-forward svc/argocd-server 8080:443
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Теперь перейдем по адресу http://localhost:8080:

Получим пароль для пользователя admin из Kubernetes Secret:

# kubectl -n argocd get secret/argocd-initial-admin-secret -o json | jq .data.password -r | base64 -d
IKFWGsjONnt5hLV1

Успешно залогинимся и увидим, что у нас всё пусто:

Подключаем репозиторий

Создадим секрет с информацией о подключении к GitHub репозиторию. Так как репозитории публичный, нам понадобится только ссылка:

apiVersion: v1
kind: Secret
metadata:
  name: github-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/AzamatKomaev/argo-demo-habr

# kubectl apply -f https://raw.githubusercontent.com/AzamatKomaev/argo-demo-habr/main/repo.yaml
secret/github-repo сreated

Убедимся, что репозитории успешно подключился:

Разворачиваем nginx

Начнём с простого: развернем три реплики с Nginx с сервисом ClusterIP. Сейчас у нас следующая структура репозитория:

В директории apps мы будем хранить все наши приложения. У каждой поддиректории будет app.yaml, который содержит ресурс Application. В manifests будут привычные нам YAML-манифесты.

Прежде чем создать app.yaml, взглянем на его содержимое:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx
  namespace: argocd  # тот же самый, где установлен ArgoCD
spec:
  project: default  # проект по-умолчанию
  destination:
    server: "https://kubernetes.default.svc"  # Kubernetes API адрес. Т.к ArgoCD запущен в тот же кластере, то путь до ClusterIP 
    namespace: nginx-demo  # пространство имен, где будут созданы ресурсы
  sources:
  - repoURL: https://github.com/AzamatKomaev/argo-demo-habr.git  # ссылка на Git-репозиторий
    targetRevision: HEAD  # указание на ветку, с котрой стоит синхронизировать состояние репозитория
    path: apps/nginx/manifests  # абсолютный путь до директории с манифестами
      
  syncPolicy:
    automated:
      prune: true  # разрешает удаление ресурса
      selfHeal: true  # разрешает ArgoCD самому приводить состояние кластера в соответствии с Git-репозиторием 
    syncOptions:
    - CreateNamespace=true  # создавать пространство имён, если оно не существует

Применим манифест:

# kubectl apply -f https://raw.githubusercontent.com/AzamatKomaev/argo-demo-habr/main/apps/nginx/app.yaml
application.argoproj.io/nginx created

Теперь взглянем на UI Argo CD. Там должно было появиться приложение nginx:

Тут же мы можем увидеть все развёрнутые ресурсы Kubernetes и их статус. Sync OK означает, что ресурсы приложения синхронизированы с Git-репозиторием. Healthy показывает, что все ресурсы развёрнуты успешно. Давайте убедимся, что все описанные ресурсы есть в пространстве имён:

# kubectl -n nginx-demo get all
NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-576c6b7b6-227dc   1/1     Running   0          8m33s
pod/nginx-deployment-576c6b7b6-27p4r   1/1     Running   0          8m33s
pod/nginx-deployment-576c6b7b6-gl24h   1/1     Running   0          8m33s

NAME                    TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/nginx-service   ClusterIP   10.43.25.85   <none>        80/TCP    8m33s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           8m33s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-576c6b7b6   3         3         3       8m33s

Разворачиваем Helm-чарт

Давайте теперь развернём Helm-чарт kube-prometheus-stack. С его помощью мы можем развернуть все необходимые компоненты для мониторинга кластера: kube-state-metrics для генерации метрик о состоянии Kubernetes кластера, Prometheus для сбора метрик, а также Grafana для визуализации собранных данных.

Создадим директорию monitoring внутри apps. Еще чуть глубже создадим директорию с названием Helm-чарта и там разместим файл app.yaml со следующим содержимым:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus
  namespace: argocd
spec:
  project: default
  destination:
    server: "https://kubernetes.default.svc"
    namespace: monitoring
  source:
    chart: kube-prometheus-stack
    repoURL: https://prometheus-community.github.io/helm-charts
    targetRevision: 60.1.0
    helm:
      releaseName: prometheus
      values: |
        grafana:
          enabled: true
          service:
            type: NodePort
            nodePort: 31234
          persistence:
            enabled: true
            accessModes:
              - ReadWriteOnce
            size: 5Gi
            finalizers:
              - kubernetes.io/pvc-protection

        defaultRules:
          create: false

        alertmanager:
          enabled: false

        prometheus:
          enabled: true

          prometheusSpec:
            storageSpec: 
              volumeClaimTemplate:
                spec:
                  accessModes: ["ReadWriteOnce"]
                  resources:
                    requests:
                      storage: 10Gi
          
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true
    

Теперь дерево нашего репозитория выглядит следующим образом:

На этот раз нам необходимо указать название и версию чарта, название релиза и актуальные значения (values.yaml). Обратите внимание на последний элемент в списке syncOptions. Если чарт содержит CRD, то у вас может появиться ошибка, связанная с большим размером данных ресурсов. Чтобы такой ошибки не возникло, необходимо добавить параметр ServerSideApply=true. Подробнее об этом тут.

Еще важно отметить, что Argo CD не использует helm install для установки чарта. Вместо этого он принимает манифесты, генерируемые командой helm template. Таким образом, Argo CD берёт на себя весь жизненный цикл приложения.

Применим манифест:

# kubectl apply -f https://raw.githubusercontent.com/AzamatKomaev/argo-demo-habr/main/apps/monitoring/kube-prometheus-stack/app.yaml
application.argoproj.io/prometheus created

У нас появилось второе приложение в Argo CD:

Подождем пока состояние приложения перейдёт в Healthy. В values релиза для доступа к Grafana мы указали service: NodePort и nodePort: 31234.

Я использую сервис с типом NodePort для быстрого доступа к Grafana. Не пренебрегайте безопасностью ваших приложений!

Попробуем перейти по адресу_узла:31234. Всё работает!

App-of-apps паттерн

Сейчас у нас только два приложения. Но ведь кластер может содержать 10, 100, 500, 10000 приложении.... И в таком случае нам нужно будет вручную принимать манифесты с Application. Есть выход - App-of-apps.

Суть заключается в том, что у нас есть корневое приложение, которое берёт под управление другие. С помощью этой схемы мы можем заставить Argo CD самому создавать и удалять добавленные в репозитории приложения.

Опишем такой Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  project: default
  destination:
    server: "https://kubernetes.default.svc"
    namespace: argocd
  sources:
  - repoURL: https://github.com/AzamatKomaev/argo-demo-habr.git
    targetRevision: HEAD
    path: apps/
    directory:
      recurse: true
      include: '**/app.yaml'
      
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

# kubectl apply -f https://raw.githubusercontent.com/AzamatKomaev/argo-demo-habr/main/root-app.yaml                                
application.argoproj.io/root-app created

Обратите внимание на элементы directory. recurse: true указывает на то, чтобы Application искал манифесты рекурсивно по всей директории apps/. С помощью include: '**/app.yaml' мы указываем приложению принимать файлы только с названием app.yaml. Такимобразом, под управление «родительского» приложения перейдут только другие, «дочерние», а обычные YAML-манифесты будут управляться как раз последними.

Вам может показаться, что вышеописанная схема достаточно сложна: необходимо для каждой пачки манифестов описывать свой app.yaml, затем указывать destination, source(-s) и другие параметры. Изначально я сделал так: Helm-чарты были отдельными приложениями, а обычные манифесты находились под контролем root-app. После увеличения количества таких ресурсов у root-app, я принял решение о дроблении манифестов на Application, что я считаю более правильным.

Вернёмся в интерфейс Argo CD. Появилось третье приложение. Перейдем в него и увидим, что теперь оно управляет двумя другими:

Переводим уже созданные сервисы под управление Argo CD

Я решил внедрять Argo CD в наш кластер уже тогда, когда в нем было развернуто несколько десятков приложений. Я опасался того, что возникнут проблемы при переезде с императивного подхода на декларативный, который предлагал Argo CD. Были также опасения по поводу того, что Argo CD как‑то «навредит» уже развернутой инфраструктуре. Но всё обошлось.

У меня уже как неделю развернут cnpg-operator в пространстве имён cnpg-system и кластер из трёх реплик в пространстве по умолчанию:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-db
  namespace: default
spec:
  bootstrap:
    initdb:
      database: db
      owner: db
      secret:
        name: db-creds
  instances: 3
  monitoring:
    enablePodMonitor: true
  storage:
    size: 1Gi
    storageClass: local-path

Сначала опишем Application для оператора (apps/cnpg-operator/app.yaml):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cnpg-operator
  namespace: argocd
spec:
  project: default
  source:
    chart: cloudnative-pg
    repoURL: https://cloudnative-pg.github.io/charts
    targetRevision: 0.22.0
    helm:
      releaseName: cnpg

  destination:
    server: "https://kubernetes.default.svc"
    namespace: cnpg-system

  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

Важно, чтобы версия чарта, название релиза и пространство имён совпадали с тем, что у нас уже развернуто в кластере. Не будем создавать приложение вручную, так как мы уже настроили App-of-apps паттерн. Просто запушим изменения в удаленный репозитории, немного подождем и увидим, что Argo CD сам подтянет все изменения:

Перейдем в само приложение cnpg-operator и убедимся, что ресурсы остались нетронутыми:

Статус приложения Healthy. Обратите также внимание на дату создания ресурсов: 7 days .

Посмотрим установленные чарты:

# helm -n cnpg-system ls  
NAME	NAMESPACE  	REVISION	UPDATED                                	STATUS  	CHART                	APP VERSION
cnpg	cnpg-system	1       	2024-09-12 15:37:54.390475578 +0300 MSK	deployed	cloudnative-pg-0.22.0	1.24.0

Как упоминалось ранее, Argo CD при создании Application не использует утилиту helm. Чтобы чарт больше не управлялся Helm, необходимо удалить секреты с типом helm.sh/release.v1:

# kubectl -n cnpg-system get secret --field-selector type=helm.sh/release.v1
NAME                         TYPE                 DATA   AGE
sh.helm.release.v1.cnpg.v1   helm.sh/release.v1   1      7d6h

# kubectl -n cnpg-system delete secret/sh.helm.release.v1.cnpg.v1
secret "sh.helm.release.v1.cnpg.v1" deleted

# helm -n cnpg-system ls
NAME	NAMESPACE	REVISION	UPDATED	STATUS	CHART	APP VERSION

С оператором разобрались, теперь опишем приложение для cnpg-кластера (apps/cnpg-operator/app.yaml):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cnpg-cluster
  namespace: argocd
spec:
  project: default
  destination:
    server: "https://kubernetes.default.svc"
    namespace: default
  sources:
  - repoURL: https://github.com/AzamatKomaev/argo-demo-habr.git
    path: apps/cnpg-cluster/manifests
    targetRevision: HEAD

  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

В директории apps/cnpg-cluster/manifests создадим cluster.yaml и поместим туда спецификацию ранее описанного Cluster. Получим следующую структуру:

Снова запушим изменения в репозитории и убедимся, что Argo CD подтянул ресурсы:

Вносим изменения в Application

Ранее для PostgreSQL я включал podMonitor. Это ресурс, при помощи которого указывается, как Prometheus должен обнаруживать и мониторить поды. Для того чтобы Prometheus смог их обнаружить, необходимо внести следующие изменения в values.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus
  namespace: argocd
spec:
  <...>
  source:
    chart: kube-prometheus-stack
    <...>
    helm:
      releaseName: prometheus
      values: |
        <...>
        prometheus:
          enabled: true

          prometheusSpec:
            <...>
            podMonitorSelectorNilUsesHelmValues: false      # +
            serviceMonitorSelectorNilUsesHelmValues: false  # + 
    

Зайдём в Grafana и импортируем дашборд для cnpg:

Много скриншотов

Argo CD Image Updater

Отлично, мы поняли как переводить более статические сервисы под управление Argo CD. Тот же самый Prometheus или CNPG-кластер вряд ли обновляется каждый день, в отличие от собственных приложений.

Везде, где я имел опыт с CI/CD, выкатка новых версий приложений происходила по модели Push: сначала собирали образ и загружали его в реестр. Затем брали тег образа (номер сборки или COMMIT_SHA) и обновляли образ в спецификации Deployment посредством kubectl apply или helm upgrade.

Если вы хотите перевести свои нагрузки под управление Argo CD, то тогда вам понадобится Argo CD Image Updater — инструмент для автоматического обновления образов. Он автоматически проверяет новые образы в реестре, которые используются в Kubernetes и сам их обновляет в соответствии с последней версией. Это Pull-подход.

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

Конец

GitOps — это круто!