Cloud Native Computing Foundation Kubernetes Community Days Bangalore 2022, 11 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Docker we still love you

Description

With dockershim removal scheduled in v1.24 release of Kubernetes, there have been a lot of confusion regarding this. In this talk, I will majorly discuss the "why dockershim removal" was necessary and discuss how the "shim" and container runtime are quite unrelated will further focus on the container ecosystem and the readily available options.
The talk will also focus on how CRI makes it easier for Kubernetes to use different container runtimes. It will include adequate links to available resources to help people understand the migration and make necessary changes.

A

Hi everyone- I am deva bretta, and this is my talk on docker. We still love you.

A

uh This means is defective of what happened last year. When uh you know docker announced it is deprecating a docker ship. uh You know, and uh there was a havoc along the depths community, especially the sre and devops. They thought and uh those people, especially who weren't aware about uh things like container run time, oci and other things they thought you know.

A

Document removal means the death of docker and uh kind of you know they thought that we won't be supporting container images built out of docker, which is very untrue, and if you uh know the uh real uh reason behind the removal of docker sim, it is for the benefit of the project and how uh it's indicative of how the project is becoming more and more inclusive for various container runtimes that are coming up in uh recent advancements in particular technologies.

A

So, in this talk I'll give you a context of what is what is happening and how you know uh this. Whole things are uh interlinked how uh cubelet talks to containers and how they occur. In turn, orchestrate uh helps in orchestration of cuban the occupation of the containers for communities. uh We will be seeing uh what is what is happening in uh communities 1.24 and there's no need to panic, it's time to adapt and the resources.

A

The unlimited resources that uh every day of stream devs are trying to create for end users as well as upstream folks, obviously to help uh understand uh what is going on behind the scenes.

A

So, uh as we know uh at the lower layers at the lowest layers, the fundamental accumulation node is the software that, among other things, starts and stops contacting the basic things and uh the thing that does this. We call this container run time. Basically, and uh you know, uh tubelet communicates with the container run time over unix sockets, uh using grpc framework, where cubelet acts as a client and cra seem uh acts as a server and uh inherently when docker started uh doc. The docker uh started. It was a monolithic service and uh kubernetes.

A

When it started, uh docker was the only container uh runtime that was uh prevalent in the market, uh so they came up uh with something called uh docker shim to support uh the container runtime interface for docker, because docker inherently didn't hide. This container runtime interface, but uh with you know, with more and more container runtime uh container runtimes coming up in kubernetes 1.5 release, with the reason of being more inclusive, providing developers more options of using various container runtimes.

A

uh It came up with a container runtime interface, which is a plug-in or interface which enables cubelet to use a wide variety of container runtimes without the need to recompile. I would say so. Historically, uh if you will see docker, uh you know started as a monolithic project.

A

As I have said, you know modulated tool that uh contained the ability to set up containers uh along uh with a myriad of developers, tool, including you know, cli logging, storage management, network building tools and many other features outside the core capacity to create a container and in the vein of unix philosophy. However, docker eventually broke up. You know these components and contributed the container d.

A

If you could see in the first thing, this container d is the container runtime component of docker and it has been uh developed as an open source project and have been donated to cncf, so the default configuration in kubernetes kept docker as the abstraction layer on the top of continuity. As as we started, you know. As I say in initial days, uh we used docker as the abstraction layer on top of alternative, which in turn was an abstraction layer.

A

uh On top of parenthesis, this additional layers and all of the additional layers that docker includes obviously creates maintenance, attack, headaches, significant overhead and larger attack surface of exploits, and this is not ideal in the future environment. But teams are, you know, deploying code multiple times a day, so the additional layer also introduces serious security implications and, at the same time of when other container runtimes begin popping up, kubernetes maintainer came up with this standard called the container runtime interface in the 1.5 version, which you prompt in the last slide.

A

That would be a common language for communication between cubelets and container runtimes and as docker wasn't compliant with the standard it required. A middle layer sim to operate, obviously that's the reason why docker sim is there and if it would have inherently uh supported this cri, we wouldn't have needed this document and you know kubernetes and container demand maintainers, and it is here.

A

I seem for communities to talk directly to content id which you could find in container d 1.0, so this allowed now this allowed kubernetes to cut out docker and use container directly, so this technically reduce the container capabilities. Obviously, the the reason why docker is famous among developers is its other capabilities of logging and uh the cli. It provides uh inherent cli and other things, but you know uh those capabilities are quite unnecessary for an orchestration tool like communities, uh because you know, containers managed by communities, for example, does doesn't need access.

A

However, cri sim, you know this, this uh demon added another complexity and another. You know attack surface for so-called developers, so you know uh how this uh thing functioned in container d. 1.0 is you know this daemon called cra container d was required to operate between cubelet and cartel d and cri continuously handled the container runtime interface service, requests from cubelet and used container d to manage containers and category images correspondingly so compared to docker sim, uh you know docker sim, the docker cr implementation.

A

This eliminated one extra hop up stack, but in container uh continuity, 1.1, uh which came up after uh you know in 2016 cryo. When came up with an alternative to docker. uh It jumped ahead of the continuity's evolution, evolution and included a native cra plug-in from the beginning, and following this uh in continental 1.1, you will find the cra container. D1 is now refactored to be a container dcra plug-in. You know aligning with what cryo came up, so this cra plugin interacts with container d through direct function calls.

A

So this new architecture makes the integration more stable and efficient and eliminates another grpc hop in the stack and user can now use kubernetes and container d 1.1 or cryo directly. You know- and you know, kubernetes uh talks directly uh via the cri to pull an image launch the low level runtime to set up name spaces c groups, root file, system, storage. Everything you know could be done directly from cubelet uh to the abstraction level of continuity and cri and cryo through this cra plugin. That has come up with so now we need to understand.

A

You know this container, runtime and container built environment are completely different things. You know we can still build our container on docker and it it can still, uh you know, run on different environment and any any uh container uh that is oci compliant uh would be able to would be able to be supported by orchestration tools like communities.

A

This again, you know, as I said in the first slide as soon as humanity's announced docker sim removal, folks that were unaware of oci and cry. You know this thing basically came up. You know docker produced images. What will happen to them? This was the question. Will it continue to work in your cluster with all the runtimes?

A

Yes, it will will be able to work and because, uh because of what work docker has done, along with other foundations, uh to build this open container initiative, you know, which is an open governance structure for express purpose of creating open industry standards for container formats and run times, so it was established by docker in 2015, and uh everyone follows the runtime specification and the image specification, and you know these these two paragraphs. Basically, I took it directly from the ocm website to introductory paragraphs.

A

You could read more about the foundation, uh this open governance structure and how uh it is. It is uh creating the ecosystem more and more inclusive, for the tools that are at a higher abstraction level than the controller. That is the orchestration tools.

A

So when we talked about you know, docker docker, which started as a monolithic tool, uh started to scale itself and build different parts of it. So container d became the container runtime part of the docker, which was you know, donated to cncf, and it's an open source project and uh shifting from native docker engine to container d won't be.

A

uh You know much of a change for uh for you uh or for any kubernetes users, especially for the folks who have who are you know using enterprise uh kubernetes like from aws from gcp from vmware or red hat. They did not have to worry because they have this default option of converting their clusters or uh putting container d by default in their clusters, and even these enterprise uh folks are uh making people aware uh you know, and we, as communities of student debt community are trying to uh put up.

A

Surveys uh know how much uh prepared uh everyone for this uh docker simulator. So, yes, as I said, you know migrating from docker sim to other cris. We have. uh We have direct uh technical blogs uh which uh no technical documentation which uh highlights uh the processes. You need to shift uh your uh node uh from docker engine to cryo or container d, how to drain the node or you know, stop the node and uh shift from one uh docker engine to other cris.

A

So you know, uh as we saw in all these slides, you know, the uh lower abstraction level is run c that is uniform throughout from cryo to container d to docker. There is just an increase in abstraction level and increase of features as we go up higher in the affection level and the value chain.

A

So uh there are a few differences around the edges which you need to take care of, like logging configuration, runtime resource limitations, node provisioning scripts that called docker or used blocker wires control, socket cube, ctl plug-ins that require docker cli, basically, uh which is an added feature to docker on top of the controller abstraction. So uh the configuration of functionality like registry mirrors and insecure registries other support scripts. So these whole, all things are mentioned in the updated faqs of our document, application that is available in kids.io website.

A

You could go and read those things, and these are the resources which majorly, unless uh all things you know, basically the faqs and uh first of all, uh you should know whether docker shift application affects you or not, because uh continuity has been part of cncf since a large amount of time and people have shifted uh to continentally, even before the docker shield application was announced or in even after docker, symptoms uh was announced.

A

So you don't have to worry about uh docker removal now, if you have already sticked to so, you need to check uh uh whether docker synthetication affects you or not, and this block is very important for everyone, and uh there is an list of our articles on docker, sim removal and on using other cri compatible runtimes. Those are available uh in case.I o website, so uh we saw you know how a container runtime is evolving with time with container technologies are evolving.

A

New and new container runtimes are coming up and using container runtime interface, cri plug-in kubernetes uh could interact with any oci compliant containers, and until uh this oci compliant containers are present in the market uh or are coming up, you need not worry about uh what will happen to your clusters. You know it. It won't stop.

A

Working and kubernetes uh will be able to manage everything in your clusters using this uh container runtime plugin, uh but for now, uh since docker has uh docker engine has been uh an inherent part uh since the early days of uh communities, and yet it's still a part. We are still supporting uh any container.

A

Runtime and docker uh qualifies as a container runtime electrons container d uh inherently, but the additional tools support uh like the cli and all those things that will drop off with this uh docker server mobile and it's it's uh in the long run, it's beneficial for uh as as upstream uh kubernetes developers as we don't have to maintain that part of the code and more and more features uh that uh used to you know break that part of the code.

A

uh Now that would be a head deck for us so hope this uh wasn't wick was on 1.2 for release. It goes smooth for you and you are adapting well to the docker similar weapon. Thank you. That's all from.

A