Los problemas de networking en Kubernetes pueden ser difíciles de diagnosticar porque un mismo síntoma puede tener muchas causas.

Una aplicación puede mostrar:

1Connection refused
2Connection timed out
3No route to host
4Name or service not known
5502 Bad Gateway
6503 Service Unavailable

pero el problema podría encontrarse en:

 1Application
 2    |
 3Pod
 4    |
 5Pod Network
 6    |
 7Service
 8    |
 9EndpointSlice
10    |
11NetworkPolicy
12    |
13Ingress / Gateway
14    |
15Load Balancer
16    |
17DNS
18    |
19External Network

La mejor estrategia no es comenzar cambiando configuraciones.

Es seguir la conexión capa por capa hasta encontrar exactamente dónde deja de funcionar.

En este tercer artículo de nuestra serie de Kubernetes Troubleshooting vamos a investigar:

• conectividad Pod-to-Pod;

• Services;

• EndpointSlices;

• DNS;

• puertos y targetPort;

• NetworkPolicies;

• Ingress;

• Gateway API;

• LoadBalancers;

• CNI;

• conectividad hacia servicios externos.

Entender primero el modelo de red de Kubernetes

Antes de hacer troubleshooting necesitamos entender algunas expectativas básicas del modelo de networking.

Cada Pod recibe su propia dirección IP dentro del cluster.

En condiciones normales, y salvo que existan mecanismos explícitos de aislamiento, la red del cluster debe permitir comunicación Pod-to-Pod, incluso cuando los Pods estén en diferentes nodos.

Los contenedores que pertenecen al mismo Pod comparten network namespace y pueden comunicarse utilizando:

1localhost

Kubernetes Services agregan otra capa de abstracción:

 1Client Pod
 2    |
 3    v
 4Service
 5    |
 6    v
 7EndpointSlice
 8    |
 9    +------ Pod A
10    |
11    +------ Pod B
12    |
13    +------ Pod C

El Service proporciona una dirección estable mientras los Pods detrás de él pueden aparecer, desaparecer o cambiar de IP.

Nuestro flujo de troubleshooting

Para networking utilizaremos un principio simple:

Probar primero el destino más cercano y después avanzar una capa a la vez.

Por ejemplo, si:

1https://api.example.com

no funciona, no comenzamos inmediatamente revisando DNS público o el Ingress Controller.

Primero comprobamos:

 1Application listening?
 2       |
 3       v
 4Pod IP reachable?
 5       |
 6       v
 7Service reachable?
 8       |
 9       v
10EndpointSlice correct?
11       |
12       v
13DNS working?
14       |
15       v
16NetworkPolicy allows traffic?
17       |
18       v
19Ingress / Gateway route?
20       |
21       v
22Load Balancer?
23       |
24       v
25Public DNS?

Esto nos permite reducir progresivamente el área del problema.

1. Comienza por los Pods

Supongamos que tenemos:

1frontend
2   |
3   v
4api-service
5   |
6   v
7api Pods

y el frontend reporta:

1connection refused

Primero revisamos los Pods backend:

1kubectl get pods \
2  -n production \
3  -o wide

Busca:

• STATUS;

• READY;

• IP;

• NODE;

• restart count.

Por ejemplo:

1NAME                      READY   STATUS    IP
2api-7cf8f76bcd-jx9pq      1/1     Running   10.244.1.23
3api-7cf8f76bcd-qt8fz      1/1     Running   10.244.2.15

Running no garantiza que la aplicación esté aceptando conexiones, pero confirma que podemos continuar investigando.

2. ¿La aplicación realmente está escuchando?

Una causa común de problemas de networking no está realmente en Kubernetes.

La aplicación puede no estar escuchando en el puerto esperado.

Si la imagen contiene herramientas adecuadas:

1kubectl exec \
2  -n production \
3  <pod> -- \
4  ss -lntp

También podemos comprobar localmente dentro del Pod:

1kubectl exec \
2  -n production \
3  <pod> -- \
4  curl -v http://127.0.0.1:8080/health

Si esto falla:

1Pod
2 |
3 X
4Application

todavía no tiene sentido investigar el Service.

Primero debemos entender por qué la aplicación no está escuchando.

Un problema clásico: escuchar solamente en localhost

Supongamos que nuestra aplicación inicia con:

1127.0.0.1:8080

Dentro del contenedor:

1curl http://127.0.0.1:8080

puede funcionar.

Pero otros Pods intentarán alcanzar la aplicación usando la IP del Pod:

110.244.1.23:8080

Si la aplicación únicamente está vinculada a loopback, esa conexión puede fallar.

Muchas aplicaciones dentro de Kubernetes necesitan escuchar en:

10.0.0.0

o en una interfaz adecuada del Pod.

3. Probar directamente el Pod IP

Desde otro Pod podemos probar la dirección del backend.

Una forma útil de crear un Pod temporal de debugging es:

1kubectl run network-debug \
2  -n production \
3  --rm -it \
4  --restart=Never \
5  --image=curlimages/curl \
6  -- sh

Dentro:

1curl -v http://10.244.1.23:8080

Si funciona:

1Debug Pod
2    |
3    v
4Pod IP
5    |
6    v
7Application
8    |
9    OK

hemos confirmado:

• Pod networking básico;

• puerto del Pod;

• aplicación.

Ahora podemos avanzar hacia el Service.

Si no funciona, debemos investigar:

1Application
2Pod networking
3NetworkPolicy
4CNI
5Node networking

4. Investigar el Service

Lista los Services:

1kubectl get svc \
2  -n production

Después:

1kubectl describe svc api-service \
2  -n production

Revisa especialmente:

1Selector
2Type
3IP Families
4ClusterIP
5Port
6TargetPort

Un Service puede verse perfectamente saludable como objeto Kubernetes y aun así no enviar tráfico correctamente.

Service port vs targetPort

Considera:

1ports:
2  - port: 80
3    targetPort: 8080

El flujo es:

1Client
2   |
3   | :80
4   v
5Service
6   |
7   | :8080
8   v
9Pod

port es el puerto presentado por el Service.

targetPort es el puerto hacia el backend.

Si nuestra aplicación escucha en:

18080

pero configuramos:

1targetPort: 3000

el Service existe y puede resolver correctamente por DNS, pero el tráfico no llegará al proceso esperado.

5. EndpointSlices: ¿el Service tiene backends?

Esta es una de las comprobaciones más importantes.

Actualmente deberíamos investigar principalmente EndpointSlices:

1kubectl get endpointslices \
2  -n production \
3  -l kubernetes.io/service-name=api-service

Para obtener más información:

1kubectl describe endpointslice \
2  -n production \
3  -l kubernetes.io/service-name=api-service

EndpointSlice es la API que Kubernetes utiliza para representar eficientemente los backends asociados a un Service.

Podemos pensar:

1Service
2   |
3   v
4EndpointSlice
5   |
6   +--- 10.244.1.23:8080
7   |
8   +--- 10.244.2.15:8080

Si encontramos endpoints, podemos probar esas IPs directamente.

¿Qué pasa si no existen endpoints?

Tenemos:

1Service
2   |
3   v
4EndpointSlice
5   |
6   X
7No backend Pods

Una de las primeras cosas que debemos revisar es el selector del Service.

1kubectl get svc api-service \
2  -n production \
3  -o yaml

Por ejemplo:

1selector:
2  app: api

Ahora revisamos los labels de los Pods:

1kubectl get pods \
2  -n production \
3  --show-labels

Si los Pods tienen:

1app=backend-api

pero el Service busca:

1app=api

no existe match.

El resultado será un Service sin los backends esperados.

Readiness también importa

Supongamos que los labels sí coinciden.

Pero:

1kubectl get pods -n production

muestra:

1NAME           READY
2api-abc        0/1
3api-def        0/1

Una readiness probe fallando puede hacer que esos Pods no sean considerados endpoints listos para tráfico normal.

Podemos comprobarlo con:

1kubectl describe pod api-abc \
2  -n production

y revisar las condiciones del EndpointSlice:

1kubectl get endpointslices \
2  -n production \
3  -l kubernetes.io/service-name=api-service \
4  -o yaml

Los EndpointSlices pueden incluir condiciones como:

1ready
2serving
3terminating

Esto permite diferenciar si un backend está disponible para recibir tráfico y si está en proceso de terminación.

6. Probar el Service desde dentro del cluster

Una vez confirmado que existen backends:

1kubectl run network-debug \
2  -n production \
3  --rm -it \
4  --restart=Never \
5  --image=curlimages/curl \
6  -- sh

Dentro:

1curl -v http://api-service

o:

1curl -v http://api-service:80

También podemos probar directamente el ClusterIP:

1curl -v http://10.96.120.15:80

Esto produce una distinción muy útil.

Pod IP funciona, Service IP falla

1Client
2  |
3  +---- Pod IP --------> OK
4  |
5  +---- Service IP ----> FAIL

Ahora podemos concentrarnos en:

1Service configuration
2EndpointSlice
3Service proxy implementation
4Node networking

Dependiendo de la plataforma y configuración, el dataplane del Service puede involucrar componentes como kube-proxy o implementaciones proporcionadas por el networking stack.

Service IP funciona, Service DNS falla

1Service ClusterIP
2       |
3       OK
4
5Service name
6       |
7       FAIL

Eso apunta fuertemente hacia DNS.

7. DNS troubleshooting

Kubernetes proporciona descubrimiento de Services mediante DNS.

Desde un Pod en el mismo namespace podemos utilizar normalmente:

1api-service

Desde otro namespace:

1api-service.production

o el FQDN:

1api-service.production.svc.cluster.local

El cluster domain puede configurarse de forma diferente, por lo que cluster.local es común pero no debe asumirse universalmente en cualquier cluster.

Probar resolución

Desde un Pod con herramientas DNS:

1nslookup api-service

Después:

1nslookup api-service.production

Y finalmente:

1nslookup api-service.production.svc.cluster.local

También podemos revisar:

1cat /etc/resolv.conf

Un ejemplo podría contener:

1search production.svc.cluster.local svc.cluster.local cluster.local
2nameserver 10.96.0.10
3options ndots:5

Esto explica por qué nombres cortos pueden funcionar dentro de un namespace y comportarse diferente desde otro.

Revisar CoreDNS

Si DNS falla para múltiples aplicaciones:

1kubectl get pods \
2  -n kube-system \
3  -l k8s-app=kube-dns

También podemos revisar el Service DNS:

1kubectl get svc \
2  -n kube-system

Y logs:

1kubectl logs \
2  -n kube-system \
3  -l k8s-app=kube-dns

Dependiendo del deployment, puede existir más de un contenedor o réplica, por lo que en incidentes reales conviene identificar exactamente qué Pods están procesando las consultas.

Una distinción importante

Considera:

1nslookup api-service
2        |
3       FAIL
4
5nslookup kubernetes.default
6        |
7       FAIL

Eso sugiere un problema DNS más general.

Pero:

1nslookup kubernetes.default
2        |
3        OK
4
5nslookup api-service
6        |
7       FAIL

entonces deberíamos revisar:

1Service name
2Namespace
3Service existence
4DNS record creation

antes de asumir que CoreDNS está completamente roto.

8. NetworkPolicy

Otro escenario común:

1Pod A -> Pod B

funcionaba hasta que implementamos nuevas políticas de red.

Comenzamos con:

1kubectl get networkpolicy -A

Después:

1kubectl describe networkpolicy \
2  <policy> \
3  -n production

También debemos revisar los labels:

1kubectl get pods \
2  -n production \
3  --show-labels

porque NetworkPolicy selecciona Pods mediante labels.

NetworkPolicies son aditivas

Este comportamiento es importante.

Si múltiples NetworkPolicies seleccionan un Pod, no se evalúan como reglas de firewall ordenadas de arriba hacia abajo.

Las reglas permitidas se combinan.

Para una conexión Pod-to-Pod:

1Source Pod
2    |
3    | Egress must allow
4    v
5Network
6    |
7    | Ingress must allow
8    v
9Destination Pod

Cuando ambos lados están aislados por NetworkPolicy, tanto el egress del origen como el ingress del destino deben permitir la conexión.

Probar NetworkPolicy

Desde el origen:

1kubectl exec \
2  -n frontend \
3  <frontend-pod> -- \
4  curl -v --connect-timeout 5 \
5  http://api-service.production:8080

También podemos probar TCP:

1nc -vz \
2  api-service.production \
3  8080

Si:

1DNS resolves
2       |
3       v
4Correct destination IP
5       |
6       v
7Connection timeout

NetworkPolicy, routing o firewall se vuelven hipótesis más fuertes.

Atención al CNI

Definir una NetworkPolicy no significa automáticamente que el cluster pueda aplicarla.

El networking implementation del cluster debe soportar NetworkPolicy enforcement.

Por lo tanto:

1NetworkPolicy exists
2        |
3        X
4does not necessarily mean
5traffic is being enforced

El comportamiento dependerá del network plugin utilizado.

9. Pod-to-Pod funciona en el mismo nodo, pero falla entre nodos

Este es un escenario muy útil para identificar problemas de CNI o infraestructura.

Supongamos:

1Node A
2  |
3  +-- Pod A
4       |
5       | works
6       v
7  +-- Pod B

pero:

1Node A                  Node B
2  |                       |
3Pod A -----------------> Pod C
4            FAIL

Eso cambia significativamente nuestra hipótesis.

Revisa dónde están los Pods:

1kubectl get pods \
2  -A \
3  -o wide

Después revisa los nodos:

1kubectl get nodes -o wide

Ahora podemos investigar:

• CNI Pods;

• routing;

• encapsulation;

• firewall;

• MTU;

• node interfaces;

• IP allocation.

Identificar el networking stack

Dependiendo de nuestra distribución Kubernetes podemos encontrar componentes diferentes.

Una inspección inicial:

1kubectl get pods \
2  -n kube-system \
3  -o wide

Podemos encontrar implementaciones como:

1Calico
2Cilium
3Flannel
4Antrea
5cloud-provider-specific networking

Cada implementación tendrá herramientas y métricas diferentes.

No debemos asumir comandos específicos de Calico o Cilium hasta confirmar qué plugin utiliza el cluster.

10. CNI y problemas de asignación de IP

Si nuevos Pods no pueden obtener conectividad, Events pueden contener pistas.

1kubectl describe pod <pod> \
2  -n production

Busca errores relacionados con:

1sandbox creation
2network setup
3CNI
4IP allocation

También:

1kubectl get events -A \
2  --sort-by='.lastTimestamp'

Puede ayudar a correlacionar si múltiples Pods o nodos comenzaron a presentar errores simultáneamente.

11. MTU: el problema que parece aleatorio

Algunos problemas de networking aparecen así:

1Small request
2     |
3     OK
4
5Large request
6     |
7     timeout

o:

1TCP connection
2     |
3     established
4     |
5TLS handshake / large response
6     |
7     FAIL

Una posible causa es un problema de MTU.

Esto puede aparecer en redes con:

• overlays;

• VXLAN;

• VPNs;

• cloud networking;

• tunnels.

Podemos investigar interfaces:

1ip link

y rutas:

1ip route

Pero cualquier cambio de MTU debe hacerse entendiendo el CNI y la red subyacente. Ajustarlo por prueba y error puede crear problemas adicionales.

12. Ingress troubleshooting

Ahora supongamos:

1curl http://api-service.production

funciona dentro del cluster.

Pero:

1https://api.example.com

no funciona desde fuera.

Esto es importante:

1Pod       OK
2Service   OK
3DNS       OK
4         |
5         v
6Problem is farther upstream

Ahora sí investigamos Ingress.

1kubectl get ingress -A

Después:

1kubectl describe ingress <name> \
2  -n production

Revisa:

1IngressClass
2Host
3Path
4Backend Service
5Backend Port
6TLS
7Events
8Address

Ingress necesita un controller

Crear:

1kind: Ingress

por sí solo no implementa el routing.

El cluster necesita un Ingress Controller que observe esos recursos y configure el dataplane correspondiente.

Podemos revisar:

1kubectl get ingressclass

y encontrar el controller apropiado según la plataforma.

Después revisamos sus Pods y logs.

Por ejemplo, si sabemos que utiliza un namespace específico:

1kubectl get pods \
2  -n <ingress-controller-namespace>

y:

1kubectl logs \
2  -n <ingress-controller-namespace> \
3  <controller-pod>

No debemos asumir que todos los clusters utilizan ingress-nginx.

502 vs 503

El significado exacto depende del proxy/controller utilizado, pero estos códigos pueden ayudarnos a orientar la investigación.

Por ejemplo:

 1External Client
 2      |
 3      v
 4Ingress Controller
 5      |
 6      +---- backend unavailable
 7      |
 8      +---- backend connection failure
 9      |
10      +---- timeout

Siempre revisa simultáneamente:

• controller logs;

• backend endpoints;

• application logs;

• latency metrics.

No debemos diagnosticar solamente basándonos en el código HTTP.

13. Gateway API

Para nuevos diseños debemos considerar Gateway API.

El proyecto Kubernetes recomienda Gateway en lugar de continuar expandiendo Ingress.

Ingress continúa soportado, pero su API está congelada.

Conceptualmente podemos tener:

 1Client
 2   |
 3Gateway
 4   |
 5HTTPRoute
 6   |
 7Service
 8   |
 9EndpointSlice
10   |
11Pods

Dependiendo de la implementación podemos revisar recursos como:

1kubectl get gateway -A

1kubectl get httproute -A

1kubectl describe gateway <gateway> \
2  -n <namespace>

1kubectl describe httproute <route> \
2  -n <namespace>

Gateway API no viene implementada automáticamente por el simple hecho de utilizar Kubernetes.

Necesitamos una implementación/controller compatible.

14. LoadBalancer no obtiene IP

Otro problema frecuente:

1kubectl get svc

muestra:

1TYPE           EXTERNAL-IP
2LoadBalancer   <pending>shellscriptshellscript

Aquí debemos entender dónde estamos ejecutando Kubernetes.

1Service type LoadBalancer
2           |
3           v
4Who provides the load balancer?

En un cloud provider puede depender de:

• cloud controller;

• permissions;

• networking;

• quotas;

• subnet configuration;

• load balancer controller.

En clusters bare-metal o locales puede requerir una implementación adicional como un load-balancer controller apropiado para ese entorno.

Kubernetes define la abstracción LoadBalancer, pero la infraestructura debe proporcionar la implementación necesaria.

15. DNS público

Supongamos que:

1Load Balancer
2      |
3      OK

pero:

1api.example.com
2      |
3     FAIL

Comprueba DNS público:

1dig api.example.com

o:

1nslookup api.example.com

Después compara la respuesta con la dirección del load balancer.

También puedes probar directamente:

1curl -v \
2  --resolve api.example.com:443:<IP> \
3  https://api.example.com

Esto es extremadamente útil porque permite probar:

1HTTP/TLS/Host routing

utilizando una IP específica sin depender de la resolución DNS normal.

16. TLS

Un problema de networking puede ser en realidad un problema TLS.

Prueba:

1curl -vk https://api.example.com

Para una inspección más detallada:

1openssl s_client \
2  -connect api.example.com:443 \
3  -servername api.example.com

Revisa:

1certificate chain
2expiration
3SAN
4issuer
5SNI
6hostname

Si utilizamos un Secret Kubernetes:

1kubectl get secret <tls-secret> \
2  -n production

y:

1kubectl describe ingress <ingress> \
2  -n production

o el recurso Gateway correspondiente para confirmar qué certificado debería utilizarse.

17. Pods no pueden salir a Internet

Ahora cambiamos de dirección:

1Pod
2 |
3 v
4Internet
5 |
6 X

Comienza desde el Pod:

1curl -v https://example.com

Después separa DNS de conectividad:

1nslookup example.com

Si DNS funciona pero la conexión no:

1DNS
2 |
3 OK
4 |
5 v
6TCP connection
7 |
8 FAIL

investiga:

• NetworkPolicy egress;

• routing;

• NAT;

• firewall;

• proxy;

• cloud security controls;

• CNI.

DNS vs egress

Por ejemplo:

1nslookup example.com

funciona.

Pero:

1curl https://example.com

timeout.

La resolución DNS funciona, así que no empezamos modificando CoreDNS.

Por el contrario:

1nslookup example.com
2     |
3     FAIL

requiere primero entender si el Pod puede alcanzar el DNS configurado.

18. Database connection timeout

Este mismo flujo es muy útil para bases de datos.

Supongamos que nuestra aplicación muestra:

1connection to database timed out

Dividimos la investigación:

 1Application
 2    |
 3    v
 4DNS resolution
 5    |
 6    v
 7TCP connection
 8    |
 9    v
10TLS
11    |
12    v
13Authentication
14    |
15    v
16Database

DNS:

1nslookup database.example.internal

TCP:

1nc -vz \
2  database.example.internal \
3  5432

Si obtenemos:

1succeeded

ya sabemos que:

1DNS + routing + TCP path

funcionan hasta cierto punto.

Después podemos investigar:

• TLS;

• credentials;

• database availability;

• connection limits;

• application pool.

Networking troubleshooting también consiste en demostrar qué capas sí funcionan.

19. Connection refused vs timeout

Esta diferencia puede aportar información útil.

Connection refused

1Client
2  |
3  v
4Destination reached
5  |
6  v
7Nothing accepting connection

Puede indicar:

• proceso no escuchando;

• puerto incorrecto;

• proxy rechazando conexión.

Timeout

1Client
2  |
3  v
4Packets sent
5  |
6  ?
7  |
8No response

Puede indicar:

• NetworkPolicy;

• firewall;

• routing;

• unavailable destination;

• severe network loss.

No es una regla absoluta, pero ayuda a seleccionar la siguiente prueba.

20. Packet capture

Cuando las pruebas de aplicación no son suficientes, podemos observar los paquetes.

Dependiendo de nuestros permisos y del entorno, podemos utilizar herramientas como:

1tcpdump

Por ejemplo:

1tcpdump -i any -nn \
2  host 10.244.2.15 \
3  and port 8080

Podemos buscar:

1SYN
2SYN-ACK
3RST
4retransmissions

Un patrón como:

1Client                  Server
2
3SYN -------------------->
4
5SYN -------------------->
6
7SYN -------------------->
8
9        no response

apunta a un escenario diferente de:

1Client                  Server
2
3SYN -------------------->
4
5    <-------------- RST

Packet capture puede ayudarnos a comprobar hasta dónde viaja realmente el tráfico.

21. Debugging de nodos

Si sospechamos un problema de red en un nodo específico:

1kubectl get pods -A -o wide

puede revelar algo como:

1Pods on node-01 -> OK
2Pods on node-02 -> FAIL

Ahora la hipótesis cambia de:

1application issue

a algo posiblemente relacionado con:

1node-02
2CNI
3routes
4interfaces
5firewall

Podemos utilizar:

1kubectl debug node/node-02 \
2  -it \
3  --image=ubuntu

y, según los permisos disponibles, revisar:

1ip addr
2ip route
3ip link

Para problemas complejos también podemos revisar logs del networking agent correspondiente al CNI.

22. Metrics

No todo problema de networking produce una falla completa.

También podemos tener:

1Packet loss
2Latency
3Connection resets
4Retries
5Timeouts

Métricas útiles pueden incluir:

1request rate
2error rate
3request duration
4TCP resets
5packet drops
6retransmissions
7DNS latency
8DNS errors
9connection counts

La disponibilidad exacta depende del CNI, ingress/gateway implementation, service mesh y stack de observabilidad.

23. Distributed tracing

Considera una aplicación:

 1Frontend
 2   |
 3   v
 4API
 5   |
 6   v
 7Payment Service
 8   |
 9   v
10Database

El usuario ve una petición de:

15.2 seconds

Un trace puede mostrar:

1Frontend                  20 ms
2   |
3API                       35 ms
4   |
5Payment Service         5.1 sec
6   |
7Database                  25 ms

Ahora sabemos qué dependencia investigar.

Las traces no reemplazan las pruebas de red, pero ayudan a identificar qué salto de una arquitectura distribuida está introduciendo el problema.

24. Logs

Los logs también deben correlacionarse entre diferentes componentes.

Durante un incidente de networking podemos revisar:

1Application logs
2Ingress/Gateway logs
3CNI logs
4CoreDNS logs
5Cloud load balancer logs
6Firewall logs

La idea es seguir la misma conexión.

Cuando sea posible utiliza:

1timestamp
2request ID
3trace ID
4source IP
5destination
6status code

para correlacionar información entre sistemas.

Flujo completo de troubleshooting

Podemos resumir el proceso así:

 1                Request fails
 2                     |
 3                     v
 4              Application alive?
 5                     |
 6                     v
 7             Listening on port?
 8                     |
 9                     v
10               Pod IP works?
11                     |
12                     v
13              Service works?
14                     |
15                     v
16          EndpointSlices correct?
17                     |
18                     v
19                DNS works?
20                     |
21                     v
22          NetworkPolicy allows?
23                     |
24                     v
25       Cross-node networking works?
26                     |
27                     v
28                  CNI healthy?
29                     |
30                     v
31          Ingress / Gateway works?
32                     |
33                     v
34             Load Balancer works?
35                     |
36                     v
37              Public DNS works?
38                     |
39                     v
40                   TLS works?
41                     |
42                     v
43                  Root cause

No todos los incidentes requieren recorrer cada paso.

La clave es utilizar cada prueba para eliminar hipótesis.

Command reference

 1# Pods and nodes
 2kubectl get pods -A -o wide
 3kubectl get nodes -o wide
 4
 5# Services
 6kubectl get svc -A
 7kubectl describe svc <service> -n <namespace>
 8
 9# EndpointSlices
10kubectl get endpointslices \
11  -n <namespace> \
12  -l kubernetes.io/service-name=<service>
13
14kubectl get endpointslices \
15  -n <namespace> \
16  -l kubernetes.io/service-name=<service> \
17  -o yaml
18
19# Labels
20kubectl get pods \
21  -n <namespace> \
22  --show-labels
23
24# DNS
25nslookup <service>
26nslookup <service>.<namespace>
27cat /etc/resolv.conf
28
29# CoreDNS
30kubectl get pods \
31  -n kube-system \
32  -l k8s-app=kube-dns
33
34kubectl logs \
35  -n kube-system \
36  -l k8s-app=kube-dns
37
38# NetworkPolicy
39kubectl get networkpolicy -A
40kubectl describe networkpolicy \
41  <policy> \
42  -n <namespace>
43
44# Ingress
45kubectl get ingress -A
46kubectl describe ingress \
47  <ingress> \
48  -n <namespace>
49
50kubectl get ingressclass
51
52# Gateway API
53kubectl get gateway -A
54kubectl get httproute -A
55
56# Debug Pod
57kubectl run network-debug \
58  -n <namespace> \
59  --rm -it \
60  --restart=Never \
61  --image=curlimages/curl \
62  -- sh
63
64# Node debugging
65kubectl debug node/<node> \
66  -it \
67  --image=ubuntu
68
69# Network tools
70curl -v <url>
71nslookup <hostname>
72dig <hostname>
73nc -vz <hostname> <port>
74ip addr
75ip route
76ip link
77tcpdump -i any -nn

Qué no hacer

Evita comenzar con:

1Service doesn't work
2       |
3       v
4Restart CoreDNS

o:

1502
2 |
3 v
4Restart Ingress Controller

o:

1Timeout
2  |
3  v
4Disable NetworkPolicy

Esas acciones pueden modificar el sistema sin demostrar la causa.

Un mejor proceso es:

 1Symptom
 2   |
 3   v
 4Test one boundary
 5   |
 6   v
 7Record result
 8   |
 9   v
10Eliminate hypotheses
11   |
12   v
13Move one layer
14   |
15   v
16Find failure point
17   |
18   v
19Fix
20   |
21   v
22Validate

Conclusión

Kubernetes networking deja de ser misterioso cuando dejamos de verlo como una sola capa.

Una petición puede recorrer:

 1Client
 2   |
 3DNS
 4   |
 5Load Balancer
 6   |
 7Gateway / Ingress
 8   |
 9Service
10   |
11EndpointSlice
12   |
13Pod network
14   |
15Application

Cada una de estas capas puede comprobarse independientemente.

Por eso una de las técnicas más efectivas durante troubleshooting es preguntar continuamente:

¿Hasta dónde sabemos que funciona la conexión?

Si podemos demostrar:

1Pod IP       -> works
2Service IP   -> works
3Service DNS  -> works
4Ingress      -> fails

ya hemos eliminado una gran parte del sistema de nuestra investigación.

Ese es el objetivo: reemplazar prueba y error por evidencia.

En el siguiente artículo continuaremos con Kubernetes health checks y veremos en detalle:

• readiness probes;

• liveness probes;

• startup probes;

• timeouts;

• thresholds;

• probes que provocan restart loops;

• dependencias externas dentro de health checks;

• cómo un health check incorrecto puede causar una falla en cascada.