Kubernetes
Kubernetes (K8s)
What Is Kubernetes?
- Automatically deploys, scales, and recovers containers
- The control tower for the cloud era
- The standard for large-scale operations
Once you start using Kubernetes, an operator's job shifts from 'logging in to a server and typing commands' to 'writing the desired state in a file.' Declare '3 order API replicas, 1GB of memory, port 8080,' and a controller compares the actual state with your declaration every few seconds and closes the gap. Instead of a person dictating procedures, you write down the target, so when a container dies at 3 a.m., the system moves before the on-call engineer does. Incident response shifting from 'recovery work' to 'closing the gap' is the biggest change teams feel in practice.
The building blocks come in layers. The smallest unit, a bundle of one or two containers, is a Pod; the object that is responsible for keeping a set number of Pods running is a Deployment; and the object that distributes incoming connections is a Service. Autoscaling doesn't happen on its own either: it only works once you set a rule such as 'scale up to 10 replicas when CPU utilization exceeds 70%.' Many people confuse it with Docker, but Docker builds and runs containers, while Kubernetes schedules those containers across many servers, so they sit at different layers. Using a managed service such as EKS, GKE, or AKS instead of installing it yourself lets you hand the work of running the control plane over to the cloud provider.
The most common gap between expectation and reality is the belief that 'put Kubernetes on top and it won't go down.' Without proper health checks (liveness and readiness probes), it treats a Pod whose process is alive but not responding as healthy and keeps sending it traffic. If you leave resource requests and limits empty, one Pod can eat all the memory and drag down other Pods on the same node. An organization with only about ten containers that adopts it too early ends up needing more people to tend the cluster than to build the app. Running a stateful database as a Pod with little preparation is another common cause of incidents, and since each minor version is supported for only about a year, you also need a regular upgrade plan.
Seungtae ParkA hands-on AX instructor who teaches AI business development and marketing automation by building them in practice
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, helping non-specialists put AI to work right awayGoogle open-sourced it in 2014 based on its experience with its internal system 'Borg,' led by Joe Beda, Brendan Burns, and Craig McLuckie.
Let's look at a hypothetical case. Online retailer Company A (180 employees, KRW 120 billion (≈ US$89,780,000) in annual transaction volume) saw its order servers buckle during every major promotion. Because it doubled its hardware in advance, half its servers sat idle on normal days, yet at last year's year-end event the checkout page went down for 27 minutes. A four-person infrastructure team spent six months migrating to Kubernetes.
- Instead of migrating everything, the infrastructure lead started with three APIs: orders, payments, and product lookup. Saying 'If we move it all at once, we can’t roll back,' they sent only 15% of total traffic to the new cluster.
- Backend developers capped each Pod at 0.5 CPU cores and 1GB of memory. In the first week without limits, the settlement batch job consumed up to 8GB of memory and dragged down the product lookup API on the same node.
- The SRE lead reset the autoscaling rule to 'if CPU exceeds 65%, scale to up to 20 replicas within 30 seconds.' They had first set it at 90%, but scale-out couldn't keep up with traffic and the service stalled twice.
- Because the health check only looked for a simple response, pods that had lost their database connection kept registering as healthy. The dev lead summed it up: 'Let's switch to a check that actually probes the database,' and the readiness probe was rewritten.
- Six months later, during a promotion, Pods scaled from 6 to 19 within 8 minutes at peak and the company got through without downtime. Average server count dropped 40%, and monthly infrastructure cost fell from KRW 23 million (≈ US$17,200) to KRW 14.5 million (≈ US$10,800).
- When you run many containers and scale often
- Large-scale, high-availability services
- When you need automated placement and recovery
- Small services (unnecessary complexity)
- When you lack operations skills or staff
- When simple deployment is enough