{"id":4736,"date":"2026-03-16T21:42:47","date_gmt":"2026-03-16T16:12:47","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/what-is-kubernetes-a-simple-guide-to-container-orchestration\/"},"modified":"2026-03-16T21:42:47","modified_gmt":"2026-03-16T16:12:47","slug":"what-is-kubernetes-a-simple-guide-to-container-orchestration","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/what-is-kubernetes-a-simple-guide-to-container-orchestration\/","title":{"rendered":"What is Kubernetes? A Simple Guide to Container Orchestration"},"content":{"rendered":"

$ kubectl get pods -A
\nNAMESPACE NAME READY STATUS RESTARTS AGE
\nkube-system coredns-7689d884b-l2v98 0\/1 CrashLoopBackOff 42 (3m ago) 72h
\nkube-system kube-proxy-z4m2n 0\/1 Error 15 72h
\nproduction api-gateway-v2-7f5d9c8d4b-9w2k1 0\/2 ImagePullBackOff 0 14m
\nproduction order-processor-5566778899-abc12 0\/1 CreateContainerConfigError 0 12m
\nproduction payment-service-8899aabbcc-xyz34 0\/1 Terminating 0 72h
\nproduction auth-service-66778899aa-def56 0\/1 Pending 0 5m
\nmonitoring prometheus-server-0 0\/1 CrashLoopBackOff 112 72h
\ningress-nginx ingress-nginx-controller-646d5d4d54-m9s2z 0\/1 ValidatingWebhookConfiguration 0 2m
\nkube-system etcd-ip-10-0-64-12.ec2.internal 0\/1 Error 9 72h<\/p>\n

$ kubectl describe node ip-10-0-64-12.ec2.internal
\nName: ip-10-0-64-12.ec2.internal
\nStatus: Ready
\nConditions:
\n Type Status LastHeartbeatTime Reason Message
\n —- —— —————– —— ——-
\n NetworkUnavailable False Thu, 24 Oct 2024 03:14:22 +0000 RouteCreated RouteCreated.
\n MemoryPressure True Thu, 24 Oct 2024 04:45:10 +0000 KubeletHasInsufficientMemory kubelet has insufficient memory available
\n DiskPressure False Thu, 24 Oct 2024 04:45:10 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure
\n PIDPressure False Thu, 24 Oct 2024 04:45:10 +0000 KubeletHasNoPidPressure kubelet has no pid pressure
\n Ready False Thu, 24 Oct 2024 04:45:10 +0000 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni config uninitialized
\nEvents:
\n Type Reason Age From Message
\n —- —— —- —- ——-
\n Warning EvictionThresholdMet 5m kubelet Threshold observed at memory.available=482Mi, boundary=500Mi<\/p>\n

The sun is coming up. Or maybe it\u2019s going down. I can\u2019t tell because the blinds are drawn and the only light in this room comes from a 32-inch monitor displaying a wall of red text and a terminal window that looks like a crime scene. My hands are shaking, not from caffeine\u2014though I\u2019ve consumed enough cold espresso to stop a horse\u2019s heart\u2014but from the sheer, unadulterated adrenaline of watching 4,000 nodes commit collective suicide because of a single character error in a ValidatingWebhookConfiguration.\n\nYou might be asking **what is** the point of all this abstraction? Why do we subject ourselves to this? We took the relatively simple problem of running a binary on a server and wrapped it in fourteen layers of YAML, virtual networking, and distributed consensus algorithms until it became a sentient beast that hates us. \n\nKubernetes version 1.30 was supposed to be "stable." They talked about "Structured Authentication" and "Node Log Query." They didn't talk about how, when the admission controller goes dark, the API server starts choking on its own tongue, and the entire control plane turns into a circular firing squad.\n\n## The Control Plane: The Brain That Forgets\n\nThe Control Plane is marketed as the "brain" of the cluster. In reality, it\u2019s a collection of anxious bureaucrats who refuse to talk to each other unless they have a signed certificate and a 200 OK response. At the center sits `kube-apiserver`. It is the only thing that talks to the database. Everything else\u2014the scheduler, the controller manager, your frantic `kubectl` commands\u2014is just a client.\n\nWhen the outage hit at 3 AM three days ago, the `kube-apiserver` wasn't just failing; it was screaming. A misconfigured admission controller\u2014a piece of code meant to "validate" objects before they are persisted\u2014was pointing to a service that didn't exist anymore. Because the webhook was set to `failurePolicy: Fail`, the API server stopped accepting *any* pod updates. \n\n[INTERNAL MONOLOGUE: Why did we let the junior dev touch the webhooks? Why did I approve the PR? I was thinking about lunch. I was thinking about a sandwich while I signed the death warrant for our production environment.]\n\nIn v1.30, the API server is more "efficient," which just means it fails faster. When the webhook timed out, the request latencies spiked. The `kube-controller-manager` noticed the nodes weren't reporting in because their status updates were being rejected by the same broken webhook. It did what it was programmed to do: it assumed the nodes were dead and started rescheduling 10,000 pods. But it couldn't create the new pods because\u2014you guessed it\u2014the webhook was failing.\n\nHere is the `ResourceQuota` we had in place, which did absolutely nothing to stop the cascading failure because the failure happened before the quota was even checked:\n\n```yaml\napiVersion: v1\nkind: ResourceQuota\nmetadata:\n  name: compute-resources\n  namespace: production\nspec:\n  hard:\n    requests.cpu: "200"\n    requests.memory: 500Gi\n    limits.cpu: "400"\n    limits.memory: 800Gi\n    pods: "1000"\n    services: "50"\n    replicationcontrollers: "20"\n    resourcequotas: "1"\n<\/code><\/pre>\n
The Control Plane is a lie. It\u2019s a series of loops. The “Reconciliation Loop” is just a fancy way of saying “I\u2019m going to keep trying to do this thing until I die or the universe ends.” When the state in etcd<\/code> doesn’t match the state on the ground, the controllers panic.<\/p>\n
\n
Table of Contents<\/p>\n