Docker usually provides a developer’s first introduction to containers. Kubernetes is an orchestration platform which solves challenges around running containers in production. Here’s how Docker commands map to their Kubernetes counterparts.
You can’t use the
docker CLI to interact with containers running in Kubernetes. Kubernetes provides its own command-line interface,
kubectl, to help you manage your cluster. Read our guide to getting started with
kubectl if you’re unfamiliar with the tool.
None of the
docker commands have the same name in
kubectl. Kubernetes exposes functionality in its own way. Workloads themselves are fundamentally different – Docker is designed to work with a single container at a time, whereas Kubernetes enables orchestration of multiple replicas.
The first point to appreciate is the shift in terminology. Docker refers to “containers” while Kubernetes uses “pods”. A pod might run one container or multiple replicas managed as a single unit. This detail aside, when you see “container” in Docker, you should think of a Kubernetes “pod”. The terms will be used interchangeably for the remainder of this article.
Getting Details of Your Containers
In Docker, you use
docker ps -a to see all the containers on your machine.
The closest Kubernetes equivalent is
kubectl get pods.
The output from the two commands is quite different. Docker shows more information about the workload the container is running.
Kubernetes will provide details about image and command when using the
describe pod command. You need to pass the name of the pod. This gives much more verbose information, using a list instead of a table.
Executing Commands in Containers
Docker lets you execute a command in a running container using
The Kubernetes equivalent is also called
exec. Use the Kubernetes pod name instead of the Docker container name. The command is specified slightly differently – it must be separated from the pod name by a
You can use the
-it flags to obtain interactive access in the same way as Docker. This is a shorthand for
--stdin --tty and should be used whenever you want to launch a shell within a pod. Specify the shell name, such as
bash, as the command.
Kubectl supports the
attach command for when you want to attach to a process in a container that’s already running. It works similarly to
docker attach but you should pass the
-it flags if you need interactive access.
Viewing Container Logs
To view a container’s logs with Docker, you use the
docker logs command. Adding the
-f switch will “follow” the logs so they’re streamed continuously to your terminal.
logs command has the same syntax. Supply a pod name in the same way Docker accepts a container name.
Both Docker and Kubernetes collect logs from the standard output and standard error (
stderr) streams of running containers. Kubernetes handles container restarts differently to Docker. Whereas in Docker a restarted container appends its logs to the existing ones, Kubernetes creates a new log for each run. You can get the logs of a replaced container by adding the
--previous flag to the
Docker containers are created with the
run command. Here’s how you could start an
nginx server with Docker:
docker run -d --name nginx --restart=always -p 80:80 nginx
This creates a container using the
nginx base image and sets it to restart automatically. The server is bound to the default HTTP port 80.
Kubernetes requires you to think of higher-level abstractions when adding containers to your cluster. Instead of running a container, you’re creating a deployment to represent your workload:
kubectl create deployment --image=nginx nginx
This will create an
nginx deployment. A pod gets started automatically; within the pod, there’ll be a container running the web server.
Creating a deployment won’t bind its containers to any ports. The newly created server isn’t yet accessible. Ports must be exposed via a service. Pods are ephemeral and may contain multiple replicated containers. Services define a logical collection of pods and let you assign them network resources such as an IP address and port.
nginx deployment on port 80 will enable the server to be accessed:
kubectl expose deployment nginx --port=80 --name nginx-http
Trying to access port 80 on the cluster’s default IP address should now direct you to the
Kubectl doesn’t directly support other
docker run options such as volume creation and bind mounts. Containers that require persistent storage will need to have volumes configured manually via
kubectl commands or a volume manifest.
Docker containers are removed using the
docker rm command with the container’s ID.
Kubernetes doesn’t let you delete containers directly. Instead, you work with the deployment which created the pod. Use the
kubectl delete deployment command, passing the deployment’s name.
Docker allows you to stop a container instead of removing it. Kubernetes has removed support for this action. The recommended way to temporarily suspend a deployment is to scale its replica count down to 0. With no pods running, the workload is effectively stopped.
kubectl scale --replicas=0 deployment/my-deployment
When you’re ready to resume the deployment, run the
scale command again. Set the new replica count to
1 or higher. Using more replicas can increase the availability of your workload.
There’s no direct parallels between the Docker CLI and
kubectl. Most of the Kubernetes commands have a different syntax to their Docker counterparts. You will need to learn new terms and options before you can transition Docker-based workflows onto Kubernetes.
In many cases, there is no
kubectl alternative to a Docker CLI capability. Docker’s functionality is focused on the container concept. Kubernetes takes that and places it at the centre of a greatly expanded resource ecosystem.
Containers are rarely dealt with in isolation. Instead, you’ll need to work with resources such as deployments, services and replica sets. This is why learning Kubernetes can seem challenging when approaching it from the perspective of a Docker user.
If you’re familiar with Docker fundamentals, transitioning to Kubernetes should nonetheless be relatively straightforward. The principle difference is that what Docker sees as a container is usually accessed as an aggregate “pod” in Kubernetes. Pods are created by “deployments” which represent the workloads in your cluster. When in doubt, refer to the
kubectl docs to find an approriate match for a Docker command.