Petya Petrova - Fotolia
Red Hat OpenShift will fold in proprietary code from an IBM tool to support multi-cluster management with plans to make the product open source, in a pivotal moment for the integration of the two companies.
Kubernetes management is complex, and that intricacy increases with scale, which prompts many enterprises to split container orchestration deployments into multiple clusters as they grow. This trend, along with a movement in some enterprises toward multi-cloud app deployments, created a demand for centralized multi-cluster management tools that most IT vendors have heeded, including Platform9, HPE, Rancher and VMware. Thus, it's not Red Hat's support for multi-cluster management that most intrigues industry watchers -- it's the sourcing of the tool it plans to offer.
"Red Hat's [corporate] branding is that it's 100% open source, but this isn't open source yet," said Tom Petrocelli, analyst at Amalgam Insights. "For them to go out with something that's this important to their competitive positioning as this platform without open sourcing it makes me wonder if that may shift."
Red Hat officials have said they plan to make the new tool, which will be called Advanced Cluster Management (ACM), open source once it becomes generally available, sometime in the next year. ACM will include centralized application lifecycle management and infrastructure monitoring for cloud and on-premises Kubernetes clusters built with OpenShift and third-party distros, a step further into distro-agnostic Kubernetes management than Red Hat has taken before.
Tom PetrocelliAnalyst, Amalgam Insights
But Petrocelli said he's concerned that there aren't more specific timelines available for the open source plan, and that more progress wasn't made on open sourcing the tool before it was announced.
"It raises the question of how much we're going to see Red Hat going from pure open source to the blend that everybody else is [between open source and proprietary products]," Petrocelli said. "Red Hat has heaped derision on competitors for doing that … they have to be consistent."
It can take time to go through the legal licensing process to open source previously proprietary codebases, which is not to mention any technical code changes that may be required to bring the product into line with the rest of the Red Hat OpenShift platform. CoreOS Quay, for example, didn't reach open source until November 2019, nearly two years after Red Hat acquired CoreOS.
However, concern about IBM's spotty open source history has lingered since the companies' merger was announced in October 2018. IBM officials have pledged to preserve Red Hat's open source commitment, but the industry will wait to see how the combined entity handles product transitions such as this, analysts predicted.
"I don't think it's just lip service when they say open source and integration with Red Hat products is a big priority," said Charlotte Dunlap, an analyst at GlobalData Technology in Santa Cruz, Calif. "This may serve as a measurement of IBM's approach -- are they going to let Red Hat run with it?"
OpenShift refactors VM support with KubeVirt integration
Industry experts sense IBM's influence in another beta product previewed for Red Hat OpenShift this week, OpenShift virtualization. It's based on KubeVirt, an upstream project created three years ago by Red Hat engineers that uses Kubernetes to orchestrate virtual machines within containers.
KubeVirt is not a new concept, but its emphasis on the OpenShift roadmap this year is probably meant to boost the platform's appeal to conservative, IBM enterprise customers, analysts said.
"As much as they'd like everyone to just dump what they've done in the past, it's just not realistic," said Dunlap. "There's a lot of investment there and moving to containers is too much of a leap for most customers to make right away."
IBM and Red Hat must also compete in this area with other options for cloud and container integration with VM infrastructure, most notably VMware Tanzu and Google Anthos. Red Hat officials say KubeVirt creates a single centralized Kubernetes-based workflow to manage VMs alongside containers, which Red Hat officials say will speed the modernization of legacy apps on the container platform.
However, while the fact that users with large legacy VM farms need to transition gradually to Kubernetes is well understood, some experts question whether KubeVirt makes sense as a technical answer to that problem.
"I can't emphasize enough how much I hate this idea," Petrocelli said. "It defies the whole point of using containers to break apps into tiny chunks that scale quickly -- now you're going to stick a chunky VM in there and wait for the container to instantiate, then the VM OS to boot and load … any architect worth their salt is going to look at this and say, 'Are you nuts?'"
Reaction to OpenShift virtualization among customers wasn't quite that strong, but it was trepidatious.
"KubeVirt gives me anxiety -- I think people will abuse it to make fat containers," said Nicolas Chaillan, chief software officer for the U.S. Air Force. "But it could be a good stopgap."
At least one prominent enterprise has already adopted KubeVirt. Goldman Sachs presented at Red Hat Summit Virtual this week on its work to incorporate upstream KubeVirt into an OpenShift 3.11 environment with 225,000 VMs on 37,000 physical hosts, and company presenters said the financial services firm plans to move to OpenShift virtualization when it migrates to OpenShift version 4.
However, the Summit presentation didn't address why Goldman Sachs engineers chose KubeVirt over vSphere to orchestrate the company's ESXi hypervisors, or why it plans to use OpenShift virtualization with version 4, rather than a packaged vSphere integration module that's also on the roadmap for OpenShift 4.5 this year. Goldman Sachs reps did not respond to requests for comment this week on that question, and Red Hat officials declined to comment.
OpenShift 4.4 irons out feature kinks
OpenShift shops that have overcome migration pains from the upgrade to version 4 from version 3 say the 4.4 release next month will smooth some technical wrinkles that required workarounds in previous versions.
Nicolas Chaillan Chief software officer, U.S. Air Force
Delta Airlines, for example, encountered incompatibilities between OpenShift version 4.1 and 4.2 default Operators and its AWS environment, according to a Delta engineer in a Summit presentation. This prompted the airline and its Red Hat services advisors to switch from pre-packaged Installer Provisioned Infrastructure (IPI), which automates and abstracts cluster installation within OpenShift, to customizable User Provisioned Infrastructure.
Among those early mismatches was incompatibility between OpenShift 4 and the airline's AWS Identity and Access Management (IAM) policies, which required an IAM broker workaround to provide pod-level authentication. Version 4.4 adds a long-term fix for that issue, according to Red Hat consultant Ava Shulman, who spoke during the Delta presentation.
OpenShift 4.4 makes services generally available that Red Hat introduced in beta over the last year, such as OpenShift Serverless support for Knative, and expanded support for Kubernetes edge workloads, including disconnected cluster maintenance. ACM will support up to 2,000 Kubernetes clusters, in part to accommodate Kubernetes edge workloads.
OpenShift roadmap includes Windows, bare metal automation
OpenShift Pipelines support for Tekton CI/CD will become generally available in the second half of 2020 with version 4.5, and a developer preview of an Operator for Jenkins is slated for the third quarter.
Windows Kubernetes hosts, already generally available from competitors such as Rancher and the major cloud providers, will have to wait for GA until OpenShift supports Kubernetes 1.18 later this year. That version of Kubernetes contains important storage and networking updates that make Windows Kubernetes hosts production-ready, company product managers said.
Red Hat officials also discussed the future of the upstream Metal Kubed project, which automates bare metal host provisioning for Kubernetes. There's been debate about whether virtual machines or bare metal servers are ideal hosts for containers since the early days of Docker, but most enterprises have stuck with VMs so far, for security purposes and to take advantage of VM orchestration tools. Metal Kubed aims to make the process of requesting bare-metal resources as abstracted and automatic as requesting VMs within Kubernetes.
OpenShift support for Metal Kubed is planned for late 2020 or the first quarter of 2021, in response to growing enterprise demand for bare metal support, according to company officials in an Ask the Experts Session at Red Hat Summit.
"Bare metal is the fastest growing population [of hosts among users], even though it's not the largest," said Michael Barrett, senior director of product management at Red Hat, who attributed that growth to expanding AI and machine learning applications that require high-performance bare metal hardware. "Just about every one of our enterprise customers has a bare metal project."