Kubernetes Tutorial: Part 3— Familiarizing the environment
By: Parthasarathy Subburaj
Tags: Docker, Streamlit, Kubernetes, Object Detection, Deployment

Pod

Pods are the smallest deployable units of computing that one can create and manage in Kubernetes. They can be seen as a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. Pods in Kubernetes can run a single container in which case, they can be just seen as a wrapper around a single container, or they could run multiple containers that need to work hand-in-hand to create a service (will be discussed in the next section). For example, you could have a container that runs an application which fetches relevant information from a datastore residing in a public volume based on the user’s query, and an additional container that keeps on updating this datastore on a realtime basis, in scenarios like this it will be better if we can tag the two containers into a single pod.

Again we will create a pod via a YAML file containing the four fields that we discussed earlier. To begin with, let’s just spin up a pod that runs the

ubuntu:18:04 image.

YAML file for Pod creation

This YAML file creates a Pod named ‘ubuntu-base’ in the Namespace ‘partha’ as specified in the ‘metadata’ section. In the ‘spec’ section we can specify the name of our container ‘ubuntu-base-container’ and the image that should be used for creating the container, in this case, it will be ‘ubuntu:18.04’. Please note that since we are pulling the image directly from the docker hub — the default docker repository — we don’t need to specify the docker server address before the image name, we can simply get away by specifying the image name alone. But this may not be the case always, oftentimes when you are working in an organization they will have their own internal docker repository in which case you need to prefix the image name with the docker-server-address since our cluster should know where it needs to pull the image from. So the ‘image’ field looks something like this:

image: <docker-server-address>/<account>/<image-name>ubuntu:<image-tag>

We should also specify the command to be run inside the container in the ‘command’ field that starts the application for which the container is spun. Here we just call the sh command to just print out the line “Hello, Kubernetes” and then sleeps for 3600 seconds. It is important to note that the Pod will be only alive as long as the command that it executes is still running, once the command ends the Pod exits. In our case, the Pod lives only for 3600 seconds and then just dies and never restarts again (as per our restartPolicy ), so don’t be surprised if the pod disappears after that 😛

Before we move on to the next section, let’s just two a few useful commands that will be handy for debugging the Pods just incase if they misbehave. They are kubectl logs and kubectl exec .

Kubectl logs : As the name suggests, it prints out the logs of the pod we are interested in:

partha@jarvis:~/Documents/Projects$ kubectl logs pod/ubuntu-base -n partha

Hello, Kubernetes!

kubectl exec : This command will allow us to run any command in an already running container; we can leverage this to get access to the terminal of our running container as follows:

partha@jarvis:~/Documents/Projects$ kubectl exec -it pod/ubuntu-base bash -n partha

kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.

root@ubuntu-base:/#

In the next part, we will be deploying our object detection application in K8S for real 😅

Part 4: The Crux