Defining Pods through Declarative Syntax

Pods as a wrapper to containers#

Even though a Pod can contain any number of containers, the most common use case is to use the single-container-in-a-Pod model. In such a case, a Pod is a wrapper around one container. From Kubernetes’ perspective, a Pod is the smallest unit. We cannot tell Kubernetes to run a container. Instead, we ask it to create a Pod that wraps around a container.

Looking into a pod’s definition#

Let us look at a simple Pod db.yml definition.

Let’s analyze the various sections in the output definition of a Pod.

• Line 1-2: We’re using v1 of Kubernetes Pods API. Both apiVersion and kind are mandatory. That way, Kubernetes knows what we want to do (create a Pod) and which API version to use.

• Line 3-7: The next section is metadata. It provides information that does not influence how the Pod behaves. We used metadata to define the name of the Pod (db) and a few labels. Later on, when we move into Controllers, labels will have a practical purpose. For now, they are purely informational.

• Line 8: The last section is the spec in which we defined a single container. As you might have guessed, we can have multiple containers defined as a Pod. Otherwise, the section would be written in singular (container without s). We’ll explore multi-container Pods later.

• Line 12: In our case, the container is defined with the name (db), the image (mongo), the command that should be executed when the container starts (mongod)

• Line 13: Finally, the set of arguments. The arguments are defined as an array with, in this case, two elements (--rest and --httpinterface).

We won’t go into details of everything you can use to define a Pod. Throughout the course, you’ll see quite a few other commonly (and not so commonly) used things we should define in Pods. Later on, when you decide to learn all the possible arguments you can apply, explore the official, and ever-changing, Pod v1 core documentation.

Let’s create the Pod defined in the db.yml file.

You’ll notice that we did not need to specify pod in the command. The command will create the kind of resource defined in the db.yml file. Later on, you’ll see that a single YAML file can contain definitions of multiple resources.

Let’s take a look at the Pods in the cluster.

The output is as follows.

Our Pod named db is up and running!

In some cases, you might want to retrieve a bit more information by specifying wide output.

The output is as follows.

As you can see, we got four additional columns; the IP, NODE, NOMINATED NODE and READINESS GATE.

If you’d like to parse the output, using json format is probably the best option.

The output is too big to be presented here, especially since we won’t go through all the information provided through the json output format.

When we want more information than provided with the default output, but still in a format that is human-friendly, yaml output is probably the best choice.

Just as with the json output, we won’t go into details of everything we got from yaml. With time, you’ll become familiar with all the information related to Pods. For now, we want to focus on the most important aspects.

Let’s introduce a new kubectl sub-command.

The describe sub-command returned details of the specified resource. In this case, the resource is the Pod named db.

The output is too big for us to go into every detail. Besides, most of it should be self-explanatory if you’re familiar with containers. Instead, we’ll briefly comment on the last section called events.

The above output may appear a bit different and take some time to show up in its full form.

We can see that Pod was created. Even though the process was simple from a user’s perspective, quite a few things happened in the background.

For your ease, all the commands used in this lesson are also given below.