Azure Red Hat OpenShift “ARO” is back again with a fabulous set of features and capabilities, making the transit from ARO 3.11 to ARO 4.x a must for most customers.
A charming white bird is bringing additional freedom to end users.
We are going to get a long hard look at this new release and provide, as usual, an Honest REX.
Read-on to find out more!
ARO 4.x is available within the HERO region as a start, including West/East Europe, US (East, West, South Central) and more. However, as Microsoft aims to spread fast, ARO 4.x is expected to be available everywhere, where ARO 3.11 is running, in the near future.
OverTheAir upgrade for OpenShift v4.5 version is already available through all the “Stable”, “Fast” and “Candidate” channels.
This release continues to improve the efficiency of the leading enterprise Kubernetes platform using the Kubernetes Operators model. In particular, this ARO release makes more out of Operators and gives DevOps teams different features/improvements such as:
- Full Cluster-Admin rights,
- No lock-in to Azure AD, nor to Virtual Networks,
- New Dashboard experience,
- Hybrid Cluster Management console, Cost Management,
- An additional set of security features,
- Network Isolation with Azure Private Link,
- Private Cluster through the usage of ingress endpoints,
- Multi-Availability zones, auto-scalable clusters,
- Over-The-Air Upgrades,
- Certified Operators such as Istio, Tekton and many more.
First, What about the Freedom?
ARO users used to be hardly controlled and restricted access to different kinds of resources. With this latest release, they got additional freedom to play with all components of an OpenShift cluster. One dummy unexpected features are to display basic statistics related to nodes from the CLI, label and taint nodes and even implementing a customized Kubernetes Scheduler.
Yes, this is absolutely basic yet was not even possible with ARO 3.11:
oc adm top nodes
oc adm top nodes --selector=""
We still can not SSH to master nodes, but do we really need that?
OpenShift is making the cluster management based only on declarative YAML / Resource Definitions, which can be automated and thus reduce the risk of misconfigurations.
But wait! Let’s discuss first how to create an ARO cluster.
Setting up such complex infrastructure is made relatively easy with the Azure Portal or Azure CLI, which provides the easiest way to deploy and manage the ARO resources.
Following this link you’ll get a Terraform ready to use for ARO 4.x cluster provisioning.
In addition to this, Microsoft introduced a new set of Azure-CLI tools:
#AZ ARO Help:
az aro -h#Deploy Command:
az aro create -g <ResourceGroup> -n <ClusterName> --domain <Domain>
With ARO 4.x, the End-Customer has the ability to:
- Bring his own Virtual Network and took full ownership of it,
- Tag the ARO resources deployed,
- Apply the desired Naming Convention on all ARO Resource Groups,
- Bring his own Identity Provider, which can be set to GitHub, Azure AD or others.
Everything in OpenShift 4 is operator enabled. Starting from the cluster upgrades, updates, monitoring, logging in addition to the application lifecycle.
With ARO 4.x, customers can turn their clusters into a highly resilient and highly available infrastructure, deployed by default as a Multi Availability-Zone cluster.
Master and Worker nodes are based on Virtual Machines and not anymore on VMSS or ”Virtual Machine Scale Sets”. Those Virtual Machines are configured and controlled only from OpenShift as “Machines” and “MachineSets” resources. This provides the ability to configure a mix of different T-Shirt sizes for different workloads (Pools).
The end-user is able to play with great freedom on the MachineSets of the worker nodes, scaling In/Out and even Up/Down by editing the MachineSets.
oc get machinesets -n openshift-machine-api
oc scale --replicas=2 machineset <machineset> \
NB. Changes on the MachineSet configuration will be enforced only to newly created nodes.
“ClusterAutoscaler” Operator or “CAO” can be configured with ease enabling automatic scalability of the worker nodes (Based on CPU and Memory conception).
Labelling/Tainting nodes and configuring its own scheduler is finally possible.
Private cluster is finally available and is based on Azure internal network LoadBalancers. The exposed OpenShift API and Application endpoints could be set to “Private” or “Public” separately.
A single pane of glass
The Dashboard provides a quick overview of the cluster, including health metrics, resource counts, and a streaming list of events, such as machine updates or pod failures.
As a hybrid cloud, Red Hat’s also introduced “Red Hat Advanced Cluster Management”, or ACM for short, as a Technology Preview. It provides a single pane of glass to control and monitors several OpenShift clusters at scale from On-Prem to Multi-Cloud.
Cost management is one of the capabilities that Red Hat and OpenShift community didn’t make a priority during the past. Red Hat is trying to minimise the gap and recently shared with the community a beta version of the new cost management service, Red Hat Cost Management.
Cost management is still in Technical Preview and available for early access to Red Hat partners through this link.
Azure Private Link is available under ARO 4.x, securing data in transit between ARO and a good set of Azure resources (such as Azure Key Vault, Azure Container Registry, SQL Databases). In a way, the traffic between your VNet and the service is routed through the Microsoft backbone network and reaching a private IP of the services.
Authentication & Authorization
ARO is made available open, thus not connected to any identity provider (IdP) and supports a wide variety of IdP, including Azure AD based on OpenID Connect. Others such as HT-Passwd (basic flat file), Github, LDAP are also supported.
Azure AD Group synchro
Extend ARO with the help of operators to integrate with external Identity-Providers.
Synchronizes groups from external providers into OpenShift The OpenShift Container Platform contains functionality to…
And Much more!
Serverless / Knative
One “Kubernetes Native” way of implementing serverless anywhere in Kubernetes deployments. Which can be even from your laptop.
Finally, Service Meshes, such as Consul, Istio and Red Hat Service Mesh, can be deployed in ARO clusters.
To know more about Service Mesh, please check my previous blog post.
Check my previous blog post on how easy it is to deploy an Argo CD application for Continuous Deployments.
This new feature is first introduced with OpenShift 4.2 release. It’s a new area of the console where Kubernetes resources can be browsed and discovered as a starting point by novice users.
Hmmmmm! The cluster is a piece of art. However, some drawbacks exist and which we need to be aware of.
- Even that Version 4.5 is available within the Stable channel, Microsoft still limits their support to ARO v4.4 only. Final customers are not allowed to upgrade/patch the cluster to any release manually.
- The Service Level Agreement is not clear yet and not measurable. No details provided around availability, response-time or quality is provided by Microsoft.
- ARO Documentation is not exhaustive and complete.
- Other points to notice with ARO 4.x is that there are still no possibilities to switch from the native SDN provider “OpenShiftSDN” to “Kuryr”, “OVNKubernetes”, or others. Red Hat is still restricting its support to the OpenShiftSDN network provider, limiting the support for Microsoft.
- Any modifications to the cluster components can bring the cluster to unsupported mode. Those modifications are highlighted in the following document yet so generic. So, it’s advised to be aware of them.
Could you please read the support policy below carefully?
Azure Red Hat OpenShift 4 cluster support policy
Certain configurations for Azure Red Hat OpenShift 4 clusters can affect your cluster's supportability. Azure Red Hat…
OpenShift 4.x excels today with the broad set of features and possibilities provided and how it’s made easy to deploy and integrate to almost all Azure features. However, the main drawback with ARO is Microsoft experience with this new offering.
Several managed solutions, such as OpenShift Dedicated, Amazon Red Hat OpenShift and IBM Red Hat OpenShift Kubernetes Service, enables organizations to gain the benefits of enterprise Kubernetes without the burden of infrastructure management.