infra
Kubernetes
Kubernetes em entrevista cobra os objetos básicos e o modelo declarativo: a diferença entre Pod, ReplicaSet, Deployment e Service, como o control plane reconcilia o estado desejado com o real, o papel de liveness/readiness probes, e por que definir requests e limits de recurso evita o vizinho barulhento e o OOMKill.
Tópicos por senioridade
Perguntas mais cobradas
ver todas →- Fácil
Pod, Deployment e Service: o que cada um é
Pod: containers agendados juntos, efêmeros. Deployment: mantém N réplicas de um Pod, faz rollout/rollback. Service: IP/DNS estável que balanceia pros Pods saudáveis por label.
- Difícil
Liveness x readiness probe
Readiness falhou → sai do Service, sem restart (warm-up, drenar). Liveness falhou → container reiniciado. Liveness que checa dependência externa vira crash loop quando a dependência cai.
- Médio
Requests e limits de recurso
requests = reserva pro scheduler (mínimo garantido); limits = teto. Estourar CPU → throttling; estourar memória → OOMKilled. Sem limits, um container come o nó inteiro.
- Médio
ConfigMap x Secret (e por que Secret não é 'seguro' por padrão)
ConfigMap: config não sensível. Secret: dado sensível, com um pouco mais de cuidado da API — mas é só base64 no etcd por padrão, não criptografado. Ligue encryption-at-rest + RBAC, ou use Vault/External Secrets.
- Médio
Service x Ingress: como o tráfego externo chega num Pod
ClusterIP: interno. NodePort: porta alta em todo nó. LoadBalancer: LB do cloud por serviço (caro, sem roteamento L7). Ingress: regras HTTP por host/path + TLS, servidas por um Ingress Controller atrás de um LB só.
- Difícil
Autoscaling horizontal (HPA) e por que ele às vezes 'não escala'
HPA ajusta réplicas por métrica (CPU/custom) vs alvo. Não escala se: falta `resources.requests` de CPU, sem metrics-server, gargalo não é CPU, `maxReplicas` baixo, ou sem nós (precisa Cluster Autoscaler).