Certified GitOps Associate (CGOA)

Beschrijving

Deze cursus bereidt je volledig voor op het CGOA — Certified GitOps Associate examen. Met realistische oefenvragen, foutenanalyse en uitgebreide uitleg per antwoord studeer je gericht en efficiënt.

Onderwerpen

De cursus behandelt alle examenonderwerpen: GitOps-principes, Git-workflows, continuous delivery, Flux en ArgoCD.

Wat zit er in het pakket?

• 60 realistische oefenvragen met foutenanalyse
• Uitgebreide uitleg bij elk antwoord
• 180 dagen toegang
• Voortgangstracking per sessie
• BTW-factuur op aanvraag

Wat leer je in CGOA?

Het CGOA-examen test je kennis van GitOps-principes, tools en best practices. In tegenstelling tot de Red Hat- en Kubernetes-examens is dit een meerkeuze-examen. Je moet de concepten begrijpen, niet per se alle commando’s uit je hoofd kennen.

Studietijd: ~20 uur. Slagingspercentage: 75% van de beschikbare punten.

---

1. GitOps-kernprincipes

De vier OpenGitOps-principes

1. Declaratief: de gewenste toestand wordt beschreven als code (YAML), niet als stappen
2. Versiebeheerd: alle configuratie staat in Git — de enige bron van waarheid
3. Automatisch toegepast: goedgekeurde wijzigingen worden automatisch uitgerold
4. Continu geverifieerd: de werkelijke toestand wordt voortdurend vergeleken met de gewenste toestand

Push versus pull model

• Push-based: een CI/CD-systeem (Jenkins, GitHub Actions) pusht wijzigingen naar het cluster. Het cluster heeft geen verbinding met Git nodig, maar de CI/CD-server heeft cluster-toegang nodig.
• Pull-based: een agent in het cluster haalt wijzigingen op uit Git. Veiliger — het cluster heeft geen inkomende verbindingen nodig. Dit is het GitOps-model.

Drift detectie en herstel

Drift treedt op wanneer de werkelijke clustertoestand afwijkt van de gewenste toestand in Git — bijvoorbeeld door een handmatige kubectl-opdracht. Een GitOps-operator detecteert drift en herstelt automatisch de gewenste toestand.

---

2. Git-workflows in GitOps

Trunk-based development

Iedereen werkt in kleine commits direct op de main-branch (of via korte feature-branches). Minder mergeconflicten, snellere deployments. Vereist goede testautomatisering.

Environment-branches

Aparte branches per omgeving: dev, staging, production. Promotie = een merge van dev naar staging naar production. Eenvoudig te begrijpen maar kan leiden tot langlevende branches.

Pull requests als poortwachter

Alle wijzigingen gaan via pull requests met code review en geautomatiseerde tests. Na goedkeuring merget de GitOps-operator automatisch en rolt uit. Geen directe kubectl-toegang voor ontwikkelaars.

Rollback

# GitOps-rollback = git revert of git reset
git revert HEAD                    # nieuwe commit die de laatste ongedaan maakt
git push origin main               # GitOps-operator pikt het op en rolt terug

# Of: reset naar een specifieke commit
git reset --hard <commit-hash>
git push --force-with-lease

---

3. Kustomize

Wat is Kustomize?

Kustomize past Kubernetes-manifesten aan via overlays zonder de originele bestanden te wijzigen. Het is ingebouwd in kubectl — geen aparte installatie nodig.

Projectstructuur

mijn-app/
├── base/
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml   # verwijst naar base + dev-patches
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        └── kustomization.yaml

# base/kustomization.yaml
resources:
  - deployment.yaml
  - service.yaml

# overlays/production/kustomization.yaml
resources:
  - ../../base

replicas:
  - name: myapp
    count: 5

images:
  - name: myapp
    newTag: v2.1.0

patches:
  - path: resource-limits-patch.yaml

# Manifesten bekijken (zonder toepassen)
kubectl kustomize overlays/production

# Toepassen
kubectl apply -k overlays/production

---

4. Flux

Flux-architectuur

Flux bestaat uit controllers die als pods in het cluster draaien. Ze bewaken Git-repositories en passen wijzigingen automatisch toe.

Kernresources

• GitRepository: definieert welke Git-repo en branch Flux bewaakt
• Kustomization: definieert welk pad in de repo wordt toegepast op het cluster
• HelmRepository: registreert een Helm chart-repository
• HelmRelease: installeert een Helm chart via Flux

# Flux CLI installeren
curl -s https://fluxcd.io/install.sh | bash

# Cluster bootstrappen (GitHub)
flux bootstrap github 
  --owner=mijn-org 
  --repository=mijn-gitops-repo 
  --branch=main 
  --path=clusters/productie

# Status bekijken
flux get all
flux get sources git
flux get kustomizations

# Handmatig synchroniseren
flux reconcile source git flux-system
flux reconcile kustomization flux-system

# GitRepository resource
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: mijn-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/mijnorg/mijn-app
  ref:
    branch: main

---
# Kustomization resource
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: mijn-app
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: mijn-app
  path: "./overlays/productie"
  prune: true          # verwijder resources die niet meer in Git staan

---

5. Beveiliging in GitOps

Sealed Secrets

Kubernetes Secrets kun je niet veilig in Git opslaan (base64 is geen encryptie). Sealed Secrets versleutelt secrets zodat alleen de controller in het cluster ze kan ontsleutelen.

# Secret versleutelen
kubeseal --format yaml < secret.yaml > sealed-secret.yaml

# Nu veilig in Git opslaan
git add sealed-secret.yaml
git commit -m "Sealed secret toevoegen"

SOPS (Secrets OPerationS)

Alternatief voor Sealed Secrets. Versleutelt YAML/JSON-bestanden met GPG, AWS KMS of Azure Key Vault. Flux heeft ingebouwde SOPS-ondersteuning.

Image signing met Cosign

# Image ondertekenen na build
cosign sign --key cosign.key registry.example.com/myapp:v1.0

# Verificatie in Flux configureren
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
spec:
  verification:
    provider: cosign
    secretRef:
      name: cosign-public-key

---

6. Progressive delivery

Canary deployment

Stuur een klein percentage verkeer naar de nieuwe versie. Vergroot geleidelijk op basis van metrics. Bij problemen automatisch terugdraaien.

• Start: 5% verkeer naar v2
• Na 10 minuten zonder fouten: 25%
• Na 30 minuten: 50%
• Na 1 uur: 100% — v1 wordt verwijderd

Blue/Green deployment

Twee identieke omgevingen (blauw = huidig, groen = nieuw). Bij succes wordt al het verkeer in één keer geswitched. Rollback = terugswitchen naar blauw.

Feature flags

Nieuwe features worden uitgerold maar pas ingeschakeld via een configuratieschakelaar. Scheidt deployment van feature-activering.

---

DORA-metrics

DevOps Research and Assessment — vier metrics voor softwareleveringsprestaties:

• Deployment frequency: hoe vaak wordt er uitgerold?
• Lead time for changes: hoe lang van commit tot productie?
• Change failure rate: welk percentage uitrollingen veroorzaakt problemen?
• Time to restore service: hoe snel herstel je na een incident?

GitOps verbetert alle vier metrics door deployments te automatiseren en reproduceerbaar te maken.

---

Officiële documentatie

• OpenGitOps — GitOps-principes
• Flux documentatie
• Kustomize documentatie
• CGOA examenpagina (Linux Foundation)

Tip: dit is een meerkeuze-examen. Focus op de concepten en begrijp het verschil tussen push en pull, drift detectie, en de vier GitOps-principes. Die komen altijd terug.