Final Talk - GitOps in de praktijk

1. Wat we nu echt hebben staan

Vandaag hebben we niet "een demo" gebouwd, maar een complete GitOps-loop:

Git bevat de gewenste state.
ArgoCD reconcilet de cluster daarnaar.
Tekton wijzigt Git (image-tag bump), en ArgoCD pakt dat weer op.
Alles is reproduceerbaar op een nieuwe VM.

Snelle architectuur

Laptop/browser
  -> argocd.192.168.56.200.nip.io
  -> podinfo.192.168.56.200.nip.io
  -> grafana.192.168.56.200.nip.io

VirtualBox host-only netwerk

VM (k3s)
  -> ingress-nginx + MetalLB
  -> ArgoCD (app-of-apps)
  -> Tekton (CI in-cluster)
  -> podinfo (demo workload)
  -> monitoring (bonus)

Componenten in 1 regel

Component	Waarom die hier zit
k3s	Lichtgewicht Kubernetes voor lokale labs
ArgoCD	GitOps controller
MetalLB	LoadBalancer IP op bare metal/VM
ingress-nginx	HTTP routing op hostnames
Tekton	Pipeline als Kubernetes resources
podinfo	Eenvoudige app om deploys zichtbaar te maken
kube-prometheus-stack	Metrics en dashboards

2. Waarom dit productie-relevant is

Zonder GitOps (klassieke drift)

kubectl set image deployment/api api=company/api:hotfix

Dat werkt snel, maar je verliest context: geen review, lastig auditbaar, foutgevoelig.

Met GitOps

Wijziging gaat via commit/PR.
Review + merge.
ArgoCD sync.
Git geschiedenis is je audit trail en rollback-mechanisme.

Concreet voordeel:

Traceerbaarheid: wie veranderde wat en waarom.
Driftcontrole: handmatige clusterwijzigingen vallen op.
Herstelbaarheid: cluster kwijt -> opnieuw opbouwen vanuit Git.
Samenwerking: app- en platformwijzigingen via hetzelfde proces.

3. App-of-Apps in het kort

apps/root.yaml verwijst naar onderliggende Argo Applications.

Dat betekent: nieuwe capability toevoegen = nieuwe app-definitie committen. Geen losse handmatige installatiestappen op de cluster.

4. Grenzen van deze workshop-opzet

Dit is een leeromgeving. In productie zou je strakker willen op o.a.:

Secrets: geen PATs als plain K8s secrets in Git-workflow, maar Vault + ESO of vergelijkbaar.
Security: PSA/namespace policies bewust hardenen i.p.v. versoepelen voor labs.
Multi-cluster: ApplicationSets en promotieflow (dev -> staging -> prod).
Delivery-strategie: canary/blue-green met meetbare rollback-criteria.

5. Wat je mee moet nemen

Als je 1 ding onthoudt:

"Het cluster is een runtime-kopie van wat in Git staat."

Niet andersom.

Dat principe maakt deployments voorspelbaar, bespreekbaar en herstelbaar.

2.8 KiB Raw Blame History