Kubernetes Felt Easier Once I Understood These Basics

I haven't actually deployed Kubernetes in any real project yet, same as most of what I know about .NET software design: watched, understood, not yet applied. But the basics stopped feeling like a wall of YAML once I had a mental model for what each piece is actually doing.

Pods, Deployments, Services, YAML files, ConfigMaps, Secrets, probes, clusters, and dozens of commands. As a junior .NET developer, I kept thinking: why would I need all of this just to run an ASP.NET Core API?

It got easier once I understood a few basic ideas.

Kubernetes runs containers

Kubernetes doesn't build my C# application. First it needs to be published and packaged inside a Docker image:

ASP.NET Core API
→ Docker image
→ Kubernetes

If the application doesn't work inside Docker, Kubernetes won't fix it.

Pods run the application

A Pod is where a container runs. One Pod can contain one instance of an ASP.NET Core API.

Pods are temporary. They can be deleted, restarted, or replaced, so nothing important should live inside one. The database, sessions, and important files belong outside the Pod.

Deployments manage Pods

A Deployment describes how many instances of an application should be running:

spec:
  replicas: 2

If one Pod crashes, Kubernetes creates another one to replace it. That's the core idea: you describe the desired state, and Kubernetes tries to maintain it.

Services expose the application

Pods can change IP addresses when they're recreated. A Service gives the application a stable address and routes requests to whichever Pods are available:

Client
→ Service
→ Pod
→ ASP.NET Core API

Without a Service, clients would need to know the address of each individual Pod.

Configuration should be external

Connection strings and environment settings shouldn't be hardcoded into the image. ConfigMaps and Secrets handle that instead, and ASP.NET Core reads them as environment variables:

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

That's what lets the same container image run in development, testing, and production with different settings.

Health checks matter

Kubernetes can check whether an API is healthy. A readiness probe asks whether the application can receive traffic. A liveness probe asks whether it's still running correctly. ASP.NET Core exposes that through a health endpoint:

builder.Services.AddHealthChecks();

app.MapHealthChecks("/health");

Kubernetes uses that to decide whether a Pod should get traffic or be restarted.

The commands that matter most

The handful of kubectl commands that come up constantly in every walkthrough:

kubectl get pods
kubectl get services
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl apply -f deployment.yaml

The debugging flow is almost always the same: get pods, then describe pod, then check logs.

Where I'm actually at with this

I understand the mental model: Docker packages the application, Pods run it, Deployments manage the Pods, Services expose them, ConfigMaps and Secrets handle configuration, probes check health. What I don't have yet is a real project actually running on Kubernetes. It's the same gap I have with a lot of software design concepts: understood well enough to explain, not yet something I've had to make work under real conditions. That's next.