Cloud Native Computing Foundation Cloud Native + Open Source Virtual Summit China 2020, 11 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deep Dive: Unified Runtime Service Infrastructure for Containers and VMs - Yunwen Bai & Peng Du

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Deep Dive: Unified Runtime Service Infrastructure for Containers and VMs - Yunwen Bai & Peng Du, Futurewei

Nowadays cloud providers offer services orchestrating both containers and VMs with different runtime services. Kubernetes, being a container orchestration platform, uses CRI interfaces which is specifically designed for containers. Extending Kubernetes to support both container and VM types carries sizable challenges in terms of managing multiple runtimes, handling OP differences with container and VM workloads, etc. In this talk, Peng and Yunwen present a new runtime infrastructure which is designed to address those challenges. They will dive deep into modification in Kubelet for managing multiple runtime services, workload-runtime late binding, partial runtime readiness handling, and the unified runtime interfaces that support both containe and VM workloads and operations such as reboot, snapshot, migration, etc. They will conclude the talk with lessons learned and future works.

https://sched.co/cp9O

A

Hello: everyone welcome to the virtual conference, I'm in mumbai. I'm.

B

A

Today, paul and I will share with you on the unified runtime service infrastructure we have been working on in this talk. We will start from the motivation for the unified platform for vms containers and bare metals and a high level introduction to the project actors.

A

Then we will dive deeper into the design and implementation details of the unified runtime project in actors. We will finish this talk with a demo and some future works in this area.

A

We hope you can walk away from this talk with understanding on this novel design and even better inspired interested and contribute to those projects.

B

Okay, let's start with background and motivation, the motivation of this work comes from the fact that we want to be able to run virtual machine and a container at the same time. Traditionally, if you want a virtual machine, you could use openstack for container. You could use kubernetes, but they're run as two different clusters uh at a certain point that we have this requirement that okay, we want to run both virtual machine and container in the same bare metal cluster.

B

We could still use two clusters, two different stacks. The problem with that is that it's very hard to coordinate the resource allocation between these two stack because they're being run independently of each other. This is where the new design comes in, where we just want to have one single layer of orchestration between the workloads and the bare metal cluster.

B

There are a few solutions to allow you to have vm pod in kubernetes, for example, you could do the crd and operator solution. Also, you could have some external component to kubernetes to allow you to access the vm pod.

B

One issue here is that, by doing this, we're still going through what the kubernetes provide us in terms of the cri interface, and that has some limitation as to what kind of feature you can have uh in the virtual machine uh with our project, which is called actos, we are taking a more more of a native approach, which means we are making changes to kubernetes itself, and by doing this we want to provide the virtual machine as a first-class citizen, and also we want to provide the full feature for virtual machine instead of a simplified one.

B

uh Here are a few challenges we're facing. First of all, we want to provide a better solution than just kubernetes, plus openstack, as we have discussed, we want to provide feature like the resource allocation coordination to this. Second is we want to stay open and extensible for future. If we have more workload types we we should be able to adapt to and accommodate them very easily. The third one is, uh we will have a unified type definition for both the virtual machine and the container.

B

What this means is that, uh basically virtual machine is the first class season. It's not a guest or it's not the add-on. uh The the pilot definition, for instance, is for virtual machine, it's very similar to the pod definition for containers, and this also leads us to the the fourth challenge that we want to provide rich operations for virtual machine because we're a more native approach. We are able to extend the cri interface and then that allows us the possibility of providing more features there.

B

The actos project has a lot of a lot of features. The unified runtime is one of them. This is the focus of this talk today, but if you're interested in other part of october's project feel free to take a look at our virtual booth and also actos project is, is part of a bigger project called centeris from us and uh yeah. That will also be show shown at the virtual booth, with this I'm gonna hand over to human for design and features.

A

Okay: let's go design.

A

Let's first briefly give a high level review to refresh aaron's memory before we dive into the unified runtime design. Cubelet gets content, runtime endpoint, where the content runtime and the container runtime endpoint command line. Arguments kubernetes, use this information to construct the remote runtime services and pass it into the generic random manager object when kubernetes manager gets the part it computes necessary actions, for example, create container for the given part with a series of api invocations.

A

The request is then handed out by the remote runtime service via the rpc call. Please keep in mind that the current only one runtime service, supported in kubernetes.

A

Now, let's take a look at the current changes in actors: this is a high level design diagram for the multiple runtime service management in actors. The goals are simple: natively support, vm workload, extensible for future random apis.

A

The components highlights in purple and time. Colors are major changes to achieve these goals. The cubelets now accept multiple runtime endpoints and extra information for the workload type and the designated runtime names.

A

A new component runtime registry was added to store and maintains this information. The cubelet when constructing the runtime manager, instead of passing in the single remote runtime service interface. Now it passes in the runtime registry.

A

The runtime registry provides gather apis to runtime manager to get the desired workload based on the part workload type.

A

Each runtime service for different workload will require different spec for the workload types. The port converter is an adapter for type conversion between actors and runtime services. In a nutshell, it translates the vm part definition actors to the desired spec that the remote runtime service expects.

A

Last but not least, the random container interface, the runtime internal interface and the cr interface are extended to support vm specific operations such as start stop, reboot click, snapshot, etc.

A

Now, in actors, when a new part is created and scheduled, the rental manager gets the pulse, it will call the runtime registry to get the desired runtime service for the part based on the workload type the desired runtime service api are called for the powered actions.

A

We call this the power runtime late binding with the real-time registry power converter. The crr extension together achieve the goal to support multiple random services natively and make actors extensible for new runtime services and provide rich vm operations in the next few slides. We'll share some more details of them.

A

Let's take a closer look at the runtime service registry type and interfaces as we can see. Besides the internal run internal api runtime services, which is constructed by kubelet, a few more fields are maintained. The workload type is to determine which workload the runtime supports.

A

The its primary field is used to determine the must-have runtime service on the node, which is used for node readiness check. Currently only static registration is supported in the future. The dynamic registration will be added.

A

So when a node is ready to support new workload, types couplet won't need to be restarted to load it up.

A

Optos is designed to support full-fledged vm definition and operations on vms to match the feature set currently openstacks offer in actors. The cr interface has been extended, with a set of new apis to support those operations need to mention that even currently, there's no deep changes at the internal data structures.

A

With some effort to allow the runtime sdk as plugins in the remote package in kublet, it can be extended to support customized interfaces.

A

Invitation with multiple runtime service in kubelet and supporting vm types, we have facing some design decisions to make due to time constraint. I only share a couple here.

A

First, we have to ensure the compute resources, such as cpu memory, etc, are controlled shared among the vm and the container types on the node in actors. This is this is designed such way when the vm is created.

A

The actual runtime service creates the sql path for the vm following the same layout pattern as the container workload type, for example, it would be under keeper pause, burst, ball, slash, port id, slash, vm id and the random service moves the vm process to the sql path for vms.

A

There are three set of metadata in terms of resource control. The first one is the sql metadata, which is sql files and each control. The second one is the random metadata and the third one would be the leap word vm domain definition, the actors, vm runtime service, keeps them synchronized by checking them each time. With the win win, the vm status is reported.

A

Another one is to handle the node status with multiple runtime service on it recall the its primary field in the runtime registry type, the actors with multiple runtime service on the node. We allow the cluster admin to elect one as the primary runtime service and use it to determine the node's runtime readiness.

A

The scheduler will only schedule the workload to the node where the desired runtime service is ready. This is very important in the cluster, so the node will be still useful as long as the primary runtime service is ready.

B

So, with those uh design decisions, we are able to have this unified runtime to allow the both the vm and the container to run the same time. There are a few other features that we want to mention here. One of them is the the pod state management.

B

What this allows us to do is to be able to have the vm to go from a running state, to a shutdown state or to a hibernate state and come back. This is different from just shutting down and deleting a pod. This will keep all the state of the vm so that when we are ready, we can bring them back running with all the same state. uh In this diagram, I have a quick mechanism showing how this works.

B

So, for example, we have this vm pod running on a node and in the definition of this other in the products back section. We have this virtual machine and one of the the key is the power spec, that's showing the running state. The power spec indicates what the state the vm should be running, and now it's in the running state.

B

So that means that the power should be running, and it is running here to change this, for example, at a certain point that we want to shut this down, maybe to uh control resource uh or just avoid using resources when we're not using this virtual machine. What we can do is we can issue a patch command to the pod uh to indicate okay. We want to change this part to shut down and then what's that's going to do?

B

Is it's not it's going to trigger the control plan to take this part out of resources from the node and put that in a shutdown state? When the scheduler sees this, for example, it it will see the shutdown state, they will see that it's intended, so it will not uh try to reschedule this part anywhere else. When we are ready to bring this back, we can do something very similar to brain back. We can issue another patch command to change this from shutdown to running.

B

Similarly, the control plan will see these changes, and the controller now sees that. Okay, we want this to be in a running state. The controller will schedule this product. To some note that the new node can be the same node or it cannot be the same node, it all depends on the resource availability at that time and when the pod is back up running, it will have have all the state from the previous life.

B

So it's as if we just pause the pod for for some time um here, the next one on the agenda is we were going to do a demo, so in this demo let me switch to the demo window uh in this demo. I will uh basically let you see, I will have two parts here. One is a virtual machine pod, as you can see, this part is the definition for the virtual machine on the right is a traditional uh container, a pod.

B

So you can see that it's, uh it's very basic uh definition is a very simple definition. uh One thing I want to point out here is that, uh as you can see, the virtual machine now is on the same level of definition to the container. So it's not a guess that is a first class citizen uh to be there and the the rest of the definition, for example, for the resource part and the resource. Limited request is very similar to the what the container has okay.

B

So the first part of the demo is: let's create this two parts I do that create, let's create the container part and let's create the vm part, and here we can see that the both parts are being created and in a second we'll see that they'll go from pending to running that's good. Now, let's take a look at what the part is. Actually the vm part. So uh here I'm gonna show you a few things one is uh we talked about this section right. uh We have this power spec to indicate the.

B

What is that the vm should be running and in the status section we actually have the the virtual machine status and also uh we have the product scheduled status for this part. Okay, so that's good! Now, let's try to change this to shutdown and bring it back. What I'm going to do is I will issue two patches. One is to shut down the the vm.

B

That's gonna work is, uh let's do I will do a patch like this. So if I do that the controller the scheduler will see that and it will see that it's in a no schedule state, so it will not try to schedule it uh if you're curious. I can show you what's in here, which is very uh straightforward.

B

We just are changing the power spec section of the pod spec okay, and if we go back and take again look at uh the status, we can see that the pod is in the virtual machine shutdown state and it's in the no schedule no schedule means again. Does the schedule will not attempt to schedule. This pathway sees that?

B

Okay? Now, let's go back uh okay. Now, let's bring this back. How do we do that? We use. uh We just do running we'll just issue another patch to to change the power spec section, and we can see that okay, the the patch has gone through, and let's just wait for it to go back to running and now it's running. So that's very good. uh This demonstrate that uh we can have both vm and the container running at the same time and we can have features like uh shutdown and the restart.

B

That concludes the demo. For today, I will hand this back to human.

A

Great thank you for the good demo. The actual project is still in its early stage for the unified runtime area. There are quite few new features that have been planned. For example, the bare metal support the gpu or device pass through more vm action support. It's very integration with the storage network provider, exactly.

A

We have put some useful links here, including the actors project repository and some design. Documentation here feel free to draw the code, draw the design, documentation and learn more from it.

A

The future we have a virtual booth set up. Please visit us there and learn more about the project, actors and other interesting projects. We are working on feel free to contact us if you are interested in contributing to those projects with that we'll be happy to take a few questions. Thank you.