https://kubernetes.io/blog/2023/04/17/fine-grained-pod-topology-spread-features-beta/

KEP-3022: min domains in Pod Topology Spread

たとえば、十分な容量を持つ 3 つのノードがあり、新しく作成された ReplicaSet の Pod テンプレートに次の topologySpreadConstraints があるとします。

...
topologySpreadConstraints:
- maxSkew: 1
  minDomains: 5 # requires 5 Nodes at least (because each Node has a unique hostname).
  whenUnsatisfiable: DoNotSchedule # minDomains is valid only when DoNotSchedule is used.
  topologyKey: kubernetes.io/hostname
  labelSelector:
    matchLabels:
        foo: bar

この場合、3 つのポッドがそれら 3 つのノードにスケジュールされますが、このレプリカセットの他の 2 つのポッドは、より多くのノードがクラスターに参加するまでスケジュールできなくなります。

クラスター オートスケーラーは、これらのスケジュール不能なポッドに基づいて新しいノードをプロビジョニングし、その結果、レプリカが最終的に 5 つのノードに分散されると想像できます。

KEP-3094: Take taints/tolerations into consideration when calculating podTopologySpread skew

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      # ...
      nodeAffinityPolicy: [Honor|Ignore]
      nodeTaintsPolicy: [Honor|Ignore]
  # other Pod fields go here

nodeAffinityPolicy フィールドは、Kubernetes がポッド トポロジの拡散のためにポッドのノードアフィニティまたはノードセレクターをどのように扱うかを示します。 Honor の場合、kube-scheduler は、分散スキューの計算において、nodeAffinity/nodeSelector に一致しないノードをフィルターで除外します。 Ignore の場合、Pod の nodeAffinity/nodeSelector と一致するかどうかに関係なく、すべてのノードが含まれます。

下位互換性のために、nodeAffinityPolicy のデフォルトは Honor です。

nodeTaintsPolicy フィールドは、Kubernetes がポッド トポロジの拡散に関してノード テイントをどのように考慮するかを定義します。 Honor の場合、受信ポッドが許容できる汚染されたノードのみが分散スキューの計算に含まれます。 Ignore の場合、kube-scheduler は分散スキューの計算でノードのテイントをまったく考慮しないため、ポッドが許容されないテイントを持つノードも含まれます。

下位互換性を確保するために、nodeTaintsPolicy のデフォルトは Ignore です。

KEP-3243: Respect Pod topology spread after rolling upgrades

Deployment でトポロジ展開を使用する場合、Deployment の labelSelector をトポロジ展開制約の labelSelector として使用するのが一般的です。ただし、これは、デプロイメントのすべてのポッドが、異なるリビジョンに属しているかどうかに関係なく、分散計算の一部であることを意味します。その結果、新しいリビジョンがロールアウトされると、古い ReplicaSet と新しい ReplicaSet の両方のポッドにわたって拡散が適用されるため、新しい ReplicaSet が完全にロールアウトされ、古い ReplicaSet がロールバックされるまでに、実際の拡散は完了します。古い ReplicaSet からポッドが削除されると、残りのポッドの分散が偏ってしまうため、期待と一致しない可能性があります。この問題を回避するには、これまでユーザーはリビジョン ラベルを Deployment に追加し、ローリング アップグレードのたびに手動で更新する必要がありました (ポッド テンプレートのラベルと、topologySpreadConstraints の labelSelector の両方)。

この問題をより単純な API で解決するために、Kubernetes v1.25 では、matchLabelKeys という名前の新しいフィールドが topologySpreadConstraints に導入されました。 matchLabelKeys は、分散を計算するポッドを選択するためのポッド ラベル キーのリストです。キーは、スケジュールされているポッドのラベルから値を検索するために使用され、それらのキーと値のラベルは labelSelector と AND 演算されて、受信ポッドの分散が計算される既存のポッドのグループを選択します。