Erros Comuns em Kubernetes que Você Precisa Evitar: Guia Completo

Erros comuns em Kubernetes que você deve evitar

Eu compartilho os principais pontos de falha que encontrei ao longo de anos atuando com clusters. A ideia é antecipar armadilhas e aplicar práticas que mantenham seus workloads estáveis e escaláveis.

1) Recursos e limites mal configurados

Configurar recursos de forma inadequada é uma das causas mais comuns de instabilidade. Sem requests bem definidos, o scheduler pode alocar pods em nós que não atendem às necessidades mínimas. Sem limites, contêineres podem consumir mais CPU/memória do que o esperado, levando a OOMKills em outros pods do mesmo nó ou a desbalanceamentos involuntários de recursos.

Defina requests como o uso típico mínimo do pod e limits como o teto seguro.
Considere LimitRange no namespace para manter um padrão de recursos entre diferentes equipes.
Monitore consumo real para ajustar valores periodicamente.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: gateway
          image: myregistry/api-gateway:1.2.3
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Boas práticas:
– Use ciclos de métricas (CPU/memória) para ajustar os valores.
– Evite definir limites muito altos sem necessidade; isso reduz a amortização de recursos entre workloads diferentes.

2) Probes mal configurados (Liveness e Readiness)

Probes ajudam a manter a saúde do seu cluster, mas configurações inadequadas podem causar ciclos de reinício desnecessários ou tráfego inválido para pods não prontos. Distinga claramente liveness e readiness: readiness controla se o pod recebe tráfego; liveness indica se o contêiner está vivo.

Readiness deve refletir quando o serviço está apto a atender pedidos.
Liveness deve reagir a falhas internas sem reiniciar desnecessariamente o pod já pronto.
Ajuste initialDelaySeconds, periodSeconds e failureThreshold com base no tempo de inicialização do seu serviço.

apiVersion: v1
kind: Pod
metadata:
  name: productive-pod
spec:
  containers:
    - name: worker
      image: myregistry/worker:2.5.0
      ports:
        - containerPort: 8080
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
        failureThreshold: 3

Dicas rápidas:
– Use endpoints simples que realmente indiquem a saúde do serviço.
– Evite probes que dependam de estados de dependências que podem estar offline temporariamente.

3) ConfigMaps, Secrets e gestão de configuração

Guardar informações sensíveis ou configurações críticas sem cuidado costuma levar a exposições acidentais ou a reinicializações em massa quando segredos são alterados. Kubernetes oferece ConfigMaps e Secrets, mas a forma como você os utiliza importa tanto quanto o conteúdo.

Não coloque segredos como literals em código ou em variáveis de ambiente sem proteção.
Prefira montar Secrets como volumes ou referenciá-los via envFrom/env:SecretRef apenas quando necessário.
Habilite encryption at rest para Secrets no cluster e utilize rotacionamento quando possível.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: dXNlcm5hbWU=        # base64: username
  password: cGFzc3dvcmQxMjM=    # base64: password123

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-secret
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: app
          image: myregistry/app:1.0
          volumeMounts:
            - name: secret-volume
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: secret-volume
          secret:
            secretName: db-credentials

Boas práticas adicionais:
– Evite depender de segredos em line no YAML ou em logs.
– Considere políticas de RBAC para restringir quem pode ler segredos.

4) Estratégias de deployments e rollouts

Falhas em estratégias de implantação causam downtime desnecessário ou atualizações parciais. Adotar um rollout controlado com parâmetros de estratégia ajuda a manter a disponibilidade e reduzir o risco de falhas em produção.

Use RollingUpdate com limites de disponibilidade e surgimento para equilibrar atualização com disponibilidade.
Garanta readiness antes de expor o novo version para tráfego real.
Automatize o rollback se o novo deployment apresentar falhas graves.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 1
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myregistry/api:1.2.4
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Boas práticas adicionais:
– Considere usar Horizontal Pod Autoscaler (HPA) para ajustar a capacidade com base no tráfego/latência.
– Verifique logs e métricas durante o rollout para detectar sinais de problemas rapidamente.

Yuri Sousa

Sou Apaixonado pela programação e estou trilhando o caminho de ter cada diz mais conhecimento e trazer toda minha experiência vinda do Design para a programação resultando em layouts incríveis e idéias inovadoras! Conecte-se Comigo!