If you have ever stared at a Pod stuck in ContainerCreating and wondered what you did wrong, this one is for you. These are the mistakes I made while learning Kubernetes — and the lessons that finally clicked.
Introduction
There is a version of Kubernetes that exists in beginner tutorials, and there is the version you meet when you actually start using it. In the tutorial version, everything looks clean: create a Pod, expose a Service, scale replicas, move on. In real life, there are drivers that are missing, Docker permissions that block you, images that take time to pull, Services that do not exist yet, namespaces that quietly change what you are looking at, and Pods that disappear only to come back because Kubernetes is doing exactly what it was designed to do.
This is not a story about becoming a Kubernetes expert overnight. It is a story about getting my hands dirty, making honest mistakes, troubleshooting them one by one, and gradually understanding why organizations trust Kubernetes to run production workloads.
1. My starting point
I started by learning the foundations: what Kubernetes is, why companies use it, what a cluster is, the difference between the control plane and worker nodes, what nodes and Pods are, how containers differ from Pods, and how Docker and Kubernetes relate to each other. I also worked with kubectl, Minikube, namespaces, Deployments, ReplicaSets, Services, scaling, Helm, and later Kubeshark.
On paper, that list looked manageable. In practice, every concept became clearer only when it broke in front of me.
2. What I thought Kubernetes was (and what I misunderstood)
At the beginning, I thought Kubernetes was basically Docker at a bigger scale. That assumption did not survive long. The more I used it, the more I saw that Kubernetes is not mostly about starting containers. It is about describing a desired state and letting the cluster keep moving toward that state.
A few of my early wrong assumptions:
Minikube would just start, without needing a supported driver or runtime such as Docker.
A Pod in ContainerCreating meant something was definitely broken.
Deleting a Pod meant I had removed the application.
I could use minikube service before creating any Service.
Every failure during Helm or Kubeshark setup had to be a Kubernetes problem.
3. Setup: Minikube, Docker, and permissions
One of my first real lessons came from setup. I tried minikube start before having a supported driver installed. That reminded me: Kubernetes on a laptop still depends on what is underneath it. Minikube is not magic. It needs a runtime/driver to create and run the local cluster.
Then came Docker permission issues, which led me to learn about the Docker group and why a user gets blocked from Docker commands until the right permissions are in place.
Early Cloud/DevOps lesson: when something “Kubernetes-related” fails, it is sometimes the environment around Kubernetes that needs attention first.
4. My first Pod and the patience it taught me
I created an NGINX Pod and saw it sit in ContainerCreating. My first instinct was that something was wrong. Eventually it became Running. That moment sounded small, but it mattered. Container images may need to be downloaded, Internet access matters, and a Pod not being ready immediately does not automatically mean failure.
The lesson: instead of treating every delay as an error, I started asking, “What is Kubernetes doing right now?”
5. Deployments, ReplicaSets, and reconciliation
The biggest “click” moment came when I deleted a Pod and watched Kubernetes recreate it. I had deleted a Pod that was managed by a Deployment. The Deployment still wanted the desired number of replicas, so the cluster created another Pod to bring the state back in line.
That single experience taught me more than several pages of explanation could. It made Deployments, ReplicaSets, and reconciliation feel real.
6. Services — and how I learned what SVC_NOT_FOUND really means
Services answered a question I kept running into: how do I reliably reach an application when Pods are temporary? A Pod can be recreated and get a different IP. A Service gives that changing set of Pods a stable endpoint.
I learned this when I ran:
minikube service nginx -n development
before I had created any Service. The response was SVC_NOT_FOUND. My assumption was the bug, not Minikube. The fix was to create the Service explicitly:
kubectl expose pod nginx --type=NodePort --port=80
7. Scaling
Scaling replicas sounds simple when you read it, but it becomes more meaningful when you watch it happen. Increasing replica count means the Deployment updates the ReplicaSet, and the ReplicaSet creates more Pods until the cluster reaches the new desired count. That is when Kubernetes starts feeling less like manual container management and more like orchestration.
8. Troubleshooting 🛠️
The most valuable part of this journey has been troubleshooting. Good troubleshooting is not random trial and error. It is a sequence:
Read the error.
Question the assumption behind the step.
Inspect the cluster state.
Compare expected behavior with actual behavior.
Isolate the real cause.
9. Helm & Kubeshark — and the layer-aware lesson
Helm clicked for me as a package manager for Kubernetes. Then came Kubeshark. I ran into repository connectivity problems and almost blamed Kubernetes immediately. The more useful question was: is this a cluster problem, or is the repository itself unreachable from my environment?
curl -I https://helm.kubeshark.com/index.yaml
curl -I https://google.com
curl -I https://github.com
curl -I https://raw.githubusercontent.com
That comparison mattered. It helped me distinguish between “my Kubernetes or Helm setup is broken” and “this particular external repository cannot be reached.” Systems fail in layers. Good troubleshooting means identifying which layer is actually failing.
10. Mistakes I made — and what each one taught me
| MISTAKE | LESSON |
|---|---|
| Starting Minikube without a supported driver | Kubernetes tools still depend on the host environment. Drivers, runtimes, and permissions matter. |
Treating ContainerCreating as immediate failure |
Sometimes the image is still downloading. Read the state in context and inspect events before panicking. |
Trying minikube service before creating a Service |
A Pod is not automatically a Service. Reachability needs to be defined explicitly. |
| Deleting a Pod and expecting the app to be gone | Deployments preserve the desired replica count. Delete the Deployment if you want the managed Pods to stop returning. |
| Working in the wrong namespace | Always confirm the namespace context. Resources can be healthy while you are looking in the wrong place. |
| Assuming every Helm/Kubeshark issue was a Kubernetes issue | Sometimes the real problem is repository/network access outside the cluster. Verify the failing layer. |
11. Commands that actually helped me
minikube start
kubectl get pods -A
kubectl get deployments -A
kubectl get services -A
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl get deployment nginx-deployment -o yaml
kubectl expose pod nginx --type=NodePort --port=80
minikube service <service-name> --url
curl -I https://helm.kubeshark.com/index.yaml
12. Lessons for other beginners
- Do not rush past the basic architecture. Knowing the relationship between Deployments, ReplicaSets, Pods, and Services saves time later.
- Read the exact error message before trying random commands.
- Check namespaces early. It is one of the easiest ways to eliminate confusion.
- If a Pod is managed by a Deployment, deleting the Pod is not the same as deleting the application.
- When troubleshooting, identify the failing layer: local machine, Docker runtime, Minikube, Kubernetes resource, network access, or external repository.
What I now understand
Kubernetes is not about micromanaging containers. It is about declaring state, letting the cluster maintain it, and using higher-level abstractions to make applications resilient and reachable.
What I still need to learn
There is still a lot ahead: Ingress, ConfigMaps, Secrets, persistent storage, observability, production-grade networking, security, and more advanced debugging patterns. The basics are no longer abstract terms — they now connect to things I have actually seen fail and recover.
Next stop: Kubernetes Ingress 🚦
Ingress is the natural next topic because it ties everything together. Pods run the application, Services give a stable way to reach those Pods inside the cluster, and Ingress sits above that to route external HTTP/HTTPS traffic to the right Service. If Services help internal reachability, Ingress helps organize external access more cleanly.
Conclusion
Every time Minikube refused to start, every time a Pod sat in ContainerCreating, every time a Service did not exist yet, every time a namespace caused confusion, every time a Pod came back after I deleted it — Kubernetes was teaching me something useful.
I thought learning Kubernetes would mostly be about commands. I was wrong. It has been more about systems thinking, careful troubleshooting, and learning how to ask better questions.
Next stop: Kubernetes Ingress — understanding how external traffic reaches Services, and through them, the Pods behind the application.
Top comments (0)