--- title: "The Difference Between Knowing Kubernetes and Understanding Kubernetes" url: https://daily.dev/posts/the-difference-between-knowing-kubernetes-and-understanding-kubernetes-uxzea3gup source_url: https://medium.com/@hrk84ya/the-difference-between-knowing-kubernetes-and-understanding-kubernetes-f79b8ba32b75 type: share source: "Chhoeun K.Keaphirunphirakbot" author: "Chhoeun K.Keaphirunphirakbot" published: 2026-07-29T02:04:45.358Z updated: 2026-07-29T14:17:27.051Z tags: ["devops", "kubernetes"] upvotes: 89 comments: 7 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Difference Between Knowing Kubernetes and Understanding Kubernetes **[Chhoeun K.Keaphirunphirakbot](https://daily.dev/sources/iuklhcqx7w7k6axa5dkxm)** · [@ckphirakbot](https://daily.dev/ckphirakbot) · 89 upvotes · 7 comments ## Summary A reflection on the gap between memorizing Kubernetes architecture and truly understanding it through hands-on experience. The author recounts a production CrashLoopBackOff incident where diagram-level knowledge proved insufficient, and a senior engineer's instinctive use of `kubectl logs --previous` revealed how real understanding is built from debugging experience, not documentation. Key lessons include how ConfigMap changes propagate to pods, how liveness probes can kill healthy pods, and how DNS issues can trace back to resource-starved CoreDNS. The advice: spin up a local cluster with kind or minikube, deliberately break things, and build pattern-matching intuition before production incidents demand it. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@radmilomarkovic** · 6 upvotes > As with every technology real understanding comes with experience on the right project. **@agustinbarrientos** · 1 upvotes > A local cluster lets an aggressive liveness probe fail somewhere cheaper than production **@ahmetozel** · 1 upvotes > Deliberate failure exercises are most valuable when they include a hypothesis before the fix. For a CrashLoopBackOff, write down what kubelet state, previous logs, events, and probe history should show, then compare that model with the evidence. I would also practice failures that cross control-plane boundaries, such as DNS degradation caused by resource pressure or stale ConfigMap assumptions. That builds causal understanding instead of a list of kubectl commands to try in order. ## Similar posts on daily.dev - [Don’t just attend KubeCon \+ CloudNativeCon, Merge Forward your experience\!](https://daily.dev/posts/don-t-just-attend-kubecon-cloudnativecon-merge-forward-your-experience--l0rpp73x8) · CNCF · 0 upvotes · 0 comments - [Announcing H2 2026 KCDs](https://daily.dev/posts/announcing-h2-2026-kcds-m96goajm1) · CNCF · 1 upvotes · 0 comments - [Two months of Open Community Groups](https://daily.dev/posts/two-months-of-open-community-groups-asf52zhbs) · CNCF · 0 upvotes · 0 comments --- Tags: [#devops](https://daily.dev/tags/devops), [#kubernetes](https://daily.dev/tags/kubernetes) [View this post on daily.dev](https://daily.dev/posts/the-difference-between-knowing-kubernetes-and-understanding-kubernetes-uxzea3gup)