Cuando algo falla en Kubernetes, es muy fácil decir “Kubernetes está roto”. Pero muchas veces el problema no está en Kubernetes. Está en DNS, almacenamiento, certificados, networking, imágenes, permisos, dependencias externas o configuración de la aplicación.
Kubernetes hace visible el fallo, pero no siempre lo causa. Un CrashLoopBackOff, un Pending, un 503 o un timeout son síntomas. La clave es saber bajar por capas.
kubectl get nodes -o wide kubectl describe node NODO kubectl top nodes
Revisa:
Ready / NotReady DiskPressure MemoryPressure PIDPressure NetworkUnavailable versiones mezcladas nodos cordoned recursos disponibles
Si varios pods fallan en el mismo nodo, puede que el problema sea del nodo y no de la aplicación.
kubectl get pods -A -o wide kubectl describe pod POD -n NAMESPACE kubectl logs POD -n NAMESPACE kubectl logs POD -n NAMESPACE --previous
Estados típicos:
CrashLoopBackOff ImagePullBackOff Pending ContainerCreating Evicted OOMKilled
--previous es clave cuando el contenedor reinicia. Muchas veces ahí está el error real.
kubectl get events -A --sort-by=.lastTimestamp
Los eventos suelen dar la pista más rápida:
FailedScheduling FailedMount BackOff Unhealthy FailedCreatePodSandBox ErrImagePull ImagePullBackOff Evicted
Antes de borrar pods, mira eventos.
kubectl get pods -n kube-system kubectl logs -n kube-system deployment/coredns kubectl run dns-test --rm -it --image=busybox -- nslookup kubernetes.default
Muchos errores de conexión entre servicios son realmente fallos de resolución DNS interna.
kubectl get pvc -A kubectl get pv kubectl describe pvc PVC -n NAMESPACE
Problemas habituales:
PVC Pending FailedMount StorageClass incorrecta backend NFS/Ceph/Longhorn degradado permisos volumen no disponible
Si el pod queda en ContainerCreating mucho tiempo, revisa storage y eventos.
En Kubernetes y especialmente en RKE2/Rancher, los certificados pueden afectar API Server, ingress, webhooks, registros internos y comunicación entre componentes.
kubectl get certificates -A 2>/dev/null kubectl get secrets -A | grep tls curl -Iv https://servicio.dominio.com openssl s_client -connect dominio.com:443 -servername dominio.com /dev/null | openssl x509 -noout -dates
Un certificado caducado o mal servido puede parecer una caída de aplicación.
kubectl get ingress -A kubectl describe ingress INGRESS -n NAMESPACE kubectl get svc -A kubectl get endpoints -A
Antes de culpar al ingress controller, mira endpoints. Si el service no tiene endpoints, el ingress no tiene backend real.
503 suele indicar backend no disponible 502 suele indicar problema hablando con backend timeout puede ser red, endpoint, firewall o aplicación lenta
kubectl get pods -n kube-system kubectl get nodes -o wide kubectl describe pod POD -n NAMESPACE
Errores típicos:
FailedCreatePodSandBox network plugin not ready failed to setup network CNI plugin error
Si los pods no obtienen IP o no se comunican entre nodos, el problema puede estar en CNI, rutas, firewall, MTU o red física.
En RKE2:
journalctl -u rke2-server -n 200 --no-pager journalctl -u rke2-agent -n 200 --no-pager
Buscar:
context deadline exceeded etcd unhealthy certificate expired websocket close 1006 failed to reconcile network unavailable
kubectl cluster-info kubectl get --raw='/readyz?verbose' kubectl get --raw='/healthz?verbose'
Si la API responde lenta o falla, todo lo demás se vuelve confuso. En ese caso hay que revisar control-plane, etcd, certificados, recursos y conectividad.
kubectl get nodes -o wide kubectl get pods -A -o wide kubectl get events -A --sort-by=.lastTimestamp kubectl get svc -A kubectl get endpoints -A kubectl get ingress -A kubectl get pvc -A kubectl top nodes kubectl top pods -A
Con estos comandos ya puedes orientar una gran parte de incidencias.
En muchas incidencias el problema no está en Kubernetes. Está en DNS, almacenamiento, certificados, networking, imágenes, permisos, recursos o dependencias externas.
Kubernetes no siempre es la causa. Muchas veces es el sitio donde el problema se hace visible.
Antes de culpar a Kubernetes, revisa capas: nodos, pods, eventos, servicios, endpoints, ingress, DNS, storage, CNI, certificados, logs y API Server. Ese orden evita diagnósticos falsos y reduce mucho el tiempo perdido.
En entornos RKE2, Rancher o Kubernetes productivo, el valor no está solo en saber desplegar. Está en saber diagnosticar cuando algo deja de comportarse como esperabas.