Spread the love
Today, Most of the enterprise organizations are running there production environment in “High Availability” Based architectures. Let’s take the example of trendy public clouds, it could be AWS, GCP or Azure they all support concept of “Region” & “Zones“.
You may understand Region as a geographic region or a country, and Zones are sitting under these regions as (Availability Zones) multiple datacenters. That means we can have multiple zones under specific region.
So, in public cloud systems, to achieve high availability for prevention from complete site failure ( DC Outage) and Failover capabilities.
In context of openshift, A highly available openshift cluster which we are planning to build on public cloud required there nodes spread across multiple zones in specific region ( as openshift has it’s limitation on minimum latency constraint ). Openshift support labeling their nodes with Region & Zones values which have specific meaning in openshift and work as per the concept explained above. Hence openshift cluster nodes spread across multiple zones support high availability.
WAIT, What if all the Pods belongs to a particular application Go and sit on the same node due to openshift facts, and during outage on that zone which is hosting that openshift node where pods are running results downtime ?
Yes, to prevent this situation, we need anti-affinity configured on all the nodes hosing pods, So with anti-affinity if you scale the application pod count to 2 from count 1 it will not go on the same node rather will go to the different available node in other zone.
So, by this all pods belongs to particular application spread across the zones in different nodes and due to zone or DataCenter outage that application will be available.