Jak správně rozdělit pody na různé uzly v různých…

V Kubernetesu se následující mechanismy a přístupy používají k rozdělení podů na uzly v různých datových centrech:

Topology Spread Constraints: Umožňují kontrolovat, jak jsou pody rozloženy přes topologické domény (například regiony, zóny, uzly). Jedná se o hlavní mechanismus pro zajištění odolnosti vůči chybám a rovnoměrné rozložení zátěže.

# Příklad Topology Spread Constraints
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname # Rozložení podle uzlů
    whenUnsatisfiable: DoNotSchedule # Pokud podmínka není splněna, pod není naplánován
    labelSelector:
      matchLabels:
        app: my-app # Sada podů, na které se pravidlo vztahuje
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone # Rozložení podle zón
    whenUnsatisfiable: ScheduleAnyway # I když je podmínka porušena, pod je naplánován
    labelSelector:
      matchLabels:
        app: my-app

Node Affinity / Anti-Affinity: Umožňuje specifikovat, na kterých uzlech by měly (nebo neměly) být pody naplánovány. Uzly v různých datových centrech mají různé štítky (labels), které lze použít k řízení umístění.

# Příklad Node Affinity
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - us-east-1a
                - us-east-1b # Plánování pouze v zónách us-east-1a a us-east-1b

Pod Affinity / Anti-Affinity: Umožňuje specifikovat, kde by měly být pody naplánovány vzhledem k jiným podům. To je užitečné pro společné umístění (nebo oddělení) podů stejné aplikace nebo souvisejících služeb.

# Příklad Pod Affinity
affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: database # Naplánování aktuálních podů na stejných uzlech jako podů s label `app: database`
        topologyKey: kubernetes.io/hostname

Pod Topology Spread Constraints ve spojení s Affinity/Anti-Affinity: Pro podrobnější kontrolu často kombinují Topology Spread Constraints s Node nebo Pod Affinity/Anti-Affinity.
Rozložení Load Balancerů přes datová centra: Použijte globální load balancery (Global Load Balancers - GLB) na úrovni DNS nebo speciální síťová řešení, která směrují provoz na různé klastry (nebo skupiny uzlů) v různých datových centrech. To zajišťuje dostupnost i při úplné nedostupnosti jednoho datového centra.
Federace clusterů (zastaralá, ale konceptuálně relevantní) / Multi-Cluster Setup: V složitějších scénářích lze použít přístupy ke správě více clusterů. Ačkoliv nativní Federation v Kubernetes je zastaralá, existují projekty a nástroje (například Kubefed, Karmada) pro správu clusterů rozložených přes datová centra. To umožňuje používat společné politiky a zdroje.
Partitioning StatefulSet: Pro StatefulSets lze použít partition v RollingUpdateStrategy pro sekvenční aktualizaci pouze části podů, což může být užitečné při práci s distribuovanými databázemi nebo jinými Stateful aplikacemi.

Správný přístup závisí na konkrétních požadavcích na odolnost vůči chybám, latenci a složitost infrastruktury. Obvykle se používá kombinace Topology Spread Constraints a Affinity/Anti-Affinity.

Tabulka hlavních nástrojů:

Nástroj	Účel	Úroveň řízení
Topology Spread Constraints	Rozložení podů podle zadaných topologických domén pro vyvážení.	Plánovač Kubernetes
Node Affinity / Anti-Affinity	Připojení podů ke konkrétním uzlům nebo skupinám uzlů podle štítků.	Plánovač Kubernetes
Pod Affinity / Anti-Affinity	Připojení podů k jiným podům podle štítků pro společné nebo oddělené umístění.	Plánovač Kubernetes
Global Load Balancers (GLB)	Rozložení externího provozu mezi datová centra.	Externí infrastruktura/DNS
Multi-Cluster Management (např. Karmada)	Správa a synchronizace zdrojů a politik mezi více klastry.	Úroveň řízení clusterů

Jak správně rozdělit pody na různé uzly v různých datových centrech?