OpenShift Container Platform Reference Architecture Implementation Guides

We’ve got a design for your next cloud-based container deployment.

An inordinate amount of time can be spent researching and debating architectural decisions, tooling, parameters, or a required sequence of tasks when trying to deploy a project to the cloud. Start your project on the right foot and take advantage of the Red Hat OpenShift Container Platform Reference Architecture implementation guides!

Reference Architectures combine the knowledge and experience of multiple cross-functional teams to formulate a best-practices design and simplify the process for creating a stable, highly-available environment on which to run your production applications.

 

noteNote: This post, originally published in January 2017, will be regularly updated to reflect current version numbers, diagrams, content overviews, and cloud providers for which there is a Reference Architecture. Last update: Nov 3, 2017 (updated AWS, Azure, RHV, vSphere).

Choose Your Cloud

Red Hat provides, and periodically updates, a comprehensive Reference Architecture document specific to deploying Red Hat OpenShift Container Platform on the most popular Cloud Infrastructure Providers:

  • Red Hat OpenStack Platform
  • Amazon Web Services (AWS)
  • Microsoft Azure public cloud
  • Google Cloud Engine (GCE)
  • VMware vSphere
  • Red Hat Virtualization (RHV)

In this write-up, I’ll briefly examine each and provide a link to discover more on your own.

Deploying on Red Hat OpenStack Platform

DEPLOYING AND MANAGING RED HAT OPENSHIFT CONTAINER PLATFORM 3.6 ON RED HAT OPENSTACK PLATFORM 10

A popular deployment scenario, the Reference Architecture by  Roger Lopez, Ryan Cook and Eduardo Minguez discusses and provides a step-by-step guide for a production-ready deployment of OpenShift Container Platform (OCP) version 3.6 on OpenStack Platform (OSP) version 10.

Understanding that not every infrastructure environment is the same, the guide provides some amount of explanation at common customization points. Topics covered include the following.

  • Deployment process overview
  • Prerequisites and preparation
  • A completely provisioned infrastructure in OpenStack using both manual and Heat orchestration
  • Native integration with OpenStack services like Heat, Neutron, Cinder and Ceilometer
  • Cinder storage for /var/lib/docker on each node
  • A role assigned to instances that will allow OCP to mount Cinder volumes
  • Creation of applications
  • Validating the environment
  • Testing failover
  • Auto-scaling OpenShift nodes with Heat and Ceilometer

For this Reference Architecture, the Red Hat OpenShift Container Platform service is deployed on infrastructure elements consisting of a single bastion host, three master hosts, and five node hosts that run the Docker containers, as depicted in the following diagram. The five node hosts are split into two types: two nodes running internal OpenShift services (OpenShift Router and the Local Registry), and three nodes dedicated to running the application container processes.

Reference Architecture Diagram for Red Hat OpenShift Container Platform on Red Hat OpenStack Platform

Deploying on Amazon Web Services

DEPLOYING AND MANAGING OPENSHIFT CONTAINER PLATFORM 3.6 ON AMAZON WEB SERVICES

Written by Ryan Cook, this cloud provider Reference Architecture describes the best practices deployment of Red Hat OpenShift Container Platform 3.6 on AWS infrastructure and demonstrates how OpenShift can be deployed with High Availability (HA) by taking advantage of the native HA capabilities of Kubernetes and AWS.

The Reference Architecture provides guidance on many topics, including the following.

  • Elastic Compute Cloud Instance details
  • Elast Load Balancers
  • Tooling prerequisites
  • Virtual Private Cloud (VPC)
  • Networking
  • Security Groups
  • Dynamic inventory
  • Registry
  • Authentication
  • Provisioning the infrastructure using Ansible
  • Validating the deployment
  • Operational management
  • Persistent volumes
  • Extending the cluster
  • Multiple OpenShift deployments

The deployment is broken up into two distinct phases:

Phase 1: Provision the infrastructure on AWS
Phase 2: Provision OpenShift Container Platform on AWS

and builds on a configuration consisting of three OpenShift Container Platform masters, two OpenShift Container Platform infrastructure nodes, two OpenShift Container Platform application nodes, and native Amazon Web Services integration.

ocp-on-aws
Reference Architecture Diagram for Red Hat OpenShift Container Platform on Amazon Web Services

Deploying on Microsoft Azure

DEPLOYING RED HAT OPENSHIFT CONTAINER PLATFORM 3.6 ON MICROSOFT AZURE

Written by Glen West, Ryan Cook and Eduardo Minguez, this Reference Architecture provides a comprehensive step-by-step of how to build an enterprise deployment of Red Hat OpenShift Container Platform 3.6 on Microsoft Azure public cloud with native integrations.

A notable addition in this version is Red Hat Single Sign-On (SSO), a fully federated central authentication service that can be used by both developers and end-users across multiple identity providers, using a simple user interface. For best practice on authentication, consult the Red Hat Single Sign-On (SSO) documentation.

The deployment is split into three separate phases:

Phase 1: Provision the Virtual Machines on Microsoft Azure
Phase 2: Install OpenShift Container Platform on Microsoft Azure
Phase 3: Post deployment activities

Additional subject matter covered includes:

  • Prerequisites: subscription, channels
  • Microsoft Azure
    • Cloud Instances
    • Cloud Storage
    • Load Balancer
    • Virtual Network (VNet)
    • Region selection
    • DNS
    • Template
  • Generation and Use of SSH Keys
  • Resource Groups and Group Name
  • OpenShift node types, SDN, router, registry
  • Network Security Groups
  • Provisioning the Infrastructure
  • Operational Management
  • Diagnostics
  • Persistent Storage

This best-practices document creates a highly-available deployment of three OpenShift masters and three OpenShift infrastructure nodes, and demonstrates the deployment of between three-to-thirty application nodes, as illustrated in the following diagram.

ocp-on-azure
Reference Architecture Diagram for Red Hat OpenShift Container Platform on Microsoft Azure

 

Deploying on Google Cloud Platform

DEPLOYING AND MANAGING OPENSHIFT CONTAINER PLATFORM 3 ON GOOGLE CLOUD PLATFORM

Written by Chris Murphy and Peter Schiffer, the cloud provider Reference Architecture focuses on a comprehensive deployment of Red Hat OpenShift Container Platform 3.5 on GCP infrastructure, dividing the steps into three distinct phases.

Phase 1: Provision the infrastructure on GCP
Phase 2: Provision OpenShift Container Platform on GCP
Phase 3: Post-deployment activities

The combined phases cover a wealth of information, including:

  • Configuration of GCP
  • Cloud storage / Persistent volumes
  • Container registry
  • Cloud DNS
  • Cloud Identity and Access Management
  • Dynamic inventory
  • Routing layer
  • Authentication
  • Tooling prerequisites
  • Provisioning the infrastructure using Ansible
  • Validating the deployment
  • Operational management
  • Diagnostics

The infrastructure used for this Reference Architecture, as depicted in the following diagram, consists of three OpenShift masters, two OpenShift infrastructure nodes and two OpenShift application nodes in a multi-zone environment.

ocp-on-gcp
Reference Architecture Diagram for Red Hat OpenShift Container Platform on Google Cloud Platform

Deploying on VMware vSphere

DEPLOYING AND MANAGING OPENSHIFT CONTAINER PLATFORM 3.6 ON VMWARE VSPHERE

Targeted for Systems Administrators and Systems Architects that are experienced with VMware, this Reference Architecture, written by Davis Phillips and Annette Clewett, provides a detailed explanation of deploying Red Hat OpenShift Container Platform 3.6 on a private VMware vSphere 6.5 cloud. The deployment is split into different phases.

Phase 1: Provision the infrastructure on VMware using Ansible
Phase 2: Provision OpenShift Container Platform on VMware
Phase 3: Post-deployment activities (operational management tasks)

The different phases cover a broad spectrum of topics, including:

  • vSphere prerequisites and configuration
  • Virtual machine details
  • Required software
  • Tooling prerequisites
  • Network components
  • Dynamic inventory
  • Registry
  • Provisioning the infrastructure with Ansible
  • Operational management
  • Testing / Troubleshooting

The infrastructure configuration demonstrated in the Reference Architecture consists of three OpenShift masters, two OpenShift infrastructure nodes, two OpenShift application nodes, and native VMware integration. An overview of all architecture components is shown in the following diagram.

ocp-on-vmware
Reference Architecture Diagram for Red Hat OpenShift Container Platform on VMware vSphere

Deploying on Red Hat Virtualization

DEPLOYING RED HAT OPENSHIFT CONTAINER PLATFORM 3.6 ON RED HAT VIRTUALIZATION 4

In this OpenShift Container Platform 3.6 on Red Hat Virtualization 4.1 Reference Architecture Guide, Chandler Wilkerson targets system administrators and system architects that have a solid background with Red Hat Virtualization, and provides a comprehensive example demonstrating how OpenShift can be set up to take advantage of the native high availability capabilities of Red Hat Virtualization in order to create a highly available OpenShift Container Platform environment.

In addition to simplifying the deployment process of a production-ready Red Hat Virtualization foundation built upon the latest best practices, the Guide also covers:

  • OpenShift Masters distributed across multiple Red Hat Virtualization hypervisor nodes utilizing anti-affinity groups
  • Infrastructure nodes likewise distributed across multiple Red Hat Virtualization hypervisor nodes with Router and Registry pods scaled accordingly
  • Native integration with Red Hat Virtualization services like thin-provisioned disks and HA
  • Creation of applications
  • Validation of the environment including fail-over tests

The configuration consists of three OpenShift master nodes, three OpenShift infrastructure nodes, and two OpenShift application nodes running as virtual machines within a highly available, self-hosted Red Hat Virtualization cluster, as shown in the following diagram:

Reference Architecture Diagram for Red Hat OpenShift Container Platform on Red Hat Virtualization

Conclusion

On a periodic basis, each of the Reference Architectures will get updated with current information, so continue to check back on them if you are planning a future deployment.

For any questions, concerns or feedback on the Reference Architectures mentioned here, please email refarch-feedback@redhat.com and be sure to visit the Red Hat Publications and Digital Assets for additional Reference Architectures as they are created.

Start a cloud-based container project off right and base it upon a validated Red Hat Reference Architecture.  You’ll be glad you did.

Categories
OpenShift Container Platform, OpenShift Dedicated, OpenShift Ecosystem, Products
Tags
, , , , , , , , ,
  • Sebastián Greco

    Hi,

    Correct me if i’m wrong but vCenter is a manager, we can deploy it on vSphere (ESXi hosts and vCenter to manage them) you don’t actually deploy anything on vCenter. Also calling “vCenter” a cloud system is imho, just wrong. “vSphere” is about virtualization. For cloud functionality one should add the provided OpenStack (included in Ent+ licensing but integrating with their own NSX and vSAN) or at least some vRealize for automation, chargeback and self-provisioning.

    It would be nice to have a reference architecture for OpenShift over RHV. Any chance to have that?

    Thx!
    Seb

    • Kamarulzaman Sali

      Yes, agree with Seb, VCenter is the manager equivalent to RHEVM/OvirtM.
      We deploy openshift on VSphere.

  • Zied Fakhfakh

    Hi,

    Should I consider VMWare architecture as valid for Red hat enterprise Virtualization ?

  • Miki Shapiro

    Most enterprise customers who run Vmware or RHV have at least two DCs.

    We should expand the RHV and Vmware architectures (as we have, for example, GCP) to address how customers are encouraged to use it
    – When they have 2 DC’s – where an “independent clusters at each DC” answer warrants expansion on where the control plane sits (e.g. CI/CD pipeline) what subservience model the cluster’s docker registries follow etc.
    – When they have 3 DC’s (where a “stretch cluster” answer clearly informs the reader how low-latency their WAN needs to to be (accounting for both etcd and CNS requirements) to take this ride, and whether the 2 DC approach maps here as well.