Apaga el scheduler y diagnostica el clúster
Este playground no es el k3s cómodo de siempre: es un Kubernetes instalado con kubeadm, con cada componente del control plane a la vista y corriendo por separado en la máquina cplane-01. Has venido a romperlo.
El objetivo es el kube-scheduler, el componente que decide en qué nodo corre cada Pod. Tu trabajo tiene tres partes: retirarlo del clúster, demostrar exactamente qué se rompe con su ausencia, y devolverlo a su sitio.
⚠️ Este experimento es seguro aquí y solo aquí: el playground es efímero y de un solo usuario. En un clúster compartido o de producción, tocar el control plane a mano es cirugía mayor.
Empieza por confirmar que el paciente está sano, desde la pestaña dev-machine:
kubectl get pods -n kube-system -o wide
Primera mitad: la operación
Retira el scheduler del clúster sin destruir su configuración (vas a necesitarla entera dentro de un rato) y, con el clúster ya cojo, pídele un Pod nuevo llamado huerfano.
Pista 1: por dónde se apaga un componente que es un Pod
En un clúster kubeadm, los componentes del control plane son static Pods: no los programó nadie, los ejecuta directamente el kubelet de cplane-01 porque encuentra sus manifiestos en una carpeta concreta del disco. Ese es también el interruptor: si el manifiesto desaparece de la carpeta, el kubelet retira el Pod. La carpeta vive bajo /etc/kubernetes, y todo esto ocurre en la pestaña cplane-01.
Pista 2: el Pod `huerfano`
Créalo como el primer Pod del curso, con la imagen ghcr.io/iximiuz/labs/nginx:alpine. Si lo creaste antes de apagar el scheduler, ya tendrá nodo asignado y no sirve: bórralo y créalo de nuevo con el clúster ya cojo.
El diagnóstico
Ahora observa el síntoma con atención, porque es la parte que de verdad te llevas de este reto. El Pod se ha creado sin problemas (el API server lo aceptó, etcd lo recuerda), está en Pending y su columna NODE está vacía. Pero hay un detalle más elocuente que todos los anteriores, y está en su describe.
Comprueba también, mientras el scheduler duerme, que tus aplicaciones ya programadas siguen funcionando: los kubelets no necesitan al scheduler para mantener lo que ya corre. Los fallos del control plane degradan la capacidad de cambiar el clúster, no derriban lo que ya está en marcha.
Segunda mitad: la resurrección
Devuelve el scheduler a su sitio y mira al huérfano mientras lo haces, porque esto pasa rápido.
Por qué importa
En cuanto el scheduler arranca, encuentra el Pod pendiente en su cola y lo asigna en el acto: Pending a Running en segundos. No ha hecho falta recrear nada ni volver a pedir nada. El estado deseado llevaba todo ese rato guardado en etcd, esperando a que alguien lo atendiera.
Ahí está la idea que sostiene Kubernetes entero: no ejecuta órdenes, persigue estados. Acabas de apagar al perseguidor, ver al estado esperar pacientemente, y verlo alcanzarlo al volver. Y de paso te llevas un reflejo de diagnóstico que vale su peso en oro: un Pending sin eventos es la firma de un scheduler ausente o enfermo, y ahora sabes distinguirlo de un Pending con motivo.