Einheit 5.3: GitOps und Deployment-Operationen

Einführung

Sie verfügen über einen produktionsreifen TaskBoard-Deployment auf Managed Kubernetes, eine CI/CD-Pipeline, die Images baut und pusht, sowie Terraform, das den Cluster provisioniert. Das Problem ist Drift. Jemand führt kubectl edit aus, um ein Hotfix für eine Produktionsdeployment durchzuführen. Der Live-Zustand weicht dadurch vom Zustand in Git ab, und der nächste Pipeline-Lauf hebt die Änderung stillschweigend wieder auf oder, im schlimmsten Fall, schlägt fehl. GitOps löst dieses Problem, indem ein Git-Repository als einzige Quelle der Wahrheit etabliert wird und ein Controller innerhalb des Clusters den gewünschten Zustand kontinuierlich abruft und den Live-Zustand entsprechend anpasst.

In dieser Einheit richten Sie ArgoCD auf Ihrem MKS-Cluster ein, verbinden es mit dem Manifest-Repository von TaskBoard und beobachten, wie es manuelle Änderungen automatisch wiederherstellt. Sie trennen das Repository, das Terraform verwaltet (Cluster, Netzwerk, Datenbanken), vom Repository, das ArgoCD verwaltet (Kubernetes-Manifeste), damit die beiden Controller einander nie überschreiben. Schließlich automatisieren Sie die Aufräumung von Branch-Umgebungen, sodass ein Feature-Branch seinen eigenen Namespace einrichtet und diesen bei Merge oder Schließen des Branches wieder entfernt.

1. GitOps-Prinzipien und der pull-basierte Reconciliation-Loop

GitOps kehrt die übliche Deployment-Richtung um. Anstatt dass ein CI-Runner kubectl apply von außen in den Cluster schiebt (Push-Modell), zieht ein Controller, der innerhalb des Clusters läuft, den gewünschten Zustand aus Git und wendet ihn an (Pull-Modell). Der Git-Commit ist gleichzeitig der Deployment-Auslöser, das Audit-Log und der Rollback-Mechanismus. Zum Zurückrollen wird der Commit zurückgesetzt, und der Controller stellt den vorherigen Zustand wieder her.

Drei Eigenschaften definieren ein GitOps-System: Der gesamte gewünschte Zustand ist deklarativ und in Git gespeichert, der Controller vergleicht kontinuierlich den gewünschten Zustand mit dem Live-Zustand, und jede Abweichung (Drift) wird entweder gemeldet oder automatisch korrigiert. Bei IONOS CLOUD MKS ist dies relevant, da der Cluster während des wöchentlichen Wartungsfensters bereits eigene Reconciliation-Loops ausführt, sodass die Reconciliation Ihrer Anwendung mit plattformgesteuerten Änderungen koexistieren muss.

1.1 Deklarativer Zustand in Git

Alles, was ArgoCD verwaltet, ist schlichtes Kubernetes YAML, das in einem Repository committet wird. In einem GitOps-Workflow gibt es keine imperativen kubectl run. Ein minimales TaskBoard-Deployment-Manifest sieht wie folgt aus:

# apps/taskboard/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  replicas: 2
  selector:
    matchLabels:
      app: taskboard-api
  template:
    metadata:
      labels:
        app: taskboard-api
    spec:
      imagePullSecrets:
        - name: cr-pull-secret
      containers:
        - name: api
          image: my-registry.cr.de-fra.ionos.com/taskboard-api:GIT_SHA
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5

Das image-Tag enthält eine Git-SHA-Prüfsumme und keine latest. Dies ist der Hebel für die Freigabe: Die Änderung des Tags in Git löst einen neuen Rollout aus, und das Tag gibt genau an, welcher Commit ausgeführt wird.

1.2 Drift-Erkennung und Selbstreparatur

Wenn jemand kubectl scale deployment/taskboard-api --replicas=5 direkt gegen den Cluster ausführt, stimmt der Live-Zustand nicht mehr mit Git überein, das weiterhin replicas: 2 angibt. Ein GitOps-Controller im Selbstreparaturmodus erkennt diese Abweichung in seinem nächsten Synchronisationszyklus und skaliert auf 2 zurück. Die operative Lektion für Ihr Team lautet: Der Cluster ist für Menschen schreibgeschützt. Alle Änderungen erfolgen über einen Pull Request.

# This manual change will be reverted by ArgoCD self-heal
kubectl -n taskboard scale deployment/taskboard-api --replicas=5

# Within the sync interval, ArgoCD reports OutOfSync, then heals back to 2
argocd app get taskboard --refresh

2. Installation und Konfiguration von ArgoCD auf MKS

ArgoCD ist ein CNCF-Projekt und kein IONOS CLOUD-Produkt. Daher wird es auf MKS auf dieselbe Weise installiert wie auf jedem anderen konformen Kubernetes-Cluster. Die IONOS CLOUD-spezifischen Aspekte betreffen die Beschaffung der kubeconfig, die Veröffentlichung des ArgoCD-Servers (dies hängt vom in Abschnitt 4 behandelten LoadBalancer-Modell von MKS ab) sowie die Authentifizierung von Image-Pulls gegenüber der IONOS CLOUD Container Registry.

2.1 Abruf der kubeconfig und Installation von ArgoCD

Sie provisionieren den Cluster mit Terraform und rufen die kubeconfig ab, bevor Sie etwas installieren. IONOS CLOUD dokumentiert drei Pfade für die Konfigurationsverwaltung zum Abrufen der kubeconfig-Datei: die ionosctl-CLI, Ansible und Terraform. Mit Terraform stellt die ionoscloud_k8s_cluster-Datenquelle die kubeconfig als Attribut bereit, das Sie in eine Datei schreiben können.

data "ionoscloud_k8s_cluster" "taskboard" {
  id = ionoscloud_k8s_cluster.taskboard.id
}

resource "local_file" "kubeconfig" {
  content         = data.ionoscloud_k8s_cluster.taskboard.kube_config
  filename        = "${path.module}/kubeconfig.yaml"
  file_permission = "0600"
}

Sobald die kubeconfig eingerichtet ist, installieren Sie ArgoCD in einem eigenen Namespace:

export KUBECONFIG=./kubeconfig.yaml

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Wait for the API server to come up on the worker nodes
kubectl -n argocd rollout status deployment/argocd-server

Die ArgoCD-Pods werden auf Ihren MKS-Worker-Knoten eingeplant. Die Komponenten der Steuerungsebene, die IONOS CLOUD verwaltet (der K8s-API-Server, CSI, CCM, Calico und CoreDNS), werden von IONOS CLOUD während der Wartung aktualisiert und sind nicht Teil der von ArgoCD vorgenommenen Änderungen.

2.2 Definition der Application-CRD

Das zentrale Objekt von ArgoCD ist das Application-Custom Resource. Es verweist auf ein Git-Repository, einen Pfad darin sowie auf ein Zielcluster und einen Namespace. automated mit prune und selfHeal macht es zu einem echten GitOps-Loop: prune entfernt Ressourcen, die aus Git gelöscht wurden, und selfHeal macht manuelle Clusteränderungen rückgängig.

# argocd/taskboard-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: taskboard
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/taskboard-manifests.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: taskboard
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Wenden Sie es mit kubectl apply -n argocd -f argocd/taskboard-app.yaml an. Ab diesem Zeitpunkt löst jedes Commit im Pfad overlays/prod eine Abgleichsaktion aus.

3. Repository-Topologie: Trennung von Infrastruktur und Anwendungen

Der häufigste GitOps-Fehler auf IONOS CLOUD besteht darin, Terraform-gemanagte Infrastruktur und ArgoCD-gemanagte Anwendungen an einem Ort zu mischen und zuzusehen, wie sie miteinander in Konflikt geraten. Das saubere Muster besteht aus zwei Repositories mit einer klaren Zuständigkeitsgrenze.

Das Infrastruktur-Repository enthält Terraform: ionoscloud_k8s_cluster, ionoscloud_k8s_node_pool, Netzwerk, Datenbanken und die Container Registry. Es wird bei Merge auf main über Ihre CI-Pipeline angewendet. Das Anwendungs-Repository enthält Kubernetes-Manifeste und Kustomize-Overlays, und ArgoCD beobachtet es.

3.1 Zuständigkeitsgrenze

Die Regel ist einfach: Wenn eine Ressource durch terraform apply erstellt wird, darf ArgoCD sie niemals verwalten, und wenn eine Ressource durch ArgoCD-Sync erstellt wird, darf Terraform sie niemals verwalten. Der Übergang erfolgt über Outputs. Terraform erzeugt den Cluster und das Registry-Pull-Secret; ArgoCD konsumiert den Cluster und deployt in ihn hinein.

# infrastructure repo: outputs that the app layer consumes
output "k8s_cluster_id" {
  value = ionoscloud_k8s_cluster.taskboard.id
}

output "registry_hostname" {
  value     = ionoscloud_container_registry.taskboard.hostname
  sensitive = false
}

Die folgende Tabelle definiert die Grenze für TaskBoard ausdrücklich.

Wie oben gezeigt, teilen sich die Controller nie einen Ressourcentyp, sodass keiner den anderen zurücksetzt.

3.2 Der imagePullSecret-Übergang

Die Container Registry auf IONOS CLOUD verwendet ausschließlich tokenbasierte docker login; es gibt weder RBAC noch teamweise Repositories. Das Pull-Secret ist die einzige Authentifizierung, die die Grenze von der Infrastruktur zur Anwendung überschreitet. Erstellen Sie es einmalig aus dem Registry-Token und verweisen Sie dann darauf in Manifesten, die ArgoCD synchronisiert.

kubectl create secret docker-registry cr-pull-secret \
  --docker-server=my-registry.cr.de-fra.ionos.com \
  --docker-username='<token-name>' \
  --docker-password='<registry-token>' \
  --namespace=taskboard

Da dieses Secret ein Anmeldezeichen enthält, sollte es nicht im Klartext versioniert werden. Erstellen Sie es entweder imperativ wie oben beschrieben (einmalig, außerhalb von Git) oder verwenden Sie einen sealed-secrets- oder external-secrets-Operator, damit ArgoCD eine verschlüsselte Form verwalten kann.

4. IONOS CLOUD-spezifische Abgleichsrisiken

GitOps geht davon aus, dass sich der Cluster vorhersehbar verhält. Zwei MKS-Verhaltensweisen brechen diese Annahme, wenn Sie nicht entsprechend planen: Nodes sind unveränderlich und werden neu aufgebaut, statt gepatcht zu werden, und ein LoadBalancer Service provisioniert keinen echten externen Load Balancer.

4.1 Unveränderliche Nodes und das Wartungsfenster

MKS-Nodes sind unveränderlich. Jede Upgrade-Aktion eines Node Pools baut alle Nodes neu, die dem Pool zugeordnet sind, statt sie an Ort und Stelle zu patchen. Upgrades erfolgen in der Regel automatisch während des wöchentlichen Wartungsfensters. Dieses Wartungsfenster ist auf maximal 4 Stunden begrenzt. Während dieses Fensters aktualisiert IONOS CLOUD alle Komponenten im Cluster, einschließlich der Steuerungsebene, CSI, CCM, Calico und CoreDNS.

Die Auswirkung für GitOps besteht darin, dass Pods auf einem Zeitplan, den Sie nicht kontrollieren, vertrieben und auf neu aufgebauten Nodes neu eingeplant werden. Ihre Manifeste müssen dies tolerieren. Konfigurieren Sie Readiness-Probes, damit ArgoCD und Services Traffic nur zu bereitwilligen Pods leiten, und verwenden Sie ein PodDisruptionBudget, damit der Neuaufbau nicht alle Replikate gleichzeitig außer Betrieb setzt.

# Survive node rebuilds during the maintenance window
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: taskboard-api

Ein Rebuild erfordert zudem einen Puffer im Serverkontingent: Bei einem Node-Rebuild wird ein neuer Node bereitgestellt, bevor der alte entfernt wird. Wenn das Serverkontingent Ihres Vertrags vollständig ausgeschöpft ist, kann der Rebuild nicht abgeschlossen werden. Halten Sie einen Kontingentpuffer von mindestens einem Node pro Pool frei.

4.2 Die LoadBalancer-Service-Falle

Dies ist das Risiko, das die meisten Teams überrascht, die ArgoCD oder TaskBoard bereitstellen. Auf MKS ist ein Service von type: LoadBalancer kein echter externer Load Balancer. IONOS CLOUD reserviert eine statische öffentliche IP und weist sie einem Worker-Node als sekundäre IP zu. Dieser Node fungiert als Ingress-Node, und kube-proxy leitet den Traffic per NAT an den Ziel-Pod weiter. Die Quell-IP geht verloren, sofern externalTrafficPolicy: Local nicht gesetzt ist. Die Durchsatzrate ist auf die öffentliche Obergrenze von 2 Gbit/s dieses einzelnen Ingress-Nodes beschränkt.

apiVersion: v1
kind: Service
metadata:
  name: taskboard-api-lb
  namespace: taskboard
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local   # preserve client source IP
  selector:
    app: taskboard-api
  ports:
    - port: 443
      targetPort: 8080

Um die Leistungsgrenze eines einzelnen Knotens zu überschreiten, skalieren Sie horizontal über mehrere LoadBalancer-IPs und Ingress-Knoten mithilfe der DNS-basierten Lastverteilung oder setzen Sie einen separat bereitgestellten Managed ALB vor den Dienst (bereitgestellt im Infrastruktur-Repository über Terraform, niemals automatisch aus einem Manifest erstellt). Für Produktions-TaskBoard-Verkehr ist der ALB-Pfad die richtige Lösung und hält die Ingress-Betrachtung in der von Terraform verwalteten Ebene.

5. Umgebungs-Förderung und ephemeres Abbauen

Die Förderung über Umgebungen hinweg ist eine Git-Operation, kein Deployment-Skript. Mit Kustomize hält eine gemeinsame Basis die Manifeste, und jede Umgebung ist ein Overlay, das Replikatenanzahlen, Ressourcenlimits und das Image-Tag patcht.

5.1 Kustomize Overlays

Die Basis definiert TaskBoard einmal; Overlays differenzieren pro Umgebung. Die Förderung eines Builds von Staging auf Produktion ist eine einzeilige Änderung des Image-Tags im prod-Overlay, die über einen Pull Request committet wird.

# overlays/prod/kustomization.yaml
resources:
  - ../../base
namespace: taskboard
images:
  - name: my-registry.cr.de-fra.ionos.com/taskboard-api
    newTag: 1a2b3c4   # promoted git SHA
patches:
  - path: replicas-patch.yaml

Jede ArgoCD Application verweist auf einen anderen Overlay-Pfad (overlays/dev, overlays/staging, overlays/prod), sodass dasselbe Repository alle drei Umgebungen steuert und die Unterschiede zwischen ihnen in Git nachvollziehbar sind.

5.2 Ephemere Branch-Umgebungen und Abbau

Für Feature-Branches richten Sie eine Wegwerf-Umgebung ein und bauen sie beim Merge oder bei der Schließung des Branches ab. Von Terraform bereitgestellte Ressourcen verursachen Kosten ab dem Zeitpunkt der Anwendung, daher ist der automatisierte Abbau eine Maßnahme der Kostenkontrolle und kein optionales Extra. Der CI-Job ruft terraform destroy für den Stack des Branches auf.

# .github/workflows/teardown.yml (triggered on PR close)
name: teardown-branch-env
on:
  pull_request:
    types: [closed]
jobs:
  destroy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform destroy branch stack
        env:
          IONOS_TOKEN: ${{ secrets.IONOS_TOKEN }}
        run: |
          terraform init -backend-config="key=env/pr-${{ github.event.number }}.tfstate"
          terraform destroy -auto-approve -var="env_name=pr-${{ github.event.number }}"

Ein häufiger Fehler bei der Bereinigung betrifft speziell MKS-Speicher: IONOS CLOUD-Volumes werden in Kubernetes als PersistentVolume-Ressourcen dargestellt, und die PV-Reclaim-Richtlinie bestimmt, was mit dem zugrunde liegenden Volume geschieht, wenn der Claim gelöscht wird. Wenn die Reclaim-Richtlinie auf Retain gesetzt ist, führt das Löschen des Namespaces oder die Ausführung von terraform destroy auf dem Cluster zu verwaisten IONOS CLOUD-Volumes in Ihrem VDC, die weiterhin abgerechnet werden. Setzen Sie die Reclaim-Richtlinie für ephemere Umgebungen auf Delete oder bereinigen Sie verbleibende Volumes nach dem Abbau explizit.

Schnellreferenz für die API

Wichtige API-Endpunkte für GitOps- und Deployment-Operationen auf MKS:

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token>

Code Lab

Ziel: Richten Sie die automatische Synchronisierung von ArgoCD für TaskBoard-Manifeste auf MKS ein, schieben Sie eine Manifeständerung und beobachten Sie, wie die Reconciliation sie wiederherstellt, und räumen Sie anschließend eine Branch-Umgebung ab.

Voraussetzungen:

• IONOS CLOUD-Konto mit API-Token
• Ein laufender MKS-Cluster, der über Terraform bereitgestellt wurde (aus Einheit 3.2)
• kubectl, argocd CLI und Terraform lokal installiert
• Ein Git-Repository, das TaskBoard-Manifeste enthält

Schritt 1: Den kubeconfig aus Terraform abrufen

terraform output -raw kubeconfig > kubeconfig.yaml
export KUBECONFIG=./kubeconfig.yaml
kubectl get nodes

Erwartete Ausgabe:

NAME                STATUS   ROLES    AGE   VERSION
taskboard-pool-1    Ready    <none>   12m   v1.34.x
taskboard-pool-2    Ready    <none>   12m   v1.34.x

Schritt 2: ArgoCD installieren

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd rollout status deployment/argocd-server

Erwartete Ausgabe:

deployment "argocd-server" successfully rolled out

Schritt 3: Erstellen der Application-CRD mit Verweis auf die TaskBoard-Manifeste

kubectl apply -n argocd -f argocd/taskboard-app.yaml
argocd app get taskboard

Erwartete Ausgabe:

Name:               argocd/taskboard
Sync Status:        Synced to main (1a2b3c4)
Health Status:      Healthy

Schritt 4: Drift manuell einleiten

kubectl -n taskboard scale deployment/taskboard-api --replicas=5
kubectl -n taskboard get deploy taskboard-api

Erwartete Ausgabe:

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   5/5     5            5

Schritt 5: Beobachten, wie ArgoCD den Zustand automatisch in den in Git deklarierten Zustand zurückführt

argocd app get taskboard --refresh
sleep 30
kubectl -n taskboard get deploy taskboard-api

Erwartete Ausgabe:

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   2/2     2            2

Schritt 6: Ein neues Image über einen Git-Commit bereitstellen

# In the manifests repo, update overlays/prod/kustomization.yaml newTag
git commit -am "promote taskboard-api to 9f8e7d6"
git push origin main
argocd app wait taskboard --sync

Erwartete Ausgabe:

taskboard   Synced   Healthy

Schritt 7: Eine Branch-Umgebung abbauen

terraform init -backend-config="key=env/pr-42.tfstate"
terraform destroy -auto-approve -var="env_name=pr-42"

Erwartete Ausgabe:

Destroy complete! Resources: 7 destroyed.

Schritt 8: Prüfen, dass keine verwaisten Volumes verbleiben

ionosctl volume list --datacenter-id $DC_ID

Erwartete Ausgabe:

No volumes found  (or: only volumes belonging to retained environments)

Validierungscheckliste:

• [ ] ArgoCD meldet Synced und Healthy für TaskBoard
• [ ] Manuelle Skalierungsänderungen werden durch Self-Heal innerhalb des Synchronisierungsintervalls zurückgesetzt
• [ ] Ein Commit mit einem neuen Image-Tag löst einen Rollout aus, ohne dass kubectl apply auftritt
• [ ] terraform destroy entfernt den Branch-Stack und hinterlässt keine Abrechnungsvolumen

Aufräumarbeiten:

kubectl delete -n argocd -f argocd/taskboard-app.yaml
kubectl delete namespace argocd
terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei GitOps- und Deployment-Vorgängen auf IONOS CLOUD zu vermeiden sind:

1. Terraform und ArgoCD streiten sich um dieselbe Ressource

   • Problem: Terraform verwaltet einen Kubernetes Service, während ArgoCD denselben Service auch aus Git synchronisiert. Jeder apply und jede Synchronisierung hebt die Änderung des jeweils anderen auf, was zu einer endlosen Konfliktschleife und instabilen Ressourcen führt.
   • Ursache: Es gibt keine klare Abgrenzung der Zuständigkeiten zwischen dem Infrastruktur-Repository und dem Anwendungs-Repository.
   • Lösung: Terraform sollte ausschließlich die IONOS CLOUD-Infrastruktur (Cluster, Node Pools, Registry, Datenbanken) verwalten, während ArgoCD ausschließlich die Manifests innerhalb des Clusters übernimmt. Übergeben Sie Cluster und Registry über Terraform-Outputs, niemals indem beide dasselbe Objekt verwalten.

2. ArgoCD oder TaskBoard mit type: LoadBalancer exponieren und einen echten Load Balancer erwarten

   • Problem: Der gesamte Traffic landet auf einem einzigen Worker-Node, die Quell-IP des Clients geht verloren und die Durchsatzrate stagniert ohne erkennbaren Grund bei etwa 2 Gbit/s.
   • Ursache: Ein MKS LoadBalancer Service provisioniert keinen externen Load Balancer. IONOS CLOUD weist eine statische öffentliche IP als sekundäre IP einem einzelnen Ingress-Node zu, und kube-proxy wendet NAT auf den Pod an.
   • Lösung: Setzen Sie externalTrafficPolicy: Local, um die Quell-IP zu erhalten, und setzen Sie in der Produktion einen separat provisionierten Managed ALB aus der Terraform-Ebene vor den Service, anstatt sich auf den Single-Node-Service zu verlassen.

3. Verwaiste IONOS CLOUD-Volumes nach dem Abbau einer Branch-Umgebung

   • Problem: Sie terraform destroy eine Branch-Umgebung, werden aber weiterhin abgerechnet, und verwaiste Volumes verbleiben im VDC.
   • Ursache: IONOS CLOUD-Volumes gehören zu PersistentVolumes, deren Reclaim Policy Retain ist. Wenn Sie den Claim oder den Namespace löschen, bleibt das zugrunde liegende Volume zurück.
   • Lösung: Verwenden Sie für ephemere Umgebungen eine StorageClass mit der Reclaim Policy Delete oder fügen Sie einen Abbau-Schritt hinzu, der verbleibende Volumes mit ionosctl volume list und ionosctl volume delete auflistet und entfernt.

Zusammenfassung

Sie können nun einen echten pull-basierten GitOps-Workflow auf IONOS CLOUD Managed Kubernetes ausführen. ArgoCD versöhnt den deklarierten Zustand von TaskBoard aus Git, heilt manuelle Abweichungen automatisch aus und fördert Builds durch Umgebungen mit einem einzigen Commit des Image-Tags. Sie halten Terraform und ArgoCD in separaten Repositories mit einer klaren Zuständigkeitsgrenze, sodass die beiden Controller einander nie überschreiben. Sie kennen auch die beiden MKS-Verhaltensweisen, die naive GitOps-Annahmen aufbrechen, und wie Sie um diese herum designen.

Der operative Vorteil besteht darin, dass die Produktion für Menschen jetzt schreibgeschützt ist, jede Änderung ein prüfbare Commit ist und ein Rollback ein git revert ist. Branch-Umgebungen sind wegwerfbar und räumen sich selbst auf, und Sie vermeiden die Abrechnungsfalle für verwaiste Volumes, indem Sie die richtige Reclaim-Richtlinie festlegen.

Wichtige Punkte:

• GitOps verwendet ein Pull-Modell: Ein Controller innerhalb des Clusters versöhnt den gewünschten Zustand aus Git, wodurch Commits den Auslöser für Deployments und den Rollback-Mechanismus darstellen
• Trennen Sie das von Terraform verwaltete Infrastruktur-Repository vom von ArgoCD verwalteten Anwendungs-Repository, um Reconciliation-Kampfschleifen zu verhindern
• MKS-Knoten sind unveränderlich und werden während des wöchentlichen Wartungsfensters (maximal 4 Stunden) neu aufgebaut; verwenden Sie PodDisruptionBudgets und Readiness-Probes, damit Deployments Neuaufbauten überstehen
• Ein MKS LoadBalancer Service ist kein echter externer Load Balancer: ein einziger Ingress-Knoten, verlorene Quell-IP, außer externalTrafficPolicy: Local, und eine Obergrenze von 2 Gbit/s; verwenden Sie einen Managed ALB für die Produktion
• Automatisieren Sie terraform destroy für Branch-Umgebungen und setzen Sie die PV-Reclaim-Richtlinie auf Delete, um verwaiste, weiterhin abgerechnete Volumes zu vermeiden

Wichtige Begriffe:

• GitOps: Ein Betriebsmodell, bei dem Git die einzige Quelle der Wahrheit ist und ein Controller innerhalb des Clusters den Live-Zustand kontinuierlich so versöhnt, dass er dem commitierten deklarativen Zustand entspricht
• Drift: Abweichung zwischen dem Live-Zustand des Clusters und dem in Git deklarierten gewünschten Zustand, verursacht durch manuelle Änderungen oder externe Prozesse
• Self-heal: Ein ArgoCD-Synchronisationsmodus, der Live-Änderungen automatisch in den in Git deklarierten Zustand zurücksetzt
• Reclaim-Richtlinie: Die Kubernetes-PersistentVolume-Einstellung (Retain oder Delete), die bestimmt, ob das zugrunde liegende IONOS CLOUD Volume entfernt wird, wenn sein Claim gelöscht wird
• Ingress-Knoten: Der einzelne MKS-Worker-Knoten, der die reservierte öffentliche IP eines LoadBalancer Service als sekundäre IP empfängt und den Traffic per NAT an die Ziel-Pods weiterleitet

Nächste Schritte

Weiter lernen: Einheit 5.4: Wissensprüfung - Produktionsbetrieb

Verwandte Themen:

• Einheit 3.3: CI/CD-Pipelines für IONOS CLOUD
• Einheit 5.2: Sicherheitsautomatisierung