Overview

Red Hat OpenShift is an enterprise Kubernetes container platform that packages Kubernetes with a rich set of DevOps services and tools. Built on Red Hat Enterprise Linux and Kubernetes, OpenShift Container Platform (OCP) provides secure and scalable multi-tenant container orchestration for enterprise-class applications, complete with integrated application runtimes and libraries.

Red Hat OpenShift is available as a fully managed cloud service, or as a self-managed software offering for organizations requiring more customization and control.

When augmented with Contrail, Red Hat OpenShift gains a full-featured CNI and networking platform that can meet the complex data center networking requirements of enterprises and service providers alike.

Red Hat provides an Assisted Installer to perform the heavy lifting for much of the cluster installation process, including automatically running pre-flight validations to ensure a smooth experience. We have integrated the installation of Contrail within the Assisted Installer framework, so you can install Contrail seamlessly as part of Assisted Installer cluster installation.

You can use the Assisted Installer service hosted by Red Hat or you can download and install a local instance of the Assisted Installer in your own infrastructure. The Assisted Installer service, whether installed locally or hosted by Red Hat, is accessible through a UI (via your browser) or through REST API calls.

Note:

This installation guide covers the use of the hosted Assisted Installer service through REST API calls. Installing a cluster through API calls makes it easier for you to automate the procedure.

The Assisted Installer service supports early binding and late binding of the hosts to the cluster. In early binding, the hosts are bound to the cluster upon cluster registration. In late binding, the hosts are bound to the cluster after cluster registration. In both cases, the hosts are not bound to the cluster directly, but through an intermediary resource that provides the necessary decoupling required to support late binding.

This installation guide follows the early binding procedure, which is summarized as follows:

• Create a cluster resource that defines your cluster. A cluster resource is an object within the Assisted Installer service. As part of creating the cluster resource, you specify that you want Contrail to be the CNI for this cluster.
• Create an infra_env resource referencing the cluster resource. The infra_env resource is an object within the Assisted Installer service that acts as an intermediary, containing attributes describing the infrastructure environment in which the cluster is to be created. By referencing the cluster resource now (early binding), the hosts will boot up directly into the cluster.
• Generate and download a live ISO image that is customized for the infrastructure environment and cluster. This image is based on Red Hat Core OS (RHCOS) and is configured to automatically run an agent upon booting. The agent uses preconfigured tokens and keys to contact the Assisted Installer service and to communicate with other hosts within the cluster.
• Boot the cluster hosts with the live ISO image. Upon boot-up, the agent on each host contacts the Assisted Installer service via API calls, announcing its presence and disclosing basic hardware specification. The Assisted Installer service authenticates these API calls by verifying the tokens within the message. The Assisted Installer then performs preflight checks and other validations to ensure the hosts are capable of supporting the cluster defined by the cluster resource. Once the Assisted Installer service validates the hosts, the Assisted Installer service waits for you to initiate cluster installation.
• Apply the Contrail manifests to the cluster resource. This augments the cluster resource with Contrail configuration. Installation of Contrail is fully integrated within OpenShift installation.
• Start the installation of the cluster. The Assisted Installer service starts the cluster installation process by first selecting one host to be the bootstrap node. The Assisted Installer service configures this host to bootstrap the other control plane hosts. You will see the other control plane hosts reboot one by one into the cluster. Once all the other control plane hosts reboot into the cluster, the bootstrap node follows suit and reboots into the cluster as well. Once the control plane nodes come back up, they boot up the worker nodes.
• Watch the progress of the installation on the Red Hat Hybrid Cloud Console (https://console.redhat.com/openshift). The Red Hat Hybrid Cloud Console is the UI for the Assisted Installer service.

When you use the Assisted Installer service, you can choose to install OpenShift with user-managed networking or with cluster-managed networking:

• User-managed networking refers to a deployment where you explicitly provide an external load balancer for your installation. The load balancer distributes internal and external control plane API calls to the control plane nodes that you set up, as well as distribute application traffic to the worker nodes as required.

  With this option, you'll only need a single fabric virtual network. This single virtual network carries installation traffic to and from the Assisted Installer service, Kubernetes control plane traffic between nodes, Contrail network control plane traffic, and user data plane traffic. Each node has a single interface that connects to the fabric.

• Cluster-managed networking refers to a deployment where the Assisted Installer installs an integrated load balancer and ingress in the cluster for you.

  With this option, you'll need two virtual networks in the underlay fabric. The first virtual network carries installation traffic to and from the Assisted Installer service as well as Kubernetes control plane traffic between nodes. The second virtual network carries Contrail network control plane traffic and user data plane traffic. Each node has two interfaces, connecting to each of the aforementioned virtual networks.

  The reason for the two virtual networks is that Contrail internally implements VRRP to provide redundancy, which might conflict with some of the functionality that OCP provides. By splitting out the Contrail (vhost0) traffic, both the Kubernetes control plane and the Contrail control plane can achieve redundancy.

  Contrail handles all aspects of this VRRP implementation internally. There is no need for external routers to participate in VRRP nor is there a need for external routers to route between the two virtual networks.

Note:

The Contrail Networking implementation of the ClusterIP service uses ECMP load balancing. Session affinity is therefore enacted per flow, not per client IP address.