Many companies use Kubernetes and Docker together. Many even claim that this approach brings substantial benefits to their business. But doing this may no longer be possible now. Why is that, and how can you use Kubernetes without Docker? Learn more in our article.
Docker and Kubernetes are two complementary IT solutions. Docker serves as a containerization platform (it allows developers to pack applications into containers), and Kubernetes is a container orchestration tool (you can use it to automate and optimize running containerized workloads and services). In fact, many companies used to leverage both of them in tandem. Yet now it seems that they will soon have to learn how to use Kubernetes without Docker.
What is Docker?
Docker is an open source containerization platform. Developers use it to put applications into containers. Containers are standardized, executable components that combine the source code of digital products with the operating system (OS), libraries and dependencies indispensable for running this code in any environment. Why does your company use it? It is easier to deliver distributed applications by leveraging containerization. Such an approach is common nowadays for companies that deal with cloud-native development or operate in a hybrid or multicloud environment.
Containers can be created without Docker, of course, but this platform comes with tools and solutions that make it easier, faster and safer. Instead of hours of manual work, developers can use simple commands and take advantage of automation.
What is Kubernetes?
There are some tasks that have to be taken care when using containers – these include workload scheduling, communication, resource usage management, scalability etc. All of this can be done with tools such as Kubernetes. This container orchestration platform is open source (so anybody can use it for free) and it can handle the most important container management processes (deployment, scaling, healing, load balancing).
After users define a pod, Kubernetes will make sure that it is always running. It monitors containers, and if one goes down, it tries to start a new one. This takes a lot of worries and work off of your employees shoulders and gives them more time to focus on more complex tasks.
How do Docker and Kubernetes work together?
Kubernetes does a lot, but it does not run the containers on a machine by itself. For that purpose, an additional piece of software is required – a container runtime. It is provided with information about what has to be done on each host by Kubernetes, and it runs containers accordingly. You have a big choice – there is a wide variety of such solutions available on the market (a lot of them are open source). For a long time, the most often selected option was Docker.
Not all companies need them both. Startups and small companies, that have fewer containers, don’t have to use Kubernetes for their orchestration and (as we mentioned before) you can build containers without Docker. For time, these two were considered reliable combination and leveraged by many organizations. Docker was used for creating containers, and Kubernetes was a tool for managing it. Together they were ensuring efficiency of the development process and fast releases.
Why can’t Docker be the container runtime for Kubernetes anymore?
For those who use this combination, we have sad news – Kubernetes is removing support for Docker as a container runtime. Docker support had been hardcoded into the container orchestration tool. The component was known as Dockershim. Kubernetes has now evolved and support for additional runtimes has been provided.
Kubernetes works well with all container runtimes that implement a standard known as the CRI (Container Runtime Interface). In short, this is a standard for communication between Kubernetes and the chosen container runtime. Solutions that support this standard, automatically work properly with Kubernetes, while others don’t, and Docker has not implemented the Container Runtime Interface. Kubernetes implemented Dockershim to enable communication between these two solutions and supported Docker for a long time. Now, as there is a wide choice of runtimes available for users, the Kubernetes team is moving away from maintaining special support for Docker.
You may ask why Kubernetes has deprecated Docker now – after all, many of the solutions that are available currently had already been on the market for some time. Well, Docker is not really a container runtime. It is a set of tools for creating containers, and the capability to actually run containers comes from a real runtime called Containered, on top of which sits Docker. So, in fact, Docker can’t run containers on its own. It provides a more accessible interface on top of a separate container runtime.
All of us like “all in one” solutions (if they are efficient) and nobody really enjoys combining together three (or more) different tools if it isn’t really necessary. In the Kubernetes – Docker pairing, Docker is simply a middle-man between the container orchestration platform and Containerd. What is more important – it is an unnecessary middle-man. Kubernetes can work with Containered as a container runtime directly. Docker has other applications of course, but with this knowledge, you can consider using Kubernetes without Docker (or at least without Docker as a container runtime).
How do you use Kubernetes without Docker?
Docker is older than Kubernetes and hasn’t implemented CRI, which means that it is no longer a good candidate for a Kubernetes runtime. You can decide to use Kubernetes without Docker, or even Docker without Kubernetes for that matter (but we advise you to use it for different purposes than running containers). Still, even though Kubernetes is a rather extensive tool, you will have to find a good container runtime for it – one that has implemented CRI. A runtime with CRI implementation will be able to communicate smoothly with Kubernetes and the combination will work well.
You have practically nothing to worry about. If you use Kubernetes services such as GKE, EKS or AKS, you have to make sure that your worker nodes are using a supported runtime. It is best to do so before Docker support is removed. Your node customizations may need to be updated based on the environment you’re working in and its runtime requirements. After selecting another runtime that uses Container Runtime Interface (CRI), your Docker-produced images will work just fine in a cluster with other runtimes. Many authors have pointed out that Docker is still a useful tool for building containers. Still, Kubernetes’s current transformation may be a good opportunity to assess your tech stack and compare the solutions you’re currently using with alternatives.
How do you carry on without Docker?
First, don’t panic – that is actually a piece of advice straight from the Kubernetes team. You should probably think of your options. There is always a chance you will find a better container runtime for your company. There are many available solutions – both open source and commercial. You will surely find what you need after careful consideration. We will be happy to offer you advice and assistance in implementing new solutions. Tell us more about your project and business requirements.