Hi everyone — I’ve been focusing on a concept for CI/CD and self-hosted agents on AKS (Azure Kubernetes Service). This post gives an overview of the design: YAML (which is essential here) and the system architecture.

Architecture overview

Quick reference for abbreviations:

• Terraform ~ tf
• Kubernetes ~ K8s

Implementation approach

Technical approach: Because we’re designing and running the system (workload executor) entirely on Kubernetes, we need to check recent Kubernetes releases and choose the right approach to avoid wasting time.

When designing and running CI/CD workloads (agents) on K8s, we often think of DinD (Docker in Docker) — and many people still use it. However, Kubernetes removed support for this from around release v19 and officially in v1.24, specifically the dockershim interface. (Details: Check if dockershim removal affects you.)

In short:

The dockershim component of Kubernetes allows the use of Docker as a Kubernetes’s container runtime. Kubernetes’ built-in dockershim component was removed in release v1.24.

If you still use DinD (it can still work in some setups) to build Docker images, you may see:

can't create unix socket /var/run/docker.sock: is a directory

Also, with DinD you often need root permission for some tasks to work properly.

Quick comparison: DinD vs Kaniko

Feature/Aspect	Docker-in-Docker (DinD)	Kaniko
Security	Requires privileged access, higher risk	No privileged access, more secure
Resource Usage	Higher (full Docker daemon)	Lower (no Docker daemon)
Compatibility	Full Docker feature support	Most Docker features, some limitations
Ease of Use	Familiar Docker CLI	Different workflow
Performance	Generally faster with caching	May be slower, caching varies
CI/CD Integration	Works with many CI/CD systems	Best with Kubernetes-native CI/CD
Setup Complexity	Higher (nested containers)	Simpler in Kubernetes

The next part will go deeper into self-hosted agents with AKS and Azure DevOps.