O ecossistema Kubernetes consolidou-se como o padrão para a gestão de workloads conteinerizados. Para desenvolvedores Java que utilizam Spring Boot, compreender como integrar essas tecnologias é essencial para garantir escalabilidade e resiliência em ambientes de produção.

Componentes Estruturais do Cluster

Antes de avançar para a configuração, é fundamental alinhar os conceitos principais utilizados na arquitetura:

• Pod: A menor unidade de execução, capaz de agrupar um ou mais containers que compartilham armazenamento e rede.
• Deployment: Define o estado desejado para a aplicação, gerenciando réplicas e estratégias de atualização (rolling updates).
• Service: Atua como um balanceador de carga interno, fornecendo um endpoint estável para comunicação entre componentes.
• Ingress: Gerencia o acesso externo aos serviços, geralmente via protocolos HTTP/HTTPS.

Configuração do Dockerfile

A criação de uma imagem eficiente é o primeiro passo. Abaixo, uma abordagem utilizando uma imagem base otimizada para Java:

FROM amazoncorretto:17-alpine
LABEL maintainer="devops-team"
WORKDIR /application

# Copia o artefato gerado pelo Maven ou Gradle
COPY build/libs/*.jar service-api.jar

# Define limites de memória para a JVM via variáveis de ambiente
ENV JAVA_OPTS="-Xms256m -Xmx512m"

EXPOSE 8080
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar service-api.jar"]

Manifestos de Recursos do Kubernetes

A infraestrutura como código (IaC) no Kubernetes é definida via arquivos YAML. Abaixo, a definição para o deployment e exposição da API.

1. Deployment e Gerenciamento de Carga

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: backend-core
  template:
    metadata:
      labels:
        app: backend-core
    spec:
      containers:
      - name: main-container
        image: minha-registry.io/api-backend:v1.2.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "800m"
            memory: "1Gi"
          requests:
            cpu: "400m"
            memory: "512Mi"

2. Exposição via Service e Ingress

# Service interno
apiVersion: v1
kind: Service
metadata:
  name: api-backend-svc
spec:
  selector:
    app: backend-core
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
# Configuração de Roteamento Externo
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress-gateway
spec:
  rules:
  - host: api.empresa.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-backend-svc
            port:
              number: 80

Implementação de Health Checks

Para que o Kubernetes saiba quando reiniciar um container ou quando ele está pronto para receber tráfego, utilizamos os probes vinculados ao Spring Boot Actuator:

        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 40
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

Operação e Manutenção do Ciclo de Vida

Com os manifestos prontos, a gestão do ciclo de vida é feita via CLI (kubectl). Abaixo, os comandos essenciais para o fluxo de trabalho:

Deploy e Atualização

# Aplicação dos manifestos
kubectl apply -f k8s-configs/

# Atualização de imagem com zero downtime
kubectl set image deployment/api-backend-deploy main-container=minha-registry.io/api-backend:v1.2.1

# Monitoramento do rollout
kubectl rollout status deployment/api-backend-deploy

Escalabilidade e Diagnóstico

O Kubernetes permite ajustar a capacidade computacional dinamicamente conforme a demanda:

# Escalonamento manual
kubectl scale deployment api-backend-deploy --replicas=8

# Configuração de auto-scaling baseado em CPU
kubectl autoscale deployment api-backend-deploy --min=3 --max=12 --cpu-percent=75

# Verificação de logs em tempo real
kubectl logs -f -l app=backend-core

Monitoramento e Observabilidade

Em ambientes complexos, apenas logs não são suficeintes. É recomendada a utilização de métricas expostas pelo endpoint /actuator/prometheus, integrando-as ao Prometheus e Grafana para visualização de consumo de heap, threads e latência de requisições. O comando kubectl top pods fornece uma visão rápida do consumo de recursos atual no cluster.