Docker and Kubernetes: What Really Breaks in Production and How to Go from docker run to a Managed Cluster

Friday, 6:40 PM. The deployment that worked yesterday fails at the rollout stage. The application starts, but a minute later it receives SIGTERM and restarts in a loop. The logs are empty because the container doesn't have time to write anything. It takes an hour and a half to figure out: the Deployment manifest lacks a readinessProbe, and the load balancer is sending traffic to a pod that hasn't yet established a connection to the database.

It's exactly these stories — not about YAML syntax, but about system behavior under load — that separate someone who has "read about Kubernetes" from someone you can hand the on-call shift to. The course Docker and Kubernetes builds a path from the first docker run to a production cluster, but let's first honestly break down what really matters in this field and what's a myth. For a deeper dive into this topic, see Kubernetes builds](/en/blog/cloud-native-microservices-kubernetes-and-cloud-technologies-who-this-path-fits-and-who-it-will-frustrate).

Why containers won in the first place, and not just "became trendy"

The mechanism is simple and worth remembering, because most problems stem from it. A container is not a "lightweight VM." It's a process on the host, isolated by Linux kernel features: namespaces create the illusion of a separate filesystem, network, and process list, while cgroups limit CPU and memory. The kernel is shared. For a deeper dive into this topic, see DevOps and Cloud Infrastructure.

All consequences follow from this:

• A container can't be "a slightly different kernel" — if your application depends on a specific kernel version or module, a container won't help.
• Isolation is cheaper than virtualization, so dozens of containers can comfortably live on one machine — but a "noisy neighbor" on CPU is also possible if limits aren't set.
• An image is layers, and how you write your Dockerfile determines whether the build takes 20 seconds or 6 minutes, and how much space it eats in the registry.

Breaking down one task: how a deployment turns into 40 minutes instead of 4

Let's take a typical situation. There's a Go backend with gRPC and a frontend, plus Postgres and Redis. The team deploys manually: builds the image on a laptop, pushes to the registry, SSHes into the server, runs docker compose up -d. It works for months until the moment scaling is needed. For a deeper dive into this topic, see Production ML (MLOps).

Here's what happens next, step by step, and where exactly it breaks:

1. Build. The Dockerfile is written naively: FROM golang:1.22, copy the whole project, go build, run. Every edit to the README invalidates the cache, and the build takes 4–6 minutes instead of 30 seconds. A multi-stage build that copies go.mod and go.sum first, then the code, solves this: dependencies are rebuilt only when they change.
2. Image size. The final image based on golang weighs about a gigabyte. A multi-stage build with a final FROM scratch or gcr.io/distroless/static yields tens of megabytes. The difference isn't cosmetic: a smaller image means faster pull on the node, faster startup during autoscaling, and a smaller attack surface (no shell, no package manager).
3. Configuration. Database passwords sit in docker-compose.yml and end up in git. Then it's either a move to environment variables and Secrets in Kubernetes, or one day those credentials leak along with the repository.
4. State. Postgres in a container with data inside the layer is a classic. With docker compose down and no named volume, the data disappears. In Kubernetes, databases need a StatefulSet with a PersistentVolumeClaim, and that's a separate conversation: stateful workloads in a cluster require understanding how a PV binds to a node and what happens if the node is lost.
5. Rollout. Manual SSH deployment offers no rollback. In Kubernetes, a Deployment with strategy: RollingUpdate and proper readinessProbe gives zero-downtime updates, and kubectl rollout undo reverts to the previous version in seconds — but only if you haven't forgotten about revisionHistoryLimit and haven't overwritten the image with the latest tag. For a deeper dive into this topic, see Data Engineering (Spark, dbt).

This breakdown shows that "Docker and Kubernetes" aren't two independent skills but one path: first you learn to build a predictable image, then to run and update it predictably. You can skip the first part and jump straight into the cluster, but then Dockerfile-level mistakes will surface in production, where they're more expensive to fix. For a deeper dive into this topic, see CI/CD as an Art.

Where the line between "knowing" and "being able to" actually lies

Most self-taught developers confidently write Dockerfiles and can run kubectl apply. Problems start in three places that almost never appear in tutorials.

First — networking. How does a Service find pods? Through selectors and Endpoints, and inside the cluster through kube-proxy and iptables/IPVS. While everything works, this doesn't matter. When traffic goes to the wrong place, you need to understand that ClusterIP is a virtual address, not a pod address, and that Ingress is just a routing rule backed by a controller (nginx, Traefik) that must be configured and updated separately.

Second — resources. Without requests, the scheduler doesn't know where to place a pod and may pack everything onto one node. Without limits, one container eats the host's memory, and the OOM-killer comes for its neighbors. A typical mistake is setting limits equal to requests "just in case": this guarantees CPU throttling and kills latency.

Third — observability. Prometheus metrics and Grafana dashboards don't appear by themselves. The application must expose /metrics, the ServiceMonitor must find it, and alerts on error rate and latency must be set up before an incident, not after. In my experience, this layer is most often postponed "for later" — and it's exactly what turns a night incident from two hours into ten minutes.

Helm deserves a separate mention. Charts solve the problem of "ten similar YAMLs with different values" but add their own: Go template templating easily turns into an unreadable 400-line values.yaml. The rule is simple: if a chart is used in one place and isn't parameterized, you don't need it — plain manifests and Kustomize will do.

Entry paths: three scenarios and their cost

Here we should talk not about "which course is better" but about "which path fits your situation." The difference lies in the cost of a mistake.

Self-guided path. Free materials, official documentation, your own cluster on a laptop. Pros — cheap and at your own pace. Cons — you don't know what you don't know: a typical self-taught developer goes through Docker, writes a couple of manifests, and stops because what follows is boring (RBAC, backup, upgrade) and unclear (what even counts as "correct"). There's no feedback, and mistakes are visible only when something breaks.

Course. Provides structure and covers typical pitfalls you won't encounter until you step on them. The cost is time and money; the gain is speed and fewer expensive mistakes in production. It's important to check whether there's hands-on practice and feedback, not just theory.

Working in a team with a mentor. The fastest path, but it depends on whether you've landed on a team where explaining is the norm, not just "look in Confluence."

The topic is adjacent to architecture: if you're already thinking about microservices, queues, and observability, it's worth looking at Microservices Architecture in Practice — there you can see how infrastructure decisions affect application structure, not the other way around. For a deeper dive into this topic, see Terraform Prompts That Think Like an SRE.

Who this path suits and who it doesn't

Honestly: Docker and Kubernetes are not a universal skill "for everyone in IT."

It suits you if you:

• deploy or will deploy services and are tired of "it works on my machine";
• are moving into DevOps/SRE/platform engineering — here it's the basic language;
• are a backend developer who needs to understand what happens to the application after git push;
• want to manage cloud infrastructure consciously rather than copy manifests from chat.

It doesn't suit you if you:

• are looking for a "quick entry into IT from scratch" — this requires a foundation in Linux, networking, and the command line;
• work in frontend and don't touch deployment — understanding at the level of "the image is built in CI" is enough;
• need only one tool for a specific task (e.g., run a database locally) — Docker and a couple of hours will suffice.

A separate note on autoscaling: HPA, VPA, and KEDA are the next level after basic Kubernetes, and they have their own forks. If you already deploy confidently but don't understand why pods don't scale under load, it's worth exploring separately — how to choose between HPA, VPA, and KEDA without breaking production.

What changes over time and why "learn once" doesn't work

Kubernetes is a fast-moving target. API versions become obsolete, deprecated resources are removed, tools swap places. The practical takeaway: learn not a "list of commands" but the model — declarativeness, the reconciliation loop, controllers. Then a cluster version upgrade won't be a catastrophe.

Another observation from practice: LLM assistants have greatly simplified drafting manifests and reading others' charts. But they're also dangerous — they confidently generate apiVersions that are already removed, or resources that don't match the actual load. AI assistance is an accelerator, not a replacement for understanding. If you want to see how this works in practice, there's a separate piece on CI/CD Without Surprises, and a collection of From CrashLoopBackOff to a Working Helm Chart. For a deeper dive into this topic, see From Dockerfile to Debugging Pods.

How to choose a path for your situation

A short algorithm that will save you months:

1. Do you have a real task? If yes, start with it: package your application into an image, get it to Compose, then move it to a local cluster. Theory without a task is forgotten in a week.
2. Is there feedback? If there's no one to say "you're doing it wrong here," a structured course fills exactly that gap — not knowledge, but correction.
3. Are you ready for the boring part? RBAC, backup, upgrade, image security — these aren't about the wow effect but about the cluster living for years. If not, limit yourself to Docker and Compose and don't take on a cluster.
4. Test in practice. Any path is only as good as your ability afterward to deploy, update, and roll back a service without hints.

Finale

Containerization and orchestration are an area where the cost of ignorance shows up not in a grade but in night incidents and manual deployments. The good news: the path here is predictable — image, Compose, cluster, Helm, CI/CD, monitoring — and at each step there are typical pitfalls best seen in a learning environment rather than in production.

The course Docker and Kubernetes covers exactly these steps in practice: from Dockerfile and multi-stage builds to Helm, GitOps, and managing a production cluster, with personalized lessons for your level — so you don't skip the basics or get stuck on the obvious. For a deeper dive into this topic, see ITIL 4 Managing Professional (MP).