Ferramenta 06 · roda no seu navegador
Gerador de Deployment + Service + Ingress
Preencha poucos campos e saia com os três manifestos consistentes: os mesmos labels no seletor, porta nomeada, probes e TLS.
privacidadeRoda no seu navegador. Nada sai da sua máquina.
O que fica consistente
- Labels:
app.kubernetes.io/nameigual no seletor do Deployment, no template, no seletor do Service e nos metadados. Seletor que não bate com o template é recusado pela API; Service que não bate fica sem endpoints. - Porta: nomeada
httpno container e usada por nome no Service, nas probes e no backend do Ingress. - Probes: readiness e liveness no mesmo caminho; a readiness tira o pod do Service enquanto ele não responde (Readiness probe failed), a liveness reinicia o container (Liveness probe failed).
- Nomes: conferidos pela regra DNS-1123 (minúsculas, números e hífen, até 63 caracteres) da documentação do Kubernetes, "Object Names and IDs".
Para escolher requests e limits, use a calculadora de QoS.
Perguntas frequentes
Por que a porta tem nome?
O Service aponta para a porta pelo nome (targetPort: http), não pelo número. Se a aplicação mudar de porta, só o Deployment muda, e as probes também usam o nome.
Por que só limit de memória, e não de CPU?
Passar do limite de memória mata o container (OOMKilled); passar do de CPU só o desacelera (throttling). O gerador põe limit de memória igual ao request e deixa a CPU sem limit, uma escolha comum para evitar throttling; se o seu cluster exige limit de CPU por LimitRange ou política, acrescente.
Preciso do cert-manager?
Só para o TLS automático. Com o nome do ClusterIssuer preenchido, o Ingress ganha a anotação cert-manager.io/cluster-issuer e o certificado é emitido sozinho. Sem ele, o Secret NOME-tls precisa existir no namespace antes.
As probes vão funcionar de primeira?
Só se a aplicação responder 200 no caminho de saúde informado. Confira antes com kubectl port-forward e curl. Probe apontando para caminho que não existe é a causa mais comum de Liveness probe failed.