链接：https://pan.baidu.com/s/1D0EHjM_PAf4mnYRnbF8ZQw 

提取码：puao 

 

Overview of this Paper

Red Hat OpenShift Container Platform (OCP) is an enterprise kubernetes distribution targeted at corporations of 

multiple segments and sizes. OpenShift is a critical workload platform, and without a virtualization layer, users and 

workloads can suffer every time there is a hardware event that will reduce OCP compute capacity and possibly lead 

to OCP cluster outages.

Over the last 20 years, VMware has mastered running some of the most critical workloads in large enterprises 1, 

ensuring that a hardware failure do not impact operations. VMware has firmly established itself in the enterprise 

datacenter, first with its vSphere compute virtualization technology and then extending to vSAN storage 

virtualization and NSX network virtualization, in addition to robust management with vRealize, which are the key 

components of a VMware SDDC. Today, VMware helps customers build modern applications, ensures customers run

and manage kubernetes.

This paper outlines the rationale of why corporations such as Example.com can benefit from integrating a VMware 

SDDC and OpenShift 3.11 and 4.1 2 to support an exponential adoption of container workloads with clusters scaled to 

run 10,000+ kubernetes pods with real-world production environments. 

Components such as VMware HA and DRS are detailed in this paper for the optimal configuration of OpenShift and 

its resiliency. 

Other sections of this paper detail the role of VMware on Day 2 operational procedures on OpenShift and lessons 

learned on deploying OpenShift on the enterprise-level scale. This paper is a complement of Reference Architecture 

“Deploying and Managing OpenShift 3.11 on VMware”. 

The adoption of OpenShift has impacted multiple groups in Example.com in the way they develop, deploy, and 

manage applications. Multiple personas have been part of this journey, but for simplicity, this paper focuses on the 

following actors:

• Application Platform Architect: A multi-disciplinary professional across infrastructure (VMware), PaaS 

(Platform as a Service), cloud, software development, DevOps, and Site Reliability Engineer (SRE)

practices. It is a technical lead responsible for designing and architecting OpenShift clusters and 

practices. Bridges the teams of Application Developers and Operations. 

• Application Developers: Individuals (and groups) responsible for developing and managing the lifecycle 

of Example.com’s applications. Usually in communication with business units to code their business 

logic under business priority and to provide time-to-market. They are the OpenShift end users. 

• Operations: The team responsible for managing and supporting the IaaS (VMware) and PaaS 

(OpenShift). This paper refers to them as a single group, but in reality, Operations can be multiple 

teams (one for vSphere, one for OCP clusters, one per business unit, and so on). 

1 https://blogs.vmware.com/vsphere/tag/business-critical-apps . 2 OpenShift 4.1 was released in June/2019 with significant changes when compared to 3.11. Most of this paper is applicable to OCP 4.1 unless noted. 

OpenShift 4.1: OpenShift 4.1 was released in June/2019 with substantial changes compared to 

OpenShift 3.11. Since this paper is a best practice of vSphere for OpenShift, the content 

applies for OpenShift 4 unless noted. For more information on OCP4, please see Appendix A: 

OpenShift 4 .

W H I T E P A P E R – N OV E M B ER 20 1 9 | 7 

Best Practices for Red Hat OpenShift on the VMware SDDC

The examples and considerations in this document provide guidance only and do not represent strict design 

requirements, as varying application requirements might result in many valid configuration possibilities.

Summary of OCP 3.11 Components

Before explaining the best practices of vSphere with Red Hat OpenShift, this section reviews at high-level the 

components of the OCP 3.11 cluster. For additional information on core kubernetes and the mechanics of how an 

OCP works, refer to kubernetes components and OCP. See Figure 1 for the very high-level diagram of the type of 

nodes:

Figure 1: Types of Node on an OCP Cluster

Master Nodes: Hosts that contain the kubernetes control plane components such as the master-api server

(API/Authentication) and master-controller (Controller and Scheduler). Additionally, the same nodes run the etcd

(DataStore). The masters are only accessible over API, and they are also known as “control plane nodes”. It is 

recommended to have at least three master nodes for HA purposes. The etcd’s Raft distributed consensus algorithm 

requires that the number of OCP master nodes are in odd numbers (1,3,5, and so on.) 3 . VMware vSphere makes it 

possible to enforce the full redundancy of master nodes with as little as two bare metal servers.

Infrastructure Nodes: Hosts that contain the router pods, responsible for managing and redirecting incoming 

application traffic from the users to the application nodes. Infrastructure nodes perform this task through route 

objects, and these nodes are known to provide the Routing Layer. It is recommended to deploy at least three nodes

3 https://raft.github.io/