Los pods nacen y mueren con IPs diferentes. Ningún cliente serio va a seguir eso. El Service da un nombre y una IP estable; el Ingress da una puerta de entrada HTTP(S); el DNS resuelve nombres; el TLS protege el camino.

\n

\n

Sello del curso: testado en Kubernetes 1.35, ingress-nginx y cert-manager.

\n

\n

Service: el nombre estable

\n

Un Service selecciona pods por label y balancea el tráfico.

\n

apiVersion: v1\nkind: Service\nmetadata:\n  name: api\n  namespace: portal\nspec:\n  selector:\n    app: api\n  ports:\n    - port: 80\n      targetPort: 8080\n  type: ClusterIP\n

\n

Tipos:

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Tipo	Acceso	Uso
ClusterIP	interno	por defecto; app → app
NodePort	puerto en cada nodo	laboratorio, acceso directo
LoadBalancer	IP externa	nube con LB
ExternalName	CNAME	apuntar a servicio externo
Headless (clusterIP: None)	DNS por pod	StatefulSet

\n

Verifique si el Service encontró los pods:

\n

kubectl -n portal get endpoints api\nkubectl -n portal get endpointslices\n

\n

Si ENDPOINTS está vacío, el selector no coincidió con ningún pod o los pods no están Ready. Este es el error nº 1 de Service.

\n

DNS

\n

El CoreDNS resuelve nombres dentro del clúster:

\n

api.portal.svc.cluster.local\n

\n

Dentro del mismo namespace, api ya resuelve. Entre namespaces, use api.portal o el FQDN completo.

\n

kubectl -n portal run dns --image=busybox:1.36 --rm -it --restart=Never -- \\\n  nslookup api.portal\n

\n

Cuidado con ndots y search domains: los nombres parciales pueden intentarse en varios sufijos antes de resolver. En aplicaciones sensibles a la latencia, use el FQDN.

\n

NodePort y LoadBalancer

\n

NodePort abre un puerto (30000–32767) en todos los nodos:

\n

spec:\n  type: NodePort\n  ports:\n    - port: 80\n      targetPort: 8080\n      nodePort: 30080\n

\n

Es útil para laboratorio, pero malo para producción: expone puertos, no hace TLS y depende de la IP del nodo. En cloud, LoadBalancer aprovisiona un LB; en bare-metal, necesita MetalLB o equivalente.

\n

Ingress: la puerta HTTP

\n

Ingress es una regla L7: host + path → Service.

\n

apiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n  name: portal\n  namespace: portal\nspec:\n  ingressClassName: nginx\n  rules:\n    - host: portal.exemplo.com\n      http:\n        paths:\n          - path: /\n            pathType: Prefix\n            backend:\n              service:\n                name: frontend\n                port:\n                  number: 80\n          - path: /api\n            pathType: Prefix\n            backend:\n              service:\n                name: api\n                port:\n                  number: 80\n

\n

Requisitos:

\n

\n
• Un Ingress Controller instalado (ingress-nginx, Traefik, etc.).
\n
• ingressClassName correcto.
\n
• DNS del host apuntando al controller.
\n
• Service con endpoints saludables.
\n

\n

Pruebe localmente con --resolve:

\n

curl -k --resolve portal.exemplo.com:443:127.0.0.1 https://portal.exemplo.com/\n

\n

TLS con cert-manager

\n

El cert-manager emite y renueva certificados. Un ClusterIssuer para Let's Encrypt:

\n

apiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n  name: letsencrypt-prod\nspec:\n  acme:\n    server: https://acme-v02.api.letsencrypt.org/directory\n    email: [email protected]\n    privateKeySecretRef:\n      name: letsencrypt-prod\n    solvers:\n      - http01:\n          ingress:\n            class: nginx\n

\n

En el Ingress:

\n

metadata:\n  annotations:\n    cert-manager.io/cluster-issuer: letsencrypt-prod\nspec:\n  tls:\n    - hosts:\n        - portal.exemplo.com\n      secretName: portal-tls\n

\n

Siga:

\n

kubectl -n portal get certificate,order,challenge\nkubectl -n portal describe certificate portal-tls\n

\n

Use el staging de Let's Encrypt en las pruebas: el de producción tiene rate limit y va a toparse con él.

\n

Laboratorio

\n

\n
1. Suba un Deployment y un Service ClusterIP.
\n
2. Pruebe con port-forward.
\n
3. Cree un Ingress con host ficticio y pruebe con --resolve.
\n
4. Emita un certificado (staging) y verifique el secret TLS.
\n
5. Fuerce HTTP → HTTPS con una annotation del ingress-nginx.
\n

\n

Errores comunes

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Síntoma	Causa
Service sin endpoints	selector incorrecto o pods no Ready
404 en el Ingress	host/path no coinciden o class incorrecta
502/503	Service sin endpoints o app fuera de servicio
Certificado no emitido	DNS no apunta, challenge bloqueado o rate limit
default backend - 404	Ingress no encontrado en el controller
DNS no resuelve	CoreDNS roto o namespace incorrecto

\n

Checklist

\n

\n
• [ ] Service con selector y endpoints correctos.
\n
• [ ] Sé la diferencia entre ClusterIP, NodePort e Ingress.
\n
• [ ] Ingress con ingressClassName y DNS apuntando.
\n
• [ ] TLS emitido y renovando.
\n
• [ ] Probé HTTP → HTTPS.
\n
• [ ] No expuse NodePort innecesariamente.
\n

\n

Glosario

\n

\n
• ClusterIP: IP virtual interna del Service.
\n
• EndpointSlice: lista de pods listos detrás del Service.
\n
• Ingress: regla L7 de entrada.
\n
• Ingress Controller: implementación que aplica el Ingress.
\n
• ACME: protocolo de Let's Encrypt.
\n
• ClusterIssuer: emisor de certificados para todo el clúster.
\n

\n

Próximo

\n

Ahora que la aplicación está accesible, vamos al capítulo más útil del curso: qué hacer cuando el pod no arranca.

\n

Próximo: Curso Kubernetes 10 — El primer “no arrancó”: diagnosticando pods