3. Deploying a container image

In this lab, we are going to deploy our first container image and look at the concepts of Pods, Services, and Deployments.

Task 3.1: Start and stop a single Pod

After we’ve familiarized ourselves with the platform, we are going to have a look at deploying a pre-built container image from Quay.io or any other public container registry.

First, we are going to directly start a new Pod. For this we have to define our Kubernetes Pod resource definition. Create a new file pod_awesome-app.yaml with the content below.

apiVersion: v1
kind: Pod
metadata:
  name: awesome-app
spec:
  containers:
  - image: quay.io/acend/example-web-go:latest
    imagePullPolicy: Always
    name: awesome-app
    resources:
      limits:
        cpu: 20m
        memory: 32Mi
      requests:
        cpu: 10m
        memory: 16Mi

Now we can apply this with:

kubectl apply -f pod_awesome-app.yaml --namespace <namespace>

The output should be:

pod/awesome-app created

Use kubectl get pods --namespace <namespace> in order to show the running Pod:

kubectl get pods --namespace <namespace>

Which gives you an output similar to this:

NAME          READY   STATUS    RESTARTS   AGE
awesome-app   1/1     Running   0          1m24s

Now delete the newly created Pod:

kubectl delete pod awesome-app --namespace <namespace>

Task 3.2: Create a Deployment

In some use cases it can make sense to start a single Pod. But this has its downsides and is not really a common practice. Let’s look at another concept which is tightly coupled with the Pod: the so-called Deployment. A Deployment ensures that a Pod is monitored and checks that the number of running Pods corresponds to the number of requested Pods.

To create a new Deployment we first define our Deployment in a new file deployment_example-web-go.yaml with the content below.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: example-web-go
  name: example-web-go
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example-web-go
  template:
    metadata:
      labels:
        app: example-web-go
    spec:
      containers:
        - image: quay.io/acend/example-web-go:latest
          name: example-web-go
          resources:
            requests:
              cpu: 10m
              memory: 16Mi
            limits:
              cpu: 20m
              memory: 32Mi

And with this we create our Deployment inside our already created namespace:

kubectl apply -f deployment_example-web-go.yaml --namespace <namespace>

The output should be:

deployment.apps/example-web-go created

We’re using a simple sample application written in Go, which you can find built as an image on Quay.io or as source code on GitHub .

Kubernetes creates the defined and necessary resources, pulls the container image (in this case from Quay.io) and deploys the Pod.

Use the command kubectl get with the -w parameter in order to get the requested resources and afterward watch for changes.

kubectl get pods -w --namespace <namespace>

watch kubectl get pods --namespace <namespace>

This process can last for some time depending on your internet connection and if the image is already available locally.

Creating Kubernetes resources

There are two fundamentally different ways to create Kubernetes resources. You’ve already seen one way: Writing the resource’s definition in YAML (or JSON) and then applying it on the cluster using kubectl apply.

The other variant is to use helper commands. These are more straightforward: You don’t have to copy a YAML definition from somewhere else and then adapt it. However, the result is the same. The helper commands just simplify the process of creating the YAML definitions.

As an example, let’s look at creating above deployment, this time using a helper command instead. If you already created the Deployment using above YAML definition, you don’t have to execute this command:

kubectl create deployment example-web-go --image=quay.io/acend/example-web-go:latest --namespace <namespace>

It’s important to know that these helper commands exist. However, in a world where GitOps concepts have an ever-increasing presence, the idea is not to constantly create these resources with helper commands. Instead, we save the resources’ YAML definitions in a Git repository and leave the creation and management of those resources to a tool.

Task 3.3: Viewing the created resources

Display the created Deployment using the following command:

kubectl get deployments --namespace <namespace>

A Deployment defines the following facts:

• Update strategy: How application updates should be executed and how the Pods are exchanged
• Containers
  • Which image should be deployed
  • Environment configuration for Pods
  • ImagePullPolicy
• The number of Pods/Replicas that should be deployed

By using the -o (or --output) parameter we get a lot more information about the deployment itself. You can choose between YAML and JSON formatting by indicating -o yaml or -o json. In this training we are going to use YAML, but please feel free to replace yaml with json if you prefer.

kubectl get deployment example-web-go -o yaml --namespace <namespace>

After the image has been pulled, Kubernetes deploys a Pod according to the Deployment:

kubectl get pods --namespace <namespace>

which gives you an output similar to this:

NAME                              READY   STATUS    RESTARTS   AGE
example-web-go-69b658f647-xnm94   1/1     Running   0          39s

The Deployment defines that one replica should be deployed — which is running as we can see in the output. This Pod is not yet reachable from outside the cluster.