I think we’re teaching Kubernetes backwards.
We start with:
kubectl get pods
kubectl apply -f deployment.yaml
kubectl logs -f
kubectl cordon
kubectl drain
Then we learn a few YAML manifests.
Then we call ourselves Kubernetes engineers.
I don’t think that’s enough.
Because the real question isn’t:
“What command do I run?”
It’s:
“Why is Kubernetes behaving this way?”
Why does a Deployment create a ReplicaSet instead of managing Pods directly?
Why does Kubernetes keep recreating a Pod after you delete it?
Why does a DaemonSet make sense for one workload but a Deployment makes more sense for another?
Why can an HPA scale a Deployment but not simply scale every workload?
Why would you use nodeSelector, taints/tolerations, or affinity instead of just telling Kubernetes where to put a Pod?
Why did the ecosystem need Gateway API when we already had Ingress?
Why does a production Kubernetes problem often require looking at metrics, logs, traces, networking, scheduling AND application behaviour rather than just running another kubectl command?
These aren’t trivia questions.
Get Habeebbabasulaiman’s stories in your inbox
Join Medium for free to get updates from this writer.
They’re questions about distributed systems, control loops, scheduling, networking, resilience and observability.
And this is the shift I’ve been making in my own Kubernetes journey.
I’m no longer trying to simply memorize Kubernetes.
I’m trying to understand the engineering philosophy behind it.
The most fascinating part of Kubernetes to me is the reconciliation model:
You declare the state you want.
Kubernetes continuously works to make reality converge toward that state.
That single idea explains so much of what makes Kubernetes powerful.
Self-healing.
Rolling updates.
Replica management.
Controllers.
Autoscaling.
Desired state.
And eventually, the entire operator pattern.
That’s a much deeper skill than memorizing YAML.
Anyone can learn kubectl.
The real engineering skill is being able to look at a cluster, understand what it’s doing, identify why it’s doing it, and make the right decision when reality doesn’t match your desired state.
That’s the Kubernetes engineer I’m working toward becoming.
And honestly, the deeper I go, the more I realize:
Kubernetes isn’t difficult because there are too many commands.
It’s difficult because it forces you to think like a distributed-systems engineer.
Do you agree?
Or do you think Kubernetes expertise is primarily about mastering the tools and abstractions around the platform?
I’d genuinely like to hear the opposing argument.
