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 |
|
After |
|
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"