CFN Cloud
2025-10-02

Kubernetes Introduction: What It Solves and How to Think About It

A practical introduction to Kubernetes: what problems it solves, what it does not solve, and how desired state and controllers work in real clusters.

Kubernetes solves the problem of running services repeatedly and predictably across machines. It does not replace application design, product engineering, or operational judgment. The real value is not that it starts containers, but that it gives teams a consistent system for deployment, recovery, scaling, and change management.

What Kubernetes actually solves

  • Scheduling: placing workloads on nodes with enough resources.
  • Self-healing: restarting or recreating failed Pods.
  • Scaling: increasing or reducing replica count in a controlled way.
  • Service discovery: giving clients stable names even when Pods change.
  • Declarative operations: describing the desired state and letting controllers converge toward it.

What it does not solve

Kubernetes will not fix:

  • bad application architecture
  • poor database design
  • weak observability
  • unsafe release processes
  • code-level performance problems

It can make operations repeatable, but it cannot make an unhealthy system healthy by itself.

A practical mental model

The shortest useful definition is this:

Kubernetes is a declarative control system for running workloads.

That means you do not tell it every step to execute. You describe what the cluster should look like, and controllers keep trying to make reality match that description.

Why beginners usually get confused

The first confusing moment is rarely architectural. It is usually something much more ordinary:

  • a Pod is running but traffic does not reach it
  • a deployment says it updated but the new version is not healthy
  • a workload keeps restarting and you do not know why

That is why a good introduction to Kubernetes should start with evidence and state, not just diagrams.

The first commands worth trusting

When something feels wrong, I would start with:

kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl describe pod -n <ns> <pod>

Those four commands are often more useful than reading five more pages of theory.

Why desired state matters

Traditional operational thinking often sounds like this:

  • start the process
  • check the process
  • restart the process if needed

Kubernetes changes that model. Instead, you describe intent in YAML and let controllers keep driving the cluster toward that intent.

That is why kubectl apply changes the desired state, not the whole outcome by itself. The cluster still needs scheduling, image pulls, probes, networking, and traffic exposure to line up afterward.

What a simple workload teaches you

A very small lab is enough to learn the basics:

kubectl create namespace demo
kubectl apply -f app.yaml -n demo
kubectl get pods -n demo
kubectl describe pod -n demo <pod-name>
kubectl get svc -n demo
kubectl get endpoints -n demo <svc> -o wide

That loop teaches three important habits:

  1. check current state
  2. compare it to intended state
  3. follow the evidence instead of guessing

Common beginner misunderstandings

“Kubernetes is a PaaS”

Not really. It is an orchestration platform. You still need CI/CD, monitoring, security, and application-level design discipline.

“A Pod is like a small VM”

No. Pods are meant to be replaced. They are not long-lived pets.

“A Service is the app”

Also no. A Service is a stable network abstraction over a changing set of backends.

“Namespace means security isolation”

Namespace is mostly about organization and scope. Real isolation still needs RBAC, policy, and security controls.

A few operational habits that scale

  • keep manifests in version control
  • use consistent labels early
  • define resource requests once workloads stop being toy examples
  • collect logs and metrics before the first real incident
  • think about rollback before rollout

These habits are not glamorous, but they save more time than almost anything else.

FAQ

Q: Should I learn every Kubernetes object before touching a cluster? A: No. Learn enough to deploy one workload, then let real state and failure modes teach you the rest.

Q: What is the most important Kubernetes skill early on? A: Learning to read state: get, describe, events, and logs.

Q: When does Kubernetes start making sense? A: Usually when you stop asking only “what command should I run” and start asking “what state does the cluster think it should be in”.

Next reading

  • Continue with kubernetes-quickstart-basics.md for the first object model.
  • Read kubernetes-quickstart-architecture.md to understand who actually makes decisions.
  • Then move into kubernetes-quickstart-pod.md and kubernetes-quickstart-service.md to connect workloads and traffic.

Wrap-up

The fastest way to get useful with Kubernetes is not memorizing more terms. It is learning to follow the evidence chain from intended state to actual state. Once that habit lands, most “mysterious” Kubernetes problems become much less mysterious.

References

View original