Common Mistakes I See Newcomers Make in Kubernetes

When people are just getting started with Kubernetes, the learning curve can feel steep. I’ve noticed that beginners often run into the same small mistakes. They don’t break your cluster, but they slow you down and cause a lot of why isn’t this working? moments. Here are some of the most common ones I’ve seen, and how to avoid them.

---

Capitalizing kubectl

It’s kubectl, not Kubectl. The command won’t run if you treat it like a proper noun, because shells are case-sensitive.

Wrong:

Kubectl get pods

Correct:

kubectl get pods

---

Forgetting the namespace

By default, kubectl looks in the default namespace. If your pod is actually in dev or staging, you’ll see nothing.

Wrong:

kubectl get pods
# Looks empty, but your pods are in another namespace

Correct:

kubectl get pods -n dev
kubectl describe pod my-app -n staging

---

Using get for logs

It feels natural to type get logs, but logs aren’t fetched with get.

Wrong:

kubectl get logs my-pod

Correct:

kubectl logs my-pod

---

Forgetting the container name in multi-container pods

If a pod runs multiple containers, kubectl logs needs to know which one.

Wrong:

kubectl logs my-multi-pod

Correct:

kubectl logs my-multi-pod -c sidecar-container

---

Deleting pods instead of deployments

Deleting a pod only removes it temporarily. If a Deployment manages it, Kubernetes spins up a new one immediately.

Wrong:

kubectl delete pod my-app-xyz
# Pod comes back right away

Correct:

kubectl delete deployment my-app
# Or better: update the deployment spec instead of deleting

---

Final Thoughts

None of these mistakes are catastrophic, and everyone falls into them early on. Kubernetes has a lot of moving parts, and sometimes the commands don’t behave how you expect. The more you get used to how kubectl sees the world namespaces, resources, and contexts, the smoother everything becomes.