The Kubernetes Aquarium

Paywalled by Medium? Read this story on my blog.

This is an app.

It’s a whole functional unit on its own, but it can’t survive on its own. It needs a correctly provisioned environment.

This fish app in particular needs water in order to be able to live.

We could toss it in the ocean alongside all the other random apps and programs out there.

But it would have to compete for resources and deal with everything else in the ocean.

It doesn’t have its own dedicated space and resources.

This is why we containerize.

Using a tool like Docker, we can provision containers for our apps to separate them and give them their own environment.

This is a Pod, the basic building block of Kubernetes.

It’s just a box in which we place our containerized app. It’s given a label so that Kubernetes knows what it is and how to reference it.

Now that our fish is safely provisioned in Pod, it is able to be managed by the Kubernetes aquarium.

Sometimes, apps need resources, like memory and CPU.

Here, our fish tank container requires 60W of power to use its water filter.

There are different rooms in the aquarium that we could put the tank.

Here, this first room here has no more resources available — both power outlets are already in use.

This second room has outlets available, but the room lets us know its outlets only provide 40W of power, and we need 60 watts for our fish tank.

These rooms are Nodes in our Kubernetes cluster — workers on which pods are running.

Kubernetes is the aquarium director.

It knows which rooms it has, what resources they have, and decides where to put the new fish tank based on all this information.

Without any other constraints, they will default to placing tanks across all rooms evenly.

We’re typically not dealing in a single fish in a single tank. More frequently, the aquarium director is putting together an exhibit — a collection of tanks that all go together.

Here, the Deep Sea exhibit is made up of some anglerfish tanks, some jellyfish tanks, and the giant squid tank. When they are created as part of an exhibit, we determine how many of each container to create.

When designing the exhibit, we provide instructions for creating each item in the exhibit.

We detail how many of each tank we want, and how to create a new tank in case one needs to be fixed. We lay out how much to fill it, what temperature the water needs to be, how much food it gets.

Giving these instructions to the the Kubernetes aquarium director, they are then able to delegate the actual job of maintaining the right number of tanks of each app to someone else — the aquarium intern.

Their job is to make sure there’s always the right number of tanks on display at the aquarium. In Kubernetes speak, this intern that gets created along with the deployment is called a Replica Set.

The aquarium visitors don’t care if they’re looking at Fred the Jellyfish or Pearl the Jellyfish — they just want to see a jellyfish.

The intern switches out a jellyfish for a brand new one using the instructions provided when the jellyfish on display gets tired and needs a break.

In Kubernetes world, Replica Sets make sure that when Pods go down, a new one gets spun up to keep the correct number of pods available.

There’s another important consideration when designing your exhibit.

So far, for illustration purposes, we’ve been showing the Pods like this — a box in which we place the containerized app.

A more accurate depiction of the Pod would be this. From the outside, it’s just a Pod with some labels.

We can ask the Kubernetes aquarium director to tell us more about what’s inside, sure. But this isn’t very useful for us to put on display so that our users — the aquarium visitors — can see and interact with the app.

What we need is some way to allow the visitors to the aquarium a peek into the pod.

We need to expose some kind of window where they can access viewing the fish inside.

In the Kubernetes aquarium, the answer is a Service. Services have a few different roles, but a primary one is to expose a port in the container so that it is externally accessible.

Applying a service to our pods will let the aquarium visitors access the fish experience inside.

Services also serve the role of allowing Pods and containers to have access to one another.

If we want the fishes in two tanks to be able to exchange water and food back and forth, we can set up a service that allows this interaction.

A Network Policy is an additional kind of thing we can apply here.

Here, it’s a one-way valve that allows this fish tank to have water flow outwards, but not inwards.

A Config Map is a set of variables or values that a Pod needs in order to operate.

The fish needs a bin of food in order to operate. The devices get mounted on a container.

We also see transparent and opaque Config Maps — because they can contain either mundane or secret values.

There’s many more pieces to Kubernetes, but these are many of the basic building blocks that make up the aquarium and describe the choices made by its director.

Why did I make this aquarium analogy? Here’s the thing — Kubernetes has a lot of Things. So many nouns, which are things wrapped in things wrapped in things that overlap with things. It’s layered like an onion.

A lot of diagrams look something like this, explaining all the nouns that are covered here.

It’s technically accurate, but it’s not very helpful to me. Applying analogies like fishes and aquariums to a tech help me parse it all together in my head.

Anne LoVerso is a full-stack software engineer and consultant at VMware Pivotal Labs.