Customers selecting AWS as their preferred cloud have been able to deploy OpenShift through a variety of means. In this post we will explore what has changed in the latest version of OpenShift, and what these changes mean for AWS customers. We also will explore the latest OpenShift on AWS Quick Starts open source project, which is helping customers and partners deploy OpenShift on AWS, and we’ll review integration solutions that run as application workloads within OpenShift on AWS.
Overview
In 2017 AWS provided the first OpenShift Quick Start for OpenShift 3.x, which used AWS CloudFormation to deploy the AWS resources and Ansible scripts to deploy OpenShift onto the provided Amazon Elastic Compute Cloud (Amazon EC2) instances. The OpenShift control plane is deployed into the customer AWS account and this saw three master nodes behind Elastic Load Balancing (ELB) spread across three availability zones.
OpenShift 4 includes many changes. The adoption of Operators has been significant—not only does OpenShift 4 allow partners to implement integrations via Operators, but all of the underlying features and components of OpenShift are Operator controlled. There is now a Storage Operator that provides simple storage configuration when running on AWS. The OpenShift Storage Operator has support for Amazon Elastic Block Store (Amazon EBS) as well as Amazon Elastic File System (Amazon EFS). Operations teams can configure the Storage Operator to provision and manage AWS storage directly from within the OpenShift management console and CLI. Machine sets allow customers to control scaling and healing of worker nodes directly from within OpenShift in the same way customers enjoyed with autoscaling groups.
Here is a glimpse of some of the operators under the hood of a basic OpenShift install:
The OpenShift installation process has seen the most dramatic change. The OpenShift installer allows customers to select the environment on which they want to deploy clusters. When deploying OpenShift on AWS, parameters for the AWS region, number of availability zones, EC2 instance sizing, and the number of master and worker nodes would be defined. The installer then generates an ignition file that it uses to deploy the cluster.
The OpenShift installer works for a user-provided infrastructure in which the underlying compute, storage, and networking is deployed first, and then OpenShift is installed onto these resources. This is similar to how OpenShift 3 would have been deployed. The OpenShift 4 install also works for installer-provisioned infrastructure in which the installer builds out the underlying AWS resources as part of the OpenShift install.
AWS and Red Hat are constantly collecting customer feedback and using it to evolve recommended patterns for running OpenShift on AWS. As these evolutions are made, the Red Hat installer team updates the installer to work for these patterns. As such, the OpenShift installer has now become a living reference architecture for deploying OpenShift on AWS.
OpenShift 4 on AWS Quick Starts
How do you take advantage of all the new OpenShift features, provide an even simpler prescriptive means customers may already be familiar with, and enable other solutions provided through the AWS Quick Starts program to deploy on OpenShift on AWS?
The first change was to allow the Red Hat OpenShift on AWS Quick Start to take advantage of the installer-provisioned infrastructure process provided by the OpenShift installer. As AWS and Red Hat improve the installer process upstream, the Quick Start can consume this directly. To this effect, the Quick Start will deploy into either a new VPC or an existing one.
AWS CloudFormation is used to provide parameters for the installer process. This allows customers familiar with AWS Quick Starts solutions to run them in the way they are used to. Customers and AWS partners building Quick Start solutions that run on OpenShift can use the Red Hat OpenShift on AWS Quick Start as a submodule and a ready-to-consume building block.
The Red Hat OpenShift on AWS Quick Start will provision a collection of Amazon Simple Storage Service (S3) buckets to store the ignition files generated by AWS Lambda functions for use by the installer. These functions are created when deploying the Quick Start.
Lambda functions download the OpenShift installer files and invoked the installer. This deploys OpenShift into the AWS customer account using the installer-provisioned infrastructure mode. Customers must provide a PullSecret needed by the install process to link this deployment of OpenShift to a subscription. Customers must first log into cloud.redhat.com to download their PullSecret.
Three OpenShift master nodes will be deployed across three AWS Availability Zones (AZ). Should an AZ be impacted, the other two AZs provide resilience. Should a singe Amazon EC2 instance be impacted, the failover means within OpenShift itself will allow the cluster to continue functioning. Auto healing and replacement of the master nodes is not currently available.
In the event a master node fails, follow the OpenShift documentation for replacing a failed master host to replace it.
Red Hat is working toward providing automatic scaling and healing of master nodes. When this becomes available it will be added to the installer and consumed by the Quick Start.
Three machine sets are provisioned in separate AWS Availability Zones, allowing for scaling, resilience, and healing of the worker nodes. The machine sets will use Amazon CloudWatch metrics to monitor the underlying EC2 instances. The machine sets will add and remove EC2 instances to the OpenShift cluster as demand changes. Replacement of nodes is also possible; although this was available in the OpenShift 3 Quick Start, machine sets provide a tighter integration between OpenShift and AWS. Additional machine sets can be added by operations teams post-deployment if desired. The OpenShift documentation provides additional details:
Customers have a few options for managing certificates for SSL offloading. Though many customers opt to make use of the self-assigned certificates provided by OpenShift, AWS customers have voiced the desire to use AWS Certificate Manager (ACM) with OpenShift. The Red Hat OpenShift on AWS Quick Start in intended to work for a variety of options and use cases.
The following image shows the certificate-related parameter inputs for the Quick Start:
Customers are able provide the ARN of certificates provided by ACM, import a certificate from a third-party certificate authority, or use the self-assigned certificate.
Conclusion
With the Red Hat OpenShift on AWS Quick Start, customers can deploy OpenShift on AWS with ease by providing a few parameters to an AWS CloudFormation template, or use this as part of a nested stack to deploy other solutions that would run on OpenShift on AWS.
The AWS Quick Starts are all open source projects. Components and features of Red Hat OpenShift are open source, and we encourage you to take part in contributing.
