Graduating from Docker to Kubernetes

Graduating from Docker to Kubernetes Deploy • Arnaud Alcabas • 29/03/23 • 12 min read

Currently a Solutions Architect here at Scaleway, I have been working with containers and Kubernetes for a few years now. And for most people, including me, the container journey started the same way: with Docker.

In this blog post, I’ll show you what the next few steps in your container journey could be as you graduate from Docker to Kubernetes.

The container journey begins with Docker

When using containers, you probably started with a docker run and were amazed that you could just start “an ubuntu” inside whatever OS you were running the command on.

After playing around with your container in interactive mode, the next step was to build a container image, starting it in the background and pointing your web browser to it. It took a bit of trial and error, but in the end, your image was there, and everything ran neatly in its own little subsystem.

Going from there, you probably linked a few containers together using Docker Compose, appreciated how you could conveniently reach neighboring containers via network just by using their names, hosted everything on a virtual machine (VM), and your first containerized app was up and running.

But, likely, your next pressing question was: how could you make your app highly available for production? Monitoring everything, making sure it stays up, and scaling up the number of replicas if needed. How could all of this be done on the VM you just set up?

The answer to that question used to be Docker Swarm, but now the de-facto standard is Kubernetes. It will do all the things you want — and much, much more. But installing and using Kubernetes is not quite as straightforward as setting everything up with Docker. The first few steps are going to be painful: there are a lot of ways to do all of this, and a lot of tutorials assume that you already know what Kubernetes is all about.

That’s why, in this blog post, I will try and limit things to the first few steps needed to do the same things with Kubernetes that you used to do with Docker.

Setting up your containerized app with Docker

Let’s start with what you already know. With Docker, to start a container in the background, you used to run the following:

docker run -d my-image CopyContentIcon Copy code And if you wanted the container to have a volume, you could create one and then mount it when you ran the container:

docker create volume myvolume docker run -d -v myvolume:/data --name back ghcr.io/n-arno/back:latest CopyContentIcon Copy code When you wanted a container to expose a network port (like a web server), you used to do:

docker run -d -p 8080:80 --name front ghcr.io/n-arno/front:latest CopyContentIcon Copy code And the step to linking those two was done through a network in order for them to be able to speak with each other:

docker network create -d bridge mynet docker run -d -v myvolume:/data --net mynet --name back ghcr.io/n-arno/back:latest docker run -d -p 8080:80 --net mynet --name front ghcr.io/n-arno/front:latest CopyContentIcon Copy code This way, the “front” container could speak through the network with the “back” container using simply its name:

docker exec -it front /bin/sh wget -qO- http://back exit CopyContentIcon Copy code As we just saw, we could jump into a container using docker exec , which can be useful for troubleshooting various problems.

The last easy step was listing running containers and getting logs:

docker container list # which is equivalent to " docker ps" docker logs front CopyContentIcon Copy code Since we wanted to have everything altogether, we installed Docker Compose and wrapped everything in a YAML file.

volumes: myvolume: networks: mynet: driver: bridge services: front: image: ghcr.io/n-arno/front:latest restart: always ports: - "8080:80" networks: - mynet back: image: ghcr.io/n-arno/back:latest restart: always volumes: - myvolume:/data networks: - mynet CopyContentIcon Copy code And then everything could be started with:

docker -compose up -d CopyContentIcon Copy code We will do at least as much with Kubernetes now 😀

Let’s get started and deploy Kubernetes!

To begin testing Kubernetes, the very first step is to have a Kubernetes cluster available.

Deploying and maintaining Kubernetes can be complicated, but Scaleway has you covered! You can deploy our managed Kubernetes cluster named Kapsule quickly and easily. To do so, just follow this tutorial . This will create one or several “nodes”, which are servers your containers will run on.

Then, to send commands to Kubernetes, we will need the kubectl command line tool. This can be installed following this tutorial .

The kubectl command line tool will need to know how to connect to your cluster. To do so, it will need a file named kubeconfig which can be downloaded from our console using this tutorial .

Setting up a containerized app with Kubernetes

Let’s take a look at how to set up a container with Kubernetes. Along the way, we’ll learn about resources, metadata, labels and service types.

Starting a container using Kubernetes will feel very similar to what you used to do:

kubectl run --image=ghcr.io/n-arno/front:latest --port 80 front CopyContentIcon Copy code This will start a single “pod” which is similar to a “container”. The main difference between pods and containers is that a pod can be multiple containers linked together, for example, to have a helper container (like a log gatherer) linked to your application container.

But for the sake of simplicity (for now), let’s assume that a “pod” equals a “container”.

You may have noticed that I did not specify which port the container can be reached at, only the port inside the container. More on this very soon.

But first, list your running pods:

kubectl get pods CopyContentIcon Copy code Then jump into your container like you used to:

kubectl exec -it front -- /bin/sh CopyContentIcon Copy code Get the logs of your container:

kubectl logs front CopyContentIcon Copy code All of this should still feel familiar to you. 😀

Resources in Kubernetes

In Kubernetes, like in Docker, there are several types of resources. With the docker command, you used to do:

docker container list docker volume list docker network list CopyContentIcon Copy code With Kubectl, it’s just slightly different:

kubectl get pods kubectl get services kubectl get persistentvolumeclaims CopyContentIcon Copy code There are even short-hand versions for the…