A Kubernetes sandbox project has begun to find a niche in enterprise IT organizations via OpenShift Virtualization, despite criticisms from analysts.
KubeVirt is an extension of the Kubernetes container orchestration platform that Red Hat created and donated to the Cloud Native Computing Foundation, where it's maintained as a sandbox, or early stage, project. It allows traditional virtual machine workloads to be managed by the Kubernetes control plane alongside Linux containers, including live migration and automated restart functions.
The project has been around since 2017, and part of the Red Hat OpenShift Kubernetes platform in some form since 2018. Red Hat originally called it container-native virtualization, but rereleased the technology for OpenShift version 4 in 2020 as OpenShift Virtualization. OpenShift Virtualization version 2.6 arrived with OpenShift version 4.7 in March, featuring Quickstart templates for creating virtual machines.
This week, Red Hat made a Migration Toolkit for Virtualization based on the Konveyor open source project generally available during its Red Hat Summit virtual event. This toolkit is specifically intended to facilitate moving workloads from VMware vSphere version 6.5+ virtual machines to OpenShift Virtualization. Future releases will support migration to OpenShift Virtualization from Red Hat Virtualization and Red Hat OpenStack Platform, a Red Hat spokesperson said.
Though KubeVirt isn't new, it was the subject of renewed attention with the rollout of OpenShift Virtualization over the last year, and much of that attention has been negative. Industry analysts panned the concept at last year's Red Hat Summit, saying that a "lift and shift" approach to moving VM workloads into container clusters was antithetical to the original purpose of Kubernetes, which is to orchestrate lightweight, ephemeral, microservices-based workloads.
"Here, Kubernetes is being positioned as a Swiss Army knife," said Naveen Chhabra, a senior analyst at Forrester Research. "But Kubernetes and containers didn't come into existence because Google had millions of VMs running in parallel to accommodate search requests."
While it might be feasible to move some relatively lightweight VMs into Kubernetes environments, it's not a very thoughtful approach, Chhabra said.
"It's the same notion as lifting and shifting on-premises apps from on-premises to public cloud -- it doesn't always make sense," he said. "It might be valuable to those who won't make significant changes in applications but still want to taste what it means to run in Kubernetes, but the benefits are very short-lived and very little."
VMware users eye KubeVirt migration
However, even short-lived benefits in a rapidly changing industry appeal to some Red Hat OpenShift customers.
"The biggest challenge for a company like ours isn't tech, but the transformation from a hardware [focused] company ... for 80 years, to a company that also has software-only services," said Josef Meier, cloud lead architect at Rohde & Schwartz, a telecommunications company in Germany. "I love the idea of KubeVirt -- I wouldn't try to run 24/7 VMs in it, but to do soft migrations."
Ideally, container migration would also include refactoring monolithic VM-based apps as microservices up front, Meier acknowledged, but that's not always feasible -- technically or financially.
"It's tough to get budget to migrate to cloud-native software, because the boss always asks, 'What new [application] features will we have after that?'" he said. "If you are honest and say, 'The features are the same, but we'll have microservices,' the answer is no."
With KubeVirt and OpenShift Virtualization, that migration could be done more gradually, while potentially reducing VMware vSphere license costs, since OpenShift Virtualization is available free as a part of OpenShift.
Josef MeierCloud architect, Rohde & Schwartz
Using KubeVirt would also give IT pros a chance to learn how to use Kubernetes without also having to figure out how to refactor apps at the same time, he said.
"You can start immediately, have your software running in the cluster, get in touch with Kubernetes and then strip out microservices," Meier said. "You can also stress your application, shut it down and restart it because [KubeVirt] handles it as if it were a pod, and so you can test from day one whether your application is robust enough to withstand the life of a container."
Morgan Stanley plans a similar migration away from VMware vSphere to OpenShift Virtualization, at least for some workloads, according to a virtual presentation this week.
According to Scott White, executive director and head of private IaaS engineering at the financial services firm, the company could get many of the same benefits as OpenShift Virtualization -- including a virtualized Kubernetes control plane -- by sticking with VMware. Morgan Stanley's OpenShift teams are more comfortable running Red Hat's VMs within OpenShift, however.
"It's also about trying to keep each of the parts of our IT infrastructure in their own silos to reduce the blast radius ... of logical failures," White said. "That might seem super-cautious, but we're a financial services company, so it's important that we're super-cautious."
Morgan Stanley taps OpenShift Virtualization for private cloud refresh
Morgan Stanley's planned use of OpenShift Virtualization goes beyond initial workload migration -- it intends to make OpenShift Virtualization and nested OpenShift clusters a permanent part of an update to its global private cloud over the next year, which spans 51 availability zones worldwide.
Nested OpenShift clusters refers to an architecture that uses KubeVirt to virtualize the OpenShift Kubernetes control plane and, in Morgan Stanley's case, distribute traffic to it using a network bridge among a three-way infrastructure cluster of virtual machines. This virtualized control plane then hosts virtual tenant clusters for individual business units within the company (see diagram).
"If you have an entire infrastructure cluster go down, the tenant clusters will go on functioning," said Arvin Amirian, a senior consultant at Red Hat who co-presented with White during the virtual session. "In development, this allows us to do very quick deployment and testing for new configurations and versions of OpenShift, so each infrastructure developer can have their own cluster to play around with, without affecting anybody else. The same goes for [tenants] as well."
Morgan Stanley hadn't intended to use nested OpenShift in production originally but is now considering supporting it for internal customers that want to host virtual clusters for their partners and clients, White said.
While OpenShift Virtualization will be a part of the Morgan Stanley private cloud beyond its initial deployment, the longer-term goal is to host the control plane using Kubernetes pods rather than virtual machines, White said.
A supported version of a pod-based OpenShift control plane is still at least 18 months to two years away, Amirian estimated in a follow-up online Q&A this week, in part because the bridge network nested OpenShift uses is currently better suited to a VM.
Overall, however, analysts maintain that case studies like Morgan Stanley's don't reflect the majority of IT organizations. They also doubt that OpenShift Virtualization or the Red Hat migration toolkit will significantly affect competition between Red Hat and other Kubernetes platform vendors such as VMware Tanzu and major public cloud providers.
"It won't change the game for OpenShift or Red Hat -- if you weren't already intending to move from VMware to OpenShift, this won't change that," said Gary Chen, an analyst at IDC. "Things like [OpenShift] Managed Cloud Services will matter much more."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.