Part III : Like Peas in a (Kubernetes) "Pod"

Have you ever wondered about the fact that everything, no matter how complex, is made up of something very basic? Like, you know, for example, the Science folks will talk about how atoms and molecules constitute matter. Or maybe, they'll tell you all living beings are just carbon.

But I, ladies and Gentlemen, am a computer nerd. So, I'm going to say a piece of software is just code which just boils down to a bunch of zeros and ones.

Seems like almost everything has some basic constituent unit. And since we're on this topic, let me tell you Kubernetes too has a basic unit. Behold:

"The Pod"

And we are dedicating this entire post to it.

(Duh, that's why we had this whole "basic unit" build up after all!)

Oh and before you proceed do give our previous post, the Kubernetes Dictionary, a read if you still haven't.

So...What's A Pod?

I googled the meaning of "Pod". These are a  few definitions that came up:

An elongated seed vessel of a leguminous plant such as the pea, splitting open on both sides when ripe.

A detachable or self-contained unit on an aircraft, spacecraft, vehicle, or vessel, having a particular function.

A small herd or school of marine animals, especially whales.

Now my technical brain (currently full of the Kubernetes material that I read through for this blog) tells me that a pod is a Kubernetes exclusive thing. You know the basic unit in Kubernetes and all that.

In reality. None of us (the dictionary definitions and my brain) are wrong! If I had to explain the concept of a "POD" in the Kubernetes context, I'd say it's actually a mix of a few things borrowed from each of the definitions.

A pea pod holds peas together. A pod is also a group of whales. Likewise, a pod is a group of one/more Containers.

A pod in an aircraft/spacecraft is "self-contained" and has a particular function. The same goes for a Kubernetes pod. It's self-contained and performs one particular function.

See if you want to get work done on a Kubernetes cluster, you have to create a Pod.  Want to run a web service? Pod! Want a process running in the background? Pod! So you can say to run any application, you need a pod.

Why a Pod? Why not Containers?

Containers run applications. So why did Kubernetes get the concept of the "pod" into the picture? Why not use a Container itself?

Because there's more to a Pod than just saying "a group of one/more containers". And the answer lies in the word "self-sufficient".

A pod doesn't just run a container, it gives you all the "accessories". Running your application code isn't enough sometimes right? You need things like networking, storage, and a particular environment that's suitable for it.

A pod has all of this in place.  Look at the image below and you'll know

You got networking capabilities like giving a pod an IP address.

Then you got the restart policy. What to do if the container fails/crashes/terminates unexpectedly. Restart the container maybe? This is given by the Restart Policy.

And finally, you have container probes. More on that later in this post

Multi-Container Pods

Okay, most of the time... Wait, Scratch that.

Maximum Number of times, a pod is going to have one single container running within it. Now, I know, you'll complain. Didn't I just say a pod can have multiple containers? Yes, that's absolutely possible. But it's not that widely used.

This sort of situation is called a "multi-container" pod. Usually, if you have containers that are tightly coupled, (ie They depend on each other a bit too much) then going for a multi-container pod makes sense.

A simple example, you have a script within a container that creates random jokes and writes them to a shared file "my-awesome-jokes.txt". Another container, say the joke web service reads this file when an HTTP request comes in and sends one joke as a response. Look here both of share the "my-awesome-jokes.txt" file. And our web service depends on the joke-producing container. Now that's a tightly coupled system of containers that are put in a single pod.

Life of Pod (not Pi)

Let me tell you about the eventful life of one of our dear pods. Here goes. Read carefully, okay?

Pending State

Our pod walked up to the cluster door because he wanted work. There was always some work that had to be done on the cluster. But first, the cluster scheduler (we'll tell you about this guy later) had to decide which node to assign our pod to. That took some time. Meanwhile, our pod waiting in the lounge.

The Pending State is when the pod is accepted by the cluster but still hasn't been assigned to a particular node to run on. This also includes the time where the pod is pulling the container images

Running State

The wait was over! Our pod was assigned to a node and was ready to run. The containers too ran with our pod.

The Running State is when the pod is assigned to a node and one of its containers has started running or is (re)starting.

Success State

It was a great moment. Our pod had succeeded! And the credit went to all the containers who had completed their tasks successfully.

The Succeeded State is when all the containers successfully terminate and need not be restarted

Failed State

But there was one day when the pod failed. It was a sad day indeed. All the containers gave up on the pod and were terminated with failure.

The Failed State occurs when the containers terminate with failure or are terminated by the system due to some error

Unknown State

The Unknown state is when the state of the pod cannot be determined usually due to some communications failure

Container Probes

Think of a probe as a phone call. Like you are calling to check on a loved one and asking, "Hello is everything okay?". Now the answer can be "Yes. I'm fine" or maybe "No. Help me". Or in certain cases, "I don't know. Lot happening lately"

A probe is a phone call to the pod's containers. Just to periodically check if the containers are doing fine. And as a response, the container can either send a status of Success (Yeah), Failure (No) or Unknown (I don't know)

Usually, a Pod is said to be up and running when all of its containers have started. But in case a container fails during either startup or some time along the way, a probe will help in handling the situation.

Liveness Probe

A Liveness Probe will ensure if the container is "alive" or not. That's if the container is up and running ( which will also mean that the pod is running too). If it's alive, then no action is required. But if the container is "dead" or terminated, then, Kubernetes will take an action based on the pod's restart policy.

So, in other words, a liveness probe will help to decide when a pod needs to be restarted.

Readiness Probe

A Readiness probe will ensure if the container is ready to start accepting requests.

Like say if your pod has containers that run a web service, then a readiness probe will be helpful to know when the container can start accepting input requests. If the readiness probe returns a success, Kubernetes starts directing traffic to the pod and its container

Startup Probe

A Startup probe, like the name suggests, will check if the container has started or not. This can be used in cases where the container takes a while to start and get ready. Especially if there are a lot of tasks that take place on container startup.

What's Next?

Well, that's a lot on pods for today and for this blog. But hey, we're just warming up! It's one piece of the entire jigsaw puzzle that you have here. In the next post, we'll be talking about the role of the master node and its components. That's gonna be a crazy important post. So stay with us for a little while.

And oh, if you're wondering where the practical part of Kubernetes is, then hey! we got a separate series for that. Practical Kubernetes. This series will help you out to put all our Kubernetes concepts in practice. Because we know you are the tinkering kind.

See you soon! Ciao!