Implantação com Kubernetes

Q: Como solucionar falha de inicialização de um Pod?

1) kubectl describe pod <name> verificar Events; 2) kubectl logs <name> verificar logs do contêiner; 3) kubectl get events --sort-by=.metadata.creationTimestamp verificar eventos do cluster.

Kubernetes é um sistema operacional para orquestração de contêineres — com auto-scaling, rolling updates e capacidades de self-healing — garantindo que as aplicações estejam sempre online.

1. O Que Você Vai Aprender

K8s Deployment e ReplicaSet: Estratégias de Rolling Update e Rollback
Tipos de Service (ClusterIP / NodePort / LoadBalancer) e roteamento Ingress
ConfigMap / Secret: Gerenciando Configuração de Aplicação e Informações Sensíveis
Probes de Liveness/Readiness e Health Checks
Bob usa Helm Charts para gerenciar a configuração de implantação K8s do OrderFlow

2. Uma História Real de Operações Cloud-Native

(1) Dor: Operações Manuais Sobrecarregadas

O ambiente de produção do OrderFlow roda em três servidores, e Bob gerencia manualmente os contêineres Docker em cada servidor. Quando um servidor caiu, Bob iniciou manualmente um novo contêiner em outro servidor às 3 da manhã. Durante grandes eventos de vendas, é necessário escalar. Bob inicia contêineres adicionais manualmente e depois configura o balanceamento de carga; cada operação de escala leva 30 minutos. Charlie solicita auto-scaling, mas Bob diz: "Não consigo fazer isso."

(2) A Solução Kubernetes

Configuração Declarativa do K8s, Gerenciamento Automatizado:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderflow
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: orderflow
        image: orderflow-service:latest
        livenessProbe:
          httpGet: { path: /actuator/health/liveness, port: 8080 }
        readinessProbe:
          httpGet: { path: /actuator/health/readiness, port: 8080 }

Nó caiu? O K8s reinicia automaticamente o Pod em outro nó. Pico de tráfego? O HPA escala automaticamente.

(3) Resultado

Depois que Bob implantou o OrderFlow usando K8s: falhas de nó são recuperadas automaticamente (MTTR caiu de 2 horas para 30 segundos), e o HPA escala automaticamente (tempo de scale up caiu de 30 minutos para 2 minutos). Bob não precisa mais consertar servidores no meio da noite.

3. Recursos Centrais do K8s

(1) Dependências de Recursos

graph TD
    A[Ingress<br/>Acesso Externo] --> B[Service<br/>LB Interno]
    B --> C[Deployment<br/>Template de Pod]
    C --> D[ReplicaSet<br/>Réplicas de Pod]
    D --> E[Pod<br/>Grupo de Contêineres]
    E --> F[Container<br/>App OrderFlow]
    G[ConfigMap] --> F
    H[Secret] --> F

Recurso	Responsabilidade	Analogia
Pod	Menor unidade de implantação, contendo contêineres	Um grupo de processos
Deployment	Gerencia o Número de Réplicas de Pod e Políticas de Atualização	Gerenciador de Processos
Service	Fornece um ponto de acesso estável para os Pods	Balanceador de Carga
Ingress	Regras de Roteamento HTTP	Proxy Reverso Nginx
ConfigMap	Configuração não sensível	Arquivo de configuração
Secret	Configuração Sensível	Arquivo de Configuração Criptografado

4. Deployment e Rolling Updates

(1) ▶ Exemplo: Deployment do OrderFlow

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderflow
  labels:
    app: orderflow
spec:
  replicas: 3
  selector:
    matchLabels:
      app: orderflow
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: orderflow
    spec:
      containers:
      - name: orderflow
        image: registry.example.com/orderflow-service:1.0.0
        ports:
        - containerPort: 8080
        - containerPort: 8081
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: "prod"
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: orderflow-config
              key: database.host
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: orderflow-secrets
              key: database.password
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"

Saída:

TEXT

Deployment.apps/my-app created
Service/my-app-service exposed
Ingress/my-app-ingress created

Parâmetro (Rolling Update)	Significado	Valor Recomendado
`maxUnavailable`	Número máximo de Pods indisponíveis	1 (ou 25%)
`maxSurge`	Número máximo de instâncias além do alvo	1 (ou 25%)

(2) ▶ Exemplo: Rolling Updates e Rollbacks

BASH

# Atualizar versão da imagem (dispara rolling update)
kubectl set image deployment/orderflow orderflow=registry.example.com/orderflow-service:2.0.0

# Verificar status do rollout
kubectl rollout status deployment/orderflow

# Rollback para versão anterior
kubectl rollout undo deployment/orderflow

# Visualizar histórico de rollout
kubectl rollout history deployment/orderflow

Saída:

TEXT

// Comando executado com sucesso

5. Service e Ingress

(1) ▶ Exemplo: Definição de Service

YAML

# Service ClusterIP (acesso interno)
apiVersion: v1
kind: Service
metadata:
  name: orderflow
spec:
  selector:
    app: orderflow
  ports:
  - name: http
    port: 80
    targetPort: 8080
  - name: management
    port: 8081
    targetPort: 8081
  type: ClusterIP

Saída:

TEXT

Configuração aplicada com sucesso

Tipo de Service	Escopo de Acesso	Cenários Aplicáveis
ClusterIP	Dentro do cluster	Chamadas entre microsserviços
NodePort	Externo ao cluster (IP do nó:porta)	Acesso externo simples
LoadBalancer	Balanceador de Carga do Provedor Cloud	Ambiente de Produção (Cloud)
ExternalName	DNS CNAME	Referência a Serviço Externo

(2) ▶ Exemplo: Roteamento Ingress

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orderflow-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: api.orderflow.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: orderflow
            port:
              number: 80
  tls:
  - hosts:
    - api.orderflow.example.com
    secretName: orderflow-tls

Saída:

TEXT

Deployment.apps/my-app created
Service/my-app-service exposed
Ingress/my-app-ingress created

6. ConfigMap e Secret

(1) ▶ Exemplo: ConfigMap e Secret

YAML

# ConfigMap: configuração não sensível
apiVersion: v1
kind: ConfigMap
metadata:
  name: orderflow-config
data:
  database.host: "mysql-service"
  database.name: "orderflow"
  redis.host: "redis-service"
  spring.profiles.active: "prod"
  management.server.port: "8081"
---
# Secret: configuração sensível (codificada em base64)
apiVersion: v1
kind: Secret
metadata:
  name: orderflow-secrets
type: Opaque
data:
  database.password: b3JkZXJmbG93MTIz   # base64 de "orderflow123"
  redis.password: cmVkaXNwYXNz          # base64 de "redispass"
  jwt.private-key: LS0tLS1CRUdJTi...    # base64 da chave privada

Saída:

TEXT

Configuração aplicada com sucesso

Dimensão	ConfigMap	Secret
Tipo de Dado	Texto puro	Codificado em Base64
Conteúdo Aplicável	Configuração Não Sensível	Senhas, Chaves, Certificados
Método de Armazenamento	etcd (texto puro)	etcd (criptografado)
Limite de Tamanho	1MB	1MB

🔒 Segurança: Secrets são apenas codificados em Base64; não são criptografados. Em ambientes de produção, você deve habilitar a criptografia do etcd ou usar uma solução externa de gerenciamento de chaves como o Vault.

7. Probes de Liveness e Readiness

(1) ▶ Exemplo: Configuração de Probes

YAML

spec:
  containers:
  - name: orderflow
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 60
      periodSeconds: 30
      timeoutSeconds: 3
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 3
      failureThreshold: 3
    startupProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Saída:

TEXT

A configuração entrou em vigor.

YAML

# application-prod.yml: Habilitar grupos liveness/readiness
management:
  endpoint:
    health:
      show-details: always
      group:
        liveness:
          include: livenessState
        readiness:
          include: readinessState, db, redis

Tipo de Probe	Propósito	Consequência de Falha
`livenessProbe`	Verificar se o processo está em execução	Reiniciar o contêiner
`readinessProbe`	Verificar se está pronto para receber tráfego	Remover do Service
`startupProbe`	Verificar se a aplicação terminou de iniciar	Desabilitar outras probes durante a inicialização

8. Exemplo Completo: Implantação Completa do OrderFlow no K8s

YAML

# k8s/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: orderflow

---
# k8s/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: orderflow-config
  namespace: orderflow
data:
  SPRING_PROFILES_ACTIVE: "prod"
  DB_HOST: "mysql-service"
  DB_NAME: "orderflow"
  REDIS_HOST: "redis-service"
  MANAGEMENT_SERVER_PORT: "8081"

---
# k8s/secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: orderflow-secrets
  namespace: orderflow
type: Opaque
data:
  DB_PASSWORD: b3JkZXJmbG93MTIz

---
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderflow
  namespace: orderflow
spec:
  replicas: 3
  selector:
    matchLabels: { app: orderflow }
  strategy:
    rollingUpdate: { maxUnavailable: 1, maxSurge: 1 }
  template:
    metadata:
      labels: { app: orderflow }
    spec:
      containers:
      - name: orderflow
        image: registry.example.com/orderflow-service:1.0.0
        ports:
        - { containerPort: 8080 }
        - { containerPort: 8081 }
        envFrom:
        - configMapRef: { name: orderflow-config }
        - secretRef: { name: orderflow-secrets }
        resources:
          requests: { memory: "512Mi", cpu: "250m" }
          limits: { memory: "1Gi", cpu: "500m" }
        livenessProbe:
          httpGet: { path: /actuator/health/liveness, port: 8080 }
          initialDelaySeconds: 60; periodSeconds: 30; failureThreshold: 3
        readinessProbe:
          httpGet: { path: /actuator/health/readiness, port: 8080 }
          initialDelaySeconds: 30; periodSeconds: 10; failureThreshold: 3

---
# k8s/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: orderflow
  namespace: orderflow
spec:
  selector: { app: orderflow }
  ports:
  - { name: http, port: 80, targetPort: 8080 }
  type: ClusterIP

---
# k8s/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orderflow-ingress
  namespace: orderflow
spec:
  ingressClassName: nginx
  rules:
  - host: api.orderflow.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: { name: orderflow, port: { number: 80 } }

❓ Perguntas Frequentes

P Qual a diferença entre Deployment e StatefulSet?

R Um Deployment gerencia aplicações stateless (que podem ser substituídas a qualquer momento), enquanto um StatefulSet gerencia aplicações stateful (com identidades de rede fixas e armazenamento persistente). OrderFlow é um serviço stateless, então use Deployment. MySQL é um serviço stateful, então use StatefulSet ou Operator.

P Como posso alcançar implantação com zero downtime?

R 1) Configure readinessProbe para que Pods sejam adicionados ao Service apenas quando estiverem prontos; 2) Defina maxUnavailable da estratégia de rolling update para 0; 3) Use o hook preStop para desligamento gracoso (sleep 10 — aguardar o dreno de tráfego); 4) Implemente desligamento gracoso na aplicação (server.shutdown=graceful).

P Um Pod recuperará automaticamente a nova configuração após um ConfigMap ser atualizado?

R Configuração via variáveis de ambiente não será atualizada automaticamente (o Pod precisa ser reiniciado). Configuração via montagem de volume será atualizada automaticamente (com um atraso de aproximadamente 60 segundos). Spring Cloud Kubernetes suporta refresh hot de configuração.

P Como definir "requests" e "limits" para CPU e memória?

R "Requests" determinam o agendamento e a garantia mínima, enquanto "limits" determinam a capacidade máxima disponível. Recomendamos definir "limits" como 2x "requests." Valores muito baixos podem resultar em OOM kills ou CPU throttling, enquanto valores muito altos desperdiçam recursos. Monitore o uso real primeiro e depois ajuste as configurações.

P Quais são as vantagens dos Helm Charts?

R Helm é um gerenciador de pacotes para K8s que transforma todos os YAMLs em templates, suportando substituição de variáveis, controle de versão e implantação, upgrades e rollbacks com um clique. É bem adequado para gerenciar implantações complexas envolvendo múltiplos recursos.

P Como solucionar falha de inicialização de um Pod?

R 1) kubectl describe pod <name> verificar Events; 2) kubectl logs <name> verificar logs do contêiner; 3) kubectl get events --sort-by=.metadata.creationTimestamp verificar eventos do cluster.

📖 Resumo

Deployment gerencia réplicas de Pod e rolling updates; maxUnavailable e maxSurge controlam o ritmo da atualização
Service: Fornece um ponto de acesso estável aos Pods — interno via ClusterIP, externo via LoadBalancer
Ingress configura roteamento HTTP e TLS, equivalente a um proxy reverso no K8s
ConfigMaps são usados para gerenciar configuração não sensível, enquanto Secrets são usados para gerenciar informações sensíveis (codificados em Base64)
As probes Liveness, Readiness e Startup monitoram os estados de vivacidade, prontidão e inicialização, respectivamente
Configuração declarativa + rolling updates = implantação com zero downtime

📝 Exercícios

Exercício Básico (Dificuldade: ⭐): Escreva os arquivos YAML de Deployment e Service para o OrderFlow, implante-os em um cluster K8s local (minikube ou kind) e verifique que a aplicação está acessível.
Exercício Avançado (Dificuldade: ⭐⭐): Adicione configurações de ConfigMap, Secret e Ingress para habilitar o acesso via domínio externo. Configure probes de Liveness e Readiness, simule falhas de Pod e verifique a recuperação automática.
Desafio (Dificuldade: ⭐⭐⭐): Use um Helm Chart para gerenciar a implantação K8s do OrderFlow, suportando substituição de variáveis via values.yaml (versão da imagem, número de réplicas, configuração de recursos), e implemente rolling updates com helm upgrade e rollbacks com helm rollback.

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

Sobre Nós

404 Not Found

Implantação com Kubernetes

1. O Que Você Vai Aprender

2. Uma História Real de Operações Cloud-Native

(1) Dor: Operações Manuais Sobrecarregadas

(2) A Solução Kubernetes

(3) Resultado

3. Recursos Centrais do K8s

(1) Dependências de Recursos

4. Deployment e Rolling Updates

(1) ▶ Exemplo: Deployment do OrderFlow

(2) ▶ Exemplo: Rolling Updates e Rollbacks

5. Service e Ingress

(1) ▶ Exemplo: Definição de Service

(2) ▶ Exemplo: Roteamento Ingress

6. ConfigMap e Secret

(1) ▶ Exemplo: ConfigMap e Secret

7. Probes de Liveness e Readiness

(1) ▶ Exemplo: Configuração de Probes

8. Exemplo Completo: Implantação Completa do OrderFlow no K8s

❓ Perguntas Frequentes

📖 Resumo

📝 Exercícios