Publicar código em produção sem padronização costuma criar um problema conhecido pelas equipes de TI: cada atualização vira uma janela de risco. Entender como publicar aplicação em Kubernetes permite transformar esse processo em uma operação controlada, com réplicas, validações de saúde, reversão de versão e capacidade de crescer sem reprojetar toda a infraestrutura.
Kubernetes não elimina a necessidade de planejamento. Ele organiza a execução dos contêineres, distribui cargas e mantém o estado definido nos manifestos. Para obter disponibilidade e desempenho, a aplicação, a imagem de contêiner, a rede e os recursos do cluster precisam estar alinhados antes do primeiro deploy.
O que preparar antes de publicar no Kubernetes
A publicação começa fora do cluster. A equipe deve ter uma aplicação empacotada em uma imagem de contêiner, armazenada em um registry acessível pelo Kubernetes. Essa imagem precisa ser versionada de forma clara. Usar apenas a tag `latest` dificulta auditorias e torna o rollback impreciso. Prefira tags imutáveis, como a versão da aplicação ou o hash do commit gerado pelo pipeline.
Também é necessário confirmar que a aplicação funciona de acordo com o modelo de execução em contêiner. Ela deve registrar eventos em saída padrão, receber configurações por variáveis de ambiente ou arquivos montados e tratar corretamente sinais de encerramento. Quando um Pod é finalizado, o Kubernetes envia um sinal para que o processo encerre as conexões abertas. Aplicações que ignoram esse fluxo podem derrubar requisições durante uma atualização.
Outro ponto decisivo é o estado da aplicação. Serviços web e APIs normalmente devem ser stateless, mantendo sessões, arquivos e dados persistentes em serviços externos, bancos de dados ou volumes apropriados. Se um Pod for recriado, ele não pode depender de dados locais para continuar atendendo.
Como publicar aplicação em Kubernetes passo a passo
O caminho mais seguro é declarar a infraestrutura em arquivos YAML e aplicar essas definições de forma versionada. Isso torna o ambiente reproduzível, reduz alterações manuais e permite revisar cada mudança antes de ela chegar à produção.
Crie um namespace para separar o ambiente
Namespaces organizam recursos por aplicação, equipe ou estágio, como desenvolvimento, homologação e produção. Essa separação simplifica permissões, políticas de rede e controle de consumo.
“`yaml apiVersion: v1 kind: Namespace metadata: name: producao “`
Após criar o namespace, todos os comandos e manifestos da aplicação devem apontar para ele. Em ambientes corporativos, também vale limitar quais usuários e pipelines podem alterar recursos de produção por meio de RBAC. Acesso administrativo amplo acelera testes, mas aumenta o risco de mudanças acidentais em serviços críticos.
Defina o Deployment com recursos e réplicas
O Deployment informa qual imagem deve ser executada, quantas réplicas precisam permanecer ativas e como as atualizações serão feitas. É o recurso central para publicar uma API, site, painel administrativo ou serviço de processamento contínuo.
“`yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-pedidos namespace: producao spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 selector: matchLabels: app: api-pedidos template: metadata: labels: app: api-pedidos spec: containers:
- name: api
image: registry.exemplo.com/api-pedidos:1.4.2 ports:
- containerPort: 8080
resources: requests: cpu: “250m” memory: “256Mi” limits: cpu: “500m” memory: “512Mi” “`
Definir `requests` e `limits` evita dois extremos. Sem requests, o agendador não consegue reservar capacidade de forma previsível. Sem limits, uma aplicação com falha ou pico inesperado pode disputar CPU e memória com outros serviços do cluster. Os valores corretos dependem do comportamento real da carga, por isso métricas de consumo são mais confiáveis do que estimativas genéricas.
No exemplo, a estratégia mantém todas as réplicas disponíveis durante a atualização e cria um Pod adicional temporariamente. Esse modelo exige capacidade livre no cluster. Se a infraestrutura estiver dimensionada exatamente no limite, uma atualização rolling pode travar ou causar pressão de recursos.
Configure probes para evitar tráfego em Pods indisponíveis
Um processo em execução não significa que a aplicação está pronta para atender. Ela pode estar aguardando uma migração, conectando ao banco de dados ou carregando dependências. As probes permitem que o Kubernetes reconheça essas condições.
A `readinessProbe` impede o envio de tráfego para um Pod que ainda não está pronto. A `livenessProbe` reinicia o contêiner quando ele entra em um estado travado. Já a `startupProbe` é indicada para aplicações que levam mais tempo para iniciar, evitando reinicializações prematuras.
“`yaml readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /health/live port: 8080 initialDelaySeconds: 30 periodSeconds: 10 “`
Os endpoints de saúde devem validar apenas o necessário. Uma readiness pode verificar conectividade com dependências essenciais, mas uma liveness excessivamente ampla pode reiniciar a aplicação por uma falha temporária de terceiro. O objetivo é preservar a disponibilidade, não criar ciclos de reinício sem necessidade.
Exponha o serviço pela rede correta
O Service cria um endereço estável para acessar os Pods, mesmo quando eles são recriados e recebem novos IPs. Para comunicação interna, o tipo `ClusterIP` é suficiente. Para tráfego externo HTTP ou HTTPS, o padrão mais comum é combinar um Service com um Ingress Controller.
“`yaml apiVersion: v1 kind: Service metadata: name: api-pedidos namespace: producao spec: selector: app: api-pedidos ports:
- port: 80
targetPort: 8080 type: ClusterIP “`
O Ingress centraliza regras de host, rota, TLS e redirecionamento HTTPS. Em aplicações expostas ao público brasileiro, a localização do datacenter influencia diretamente a latência. Manter a camada de aplicação próxima aos usuários e aos bancos de dados reduz o tempo de resposta e evita tráfego desnecessário entre regiões.
Proteja configurações, segredos e acesso ao cluster
Não inclua senhas, tokens e chaves de API dentro da imagem nem em repositórios de código. Configurações não sensíveis podem ficar em ConfigMaps. Credenciais devem ser mantidas em Secrets, com controle de acesso restrito e rotação definida pela empresa.
Ainda assim, Secret não significa criptografia completa por padrão em todas as camadas. A organização precisa avaliar criptografia em repouso no cluster, proteção do etcd, gestão de chaves e permissões de leitura. Para sistemas com requisitos regulatórios ou dados sensíveis, esse desenho merece validação da equipe de segurança.
Também aplique o princípio do menor privilégio. Um Pod que apenas consulta uma API interna não deve receber permissões para listar namespaces, criar deployments ou acessar Secrets de outras aplicações. Network Policies ajudam a limitar conexões entre serviços, reduzindo a superfície de ataque caso um contêiner seja comprometido.
Automatize o deploy, mas mantenha aprovação para produção
Aplicar manifestos manualmente com `kubectl apply` é útil para testes e diagnósticos. Em produção, o método mais consistente é usar um pipeline de CI/CD. Ele pode executar testes, criar a imagem, verificar vulnerabilidades, publicar no registry e atualizar os manifestos com a nova tag.
A automação não precisa remover o controle humano. Empresas com serviços críticos podem exigir aprovação antes da etapa de produção, janelas de mudança ou validação de métricas após o rollout. O equilíbrio depende da frequência de releases, do impacto de uma falha e da maturidade operacional do time.
Durante a atualização, acompanhe o status com comandos como `kubectl rollout status deployment/api-pedidos -n producao`. Se houver falha, a reversão é direta com `kubectl rollout undo deployment/api-pedidos -n producao`, desde que o histórico de versões esteja preservado. O rollback recupera a versão anterior da aplicação, mas não desfaz automaticamente alterações incompatíveis no banco de dados. Migrações precisam ser planejadas para coexistir com versões antigas quando a reversão for uma possibilidade real.
Monitore capacidade, disponibilidade e experiência do usuário
Publicar é apenas o início da operação. A equipe deve observar logs, uso de CPU e memória, número de réplicas disponíveis, erros HTTP, latência e falhas de rede. Alertas úteis indicam impacto antes que o cliente abra um chamado: aumento de respostas 5xx, Pods em reinicialização, uso de memória próximo ao limite ou queda na disponibilidade de uma rota.
O autoscaling pode ajustar réplicas conforme CPU, memória ou métricas de negócio, como fila de pedidos. Porém, HPA não substitui capacidade física ou virtual disponível. Se todos os nós estiverem saturados, novos Pods permanecerão pendentes. Planejamento de nós, armazenamento, rede e regras de escalabilidade deve acompanhar o crescimento da aplicação.
Uma infraestrutura Kubernetes bem operada combina automação com visibilidade e suporte técnico capaz de responder quando a carga foge do esperado. Para operações que exigem baixa latência no Brasil, recursos escaláveis e acompanhamento contínuo, uma plataforma gerenciada como a Locacloud reduz a carga operacional sem tirar da equipe o controle sobre os deploys.
A publicação mais segura é aquela que pode ser repetida, medida e revertida com confiança. Comece com manifestos simples, defina limites reais e transforme cada release em uma rotina previsível para o negócio.