Este documento explica qué es containerd, qué papel cumple dentro del clúster y por qué es una pieza fundamental aunque casi nunca se vea.
No es un manual de instalación. Es una explicación conceptual.
Mucha gente piensa que Kubernetes “ejecuta contenedores”.
No es exactamente así.
Kubernetes es un orquestador.
Es decir:
Pero Kubernetes no sabe crear contenedores directamente.
Necesita un motor que los ejecute.
👉 Ese motor es el container runtime.
containerd es el runtime que ejecuta los contenedores en cada nodo.
En términos simples:
Es el componente que realmente “hace que algo se ejecute”.
Históricamente Kubernetes utilizaba Docker como runtime.
Pero Docker incluye muchas funciones adicionales que Kubernetes no necesita.
Con el tiempo se separaron responsabilidades:
Hoy en día:
👉 Kubernetes ya no soporta Docker directamente como runtime.
👉 containerd es la opción estándar y recomendada.
Cuando se despliega un Deployment:
Sin containerd:
En cada nodo existen dos piezas clave:
El flujo es:
👉 Kubernetes API → kubelet → containerd → contenedor ejecutándose.
kubelet vigila.
containerd ejecuta.
En este clúster se configuró containerd con:
SystemdCgroup = trueEsto es importante porque:
Es un detalle técnico pequeño, pero crítico.
containerd no:
Solo ejecuta contenedores.
Pero sin él, nada funciona.
Si vemos el clúster por capas:
containerd está en la base de todo.
Es invisible para el usuario.
Pero es imprescindible.
containerd encaja perfectamente con el modelo que se busca:
No añade complejidad innecesaria.
Hace exactamente lo que debe hacer.
Después de leer este documento debe quedar claro que:
Es una pieza pequeña en apariencia.
Pero es el motor real del sistema.
Orquestación sin motor no sirve de nada. containerd es el motor.