Kubernetes is dropping Docker support - What does it mean for YOU?

a couple of days ago an update was released that kubernetes will no longer support docker so what does that actually mean why did this change happen and how does that impact you as a developer or devops engineer who is working with docker and kubernetes as you probably already know kubernetes supports multiple container runtimes one of them being docker which is also one of the most popular container tools out there which is used in different projects and docker was also originally the container technology that made containers popular in the first place and also caused need for orchestration tools like kubernetes itself so let's say we deployed docker engine on a kubernetes worker node docker engine actually comes with three components you have docker server then you have the docker api which is basically for interacting with the server and we have the command line interface these are the docker commands that you can execute against the server and docker server component itself has a couple of components and features it has the container runtime which is responsible for starting and stopping containers basically managing the whole life cycle it has the volumes part which is for persisting data in docker it has the network interface for docker containers and also you can build images with docker and the fact is that the only part that kubernetes needs in order to run the containers inside the cluster is the container runtime of docker so kubernetes doesn't actually need all of those features that docker offers because either it has its own features for example for creating volumes or command line interface as well as container network interface or in case of docker feature of building images kubernetes doesn't actually need that because you're not building images inside kubernetes cluster or with kubernetes and for kubernetes to actually directly talk to and use this container runtime component it needs to interact with docker first and for this interaction with docker kubernetes uses docker shim and docker shim is basically part of or has been part of kubernetes code so kubernetes developers have been maintaining and updating dokashim till now and this docker shim this part of the code in kubernetes that talks to docker is actually what kubernetes is deprecating and eventually removing from code and as you see from this diagram it is logical not to deploy the whole docker with all the features that kubernetes doesn't need and instead have just the runtime component so that containers can run in kubernetes cluster this first of all will save a lot of resources like ram and cpu and storage because your installation is much smaller and also it will reduce the security risk because the less components you have the less security risk you are exposed to and the container runtime that docker uses is container d and container d component was actually originally part of the docker daemon code and docker has extracted it as a separate component so that it can be deployed as a standalone container runtime and used in kubernetes cluster and container d is actually now part of cncf and is being developed and maintained as a separate project and container d is the second most popular alternative to using docker as a runtime and in fact container d is already being used by major cloud platforms in kubernetes cluster for example aws eks or google cloud's kubernetes service all use container d already as a container runtime so container d is a mature and also very popular container runtime used in kubernetes clusters another alternative container runtime is cryo which is used by openshift so probably now the most interesting and important question is what does this change mean for you as a kubernetes user or kubernetes administrator now first let's start with kubernetes users and these are mostly developers maybe also devops engineers who are just installing resources on an already existing and configured kubernetes cluster so basically the cluster is running already and you're deploying your applications inside in this case the change or substituting the container runtime underneath kubernetes doesn't actually affect any of your workflows as kubernetes user because that layer is completely abstracted away from you're not interacting with containers so whatever container runtime is running underneath even if it changes you won't probably even notice that the second part is kubernetes administrators or operators and these are actually people who are setting up kubernetes cluster right they're creating them from scratch and maybe configuring some network configuration on kubernetes cluster etc and these are either devops engineers or system administrators or cloud engineers and as i mentioned if you have created your kubernetes cluster on cloud on one of those kubernetes services like on aws or google cloud etc you didn't actually have to install any binaries on the servers you didn't have to install and configure masternodes you didn't have to install container runtime and the kubernetes processes on worker nodes and that means that it is not your responsibility or worry what container runtime is running on those servers so basically the cloud providers who are managing your cluster for you are actually taking care of all that for you which is again one of the advantages of using managed community service because you don't have to worry about installing all these binaries and then updating the versions etc and as i said aws google cloud and many other platforms already use container d as a container runtime now there is one specific case where you as a kubernetes administrator have to take some action and that is if you have installed kubernetes maybe on bare metal or some just virtual machines using cube admin for example so you basically spin up some servers and you installed all those binaries the kubernetes processes container runtime the network interface one by one on those servers in order to create your own kubernetes cluster and this actually might be a case for companies that are using on-premise servers maybe because of some security issues and who are installing the whole kubernetes cluster on those servers from scratch including the container runtime and if it was docker then you have two alternatives first of all you can either substitute the container runtime and use container d or cryo or some other container runtime or as a second option if you for some reason still want to use docker as a container runtime in your cluster mirantis and docker actually announced that they will maintain and support dokoshim as a standalone open source component that you can install separately inside your kubernetes cluster to be able to run docker as a container runtime now in this case when do you need to make this change you won't have to do it immediately obviously because the first step is that docker support just got deprecated so you're just gonna have a warning if you update to the latest version of kubernetes and you will still have some time to make that change from docker to another container runtime so that means that even in this specific scenario there is basically not such a huge change and not an urgent one that you have to do inside your cluster and when kubernetes administrators actually substitute docker with another container runtime developers who are using kubernetes cluster and deploying applications inside probably won't even notice that change there's still two more questions that i want to address the first one being what about running kubernetes locally using mini cube or docker desktop do i have to change anything or does this change actually impact running mini cube cluster or running kubernetes cluster with docker desktop the answer to that is no it doesn't impact at all you as a community's user again will just install these tools and they actually already make the decision about which container runtime is used in the background because you don't have to install that separately it comes with the tool so in this case minicube has support for docker and container d so if it gets removed from mini cube as well you're just gonna install mini cube and you're gonna start using kubernetes cluster without even worrying or knowing what container runtime is running behind one of the frequent questions that i see is should i still learn docker if i'm gonna use kubernetes and what about building docker images in a cicd pipeline well one of the features of docker is actually building images so before the image can run as a container inside kubernetes cluster you first have to build that image right and this is where you will still be using docker in your cicd pipeline to build images from your application let's say we have this complete ci cd pipeline that builds docker images and then deploys to a kubernetes cluster how will this work because we're building docker images we're pushing them to docker repository and how are they going to run in kubernetes cluster where there's no docker installed and the answer to that is very simple every docker image can run in every container runtime so basically you can be building docker images pushing them to docker repository and deploying it to kubernetes cluster that runs container d as a container runtime and it will run perfectly in fact it is already happening if you're using eks and the reason for this compatibility and why all the docker images can run as containers in any container runtime is that these container tools are all compatible with each other because they're all using standards defined by open container initiative open container initiative or oci is basically a project of linux foundation that standardizes how container technologies should work and how they should be implemented and because docker and container d as well as cryo all comply to these open container initiative standards they're actually compatible with each other so you can run docker images on cryo runtime on container d runtime without any problem and that means you will not have to make any changes to your existing infrastructure to your existing ci cd setup even when kubernetes does not use docker as a container runtime so to wrap this up in most of the cases there's no action required especially if you're a kubernetes user as a kubernetes administrator if you have created cluster from scratch by installing everything yourself then either you can substitute docker with another container runtime or just use docker shim as a standalone component

Channel: TechWorld with Nana

Views: 512,296

Keywords: kubernetes drops docker, kubernetes deprecates docker, docker, kubernetes, techworld with nana, docker and kubernetes, kubernetes dropping docker, kubernetes deprecated docker, container runtime, containerd, containers, cri-o, cncf, k8s, k8s docker, k8s and docker, devops

Id: 7KUdmFyefSA

Length: 12min 21sec (741 seconds)

Published: Thu Dec 10 2020