When deploying containerized IBM API Connect Gateways in a cloud like AWS, Azure or GCP, one would like to make sure that Kubernetes scheduler tries to ensure resiliency for these containers across multiple . IBM API Connect Operator does not ensure that by default, but it can be instructed to do so.
In this blog post I will explain how to configure IBM API Connect Custom Resources to ensure that IBM API Connect Gateway Pods are spread across all possible Availability Zones.
Availability Zones, Node Affinities and Anti-affinities
Availability Zones (AZ) are logically or physically segregated locations where compute resources are placed. They are engineered to be isolated from failures in other AZs and provide low latency connectivity between them. They often translate to separate Data Centers. Hosting applications across multiple AZs enable resiliency to any failures local to single AZ. High Availability (HA) mechanisms in Kubernetes rely on concept of quorum, therefore it is desirable to have 3 AZs to host highly resilient applications, and ensure that Kubernetes or RedHat Openshift clusters deployed in a cloud span all possible AZs.
In Kubernetes and RedHat Openshift Node affinity and Node anti-affinity allow you to specify on which nodes your Pods are being scheduled. Affinities and anti-affinities can be either soft, or hard.
Hard node affinity (requiredDuringSchedulingIgnoredDuringExecution) will prioritize HA rules over capacity/uptime. In real life deployments soft node affinity (preferredDuringSchedulingIgnoredDuringExecution) is more desirable.
Soft node affinity will prioritize capacity and uptime over HA rules. To better capture the difference between hard and soft affinities, let’s consider following situation: