TL;DR
Quinze comandos resolvem quase todo o dia a dia no Kubernetes. Para ver: get com -o wide, describe e top. Para depurar: logs (com --previous quando o container reiniciou), get events ordenado por tempo e exec. Para deploy: set image, rollout status, rollout history e rollout undo, e scale. Para acessar sem expor: port-forward. Para conferir: auth can-i e explain. E um antes de todos: config current-context, porque o kubectl roda no cluster do contexto atual. Cada comando abaixo tem a saída real de um cluster de teste.
Antes de tudo: qual cluster
O kubectl roda no cluster do current-context. Em máquina com vários clusters, esse é o comando que evita o delete no lugar errado:
kubectl config current-context
kubectl config get-contexts
kubectl config use-context NOMEVer o que está rodando
get · com nó e IP
kubectl -n loja get pods -l app=vitrine -o wideNAME READY STATUS RESTARTS AGE IP NODE
vitrine-5c454758b8-stg57 1/1 Running 0 22s 10.42.1.10 k3d-ia4code-lab-agent-0
vitrine-5c454758b8-x9rsb 1/1 Running 0 22s 10.42.0.12 k3d-ia4code-lab-server-0get · vários tipos de uma vez
kubectl -n loja get deploy,svcNAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/vitrine 2/2 2 2 22s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/vitrine ClusterIP 10.43.35.187 <none> 80/TCP 22stop · consumo agora (precisa do metrics-server)
kubectl -n loja top pod cpu-limitada --containersPOD NAME CPU(cores) MEMORY(bytes)
cpu-limitada app 201m 0Midescribe junta estado, configuração e eventos de um objeto; é o primeiro comando de qualquer investigação. Os guias de erro mostram a saída dele em cada caso, como em ImagePullBackOff.
Depurar um pod
logs · de um Deployment, sem saber o nome do pod
kubectl -n loja logs deploy/vitrine --tail=3Found 3 pods, using pod/vitrine-5c454758b8-68n66
2026/09/25 23:37:48 [notice] 1#1: start worker process 39
10.42.0.1 - - [25/Sep/2026:23:37:48 +0000] "GET / HTTP/1.1" 200 615 "-" "kube-probe/1.35" "-"Quando o container reiniciou, o log que importa é o do anterior: kubectl logs POD --previous.
events · o que aconteceu, em ordem
kubectl -n loja get events --sort-by=.lastTimestamp | tail -50s Normal SuccessfulCreate replicaset/vitrine-5c454758b8 Created pod: vitrine-5c454758b8-qg9bt
0s Normal SuccessfulDelete replicaset/vitrine-664999df85 Deleted pod: vitrine-664999df85-b68v7
0s Normal Killing pod/vitrine-664999df85-b68v7 Stopping container vitrine
0s Normal ScalingReplicaSet deployment/vitrine Scaled down replica set vitrine-664999df85 from 1 to 0exec · rodar um comando dentro do container
kubectl -n loja exec deploy/vitrine -- nginx -vnginx version: nginx/1.27.5Deploy e rollback
set image · trocar a versão
kubectl -n loja set image deploy/vitrine vitrine=nginx:1.28-alpinedeployment.apps/vitrine image updatedrollout status · acompanhar até o fim
kubectl -n loja rollout status deploy/vitrineWaiting for deployment "vitrine" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "vitrine" rollout to finish: 1 old replicas are pending termination...
deployment "vitrine" successfully rolled outrollout history e undo · voltar a versão anterior
kubectl -n loja rollout history deploy/vitrine
kubectl -n loja rollout undo deploy/vitrineREVISION CHANGE-CAUSE
1 <none>
2 nginx 1.28
deployment.apps/vitrine rolled backA coluna CHANGE-CAUSE vem da anotação kubernetes.io/change-cause; sem ela, fica <none>. Depois do undo, o exec acima mostrou de novo o nginx 1.27.5.
scale · mudar o número de réplicas
kubectl -n loja scale deploy/vitrine --replicas=3deployment.apps/vitrine scaledAcessar sem expor
port-forward · o Service na sua máquina
kubectl -n loja port-forward svc/vitrine 18090:80
curl -s -o /dev/null -w "HTTP %{http_code}\n" localhost:18090/Forwarding from 127.0.0.1:18090 -> 80
Forwarding from [::1]:18090 -> 80
Handling connection for 18090
HTTP 200Conferir permissão e documentação
auth can-i · eu posso? e a conta de serviço do pod?
kubectl auth can-i delete pods -n loja
kubectl auth can-i delete pods -n loja --as system:serviceaccount:loja:defaultyes
noexplain · a documentação de qualquer campo, no terminal
kubectl explain deployment.spec.strategy.rollingUpdate.maxUnavailableFIELD: maxUnavailable <IntOrString>
DESCRIPTION:
The maximum number of pods that can be unavailable during the update. Value
can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%).
Absolute number is calculated from percentage by rounding down. This can not
be 0 if MaxSurge is 0. Defaults to 25%.Perguntas frequentes
Qual a diferença entre kubectl apply e kubectl create?
create cria e falha se o objeto já existe; apply cria ou atualiza a partir do arquivo, guardando a configuração aplicada. Para manifestos versionados, apply.
Como vejo o que um apply vai mudar antes de aplicar?
kubectl diff -f arquivo.yaml mostra a diferença entre o que está no cluster e o que o arquivo produziria. kubectl apply --dry-run=server -f arquivo.yaml valida contra a API sem gravar.
rollout undo volta para qual versão?
Para a revisão anterior, por padrão. Com --to-revision=N, para uma específica do rollout history. Ele só desfaz o template do pod; ConfigMaps e Secrets alterados à parte não voltam junto.
Por que meu comando pegou o cluster errado?
O kubectl usa o current-context do kubeconfig. Confira com kubectl config current-context antes de qualquer delete, e prefira passar --context explícito em scripts.