Running Docker images

Requirements#

In order to interact with Kubernetes you need the kubectl executable in your path. In most of the distributions you just need to install kubectl. If you also want to build your own Docker images you will also need docker.

• Kubectl
• Docker
• Kubernetes access certificate

First steps#

The first command lists the pods that are scheduled by the user demo. The -n flag selects the namespace. A namespace is just a mechanism for isolating resources in the cluster, so each user has access to their own namespace and their own namespace only. If the user’s username is demo their allocated namespace is users-demo.

kubectl get pods -n users-demo
No resources found in users-demo namespace.

In order to make the namespace users-demo the default so that we do not need to specify it in every command we run

kubectl config set-context --current --namespace users-demo

Scheduling a Pod#

In order to schedule a pod, the user needs to create a manifest in YAML format. A manifest specifies which Docker image is going to be run, with which command, permissions, resource requests including GPU access, environment variables and access to storage volumes. An example manifest is s hown below. This example schedules a pod that contains the Anaconda Python distribution:

apiVersion: v1
kind: Pod
metadata:
  name: python                                      # (1)
spec:
  securityContext:                                  # (2)
    seccompProfile:
      type: RuntimeDefault
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
  containers:
  - name: python                                    # (3)
    image: continuumio/anaconda3:2022.05            # (4)
    command:                                        # (5)
      - /bin/bash
      - -c
      - "trap : TERM INT; sleep infinity & wait"
    resources:                                      # (6)
      requests:
        memory: "6Gi"
        cpu: "3"
      limits:
        memory: "6Gi"
        cpu: "3"
    ports:                                          # (7)
      - name: http
        containerPort: 8888
    securityContext:                                # (8)
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

1. Name of the pod. This is just a unique name that identifies the port.
2. Pod security context. This is mandatory exactly as it is.
3. Name of the first container. It has to be unique within a Pod.
4. Docker image to use
5. Command to execute in the Docker image. In this case it is a command that just sleeps forever.
6. Optional but strongly suggested. Resource requests with the CPU/GPU and RAM to be allocated.
7. Optional. Ports definition.
8. Container security context. This is mandatory, exactly as it is.

The above manifest should be saved into a file called e.g. python.yaml. Then we would schedule this pod in the cluster as follows:

kubectl create -f python.yaml

We can get the status using:

kubectl get pods
NAME           READY   STATUS              RESTARTS   AGE
python         0/1     ContainerCreating   0          23s

The Pod will go trough different statuses from Pending to Running (unless there is an error).

Getting information about the container#

kubectl describe pod python

kubectl get logs python

Accessing the container#

It is possible to open a terminal in the container using the following command:

kubectl exec -it python -- /bin/bash

The above connects to the running container and executes a Bash shell on it. Everything that runs in that shell will be executed in the remove container.

Mounting storage#

In order to mount your private storage in the container, add the following statements at the end of your YAML manifest:

    volumeMounts:
      - mountPath: /storage/demo
        name: userstorage
  volumes:
    - name: userstorage
      persistentVolumeClaim:
        claimName: userstorage

Terminating the pod#

You can terminate the pod using

kubectl delete pod python

Restrictions using Docker images#

Most of the Docker images should run on the cluster. The only images that cannot run are those that are not compatible with the security context. For example if an image requires to be run as the root user necessarly then it is either not scheduled or will fail when running.