Introducing OKD Virtualization
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Tiraboschi, Simone
Bonazzola, Sandro
OKD Virtualization is the community project bringing traditional virtualization technology into OKD. Meet the OKD Virtualization community and learn about it! OKD Virtualization is the community project bringing traditional virtualization technology into OKD. It’s built on top of the KubeVirt project and the Hyperconverged Cluster Operator project. HCO ensures a single installable unit for Kubevirt and its sibling components leveraging the operator framework to provide the easiest way of installing and maintaining this additional control plane. This bundle will ship additional tools required to do traditional virtualization tasks like uploading disk images, host network configuration, local storage provisioning, and other functionality which is not covered by the core KubeVirt. On top of this a user interface embedded within the OKD Console is provided for managing the lifecycle of the Virtual Machines. Virtual Machines from other virtualization systems can be imported into OKD Virtualization leveraging the Konveyor Forklift project. Meet the OKD Virtualization community and learn about it! After this session you will Know what KubeVirt is Know what HCO (Hyper Converged Cluster Operator) is and how it relates to KubeVirt How the OKD UI is presenting VMs A rough idea of the featureset of what this setup provides Seen a demo, and knowledge of how to set this up yourself.
 Good afternoon. My name is Sandro Bonazzola. I'm a manager working for Red Hat and within the OKD World Group, I'm focusing on the virtualization related topics. Today, Simone Tiraboschi, Red Hat Principal Software Engineer working within OpenShift Virtualization Product, is here with me for introducing you to OKD Virtualization. Due to time constraints, it will be a very quick introduction. So if you find the topic interesting, I would like to invite you to join the conversation within the OKD community and learn more about it. OKD Virtualization is the community project bringing traditional virtualization technology into OKD. It's built on top of the CUBIR project and the Hyperconverged Cluster Operator project. For those who don't know OKD, it's a sibling Kubernetes distribution to Red Hat OpenShift. If you're not familiar with OpenShift, you can think of it as a Kubernetes distribution which extends the vanilla Kubernetes with security and other integrated concepts, adding developer and operation-centric tools. The OKD World Group Board is composed by members from Red Hat and the University of Michigan. OKD is deployable on many different infrastructure platforms, from bare metal to cloud. It is suitable for a wide array of deployments from small-edge clusters to massive compute workloads. But for OKD Virtualization's scope, we focus on the bare metal on premiums deployment. So what is CUBIR? CUBIR is a Kubernetes Virtualization API and all its runtime in order to provide a control plane, an additional control plane, to let the user define and manage virtual machines. What do we mean with virtual machines in Kubernetes? Our virtual machines are running in containers and they are based on the standard KVM stack. They are going to be scheduled and deployed and managed by Kubernetes as a native object and they are going to be integrated with the standard mechanism to let Kubernetes provide access to containers and ports. So there is the traditional pod-like software defined network connectivity for them and they are going to be baked off by the persistent storage paradigm that is commonly used in the Kubernetes super systems volume clays, persistent volume storage classes. Why CUBIR? The main advantage, the main benefit of CUBIR is that you can use virtual machines and containers together. CUBIR follows the standard Kubernetes paradigms. So you can use container networking interfaces, CNA drivers, you can use container storage interfaces, CSA drivers and the virtual machines are defined as a via customer source definition so that you can manage them as customer sources to be able to manage them as a native Kubernetes object. Just a few words on the CUBIR textures. This is pretty complex and it deserves a separate discussion. Basically on each node there is a control layer named the vith handler. Each virtual machine is basically a pod that contains LibVirt and QEmo that runs the virtual machine as a process. That pod runs on each, can run on each configurable node alongside other pods that contains standard containers. All of them is managed by an additional API server that provides this additional control plane. Now what is HCO? HCO is the hyperconverged cluster operator. CUBIR project provides virtualization capabilities on top of Kubernetes, but in order to get a full and complete experience you need also sibling components like a storage operator to be able to import the disks of virtual machines and you need a network-related operator to be able to plumb the network connection, to easily configure and plumb the network connections for your virtual machines. So the hyperconverged cluster operator is going to deploy the CUBIR operator and all of those sibling operators, so the virt, the storage, the network ones, as a single install label unit and it's going to provide a single upgrade path for all of them so that they can be upgraded altogether in a controlled way. Then HCO is going to provide a single entry point to let the cluster admin configure the whole virtualization subsystem from a single control point. How can I get it? The CUBIR type hyperconverged cluster operator is available out of the box in operator app.io and it's also available as we see in the next demo in the OKD community operator's catalog. It's almost a single click install. If you're curious about how does it look like when all the pieces are put together, here you can see the installed operator's dashboard provided by OKD. Simone is going to give a brief demo on how to get them installed in a minute. On top of this, a user interface embedded within the OKD console is provided for managing the lifecycle of the virtual machines, the star of this presentation. OKD provides an UI built on top of the functionality provided by HCO and its operands. It's just a screenshot of the virtualization UI. Simone is going to give a short demonstration on how to use it. And if you are already using a virtualization solution, well, we're the machine from other virtualization systems can be imported into OKD virtualization, leveraging the conveyor forklift project. We are not going to show a demo for it due to time constraints, but you can see an end to end demonstration on the conveyor YouTube channel. And now Simone, it's demo time. OK, welcome to the demo. So this is OKD. OKD is already installed on a bare meta cluster. Installing OKD is not part of this demo. OKD is already there. We can see that we are using OKD 4.9.0, which is the latest version from the end of December. We can see that we stole the data on a pretty small cluster composed of three master nodes and with the three worker nodes. All of them are bare meta and are capable of running virtual machines. We also already configured the persistent storage for this cluster. More specifically, we choose to configure it with Rook.io to provide a safe, basic persistent storage. You can see that we have a customer source for safe. It's called a self cluster. We have an instance of it. And in the demo, we can check its status. It's managed by RookSafe. And you can see that the self cluster is in a health condition and it's up and running. And it's able to host the persistent disks for our virtual machines. Now let's go back to the operator-app page. In operator-app, we have multiple catalogs. We can look for operators by name, by keywords. If we type a Qubivit, we will find the Qubivit app because the Azure cluster operator. You can click on install. The first page will let you tune the installation. We're going to install it from the stable channel with automatic updates. Now we see that the operator is getting installed. We cut a bit the recording of the demo just to speed it up, but the install process is really, really fast. We are talking about two minutes. Now we see that the operator is ready and we can create its customer source to trigger the operator and configure our virtualization cluster. Here we have a lot of options to tune the virtualization subsystem. For instance, we can enable or disable specific feature gates. We can configure host devices that are going to be exposed to our virtual machines and so on. This is something that is up to the cluster admin. This is the configuration of the virtualization subsystem for the world cluster. The user is supposed to create a single, the cluster admin is supposed to create a single customer source for the world cluster. Now we see that the hyperconverged cluster operator created the customer source to trigger other operators and it's watching their progress. We see that now the cube virtual converged cluster operator is installing other components. Here it depends on the time, but also this phase it's pretty fast and not as in the video, but it's still pretty fast. Now we see that the product is successfully installed and we can see that under the workloads we have a new entry which is the virtualization UI. It wasn't there before. In the virtualization UI we find a tab to manage virtual machines and an additional tab to manage templates. In our case we want to create virtual machines from templates. The templates are already there, but they don't contain the disk with the operative system that you need for your guest virtual machines. But you can easily provide a new URL to have the cluster downloading it from the cloud. Now I'm filling in the details for the CentOS template. I can do the same on the Fedora template. Also in this case I can choose to import the operative system and the OS image available in the cloud. I have only to provide the URL to download the base image. I can eventually tune it choosing to use a particular storage class. In this case we have only one which is the RookSeth one. We see that the cluster is now importing the base images that we want to make available in our cluster. As you can imagine we have a set of predefined templates but you can also define your customer once. Now we see that in the kubivirt OS images namespace our operators created some persistent volumes to store the base images for our Fedora CentOS-based virtual machines. Now the cluster is importing the disks from the cloud. You can see that there is also progress bar to monitor the importing process. We are importing CentOS and Fedora OS disks at the same time. We cut a bit of the demo. Now Fedora completed and CentOS is still in progress. Now that my templates are ready I can choose to create my first virtual machine starting from one of the templates that is ready to be used. Now you see that Fedora template is green. I click on it. I can customize my virtual machine. I can even choose to create on the fly a Kubernetes service to expose my to expose the SSH part of my virtual machine over a Kubernetes service. Because as I said before by default the virtual machines are running on the border network. As you can see I can also add additional network cards on eventually even on a different network kind. As you can imagine I can easily kill my virtual machine and add additional disks. In this case I'm adding 20 gigabytes of disks in addition to the base disk with the interactive system. Also the disk will be baked by myself. Then I can use a crowd unit or a sysplap or whatever I need to get my virtual machines automatically configured. Now the virtual machine is ready and I created it in the default namespace. As you can imagine virtual machines are namespace objects. So in my cluster I have more than one namespace and I can have a virtual machine container and confine it to each namespace. Now the storage sub system is cloning the disk of my virtual machine starting from the template one. Then we show a lot about the UI but as I said before virtual machine is a native Kubernetes object. So it's represented by a CR according to a customer source definition. The CR is an instance that you can play also with. There is a lot of API that you can use to tune the details of your virtual machines. For instance you can change the mac address, you can play with that, you can also check the status of that specific virtual machine instance. Now my virtual machine is finally running. I can go to the console, it's a VNC console. My virtual machine got configured by CloudInit so there is a randomly generated password for that but of course I can also specify a custom one. I'm able to login via VNC to my virtual machine and I can play with it. If I started a virtual machine probably I already know what I'm going to do with that. It's just a simple demo, just playing with my virtual machine. My virtual machine is available for you. So if we go back to the main virtualization tab we see that the virtual machine is running on the VNODE. It's called a boost-trap machine. This is the name of the node. As you can see I can perform all the standard actions that you expect to be available for virtual machines. I can also trigger live migration of my virtual machine. So the virtual machine that was running on the bootstrap node is now going to be live-immigrated to a different node in the cluster. As you can see the virtual machine is now in migrating status. All of the disk of my virtual machine was back at by Rooksef. They were shared the disks so the virtual machine can be easily live-immigrated and the disks are available for all the nodes. According to the capability of the Stragisap system I can eventually create a snapshot. The snapshotting mechanisms can be eventually completely ended by the Stragisap system via the CSI driver. We also announced OKD adding a cube-virtue-specific dashboard which contains some graphs based on the virtual machine-specific matrix. We introduced a lot of matrix with relevant data for all of your virtual machines. Then we created this dashboard with the most useful graph for virtual machines. You can also access individual data as a each specific metric and you can create alerts based on the values of those matrix. Everything now has been performed in the administration perspective in OKD but as a regular developer that is using my cluster, I'm supposed to use the developer perspective which is this one. Here I can see a simple switcher perspective to the developer one. I see that I can still see my virtual machine but it's still running. I can see it as a developer managing my application in my developer perspective. As I said before, the virtual machine is basically a pod. Here I can see the blocks of that pod. I'm just showing this to see the control that a regular developer has over his virtual machine. Still as a developer, I can choose to create a new virtual machine. In that case, the virtual machine is based in this case, I'm available only to create virtual machines according to the templates that the cluster admin's decided to make available for me. The centers were still important so just Fedora was available now. Here I can create a second virtual machine still based on Fedora. The two objects are now available in my name space. Just a curiosity, if I check the first virtual machine that is still running, now I see that it's running on a different node, namely the worker. So the live migration has successfully converged. I can see that associated with my virtual machine, I see the Kubernetes service to expose the SSH part of my virtual machine over the unnamed Kubernetes service. A different one for my second virtual machine, of course. Now we see that the virtual machine is starting. We can monitor its status. We see that the cloning process is still pending. Another interesting thing is that we're also providing CLI-based tool to interact with virtual machines. It's named VHCTL. It's installed. The virtual cluster operator makes it integrated into OKD so you can get it somewhere in the UI. It's already available in your cluster. Now we can quickly see how we can integrate with a forklift. Forklift is also available as an operator. You can install forklift operator. Forklift installation is in progress. The operator is ready. You should create a customer source to trigger it. Now we see that under conveyor-forklift namespace forklift operator is starting. All the ports it needs to act to import virtual machines and so on. After a couple of minutes, forklift is ready. If you go back to the main virtualization tab, you see that now there is a new button called the import virtual machine that is opening the forklift UI to let you import virtual machines. We are not going to demo it right now. You can find forklift demo on YouTube. If we go back to the perconverter cluster operator, we see that as all the operators managed by the operator or the cycle manager, we choose to install the thermal specific update channel so that we are going to get automatic updates for that. The operator is managing a lot of ports in the cube virtual hyperconverter namespace. As you can see, the most critical ports, so the API servers and so on are running with multiple instance to provide availability. Thanks, Simone. If you want to learn more about OKD, here you can find references for getting in touch with the workgroup. If you are interested in the virtualization aspects of OKD, here are a few dedicated pointers. Thank you, everyone, for joining. If you have questions, we are here to answer them in a few minutes. Ciao!
 Good afternoon. My name is Sandro Bonazzola. I'm a manager working for Red Hat and within  the OKD World Group, I'm focusing on the virtualization related topics. Today, Simone  Tiraboschi, Red Hat Principal Software Engineer working within OpenShift Virtualization Product,  is here with me for introducing you to OKD Virtualization. Due to time constraints,  it will be a very quick introduction. So if you find the topic interesting, I would like to invite  you to join the conversation within the OKD community and learn more about it. OKD Virtualization  is the community project bringing traditional virtualization technology into OKD. It's built on  top of the CUBIR project and the Hyperconverged Cluster Operator project. For those who don't  know OKD, it's a sibling Kubernetes distribution to Red Hat OpenShift. If you're not familiar with  OpenShift, you can think of it as a Kubernetes distribution which extends the vanilla Kubernetes  with security and other integrated concepts, adding developer and operation-centric tools.  The OKD World Group Board is composed by members from Red Hat and the University of Michigan.  OKD is deployable on many different infrastructure platforms, from bare metal to cloud. It is  suitable for a wide array of deployments from small-edge clusters to massive compute workloads.  But for OKD Virtualization's scope, we focus on the bare metal on premiums deployment.  So what is CUBIR? CUBIR is a Kubernetes Virtualization API and all its runtime in order to provide a  control plane, an additional control plane, to let the user define and manage virtual machines.  What do we mean with virtual machines in Kubernetes? Our virtual machines are running in  containers and they are based on the standard KVM stack. They are going to be scheduled and  deployed and managed by Kubernetes as a native object and they are going to be integrated  with the standard mechanism to let Kubernetes provide access to containers and ports.  So there is the traditional pod-like software defined network connectivity for them  and they are going to be baked off by the persistent storage paradigm that is commonly  used in the Kubernetes super systems volume clays, persistent volume storage classes.  Why CUBIR? The main advantage, the main benefit of CUBIR is that you can use virtual machines  and containers together. CUBIR follows the standard Kubernetes paradigms. So you can use  container networking interfaces, CNA drivers, you can use container storage interfaces,  CSA drivers and the virtual machines are defined as a via customer source definition so that you  can manage them as customer sources to be able to manage them as a native Kubernetes object.  Just a few words on the CUBIR textures. This is pretty complex and it deserves a separate  discussion. Basically on each node there is a control layer named the vith handler. Each  virtual machine is basically a pod that contains LibVirt and QEmo that runs the virtual machine  as a process. That pod runs on each, can run on each configurable node alongside other  pods that contains standard containers. All of them is managed by an additional API server  that provides this additional control plane. Now what is HCO? HCO is the hyperconverged cluster  operator. CUBIR project provides virtualization capabilities on top of Kubernetes, but in order  to get a full and complete experience you need also sibling components like a storage operator  to be able to import the disks of virtual machines and you need a network-related operator to be able  to plumb the network connection, to easily configure and plumb the network connections for  your virtual machines. So the hyperconverged cluster operator is going to deploy the CUBIR  operator and all of those sibling operators, so the virt, the storage, the network ones,  as a single install label unit and it's going to provide a single upgrade path for all of them  so that they can be upgraded altogether in a controlled way. Then HCO is going to provide a  single entry point to let the cluster admin configure the whole virtualization subsystem  from a single control point. How can I get it? The CUBIR type hyperconverged cluster operator  is available out of the box in operator app.io and it's also available as we see in the next demo  in the OKD community operator's catalog. It's almost a single click install.  If you're curious about how does it look like when all the pieces are put together,  here you can see the installed operator's dashboard provided by OKD. Simone is going to  give a brief demo on how to get them installed in a minute. On top of this, a user interface embedded  within the OKD console is provided for managing the lifecycle of the virtual machines, the star  of this presentation. OKD provides an UI built on top of the functionality provided by HCO and  its operands. It's just a screenshot of the virtualization UI. Simone is going to give a  short demonstration on how to use it. And if you are already using a virtualization solution,  well, we're the machine from other virtualization systems can be imported into OKD virtualization,  leveraging the conveyor forklift project. We are not going to show a demo for it due to time  constraints, but you can see an end to end demonstration on the conveyor YouTube channel.  And now Simone, it's demo time.  OK, welcome to the demo. So this is OKD. OKD is already installed on a bare meta cluster.  Installing OKD is not part of this demo. OKD is already there.  We can see that we are using OKD 4.9.0, which is the latest version from the end of December.  We can see that we stole the data on a pretty small cluster composed of three master nodes  and with the three worker nodes. All of them are bare meta and are capable of running virtual machines.  We also already configured the persistent storage for this cluster. More specifically,  we choose to configure it with Rook.io to provide a safe, basic persistent storage.  You can see that we have a customer source for safe. It's called a self cluster.  We have an instance of it. And in the demo, we can check its status. It's managed by RookSafe.  And you can see that the self cluster is in a health condition and it's up and running.  And it's able to host the persistent disks for our virtual machines.  Now let's go back to the operator-app page. In operator-app, we have multiple catalogs.  We can look for operators by name, by keywords. If we type a Qubivit, we will find the Qubivit  app because the Azure cluster operator. You can click on install. The first page will let you tune  the installation. We're going to install it from the stable channel with automatic updates.  Now we see that the operator is getting installed. We cut a bit the recording of the demo just to  speed it up, but the install process is really, really fast. We are talking about two minutes.  Now we see that the operator is ready and we can create its customer source to trigger the  operator and configure our virtualization cluster. Here we have a lot of options to tune  the virtualization subsystem. For instance, we can enable or disable specific feature gates.  We can configure host devices that are going to be exposed to our virtual machines and so on.  This is something that is up to the cluster admin. This is the configuration of the  virtualization subsystem for the world cluster. The user is supposed to create a single,  the cluster admin is supposed to create a single customer source for the world cluster.  Now we see that the hyperconverged cluster operator created the customer source to trigger  other operators and it's watching their progress. We see that now the cube virtual  converged cluster operator is installing other components.  Here it depends on the time, but also this phase it's pretty fast and not as in the video,  but it's still pretty fast. Now we see that the product is successfully installed and we can  see that under the workloads we have a new entry which is the virtualization UI. It wasn't there  before. In the virtualization UI we find a tab to manage virtual machines and an additional  tab to manage templates. In our case we want to create virtual machines from templates.  The templates are already there, but they don't contain the disk with the operative system that  you need for your guest virtual machines. But you can easily provide a new URL to have the cluster  downloading it from the cloud. Now I'm filling in the details for the CentOS template.  I can do the same on the Fedora template.  Also in this case I can choose to import the operative system and  the OS image available in the cloud. I have only to provide the URL to download the base image.  I can eventually tune it choosing to use a particular storage class. In this case we have  only one which is the RookSeth one. We see that the cluster is now importing  the base images that we want to make available in our cluster. As you can imagine we have a  set of predefined templates but you can also define your customer once.  Now we see that in the kubivirt OS images namespace our operators created  some persistent volumes to store the base images for our Fedora CentOS-based virtual machines.  Now the cluster is importing the disks from the cloud.  You can see that there is also progress bar to monitor the importing process.  We are importing CentOS and Fedora OS disks at the same time.  We cut a bit of the demo. Now Fedora completed and CentOS is still in progress.  Now that my templates are ready I can choose to create my first virtual machine starting  from one of the templates that is ready to be used. Now you see that Fedora template is green.  I click on it. I can customize my virtual machine. I can even choose to create on the fly a Kubernetes  service to expose my to expose the SSH part of my virtual machine over a Kubernetes service.  Because as I said before by default the virtual machines are running on the  border network. As you can see I can also add additional network cards on  eventually even on a different network kind. As you can imagine I can easily kill my  virtual machine and add additional disks. In this case I'm adding 20 gigabytes of disks  in addition to the base disk with the interactive system.  Also the disk will be baked by myself. Then I can use a crowd unit or a sysplap or whatever I need  to get my virtual machines automatically configured. Now the virtual machine is ready and I created it  in the default namespace. As you can imagine virtual machines are namespace objects. So in my  cluster I have more than one namespace and I can have a virtual machine container and confine it to  each namespace. Now the storage sub system is cloning the disk of my virtual machine starting  from the template one. Then we show a lot about the UI but as I said before virtual machine is a  native Kubernetes object. So it's represented by a CR according to a customer source definition.  The CR is an instance that you can play also with. There is a lot of API that you can use to  tune the details of your virtual machines. For instance you can change the mac address,  you can play with that, you can also check the status of that specific virtual machine instance.  Now my virtual machine is finally running. I can go to the console, it's a VNC console.  My virtual machine got configured by CloudInit so there is a randomly generated password for that  but of course I can also specify a custom one. I'm able to login via VNC to my virtual machine and  I can play with it. If I started a virtual machine probably I already know what I'm going to do with  that. It's just a simple demo, just playing with my virtual machine. My virtual machine is available for you.  So if we go back to the main virtualization tab we see that the virtual machine is running on  the VNODE. It's called a boost-trap machine. This is the name of the node. As you can see I can  perform all the standard actions that you expect to be available for virtual machines. I can also  trigger live migration of my virtual machine. So the virtual machine that was running on  the bootstrap node is now going to be live-immigrated to a different node in the cluster. As you can  see the virtual machine is now in migrating status. All of the disk of my virtual machine was back at  by Rooksef. They were shared the disks so the virtual machine can be easily live-immigrated and the  disks are available for all the nodes. According to the capability of the Stragisap system I can  eventually create a snapshot. The snapshotting mechanisms can be eventually completely ended  by the Stragisap system via the CSI driver. We also announced OKD adding a cube-virtue-specific  dashboard which contains some graphs based on the virtual machine-specific matrix. We  introduced a lot of matrix with relevant data for all of your virtual machines. Then we created  this dashboard with the most useful graph for virtual machines. You can also access individual  data as a each specific metric and you can create alerts based on the values of those matrix.  Everything now has been performed in the administration perspective in OKD but  as a regular developer that is using my cluster, I'm supposed to use the developer perspective  which is this one. Here I can see a simple switcher perspective to the developer one.  I see that I can still see my virtual machine but it's still running.  I can see it as a developer managing my application in my developer perspective.  As I said before, the virtual machine is basically a pod. Here I can see the blocks of that pod.  I'm just showing this to see the control that a regular developer has over his virtual machine.  Still as a developer, I can choose to create a new virtual machine. In that case, the virtual machine  is based in this case, I'm available only to create virtual machines according to the templates  that the cluster admin's decided to make available for me. The centers were still  important so just Fedora was available now. Here I can create a second virtual machine still based  on Fedora. The two objects are now available in my name space.  Just a curiosity, if I check the first virtual machine that is still running,  now I see that it's running on a different node, namely the worker.  So the live migration has successfully converged.  I can see that associated with my virtual machine, I see the Kubernetes service to  expose the SSH part of my virtual machine over the unnamed Kubernetes service.  A different one for my second virtual machine, of course.  Now we see that the virtual machine is starting. We can monitor its status.  We see that the cloning process is still pending.  Another interesting thing is that we're also providing CLI-based tool to interact with  virtual machines. It's named VHCTL. It's installed. The virtual cluster operator makes it  integrated into OKD so you can get it somewhere in the UI. It's already available in your cluster.  Now we can quickly see how we can integrate with a forklift. Forklift is also available as an  operator. You can install forklift operator. Forklift installation is in progress.  The operator is ready. You should create a customer source to trigger it.  Now we see that under conveyor-forklift namespace forklift operator is starting.  All the ports it needs to act to import virtual machines and so on.  After a couple of minutes, forklift is ready. If you go back to the main virtualization tab,  you see that now there is a new button called the import virtual machine that is opening  the forklift UI to let you import virtual machines. We are not going to demo it right now.  You can find forklift demo on YouTube. If we go back to the perconverter cluster operator,  we see that as all the operators managed by the operator or the cycle manager,  we choose to install the thermal specific update channel so that we are going to get  automatic updates for that. The operator is managing a lot of ports in the cube  virtual hyperconverter namespace. As you can see, the most critical ports, so the API servers and  so on are running with multiple instance to provide availability.  Thanks, Simone. If you want to learn more about OKD, here you can find references  for getting in touch with the workgroup. If you are interested in the virtualization  aspects of OKD, here are a few dedicated pointers. Thank you, everyone, for joining.  If you have questions, we are here to answer them in a few minutes.  Ciao!
vai_intro_okd_0_1427.png vai_intro_okd_1428_2663.png vai_intro_okd_2664_10607.png vai_intro_okd_10608_11183.png vai_intro_okd_11184_12227.png vai_intro_okd_12228_13295.png vai_intro_okd_13296_15863.png vai_intro_okd_15864_16247.png vai_intro_okd_16248_16451.png vai_intro_okd_16452_16823.png vai_intro_okd_16824_16883.png vai_intro_okd_16884_19859.png vai_intro_okd_19860_20183.png vai_intro_okd_20184_21023.png vai_intro_okd_21024_21131.png vai_intro_okd_21132_22247.png vai_intro_okd_22248_24395.png vai_intro_okd_24396_25367.png vai_intro_okd_25368_26207.png vai_intro_okd_26208_26447.png vai_intro_okd_26448_26759.png vai_intro_okd_26760_28139.png vai_intro_okd_28140_29651.png vai_intro_okd_29652_30107.png vai_intro_okd_30108_30383.png vai_intro_okd_30384_30755.png vai_intro_okd_30756_33563.png vai_intro_okd_33564_35051.png vai_intro_okd_35052_36875.png vai_intro_okd_36876_36971.png vai_intro_okd_36972_37787.png vai_intro_okd_37788_37835.png vai_intro_okd_37836_37943.png vai_intro_okd_37944_38411.png vai_intro_okd_38412_38567.png vai_intro_okd_38568_38831.png vai_intro_okd_38832_40987.png