OpenShift architecture bakes in CoreOS Operator automation
OpenShift 4.1 promises easier container management for IT ops pros, but getting there from OpenShift 3 could be tricky for enterprises with large deployments.
BOSTON -- Red Hat OpenShift Container Platform version 4.1 holds tempting infrastructure automation features for IT ops pros, but moving large OpenShift 3 environments to the next version will take careful planning.
The new OpenShift architecture will become generally available in two weeks when Red Hat delivers version 4.1, skipping version 4.0. It integrates CoreOS Operators into the core management features of the Red Hat Kubernetes-based container management platform, with the goal of simplifying and automating ongoing operations tasks for enterprise shops with hundreds or thousands of pods, clusters and projects to worry about on Kubernetes. CoreOS Operators help users pack, deploy and manage an application on Kubernetes.
Previous versions of OpenShift had largely focused on the developer self-service experience, but this release is aimed squarely at an IT operations audience, Red Hat Summit attendees noted here this week.
"We've kept our cluster footprint small on purpose, and we don't want to spin up thousands of clusters without being confident in our ability to operate them," said James Anderson, senior principal enterprise architect at Sabre Corp., a travel industry software provider in Southlake, Texas. "OpenShift [4.1] builds in a lot of support for day-two operations that will make that easier."
CoreOS automation features define updated OpenShift architecture
Red Hat demonstrated automated features in the updated OpenShift architecture that function at the application and infrastructure layers of the platform, such as an Operator for Microsoft SQL Server that automates rolling upgrades, as well as a highly anticipated feature known as OpenShift Installer, which automates the setup of OpenShift clusters -- from application containers down to bare-metal hardware.
It's a pretty radical shift, but ultimately, it will be worth it. I constantly hear from IT pros that large clusters and rapid deployments are too hard to do without automation.
Tom PetrocelliAnalyst at Amalgam Insights
"Operators should be able to help with stateful apps in containers," Anderson said. "We want to run Couchbase [NoSQL databases] using the Operator. Right now, we run it outside [OpenShift], because we're not confident about running it in production."
The OpenShift 4.1 user interface also now includes the following:
a multi-cluster view;
Kubernetes monitoring visualizations based on Prometheus and Grafana; and
visibility into the Istio service mesh based on the Kiali open source project, as well as into virtual and bare-metal hosts.
Multi-cluster visibility and the default high-availability (HA) cluster configuration that comes with OpenShift Installer will give commercial aircraft maker Airbus more confidence when it converts apps that need built-in resilience to containers.
"We're waiting for version 4 to target HA, because we don't want to set things up in version 3 when the new version is coming out soon," said Colin Richards, cloud and container architect for Airbus, based in France. "The new UI will also help us manage HA clusters more easily instead of having to log in to each one."
OpenShift 4.1 also bakes in the Red Hat Enterprise Linux CoreOS microkernel, a lightweight container-optimized version of Red Hat's Linux distribution. CoreOS is now the mandatory kernel for OpenShift master nodes, and IT pros said it could ease day-to-day container operations.
"The way CoreOS is designed means it could reduce downtime for upgrades and make it easier to roll back to previous versions," said an engineer with a financial services company in Europe who requested anonymity. "It maintains two views of a virtual file system and swaps between them on reboot."
Red Hat's OpenShift senior principal product manager, Tushar Katarki, demonstrates an application migration tool at Red Hat Summit.
OpenShift architecture overhaul calls for careful migration plans
While the advances in the OpenShift architecture have broad appeal to IT pros, getting from version 3 to version 4.1 and higher could be a big undertaking. Red Hat officials demonstrated a wizard for application migration built into the OpenShift dashboard that's based on Heptio's Velero open source project. But that demo involved manually setting source and target clusters and used the example of migrating two namespaces and 12 pods -- a far cry from the scale seen at many OpenShift enterprise users.
"We have 1,300 projects, and that demo still had you manually doing every one of the process migrations," said a director of Linux middleware and hosting services at a university in the Southeast who watched the demo. "We're going to have to think about how we go about that process, and we also want to make the upgrade with no URL changes to our clusters. We'll have to figure out how to make that work."
Red Hat officials said maintaining cluster URLs will depend on how users implement the global domain name system features in OpenShift. For large-scale app migrations, users can automate the process through the Velero API, but must create their own tools to do so.
Industry analysts predict OpenShift shops will have enough incentive to make the upgrade, even if the process turns out to be painful.
"It's a pretty radical shift, but ultimately, it will be worth it," said Tom Petrocelli, analyst at Amalgam Insights in Arlington, Mass. "I constantly hear from IT pros that large clusters and rapid deployments are too hard to do without automation."
