Containers, Kubernetes and infrastructure as code

The interviewer asks how you pack your service, keep the right number running, and build servers the same way every time. A weak answer is a list of tool names. A strong answer says what problem each part solves. At SDE-3 level you should also say when this is too much.

Think about a shipping container. Cranes, ships and trucks all handle the same box, whatever is inside. A software container is the same idea.

A container is your program packed with the files and settings it needs, running alone on a shared machine. It shares the operating system core of its machine, so it starts in seconds. A virtual machine (lesson 13) carries a whole operating system of its own, so it is heavier. An image is the fixed package that one build makes. A container starts from an image, and one image can start many containers. The same image runs in testing and live. Servers set up by hand differ, as server 3 did in lesson 94. Images do not.

Kubernetes runs containers on a group of machines, called a cluster. A node is one machine in it. These are its main parts:

• A pod is the smallest unit that Kubernetes runs: one or more containers that share one address. A pod is disposable, and a replacement has a new address. Keep no data in a pod (lesson 26).
• A Deployment is your wish: "run 6 pods from this image". Kubernetes keeps comparing the pods that exist with your wish. If a pod is lost, it starts another. If you name a new image, it replaces pods in batches (a rolling release, lesson 95) and can go back.
• A Service is one steady address in front of changing pods. It shares requests among them, like the load balancer of lesson 28. A pod gets requests only when its readiness check, the health check of lesson 28, passes.

A Deployment can set a memory limit for each container. If a container uses more, the system stops it (an out-of-memory kill). Kubernetes then starts the container again in the same pod.

Infrastructure as code means you write servers, networks and databases in text files, kept and reviewed like code. A tool reads the files and compares them with what exists. It prints a plan, which is the list of changes, such as Plan: 1 to add, 0 to change, 1 to destroy. Then it applies the plan. Terraform is one such tool. A change made by hand makes the real system differ from the files. This is drift, and the next plan shows it.

The food-ordering app has a checkout service.

Assumptions (made up to teach with): peak load is 420 requests per second. One pod handles 100 per second at full load. We plan for 70% busy.

Step 1: how many pods. One pod at 70% handles 100 x 0.7 = 70. Pods = 420 / 70 = 6.

Step 2: the memory growth. The pod stops when memory reaches 1,000 MB. The growth is 1,000 - 300 = 700 MB, and 700 / 100 = 7 hours. This answers the predict box. Kubernetes starts the container again from the same image, with memory back at 300 MB. Requests on it fail. If we raise the limit to 2,000 MB, the pod lasts (2,000 - 300) / 100 = 17 hours. The leak is still there.

• Containers and Kubernetes solve one package everywhere and the right number of pods kept running. They cost a cluster to run and more steps when something breaks. I would use plain servers for one small service on two or three of them.
• Infrastructure as code solves servers that are the same and reviewed. It costs files to write and keep. I would start with the parts that you must rebuild fast.

"A container is a small virtual machine." A container shares the operating system core of its machine. A virtual machine has its own.

"Kubernetes restarts the container, so a memory leak is handled." The restart hides the leak. Users still see errors, and the cause stays.

1. Say in one line what each one is: image, pod, Deployment, Service.
2. A service peaks at 900 requests per second. One pod handles 150 per second at full load. We plan for 70% busy. (a) How many pods? (b) A pod starts at 200 MB, grows 50 MB an hour, and has an 800 MB limit. After how many hours does it stop?
3. The plan says Plan: 0 to add, 0 to change, 1 to destroy. The resource is the database. What do you do?