Proxy en Kubernetes

Los proxies en Kubernetes para Pods y Services se configuran principalmente a través de variables de entorno para el tráfico de salida, contenedores sidecar para un control granular y la integración de la malla de servicios, y recursos Ingress o tipos de Service para la gestión del tráfico de entrada. Este artículo detalla los mecanismos para implementar configuraciones de proxy dentro de un entorno de Kubernetes.

Configuración de Proxy de Salida para Pods

Los Pods a menudo requieren un proxy de salida para acceder a redes externas, aplicar políticas de seguridad o gestionar el enrutamiento del tráfico fuera del clúster.

Variables de Entorno

El método más sencillo para configurar un proxy de salida para aplicaciones dentro de un Pod es a través de las variables de entorno estándar de proxy HTTP/HTTPS. Muchas aplicaciones y bibliotecas cliente respetan automáticamente estas variables.

• HTTP_PROXY: Especifica un servidor proxy para solicitudes HTTP.
• HTTPS_PROXY: Especifica un servidor proxy para solicitudes HTTPS.
• NO_PROXY: Una lista separada por comas de nombres de host, dominios o direcciones IP que deben omitir el proxy. Esto es crucial para la comunicación interna del clúster (por ejemplo, kubernetes.default.svc, 10.0.0.0/8, *.svc.cluster.local).

Estas variables se definen en la especificación del contenedor del Pod.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-proxy
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    env:
    - name: HTTP_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: HTTPS_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,.svc,.cluster.local,10.0.0.0/8" # Ejemplo: ajustar para el CIDR de tu clúster

Contenedores Init para Configuración Dinámica de Proxy

Para escenarios más complejos, un Contenedor Init puede preparar configuraciones de proxy o inyectar certificados antes de que se inicie el contenedor principal de la aplicación. Esto es útil para:

• Obtener detalles del proxy de un servicio de configuración.
• Generar listas NO_PROXY basadas en rangos de IP internos del clúster.
• Inyectar certificados CA personalizados requeridos por el proxy.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-init-proxy
spec:
  initContainers:
  - name: init-proxy-config
    image: alpine/git # Ejemplo: Una imagen simple para obtener la configuración
    command: ["sh", "-c", "echo 'HTTP_PROXY=http://dynamic-proxy:3128' > /mnt/proxy/config"]
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  containers:
  - name: my-app
    image: my-application-image:latest
    command: ["sh", "-c", ". /mnt/proxy/config && exec my-app-binary"] # Obtener configuración
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  volumes:
  - name: proxy-config-volume
    emptyDir: {}

Proxies Sidecar para Salida

Un proxy sidecar se ejecuta en el mismo Pod que el contenedor de la aplicación. Intercepta todo el tráfico saliente del contenedor de la aplicación, enrutándolo a través del proxy. Este patrón proporciona:

• Transparencia de Red: El contenedor de la aplicación no necesita ser consciente del proxy; el sidecar maneja la lógica del proxy.
• Política Centralizada: Las políticas de salida (por ejemplo, listas de permitidos/denegados, limitación de velocidad, autenticación) se pueden aplicar a nivel del sidecar, independientemente de la aplicación.
• Observabilidad: El sidecar puede emitir métricas, registros y trazas para todo el tráfico de salida.

Los proxies sidecar comunes incluyen Envoy (utilizado por Istio) o el proxy de Linkerd.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-sidecar-egress
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    # El tráfico de la aplicación se redirige al sidecar a través de reglas de iptables
  - name: egress-proxy-sidecar
    image: envoyproxy/envoy:v1.28.0 # Ejemplo de imagen de Envoy
    ports:
    - containerPort: 15001 # Puerto para que la aplicación envíe tráfico
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
    # Configuración para que Envoy reenvíe el tráfico a un proxy externo o directamente
    # (típicamente gestionado por un plano de control de malla de servicios)
  volumes:
  - name: envoy-config
    configMap:
      name: egress-envoy-config

Configuración de Proxy de Entrada para Servicios

Para el tráfico entrante a los Services, Kubernetes ofrece varios mecanismos que inherentemente implican el uso de proxies.

Servicios de Kubernetes (kube-proxy)

El componente kube-proxy que se ejecuta en cada nodo maneja la IP virtual (VIP) para los Services de Kubernetes. Cuando un cliente dentro o fuera del clúster intenta conectarse a la ClusterIP de un Service, kube-proxy intercepta el tráfico y lo reenvía a uno de los Pods que respaldan ese Service. Esto actúa como un proxy y balanceador de carga de Capa 4 (TCP/UDP).

• Modo: kube-proxy opera en modo iptables (predeterminado) o ipvs.
  • iptables: Utiliza reglas iptables para realizar NAT y balanceo de carga.
  • ipvs: Utiliza IP Virtual Server (IPVS) para algoritmos de balanceo de carga más sofisticados y un mejor rendimiento para un gran número de servicios.

Este proxying es automático y no requiere configuración explícita dentro de los Pods o Services más allá de la definición del propio Service.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP # Proxying interno por kube-proxy

Recursos Ingress y Controladores Ingress

Para el acceso externo HTTP/HTTPS a los Services, se utiliza un recurso Ingress junto con un Controlador Ingress. El propio Controlador Ingress es un proxy especializado que se ejecuta dentro del clúster.

• Controlador Ingress: Un Pod (o conjunto de Pods) que ejecuta un proxy como NGINX, HAProxy, Traefik, o un controlador de balanceador de carga L7 de AWS ALB/GCE. Observa los recursos Ingress y configura sus reglas de proxy dinámicamente.
• Recurso Ingress: Define reglas para enrutar el tráfico HTTP/HTTPS externo a los Services. Esto incluye enrutamiento basado en host, enrutamiento basado en ruta y terminación TLS.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80
  tls: # Opcional: terminación TLS en el Controlador Ingress
  - hosts:
    - api.example.com
    secretName: my-tls-secret

Servicios LoadBalancer

Cuando se crea un Service de tipo LoadBalancer, este aprovisiona un balanceador de carga externo (típicamente del proveedor de la nube). Este balanceador de carga externo actúa como un proxy, reenviando el tráfico a los NodePorts del Service, que kube-proxy luego enruta a los Pods de respaldo.

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer # Proxying externo por el LB del proveedor de la nube

Proxies Sidecar para Entrada (Malla de Servicios)

En una malla de servicios (por ejemplo, Istio, Linkerd), se inyectan proxies sidecar en los Pods para manejar tanto el tráfico de entrada como el de salida para el contenedor de la aplicación. Para la entrada, el sidecar intercepta el tráfico entrante a la aplicación y aplica políticas de malla (por ejemplo, autenticación, autorización, cambio de tráfico, reintentos, interrupción de circuito) antes de reenviarlo al contenedor de la aplicación.

Esto proporciona:

• Aplicación de Políticas: Control granular sobre cómo se comunican los servicios.
• Observabilidad: Métricas, registros y trazado distribuido automáticos para toda la comunicación de servicio a servicio.
• Gestión de Tráfico: Capacidades avanzadas de enrutamiento (por ejemplo, despliegues canary, pruebas A/B).
• Seguridad: TLS mutuo (mTLS) entre servicios.

La inyección y configuración del sidecar son típicamente automatizadas por el plano de control de la malla de servicios.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-mesh-sidecar
  labels:
    app: my-app
    # Ejemplo para Istio: activa la inyección automática del sidecar
    istio-injection: enabled
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    ports:
    - containerPort: 8080
  # El plano de control de Istio añade automáticamente un contenedor sidecar 'istio-proxy'
  # y configura reglas de iptables para redirigir el tráfico.

Comparación de Enfoques de Proxy

Consideraciones Prácticas

Gestión de Certificados

Los proxies a menudo terminan u originan conexiones TLS.

• Controladores Ingress: Típicamente gestionan certificados TLS a través de Secrets de Kubernetes, permitiendo la terminación TLS en el borde del clúster.
• Proxies Sidecar: En una malla de servicios, los sidecars manejan mTLS automáticamente, a menudo utilizando certificados de corta duración emitidos por la autoridad de certificación de la malla. Para la salida, podrían necesitar confiar en CAs personalizadas para inspeccionar el tráfico cifrado o conectarse a servicios internos.

Rendimiento y Sobrecarga

Cada proxy introduce un salto adicional en la ruta de red, lo que puede añadir latencia.

• kube-proxy: Altamente optimizado. El modo ipvs ofrece un mejor rendimiento para un gran número de servicios.
• Sidecars: Introducen sobrecarga de CPU, memoria y red por Pod. Esta sobrecarga es una consideración de diseño para las implementaciones de malla de servicios.
• Controladores Ingress: Pueden ser un cuello de botella si no se escalan adecuadamente para volúmenes de tráfico altos.

Observabilidad

Los proxies proporcionan un punto centralizado para la recopilación de telemetría.

• Registros: Los proxies pueden registrar detalles de conexión, encabezados de solicitud/respuesta y errores.
• Métricas: Se pueden recopilar métricas estándar como tasas de solicitud, latencias, tasas de error.
• Trazado: Los proxies sidecar en una malla de servicios permiten el trazado distribuido sin cambios en el código de la aplicación.

Seguridad

Los proxies son puntos de aplicación críticos para las políticas de seguridad.

• Control de Acceso: Los proxies pueden aplicar políticas de autenticación y autorización para el tráfico entrante y saliente.
• Segmentación de Red: Los proxies pueden aislar el tráfico de la aplicación, evitando conexiones directas entre servicios que no deberían comunicarse.
• Protección DDoS: Los proxies externos (como los Controladores Ingress o los LBs en la nube) pueden ofrecer capacidades de mitigación de DDoS.