K8s · Networking y service discovery

01 Capas de red — del internet al Pod

Flujo de tráfico externo → Ingress → Service → Pod

🌍 INTERNET / CLIENTE

api.miempresa.com

→ resuelve via DNS público → IP del LoadBalancer

↓

☁️ CLOUD LOAD BALANCER (Service tipo LoadBalancer)

AWS ALB / GCP GLB

IP Pública: 34.x.x.x

→ puerto 443/80 → NodePort del cluster

↓

🚪 INGRESS CONTROLLER (Nginx / Traefik / Istio)

host: api.miempresa.com

path: /users → svc/users-svc:80

path: /orders → svc/orders-svc:80

→ TLS termination · routing por host/path · rate limiting

↓

🔌 SERVICE (ClusterIP — virtual IP interna)

users-svc · ClusterIP: 10.96.x.x

selector: app=users

→ kube-proxy balancea entre los Pods que matchean el selector

↓

📦 PODS (IPs reales de Pod — efímeras)

users-pod-abc · 172.16.0.5

users-pod-def · 172.16.0.6

users-pod-ghi · 172.16.0.7

02 Tipos de Service — cuándo usar cada uno

Tipo

Accesibilidad

Descripción y caso de uso

Cuándo usarlo

ClusterIP

Solo interno

IP virtual solo accesible dentro del cluster. Es el tipo por defecto. Otros Pods acceden por DNS: svc-name.namespace.svc.cluster.local

Comunicación interna entre microservicios. La gran mayoría de tus Services.

NodePort

Node IP + puerto

Abre un puerto (30000-32767) en cada Node del cluster. Accesible desde fuera via NodeIP:NodePort

Desarrollo local, testing rápido. Evitar en producción — expone puertos en todos los Nodes.

LoadBalancer

IP pública cloud

Provisiona un Load Balancer del cloud provider (AWS ALB, GCP GLB). La IP pública apunta al Service. Caro si tienes muchos Services.

Un LB por Ingress Controller (no uno por Service). O para TCP/UDP que no puede pasar por Ingress HTTP.

ExternalName

DNS alias

Crea un alias DNS interno que apunta a un FQDN externo. my-db → rds.amazonaws.com Útil para integrar servicios externos sin cambiar el código.

Bases de datos RDS, servicios SaaS externos, migración gradual a K8s.

Headless

DNS por Pod

clusterIP: None — sin IP virtual. DNS resuelve directamente a las IPs de cada Pod. Usado por StatefulSets para que los Pods se conozcan entre sí.

Clustering de bases de datos (Kafka, Elasticsearch, MySQL cluster).

03 Ingress — routing HTTP/HTTPS avanzado

🚪

INGRESS · CONCEPTO

Ingress Resource vs Ingress Controller

HTTP routing TLS termination Host-based routing

El Ingress Resource es el YAML con las reglas de routing (declarativo). El Ingress Controller (Nginx, Traefik, Istio Gateway) es el Pod que lee esas reglas y las implementa. Sin Controller, el Resource no hace nada.

Instalar Nginx Ingress Controller:

helm install nginx-ingress ingress-nginx/ingress-nginx
--set controller.replicaCount=2

🔤

DNS INTERNO · COREDNS

CoreDNS — service discovery automático

FQDN Service discovery Namespace DNS

CoreDNS corre en kube-system y resuelve nombres de Services automáticamente. Cada Pod tiene CoreDNS configurado como su resolver.

Formato DNS de Service:

          my-svc                        # mismo namespace

          my-svc.my-ns                  # otro namespace

          my-svc.my-ns.svc.cluster.local # FQDN completo

          pod-0.my-svc.my-ns.svc.local  # StatefulSet Pod

04 YAML de Ingress y práctica — exponer tu app al mundo

ingress.yaml — routing por host y path con TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts: [api.miempresa.com]
    secretName: tls-secret   # Secret con cert.pem + key.pem
  rules:
  - host: api.miempresa.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service: { name: users-svc, port: { number: 80 } }
      - path: /orders
        pathType: Prefix
        backend:
          service: { name: orders-svc, port: { number: 80 } }
---
# Verificar el Ingress
kubectl get ingress
NAME          CLASS   HOSTS               ADDRESS         PORTS     AGE
app-ingress   nginx   api.miempresa.com   34.12.34.56     80, 443   5m

# Debug: ver los endpoints del Service (¿apunta a los Pods correctos?)
kubectl get endpoints users-svc
NAME        ENDPOINTS                                         AGE
users-svc   172.16.0.5:8080,172.16.0.6:8080,172.16.0.7:8080   10m

🔑

Service selector — la magia del balanceo

Un Service encuentra sus Pods por labels selector. Añadir/quitar Pods con ese label actualiza automáticamente el balanceo — sin reiniciar nada.

🚪

Un LB para todo — el patrón correcto

Un solo Service LoadBalancer apunta al Ingress Controller. El Controller hace el routing interno. No crees un LB por microservicio — es caro y difícil de gestionar.

🔤

DNS interno — zero config

No necesitas configurar nada. Desde cualquier Pod, curl users-svc funciona si estás en el mismo namespace. CoreDNS resuelve automáticamente al crear el Service.

Networking yService Discovery

Networking y
Service Discovery