Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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 CN2, Red Hat OpenShift gains a full-featured CNI and networking platform that can meet the complex networking requirements of enterprises and service providers alike.

You can install OpenShift with the user-managed networking option or with the cluster-managed networking option:

  • 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, each node has a single interface into the fabric. This single interface 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.

  • 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, each node has two interfaces into the fabric. One interface carries installation traffic to and from the Assisted Installer service as well as Kubernetes control plane traffic between nodes. The other interface carries Contrail network control plane traffic and user data plane traffic.

    The reason for the two interfaces is that CN2 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.

    CN2 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.

Red Hat provides multiple ways for you to create an OpenShift cluster. We describe installation using the Assisted Installer and using Advanced Cluster Management.

Note:

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

Assisted Installer

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 CN2 within the Assisted Installer framework, so you can install CN2 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 CN2 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 CN2 manifests to the cluster resource. This augments the cluster resource with CN2 configuration. Installation of CN2 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.

Advanced Cluster Management

Advanced Cluster Management (ACM) brings a host of benefits to how you manage your OpenShift clusters. The centralized architecture gives you multicluster control, multicluster observability, and multicluster life cycle management all from a single console.

ACM consists of a hub cluster that provides the centralized management together with the clusters that you want to manage. After you set up the hub cluster, you use ACM to install or import the clusters that you want to manage. These clusters are called managed clusters. We'll show you examples on how you can use ACM to install or import managed CN2 clusters.

Note:

ACM supports the user-managed networking option only. ACM does not support the cluster-managed networking option.

Benefits of OpenShift with CN2

  • Industry-leading enterprise Kubernetes platform together with industry-leading CNI
  • Full featured SDN solution for enterprises and service providers alike
  • Feature-rich graphical user interface
  • Automated workflows and seamless integration with CI/CD pipelines
  • Assisted Installer and Advanced Cluster Management facilitate installation