Configure Pod Affinity

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

  • When scheduling, prefer to put a pod on a node that is in an availability zone that doesn’t already have a running instance of this component.

  • Require that pods are all deployed on a host that doesn’t have a running instance of the component that is being scheduled.

This means that the loss of a host will bring down at most one component. However, the cluster will need to be at least as large as the number of replicas in the largest deployment.

If you need to run a large number of a certain type of component, then consider relaxing the "required" policy by changing it to a "preferred" policy on hostname by changing

     requiredDuringSchedulingIgnoredDuringExecution:

to

     preferredDuringSchedulingIgnoredDuringExecution:

for the kubernetes.io/hostname policies.

If you used the --with-affinity-rules option when running the ./customize_fusion_values.sh script, then you already have pod affinity rules configured for your cluster. If not, then we recommend copying the example-values/affinity.yaml file and renaming it using our convention: <provider>_<cluster>_<release>_fusion_affinity.yaml.

Append the following to your upgrade script:

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