Kubernetes continue levering: GitOps-pijplijnen met ArgoCD en Flux

Continue levering op Kubernetes is veel verder dan eenvoudig geëvolueerd kubectl apply opdrachten. Moderne teams adopteren GitOps, een paradigma dat Git gebruikt als de enige bron van waarheid voor declaratieve infrastructuur- en applicatieconfiguratie. Door de principes van GitOps te combineren met tools als ArgoCD en Flux CD kunnen organisaties betrouwbare, controleerbare en geautomatiseerde implementatiepijplijnen realiseren die over clusters en omgevingen heen kunnen worden geschaald.

Deze handleiding behandelt de architectuur, opzet en best practices voor het bouwen van pijplijnen voor continue levering op productieniveau op Kubernetes met behulp van de GitOps-aanpak.

GitOps-principes

GitOps is gebouwd op vier kernprincipes die de manier waarop teams implementaties beheren fundamenteel veranderen:

• Declaratieve configuratie - De gehele gewenste staat van uw systeem wordt declaratief beschreven. Voor Kubernetes betekent dit YAML-manifesten, Helm-grafieken of Kustomize-overlays die zijn opgeslagen in Git.
• Versiegestuurd - Git dient als de enige bron van waarheid. Elke wijziging gaat via een pull-request, waardoor een compleet audittraject wordt geboden en eenvoudige rollbacks mogelijk worden gemaakt door commits terug te draaien.
• Geautomatiseerde afstemming - Een agent die in het cluster draait, vergelijkt voortdurend de gewenste status in Git met de werkelijke status in het cluster en stemt eventuele afwijkingen automatisch af.
• Continue observatie - Het systeem bewaakt voortdurend zowel de Git-repository als de clusterstatus, waarschuwt bij afwijkingen en zorgt ervoor dat het cluster altijd overeenkomt met de aangegeven configuratie.

Deze principes elimineren handmatige implementatiestappen, verminderen menselijke fouten en zorgen voor een consistente workflow, ongeacht de clustercomplexiteit.

ArgoCD-architectuur en -installatie

ArgoCD is de meest gebruikte GitOps-tool voor Kubernetes. Het biedt een krachtige web-UI, CLI en API voor het beheren van applicatie-implementaties in clusters.

Kerncomponenten

ArgoCD bestaat uit verschillende belangrijke componenten die samenwerken:

• API-server - Geeft een gRPC/REST API weer en bedient de webinterface. Verwerkt authenticatie, RBAC en externe integraties.
• Repository-server - Kloont Git-opslagplaatsen en genereert Kubernetes-manifesten vanuit Helm-grafieken, Kustomize of gewone YAML.
• Applicatiecontroller - Bewaakt voortdurend actieve applicaties en vergelijkt de live-status met de gewenste status in Git.
• Opnieuw - Biedt caching voor de repositoryserver en applicatiecontroller.

Installatie

Implementeer ArgoCD in uw cluster met behulp van de officiële manifesten of het Helm-diagram:

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

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

Toepassingen definiëren

ArgoCD maakt gebruik van een Application aangepaste resource om te definiëren wat er moet worden geïmplementeerd en waar. Hier is een typische toepassingsdefinitie:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

De syncPolicy.automated sectie maakt automatische synchronisatie mogelijk. De prune optie verwijdert bronnen die niet langer in Git zijn gedefinieerd, while selfHeal zet handmatige wijzigingen terug die rechtstreeks in het cluster zijn aangebracht.

Flux CD: een alternatieve aanpak

Flux CD hanteert een andere architecturale benadering van GitOps. In plaats van een gecentraliseerde server met een gebruikersinterface, werkt Flux als een set Kubernetes-controllers die elk een specifiek probleem afhandelen.

Flux-componenten

• Broncontroller - Beheert Git-opslagplaatsen, Helm-opslagplaatsen en OCI-artefactbronnen.
• Kustomize-controller - Past Kustomize-overlays en gewone YAML-manifesten toe.
• Helm-controller - Beheert Helm-kaartreleases via HelmRelease aangepaste bronnen.
• Meldingsbeheerder - Verwerkt inkomende en uitgaande gebeurtenissen, geïntegreerd met Slack-, Teams- en webhook-providers.
• Controllers voor beeldautomatisering - Scan containerregisters en update manifesten wanneer er nieuwe afbeeldingen beschikbaar zijn.

Flux-bootstrap

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD versus Flux: wanneer moet u kiezen welke?

ArgoCD is ideaal wanneer u een rijke web-UI nodig heeft voor zichtbaarheid, multi-tenancy met fijnmazige RBAC en een gecentraliseerd beheervlak. Flux schittert in omgevingen die de voorkeur geven aan een lichtgewicht, op controllers gebaseerde architectuur, beeldautomatiseringsmogelijkheden nodig hebben of een diepere integratie met het Kubernetes API-ecosysteem willen.

Helmdiagrambeheer in GitOps

Helm-diagrammen zijn het de facto verpakkingsformaat voor Kubernetes-toepassingen. In een GitOps-workflow vereist het beheren van Helm-waarden in verschillende omgevingen een zorgvuldige organisatie.

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

Zowel ArgoCD als Flux ondersteunen Helm native. ArgoCD geeft kaarten server-side weer via de repository-server, terwijl Flux de Helm SDK rechtstreeks in de Helm-controller gebruikt.

Implementatiestrategieën

Door de juiste implementatiestrategie te kiezen, worden de risico's geminimaliseerd en worden releases zonder downtime gegarandeerd.

Rollende updates

De standaard Kubernetes-strategie. Pods worden geleidelijk vervangen door nieuwe versies. Configureer maxSurge En maxUnavailable om de uitrolsnelheid te controleren.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Blauw-groene implementaties

Voer twee identieke omgevingen uit (blauw en groen). Implementeer de nieuwe versie in de inactieve omgeving, verifieer deze en schakel vervolgens het verkeer om. Dit zorgt voor een onmiddellijke terugdraaiing door terug te schakelen naar de vorige omgeving. Implementeer met servicelabelkiezers of Istio-verkeersbeheer.

Canarische implementaties

Leid geleidelijk een klein percentage van het verkeer naar de nieuwe versie, waarbij u het percentage verhoogt naarmate het vertrouwen groeit. Tools zoals Flagger en Argo Rollouts automatiseren canarische analyses met op statistieken gebaseerde promotie.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

Geautomatiseerde terugdraaiingen

GitOps maakt rollbacks eenvoudig: draai eenvoudigweg de Git-commit terug. Geautomatiseerde terugdraaiingen op basis van gezondheidscontroles bieden echter een extra vangnet.

ArgoCD ondersteunt geautomatiseerde rollbacks via zijn synchronisatie- en gezondheidsbeoordelingssysteem. Als een applicatie na een synchronisatie in een verslechterde staat terechtkomt, kan ArgoCD automatisch teruggaan naar de laatst bekende goede staat.

Voor meer geavanceerde rollback-scenario's kunnen Argo Rollouts en Flagger Prometheus-statistieken analyseren, geautomatiseerde tests uitvoeren en implementaties afbreken die verminderde prestaties aantonen.

Geheimenbeheer met verzegelde geheimen

Het opslaan van geheimen in Git is een cruciale uitdaging voor GitOps. Sealed Secrets lost dit op door geheimen te versleutelen die alleen kunnen worden ontsleuteld door de controller die in het doelcluster draait.

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

Het resultaat SealedSecret resource kan veilig worden vastgelegd in Git. Alleen de Sealed Secrets-controller in het doelcluster bevat de privésleutel die nodig is om deze te ontsleutelen. Alternatieve benaderingen zijn onder meer External Secrets Operator (voor het ophalen uit AWS Secrets Manager, HashiCorp Vault, enz.) en SOPS voor versleuteling op bestandsniveau.

Implementaties monitoren

Inzicht in de implementatiestatus is essentieel voor productie-GitOps-pijplijnen. Implementeer monitoring op meerdere niveaus:

• ArgoCD-statistieken - ArgoCD onthult Prometheus-statistieken voor synchronisatiestatus, gezondheid en werkingsduur. Maak Grafana-dashboards om de implementatiefrequentie en foutpercentages bij te houden.
• Kubernetes-evenementen - Bewaak de planning van pods, het ophalen van afbeeldingen en de gereedheidsonderzoeksgebeurtenissen om problemen vroegtijdig op te sporen.
• Statuscontroles van applicaties - Configureer aangepaste gezondheidscontroles in ArgoCD met behulp van Lua-scripts om te definiëren wat "gezond" betekent voor uw specifieke bronnen.
• Waarschuwing - Integreer ArgoCD-meldingen met Slack, PagerDuty of e-mail om te waarschuwen bij synchronisatiefouten, verslechtering van de gezondheid of driftdetectie.

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

Levering in meerdere clusters

Naarmate organisaties groter worden, wordt implementatie over meerdere clusters noodzakelijk. ArgoCD ondersteunt native multi-clusterbeheer door externe clusters te registreren. Flux bereikt dit via een beheercluster dat werklastclusters opstart.

De ApplicationSet-controller in ArgoCD is bijzonder krachtig voor scenario's met meerdere clusters. Het kan op dynamische wijze applicatiebronnen genereren op basis van clusterlijsten, Git-mappen of pull-request-gebeurtenissen.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

Conclusie

GitOps met ArgoCD of Flux CD biedt een robuuste basis voor continue levering van Kubernetes. Door Git te behandelen als de bron van de waarheid, de afstemming te automatiseren en gebruik te maken van progressieve leveringsstrategieën, kunnen teams met vertrouwen inzetten en snel herstellen van mislukkingen. Begin met een eenvoudige configuratie met één cluster, breng uw Git-repositorystructuur tot stand en adopteer geleidelijk geavanceerde patronen zoals canary-implementaties, multi-clusterbeheer en geautomatiseerd rollback-beleid naarmate uw platform volwassener wordt.

De investering in de GitOps-infrastructuur betaalt zich uit door verbeterde betrouwbaarheid, snellere respons op incidenten, volledige audittrails en een ontwikkelaarservaring die implementaties net zo eenvoudig maakt als het samenvoegen van een pull-verzoek.