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

> Domine os conceitos essenciais de Kubernetes para entrevistas de emprego. Aprenda sobre Pods, Services, Deployments e HPA com exemplos de código YAML.

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, pods, services, deployments, entrevista
- Reading time: 12 min

---

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.

> **Referência Rápida para a Entrevista**
>
> O Kubernetes organiza containers em Pods (unidade mínima de deployment), gerencia réplicas através de Deployments e expõe aplicações via Services. Essa hierarquia aparece em praticamente todas as perguntas técnicas sobre K8s.

## 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:

```yaml
# 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.

> **Armadilha Comum em Entrevistas**
>
> Confundir readinessProbe com livenessProbe pode custar pontos valiosos. A readiness afeta apenas o roteamento de tráfego (Service endpoints), enquanto a liveness controla restarts do container. Aplicar incorretamente pode causar restarts desnecessários ou roteamento para Pods não prontos.

## 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.

```yaml
# 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**

```yaml
# 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`:

```bash
# 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.

```yaml
# 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:

```yaml
# 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.

> **Gateway API: O Futuro do Ingress**
>
> A Gateway API representa a evolução do Ingress, oferecendo maior expressividade e separação de responsabilidades. Clusters modernos adotam progressivamente esse modelo, embora Ingress ainda predomine em ambientes existentes. Candidatos familiarizados com ambos demonstram conhecimento atualizado.

## 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:

```yaml
# 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.

```yaml
# 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](/technologies/devops/interview-questions/kubernetes-basics).

## 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.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pt/blog/devops/kubernetes-interview-pods-services-deployments-explained