Kubernetes para Entrevistas: Guia Completo de Pods, Services e Deployments

Entrevistas para posições de DevOps e engenharia de plataforma frequentemente abordam Kubernetes de maneira aprofundada. Recrutadores esperam que candidatos compreendam não apenas os comandos básicos do kubectl, mas também a arquitetura interna do orquestrador e como os recursos se relacionam entre si. Pods, Services e Deployments representam a tríade fundamental que sustenta praticamente todas as aplicações em produção no Kubernetes. Dominar esses conceitos abre portas para discussões mais avançadas sobre escalabilidade, resiliência e padrões de deployment.

Entendendo Pods: A Unidade Atômica do Kubernetes

O Pod constitui a menor unidade deployável no Kubernetes. Diferente de containers isolados, um Pod pode encapsular um ou mais containers que compartilham o mesmo namespace de rede e volumes de armazenamento. Essa característica permite que containers dentro do mesmo Pod se comuniquem via localhost, simplificando arquiteturas de sidecar e init containers.

Entrevistadores costumam perguntar por que o Kubernetes não gerencia containers diretamente. A resposta reside no modelo de coesão: containers em um Pod representam processos que devem ser escalados e deployados juntos. Um exemplo clássico envolve uma aplicação principal acompanhada de um container de logging ou proxy.

A especificação de um Pod inclui elementos críticos que aparecem frequentemente em entrevistas:

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Observe os campos resources, readinessProbe e livenessProbe. Requests garantem recursos mínimos reservados pelo scheduler, enquanto limits estabelecem o teto máximo de consumo. Quando um container ultrapassa o limite de memória, o kubelet o encerra com status OOMKilled. Probes de readiness determinam quando o Pod pode receber tráfego, enquanto probes de liveness indicam se o container deve ser reiniciado.

Ciclo de Vida do Pod e Políticas de Restart

Pods atravessam fases bem definidas durante sua existência. Entender esse ciclo ajuda a diagnosticar problemas e responder perguntas sobre comportamento em cenários de falha.

| Fase | Descrição | |------|----------| | Pending | Pod aceito pelo cluster, aguardando scheduling ou download de imagem | | Running | Pod vinculado a um node, pelo menos um container em execução | | Succeeded | Todos os containers terminaram com sucesso (exit code 0) | | Failed | Pelo menos um container terminou com falha | | Unknown | Estado do Pod não pode ser obtido (geralmente falha de comunicação com o node) |

A política de restart determina o comportamento após o término de containers:

• Always (padrão): Reinicia containers independentemente do exit code. Ideal para serviços de longa duração.
• OnFailure: Reinicia apenas quando o container falha (exit code diferente de zero). Apropriado para jobs que devem ser retentados em caso de erro.
• Never: Nunca reinicia containers. Utilizado para tarefas pontuais onde falhas devem ser tratadas externamente.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Note que o Pod de migração utiliza OnFailure para retentar em caso de erro de conexão com o banco de dados, mas não reiniciar se a migração completar com sucesso.

Deployments: Gerenciando Estado Desejado

Enquanto Pods representam instâncias individuais, Deployments gerenciam o ciclo de vida de múltiplas réplicas. O Deployment abstrai a complexidade de manter o número desejado de Pods em execução, realizar atualizações graduais e permitir rollbacks.

O controller do Deployment cria e gerencia ReplicaSets, que por sua vez garantem que o número especificado de Pods esteja sempre disponível. Essa cadeia de responsabilidades aparece frequentemente em perguntas sobre a arquitetura do Kubernetes:

Deployment -> ReplicaSet -> Pods

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

O campo strategy define como atualizações ocorrem. RollingUpdate substitui Pods gradualmente, garantindo disponibilidade durante o processo. Os parâmetros maxUnavailable e maxSurge controlam a velocidade versus a capacidade extra durante a transição.

Executando Rollbacks

Rollbacks permitem reverter para versões anteriores quando problemas são detectados em produção. O Kubernetes mantém histórico de revisões baseado no valor de revisionHistoryLimit:

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

Candidatos que demonstram conhecimento sobre rollbacks e histórico de revisões destacam-se em entrevistas, pois isso indica experiência com operações em produção.

Services: Expondo Aplicações de Forma Estável

Pods possuem endereços IP efêmeros que mudam a cada recriação. Services resolvem esse problema fornecendo um endpoint estável (ClusterIP ou DNS) que roteia tráfego para Pods saudáveis através de selectors baseados em labels.

O kube-proxy implementa o roteamento de Services em cada node, utilizando iptables ou IPVS dependendo da configuração do cluster. Entender essa mecânica ajuda a responder perguntas sobre latência e comportamento de rede.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

O Service acima expõe Pods com label app: api na porta 80 do cluster. Clientes internos acessam o serviço via api-service.namespace.svc.cluster.local ou simplesmente api-service dentro do mesmo namespace.

Tipos de Service e Casos de Uso

Kubernetes oferece diferentes tipos de Service para cenários específicos:

| Tipo | Descrição | Caso de Uso | |------|-----------|-------------| | ClusterIP | IP interno acessível apenas dentro do cluster | Comunicação entre microsserviços | | NodePort | Expõe o serviço em uma porta fixa em cada node (30000-32767) | Acesso externo simples, testes | | LoadBalancer | Provisiona load balancer externo via cloud provider | Produção com tráfego externo | | ExternalName | Mapeia serviço para um DNS externo | Integração com serviços fora do cluster |

Para expor aplicações em produção com tráfego externo, LoadBalancer representa a escolha mais comum:

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Anotações específicas do cloud provider permitem customizar o comportamento do load balancer, como escolher entre Application Load Balancer (ALB) ou Network Load Balancer (NLB) na AWS.

Conectando Deployments a Services

A conexão entre Deployments e Services ocorre exclusivamente através de labels. O selector do Service deve corresponder aos labels definidos no template do Pod dentro do Deployment.

Essa arquitetura desacoplada permite padrões avançados como canary deployments, onde uma versão experimental recebe uma fração do tráfego:

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Com 3 réplicas do Deployment principal e 1 réplica canary, o Service distribui aproximadamente 25% do tráfego para a nova versão. Esse padrão permite validar mudanças em produção com impacto limitado.

Horizontal Pod Autoscaler: Escalabilidade Automática

O HPA ajusta automaticamente o número de réplicas com base em métricas como CPU e memória. Essa capacidade aparece frequentemente em perguntas sobre arquitetura de sistemas resilientes e custos de infraestrutura.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

O campo behavior controla a velocidade de scale down, evitando oscilações rápidas em cargas variáveis. O stabilizationWindowSeconds garante que o sistema aguarde um período antes de reduzir réplicas, prevenindo thrashing.

Para que o HPA funcione corretamente, o Metrics Server deve estar instalado no cluster. Candidatos que mencionam essa dependência demonstram experiência prática com autoscaling.

Perguntas Frequentes em Entrevistas

Qual a diferença entre Deployment e StatefulSet? Deployments gerenciam aplicações stateless onde Pods são intercambiáveis. StatefulSets garantem identidades estáveis (nomes e volumes persistentes) para aplicações stateful como bancos de dados.

Como o Kubernetes descobre quais Pods pertencem a um Service? O controller de endpoints monitora Pods que correspondem ao selector do Service e atualiza a lista de endpoints automaticamente. Apenas Pods com readinessProbe bem-sucedida recebem tráfego.

O que acontece se um Pod exceder seus limites de recursos? Exceder o limite de CPU resulta em throttling (redução de ciclos de CPU). Exceder o limite de memória causa OOMKilled, e o container é reiniciado conforme a política de restart.

Como realizar zero-downtime deployments? Configurar readinessProbe adequadamente, utilizar RollingUpdate strategy com maxUnavailable e maxSurge apropriados, e garantir que a aplicação trate graceful shutdown via SIGTERM.

Qual a função do selector em um Deployment? O selector identifica quais Pods o Deployment gerencia. Labels no selector devem corresponder exatamente aos labels no template do Pod, caso contrário o Deployment falha na validação.

Como debugar um Pod que não inicia? Verificar eventos com kubectl describe pod, logs com kubectl logs, e status das probes. Problemas comuns incluem imagem não encontrada, recursos insuficientes no cluster, ou falha em probes de liveness.

Para mais perguntas de entrevista sobre Kubernetes e DevOps, acesse perguntas de entrevista DevOps.

Conclusão

Dominar Pods, Services e Deployments fornece a base necessária para discutir tópicos avançados de Kubernetes em entrevistas. Recapitulando os pontos principais:

• Pods encapsulam containers que compartilham rede e armazenamento, representando a unidade atômica de deployment
• Probes de readiness e liveness controlam roteamento de tráfego e restarts, respectivamente
• Deployments gerenciam ReplicaSets e habilitam rolling updates com possibilidade de rollback
• Services fornecem endpoints estáveis para descoberta de serviços através de selectors baseados em labels
• HPA automatiza escalabilidade horizontal baseada em métricas de recursos
• Labels e selectors conectam todos os recursos, permitindo padrões como canary deployments

Preparar-se com exemplos práticos de YAML e entender o funcionamento interno de cada recurso diferencia candidatos em processos seletivos para posições de DevOps, SRE e engenharia de plataforma.