Proxy no Kubernetes

Proxies no Kubernetes para Pods e Services são configurados principalmente por variáveis de ambiente no tráfego de saída (egress), por containers sidecar para controle granular e integração com service mesh, e por recursos Ingress ou tipos de Service para o gerenciamento do tráfego de entrada (ingress). Este artigo detalha os mecanismos para implementar configurações de proxy dentro de um ambiente Kubernetes.

Configuração de proxy de egress para Pods

Pods frequentemente precisam de um proxy de egress para acessar redes externas, aplicar políticas de segurança ou gerenciar o roteamento de tráfego para fora do cluster.

Variáveis de ambiente

O método mais direto para configurar um proxy de egress para aplicações dentro de um Pod é usar as variáveis de ambiente padrão de proxy HTTP/HTTPS. Muitas aplicações e bibliotecas cliente respeitam essas variáveis automaticamente.

• HTTP_PROXY: define um servidor proxy para requisições HTTP.
• HTTPS_PROXY: define um servidor proxy para requisições HTTPS.
• NO_PROXY: uma lista separada por vírgulas de hostnames, domínios ou endereços IP que devem ignorar o proxy. Isso é essencial para a comunicação interna do cluster (por exemplo, kubernetes.default.svc, 10.0.0.0/8, *.svc.cluster.local).

Essas variáveis são definidas na especificação do container do 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" # Exemplo: ajuste para o CIDR do seu cluster

Init Containers para configuração dinâmica de proxy

Em cenários mais complexos, um Init Container pode preparar as configurações de proxy ou injetar certificados antes que o container principal da aplicação inicie. Isso é útil para:

• Buscar detalhes do proxy em um serviço de configuração.
• Gerar listas NO_PROXY com base nas faixas de IP internas do cluster.
• Injetar certificados CA personalizados exigidos pelo proxy.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-init-proxy
spec:
  initContainers:
  - name: init-proxy-config
    image: alpine/git # Exemplo: uma imagem simples para buscar a configuração
    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"] # Carrega a configuração
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  volumes:
  - name: proxy-config-volume
    emptyDir: {}

Proxies sidecar para egress

Um proxy sidecar roda no mesmo Pod que o container da aplicação. Ele intercepta todo o tráfego de saída do container da aplicação e o roteia através do proxy. Esse padrão oferece:

• Transparência de rede: o container da aplicação não precisa conhecer o proxy; o sidecar cuida da lógica de proxy.
• Política centralizada: políticas de egress (por exemplo, listas de permissão/bloqueio, rate limiting, autenticação) podem ser aplicadas no nível do sidecar, independentemente da aplicação.
• Observabilidade: o sidecar pode emitir métricas, logs e traces de todo o tráfego de saída.

Proxies sidecar comuns incluem o Envoy (usado pelo Istio) ou o proxy do Linkerd.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-sidecar-egress
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    # O tráfego da aplicação é redirecionado para o sidecar por regras de iptables
  - name: egress-proxy-sidecar
    image: envoyproxy/envoy:v1.28.0 # Exemplo de imagem do Envoy
    ports:
    - containerPort: 15001 # Porta para a qual a aplicação envia o tráfego
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
    # Configuração do Envoy para encaminhar o tráfego a um proxy externo ou diretamente
    # (normalmente gerenciada pelo control plane do service mesh)
  volumes:
  - name: envoy-config
    configMap:
      name: egress-envoy-config

Configuração de proxy de ingress para Services

Para o tráfego de entrada em Services, o Kubernetes oferece vários mecanismos que envolvem proxy por natureza.

Kubernetes Services (kube-proxy)

O componente kube-proxy, executado em cada nó, cuida do IP virtual (VIP) dos Services do Kubernetes. Quando um cliente dentro ou fora do cluster tenta se conectar ao ClusterIP de um Service, o kube-proxy intercepta o tráfego e o encaminha para um dos Pods que compõem esse Service. Ele atua como um proxy e balanceador de carga de camada 4 (TCP/UDP).

• Modo: o kube-proxy opera em modo iptables (padrão) ou ipvs.
  • iptables: usa regras iptables para fazer NAT e balanceamento de carga.
  • ipvs: usa o IP Virtual Server (IPVS) para algoritmos de balanceamento mais sofisticados e melhor desempenho com um grande número de services.

Esse proxy é automático e não exige nenhuma configuração explícita em Pods ou Services além da própria definição do Service.

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

Recursos Ingress e Ingress Controllers

Para acesso externo HTTP/HTTPS a Services, usa-se um recurso Ingress em conjunto com um Ingress Controller. O próprio Ingress Controller é um proxy especializado que roda dentro do cluster.

• Ingress Controller: um Pod (ou conjunto de Pods) executando um proxy como NGINX, HAProxy, Traefik, ou um controller de AWS ALB/GCE L7 Load Balancer. Ele observa os recursos Ingress e configura suas regras de proxy dinamicamente.
• Recurso Ingress: define regras para rotear o tráfego HTTP/HTTPS externo para Services. Isso inclui roteamento por host, roteamento por path e terminação 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: terminação TLS no Ingress Controller
  - hosts:
    - api.example.com
    secretName: my-tls-secret

Services do tipo LoadBalancer

Quando um Service do tipo LoadBalancer é criado, ele provisiona um load balancer externo (normalmente do provedor de nuvem). Esse load balancer externo atua como um proxy, encaminhando o tráfego para os NodePorts do Service, que o kube-proxy então roteia para os Pods correspondentes.

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer # Proxy externo pelo LB do provedor de nuvem

Proxies sidecar para ingress (Service Mesh)

Em um service mesh (por exemplo, Istio, Linkerd), proxies sidecar são injetados nos Pods para lidar com o tráfego de entrada e de saída do container da aplicação. No ingress, o sidecar intercepta o tráfego que chega à aplicação e aplica as políticas do mesh (por exemplo, autenticação, autorização, traffic shifting, retries, circuit breaking) antes de encaminhá-lo ao container da aplicação.

Isso oferece:

• Aplicação de políticas: controle detalhado sobre como os serviços se comunicam.
• Observabilidade: métricas, logs e tracing distribuído automáticos para toda a comunicação entre serviços.
• Gerenciamento de tráfego: capacidades avançadas de roteamento (por exemplo, deploys canário, testes A/B).
• Segurança: TLS mútuo (mTLS) entre serviços.

A injeção e a configuração do sidecar normalmente são automatizadas pelo control plane do service mesh.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-mesh-sidecar
  labels:
    app: my-app
    # Exemplo para o Istio: dispara a injeção automática do sidecar
    istio-injection: enabled
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    ports:
    - containerPort: 8080
  # O control plane do Istio adiciona automaticamente um container sidecar 'istio-proxy'
  # e configura regras de iptables para redirecionar o tráfego.

Comparação das abordagens de proxy

Considerações práticas

Gerenciamento de certificados

Proxies frequentemente terminam ou originam conexões TLS.

• Ingress Controllers: normalmente gerenciam certificados TLS via Secrets do Kubernetes, permitindo a terminação TLS na borda do cluster.
• Proxies sidecar: em um service mesh, os sidecars cuidam do mTLS automaticamente, muitas vezes usando certificados de curta duração emitidos pela autoridade certificadora do mesh. Para egress, podem precisar confiar em CAs personalizadas para inspecionar tráfego criptografado ou se conectar a serviços internos.

Desempenho e overhead

Cada proxy adiciona um salto extra no caminho de rede, o que pode aumentar a latência.

• kube-proxy: altamente otimizado. O modo ipvs oferece melhor desempenho com um grande número de services.
• Sidecars: introduzem overhead de CPU, memória e rede por Pod. Esse overhead é um ponto de projeto em implantações de service mesh.
• Ingress Controllers: podem se tornar um gargalo se não forem escalados adequadamente para altos volumes de tráfego.

Observabilidade

Proxies fornecem um ponto centralizado para coletar telemetria.

• Logs: proxies podem registrar detalhes de conexão, headers de requisição/resposta e erros.
• Métricas: métricas padrão como taxas de requisição, latências e taxas de erro podem ser coletadas.
• Tracing: proxies sidecar em um service mesh permitem tracing distribuído sem alterar o código da aplicação.

Segurança

Proxies são pontos críticos de aplicação de políticas de segurança.

• Controle de acesso: proxies podem aplicar políticas de autenticação e autorização para o tráfego de entrada e de saída.
• Segmentação de rede: proxies podem isolar o tráfego da aplicação, impedindo conexões diretas entre serviços que não deveriam se comunicar.
• Proteção contra DDoS: proxies externos (como Ingress Controllers ou LBs de nuvem) podem oferecer recursos de mitigação de DDoS.