Por qué Kubernetes Importa para QA
Kubernetes (K8s) se ha convertido en la plataforma estándar para ejecutar aplicaciones containerizadas en producción. Si la aplicación que testeas se ejecuta en Kubernetes, entender su arquitectura te ayuda a depurar fallos, entender el comportamiento de despliegue y diseñar tests más efectivos.
No necesitas convertirte en administrador de Kubernetes. Pero como ingeniero QA, necesitas suficiente conocimiento para leer logs de pods, verificar estado de despliegues, entender por qué un entorno de test se comporta mal y comunicarte efectivamente con equipos DevOps.
Arquitectura de Kubernetes
Componentes del Cluster
Un cluster Kubernetes consiste en:
- Control Plane (Master): Gestiona el estado del cluster, scheduling y API
- Worker Nodes: Máquinas que ejecutan contenedores de aplicación
- etcd: Almacén clave-valor distribuido para datos del cluster
Recursos Clave
| Recurso | Propósito | Relevancia QA |
|---|---|---|
| Pod | Unidad más pequeña — uno o más contenedores | Tu aplicación se ejecuta en pods |
| Deployment | Gestiona réplicas de pods y actualizaciones | Rolling updates afectan tus tests |
| Service | Endpoint de red estable para pods | Cómo los tests se conectan a la aplicación |
| Namespace | Aislamiento de cluster virtual | Entornos de test como namespaces |
| ConfigMap | Datos de configuración | Configuraciones del entorno de test |
| Secret | Datos sensibles | API keys, credenciales de BD |
| Ingress | Acceso HTTP/S externo | Routing de URLs para entornos de test |
Comandos kubectl Esenciales para QA
Visualizando Recursos
# Listar todos los pods en el namespace actual
kubectl get pods
# Listar pods en un namespace específico
kubectl get pods -n staging
# Obtener información detallada del pod
kubectl describe pod my-app-abc123
# Listar todos los services
kubectl get services
# Observar pods en tiempo real
kubectl get pods -w
Depurando Aplicaciones
# Ver logs del pod
kubectl logs my-app-abc123
# Seguir logs en tiempo real
kubectl logs -f my-app-abc123
# Ejecutar un shell dentro de un pod
kubectl exec -it my-app-abc123 -- bash
# Port-forward para acceder a un pod localmente
kubectl port-forward my-app-abc123 3000:3000
# Verificar uso de recursos
kubectl top pods
Namespaces para Entornos de Test
Los namespaces proporcionan aislamiento dentro de un cluster. Los equipos comúnmente usan namespaces para crear entornos de test separados:
production → Aplicación en vivo
staging → Testing pre-producción
qa → Entorno de test del equipo QA
feature-xyz → Entorno efímero para un feature específico
Escenarios Comunes de QA en Kubernetes
Escenario 1: Tests Fallan Después del Despliegue
Tus tests E2E repentinamente fallan después de un nuevo despliegue. Verifica:
# ¿Está el pod ejecutándose?
kubectl get pods -n staging
# ¿Hay reinicios recientes?
kubectl describe pod app-pod-name -n staging
# Verificar logs de la aplicación
kubectl logs app-pod-name -n staging --tail=100
Escenario 2: Fallos Intermitentes de Tests
Los tests pasan a veces y fallan otras. Posibles causas relacionadas con K8s:
- Escalado de pods: Requests llegando a diferentes pods con diferentes estados
- Límites de recursos: Pod quedándose sin memoria o CPU
- Fallos de liveness probe: Pod reiniciándose durante el test
Ejercicio: Depura un Entorno de Test Fallido
Tu equipo despliega una aplicación en un namespace staging de Kubernetes. Los tests E2E que funcionaban ayer ahora fallan con timeout “connection refused.” Recorre los pasos de depuración.
Solución
Paso 1: Verificar estado de pods
kubectl get pods -n staging
Busca: CrashLoopBackOff, ImagePullBackOff, Pending, o 0/1 Ready.
Paso 2: Verificar eventos y logs del pod
kubectl describe pod app-pod-name -n staging
kubectl logs app-pod-name -n staging
Busca: OOM killed, health checks fallidos, errores de configuración.
Paso 3: Verificar el service
kubectl get service my-app -n staging
kubectl get endpoints my-app -n staging
Busca: Endpoints faltantes (no hay pods saludables respaldando el service).
Paso 4: Verificar despliegues recientes
kubectl rollout status deployment/my-app -n staging
kubectl rollout history deployment/my-app -n staging
Causas raíz comunes:
- Nuevo despliegue tiene un bug — pod crashea al iniciar
- Tag de imagen Docker incorrecto — ImagePullBackOff
- Variable de entorno o secret faltante
- Cuota de recursos excedida — pod no puede ser programado
- Política de red bloquea tráfico — service inalcanzable
Patrones de Testing en Kubernetes
Patrón 1: Namespace por PR
Crea un namespace efímero para cada pull request con el stack completo. Elimina después de que los tests pasen.
Patrón 2: Staging Compartido
Un solo namespace staging con la última rama main desplegada. Todos los tests QA se ejecutan aquí.
Patrón 3: Desarrollo Local con Minikube
Ejecuta un cluster Kubernetes local para testing de desarrollo.
Conclusiones Clave
- Conoce suficiente K8s para depurar fallos de tests —
kubectl get pods,kubectl logsykubectl describeson tus herramientas principales - Los namespaces aíslan entornos de test — cada equipo o feature puede tener su propio namespace
- El ciclo de vida de pods afecta los tests — reinicios, escalado y límites de recursos causan fallos intermitentes
- Los services proporcionan endpoints estables — siempre conecta tests a services, no directamente a pods
- Colabora con DevOps — QA no gestiona el cluster pero debe entenderlo para diagnosticar problemas