Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Cuando una aplicación que corre en Kubernetes no consigue enviar email, la causa rara vez está en un único sitio. La forma más rápida de localizarla es seguir el recorrido del mensaje, desde el pod hasta el servidor SMTP, y detenerse en el primer tramo que falla: la aplicación, la resolución DNS, la conexión TCP de salida, el cifrado TLS, la autenticación y, por último, las restricciones del proveedor cloud. Cambiar credenciales o escalar al equipo de red antes de cerrar esos tramos suele costar más tiempo del necesario.
Qué tramos separar antes de tocar la configuración
Cada tramo produce un síntoma distinto. Si asignas el síntoma al tramo correcto, evitas cambiar algo que ya funciona.
As an Amazon Associate I earn from qualifying purchases.
| Tramo | Síntoma típico | Qué comprobar primero |
|---|---|---|
| Aplicación | Error genérico, reinicios del contenedor, configuración vacía o distinta de la esperada | Logs, eventos y variables de entorno efectivas dentro del pod |
| DNS | Fallo al resolver el hostname del relay, o timeout en la resolución | Resolución del nombre exacto desde el mismo namespace |
| Conexión TCP de salida | Timeout antes de recibir el banner SMTP, o rechazo de conexión | Puerto y destino, NetworkPolicy, firewall de egress, rutas, NAT o proxy |
| TLS | La conexión TCP se establece, pero el handshake falla | Modo STARTTLS frente a TLS implícito, puerto, certificado y hostname |
| Autenticación y remitente | La sesión SMTP llega, pero el servidor rechaza el envío con un código de respuesta | Usuario, contraseña o token, permisos, expiración y dominio remitente autorizado |
| Proveedor cloud | La conexión queda bloqueada aunque el pod y el relay estén bien configurados | Restricciones por defecto de egress del proveedor y del tipo de instancia |
Ruta de diagnóstico, paso a paso
Paso 1: confirmar el síntoma dentro del workload
Empieza por el propio pod. La documentación de Kubernetes trata por separado la depuración de la aplicación y la del clúster, así que conviene descartar primero problemas de la carga de trabajo.
- Revisa el estado y los reinicios:
kubectl get pods -n <namespace> - Inspecciona condiciones y eventos del pod:
kubectl describe pod <pod> -n <namespace> - Lee los logs de todos los contenedores:
kubectl logs <pod> -n <namespace> --all-containers - Ordena los eventos del namespace por tiempo:
kubectl get events -n <namespace> --sort-by=.lastTimestamp
Copia el texto exacto del error y anota la hora en que ocurre. Después clasifícalo en uno de cuatro tipos: timeout, rechazo TCP, fallo de handshake TLS o respuesta SMTP con código. Esa clasificación decide por dónde seguir.
#1 Best Overall
Paso 2: comprobar DNS desde el mismo contexto de red
Resuelve el hostname exacto que usa la aplicación para el relay, no el dominio del proveedor en abstracto. Desde un pod del mismo namespace, con una herramienta de resolución disponible en la imagen, por ejemplo:
kubectl exec -it <pod> -n <namespace> -- nslookup <host-del-relay>
Si la imagen no incluye herramientas de red, usa un pod de diagnóstico en el mismo namespace con las mismas políticas. Si la resolución falla, revisa el propio DNS del clúster:
- Estado de CoreDNS:
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns - Logs de CoreDNS:
kubectl logs -n kube-system -l k8s-app=kube-dns - Service y endpoints:
kubectl get svc,endpoints -n kube-system kube-dns
Un detalle que provoca muchos falsos diagnósticos: un nombre corto solo se busca dentro del namespace del pod. Si el relay vive en otro namespace, usa el nombre completo, por ejemplo <servicio>.<namespace>.svc.cluster.local. La documentación de DNS de Kubernetes consultada corresponde a la versión 1.32 y tiene como última modificación el 22 de mayo de 2024; contrasta el comportamiento con la versión que tienes instalada.
Paso 3: comprobar la conexión TCP de salida
Prueba el puerto y el destino del proveedor desde el pod o desde un pod de diagnóstico autorizado. Por ejemplo, con nc -vz <host> 587, o con un timeout 5 bash -c '</dev/tcp/<host>/587' si la imagen no trae nc.
Si la conexión agota el tiempo antes de recibir el banner SMTP, el problema está en la conectividad o el filtrado, no en las credenciales. Revisa estos elementos según tu topología:
- NetworkPolicy aplicadas al namespace o al pod, y si el plugin de red (CNI) las hace cumplir.
- Reglas de egress del firewall del clúster o de la red del proveedor.
- Rutas, NAT o proxy saliente, que pueden alterar el destino real de la conexión.
No des por universal el puerto 25. Los proveedores aplican reglas distintas, como se ve en la tabla siguiente.
| Proveedor o servicio | Dato documentado | Alcance |
|---|---|---|
| Google Cloud | Bloquea por defecto el egress TCP 25 hacia direcciones externas en ciertos proyectos; el SMTP con TLS en 465 y 587 queda excluido de ese bloqueo | Depende del proyecto y de su configuración; verificar en la documentación vigente |
| AWS EC2 | Documenta límites por defecto para el puerto 25 | Aplica a instancias EC2; el procedimiento para ampliar el límite no está detallado en la documentación consultada |
| AWS SES | Documenta STARTTLS en los puertos habilitados para ese modo y TLS Wrapper en 465 y 2465 | Específico de SES; los puertos admitidos pueden cambiar |
| Cloudflare Email Sending | Asocia el código 535 a fallos de usuario, permiso o estado del token, y el 550 a un dominio remitente no incorporado al servicio | Específico de ese servicio; no extrapolar a otros relays |
Las reglas de esta tabla reflejan la documentación consultada. Los proveedores cambian puertos, restricciones y requisitos de cuenta, así que valida cada dato en su documentación antes de aplicarlo.
Paso 4: validar el modo TLS del puerto
Si TCP conecta, el siguiente paso es comprobar qué espera el servidor en ese puerto. Hay dos modos habituales:
- STARTTLS: la sesión empieza sin cifrar y se actualiza a TLS con un comando explícito. Suele usarse en el puerto 587.
- TLS implícito o Wrapper: la conexión se cifra desde el primer byte. Es el caso habitual del puerto 465.
Para verificarlo puedes usar openssl s_client -starttls smtp -connect <host>:587 o openssl s_client -connect <host>:465. Si el handshake falla, compara cuatro cosas: el modo configurado en la aplicación, el puerto, el hostname y el certificado, y la configuración de la librería SMTP, que en algunos casos activa STARTTLS por defecto aunque el puerto espere TLS implícito.
Paso 5: interpretar la respuesta de autenticación y remitente
Si la sesión SMTP llega al servidor y el TLS se negocia, el problema pasa a la aplicación de identidad. Revisa, en este orden:
- Usuario y contraseña o token, incluido su estado de expiración o revocación.
- Permisos de la credencial para enviar desde esa cuenta o API.
- Autorización del dominio remitente. Muchos servicios exigen verificar o incorporar el dominio antes de aceptar mensajes.
Los códigos de respuesta tienen significado dentro de cada servicio. Por ejemplo, Cloudflare documenta el 535 y el 550 con causas concretas; otro relay puede usar esos mismos números con otro significado. Consulta la tabla de códigos de tu proveedor antes de interpretar una respuesta.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Probes: por qué un SMTP externo no debería reiniciar el pod
Kubernetes distingue tres sondas: startup, readiness y liveness. La documentación de Configure Liveness, Readiness and Startup Probes describe la función general de las sondas con esta frase: “Based on the probe results, Kubernetes can restart unhealthy containers or stop sending traffic to containers that are not ready.”
- Readiness decide si un pod recibe tráfico de un Service.
- Liveness puede provocar el reinicio del contenedor.
Por eso, un fallo del servidor SMTP externo no debería convertirse automáticamente en un fallo de liveness. Si un relay intermitente hace que la sonda reinicie el pod, el resultado puede ser peor que el fallo original, porque el reinicio no arregla el proveedor y reduce la disponibilidad de la aplicación. Esta recomendación es una inferencia de diseño a partir de la función descrita en la documentación, no una regla explícita de Kubernetes.
Observabilidad: detectar el fallo antes que el usuario
Kubernetes expone métricas de sus componentes en formato Prometheus, y el scraping las lleva a una base de series temporales. Para la aplicación, eso solo sirve si expone métricas de envío propias.
- Grafica errores y latencia de envío por tipo: timeout, TLS, autenticación y respuesta del servidor.
- Alerta por acumulación sostenida de fallos, no por un error aislado.
- Si usas Prometheus Operator, valida los ServiceMonitor: los recursos inválidos pueden generar Events, y el objeto depende de un selector correcto y de una referencia válida al Service y al puerto.
No existe una métrica universal de envío de email en Kubernetes. Debes instrumentar la aplicación o usar las métricas que exponga tu relay.
Quick Recap
Secuencia resumida para un incidente
- Clasifica el error: timeout, rechazo TCP, TLS o respuesta SMTP.
- Resuelve el hostname exacto desde el namespace del pod.
- Verifica TCP al puerto del proveedor antes de revisar credenciales.
- Confirma el modo STARTTLS o TLS implícito para ese puerto.
- Interpreta el código SMTP con la documentación del proveedor concreto.
- Revisa si las restricciones del proveedor cloud explican el bloqueo.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
