Kubernetes is a powerful tool. It can help you manage complex applications and provide you with the ability to easily automate tasks involved in managing them. In this course, we will start exploring Kubernetes from a beginner's standpoint. We will discuss what Kubernetes is and what it does, and we will work with some of the basic functionality of Kubernetes hands-on. We will build a simple Kubernetes cluster. We will also deploy a sample microservice application to the cluster in order to explore how Kubernetes can help easily manage such applications.

A Practical Guide to Kubernetes

# Defining Pods Through Declarative Syntax

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 take a look at a simple Pod definition by accessing the `db.yml` file from the cloned git [repository](https://github.com/vfarcic/k8s-specs/blob/master/pod/db.yml).

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.

* **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](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#pod-v1-core) documentation.

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


In this lesson, we will create and run Pods using declarative syntax.

Defining Pods through Declarative Syntax

Defining Pods Through Declarative Syntax

Looking into a Pod’s Definition