Kubernetes CI/CD: elke commit een image, elke release een commit

Op GitHub Actions bouwen we met docker/setup-buildx-action en docker/build-push-action. BuildKit draait de multi-stage build en bewaart de layer-cache in de GitHub Actions-cache of in de registry. Een wijziging in alleen PHP-code bouwt dan niet opnieuw de composer-dependencies en de frontend-assets. Authenticatie naar AWS, Azure of Google Cloud gaat via OIDC, zonder statische sleutels in je repository-secrets.

Op GitLab CI was Kaniko lange tijd de standaard om zonder Docker-daemon te bouwen. Google heeft de Kaniko-repository in juni 2025 gearchiveerd. Er bestaan forks, maar voor nieuwe pipelines kiezen we liever BuildKit in rootless modus of Buildah. GitLab heeft een eigen container registry per project, dus push en pull blijven in hetzelfde systeem.

Wat er in het image komt, verschilt per platform. Voor Laravel: composer install zonder dev-dependencies, de frontend-build met Vite in een aparte Node-stage, route- en view-cache in de build, en config:cache pas bij het opstarten, omdat die van environment-variabelen afhangt. Voor Magento: setup:di:compile en setup:static-content:deploy in de build, zodat een pod in seconden start in plaats van minuten. Dat vraagt een build-stap met de juiste config.php en themalijst, maar zonder databaseverbinding. Een image bouw je één keer en promoot je door de omgevingen. Opnieuw bouwen voor productie betekent dat je iets anders uitrolt dan je getest hebt.

De tag latest heeft in een productiecluster niets te zoeken. Twee pods met dezelfde tag kunnen verschillende images draaien, afhankelijk van wanneer de node het image ophaalde. Terugrollen naar latest kan niet, want latest is al het nieuwe image. Wij taggen op de commit-SHA, of op een releaseversie met de SHA erin, zoals 2026.10.3-a1b2c3d.

Een tag is een verwijzing die kan veranderen. Een digest, de sha256-hash van het image, kan dat niet. Daarom maken we tags immutable in de registry, en zetten we in productie bij voorkeur de digest in de manifests. In Helm kan dat met een apart digest-veld naast de tag; Kustomize ondersteunt het via het images-blok. Je ziet in Git dan precies welk image er draait, en een Kyverno-policy kan afdwingen dat productie alleen images met een digest accepteert.

Hetzelfde geldt voor alles wat je pipeline zelf gebruikt. In maart 2026 overschreven aanvallers vrijwel alle versietags van de GitHub Action van Trivy met code die credentials stal. Wie de action op een commit-SHA had gepind, had er geen last van. Sinds augustus 2025 kun je SHA-pinning afdwingen in de Actions-policy van je GitHub-organisatie. Dat zetten we standaard aan.

Argo CD synct de config-repository naar het cluster. Migraties draaien als Job met een PreSync-hook: faalt de migratie, dan stopt de sync en blijft de huidige versie draaien. Met sync waves bepalen we de volgorde, bijvoorbeeld eerst ExternalSecrets, dan de migratie, dan de web-pods en als laatste de queue-workers. Bij Magento komt setup:upgrade op die plek, met een strategie voor de korte periode waarin oude code tegen een nieuw schema draait.

Een gewone Deployment doet een rolling update: pods worden één voor één vervangen. Argo Rollouts vervangt de Deployment door een Rollout-resource met een strategie. Bij canary krijgt de nieuwe versie eerst een klein deel van het verkeer, dan meer. Met een AnalysisTemplate controleert Rollouts tussen de stappen Prometheus-metrics zoals het percentage 5xx-responses of de p95-responstijd. Gaat dat over de grens, dan rolt Rollouts zelf terug. Bij blue-green draait de nieuwe versie volledig naast de oude, test je via een preview-Service en schakel je in één keer om.

Voor precieze verkeersverdeling gebruikt Rollouts de traffic router van je ingresslaag. Met de Gateway API gaat dat via de officiële plugin, die de gewichten in een HTTPRoute aanpast. Zonder traffic router verdeelt Rollouts het verkeer via het aantal pods, wat grover is. Canary vraagt wel iets van je applicatie: twee versies draaien tegelijk tegen dezelfde database, cache en queue. Voor Laravel werkt dat goed met migraties volgens expand en contract. Voor Magento met schemawijzigingen is blue-green of een korte canary vaak verstandiger.