Einheit 5.3: GitOps und Deployment-Operationen

Einführung

Sie haben eine funktionierende TaskBoard-Bereitstellung auf Managed Kubernetes, eine CI/CD-Pipeline, die Bilder erstellt und verteilt, und Terraform, das die Cluster bereitstellt. Das Problem ist die Abdrift. Jemand führt kubectl edit aus, um eine Produktionsbereitstellung zu beheben, der Live-Zustand weicht von dem ab, was in Git ist, und der nächste Pipeline-Lauf setzt es stillschweigend zurück oder, schlimmer noch, schlägt fehl. GitOps behebt dies, indem es ein Git-Repository als einzige Wahrheitsquelle macht und einen Controller innerhalb der Cluster ausführt, der kontinuierlich den gewünschten Zustand abruft und den Live-Zustand anpasst, um ihn zu entsprechen.

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 selbst repariert. Sie trennen das Repository, das Terraform besitzt (die Cluster, Netzwerk, Datenbanken), von dem Repository, das ArgoCD besitzt (Kubernetes-Manifeste), sodass die beiden Controller einander nie überschreiben. Schließlich automatisieren Sie die Demontage von Branch-Umgebungen, sodass ein Feature-Branch seinen eigenen Namespace erstellt und ihn bei Merge oder Schließen abbaut.

1. GitOps-Prinzipien und der Pull-basierte Ausgleichsloop

GitOps invertiert die übliche Bereitstellungsrichtung. Anstatt ein CI-Runner kubectl apply in das Cluster von außen zu pushen (Push-Modell), zieht ein Controller, der innerhalb des Cluster läuft, den gewünschten Zustand aus Git und wendet ihn an (Pull-Modell). Der Git-Commit ist der Bereitstellungstrigger, das Audit-Log und das Rollback-Mechanismus in einem. Um zurück zu versionieren, revertieren Sie den Commit und der Controller gleicht zurück zum vorherigen Zustand.

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. Auf IONOS MKS ist dies wichtig, da das Cluster bereits Ausgleichsloops seiner eigenen während des wöchentlichen Wartungsfensters durchführt, sodass Ihre Anwendungs-Ausgleichung mit plattformgetriebenen Änderungen koexistieren muss.

1.1 Deklarativer Zustand in Git

Alles, was ArgoCD verwaltet, ist einfacher Kubernetes YAML, der in ein Repository committet wird. Es gibt keine imperativen kubectl run in einem GitOps-Workflow. Ein minimales TaskBoard-Bereitstellungsmanifest 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 trägt einen Git-SHA anstelle von latest. Dies ist der Promotion-Hebel: Das Ändern des Tags in Git ist das, was eine neue Rollout auslöst, und das Tag sagt Ihnen genau, welcher Commit ausgeführt wird.

1.2 Drift-Erkennung und Selbstheilung

Wenn jemand kubectl scale deployment/taskboard-api --replicas=5 direkt gegen das Cluster ausführt, entspricht der Live-Zustand nicht mehr dem Git-Zustand, der noch replicas: 2 sagt. Ein GitOps-Controller im Selbstheil-Modus erkennt diesen Unterschied bei seinem nächsten Synchronisationszyklus und skaliert wieder auf 2 zurück. Die Lektion für Ihr Team ist operativ: Das Cluster ist für Menschen schreibgeschützt. Alle Änderungen erfolgen durch 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-Produkt, daher wird es auf MKS auf die gleiche Weise installiert wie auf jedes konforme Kubernetes Cluster. Die IONOS-spezifischen Teile sind, wie Sie die kubeconfig erhalten, wie der ArgoCD-Server verfügbar gemacht wird (was vom MKS-LoadBalancer-Modell abhängt, das in Abschnitt 4 behandelt wird) und wie Bildabrufe gegen das IONOS Container-Repository authentifiziert werden.

2.1 Abrufen der kubeconfig und Installation von ArgoCD

Sie bereitstellen den Cluster mit Terraform und rufen die kubeconfig ab, bevor Sie etwas installieren. IONOS dokumentiert drei Konfigurationsverwaltungspfade für das 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"
}

Mit dem kubeconfig auf dem Platz, installieren Sie ArgoCD in seinem 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

Der ArgoCD-Plan wird auf Ihre MKS-Instanz angewendet. Die Steuerungsebenenkomponenten, die IONOS verwaltet (der K8s-Server, CSI, CCM, Calico und CoreDNS), werden von IONOS während der Wartung aktualisiert und sind nicht etwas, das ArgoCD berührt.

2.2 Definieren der Anwendungs-CRD

Das Kernobjekt von ArgoCD ist die Application-Benutzerressource. Es verweist auf ein Git-Repository, einen Pfad innerhalb davon und ein Ziel-Cluster und eine Namensraum. automated synchronisiert mit prune und selfHeal, was es zu einer wahren GitOps-Schleife macht: prune löscht Ressourcen, die aus Git entfernt wurden, und selfHeal revertiert manuelle Cluster-Änderungen.

# 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. Von diesem Punkt an löst jeder Commit im overlays/prod-Pfad eine Wiederherstellung aus.

3. Repository-Topologie: Trennung von Infrastruktur und Anwendungen

Der häufigste GitOps-Fehler bei IONOS ist das Mischen von Terraform-verwalteter Infrastruktur und ArgoCD-verwalteter Anwendungen an einem Ort und dann das Beobachten, wie sie miteinander kämpfen. Das saubere Muster sind zwei Repositorys mit einer klaren Eigentumsbegrenzung.

Das Infrastruktur-Repository enthält Terraform: ionoscloud_k8s_cluster, ionoscloud_k8s_node_pool, Netzwerke, Datenbanken und das Container-Register. Es wird auf Merge zu main durch Ihre CI-Pipeline angewendet. Das Anwendungs-Repository enthält Kubernetes-Manifeste und Kustomize-Overlays, und ArgoCD überwacht es.

3.1 Eigentumsbegrenzung

Die Regel ist einfach: Wenn eine Ressource durch terraform apply erstellt wird, darf ArgoCD sie niemals verwalten, und wenn eine Ressource durch ArgoCD-Synchronisation erstellt wird, darf Terraform sie niemals verwalten. Die Übergabe erfolgt durch Ausgaben. Terraform erzeugt die Cluster und das Registry-Pull-Geheimnis; ArgoCD verbraucht die Cluster und deployt in sie.

# 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 setzt die Begrenzung explizit für TaskBoard fest.

Wie oben gezeigt, teilen sich die Controller niemals eine Ressourcentyp, sodass keiner den anderen rückgängig macht.

3.2 Die imagePullSecret-Übergabe

Das Container-Register bei IONOS verwendet tokenbasierte docker login nur; es gibt kein RBAC und keine pro-Team-Repositorys. Das Pull-Geheimnis ist die einzige Anmeldeinformation, die die Infrastruktur-Anwendungs-Grenze überquert. Erstellen Sie es einmal aus dem Registertoken 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 Geheimnis eine Anmeldeinformation enthält, dürfen Sie es nicht im Klartext committen. Entweder erstellen Sie es imperativ wie oben (einmal, außerhalb von Git) oder verwenden Sie einen sealed-secrets- oder external-secrets-Operator, damit ArgoCD eine verschlüsselte Form verwalten kann.

4. IONOS-Spezifische Abstimmungshazarden

GitOps geht davon aus, dass das Cluster vorhersehbar funktioniert. Zwei MKS-Verhaltensweisen brechen diese Annahme, wenn Sie nicht entsprechend planen: Knoten sind unveränderlich und werden neu erstellt, anstatt gepatcht zu werden, und ein LoadBalancer-Dienst stellt keinen echten externen Load Balancer bereit.

4.1 Unveränderliche Knoten und das Wartungsfenster

MKS-Knoten sind unveränderlich. Jedes Node-Pool-Upgrade erstellt jeden Node, der dem Pool angehört, neu, anstatt ihn vor Ort zu patchen, und 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 alle Komponenten innerhalb von Cluster, einschließlich der Steuerungsebene, CSI, CCM, Calico und CoreDNS.

Die GitOps-Implication ist, dass Pods verdrängt und auf frisch erstellten Knoten neu geplant werden, und zwar nach einem Zeitplan, den Sie nicht kontrollieren. Ihre Manifeste müssen diese Situation tolerieren. Legen Sie Bereitschaftssonden fest, damit ArgoCD und Dienste nur den Datenverkehr zu bereiten Pods weiterleiten, und verwenden Sie ein PodDisruptionBudget, damit der Neubau nicht alle Repliken auf einmal herunterfährt.

# 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 Neubau erfordert auch Server-Quoten-Spielraum: Ein Node-Neubau stellt einen neuen Node bereit, bevor der alte entfernt wird, sodass der Neubau nicht abgeschlossen werden kann, wenn Sie Ihre Vertrags-Server-Quoten ausgeschöpft haben. Halten Sie Quoten-Spielraum gleich wenigstens einem Node pro Pool.

4.2 Die LoadBalancer-Dienst-Falle

Dies ist die Gefahr, die die meisten Teams überrascht, die ArgoCD oder TaskBoard exponieren. In MKS ist ein Service von type: LoadBalancer kein echter externer Load Balancer. IONOS Cloud reserviert eine statische öffentliche IP und weist sie als sekundäre IP einem Worker-Node zu, das als Eingangs-Node fungiert, und kube-proxy leitet den Datenverkehr zum Ziel-Pod um. Die Quell-IP geht verloren, es sei denn, Sie setzen externalTrafficPolicy: Local, und die Durchsatzleistung ist auf die öffentliche Obergrenze von 2 Gbit/s dieses einzelnen Eingangs-Node begrenzt.

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 Ein-Node-Obergrenze zu überschreiten, skalieren Sie horizontal über mehrere LoadBalancer-IPs und Eingangsknoten mit DNS-Lastverteilung oder stellen Sie den Dienst mit einem separat bereitgestellten Managed ALB (bereitgestellt im Infrastruktur-Repository über Terraform, niemals automatisch erstellt aus einem Manifest) vor. Für Produktions-TaskBoard-Datenverkehr ist der ALB-Pfad die richtige Antwort und hält die Eingangs-Bedenken in der Terraform-eigenen Ebene.

5. Umgebungsweiterleitung und ephemere Demontage

Die Weiterleitung über Umgebungen hinweg ist ein Git-Vorgang und kein Deploy-Skript. Mit Kustomize enthält eine gemeinsame Basis die Manifeste und jede Umgebung ist ein Overlay, das Replikazahlen, Ressourcenlimits und den Image-Tag patcht.

5.1 Kustomize-Overlays

Die Basis definiert TaskBoard einmal, die Overlays unterscheiden sich pro Umgebung. Die Weiterleitung eines Builds von der Staging- zur Produktionsumgebung 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

Jeder ArgoCD Application zeigt auf einen unterschiedlichen Overlay-Pfad (overlays/dev, overlays/staging, overlays/prod), sodass das gleiche Repository alle drei Umgebungen antreibt und der Unterschied zwischen ihnen in Git überprüfbar ist.

5.2 Ephemere Branchen-Umgebungen und Abbau

Für Feature-Branches richten Sie eine wegwerfbare Umgebung ein und bauen Sie sie bei Merge oder Schließen des Branches ab. Terraform-bereitgestellte Ressourcen verursachen Kosten ab dem Zeitpunkt der Bereitstellung, sodass der automatisierte Abbau eine Kostenkontrolle und kein Luxus ist. Der CI-Job ruft terraform destroy für den Stapel 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 }}"

Eine wichtige Überlegung bei der Bereinigung ist spezifisch für den MKS-Speicher: IONOS-Volume werden in Kubernetes als PersistentVolume-Ressourcen dargestellt, und die PV-Rückgewinnungspolitik bestimmt, was mit dem zugrunde liegenden Volume passiert, wenn der Anspruch gelöscht wird. Wenn die Rückgewinnungspolitik Retain ist, bleiben bei der Löschung des Namespaces oder dem Ausführen von terraform destroy auf dem Cluster verwaiste IONOS-Volume in Ihrem virtuellen Rechenzentrum (VDC) zurück, die weiterhin berechnet werden. Entweder legen Sie die Rückgewinnungspolitik auf Delete für ephemere Umgebungen fest oder bereinigen Sie die verbleibenden Volume explizit nach der Demontage.

API Referenz-Quick-Card

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: Einrichten von ArgoCD Auto-Sync für TaskBoard-Manifeste auf MKS, Übermitteln einer Manifest-Änderung und Beobachten der Wiederherstellung durch die Versöhnung, dann Abbauen einer Branch-Umgebung.

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: Abrufen der kubeconfig von Terraform

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: Installieren von ArgoCD

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, die auf TaskBoard-Manifeste verweist

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: Manuelles Einführen von Drift

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 sich selbst zur Git-deklarierten Zustand zurückversetzt

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: Förderung eines neuen Bildes über Git-Commit

# 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: Abbauen einer Branch-Umgebung

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: Überprüfen, ob keine verwaisten Volumes verbleiben

ionosctl volume list --datacenter-id $DC_ID

Erwartete Ausgabe:

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

Validierungs-Checkliste:

• [ ] ArgoCD berichtet Synced und Healthy für TaskBoard
• [ ] Manuelle Skalierungsänderung wird durch Selbstheilung innerhalb des Synchronisierungsintervalls rückgängig gemacht
• [ ] Bild-Tag-Commit löst einen Rollout ohne kubectl apply aus
• [ ] terraform destroy entfernt den Branch-Stack und hinterlässt keine Abrechnungs-Volumes

Aufräumen:

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

Häufige Fallstricke

Entwicklerfehler, die bei GitOps und Bereitstellungsoperationen auf IONOS vermieden werden sollten:

1. Terraform und ArgoCD kämpfen um dieselbe Ressource

   • Problem: Terraform verwaltet einen Kubernetes-Dienst, während ArgoCD ihn auch aus Git synchronisiert. Jeder apply und jede Synchronisation setzen die andere zurück, was einen endlosen Kampf und flatternde Ressourcen erzeugt.
   • Warum es passiert: Es gibt keine klare Eigentumsbegrenzung zwischen dem Infrastruktur-Repository und dem Anwendungs-Repository.
   • Lösung: Stellen Sie sicher, dass Terraform nur die IONOS-Infrastruktur (Cluster, Node Pools, Registry, Datenbanken) besitzt und ArgoCD nur die in-Cluster-Manifeste besitzt. Übergeben Sie die Cluster und die Registry zwischen ihnen durch Terraform-Ausgaben, nie indem beide das gleiche Objekt verwalten.

2. ArgoCD oder TaskBoard mit type: LoadBalancer exponieren und ein reales LB erwarten

   • Problem: Der gesamte Datenverkehr landet auf einem einzelnen Worker-Node, die Client-Quelle IP geht verloren und die Durchsatzleistung erreicht einen Plateauwert von etwa 2 Gbit/s ohne offensichtlichen Grund.
   • Warum es passiert: Ein MKS-LoadBalancer-Dienst stellt keinen externen Load Balancer bereit. IONOS weist eine statische öffentliche IP als sekundäre IP einem einzelnen Ingress-Node zu und kube-proxy NATs zum Pod.
   • Lösung: Stellen Sie externalTrafficPolicy: Local so ein, dass die Quelle IP erhalten bleibt, und stellen Sie den Dienst für die Produktion mit einem separat bereitgestellten Managed ALB aus der Terraform-Schicht bereit, anstatt sich auf den einzelnen-Node-Dienst zu verlassen.

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

   • Problem: Sie terraform destroy eine Branch-Umgebung, aber Sie werden weiterhin berechnet und die verwaisten Volumes bleiben im VDC.
   • Warum es passiert: IONOS-Volumes unterstützen PersistentVolumes, deren Rückforderungsrichtlinie Retain ist, so dass das Löschen des Anspruchs oder des Namespaces die zugrunde liegende Volume-Ressource zurücklässt.
   • Lösung: Verwenden Sie eine StorageClass mit einer Rückforderungsrichtlinie Delete für ephemere Umgebungen oder fügen Sie einen Abbau-Schritt hinzu, der die verbleibenden Volumes mit ionosctl volume list und ionosctl volume delete auflistet und entfernt.

Zusammenfassung

Sie können jetzt einen echten pull-basierten GitOps-Workflow auf IONOS Managed Kubernetes ausführen. ArgoCD versöhnt TaskBoards erklärten Zustand aus Git, heilt manuelle Abweichungen selbst und fördert Builds durch Umgebungen mit einem einzigen Image-Tag-Commit. Sie halten Terraform und ArgoCD in separaten Repositories mit einer sauberen Eigentumsbegrenzung, sodass die beiden Controller einander nie überschreiben. Sie wissen auch die beiden MKS-Verhaltensweisen, die naive GitOps-Annahmen brechen, und wie man sie umgeht.

Der operative Gewinn ist, dass die Produktion jetzt für Menschen schreibgeschützt ist, jede Änderung ein überprüfbarer Commit ist und die Rückgängigstellung ein git revert ist. Die Umgebungen für Zweige sind verwurfbar und bauen sich selbst ab, und Sie vermeiden die Falle der verwaisten Volume-Abrechnung, indem Sie die richtige Rückgewinnungspolitik festlegen.

Wichtige Punkte:

• GitOps verwendet ein Pull-Modell: Ein Controller innerhalb des Cluster versöhnt den gewünschten Zustand von Git, wodurch Commits zum Auslöser für die Bereitstellung und die Rückgängigstellung werden
• Trennen Sie das Terraform-eigene Infrastruktur-Repository vom ArgoCD-eigenen Anwendungs-Repository, um Versöhnungskämpfe zu vermeiden
• MKS-Knoten sind unveränderlich und werden während des wöchentlichen Wartungsfensters (max. 4 Stunden) neu erstellt; verwenden Sie PodDisruptionBudgets und Readiness-Sonden, damit Bereitstellungen die Neuerstellung überstehen
• Ein MKS-LoadBalancer-Dienst ist kein echter externer Lastenausgleich: ein Eingangs-Node, verlorene Quell-IP, es sei denn, externalTrafficPolicy: Local, und eine Decke von 2 Gbit/s; verwenden Sie einen gemanagten ALB für die Produktion
• Automatisieren Sie die terraform destroy für Umgebungen von Zweigen und legen Sie die PV-Rückgewinnungspolitik auf Delete fest, um verwaiste, immer noch abgerechnete Volumen zu vermeiden

Wichtige Begriffe:

• GitOps: Ein Betriebsmodell, bei dem Git die einzige Wahrheitsquelle ist und ein Controller innerhalb des Cluster kontinuierlich den Live-Zustand mit dem kommitierten deklarativen Zustand versöhnt
• Abweichung: Abweichung zwischen dem Live-Cluster-Zustand und dem gewünschten Zustand, der in Git deklariert ist, verursacht durch manuelle Änderungen oder externe Prozesse
• Selbstheilung: Ein ArgoCD-Synchronisationsmodus, der automatisch Live-Änderungen zurück zum Git-deklarierten Zustand reverts
• Rückgewinnungspolitik: Die Kubernetes-Einstellung für PersistentVolume (Retain oder Delete), die bestimmt, ob das zugrunde liegende IONOS-Volume entfernt wird, wenn sein Anspruch gelöscht wird
• Eingangs-Node: Die einzelne MKS-Worker-Node, die eine LoadBalancer-Service-Reservierung für eine öffentliche IP als sekundäre IP erhält und den Datenverkehr auf Ziel-Pods umleitet

Nächste Schritte

Weiterlernen: Einheit 5.4: Wissensprüfung - Produktionsvorgänge

Verwandte Themen:

• Einheit 3.3: CI/CD-Pipelines für IONOS
• Einheit 5.2: Automatisierung der Sicherheit