Legacy Product

Fusion 5.10
    Fusion 5.10

    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"