Configure Pod Affinity

Affinity rules govern how Kubernetes schedules pods for Fusion components across the cluster. All components have the same affinity setup, which follows this logic:

When scheduling, prefer to put a pod on a node in an availability zone that doesn’t have a running instance of this component.
Require that pods are deployed on a host that doesn’t have a running instance of the component that is being scheduled.

With this logic, the loss of a host can only bring down one component at most. However, the cluster must be at least as large as the number of replicas in the largest deployment.

To run a large number of a component, consider relaxing the "required" policy by changing it to a "preferred" policy on the hostname for the kubernetes.io/hostname policies:

Before

requiredDuringSchedulingIgnoredDuringExecution:

After

preferredDuringSchedulingIgnoredDuringExecution:

If you used the --with-affinity-rules option when running the ./customize_fusion_values.sh script, the pod affinity rules are configured for your cluster. Alternatively, copy affinity.yaml, and rename it using the following naming convention: <provider>_<cluster>_<release>_fusion_affinity.yaml.

To implement the file, append the following to your upgrade script:

MY_VALUES="${MY_VALUES} --values gke_search_f5_fusion_affinity.yaml"