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 docker exec.
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 -- sequence.
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.
Kubectl’s 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 (stdout/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 logs command.
Creating Containers
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.
Exposing the 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 nginx server.
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.
Removing Containers
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.
Conclusion
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.
