# The base building block: `pod`

## Introduction

In this section we will learn what is a pod, deploy your first container, configure Kubernetes, and interact with Kubernetes in the command line.

The base job of Kubernetes is to schedule `pods`. Kubernetes will choose how and where to schedule them. You can also see a `pod` as an object that requests some CPU and RAM. Kubernetes will take those requirements into account in its scheduling.

But it has a base assumption that a `pod` can be killed whenever it wants to. So keep in mind that a `pod` is **mortal** and it **will** be destroyed at some point.

## First pod

Let's start to deploy the docker image [mhausenblas/simpleservice](https://hub.docker.com/r/mhausenblas/simpleservice/). It's a stateless python JSON API that answers on multiple endpoints. In this hands-on we will only use the `/health`.

Here is our first manifest for Kubernetes:

```yml
apiVersion: v1
kind: Pod
metadata:
  name: simple-pod
spec:
  containers:
  - name: simple-pod
    image: mhausenblas/simpleservice:0.5.0
```

The manifest of Kubernetes represents a desired state. We do not write the steps to go to this state. It's Kubernetes who will handle it for us.
Let's have a look a the fields:

* `apiVersion`: the version of the Kubernetes API we will be using, `v1` here
* `kind`: what resource this object represents
* `metadata`: some metadata about this `pod`, more on it later
* `spec`: specification of the desired behavior of this pod
  * `containers`: the list of containers to start in this pod
    * `name`: the name of the container
    * `image`: which image to start

Let's `apply` this manifest to Kubernetes. This will tell Kubernetes to create the `pod` and run it.

```sh
$ kubectl apply -f 05-pods/01-simple-pod.yml
pod "simple-pod" created
```

We also could have used the `kubectl create -f ...`. But it's better to have a declarative approach in Kubernetes rather than an imperative one, [see](https://medium.com/bitnami-perspectives/imperative-declarative-and-a-few-kubectl-tricks-9d6deabdde).

## `kubectl get`

Now list all the `pods` running in Kubernetes. `get` is the `ls` of Kubernetes.

```sh
$ kubectl get pod
NAME             READY     STATUS    RESTARTS   AGE
simple-pod   1/1       Running   0          4s
```

## Logs

Let's have a look at the logs of this `pod`:

```sh
$ kubectl logs simple-pod
2018-10-01T09:21:59 INFO This is simple service in version v0.5.0 listening on port 9876 [at line 142]
2018-10-01T09:23:21 INFO /info serving from 172.17.0.4:9876 has been invoked from 172.17.0.1 [at line 101]
2018-10-01T09:23:21 INFO 200 GET /info (172.17.0.1) 1.38ms [at line 1946]
```

## `kubectl describe`

Our first `pod` is now running. Now `describe` it. `describe` is a `get` on steroid, with more information.

```sh
$ kubectl describe pod simple-pod
[a lot of stuff]

IP: 172.17.0.1

[more stuff]
```

Look at the information provided. Get the field `IP`, it's the internal ip for this `pod`.

Connect to the cluster, and try to `curl` this ip - `172.17.0.4` in the example.

```sh
$ minikube ssh
                         _             _
            _         _ ( )           ( )
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ curl 172.17.0.4:9876/info
{"host": "172.17.0.4:9876", "version": "0.5.0", "from": "172.17.0.1"}
```

Kubernetes has a useful add-on, a web dashboard. It's included by default in minikube. You can start it with:

```sh
minikube dashboard
```

## Exercises

1. Deploy a `pod` containing nginx. The image name is `nginx`, see: https://hub.docker.com/_/nginx/.
2. Do you think you can access the pod `simple-service` from outside of Kubernetes, *without changing the manifest*?

## Clean up

```sh
kubectl delete pod --all
```

## Answers

For 2), no, the pod is only visible from the inside of the cluster.

## Links

* https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/
* https://kubernetes.io/docs/concepts/workloads/pods/pod/
* https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/