Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# Pods as wrappers for 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's look at a simple Pod `db.yml` 
 definition:

apiVersion: v1
kind: Pod
metadata:
  name: db
  labels:
    type: db
    vendor: MongoLabs
spec:
  containers:
  - name: db
    image: mongo:3.3
    command: ["mongod"]
    args: ["--rest", "--httpinterface"]

Let's analyze the various sections in the output definition of a Pod:

* **Lines 1--2:** We use `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.

* **Lines 3--7:** The next section is `metadata`. It provides information that does not influence how the Pod behaves. We use `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 define a single container. We can have multiple containers defined as a Pod. Otherwise, the section would be written in the 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`), and the command that should be executed when the container starts (`mongod`).
* **Line 13:** Finally, this is 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 about of everything you can use to define a Pod. Throughout the course, you'll see quite a few other common (and not so common) used things we should define in Pods. Later on, when you decide to learn all the possible arguments you can explore the official and ever-changing, [Pod v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#pod-v1-core) documentation.

Let's create the Pod defined in the `db.yml` file:


Learn to create Pods using declarative syntax. 

Defining Pods through Declarative Syntax

Learn to create Pods using declarative syntax.

Defining Pods through Declarative Syntax

Pods as wrappers for containers

Looking into a Pod’s definition