Debug de pods con Ephemeral Containers
A veces el pod no tiene curl, ni ping, ni un shell decente porque está construido con una imagen mínima (distroless, scratch, alpine recortada). Cuando algo falla en producción no quieres reconstruir la imagen ni redeployar solo para meter herramientas: para eso existen los Ephemeral Containers.
Un ephemeral container es un contenedor que se agrega temporalmente a un pod en ejecución para diagnosticar problemas. Comparte los namespaces de red y proceso del pod, por lo que ves su tráfico, sus archivos abiertos, sus variables — pero no necesita estar declarado en el manifiesto original.
Crear un debug container con kubectl debug
La forma más común de usarlos es a través de kubectl debug:
kubectl debug buggypod --image=debian --attach
Lo que hace este comando:
- Inyecta un contenedor temporal con la imagen
debiandentro del podbuggypod. --attachte conecta de inmediato a su salida.- Al ser un contenedor más en el pod, puedes hacer
curl,dig,tcpdump, etc., contra los servicios que el pod ve.
Opciones útiles:
# Compartir el namespace de proceso para ver los PIDs de los otros containers
kubectl debug buggypod --image=nicolaka/netshoot \
--target=app --share-processes -it
# Crear una copia del pod con un container extra, sin tocar el original
kubectl debug buggypod -it --copy-to=buggypod-debug --image=busybox
Para usar
--targetel cluster debe permitir compartir process namespace, y la versión de Kubernetes debe ser ≥ 1.25 para queephemeralContainersesté GA.
Por qué falla con frecuencia: certificados y red
Cuando estés depurando comunicación entre pods o hacia servicios externos, antes de culpar al código revisa la capa de transporte:
- Certificados SSL/TLS vencidos o no confiados por la imagen base.
- Nombres DNS que no resuelven (CoreDNS,
searchdelresolv.conf). NetworkPoliciesque bloquean el tráfico saliente.- Puertos cerrados en el firewall del nodo.
El ephemeral container con nicolaka/netshoot viene con dig, nslookup, curl, openssl s_client, tcpdump y casi cualquier herramienta de red que necesites.
RBAC: lo que necesitas para usar kubectl debug
Para crear ephemeral containers, la cuenta que ejecuta kubectl debug necesita permisos sobre el subrecurso pods/ephemeralcontainers. Algunas combinaciones típicas de RBAC son:
- Role + RoleBinding → permisos limitados a un namespace.
- ClusterRole + ClusterRoleBinding → permisos globales en el cluster.
- ClusterRole + RoleBinding → reutilizas un ClusterRole pero restringes su alcance a un namespace concreto.
Ejemplo mínimo para permitir debug en un namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: app
name: debugger
rules:
- apiGroups: [""]
resources: ["pods", "pods/ephemeralcontainers"]
verbs: ["get", "list", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: app
name: debugger
subjects:
- kind: User
name: oncall
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: debugger
apiGroup: rbac.authorization.k8s.io
Con esto el usuario oncall puede ejecutar kubectl debug contra cualquier pod del namespace app sin tener permisos elevados en el resto del cluster.
Resumen
Los ephemeral containers son el sustituto moderno de "entrar al pod a depurar". No requieren rebuild, no quedan registrados en el manifiesto y se eliminan cuando el pod muere. Combínalos con una imagen como netshoot o busybox y tendrás una caja de herramientas lista para los incidentes del día a día.