Pular para o conteúdo
~/.primo-academy.sh
☰ Aulas · Kubernetes · 0/12
Recomendado: essencial

Ingress: expondo o cluster pro mundo

2 min de leitura

fonte

Service do tipo LoadBalancer provisiona um LB externo (e custa caro em cloud). Pra ter vários apps no mesmo LB, com rotas diferentes e TLS centralizado, você usa Ingress.

O que Ingress faz

Ingress é um objeto k8s que diz: "para requisições com host app.exemplo.com e path /api, mande pro service api. Para host app.exemplo.com e path /, mande pro service frontend."

Fluxo: navegador -> DNS -> Load Balancer -> Ingress -> Service -> Pod.

Pontos do diagrama:

  • DNS aponta pro LB do ingress controller (não pros Pods).
  • Ingress Controller (nginx, Traefik, HAProxy) é o pod que recebe as requisições e aplica as regras. O objeto Ingress é só a configuração.
  • Regras por host e path - roteamento baseado em URL.
  • Service interno (ClusterIP) recebe o tráfego do controller.

Manifesto

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.exemplo.com
      secretName: app-tls     # Secret com cert + key
  rules:
    - host: app.exemplo.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80

Aplique:

kubectl apply -f ingress.yaml
kubectl get ingress
kubectl describe ingress app

Ingress Controller (a parte que falta)

O objeto Ingress sozinho não faz nada. Você precisa de um Ingress Controller rodando no cluster (geralmente como Deployment próprio). Os mais comuns:

  • nginx-ingress - o padrão da indústria, mantido pela comunidade Kubernetes.
  • Traefik - configuração via labels, bom pra múltiplos ambientes.
  • HAProxy - performático, configuração complexa.
  • Contour - baseado em Envoy.
  • Em cloud gerenciado (EKS, GKE, AKS), o provedor oferece o controller como add-on.

Em minikube:

minikube addons enable ingress
kubectl get pods -n ingress-nginx    # controller rodando

TLS / HTTPS

Ingress suporta TLS nativo: você cria um Secret com o certificado

  • chave privada, e o controller serve HTTPS na porta 443.
# Com cert-manager (geralmente já instalado em cluster moderno)
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-tls
spec:
  secretName: app-tls
  dnsNames:
    - app.exemplo.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
EOF

cert-manager é um controller que fala com a Let's Encrypt e renova o certificado automaticamente. Sem ele, você geraria o cert manualmente (ou usaria um serviço pago).

Três conceitos que você acabou de aprender:

  • Ingress = objeto de configuração. Sem Ingress Controller rodando, ele é só YAML.
  • Regras por host + path permitem múltiplos apps no mesmo LB
    • muito mais barato que um LoadBalancer por app.
  • TLS via Secret - coloca o cert no cluster e o controller serve HTTPS. Com cert-manager, renovação é automática.

Dica: em produção real, não exponha apps sem Ingress. A alternativa (LoadBalancer por app) custa caro e cada LB é mais um ponto de gestão. Ingress é a forma idiomática.

No próximo nó, vamos falar de probes, HPA e resource limits - o que faz o cluster se auto-cuidar.

// recursos

// avaliação da trilha

—
ainda sem avaliações