Chapter 5. Red Hat OpenShift installation planning and considerations 95
For the purposes of this reference environment, the Red Hat OpenShift Container Platform 
ovs-networkpolicy SDN plug-in is chosen because of its ability to provide Pod isolation by 
using Kubernetes NetworkPolicy. 
Next, we discuss the important points to consider when deciding between the three popular 
options for the internal networks: ovs-multitenant, ovs-networkpolicy, and ovs-subnet.
OpenShift SDN plug-ins
This section focuses on multiple plug-ins for pod communication within Red Hat OpenShift 
Container Platform by using OpenShift SDN. The following plug-in options are available:
/SM590000ovs-subnet
The original plug-in that provides an overlay network that is created to allow Pod-to-Pod 
communication and services. This pod network is created by using Open vSwitch (OVS).
/SM590000ovs-multitenant
A plug-in that provides an overlay network that is configured by using OVS, which is similar 
to the ovs-subnet plug-in. However, unlike the ovs-subnet, this plug-in provides Red Hat 
OpenShift Container Platform project-level isolation for pods and services.
/SM590000ovs-networkpolicy
A plug-in that provides an overlay network that is configured by using OVS that provides 
the ability for Red Hat OpenShift Container Platform administrators to configure specific 
isolation policies by using NetworkPolicy objects.
Choosing an OpenShift SDN option
Two other OpenShift SDN options are available: ovs-multitenant and ovs-networkpolicy. The 
reason ovs-subnet is ruled out as an OpenShift SDN option is because it does not feature 
network isolation.
Although ovs-multitenant and ovs-networkpolicy provide network isolation, the optimal choice 
comes down to what type of isolation is required. The ovs-multitenant plug-in provides 
project-level isolation for pods and services. Therefore, pods and services from different 
projects cannot communicate with each other.
However, ovs-networkpolicy solves network isolation by providing project administrators the 
flexibility to create their own network policies by using Kubernetes NetworkPolicy objects. 
That is, all pods in a project are accessible from other pods and network endpoints by default 
until NetworkPolicy objects are created. Then, Pods from separate projects can communicate 
with each other, assuming the suitable NetworkPolicy is in place.
Depending on the level of isolation that is required, you must determine the suitable choice 
when deciding between ovs-multitenant and ovs-networkpolicy.
OpenShift storage
Container storage is ephemeral by design. Initially, containers were designed for immutable 
and stateless workloads. Later, the advantages of containerizing stateful applications became 
apparent. With that realization came the need to support persistent storage. 
A similar paradigm occurred with Kubernetes. Initially, it was designed for stateless 
applications, but it was rapidly extended to support stateful workloads. Supporting these new 
types of workloads drove the need to support multiple storage options. The storage options 
for Kubernetes and OpenShift environments are grouped under two classifications: 
ephemeral storage and persistent storage.