“Kubernetes is removing Docker support”
Det var en rubrik som skapade onödigt mycket förvirring. Om man bara läste den lät det som att Docker och Kubernetes plötsligt inte längre fungerade ihop, men så var det inte.
Vad som faktiskt togs bort
Kubernetes använde tidigare Docker Engine via något som kallades dockershim. När det stödet togs bort slutade Kubernetes prata direkt med Docker som container runtime på noden. I stället används runtimes som följer Container Runtime Interface, till exempel containerd eller CRI-O.
Det här påverkar inte formatet på images i sig. Images byggda i Docker är fortfarande OCI-kompatibla och kan köras i Kubernetes precis som tidigare.
När märker du av förändringen?
För de flesta team märktes nästan ingenting. Bygger ni images i vanliga CI/CD-system eller lokalt och pushar till ett registry, fortsätter flödet i stort sett som vanligt.
- Bygger ni images i Azure DevOps, GitHub Actions, GitLab eller liknande: normalt ingen dramatik.
- Kör ni ett vanligt utvecklarflöde med Docker lokalt: normalt ingen dramatik.
- Försöker ni bygga images inuti själva klustret med Docker-kommandon: där kan ni behöva andra verktyg.
Vad används i stället?
Om du behöver bygga images inne i klustret finns andra verktyg för det, exempelvis Kaniko eller Podman beroende på upplägg. Poängen är att problemet inte är containerimages, utan den specifika kopplingen till Docker Engine som runtime.
Kort sammanfattning
Rubriken var större än konsekvensen. Kubernetes tog bort stödet för dockershim, inte stödet för att köra OCI-baserade images. För de flesta organisationer fortsätter Docker och Kubernetes därför att fungera bra tillsammans i praktiken, även om implementationen under huven ser annorlunda ut.