Kubernetes Isn't as Hard as You Think
Translated from the original Korean post. 한국어 원문 보기 →
Why Kubernetes, and why now
I revisited Kubernetes recently while moving a legacy server environment into containers. Docker I already knew cold. What I doubted was why I needed another heavy layer on top of it. If you're running a handful of containers, isn't docker run the whole story? I held that position for a while.
The answer turned out to be boring. Managing one container and managing dozens are not the same problem. With one, you start it by hand and kill it by hand. Once you hit dozens, you can no longer track with your own eyes which container died, where traffic should go, or how many more to spin up when load spikes. Kubernetes exists to solve that one problem: scale.
What Kubernetes absorbs isn't containers. It's the operator's attention.
Right now 77% of organizations are expanding their container usage, and Kubernetes has locked in the standard spot for container orchestration. As of 2026 it's hard to sketch a cloud native infrastructure diagram without it. Like it or not, you'll run into it eventually.
So what is it, exactly
Kubernetes (K8s for short) is an open source platform that automatically deploys, scales, and manages containerized applications. The name is Greek for helmsman, or captain. The thing that steers the ship safely to port.
Google open sourced it in 2014, and it didn't appear out of nowhere. It's built on operational experience from Borg, the internal system Google used to run containers by the billions. Meaning it started life chewing on the question of how to run things at massive scale. Once I understood that lineage, the shape of the architecture started to make sense.
The list of things Kubernetes does for you is short. It decides where a container should land and deploys it. It watches application state and rebuilds anything that dies. It scales the count up or down with traffic. It handles networking and load balancing between services. It keeps configuration and secrets separate. Five lines. The catch is that doing those five lines by hand across dozens of containers is an all-nighter you'll still lose.
A food delivery analogy gets you there fast. A system that adds and removes couriers based on order volume, instantly backfills when a courier drops out, and routes food along the fastest path. That's exactly what Kubernetes does, with containers instead of couriers. It keeps running without anyone babysitting it.
How infrastructure got here
To understand why Kubernetes looks the way it does, it helps to see the road that led to it.
| 시대 | 특징 | 장점 | 단점 |
|---|---|---|---|
| 물리 서버 | 서버 1대에 앱 1개 | 안정성, 성능 | 자원 낭비, 확장성 제한 |
| 가상화 | 서버 1대에 VM 여러 개 | 자원 효율성 증대 | 무거운 OS, 느린 시작 |
| 컨테이너 | 가벼운 애플리케이션 패키징 | 빠른 시작, 이식성 | 대규모 관리 복잡성 |
| 쿠버네티스 | 컨테이너 오케스트레이션 | 자동화, 확장성, 안정성 | 초기 학습 곡선 |
Each stage inherited the homework the previous one left behind. Physical servers idled entire boxes. Virtualization sliced them up, but every slice dragged a full OS along and stayed heavy. Containers fixed packaging and startup time, and then those containers multiplied into the hundreds, which produced a brand new problem called management. Kubernetes is the upper floor that only became necessary once containers were everywhere.
The architecture
A cluster splits into two halves. The head, and the part that does the actual work.
Control Plane
The brain of the cluster. Every request comes in through a single door called the API Server, and all cluster state piles up in a database called etcd. The Scheduler decides which node a new Pod lands on. The Controller Manager watches nonstop to see whether the desired state still holds, and corrects the drift when it doesn't.
That idea — the Controller Manager keeping the desired state — is the whole philosophy of Kubernetes. You just declare "this is how it should look." The system compares that to reality and closes the gap. This structure, the control loop, is the root of self healing.
Worker Node
Where your applications actually run. kubelet is the agent responsible for running containers, sitting on every node. kube-proxy handles networking. Underneath, the Container Runtime (usually containerd) is what actually starts the containers.
Pod: the smallest unit
Pod is the first concept you need to understand in Kubernetes. It's also where most beginners trip. Kubernetes doesn't deploy containers directly. It wraps a container in a shell called a Pod and deploys that.
A Pod usually holds exactly one container. That's the common case. Containers inside the same Pod share networking and storage, and the Pod itself gets one unique IP address. It's also ephemeral. It gets deleted and recreated at any time.
Why wrap it instead of using the container directly? So that containers which need to stay glued together can be handled as one unit. If a web application and the collector scraping its logs must always live in the same place, you put them in the same Pod and manage them as one body. The fact that a Pod dies and is reborn at will keeps coming back in the Service and scaling sections, so it's worth parking that fact here.
The pieces
The workload type you'll use most is the Deployment. It manages stateless applications, creating and replacing Pods automatically. When a Pod dies, the Deployment brings up a new one on its own, which is why in practice almost everything you ship goes through a Deployment.
Service: the network entry point
Pods are ephemeral, so their IPs keep changing. The Pod you were just talking to might come back at a different IP a moment later. That's why you never hardcode a Pod IP. A Service stands in front of these fickle Pods as a fixed entry point. ClusterIP if you only need reachability inside the cluster, NodePort if you want to open a specific port on a node for outside traffic, LoadBalancer if you want to hook into your cloud provider's load balancer.
Config and data
Application configuration lives outside the code. Ordinary settings go in a ConfigMap, sensitive things like passwords and API keys go in a Secret. That's not for tidiness. It's so you can ship the same image to dev, staging, and production and swap only the per-environment values. No rebuilding an image per environment — that's the part you actually feel on the job.
Containers are stateless by default. When one dies, the data inside it goes with it. But some things, like databases, have to keep their state. That's when you attach a PV (Persistent Volume) to decouple data from the container's lifecycle.
kubectl: how you talk to Kubernetes
kubectl is the CLI you use to throw commands at the cluster. Think of it as your mouth when talking to Kubernetes. The commands you'll actually use:
# 리소스 조회
kubectl get pods
kubectl get services
kubectl get deployments
# 자세한 정보 확인
kubectl describe pod my-pod
kubectl logs my-pod
# 리소스 생성/수정
kubectl apply -f app.yaml
kubectl create deployment nginx --image=nginx
# 스케일링
kubectl scale deployment my-app --replicas=5
# 디버깅
kubectl exec -it my-pod -- bash
Early on, getting get, describe, and logs into your fingers covers half the job. When something breaks, what a human actually does is look at state, look closer, then read the logs. On repeat.
The secret to scaling
There's one principle worth nailing down about scaling. You don't cram more containers into a Pod. You add more Pods.
Say traffic spikes. Stuffing three containers into one Pod is the wrong direction. Running three Pods with one container each is the right one. This is horizontal scaling, and it's where Kubernetes gets its elasticity. Pods being ephemeral and replicable as identical units leads straight to a dead simple strategy: stamp out more copies and split the load.
Set up an HPA (Horizontal Pod Autoscaler) and it adjusts the Pod count on its own based on CPU or memory usage. Traffic drops at 3am, scale down. Traffic piles up midday, scale up. Making capacity track demand without a human watching is the entire point of the tool.
Kubernetes in practice
As of 2026, the places Kubernetes sits at the center are fairly settled. It underpins inter-service communication, deployment, and management in microservice architectures. In CI/CD pipelines it pairs with GitOps to automate delivery. Cloud native applications inherit the cloud's elasticity directly. In hybrid and multi-cloud setups, it's the layer that makes several clouds behave as one.
Large AI services like ChatGPT are handling traffic on Kubernetes internally too. The harder a service's load is to predict, the more you see it converge on this shape.
Getting started
If you want to poke at it locally, there are low-commitment paths. Spin up a single-node cluster with Minikube and practice. Use K3s, the lightweight distribution. Or if you already have Docker Desktop installed, just turn on the built-in Kubernetes feature. That third one was the laziest and the fastest for me.
Production is a different conversation. Most people use a managed service rather than building a cluster themselves, because running the Control Plane is a job unto itself. AWS EKS, Google GKE, Azure AKS, Naver Cloud Platform NKS — pick whichever matches the cloud you're already on.
Kubernetes looks complicated at first because the vocabulary arrives all at once. Follow the concepts one at a time and you find they sit on a surprisingly consistent logic. One principle — declare it and the system reconciles it — runs through everything from Pods to scaling to self healing.
You don't need to memorize every component to get started. Hold onto the big picture, that the machine takes over the parts a human can't track once scale kicks in, and you'll fill in the rest as you need it.
Though looking at how much I just wrote under a title claiming this isn't hard, I'm no longer sure that title holds up.
Was this post helpful?
One click helps me write the next one