KubeVirt KubeVirt Summit, 24 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: KubeVirt opinionated deployment via Hyperconverged Cluster Operator

Description

How deploy KubeVirt and several adjacent operators with ease?

The HyperConverged Cluster operator (HCO) is a unified operator deploying and controlling KubeVirt and several adjacent operators:

- Containerized Data Importer
- Scheduling, Scale and Performance
- Cluster Network Addons
- Node Maintenance

The purpose of HCO is to ease the deployment, upgrade, monitoring and configuration of an opinionated version of the KubeVirt cluster.

The Hyperconverged Cluster Operator can be installed on bare metal server clusters in a matter of minutes, even from a GUI, without requiring a deep knowledge of Kubernetes internals.

An attendee will learn:

- how to deploy and maintain a KubeVirt cluster with the Hyperconverged Cluster Operator
- a demo
- ongoing development and how to contribute

NOTE: a high quality version of the demo is available here: https://youtu.be/tHPHfL5PzGM

Presenters:
- Nahshon Unna-Tsametet, Senior Software Engineer, Red Hat, https://github.com/nunnatsa
- Oren Cohen, Software Engineer, Red Hat, https://github.com/orenc1

References:
- HyperConverged Cluster operator (HCO): https://github.com/kubevirt/hyperconverged-cluster-operator

A

Okay, so this is the next session on the kuber summit. uh Nashun and oren are here to tell us about the uh hyper-converged cluster operator a way to deploy uh multiple components in an opinionated way, but they will tell you a lot more about it all yours, thank you.

B

So hello, everyone and thank you for joining I'm sean from red hat, I'm working on the cubewort installation and upgrade team- and here with me, is owen. Please present yourself.

C

Hello, I am owen cohen, a software engineer in kyovo's install upgrade and operator team in redder.

B

B

So we will talk in this session about the hco, the hyper-converged cluster operator. Why do we need it? What it does, what we are planning for the future, and hopefully we will have some time for questions and answers.

B

So, let's start so why a hcl.

B

In order to have a fully functional virtualization system, we want several components.

B

So we want to have a compute subsystem and storage and networking and we want to to have a way to import vms from other places and we want templating, and we have subsystems like that. In cubeworld we have the keyboard for compute and cdi from for storage and so on, but deploy and configure such complex system may be a bit challenging, and this is where hco came in for help.

B

So that the goal of the hco is to provide the right set of components in order to deploy the fully functional virtualization system in kubernetes and to be a single and entry point for multiple operators where users can deploy and configure them in a sin in the single object.

B

Hco provide opinionated deployment for purebuild and and all the rest of the components, and we want to make this process the deployment. The configuration the upgrade as much easy as possible and to to make it easy to monitor and configure and to install and to upgrade and all the boring stuff. That should be automatically done as much possible.

B

We have some kind of relationship with olm, but we even though hco control uh several components. It's like a meta component, meta operand. It doesn't replace uh olm, while I'm still working and olm still control the life cycle, life cycle of the deployments and the operators and hco controls the cr, the configuration and the monitoring and so on.

B

So let's talk about the hco responsibility. What it does.

B

First of all about it make sure that um all the components are deployed with the matching versions in order to avoid the dependency conflicts and problems with this kind seo.

B

Packaging shaped with a single cluster service version file, csv uh that contained the configuration how to deploy all the conf, all the operators, the crds and everything with the right versions, and the same is done for upgrade actually because we want to upgrade the whole system in one transition again to avoid uh conflicts and to be able to ship new features that that will cross a system, and things like that.

B

um We talked about our lm before um the or the om integration I mean. Hcl is the integration point for the system and, for example, it uh report the status of the system by aggregating the conditions of all the rest of the components and report the accumulative status to olm.

B

And the rest of it, I think we talked about and by the way we don't force to work with olm. If you don't want to seo, can work without or lm2, and we are doing it in test all the time.

B

um We want to have to uh see how to be the single point for configuration for the whole system. Now this is still in progress and we will talk about it later in some more details.

B

But the idea is that the user will have to deal only with one custom resource it will he will he she will deploy. Only the uh hyper converge, custom resource and configure it and htr will take it from there and propagate to all the other components as needed.

B

So how is it working?

B

We have here the end user, in our case, the system administrator that want to deploy virtualization on kubernetes, so they will go to the marketplace the the operator hub and will deploy the cube, build product, the system within the shipping of this pod system.

B

We have the catalog and the csv for the specific versions and the user will choose the version and deploy it and olm will take.

B

It create a csv object from it and we'll, according to this csv, we'll create all the crds and operators and we'll make sure that the operators are up and running and then again the system administrator will create one and only hyperconverge custom resource here, and from that moment the hco operator will uh take control and we'll create all the rest of this cls and monitor them, and the system can start working and now we will have a short demo from oren. So owen plays take control.

B

Oh, and we can tell.

B

C

Hello, everyone and thank you for joining in this demo. I'm going to show you how hubert and all of its supporting operators, such as cdi for storage, cna for network and so on all can be easily deployed, monitored and maintained by the hyperconverged cluster operator on a okd cluster or openshift container platform.

C

Cluster hcl is not yet available in operator by default, but will be soon be there. Until then, we can create a custom catalog source by navigating to cluster settings, global configuration operator sources and locate a new catalog source. Let's call it hco catalog source and the image url of the container image is this.

C

um We are publishing the most recent index image here and we creating it once we create the catalog source. A pod is being created from openshift marketplace and this processing the index image and make the package of the operator available at operator.

C

Now we can navigate to operator up and search for cube, filled keyword. You can see it here. We can see general information about the operator and description clicking on the install button.

C

We choose the most recent update channel, which will soon be changed to stable and the operator is installed on the specific name space on the cluster, which is google type converged. This operator is singleton, meaning it can be only installed once cluster, because it's watching all the virtualization resources within the cluster. We click on install.

C

Now the first stage of the installation begins. um The resources are being deployed by olm.

C

And we can see, um we can navigate to cuban type and converge a namespace, and we can see our operator is installing and the resources that it's installed are are listed in the install plan objects under component.

C

This is what going to be installed by our hco package. This is mostly clds and service accounts and role bindings, and also the csv object, which is a spatial object containing all the deployments and other resources that was defined to be deployed.

C

This are the initial deployments, mainly operator pods, that are in charged of watching the lcls and acting accordingly.

C

Once we see that all pods in stage one have been deployed and the status is succeeded, we can proceed to creating the hco custom results and there is the form view of the yaml view um we can set some feature gates. These are the default values and we can click on create once we click on create the custom resource is being populated with conditions telling what is going in the cluster.

C

Currently ssp is progressing and in we can see that um a bunch of additional pods have been created which are deployments and demon sets and hco created. This custom results for all the underlying component, such as huge word.

C

C

And network add-on, config, ssd and so on. You can see that all were created within a minute ago. So since we created this, the custom resource.

C

So um when all the pods are going to be ready, the hcl operator will be ready as well and it will signal installation is completed.

C

I am pausing and waiting.

C

Okay and now the hco is going to be ready and the installation is succeeded, as we can see here.

C

If any disruption will made to the cluster and for a component, it will be reflected here in the conditions and now that the installation is completed, we can move to the virtualization page, which is shown after the installation and create a new virtual machine.

B

Using the ui- and this is all I wanted to show- thank you very much.

B

Thank you, owen.

C

Okay, I just wanted to add that what you see is it's just the tip of the iceberg. Hco is also responsible on a full life cycle on upgrade on and on second day maintenance. So you can configure your keep the deployment while the cluster is running.

C

Okay, you may continue thank.

B

B

So what we are playing for the exercises?

B

um First, we want to announce no, it's not announcement. Yet um we are about to ship the community version of the operator hub very soon it's around the corner and it will be appear on the operator hub.

B

I think it's a very important news about olm integration.

B

We are trying to be in sync with the olm all the time, tracking the new features and so on. We are now working to implement the the new operator condition feature and later we are going to implement the scoped operator feature when it will be available for me from olm.

B

And also about the maturity of the product, we want to be go to the next level of the operator compatibility capabilities.

B

We are around level four. We are working very hard on metrics and alerts and we hope to move to level five and to get seo to be a mature operator.

B

Let's support all the good things um about the configuration we talked about it earlier. I want to talk about a bit more.

B

So, as we said before, we want seo to be to build a single point of configuration for the whole system, so we started with the node placement and it's now supported and you can define node selectors affinity and tolerations in the hyper-converged custom resource and hcl will propagate it to the other components.

B

Next, we'll in the middle of moving the feature gates from cube world to h to the hyper converged custom resource. We are in the middle of this process um and later we want to retire the whole uh cube, vert config map and to move everything to the hyper-converged custom resource.

B

And uh we are trying to use uh open api version 3 in order to support the explain command and to have us say you saw in their own demo, ui form for all the configuration fields.

B

And we actually want to hear from you: how do you want to see the api and we want the api to be as easy to use as possible? We wanted to to have a common language and clear, and this is pretty much it.

B

So um let's say I see that there are several questions in the in the chat and they say that oh and already answering.

C

Yes, uh sachin asks about openstreet virtualization openshift virtualization is the productized version of what you've just seen. It's a product shipped by a red hat, it's on a different source, it's in reddit operators, source and not in community operators.

C

um The current version is five is two five three. uh In the upcoming month, we are releasing two six which is uh um supported in openshift 4.7 on the next version. We are aligning the versions and uh it will be cnv sorry open shift utilization, a 4.8 for openshift 4.8 and in the upstream, the version.

C

The latest version is 1.4.

B

C

Another questions.

A

B

A

B

A

That that looks like all the questions.