Operator Manual

Overview

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

Architectural Overview

Components

API Server

API Server это gRPC/REST сервер который предоставляет API используемый Web UI, CLI и CI/CD системами. Он отвечает за:

• управление приложениями и контроль их состояний
• выполнение различных операций над приложениями (напр. sync, rollback, user-defined actions)
• управление репозиториями и кредами от кластеров (хранятся как секреты в K8s)
• аутентификация и делегирование аутентификации другим провайдерам
• RBAC
• listener/forwarder для Git вебхуков

Repository Server

Repository server это внутренний сервис который поддерживает локальный кэш Git репозитория хранящего манифесты. Он отвечает за генерацию и отдачу манифестов когда даны следующие вводные:

• repository URL
• revision (commit, tag, branch)
• application path
• template specific settings: parameters, helm values.yaml

Application Controller

Application controller это Kubernetes контроллер который постоянно отслеживает запущенные приложения и сравнивает их текущее состояние с желаемым (из репы). Он обнаруживает OutOfSync приложения и, если указано, предпринимает корректирующие действия. Также он отвечает за выполнение настроенных пользователем хуков (PreSync, Sync, PostSync)

Installation

Argo CD имеет два варианта установки: мультитенантный и core

Multi-Tenant

Multi-tenant инсталяция это самый частый вариант установки. Этот вариант обычно используется для обслуживания множества команд разработчиков приложений в организации и поддерживается командой платформы

Конечные пользователи могут использовать Argo CD через API используя Web UI или argocd CLI

Есть два варианта такой инсталяции

Non High Availability

Не рекомендуется для использования в проде. Обычно этот вариант используется на время тестов или для демонстраций

• install.yaml - стандартная инсталяция с cluster-admin доступом. Используй этот набор манифестов если планируешь деплоить приложения в тот же кластер в который устанавливаешь Argo CD. Возможность деплоить во внешние кластеры останется
• namespace-install.yaml - инсталяция требующая привелегий только на уровне неймспейса. Используй этот набор манифестов для установки Argo CD в кластер которым не планируешь управлять через Argo CD, а когда планируешь использовать Argo CD для управления другими кластерами. Возможность деплоить в этот же кластер остается, нужно лишь добавить его как внешний

High Availability

HA инсталяция рекомендована для продакшена. Следующие два набора манифестов содержат те же самые компоненты, но подтюненные для HA

• ha/install.yaml - то же что и install.yaml, но компоненты зареплицированы
• ha/namespace-install.yaml - то же что и namespace-install.yaml, но компоненты зареплицированы

Core

Core инсталяция подходят для кластер администраторов использующих Argo CD независимо от остальных и кому не нужна мультитенантность. Она содержит меньшее число компонентов и легче в установке. В нее не включен UI и устанавливается легковесная версия каждого компонента (non-HA)

Конечным пользователям необходим доступ к Kubernetes для управления Argo CD. argocd CLI должен быть сконфигурирован следующими командами:

kubectl config set-context --current --namespace=argocd # change current kube context to argocd namespace
argocd login --core

Web UI доступен локально через argocd admin dashboard:

(yc-test:argocd) vandud@macbook: ~ [0] ? argocd admin dashboard
Argo CD UI is available at http://localhost:8080

Команда argocd app create у меня завелась только когда в переменной KUBECONFIG оказался один файл:

(yc-test:argocd) vandud@macbook: ~ [0] ? export KUBECONFIG=/tmp/yc-test.kubeconfig.yaml
(yc-test:argocd) vandud@macbook: ~ [0] ? argocd --core app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default --upsert
application 'guestbook' created

Когда их там много - не работает:

Kustomize

Argo CD манифесты могут быть установлены через Kustomize и пропатчены по ходу

Helm

Argo CD может быть установлен через Helm
Community maintained chart - https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd

Supported versions

Как и у Kubernetes, поддерживаемая версия Argo CD в любой момент времени это последний патч-релиз для N и N-1 минорной версии

Declarative Setup

Argo CD applications, projects и настройки могут быть описаны декларативно в Kubernetes манифестах
И могут обновляться через kubectl apply без использования argocd cli

Quick Reference

Все ресурсы, включая Application и AppProject должны устанавливаться в неймспейс с Argo CD (by default argocd)

Atomic configuration

Для каждого ConfigMap или Secret возможно только определенное имя ресурса (в таблице)
Каждая ConfigMap должна иметь лейбл app.kubernetes.io/part-of: argocd, иначе Argo CD их не увидит

Multiple configuration objects

Для Application и AppProject имя ресурса равно объекта в Argo CD
Это значит что имена для Application и AppProject должны быть уникальными в рамках Argo CD и не может быть двух приложений с одинаковыми именами

Applications

Application CRD это ресурс Kubernetes отображающий задеплоенный инстанс приложения в каком-то окружении. Он определяется двуми ключевыми частями:

• source - референс на желаемое состояние описанное в гите
• destination - референс на кластер и неймспейс. Для обозначения кластера может быть указано либо сервер либо имя (но не оба). Под капотом когда сервер не указан он узнается на основе имени

Минимальный Application выглядит так:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook

Дополнительные поля можно посмотреть в https://argo-cd.readthedocs.io/en/stable/operator-manual/application.yaml

Namespace должен совпадать с неймспейсом где находится Argo CD, обычно это argocd

Когда приложение берется из Helm репозитория, аттрибут chart должен быть указан вместо path

spec:
  source:
    repoURL: https://argoproj.github.io/argo-helm
    chart: argo

По умолчанию при удалении application не происходит каскадного удаления ресурсов. Для такого нужно указывать finalizer

metadata:
  finalizers:
    - resources-finalizer.argocd.argoproj.io

App of Apps

Можно создать app который будет создавать другие app, которые могут создавать другие app (и так до бесконечности)
Это позволяет декларативно управлять группами приложений которые будут соответственно задеплоены и сконфигурированы

Смотри cluster bootstrapping

Projects

AppProject CRD это ресурс Kubernetes представляющий логическую группу приложений. Он определяется следующими ключевыми частями:

• sourceRepos - референс на репозитории откуда application'ы проекта могут получить манифесты
• destinations - референс на кластеры и неймспейсы куда application'ы проекта могут быть задеплоены (тут нельзя использовать поле name, а только server)
• roles - список сущностей с описанием их доступов к ресурсам в проекте

Если у проекта в destinations разрешено деплоиться в неймспейс где установлен Argo CD, тогда аппликейшены из этого проекта будут иметь админские права

Пример:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
  namespace: argocd
  # Finalizer that ensures that project is not deleted until it is not referenced by any application
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Example Project
  # Allow manifests to deploy from any Git repos
  sourceRepos:
  - '*'
  # Only permit applications to deploy to the guestbook namespace in the same cluster
  destinations:
  - namespace: guestbook
    server: https://kubernetes.default.svc
  # Deny all cluster-scoped resources from being created, except for Namespace
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  # Allow all namespaced-scoped resources to be created, except for ResourceQuota, LimitRange, NetworkPolicy
  namespaceResourceBlacklist:
  - group: ''
    kind: ResourceQuota
  - group: ''
    kind: LimitRange
  - group: ''
    kind: NetworkPolicy
  # Deny all namespaced-scoped resources from being created, except for Deployment and StatefulSet
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: 'apps'
    kind: StatefulSet
  roles:
  # A role which provides read-only access to all applications in the project
  - name: read-only
    description: Read-only privileges to my-project
    policies:
    - p, proj:my-project:read-only, applications, get, my-project/*, allow
    groups:
    - my-oidc-group
  # A role which provides sync privileges to only the guestbook-dev application, e.g. to provide
  # sync privileges to a CI system
  - name: ci-role
    description: Sync privileges for guestbook-dev
    policies:
    - p, proj:my-project:ci-role, applications, sync, my-project/guestbook-dev, allow
    # NOTE: JWT tokens can only be generated by the API server and the token is not persisted
    # anywhere by Argo CD. It can be prematurely revoked by removing the entry from this list.
    jwtTokens:
    - iat: 1535390316

Repositories

Некоторые Git хостеры, в особенности GitLab, требуют указывать на конце урла репозитория суффикс .git, иначе они возвращают 301 редирект на урл с суффиксом. Argo CD не следует за редиректами, поэтому надо указывать сразу нормальные урлы

Детали о репозитории хранятся в секрете. Чтобы сконфигурировать репозиторий нужно создать секрет содержащий нужную инфу о нем
Описание каждого репозитория должно иметь поле url и в зависимости от того происходит коннект по https, ssh или github app, требуются поля username, password, sshPrivateKey или githubAppPrivateKey

Example for HTTPS:

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/private-repo
  password: my-password
  username: my-username

Example for SSH:

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: git@github.com:argoproj/my-private-repository
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

Example for GitHub App:

apiVersion: v1
kind: Secret
metadata:
  name: github-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/my-private-repository
  githubAppID: 1
  githubAppInstallationID: 2
  githubAppPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----
---
apiVersion: v1
kind: Secret
metadata:
  name: github-enterprise-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://ghe.example.com/argoproj/my-private-repository
  githubAppID: 1
  githubAppInstallationID: 2
  githubAppEnterpriseBaseUrl: https://ghe.example.com/api/v3
  githubAppPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

Repository Credentials

Если ты хочешь использовать одни и те же креды для многих репозиториев, то можно наладить шаблон. Credential template может нести в себе ту же инфу которую может секрет с репозиторием:

apiVersion: v1
kind: Secret
metadata:
  name: first-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/private-repo
---
apiVersion: v1
kind: Secret
metadata:
  name: second-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/other-private-repo
---
apiVersion: v1
kind: Secret
metadata:
  name: private-repo-creds
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repo-creds
stringData:
  type: git
  url: https://github.com/argoproj
  password: my-password
  username: my-username

В примере выше каждый репозиторий доступный через https и чей url начинается на https://github.com/argoproj будет использовать username и password из секрета private-repo-creds

Для того чтобы Argo CD могу использовать credential template нужно чтобы совпали следующие условия:

• репозиторий должен быть недоконфигурирован или не содержать кредов
• урл из темплейта должен матчиться на урл репозитория как префикс

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

Следующие ключи (поля) валидны для темплейтирования:

SSH repositories

• sshPrivateKey - указыавет на ssh private key для доступа к репозиториям

HTTPS repositories

• username и password - логин и пароль для доступа к репозиториям
• tlsClientCertData и tlsClientCertKey - когда используются клиентские сертификаты для доступа в гит

GitHub App repositories

• githubAppPrivateKey - GitHub App private key
• githubAppID - GitHub Application ID созданного тобой приложения
• githubAppInstallationID - Installation ID созданного тобой приложения
• githubAppEnterpriseBaseUrl - api URL твоего GitHub Enterprise (когда self-hosted)
• tlsClientCertData и tlsClientCertKey - референсы на секреты с сертификатами

Repositories using self-signed TLS certificates (or are signed by custom CA)

https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#repositories-using-self-signed-tls-certificates-or-are-signed-by-custom-ca

v1.2 or later

Можно заложить самоподписанный серт от гитрепозитория в конфигмапу и подложить ее argocd-server'у и argocd-repo-server'у чтобы они могли работать с таким репозиторием

SSH known host public keys

Если ты коннектишься к репам через ssh, то Argo CD нужно знать SSH known hosts public keys git серверов
Это можно менеджить в ConfigMap argocd-ssh-known-hosts-cm, этот ConfigMap содержит простую key value пару, где ssh_known_hosts указан в качестве ключа и список public keys как значение
В отличие варианту с TLS, публичный ключ каждого Git сервера, куда будет коннектиться Argo CD, должен быть сконфигурирован, иначе подключение зафейлится (без вариантов)
Контент может быть скопирован из .ssh/known_hosts или из вывода утилиты ssh-keyscan
Формат - <servername> <keydata>, по одному на строку
Пример:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-ssh-known-hosts-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  ssh_known_hosts: |
    bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
    github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
    gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=
    gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
    gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
    ssh.dev.azure.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7Hr1oTWqNqOlzGJOfGJ4NakVyIzf1rXYd4d7wo6jBlkLvCA4odBlL0mDUyZ0/QUfTTqeu+tm22gOsv+VrVTMk6vwRU75gY/y9ut5Mb3bR5BV58dKXyq9A9UeB5Cakehn5Zgm6x1mKoVyf+FFn26iYqXJRgzIZZcZ5V6hrE0Qg39kZm4az48o0AUbf6Sp4SLdvnuMa2sVNwHBboS7EJkm57XQPVU3/QpyNLHbWDdzwtrlS+ez30S3AdYhLKEOxAG8weOnyrtLJAUen9mTkol8oII1edf7mWWbWVf0nBmly21+nZcmCTISQBtdcyPaEno7fFQMDD26/s0lfKob4Kw8H
    vs-ssh.visualstudio.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7Hr1oTWqNqOlzGJOfGJ4NakVyIzf1rXYd4d7wo6jBlkLvCA4odBlL0mDUyZ0/QUfTTqeu+tm22gOsv+VrVTMk6vwRU75gY/y9ut5Mb3bR5BV58dKXyq9A9UeB5Cakehn5Zgm6x1mKoVyf+FFn26iYqXJRgzIZZcZ5V6hrE0Qg39kZm4az48o0AUbf6Sp4SLdvnuMa2sVNwHBboS7EJkm57XQPVU3/QpyNLHbWDdzwtrlS+ez30S3AdYhLKEOxAG8weOnyrtLJAUen9mTkol8oII1edf7mWWbWVf0nBmly21+nZcmCTISQBtdcyPaEno7fFQMDD26/s0lfKob4Kw8H
    github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
    github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl

Конфигмапа argocd-ssh-known-hosts-cm должна быть примаунчена в /app/config/ssh к argocd-server и argocd-repo-server

Configure repositories with proxy

Прокси для репозитория должна быть указана в поле proxy в секрете репозитория наравне с другуми параметрами. Argo CD будет использовать указанную прокси для доступа к репозиторию. Argo CD будет использовать переменные окружения конфигурирующие прокси на repository server'e если прокси не указана для конкретного репозитория

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/private-repo
  proxy: https://proxy-server-url:8888
  password: my-password
  username: my-username

Legacy behaviour

В ранних версиях Argo CD можно было конфигурировать репозитории в argocd-cm

apiVersion: v1
kind: ConfigMap
data:
  repositories: |
    - url: https://github.com/argoproj/my-private-repository
      passwordSecret:
        name: my-secret
        key: password
      usernameSecret:
        name: my-secret
        key: username
  repository.credentials: |
    - url: https://github.com/argoproj
      passwordSecret:
        name: my-secret
        key: password
      usernameSecret:
        name: my-secret
        key: username
---
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: argocd
stringData:
  password: my-password
  username: my-username

Для обратной совместимости это продолжает работать, но скоро будет выпилено

Clusters

Креды от кластеров хранятся так же как креды от репозиторием или сами репозитории. Каждый секрет должен иметь лейбл argocd.argoproj.io/secret-type: cluster
Секрет должен иметь следующие поля:

• name - cluster name
• server - url до апи сервера
• namespaces - опциональный список доступных в этом кластере неймспейсов. Если это поле не пустое, то ресурсы уровня кластера будут игнорироваться
• clusterResources - опциональный булевый строковый переключатель ("true"/"false") указывающий на то может ли Argo CD управлять ресурсами уровня всего кластера (имеет смысл только если поле namespaces не пустое)
• config - JSON представление следующей структуры данных:

  # Basic authentication settings
  username: string
  password: string
  # Bearer authentication settings
  bearerToken: string
  # IAM authentication configuration
  awsAuthConfig:
      clusterName: string
      roleARN: string
  # Configure external command to supply client credentials
  # See https://godoc.org/k8s.io/client-go/tools/clientcmd/api#ExecConfig
  execProviderConfig:
      command: string
      args: [
        string
      ]
      env: {
        key: value
      }
      apiVersion: string
      installHint: string
  # Transport layer security configuration settings
  tlsClientConfig:
      # Base64 encoded PEM-encoded bytes (typically read from a client certificate file).
      caData: string
      # Base64 encoded PEM-encoded bytes (typically read from a client certificate file).
      certData: string
      # Server should be accessed without verifying the TLS certificate
      insecure: boolean
      # Base64 encoded PEM-encoded bytes (typically read from a client certificate key file).
      keyData: string
      # ServerName is passed to the server for SNI and is used in the client to check server
      # certificates against. If ServerName is empty, the hostname used to contact the
      # server is used.
      serverName: string
  

  Всякие провайдеры используемые для генерации токенов должны быть доступны в образе Argo CD
  Пример использования провайдера:

  vandud@macbook: ~ [0] ? kubectl config view --minify
  apiVersion: v1
  clusters:
  - cluster:
      certificate-authority-data: DATA+OMITTED
      server: https://51.250.19.246
    name: yc-managed-k8s-cato2ca3074sifli6462
  contexts:
  - context:
      cluster: yc-managed-k8s-cato2ca3074sifli6462
      namespace: argocd
      user: yc-managed-k8s-cato2ca3074sifli6462
    name: yc-test
  current-context: yc-test
  kind: Config
  preferences: {}
  users:
  - name: yc-managed-k8s-cato2ca3074sifli6462
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        args:
        - k8s
        - create-token
        - --profile=lastbackend
        command: /Users/vandud/yandex-cloud/bin/yc
        env: null
        provideClusterInfo: false
  

Helm Chart Repositories

Нестандартные Helm Chart репозитории должны быть зарегистрированы явно. Каждый репозиторий должен иметь url, type и name. Для приватных репозиториев можно указать креды через поля username, password, tlsClientCertData и tlsClientCertKey
Так же должен быть лейбл argocd.argoproj.io/secret-type: repository

apiVersion: v1
kind: Secret
metadata:
  name: istio
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  name: istio.io
  url: https://storage.googleapis.com/istio-prerelease/daily-build/master-latest-daily/charts
  type: helm
---
apiVersion: v1
kind: Secret
metadata:
  name: argo-helm
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  name: argo
  url: https://argoproj.github.io/argo-helm
  type: helm
  username: my-username
  password: my-password
  tlsClientCertData: ...
  tlsClientCertKey: ...

Resource Exclusion/Inclusion

Ресурсы можно исключать из дискавери и синхронизации так что Argo CD не будет о них знать
Например events.k8s.io и metrics.k8s.io всегда исключены
Юзкейсы:

• Имеются временные проблемы и нужно исключить проблемные ресурсы
• Существует множество ресурсов, которые влияют на производительность Argo CD
• Ограничение доступа Argo CD к некоторым видам ресурсов

Чтобы это настроить нужно добавить в argocd-cm конфигмапу секцию resource.exclusions:

apiVersion: v1
data:
  resource.exclusions: |
    - apiGroups:
      - "*"
      kinds:
      - "*"
      clusters:
      - https://192.168.0.20
kind: ConfigMap

resource.exclusions это список объектов, каждый объект имеет:

• apiGroups - список паттернов которые должны быть заматченны на API группы
• kinds - список kind'ов (может быть выставлен в *)
• clusters - список паттернов которые должны быть заматченны на кластеры

Если все три совпадают то ресурс будет игнорироваться

В дополнение к исключениям можно настроить включения параметром resource.inclusions
По умолчанию включены все groups/kinds. С помощью resource.inclusions можно изменить список включенных groups/kinds

apiVersion: v1
data:
  resource.inclusions: |
    - apiGroups:
      - "*"
      kinds:
      - Deployment
      clusters:
      - https://192.168.0.20
kind: ConfigMap

resource.inclusions и resource.exclusions могут использоваться одновременно. Итоговый список включенных groups/kinds будет получен из resource.inclusions минус resource.exclusions

• Кавычь глоббинги чтобы не было ошибок парсинга
• Кривые глоббинги приводят к игнорированию всего правила
• Если вы добавите правило, соответствующее существующим ресурсам, они будут отображаться в интерфейсе как OutOfSync

SSO & RBAC

• SSO configuration details: SSO
• RBAC configuration details: RBAC

Manage Argo CD Using Argo CD

Argo CD может управлять самим собой потому что все настройки это Kubernetes манифесты
Предлагается создать Kustomization с базовыми манифестами отсюда - https://github.com/argoproj/argo-cd/tree/stable/manifests
Поверх которых будут накладываться нужные изменения

bases:
- github.com/argoproj/argo-cd/manifests/cluster-install?ref=v1.0.1

# additional resources like ingress rules, cluster and repository secrets.
resources:
- clusters-secrets.yaml
- repos-secrets.yaml

# changes to config maps
patchesStrategicMerge:
- overlays/argo-cd-cm.yaml

Пример самоуправляемого Argo CD https://cd.apps.argoproj.io/
У которого конфигурация хранится в https://github.com/argoproj/argoproj-deployments/tree/master/argocd

Ingress Configuration

Ambassador

Option 1: Mapping CRD for Host-based Routing

Option 2: Mapping CRD for Path-based Routing

Contour

Private Argo CD UI with Multiple Ingress Objects and BYO Certificate

kubernetes/ingress-nginx

Option 1: SSL-Passthrough

SSL-Passthrough with cert-manager and Let's Encrypt

Option 2: Multiple Ingress Objects And Hosts

Traefik (v2.2)

IngressRoute CRD

AWS Application Load Balancers (ALBs) And Classic ELB (HTTP Mode)

Google Cloud load balancers with Kubernetes Ingress

Disable internal TLS

Creating a service

Creating a BackendConfig

Creating a FrontendConfig

Creating a certificate secret

Creating an Ingress

Authenticating through multiple layers of authenticating reverse proxies

ArgoCD Server and UI Root Path (v1.5.3)

UI Base Path

User Management

Security

TLS configuration

Cluster Bootstrapping

Secret Management

High Availability

Disaster Recovery

Git Webhook Configuration

Resource Health

Resource Actions

Custom Tooling

Custom Styles

Metrics

Web-based Terminal

Notification

Troubleshooting Tools

ApplicationSet

Server Configuration Parameters

Upgrading