Die wichtigsten Konzepte von ArgoCD

Application

Eine ArgoCD Application definiert eine Source und ein Target. Die Source ist beispielsweise eine Gruppe von Kubernetes Ressourcen oder ein Helm chart (package), hinterlegt als yaml files in einem git repository. Das Target ist ein Namespace auf einem bestimmten Kubernetes cluster, häufig der Cluster, wo ArgoCD selbst drauf läuft.

Health Status

Beschreibt, ob die Applikation einwandfrei funktioniert und beispielsweise auf Requests antworten kann. Der default health check ist abhängig vom Typ der Kubernetes Resource. Es werden aber auch custom Implementationen unterstützt.

Refresh

Mit einem refresh wird der aktuelle Stand aus dem git repository abgefragt. Stimmt dieser nicht mit dem Stand des Clusters überein, wechselt die Applikation in einen out-of-sync Status. Merke: Per Default wird ein refresh alle 3 Minuten ausgeführt.

Sync

Ein sync appliziert Änderungen auf einem Cluster. Beispiel: Skalierung von 5 auf 10 Pods aufgrund einer Konfigurationsanspassung im git repository.

Auto-sync

Ist auto-sync für eine Applikation aktiviert, werden Applikationen, welche aufgrund eines refreshs (manuell, time-triggered oder via webhook) out-of-sync sind, direkt und ohne manuelle Bestätigung auf dem Cluster angepasst.

Self-heal

Self-heal ist nur möglich, wenn auto-sync aktiviert ist. Ist self-heal aktiv, werden manuelle Änderungen am Cluster von ArgoCD überwacht und direkt überschrieben, so dass der definierte Stand vom git repository wieder hergestellt wird. Dies verhindert Konfigurationsdrift.

Prune

Ist prune aktiv, werden Resourcen (bsp. Pods), welche noch auf dem Cluster leben, aber nicht mehr durch eine ArgoCD Applikation gesteuert werden, von ArgoCD gelöscht. Diese Option ist mächtig, sollte aber auch mit der nötigen Vorsicht genossen werden.

Project

Logische Gruppierung von Applications innerhalb ArgoCD für Access Management und Policy Enforcements.