Dell EMC can help you define an entry-level cluster that can scale as the business grows while you control your present capital and operating costs. Not all container ecosystems need hundreds of servers and no single cluster size fits all situations and circumstances. Customers who are new to containerization ask for a minimum platform configuration. A typical entry-level production platform in the corporate and enterprise markets has between 10 and 30 compute nodes. Large industrial-grade container ecosystems require several full racks of servers per cluster or multiple clusters per data center.
This solution design uses PowerEdge R640 and PowerEdge R740xd servers for compute and storage.
The PowerEdge R640 general-purpose platform supports up to 7.68 TB of memory and twelve 2.5-in. drives and provides flexible I/O options. It is a dual-socket, 1U platform that is ideal for dense scale-out data center computing.
The PowerEdge R640 platform
PowerEdge R640 servers are preferred for the CSAH and control plane node roles because the needs of these node types are easily accommodated in this 1U node configuration. We recognize that customers might prefer to use identical server configurations for all nodes in their cluster and might therefore choose PowerEdge R740xd servers instead.
Dell EMC PowerEdge R740 and R740xd are two socket, 2U rack servers designed to run complex workloads using highly scalable memory, I/O capacity, and network options. The R740 and R740xd features the 2nd Generation Intel Xeon Scalable processor family, up to 24 DIMMs, PCI Express (PCIe) 3.0 enabled expansion slots, and a choice of network interface technologies to cover NIC and rNDC. The PowerEdge R740 general-purpose platform is capable of handling demanding workloads and applications such as data warehouses, e-commerce, databases, and high-performance computing (HPC). The PowerEdge R740xd platform adds exceptional storage capacity options, making it well-suited for data- intensive applications that require greater storage while not sacrificing I/O performance.
PowerSwitch S series switches provide the architectural agility and flexibility that are ideal for Ready Stack for Red Hat OpenShift Container Platform 4.2. This Ready Stack design uses the following switches:
For more information, see Chapter 3 Networking Infrastructure and Configuration.
OpenShift Container Platform 4.2 can host the development and run-time execution of containerized applications, sometimes called “container workloads.” The platform uses the Kubernetes container orchestration toolchain that is core to modern automation container deployment, scaling, and management. OpenShift Container Platform 4.2 is designed to meet exacting demand-driven, scale-out capabilities for workloads. We expect the software platform to continue to mature and to expand rapidly, ensuring continued access to the tools you need to grow your business.
OpenShift Container Platform 4.2 is supported on Red Hat Enterprise Linux (RHE L) 7.6 as well as Red Hat Enterprise Linux CoreOS (RHCOS) 4.2. The OpenShift Container Platform 4.2 control plane can be deployed only on RHCOS. The control plane is hosted on control plane nodes. Either RHEL 7.6 or RHCOS can be deployed on compute nodes, known as worker nodes. Red Hat Enterprise Linux version 8 is not yet supported in OpenShift Container Platform.
Differences between OpenShift Container Platform 3.11 and OpenShift Container Platform 4.2 include:
This section further describes the new features and enhancements in OpenShift Container Platform 4.2.
OpenShift Container Platform 4.x introduced an operator framework to replace much of the functionality that was previously available with Helm and Helm Charts. An operator is a method by which Kubernetes-native applications are packaged and deployed into the Kubernetes run-time environment. An operator provides a key method for management of repetitive Kubernetes functional operations.
The functions that OLM supports include:
We deployed OpenShift Container Platform 3.11 using the openshift-ansible tool. OpenShift Container Platform 4.2 uses ignition-based deployment, a new approach to getting your Kubernetes cluster operational quickly and simply. The ignition-based deployment tool is called openshift-install.
The ignition-based installation method supports two modes of deployment: installer-provisioned infrastructure and user-provisioned infrastructure.
For bare-metal deployment, the Dell EMC Ready Stack deployment process uses the User Provisioned Infrastructure (UPI) method. The openshift-install tool requires very few install-time configuration settings. A post-installation Customer Resource Definition (CRD) facility is used to specify run-time configuration settings.
Over-the-air upgrades for asynchronous z-stream releases of OpenShift Container Platform 4.x are available. Cluster administrators can perform an upgrade by using the Cluster Settings tab in the web console. Updates are mirrored to the local container registry before being pushed to the cluster.
Currently, no facility exists for performing an in-place upgrade of an OpenShift 3.11 cluster to OpenShift 4.2. You must redeploy the cluster to use OpenShift 4.2. After deployment, OpenShift 4.2 is capable of automatic updating, and it will likely be possible to enable automatic upgrading to later releases. Red Hat is developing tooling to enable migration of OpenShift 3.7 and later clusters to OpenShift 4.2. For more information, see this .
OperatorHub helps administrators discover and install optional components and applications. It supports add-on tools and utilities from Red Hat, Red Hat partners, and the open source community.
OpenShift Container Platform 4.2 provides support for CSI 1.0, the container storage operator, and for the manila-provisioner/operator and snapshot operator.
Red Hat has added many other capabilities to the OpenShift Container Platform to make your container development process easier and more agile and to simplify deployment and management operations in production. For more information, see in the OpenShift documentation.
OpenShift Container Platform 4.2 introduces the three basic host types that make up every cluster: the bootstrap node, control plane nodes, and worker nodes.
The deployment process also requires a node called the Cluster System Admin Host (CSAH), but this node is not mentioned in Red Hat online documentation. The CSAH node is not part of the cluster but is required for OpenShift cluster administration. While you could log in to a control plane node to manage the cluster, this practice is not recommended. Although the OpenShift CLI administration tools are deployed onto the control plane nodes, the authentication tokens that are needed to administer the OpenShift cluster are installed only on the CSAH node as part of the deployment process.
Note: Control plane nodes are deployed using an immutable infrastructure, further driving the preference for an administration host that is external to the cluster.
Dell EMC recommends provisioning a dedicated host for administration of the OpenShift cluster. After the cluster is installed and started, the bootstrap node is repurposed as a worker node.
When your CSAH node is operational, installation of the cluster begins with the creation of a bootstrap node. This node is needed only during the bring-up phase of OpenShift cluster installation. When the initial minimum cluster—the control plane nodes and at least two worker nodes—is operational, you can redeploy the bootstrap node as a worker node. The bootstrap node is necessary to create the persistent control plane that is managed by the control plane nodes.
Nodes that run the control plane are referred to as “control plane nodes.” Three control plane nodes are required to control the operation of a Kubernetes cluster. In OpenShift Container Platform, these nodes are responsible for all control plane operations. The control plane operates outside the application container workloads and is responsible for ensuring the overall continued viability, health, and integrity of the container ecosystem.
Control plane nodes operate outside the MachineType framework. They consist of machines that provide an API for overall resource management. Control plane nodes cannot be removed from a cluster. These nodes provide HAProxy services and run etcd, the API server, and the Controller Manager Server.
In an OpenShift Kubernetes-based cluster, all application containers are deployed to run on worker nodes. Worker nodes advertise their resources and resource utilization so that the scheduler can allocate containers and pods to worker nodes and maintain a reasonable workload distribution. The CRI-O Kubelet service runs on each worker node. This service receives container deployment requests and ensures that they are instantiated and put into operation. The Kubelet service also starts and stops container workloads. In addition, this service manages a service proxy that handles communication between pods that are running across worker nodes.
Logical constructs called MachineSets define worker node resources. MachineSets can be used to match requirements for a pod to direct deployment to a matching worker node. OpenShift Container Platform supports defining multiple machine types, each of which defines a worker node target type. A future release of OpenShift Container Platform will support specifically classified worker node types, such as AI hosts, infrastructure hosts, NFV hosts, and more.
Worker nodes can be added to or deleted from a cluster as long as the viability of the cluster is not compromised. A minimum of two viable worker nodes must be operating at all times. Further, sufficient compute platform resources must be available to sustain the overall cluster application container workload.
Dell EMC has simplified the process of bootstrapping your first OpenShift Container Platform 4.2 cluster. To use the simplified process, ensure that your rack has been provisioned with suitable network switches and servers, that network cabling has been completed, and that Internet connectivity has been provided to the rack. Internet connectivity is necessary for the installation of OpenShift Container Platform 4.2.
The deployment procedure begins with initial switch provisioning. This step enables preparation and installation of the CSAH node, which includes:
Dell EMC has generated Ansible playbooks that fully prepare the CSAH node. Before installation of the OpenShift Container Platform 4.2 cluster begins, the Ansible playbook sets up a PXE server, DHCP server, DNS server, and HTTP server. The playbook also creates the ignition files that you need to drive your installation of the bootstrap, control plane, and worker nodes, and it configures HAProxy so that the installation infrastructure is ready for the next step. The Ansible playbook presents a list of node types that must be deployed in top-down order.
The Ansible playbook creates an installconfig file that is used to control deployment of the bootstrap node. The following figure shows the workflow to generate the installconfig file:
An ignition configuration control file starts the bootstrap node, as shown in the following figure:
Note: Ignition configuration-driven installation generates security certificates that expire after 24 hours. The cluster must be completely installed before the certificates expire. The cluster must operate in a viable (nondegraded) state so that the first certificate rotation can be completed.
The cluster bootstrapping process involves the following phases:
The control plane node (control plane) now drives creation and instantiation of the worker nodes.
Your cluster is now viable and can be placed into service in readiness for Day-2 operations. You can expand the cluster by adding worker nodes.