Kubernetes (Kind) Course consejos de supervivencia

1. Tu mejor amigo en la terminal:`k9s`

Olvídate de escribirkubectl get podsveinte veces por minuto. Instala k9s. Es una interfaz de terminal (TUI) para gestionar el cluster. Te permite navegar entre pods, ver logs, entrar en la shell del contenedor y matar procesos con atajos de teclado.

Por qué te sirve: Te da visibilidad instantánea de cuando algo falla (se pone rojo) y te permite ver los logs en tiempo real sin recordar comandos largos.

2. La documentación integrada:`kubectl explain`

Antes de ir a Google, prueba esto. Si estás escribiendo un YAML para un Pod y no recuerdas cómo definir los puertos, escribe en tu terminal:kubectl explain pod.spec.containers.ports

Por qué te sirve: Te da la documentación de la API directamente en la terminal, te dice qué campos son obligatorios y qué tipo de dato esperan (string, int, array).

3. La trampa del "Latest"

Cuando definas las imágenes en tus manifiestos (ej:image: nginx),evita usar el tag**:latest**o no poner tag.

Motivo: Kubernetes a veces cachea las imágenes. Si usaslatest, puede que hagas un cambio, redespliegues, y K8s siga usando la versión vieja que ya tenía descargada.
Consejo: Usa versiones específicas (nginx:1.21) o shas. Para tus pruebas, asegúrate de que la política de descarga (imagePullPolicy) esté clara (en KIND suele serIfNotPresent, pero si estás desarrollando localmente a veces necesitasNeveroAlways).

4. Networking: El punto de dolor #1

Aquí es donde KIND y K3S difieren más y donde más te vas a atascar.

En KIND: Estás dentro de Docker. Si un servicio es tipoNodePort, no podrás acceder a él directamente desde tu navegador (localhost) a menos que hayas mapeado puertos al crear el cluster o useskubectl port-forward.
En K3S: Si el nodo tiene una IP en tu red (ej: 192.168.1.50), unNodePortsí será accesible directamente en esa IP.
El salvavidas universal: Cuando no logres conectar a tu aplicación, usakubectl port-forward. Funciona igual en ambos y salta todas las reglas de firewall/ingress. Es la mejor herramienta para depurar si el fallo es la app o la red.

5. Divide y vencerás: Usa Namespaces (`ns`)

No despliegues todo en el namespacedefault. Crea uno para cada prueba:

kubectl create ns wordpress-test

Y en tus YAML añadenamespace: wordpress-test(o usakubectl apply -f archivo.yaml -n wordpress-test).

Por qué te sirve: Cuando te canses o "rompas" algo irreparablemente, simplemente borras el namespace (kubectl delete ns wordpress-test) y Kubernetes limpiará todo lo que había dentro (servicios, pods, secretos) de una vez. Es mucho más limpio que borrar recursos uno a uno.

6. Depuración: La "Santa Trinidad"

Cuando un Pod falle (estadoCrashLoopBackOffoError), sigue este orden estricto de investigación:

kubectl describe pod <nombre-del-pod>: Mira la sección "Events" al final. Te dirá si falta un secreto, si no cabe en el nodo o si la imagen no existe.
kubectl logs <nombre-del-pod>: Te dirá por qué la aplicación explotó internamente (error de base de datos, variable de entorno faltante).
kubectl get pod <nombre-del-pod> -o yaml: A veces lo que K8s "entendió" no es lo que tú escribiste en tu archivo. Esto te muestra la verdad del cluster.

7. Almacenamiento (PVCs)

Ten en cuenta que cuando pidas un volumen (PVC), si borras el PVC, por defecto K8s borrará los datos. Si quieres conservar datos entre pruebas destructivas, investiga sobre laReclaimPolicy: Retain