Ir para o conteúdo principal

Ingress.yml

Descrição: este arquivo cria um Ingress no Kubernetes.

Um Ingress é usado para definir regras de entrada HTTP/HTTPS para serviços dentro do cluster.

Ele permite publicar aplicações por hostname e caminho, apontando o tráfego para um Service existente. O Ingress não executa aplicação, não cria Pods e não substitui o Service. Ele define regras de roteamento que precisam ser atendidas por um Ingress Controller instalado no cluster.

No arquivo de referência do cluster, o recurso aparece como:

Recurso: ingresses.networking.k8s.io
Grupo/API: networking.k8s.io
Tipo: Ingress
Versão: v1

GRUPO:      networking.k8s.io
TIPO:       Ingress
VERSÃO:    v1

DESCRIÇÃO:
    Ingress é uma coleção de regras que permite que conexões de entrada alcancem os
    endpoints definidos por um backend. Um Ingress pode ser configurado para fornecer URLs
    acessíveis externamente para serviços, balancear tráfego, terminar SSL, oferecer
    hospedagem virtual baseada em nome etc.

Quando usar Ingress

Use Ingress quando a aplicação:

  • precisa ser publicada por domínio HTTP/HTTPS;
  • precisa ser acessada externamente por navegador ou cliente HTTP;
  • precisa de roteamento por hostname;
  • precisa de roteamento por caminho;
  • precisa apontar um domínio para um Service;
  • precisa compartilhar o mesmo IP de entrada com várias aplicações;
  • precisa usar TLS/HTTPS com certificado armazenado em Secret;
  • precisa de hospedagem virtual baseada em nome;
  • precisa centralizar regras de entrada web no cluster;
  • já possui um Service expondo os Pods internamente.

Exemplos comuns:

  • publicar um portal institucional;
  • publicar uma API;
  • publicar um frontend;
  • publicar um painel interno;
  • publicar aplicação de laboratório;
  • publicar ambiente de homologação;
  • publicar aplicação de disciplina;
  • publicar sistema administrativo;
  • rotear /api para um Service e / para outro;
  • usar app.exemplo.local apontando para um Service interno.

Quando Ingress não é o recurso indicado

Ingress não é o melhor recurso quando o problema exige outro tipo de controle.

Necessidade Recurso mais indicado Motivo
Executar aplicação e controlar réplicas Deployment Ingress não cria Pods; ele apenas define regras de entrada.
Criar endereço interno estável para Pods Service Ingress aponta para Service, não diretamente para Pods.
Expor protocolo que não é HTTP/HTTPS Service do tipo NodePort ou LoadBalancer, ou solução específica do controlador Ingress é voltado a tráfego HTTP/HTTPS.
Criar política de isolamento de rede NetworkPolicy Ingress não controla isolamento entre Pods ou namespaces.
Guardar certificado TLS Secret Ingress apenas referencia o Secret em spec.tls.secretName.
Guardar configuração da aplicação ConfigMap Ingress não armazena configuração de aplicação.
Guardar senha/token Secret Ingress não é cofre de credenciais.
Controlar CPU/memória ResourceQuota, LimitRange ou resources Ingress não controla consumo de recursos da aplicação.
Criar balanceador TCP/UDP genérico Service ou recurso específico do controlador Ingress trabalha com regras HTTP/HTTPS.
Fazer roteamento avançado moderno, com papéis separados e mais extensibilidade Gateway API Gateway API foi criada para cenários mais avançados de roteamento.
Autenticação de usuário da aplicação Aplicação, proxy de autenticação, Gateway, Ingress Controller com recurso específico ou solução OIDC Ingress nativo não define login de usuário.

Uso em cenário de universidade

Em uma universidade, um Ingress pode ser usado para publicar aplicações acadêmicas, administrativas, laboratoriais e de pesquisa sem criar uma VM ou IP exclusivo para cada sistema.

Exemplos:

  • publicar um sistema web de setor administrativo;
  • publicar uma API de projeto de pesquisa;
  • publicar ambiente de homologação de uma equipe;
  • publicar aplicação de disciplina;
  • publicar painel de laboratório;
  • publicar frontend de um projeto;
  • publicar múltiplos sistemas usando o mesmo controlador de entrada;
  • usar domínios diferentes para ambientes diferentes;
  • usar TLS para aplicações web institucionais;
  • centralizar entrada HTTP/HTTPS em um Ingress Controller gerenciado.

Uso recomendado em ambiente universitário:

  • um Namespace por projeto, sistema, disciplina, laboratório ou ambiente;
  • um Deployment para executar a aplicação;
  • um Service para expor os Pods internamente;
  • um Ingress para publicar o Service por domínio HTTP/HTTPS;
  • um Secret TLS quando o Ingress usar HTTPS;
  • ResourceQuota e LimitRange para controlar uso de CPU/memória;
  • NetworkPolicy para isolar projetos diferentes;
  • ServiceAccount, Role e RoleBinding para permissões mínimas;
  • GitLab, Argo CD ou outro GitOps/CI para aplicar os manifestos;
  • ingressClassName definido quando houver mais de um Ingress Controller;
  • regras de hostname claras e padronizadas por projeto ou ambiente.

Exemplo completo: ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress

metadata:
  name: minha-aplicacao
  namespace: meu-projeto
  labels:
    app: minha-aplicacao
    ambiente: homologacao
    componente: entrada-web
  annotations:
    descricao: "Ingress exemplo para publicar aplicação HTTP/HTTPS"

spec:
  ingressClassName: nginx

  tls:
    - hosts:
        - minha-aplicacao.exemplo.local
      secretName: minha-aplicacao-tls

  rules:
    - host: minha-aplicacao.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: minha-aplicacao
                port:
                  number: 80

Explicação linha por linha

apiVersion: networking.k8s.io/v1

Define a versão da API usada pelo manifesto.

Para Ingress, normalmente é:

apiVersion: networking.k8s.io/v1

Significado:

  • networking.k8s.io: grupo da API Kubernetes onde fica o Ingress;
  • v1: versão estável da API.

Use exatamente networking.k8s.io/v1 para Ingress moderno.

kind: Ingress

Define o tipo de recurso que será criado.

kind: Ingress

Significado:

  • Ingress: recurso que define regras de entrada HTTP/HTTPS para Services.

Não confundir com:

  • Service: cria acesso estável aos Pods;
  • Deployment: cria e atualiza Pods;
  • IngressClass: define a classe/controlador de Ingress;
  • Secret: armazena certificado TLS;
  • Gateway: recurso da Gateway API para roteamento mais avançado.

metadata

metadata identifica e organiza o Ingress.

metadata:
  name: minha-aplicacao
  namespace: meu-projeto
  labels:
    app: minha-aplicacao
  annotations:
    descricao: "Ingress exemplo"

metadata.name

Nome do Ingress.

name: minha-aplicacao

Uso:

  • identifica o recurso dentro do namespace;
  • aparece em kubectl get ingress;
  • deve ser único dentro do namespace.

Exemplos bons:

name: portal-academico
name: api-pesquisa
name: backend-laboratorio

Regras práticas:

  • use letras minúsculas;
  • use hífen;
  • evite acentos;
  • evite espaços;
  • escolha nome curto e claro.

metadata.namespace

Namespace onde o Ingress será criado.

namespace: meu-projeto

Uso:

  • separa aplicações;
  • evita mistura entre projetos;
  • mantém o Ingress junto do Service que ele publica;
  • ajuda em RBAC, quotas, isolamento e organização.

Regra importante:

  • o backend service.name referenciado pelo Ingress deve estar no mesmo namespace do Ingress.

Se omitir:

  • Kubernetes usa o namespace atual do contexto;
  • em produção isso pode causar Ingress no namespace errado.

Recomendação:

  • sempre declarar namespace.

metadata.labels

Labels são pares chave/valor usados para organização e filtros.

labels:
  app: minha-aplicacao
  ambiente: homologacao
  componente: entrada-web

Uso:

  • filtrar Ingresses com kubectl;
  • organizar recursos;
  • permitir automações;
  • associar recursos ao mesmo sistema;
  • ajudar ferramentas de observabilidade e GitOps.

Exemplo:

kubectl get ingress -l app=minha-aplicacao

Boas labels:

app: minha-aplicacao
ambiente: producao
componente: entrada-web

Evite usar label com dado sensível.

metadata.annotations

Annotations são metadados livres.

annotations:
  descricao: "Ingress da aplicação"

Uso:

  • documentação;
  • configuração de ferramentas;
  • configuração de controladores;
  • integração com Ingress Controller.

Cuidado:

  • muitas configurações avançadas de Ingress são específicas do controlador;
  • uma annotation aceita por um controlador pode não funcionar em outro;
  • consulte a documentação do Ingress Controller usado no cluster antes de adicionar annotations específicas.

Diferença entre labels e annotations:

Campo Uso
labels seleção, filtro e organização
annotations informação extra e configuração de ferramentas

Campos de metadata normalmente gerenciados pelo Kubernetes

O kubectl explain mostra vários campos de metadata, mas muitos são preenchidos pelo próprio cluster.

Normalmente você não escreve manualmente:

creationTimestamp:
deletionTimestamp:
resourceVersion:
uid:
generation:
managedFields:
selfLink:

Eles servem para controle interno do Kubernetes.

spec

spec descreve o estado desejado do Ingress.

spec:
  ingressClassName: nginx
  rules:
    - host: minha-aplicacao.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: minha-aplicacao
                port:
                  number: 80

Campos principais:

spec:
  defaultBackend
  ingressClassName
  rules
  tls

spec.ingressClassName

Define qual classe de Ingress deve processar este recurso.

ingressClassName: nginx

Uso:

  • escolher o Ingress Controller;
  • evitar ambiguidade quando há mais de um controlador;
  • substituir o método antigo baseado em annotation.

Exemplos possíveis, dependendo do cluster:

ingressClassName: nginx
ingressClassName: traefik
ingressClassName: haproxy

Cuidado:

  • o valor precisa corresponder a uma IngressClass existente no cluster;
  • o nome correto depende da instalação do Ingress Controller.

Verificar classes disponíveis:

kubectl get ingressclass

spec.rules

Lista regras de roteamento do Ingress.

rules:
  - host: minha-aplicacao.exemplo.local
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: minha-aplicacao
              port:
                number: 80

Cada regra pode definir:

  • host;
  • regras HTTP;
  • caminhos;
  • backend de destino.

spec.rules[].host

Define o hostname atendido por aquela regra.

host: minha-aplicacao.exemplo.local

Uso:

  • publicar aplicação por domínio;
  • separar aplicações por hostname;
  • permitir hospedagem virtual baseada em nome.

Exemplos:

host: portal.exemplo.local
host: api.exemplo.local
host: laboratorio.exemplo.local

Cuidado:

  • o DNS precisa apontar o hostname para o endereço do Ingress Controller;
  • o host deve ser compatível com o certificado TLS se HTTPS for usado.

spec.rules[].http

Define regras HTTP para o host.

http:
  paths:
    - path: /
      pathType: Prefix
      backend:
        service:
          name: minha-aplicacao
          port:
            number: 80

Uso:

  • encaminhar caminhos HTTP para backends;
  • permitir vários caminhos no mesmo host;
  • publicar uma ou mais aplicações sob o mesmo domínio.

spec.rules[].http.paths

Lista caminhos HTTP.

paths:
  - path: /
    pathType: Prefix
    backend:
      service:
        name: minha-aplicacao
        port:
          number: 80

Este campo é obrigatório dentro de http.

Um host pode ter vários caminhos.

Exemplo:

paths:
  - path: /
    pathType: Prefix
    backend:
      service:
        name: frontend
        port:
          number: 80
  - path: /api
    pathType: Prefix
    backend:
      service:
        name: backend
        port:
          number: 80

spec.rules[].http.paths[].path

Define o caminho HTTP.

path: /

Exemplos:

path: /
path: /api
path: /admin
path: /sistema

Uso:

  • /: raiz do site;
  • /api: API;
  • /admin: área administrativa;
  • /sistema: aplicação em subcaminho.

Cuidado:

  • aplicações em subcaminho podem precisar estar preparadas para rodar nesse path;
  • rewrite de caminho costuma depender de recurso específico do Ingress Controller.

spec.rules[].http.paths[].pathType

Define como o campo path será interpretado.

pathType: Prefix

Este campo é obrigatório.

Valores aceitos:

pathType: Exact
pathType: Prefix
pathType: ImplementationSpecific

Exact

Casa o caminho exatamente.

path: /api
pathType: Exact

Exemplo:

/api      casa
/api/     não casa da mesma forma
/api/v1   não casa

Use quando:

  • o caminho precisa ser exatamente aquele;
  • não quer pegar subcaminhos.

Prefix

Casa por prefixo de caminho.

path: /api
pathType: Prefix

Exemplo:

/api       casa
/api/      casa
/api/v1    casa
/apix      não deve ser tratado como mesmo segmento

Use quando:

  • quer rotear uma árvore de caminhos;
  • quer que /api, /api/ e /api/v1 sigam para o mesmo backend.

É o tipo mais comum para aplicações web.

ImplementationSpecific

A interpretação depende do Ingress Controller.

pathType: ImplementationSpecific

Uso:

  • compatibilidade com comportamento específico do controlador;
  • cenários em que o controlador define sua própria regra.

Cuidado:

  • pode mudar entre controladores;
  • reduz portabilidade do manifesto;
  • evite em tutorial básico ou ambiente padronizado, salvo necessidade real.

spec.rules[].http.paths[].backend

Define para onde o tráfego será enviado.

backend:
  service:
    name: minha-aplicacao
    port:
      number: 80

O backend pode apontar para:

service
resource

O uso mais comum é service.

backend.service.name

Nome do Service que receberá o tráfego.

name: minha-aplicacao

Regra importante:

  • o Service precisa existir no mesmo namespace do Ingress;
  • o Service precisa ter endpoints funcionais;
  • o Service precisa expor a porta indicada.

Verificar Service:

kubectl get service minha-aplicacao -n meu-projeto

Verificar endpoints:

kubectl get endpoints minha-aplicacao -n meu-projeto

backend.service.port.number

Porta numérica do Service.

port:
  number: 80

Uso:

  • aponta para spec.ports[].port do Service;
  • não aponta diretamente para targetPort do container.

Exemplo:

# Service
ports:
  - port: 80
    targetPort: 8080

# Ingress
backend:
  service:
    name: minha-aplicacao
    port:
      number: 80

backend.service.port.name

Nome da porta do Service.

port:
  name: http

Uso:

  • quando o Service nomeia a porta;
  • ajuda quando há múltiplas portas.

Exemplo:

# Service
ports:
  - name: http
    port: 80
    targetPort: 8080

# Ingress
backend:
  service:
    name: minha-aplicacao
    port:
      name: http

backend.resource

Permite apontar o backend para outro recurso local tipado.

backend:
  resource:
    apiGroup: exemplo.io
    kind: StorageBucket
    name: arquivos

Campos:

Campo Função
apiGroup grupo da API do recurso
kind tipo do recurso
name nome do recurso

Uso:

  • cenários específicos;
  • integrações com controladores que suportam backend por recurso.

Cuidado:

  • não é o caso mais comum;
  • para aplicações web comuns, use backend.service.

spec.defaultBackend

Define backend padrão para requisições que não casam com nenhuma regra.

defaultBackend:
  service:
    name: pagina-padrao
    port:
      number: 80

Uso:

  • responder quando nenhum host ou path casa;
  • criar página padrão;
  • encaminhar tráfego não correspondido para um Service específico.

Cuidado:

  • se omitido, o comportamento para requisições não correspondidas depende do Ingress Controller;
  • o Service do defaultBackend precisa existir no mesmo namespace.

Exemplo completo:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: entrada-com-padrao
  namespace: meu-projeto
spec:
  ingressClassName: nginx
  defaultBackend:
    service:
      name: pagina-padrao
      port:
        number: 80

spec.tls

Configura TLS/HTTPS para hosts do Ingress.

tls:
  - hosts:
      - minha-aplicacao.exemplo.local
    secretName: minha-aplicacao-tls

Campos:

tls:
  hosts
  secretName

spec.tls[].hosts

Lista hostnames cobertos por aquela configuração TLS.

hosts:
  - minha-aplicacao.exemplo.local

Uso:

  • associar domínio ao certificado;
  • indicar quais hosts devem usar o Secret TLS.

Cuidado:

  • o certificado no Secret deve ser válido para os hosts listados;
  • o host em rules[].host normalmente deve estar presente em tls[].hosts.

spec.tls[].secretName

Nome do Secret com o certificado TLS.

secretName: minha-aplicacao-tls

O Secret deve estar no mesmo namespace do Ingress.

Formato comum do Secret TLS:

apiVersion: v1
kind: Secret
metadata:
  name: minha-aplicacao-tls
  namespace: meu-projeto
type: kubernetes.io/tls
data:
  tls.crt: BASE64_DO_CERTIFICADO
  tls.key: BASE64_DA_CHAVE

Cuidado:

  • não coloque chave privada diretamente em texto puro no repositório;
  • use ferramenta adequada para gerenciar Secrets;
  • cert-manager ou outra automação pode criar esse Secret, se existir no cluster.

status

status mostra o estado atual observado pelo Kubernetes e pelo Ingress Controller.

Você normalmente não escreve status no YAML.

O Kubernetes e os controladores preenchem automaticamente.

No arquivo de referência aparecem campos como:

status:
  loadBalancer

Use para diagnóstico:

kubectl get ingress minha-aplicacao -n meu-projeto
kubectl describe ingress minha-aplicacao -n meu-projeto
kubectl get ingress minha-aplicacao -n meu-projeto -o yaml

status.loadBalancer

Mostra o endereço de entrada atribuído pelo controlador, quando disponível.

loadBalancer:
  ingress:
    hostname
    ip
    ports

Uso:

  • verificar IP;
  • verificar hostname;
  • diagnosticar publicação externa;
  • confirmar se o Ingress Controller processou o recurso.

Exemplo de consulta:

kubectl get ingress minha-aplicacao -n meu-projeto

Manifesto mínimo funcional

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-exemplo
  namespace: meu-projeto
spec:
  ingressClassName: nginx
  rules:
    - host: nginx-exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-exemplo
                port:
                  number: 80

Aplicar:

kubectl apply -f ingress.yml

Verificar:

kubectl get ingress -n meu-projeto
kubectl describe ingress nginx-exemplo -n meu-projeto

Manifesto recomendado para aplicação web simples

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-web
  namespace: meu-projeto
  labels:
    app: app-web
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app-web.exemplo.local
      secretName: app-web-tls
  rules:
    - host: app-web.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-web
                port:
                  number: 80

Este modelo é adequado para uma aplicação web/API que já tem um Service do tipo ClusterIP.

Manifesto com múltiplos caminhos

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-com-api
  namespace: meu-projeto
spec:
  ingressClassName: nginx
  rules:
    - host: sistema.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend
                port:
                  number: 80

Uso:

  • / encaminha para o frontend;
  • /api encaminha para o backend.

Cuidado:

  • se a aplicação precisa remover ou reescrever o prefixo /api, isso depende de recurso específico do Ingress Controller.

Manifesto com múltiplos hosts

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multiplos-hosts
  namespace: meu-projeto
spec:
  ingressClassName: nginx
  rules:
    - host: app1.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1
                port:
                  number: 80
    - host: app2.exemplo.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app2
                port:
                  number: 80

Uso:

  • publicar aplicações diferentes por domínios diferentes;
  • usar o mesmo Ingress Controller para múltiplas aplicações;
  • organizar entrada web de um namespace.

Manifesto com defaultBackend

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: entrada-padrao
  namespace: meu-projeto
spec:
  ingressClassName: nginx
  defaultBackend:
    service:
      name: pagina-padrao
      port:
        number: 80

Uso:

  • responder quando nenhuma regra específica casa;
  • criar página padrão para aquele Ingress;
  • encaminhar tráfego não correspondido.

Comandos úteis

Aplicar

kubectl apply -f ingress.yml

Ver Ingresses

kubectl get ingress -n meu-projeto

Ver Ingress específico

kubectl get ingress minha-aplicacao -n meu-projeto

Ver detalhes

kubectl describe ingress minha-aplicacao -n meu-projeto

Ver YAML real aplicado

kubectl get ingress minha-aplicacao -n meu-projeto -o yaml

Ver IngressClasses disponíveis

kubectl get ingressclass

Ver Service usado pelo Ingress

kubectl get service minha-aplicacao -n meu-projeto

Ver endpoints do Service usado pelo Ingress

kubectl get endpoints minha-aplicacao -n meu-projeto

Testar DNS do host

dig +short minha-aplicacao.exemplo.local

Testar HTTP usando Host header

curl -v -H "Host: minha-aplicacao.exemplo.local" http://IP-DO-INGRESS/

Testar HTTPS ignorando validação temporariamente

curl -vk https://minha-aplicacao.exemplo.local/

Testar HTTPS com resolução manual

curl -vk --resolve minha-aplicacao.exemplo.local:443:IP-DO-INGRESS https://minha-aplicacao.exemplo.local/

Relação com outros manifestos

Um Ingress normalmente faz parte de um conjunto de manifestos.

Uso típico:

Namespace
  ├── ConfigMap
  ├── Secret
  ├── ServiceAccount
  ├── Deployment
  ├── Service
  ├── Ingress
  ├── NetworkPolicy
  ├── ResourceQuota
  └── LimitRange

Ingress + Service

Ingress aponta para Service.

Service aponta para Pods.

Ingress + Deployment

Deployment cria Pods.

Service expõe os Pods.

Ingress publica o Service por domínio HTTP/HTTPS.

Ingress + Secret TLS

Secret guarda certificado e chave TLS.

Ingress referencia o Secret em spec.tls.secretName.

Ingress + IngressClass

IngressClass define qual controlador deve processar o Ingress.

Ingress referencia essa classe em spec.ingressClassName.

Ingress + NetworkPolicy

Ingress publica a aplicação.

NetworkPolicy controla o tráfego permitido entre componentes.

Erros comuns

Criar Ingress sem Ingress Controller

Sintoma:

  • Ingress é criado;
  • mas nada responde externamente;
  • ADDRESS pode ficar vazio;
  • regras não são aplicadas.

Causa:

Ingress resource sozinho não tem efeito sem Ingress Controller.

Verificar:

kubectl get pods -A | grep -i ingress
kubectl get ingressclass

ingressClassName errado

Sintoma:

  • Ingress não é processado pelo controlador esperado;
  • ADDRESS fica vazio;
  • tráfego não chega.

Verificar classes disponíveis:

kubectl get ingressclass

Corrigir:

spec:
  ingressClassName: nome-correto

Service inexistente

Errado:

backend:
  service:
    name: app-web

Mas o Service não existe.

Verificar:

kubectl get service app-web -n meu-projeto

Porta do backend errada

Errado:

backend:
  service:
    name: app-web
    port:
      number: 8080

Mas o Service expõe:

ports:
  - port: 80
    targetPort: 8080

Correto:

backend:
  service:
    name: app-web
    port:
      number: 80

O Ingress aponta para a porta do Service, não para a porta do container.

Service sem endpoints

Sintoma:

  • Ingress existe;
  • Service existe;
  • mas aplicação não responde.

Verificar:

kubectl get endpoints app-web -n meu-projeto

Causa comum:

selector do Service não combina com labels dos Pods.

Host sem DNS apontando para o Ingress Controller

Sintoma:

  • Ingress está correto;
  • Service tem endpoints;
  • mas domínio não resolve ou resolve para IP errado.

Verificar:

dig +short app-web.exemplo.local
kubectl get ingress app-web -n meu-projeto

TLS com Secret ausente ou errado

Sintoma:

  • HTTPS falha;
  • certificado não corresponde ao domínio;
  • controlador mostra erro.

Verificar:

kubectl get secret app-web-tls -n meu-projeto
kubectl describe ingress app-web -n meu-projeto

O Secret TLS precisa estar no mesmo namespace do Ingress.

Usar path sem entender pathType

Errado usar ImplementationSpecific sem necessidade:

pathType: ImplementationSpecific

Prefira para caso comum:

pathType: Prefix

Use Exact quando o caminho precisa casar exatamente.

Esperar rewrite sem configurar controlador

O Ingress nativo define host, path e backend.

Reescrita de caminho, autenticação, CORS, headers e regras avançadas geralmente dependem do Ingress Controller e de sua documentação específica.

Checklist para uso em produção

Antes de aplicar um Ingress em ambiente compartilhado:

  • namespace definido;
  • name claro;
  • labels claras;
  • ingressClassName correto;
  • Ingress Controller instalado no cluster;
  • host definido corretamente;
  • DNS aponta para o endereço do Ingress Controller;
  • path correto;
  • pathType definido;
  • backend aponta para Service existente;
  • backend aponta para a porta do Service, não para a porta direta do container;
  • Service está no mesmo namespace do Ingress;
  • Service tem endpoints;
  • TLS configurado quando necessário;
  • Secret TLS existe no mesmo namespace;
  • certificado TLS cobre o hostname usado;
  • annotations específicas conferidas na documentação do controlador;
  • aplicação testada via HTTP/HTTPS;
  • exposição externa revisada com cuidado;
  • NetworkPolicy criada se houver necessidade de isolamento.

Resumo

Use Ingress para publicar aplicações HTTP/HTTPS no Kubernetes.

O Ingress controla:

  • hostname;
  • caminho HTTP;
  • backend de destino;
  • referência ao Service;
  • TLS por Secret;
  • backend padrão;
  • classe de Ingress usada pelo controlador.

Para aplicação web comum, o conjunto mínimo geralmente é:

Namespace + Deployment + Service + Ingress

Para ambiente institucional compartilhado, o conjunto recomendado é:

Namespace + ResourceQuota + LimitRange + ServiceAccount + Role/RoleBinding
+ ConfigMap + Secret + Deployment + Service + Ingress + NetworkPolicy + PDB

Nenhum comentário para exibir

Voltar ao topo