 I'd like to thank everybody who is joining us today. And welcome to today's CNCF webinar, Challenges in Deploying Kubernetes on Hyperconverged Infrastructures. So two things, yeah, we'll go back, let me do our KubeCon slide. I do want to also remind everybody that KubeCon, CloudNativeCon, North America are flagship event and it is coming up in November in San Diego. It should still be very sunny, lovely in November. And this is, as many of you who have attended before, this is a time for the community to come together to further their education in advanced CloudNative computing. You can go to kubecon.io for more information, get your ticket, and we're expecting about 12,000 people and to sell that out. So before we get started, I'd like to also go through a few housekeeping items. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen. Please feel free to drop your questions in there. And the team from Diamante will go ahead and answer them throughout the presentation. Now with that, I would like to kick it over to Narendh, who is going to introduce today's presenters and kick off the webinar. Thanks, Kim. Good morning, good afternoon, good evening, folks, wherever you are, greetings. So I am Narendh Narendra, Director of Product Marketing at Diamante, along with me, I have Naveen Seth, who is the Founding Engineer at Diamante and Hiral Patel, Founding Engineer at Diamante. All right, so today, we're going to take you through the background of AWS EC2 Evolution as an example. Hi, Naveen here, and I'll be discussing the challenges and some of the option solution technologies available from network and storage and when this transformation goes, is cloud native applications that's happening and this is from context of HCI platform. Hi, this is Hiral, and at the last I'll do a demo for deploying a container workload and also the virtualize KVM workload onto the same HCI infrastructure using the same Kubernetes cluster and we'll wrap up with Q&A. All right, thank you, Hiral. So let's take you through some evolution here for the next few minutes. Credit goes to the two stalwarts at Amazon Web Services, also known as AWS Jerry Hargrove, who is very famously known as AWS Geek, looking him up as AWS Geek and you'll find lots and lots and lots of beautiful pictures about how things work, how things are architected at AWS and this picture, this is a part of the picture from one of Jerry Hargrove's drawings. Credit also goes to James Hamilton, who is a distinguished engineer at AWS, been at AWS forever and there's a bunch of publications that he has done through MB Drona and others that we're gonna use today to walk you through some of the evolutionary aspects of the EC2 compute instance at AWS. So it all began this way for all of us, anybody in IT, this is a standard picture, right? And this is the crawl phase of what Jerry calls it as for an Amazon compute instance and this is specifically Amazon EC2 instance and if you go back to history, the first incarnation of EC2 came about in 2006, all right? And up to 2013, this was the constant picture for any compute node or host at AWS. And if you look at this picture, it's got hardware, on top of hardware is software, software that runs networking, that runs storage, provides management, security, monitoring. There is a layer of hypervisor and on top of the hypervisor, you deploy virtual machines which are also known as instances. But in effect from 2006 all the way to about 2013, if you look at what James Hamilton has written, he basically sums it up in one sentence which is networking is in effect in the way and blocking the efficient optimization of valuable resources in the data center. So why is this? A server is the most expensive component in a data center, a server and all the components that go into a server. And think about it, every data center for a public cloud provider like AWS, there's hundreds and hundreds of server in any data center. And if that's the most valuable asset that you have, something else coming in and coming in your way of efficient utilization means a lot in terms of the cost, means a lot in terms of the capabilities at which they have to provide to the customers. So let's take a look at now and see how this EC2 instances evolved over time. So this is the big picture from AWS Geek of which I took a part of it to explain and kick this conversation off. And you can find this again at awsgeek.com. So let's walk from the left hand side or crawl from the left hand side and try to walk by the end of it. So what we see on the left hand side here is the picture from EC2 instance circa 2013, all right? In 2013, Amazon introduced the Nitro card or the Nitro system. By using the Nitro system, they offloaded the networking component which was running in software onto a hardware offload known as Nitro. And this Nitro system was built on carts, meaning commercial off-the-shelf components. And basically just by doing this, they got 20% additional bandwidth on the network. And this is the C3 instance. So there's the evolution from C2 to C3, 20% additional bandwidth and 50% latency reduction. So your latency went on by 50% reduced performance variability which means you could expect much more deterministic performance when you ran something, ran a virtual machine on top of the system compared to an EC2 system, all right? So that was the first technique that they used to offload the network, of course, the taste was good. So next comes C3 instance and that was one year later in 2014. And with the introduction of Annapurna, at that time the storage subsystem or the storage system which was running in software got moved to hardware offload and that was also a cart system meaning off-the-shelf system, ASIC based. And by now moving the storage component to the hardware layer to offload the system, they gained 12.5% more compute out of the environment. What that means is if we have 100 data centers previously, they basically eliminated at least 12 of them. That's huge, huge, huge cost savings, first of all. On top of that, it's not only about cost, it's also about performance, it's also about latency reduction, it's also about QoS type of treatment to traffic across the data center. So that was C4, all right? So now in 2015, a year later, the EC5 instance was introduced and following the same suit, the management security and monitoring layers were pushed down to the hardware layer, again with another hardware offload mechanism. And do note here that by moving that, Amazon achieved separation of control and data plane, which is very critical so that there is granular control of the system overall and 100% compute availability. So essentially again, more savings, more performance, more compute, which means more margins, more wiggle room to play with and more applications to be onboarded onto the same infrastructure because of higher performance. So there is a few things though that we need to compare and contrast here. By the time we got to the C5 instance, the Annapurna system, which was used for the management, security and monitoring was based off a custom ASIC, not COTS, all right, that's just, that's what it is, that's what the picture says. As well as one other aspect here is the hypervisor layer stayed on from left to right. However, the hypervisor on the first three is different from the hypervisor on the right-hand side because the right-hand side hypervisor is known as the nitro hypervisor with additional capabilities to enable certain other applications to be run on the system, all right. So by separating control and data plane, they also were able to easily do billing of instances and so on, all right. So now this is the evolution that's happened over a period of time. So in summary, half-loading, storage, networking capabilities onto COTS-based systems or custom ASIC-based systems provides us better, reduces performance variability, provides us with better performance, reduces latency and so on, all right. So let's have that in our mind and the evolution in mind and let's see how data center is awarded over a period of time. So here for your reference, these are the four variations or the form factors of the AWS Nitro Cards for your reference. There's the URLs, take a look at them at your free time. So now let's go and take a look at how data center looks today, how hyperconversion infrastructure in a data center looks today and what are some of the parallels that we can draw from public cloud providers like AWS and see where we can land or where we should be heading towards in the data center. So here's a picture and I'll walk you through this from left-hand side to right-hand side in the next couple of minutes and there's a little bit of a reality here. There's a little bit of a fiction here and then there's a little bit of a reality here. So I will tell you why I am saying that in such a funny manner. All right, so let's start from the left-hand side here. So it's known, first of all, hyperconversion infrastructure is the de facto infrastructure that's being deployed in the data center today in every enterprise, in every service provider environment for any IT workload deployment, all right? So with hyperconversion 1.0, the pioneers of HCI, visa-based, Nutanix, VMware, as you all know, networking, storage, compute onto a single node or single server, they're basically bringing more efficiencies in terms of packing things into a server. At the same time, what we also observed with hyperconversion 1.0 is that host is heavily taxed in terms of utilization and performance. There is applications starvation due to the way that virtual machines run on an hypervisor environment, the noisy neighbor problems persisted. SLAs could be only guaranteed to a certain extent or maybe not at all at some times. And it costed a whole bunch of money still to deploy these systems. Keep that 1.0 picture in mind. Now let's take the learnings from AWS and say what if we offloaded the networking component in an HCI 1.0 environment and made that HCI 1.5, right? So that is the second picture from the left-hand side. All right, let's fast forward. What if we also learned from the storage evolution in AWS and offloaded that onto another storage system in hardware, okay, that's HCI 2.0. That's basically following AWS Azure and AWS in terms of outpost and Nitro that you might have seen some announcements on, right? So if this is a what-is scenario where if we had offloaded both networking storage onto HCI 2.0, we would have gotten much more efficiencies in parallel with what AWS got with respect to networking storage and so on. However, hypervisor still remained in the picture. Not only that, let's also take a look at the current HCI solutions that we have in the market today, right? In all of the HCI solutions that are available today, the instant storage, which is also known as is always in a pooled storage environment. It is never in a cloud providers have been able to solve this problem with hardware offloads and other mechanisms to actually provide an instant storage on the host. That brings a lot of efficiencies. That provides the QoS capabilities that is critically needed for a workload to run in the environment. So that's absolutely missing today, all right? So Diamante looked at these progress being made in the industry as well as the learnings that we picked up along the way and we adopted these things right from day one in our approach to building the hyper-continuous infrastructure for Kubernetes. So at Diamante, we have networking and storage offloads along with open-source Kubernetes packaged together for a cloud-native infrastructure. We are able to achieve 95% host-illus utilization. The hypervisor is completely eliminated. There is no noisy neighbor problems. All those are taken care of due to the way the hardware offload works for both networking and storage. SLA guarantees can be provided to as granular as 100 microseconds of latency came out there. They're not given a white piece of paper every day or a blank piece of paper every day to restart their IT environment. They will always have a set of legacy workloads which may not be containerized at all, which are yet to be containerized. So they would need to run a virtual machine-based environment. So how would we solve that problem? In the CNCF community, the community has together brought forward the notion of CNV or container-native virtualization. And Kubeboard is one of the projects in this, under this umbrella. Within Kubeboard, the idea is to, using, leveraging Kubeboard, the idea is to run containers and virtual machine as equal citizens on the same infrastructure, which is Ipoconverse 3.0 plus here, with Kubernetes as the orchestrator. And why is this important? This is important because regardless of the workload, whether it's a container, whether it's a virtual machine, they both can be orchestrated using Kubernetes. They are a set of part specs and you deploy a container, you deploy a set of containers, you deploy a virtual machine or a set of virtual machines. It's the same mechanism, it's the same tool, it's the same learning, it's the same training that you need to have. And this is very important because simplicity drives efficiency, simplicity drives debugability, simplicity drives a whole lot of things. And this is where the CNCF community is heading towards. And you might have seen some announcements a couple of weeks ago from VMware in terms of taking certain Kubernetes components and plugging them into the vSphere environment. The most important aspect to observe there is that for anybody to run a virtual machine, they have to go through the vSphere way of doing things, whereas when somebody wants to light up a set of containers, they will have to go through a different path. And that results in two sets of tools for two different workload types, two different training, two different, you know, multiple training sessions, et cetera, et cetera, et cetera. So that kind of comes in the way of simplicity, essentially. Now, with that background, let me hand you over to Naveen to walk through some of the critical requirements to run containers in ACI environment. Sure. Hey, thanks, Naveen. Thanks for walking through the whole evaluation process that happened over these few years. Let's now look at the requirements that came up during this process, right? I mean, if you step back five years or so, container technology had just started being touted as the next wave of disruption. The way applications will be deployed and delivered. And this with oncoming change, the requirements for an ACI platform had to be revisited. So let's look at from just containerized applications perspective, right? You have multiple applications running. What are the new requirements from network and storage side from this perspective? You want multiple applications, but you want guaranteed SLAs for these applications from network and storage. You want consistency in performance, predictability in performance. So what does it map to? On network side, if you look at it, the technology had already started, it was already out there. SRIOV was already proven. They were already off the shelf chips that could guarantee performance, that could give hardware cues to your application, right? These allowed you to program minimum guarantees, maximum limits at each container level, at each virtual function level. That virtual function could always be extended to container. Let's extend this on the storage side. Around the same time, NVMe started becoming standardized. So now you could have the same way you had it on networking side, you could have virtual functions, which could map to namespaces at the storage layer, where you could have hardware cues for each of these virtual functions. And then you could basically guarantee, minimum guarantee, as well as put maximum limits on each of these virtual functions, basically meaning for each application, you could guarantee a certain amount of IOPS, you could limit a certain amount of IOPS. Now, going back to referring to Narene's one of the slides, this evolution that happened, there was a physical aspect also that was out there. Networking side, the bandwidths were going from 10 gig to 25 gig or 40 gig, 50 gig and even 100 gig with sub millisecond latency. Similarly on the storage end, we are talking about a million IOPS becoming very normal, again at sub millisecond level. So with all this in mind, now you have to really review, revisit how your HCI platform is going to look at. Move one year forward and Kubernetes starts getting a strong foothold as the orchestration platform of choice. From multiple applications running on a node, your transition to multiple instances of applications running on multiple nodes and handling of application failover is now part of the core design of this orchestration platform. Through different SIG groups and CS playing of course an important role here, the CNI and CSI standards evolved. I mean of course, flex volume being a precursor for this on the CSI side and on the scheduler side, a way to extend the scheduler, which was way more aware, could take decision more intelligently based on its knowledge of the resources of the underlying hyperconverging infrastructure. So let's look at networking and storage side requirements that came up because of that. On the networking side, IP address or network endpoint being another way of referring to it, it should be dynamically manageable without the user having to provision it for each and every application instance that comes or goes away. But then look at the other way, there could be certain application that would require static configuration. They want an endpoint to be persistent with the instance of an application. Ability to have visibility of these endpoints at the network layer to allow monitoring or even enforcing policies. You want separation of control and data plane. You don't want your data plane failover to impact your manageability of your Kubernetes cluster. Availability to support availability zones itself, multiple data centers, campus clusters. Similarly on the storage side, sorry about that. Similarly on the storage end, you wanted static and dynamic provisioning from storage perspective, from volume perspective. You wanted synchronous mirroring where your applications would have persistent data across different nodes and that should be synchronous. The application failover should not have to worry about a delta between the state of data across these nodes. You want rich feature set from enterprise customers perspective. You want snapshots. You want ability to restore these snapshots. You want to take backup and you want ability to restore the state to the backups. And of course, availability zones should also be able to extend, the storage feature should be able to extend across availability zones. Now let's look at the HCI requirements for Kubernetes clusters from availability zones perspective. Now high availability zones from enterprise customers perspective normally maps to campus clusters. These are data centers, not that far apart. Let's take around 50 miles or so. Now the requirements from network and storage a little bit different. On the networking side, you want your administration to be able to configure different subnets across different zones. So when applications are coming up on different zones, they get IP addresses. They get endpoint assigned dynamically, automatically on the subnet where that application comes up and the network should be laid out such that these are outtable across these data centers. On the storage side, you want your mirrors to be created, to be placed across these zones so that a failover on one zone allows you to move the application to another zone and having the data available synchronously in that zone as well. Now all this works very well for containerized applications. But what about application that are still on this path of transformation? They yet to be containerized applications. You don't want to have a separate infrastructure that deploy such applications. And through Kube word project under CNCF, there have been some great work done here. Ability to run applications in a virtualized environment but inside a container framework referred to as container native virtualization. On networking and storage perspective, you don't want anything to change from the way you did your cloud native application itself. You want the same feature parity. You want the same performance and you want a single pane of managing these applications. You have learned Kubernetes already to deploy your applications natively. You want these applications, the yet to be containerized applications to be also managed exactly in the same way. You don't want to learn a different framework for deploying such applications. Now stepping back, given all these requirements defined for HCI, the management of these components is also an integral part of an HCI requirement. Again, not very different from the offerings in the cloud, whether it be for configuration management, user management through Active Directory, or user policy enforcement through RBAD, should also be considered when designing or evaluating a platform for deploying cloud native application under this new paradigm. So given all these requirements are defined, let's look at one of the solutions that's out there that does take care of all these feature sets. I'm going to give it to Hero who's going to demo some of the features that we just now discussed. Thanks. Thank you, Naveen and Nareen for the great introduction. In this section, I'll go ahead and give a demo of multiple demos. So there are three demos that I've set it up. First, we'll go over the setup that I'll be using it. The Kubernetes cluster, which is deployed onto the HCI appliance. And the same cluster we'll use to deploy a containerized workload, which is a WordPress application. That's an example. I'll use it to deploy it. And we'll use the same Kubernetes cluster and deploy a KVM to showcase that yet to be containerized applications can also be deployed onto the same infrastructure using the same Kubernetes cluster. And in the fourth section, which will be the last demo, in that one we will showcase the benefits of hardware offloading for the network and storage resources and how we can use those benefits to provide the IO isolation per application, per VM instances along with the QS for the performance. Now let's go ahead and take a look at the demo setup that I'll be using it. So I'll use the three node cluster. As I mentioned, this is an HCI platform appliance on which we have clustered the three node Kubernetes cluster. As you can see, there are blue and green components. Blue are all open source Kubernetes components. We have one node, node one, which is running all the master components of the Kubernetes. And the green components are basically nothing but these components provide the functionality from the HCI platform standpoint to do a resource pooling for the network and storage standpoint. And also the CNI and CSI plugins to provision the network and storage resources to provide the guaranteed QS, guaranteed performance and making sure that you provide IO isolation for each and every container deployed onto this infrastructure. There's also a scheduler extension component which makes sure that it is aware of what all the resources this given infrastructure is able to provide, making sure it is aware of whether it's a high availability cluster, whether it is a single zone cluster and making sure it is able to schedule the resources in such a manner that it provides a high availability for a given resource from an application standpoint. Now let's go ahead and kick in the first demo where I'll go ahead and deploy a WordPress application. Before I deploy the application, I'll just give you a pictorial view of how the application deployment will look like onto the Kubernetes cluster that we have built across the three nodes. So when we deploy a WordPress along with the MySQL which is using a MySQL as a data store, so here I'll deploy a three instances of the WordPress, which will be running onto the three instances, node one, node two and node three and will deploy a MySQL which will be using an underneath persistent volume onto a DMIT IO layer. As you can see, Kubernetes construct called storage class to dynamically provision the persistent storage onto the DMIT IO layer. As you can see there are on onto the picture, green disk, those are nothing but the three replicas of the persistent volume that MySQL will provision. These three replicas are synchronously replicated. What does that mean? That means it gives a high availability of the volume or data store onto this replicas for a MySQL to fail over in the instances of the node going down or the MySQL instance itself goes down because of some reason. Now, the DMIT IO layer also provides a way to take the snapshots of these replicas. Because these replicas are synchronously replicated, you can use either of the replicas to take a snapshot into given a time frame. And these snapshots can also be used to backup into the third party backup storage like NFS or AWS. Now these used in future to restore onto a given volume or also to create a new volume for log analytics or any further analytics that end user wants to do it. Now let's go ahead and apply this instance, the WordPress instance that we'll be using it to the demo. So as I mentioned before, it is a three node cluster using as a standby right now. We'll use this fourth node into the later part of the demo. So we'll go ahead and mainly use the three nodes of the cluster, Qubectl which is the open source Qubenator CLI which gives you the details from the Qubenator's cluster standpoint. And there is another CLI here is a DCTL CLI which is a DMIT infrastructure level CLI which give you the more awareness from the infrastructure resource and resource pooling standpoint. So here you will be seeing more information from the platform standpoint like millicores, memory provided onto or available onto the server, storage and VNICs which are the underneath infrastructure level resources that can be used to schedule a specific workload onto a given node. Now let's go ahead, first one is nothing but a MySQL password. So we have created a secret for it, MySQL deployment and WordPress will be deployed as a stateful set. Let's go ahead and create a secret and deploy a MySQL deployment instance. For what is the port spec looks like with provision? We have mentioned that we will be using a dynamic provision and we'll use a storage class that is construct that is provided by the Qubenators to provision the volume onto the DMIT. Here it says that storage class will be using as a mirror. That means we will go ahead, let's look at what is this the mirrored storage class looks like and be a volume provisioner. And this provisioner is aware of these means we need a three replicas onto a given cluster whenever we provision the storage. The file system it will be using is the EXT4 file system and this is the performance tier or guaranteed QoS that it requires is the best effort based. We'll go into the details of the different performance tiers that you can provision onto the infrastructure and how we are able to give the IO isolation and guaranteed QoS into the later section of the demo instance is running. So this is the WordPress MySQL instance that we deployed and we had requested that we needed a three-way mirrored volume or mirrored replicas for a given MySQL instance to be deployed. Now if we zoom in into this volume which was dynamically provisioned, we will see that it has provisioned a three-way replicas onto a three different nodes of the cluster. And these all replicas right will happen to the MySQL instance will be replicated onto all Plexus or all replicas of this provision persistent volume. Now let's take a look at the part state Floyd one MySQL instance it is into a running state it is running into the node one and we have three instances of the WordPress stateful site running because we have three node cluster and we had requested for the three replicas. So we have all three instances of the replicas running onto the three different nodes of the cluster. Run the yet to be containerized application onto the same Kubernetes cluster. This gives us who are able to deploy the same how we are able to use the same node and also deploy the containerized workload along with the KVM workload. Here I'll just give before we go ahead and deploy it I'll just give a little bit deeper view into how we are able to achieve that and how we are able to use the same infrastructure to the KVM workload along with the container workload. The design is very much similar to the Kube word where the philosophy is we want to run a KVM inside a container. So they can coexist onto the same infrastructure along with the container workload. In this we are using a KVM as in this our solution is based off the KVM hypervisor. Now looks like the KVM is becoming a default runtime manager for deploying the VMs. Nowadays, like Google is using it, AWS, NitroCards are also supporting the KVM as a hypervisor to deploy the VMs. We will use this to deploy the VMs like the container workload. As of the HCI and by us offloading the network and the storage resources, we are able to achieve the consistent IO isolation and quality of service for the both containers and the VM workload using the PCI pass through mechanism. Another one is the NVME VM. So every application or every container or every VM which get provision onto the HCI adapter, DM and HCI adapter, it gets in its own isolated or its own isolated VS per a container or per VM. So here, let's say if the VM requires a network and the storage resource, both of them will get its own SRLV function for VM for network and the storage. So this gives you the way of provisioning or make a consistent way of getting an IO isolation and also guaranteed QoS for a given application or for a given VM instance. Now, this is little more technical. I won't go into each and every component detail, but this is kind of a high level picture which gives you the details on how the orchestration can be used to deploy the container or a VM instance onto the same infrastructure. So here, there are two workflows as a part of the regular container native workload and the red one is the KVM deployment workload. So KVM deployment is here in this case which is actually implemented using a Kubernetes construct called CRD, Custom Resource Definitions. So KVM objects are exposed as a custom resource definition onto this Kubernetes cluster. So whenever a KVM object gets created, the custom controller, KVM controller, which is in the green component underneath the API server will watch onto those instances and it will act on it. Here we are seeing other components like scheduler, network controller and storage controller. So whether you deploy a container or you deploy a VM, underneath, it will be used in a similar manner. They are in case of provisioning the storage or network for the container or the VM, the code path will remain same. This gives us the benefit of having the same features like storage classes, dynamic provisions, static provisioning for the storage and network to be exercised for both pod and the KVM workloads. So if you see at the end on the right-hand side, the containers and the VMs are running next to each other. They can coexist onto the same infrastructure just because we are able to extend the Kubernetes to deploy the VM and the container workload onto the same infrastructure. Now this is the pictorial view of how I will go ahead and deploy the KVM. So if you remember from the first demo, we had deployed a MySQL and one of the WordPress instance was running into the Node 1. In this demo, I'll go ahead and deploy a KVM instance onto the same Node instead that you are able to deploy the KVM and container workload onto the same Node of the same Kubernetes cluster. Underneath IO layer is exactly the same. The way we will provision, in this case, I'll take an example of provisioning the persistent storage using a static provisioning just to showcase the static provision onto the Kubernetes cluster for the KVM. And you can still use the same storage features like snapshots and also taking a backup of these snapshots and restoring this backup into the persistent volume. Kubernetes CRDs to support KVM as a primary object onto the cluster. So this is the KVM CRD. And this is the custom KVM controller that we have written to watch onto the KVM CRDs being created onto the Kubernetes cluster and then take an action on it. Comes into our mind. The first is how we're gonna do the boot image management. We're gonna be able to pull the images to boot the VM from it. So in this example, we'll use a web server-based management for the boot images. So I've just deployed an Nginx which is hosting a CentOS 7.4 QCAU image for VM to boot from. So this is the Nginx web server which will be hosting the CentOS QCAU image. And this is how the KVM pod spec will look like. You can see it is same as the pod spec. The way we provision the network is using a notation and it will use underneath a CNI plug, same CNI plug-in to provision the network onto the same infrastructure. Because for the VMs, you want to make sure the IP addresses which are allocated once they're purchased for reboot or redeployment of the same instances on case of node failures or zone failures onto the same Kubernetes cluster. So end-user doesn't have to worry about IP address changes and node configuration changes and things like that. As I mentioned before, we are using a web server-based of pulling the image. So this is the HTTP endpoint from where the CentOS 7.4 QCAU image will be pulled and booted. It will be used for VM boot up. This is the way we are able to expose the resources for a VM instance. The number of CPO cores that we'll be using is 16. And memory will requested for 32 gig of memory. Graphical VMC remote console way of graphical remote console way of accessing the VM. This is just the index for it to use it, for which index to use for the graphical VMC index. And here, these are all the same volume construct that you would, persistent volume construct that you would see it into a container, regular container or regular pod spec. Here, there are two persistent volumes we have specified. One is a volume images and another one is a data volume, which is a volume one. So persistent volume that I will use to persistently save the configuration or the boot image. So the reason we want to use the persistent volume is once the VM is booted, if the end user is making any configuration changes, like it is making any changes into our result local or the way the application should start once the VM is booted, you want to keep those configuration changes persistent onto the persistent volume to make sure that they are persisted across reboot. They're persisted if the KVM instance moves from one node to another node or it moves from one zone to another zone. This volume two is the volume one is the data volume. This volume is exposed as a PCI pass through inside the VM. And we are using a block device as an SS type and this support was added into the flex volume to make sure that we are able to do the PCI pass through for a storage persistent volume storage and also able to get the guaranteed QoS and IO isolation for the VM instances same way we are able to get it for the container workload. And instance using the same pod spec. Let's go ahead and provision the endpoint, which is the EP one, I like to create a persistent volume. This is a volume image one is the persistent volume for storing the boot image. And this is our block volume particularly provisioned onto the cluster and both of them we provision onto the node one where the WordPress and MySQL instances are running. Let's go ahead and create the PVPVCs to bind this volume. And I will go ahead and some KVM controller would have created the KVM pod for the given KVM instance that we created. Here as we see the same KVM instance we deployed it onto the same node where we have one of the WordPress instances running and also the MySQL instances running. Now this is the IP address got attached or it was reserved for a given KVM instance. As you can see it is underneath using an SRIOVVF for this given instance. These are the two storage wall these are the two persistent volumes that got assigned for a KVM instance. And as you can see the first one wall one one was the block device. So there is no device parts will exist onto the host because we are doing a PCI pass through and in that case host will not see this PCI device on the host and it will be passed directly inside the VM. And second instance we are using for persistently saving the boot image. Now we'll access using a serial console to the VM and as you can see you are able to log into the KVM instance that we just deployed. And we will able to see the same IP addresses being configured inside the VM for the interface that we exposed as a PCI pass through device. Next demo which is the last demo of this section. We would like to do and I'd like to do showcase the IO isolation with QoS for performance which showcases the benefits of offloading of both network and storage to the hardware and how you can get the guaranteed QoS or guaranteed performance for a given container or a VM workload. So we will take advantage of using a four node cluster to dedicate a node one for all the KVM instances deployment. So we just use the same Kubernetes construct to label the node for the KVM deployment just to make sure that all the KVM instances that we deploy onto the cluster only goes onto the node one and all the container workloads we will dedicate on the node two, three and four. Here we will basically deploy around 27 containers across three nodes and nine KVM instances on node one. And we will see how we are able to guarantee the IO isolation and also the performance for a given workload KVM or a container workload using a hardware offload for network and storage. State the usage of a performance tier and the guaranteed IO isolation and the performance for the container and VM workload. So we have divided the performance tiers here. One is the best effort, high and medium. As you can see their reserved effort is zero and network bandwidth is zero. That means if a system has any to give, they will get some storage IOPS and network bandwidth based on the best effort. High is going to get the maximum which is 20 K and 500 meg and medium is the next level which is 5 K and 125 meg. You can use the same construct to get the maximum to limit the maximum storage IOPS and maximum network bandwidth also. But in this case, we'll just demonstrate the min requirements. So these are the way of setting the min requirements for a given workload. I'll use the performance tiers and deploy three instances of KVM using a best effort, three instances of KVM using a high and other three using a medium onto the node one. First node as a type KVM and make sure that we use the same KVM node label to deploy all the KVM workloads. Here the node is labeled as a KVM. The instances of KVM which will be getting deployed onto the node one which we labeled as a KVM node. You see there are nine instances of KVM CRDs we deployed and let's take a look at the container states. As we can see the nine instances are going into the container creating state. I'll just showcase a dashboard which we can see two locations of KVM instances that got deployed. So this is the dashboard from the infrastructure standpoint. The application tab will be able to see it. Just logged out. I'll just re-login to the node. Hyperbenchmarking containers onto the same infrastructure. So here we'll deploy a 27 instances of FIO benchmarking and hyperbenchmarking pods across three nodes of the cluster at the different applications. Let's go and take a look at the nodes while the other container workload is coming up. As we see we had deployed a KVM instances onto the node one of the cluster. Here, as we can see because of the flow network and storage hardware offload, we are able to get a one million IOPS or more than a million IOPS for a given node throughput. If you see it that is in this case we are not running KVM is not running any network traffic. It is only running a storage traffic. So you'll be only seeing the storage IOPS and which is close to a million, you are able to get it just because of the hardware offload for the storage. As we see these containers, here we see a nine KVM instances that we deployed using a different performance tiers. Three with best effort, three with medium and three with high. Now let's look at the deployed which is a nothing but a storage benchmarking application, IPERF, which is a network, IPERF is a network benchmarking tool. It's the traffic. We will see the numbers in such a manner that high workload will be getting the maximum IOPS onto the node right after, next year will be the medium and after that will be the best effort. 1040K IOPS need and right latency. To see how much latency we are able to gain for a given specific performance tier So as we can see, second latency, there are around 480 microsecond latency for a read workload. And as we can see here, they also get 260K IOPS effort which are running around the 16K IOPS with the higher latency because you will be giving the high priority to the higher workload. The hardware is giving the high priority for the high workload, which requires the maximum IOPS. And the next is the medium which is getting a 66K IOPS and with the 1.9 millisecond latency. This is the same behavior we will see onto the other nodes where we deployed it. So here, as you can see, all three best effort are into their own range with high, getting the maximum and then the medium into the next category. Yeah, this is what I had from the demo standpoint. Now we can wrap it up with the Q and A. A few questions that came through the Q and A channel on Zoom. We've answered all of those questions. Feel free to, if you have any more questions, you know, feel free to plug them in now or let's roll to the next one. As well on the top of the hour. For about DMRT, go to DMRT.com. Email us at info at DMRT.com or follow us on Twitter at DMRT.com or we're also on LinkedIn. So in closing, thank you for your time. We appreciate it a lot. Hope we were able to share some insights from the industry. So in closing, DMRT is an enterprise Kubernetes platform with hardware offloads based on, you know, COTS hardware and software prepackaged with open source Kubernetes with million IOPS for one RU and sub 100 millisecond latency. Check out our website for all the use cases solutions. Of course, plan.enqlubcon, we'll see you there and you can expect more from us at qlubcon. So until then, have a great day. Back to you Kim. Thank you all. Have a great day.