Product

Fusion 5.9

    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"