From docker run to kubectl apply — quick Kubernetes cheat sheet for Docker users

Primarily for my personal reference: this article provides instructions on running a Docker container image as a Kubernetes Deployment plus Service. It compares the Docker run command with the approach for running on Kubernetes using a Yaml file and introduces some additional kubectl commands in the process.

To work with a Kubernetes cluster — either local Minikube or a multi node cluster either locally or in some cloud — I am assuming a local installation of kubectl (https://kubernetes.io/docs/tasks/tools/install-kubectl/) and a kubeconfig file that provides the configuration details for the cluster you will be accessing.

To get going with kubectl:

set KUBECONFIG=<reference to kubeconfig file>

or

export KUBECONFIG=<reference to kubeconfig file>

The main Docker command we will replace in this article with Kubernetes Yaml files is this one:

This command runs a container called soaring-portal based on the ojet-run-live-reload image, it maps ports 3000 and 4500 in the container to host ports 3020 and 4600 and it passes in values for two environment variable.

When this command is fully done and after the container startup is complete, we expect to access the application at host:3020 (where host is the server running the Docker engine).

We can use Docker commands to inspect the container:

And execute a command inside the container:

Through kubectl and with Kubernetes we can achieve and do the same things — in a slightly different manner and against a potentially vastly different and more powerful container runtime.

The main step in getting a container to run on Kubernetes is to apply a configuration file that describes the desired state (a running container exposed externally on two ports) using kubectl apply. The thing we want to run is called a Pod that contains one or more containers. To expose certain ports from the [containers in the] Pod, we define a Service for Kubernetes. The Deployment artifact is used to describe the desired state as a combination of the Pod specification and the deployment parameters such as scaling (the desired number of Pod instances). We also use the deployment object to roll out changes in the Pod definition in a controlled fashion.

Ideally, we organize our applications on Kubernetes in namespaces. Most management operations can be executed per namespace and authorization can be defined on namespaces. Our first step is to create a namespace:

The following Yaml file (portal-deployment.yaml) provides the rough equivalent of the parameters of the docker run command:

To have the desired state described by this Yaml file put in place, we have to instruct kubectl to apply this file:

To check on the status of the rollout, we can use

To learn about the pod(s) running in the namespace:

And to check on the logs from any specific pod:

To execute a command in this Pod:

The Kubernetes Dashboard gives a nice overview of all artifacts created:

Finally: everything created on the Kubernetes cluster through the kubectl apply of the Yaml file can be removed again, as simply as this:

Resources

Kubernetes documentation kubectl for Docker users: https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

A friendly introduction to Kubernetes : https://medium.freecodecamp.org/a-friendly-introduction-to-kubernetes-670c50ce4542

Originally published at technology.amis.nl on September 26, 2018.

Lucas Jellema is solution architect and CTO at AMIS, The Netherlands. He is Oracle ACE Director, Groundbreaker Ambassador, JavaOne Rockstar and programmer