Since the time the big announcement about ‘Kubernetes deprecating Docker’ has come in to the Technology Social Media, I think it has gained lot of attention across the SW Industry especially the teams and the people dealing with Kubernetes in their day-to-day. I’m no exception :)
And Why Not?
It is such a big news from one side but on the other side., everyone wants to understand little deep about Why ? What ? and Finally When ? so that they have a plan in place to deal with it strategically
So., the same question hit me as well a bit hard in my mind — As I just started with too many buzz words and I’m in a phase where I’m soaking in to the Kubernetes world of magic and complexity slowly but surly.
I spent good no. of hours to read and digest the IFs and BUTs of this topic and I thought it’s good idea to feed back to the community with my notes and understanding. Intention is to keep it very simple and to the point. But to understand the context clearly., I definitely think the reader *must* know the entire K8S Architecture and have a detailed understanding of how each component/s work within and across the cluster before further reading this blog post — Sorry, If I’m sounding bit harsh here but that’s the truth!
Let’s get to the point., enough of exaggeration about this topic ;)
Fundamentally, K8S supports multiple container run times but Docker is the most popular as on today when we talk about Containers and Container Technologies. Other well knowns are like Containerd and Cri-o
When we deploy Docker Engine on the cluster, it comes with many components along with the Container Run time like CLI, API, Server etc. The Docker Server contains more components inside along with the Container Run Time like volumes/network etc.
Fig :1 shows a general Docker Engine Components overview
But when you look at the K8S Cluster from deep dive, it just needs the Container Run Time of the Docker but nothing else to run as K8S Cluster has all other mechanisms in place to deal with them inside already.
Fig : 2 for a rough illustration
Consider a situation where K8S cluster has to interact with the Container Run-time. In the current scenario, it has to go through the Docker first and through which it has to talk to the Container Run-Time. And to do this, Kubernetes uses Dockershim to interact with the Docker Engine. This adds loads overhead and consumes too many resources in between rather Kubernetes can directly talk to the Container Run Time., which is already part of the K8S cluster of the major cloud managed Kubernetes services.
Fig : 3 — shows a rough illustration
To simplify the use case here., by deprecating the Docker from Kubernetes., it essentially reducing the complexity as container run-time interactions can be done without depending on the Docker or the Dockershim.
Fig : 4 shows a rough illustration
This is not as simple as I shown in the diagram but at a layman’s terminology., this is the simplest representation I could come up with. It brings 2 advantages
- Less Resource Utilisation and means <in this case> less complexity
- #1 indirectly means less Security Risk to some extent for sure
Till now I tried to answer ‘Why?’ — hope that meets your expectations.
Let me talk about ‘What?’ it means to the consumers like us in practice in our day-to-day life
If you are an ‘End-User’ who is just using the K8S services as it is as a Managed Service., it doesn’t affect you much in short as the topic we have been discussing here is little more abstracted layer and underlying components of the K8S cluster which is truly abstracted for the end-user — So, just relax but it is very important for you to understand the context and theory behind this change
If you are a K8S Admin or Dev-OPs Engineer who is dealing with configuring the cluster and managing it., there is a little caution for you to be aware of. Let’s talk about it now:
- If you are using Managed K8S Service, no concern at this moment as the Cloud Providers will handle this for you. As this is internal to cluster and it’s architecture, cloud providers are responsible to deal with the container run-time and provide the seamless experience to you as the end-user. But, keep in mind to check with your respective CSPs and confirm if it is getting handled as per the deprecation guidelines — that’s it!
But in case if your cluster is ‘Self-managed’ or ‘On-Prem’ — You’ve below options
- You can substitute Docker with either Containerd or Cri-o or any other if that fits your purpose
- Or Continue using Dockershim [as Mirantis is supporting it] and hope the support is for longer time
Let’s talk about ‘When?’
- Nothing really urgent and mission-critical at this moment but from v1.23 onwards which is somewhere late 2021 onwards. So, you’ve time to breath, plan and strategise things for your control. We are v1.21 at the time of writing this blog
Does this mean ‘End of Docker era?’
- NO, NOT AT ALL!
We still be using the Docker in for CI/CD Pipelines for building the Docker Images and pushing them to the Docker Repo — That’s not going anywhere :)
There comes The End!
I hope I’m able to narrate this complex story in a simple way and I do believe others might be able to make it more simpler than me. Learning is a journey and I’m on my way… — Thanks for reading!
Do provide your feedback both positive and negative