CDL uses the K8s topology spread constraints feature to spread pods across upgrade zones so that if an upgrade zone is down, all the redundant pods are not lost at the same time.

The following fields are defined for the topology spread constraint:

• maxSkew —Defines the maximum permitted difference between the number of matching pods in the target topology and the global minimum (the minimum number of pods that match the label selector in a topology domain). For example, if you have 3 zones with 2, 4, and 5 matching pods respectively, then the global minimum is 2 and maxSkew is compared relative to that number.

• whenUnsatisfiable —Indicates how to deal with a pod if it does not satisfy the spread constraint:

  • DoNotSchedule (default) indicates the scheduler not to schedule the pod.

  • ScheduleAnyway indicates the scheduler to schedule the pod while prioritizing nodes that minimize the skew.

• topologyKey is the key of node labels. If two nodes are labelled with this key and have identical values for that label, the scheduler treats both nodes as being in the same topology. The scheduler tries to place a balanced number of pods into each topology domain.

• labelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain.

For CDL pods, the following is an example of the fields defined for topology spread constraint:

• topologyKey: smi.cisco.com/upgrade-zone

• maxSkew: 1

• whenUnsatisfiable: DoNotSchedule

• labelSelector: Selects all pods matching the deployment or stateful set

Based on this constraint, the K8s scheduler attempts to distribute the pods evenly in a deployment or stateful set across zones with maxSkew of 1.

• For slot or index pods that have two replicas, then the two replicas are always in separate upgrade zones.

• For cdl-ep or Kafka pods, the pods will be distributed almost evenly with a maxSkew of 1.

• If the pod is unable to satisfy the maxSkew: 1 constraint, the pod will remain in Pending state as the whenUnsatisfiable field is set to DoNotSchedule . This constraint does not allow the maxSkew to be violated.

Note	The topology spread constraints are only added for cdl-ep, cdl-slot, index, Kafka, or stateful sets deployment. There is no change for etcd and zookeeper as they are scheduled on primary or OAM nodes which will be upgraded one by one.

This section describes the known limitations and restrictions for CDL zone upgrade:

• CDL supports NF deployments with Kafka replica 2 or Kafka replica 3. For deployments with Kafka replica 3, CDL defines at least three upgrade zones. If there are three replicas and two upgrade zones, then one upgrade zone will have two replicas and the other will have one replica. In this scenario where the upgrade zone having two replicas goes down, only one replica will be available to serve traffic.

• If the nodes in an upgrade zone are fully utilized and if one or more nodes in that zone go down, the pods on one or more nodes that went down may be in Pending state.

  The following conditions apply for same zone nodes and different zone nodes:

  • Same zone nodes—Nodes in the same zone do not have the requested CPU or memory resources for the pod to be scheduled on it.

  • Different zone nodes—One of the following conditions applies for different zone nodes:

    • Nodes in another zone do not have the requested CPU or memory resources for the pod to be scheduled on it.

    • Nodes in another zone have the requested CPU or memory resources for the pod to be scheduled. With scheduling, the pod will violate the maxSkew:1 constraint.