Ako správne rozdeliť pody na rôzne uzly v rôznych dátových centrách?

Na rozdelenie podov po uzloch v rôznych dátových centrách v Kubernetes sa používajú nasledujúce mechanizmy a prístupy:

1. Topology Spread Constraints: Umožňujú kontrolu nad rozdeľovaním podov podľa topologických domén (napríklad regióny, zóny, uzly). Ide o základný mechanizmus na zabezpečenie odolnosti a rovnomerného rozloženia záťaže.

   # Príklad Topology Spread Constraints
   topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: kubernetes.io/hostname # Rozloženie podľa uzlov
       whenUnsatisfiable: DoNotSchedule # Ak podmienka nie je splnená, pod sa neplánuje
       labelSelector:
         matchLabels:
           app: my-app # Určuje skupinu podov, na ktoré sa vzťahuje pravidlo
     - maxSkew: 1
       topologyKey: topology.kubernetes.io/zone # Rozloženie podľa zón
       whenUnsatisfiable: ScheduleAnyway # Aj keď je podmienka narušená, pod sa plánuje
       labelSelector:
         matchLabels:
           app: my-app
   

2. Node Affinity / Anti-Affinity: Umožňujú špecifikovať, na ktorých uzloch majú byť pody plánované alebo nie. Uzly v rôznych dátových centrách majú rôzne značky (labels), ktoré je možné použiť na správu rozmiestnenia.

   # Príklad Node Affinity
   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
           - matchExpressions:
               - key: topology.kubernetes.io/zone
                 operator: In
                 values:
                   - us-east-1a
                   - us-east-1b # Plánovanie podov iba v zónach us-east-1a a us-east-1b
   

3. Pod Affinity / Anti-Affinity: Umožňujú špecifikovať, kde majú byť pody plánované vzhľadom na iné pody. Je to užitočné pre spoločné rozmiestnenie (alebo oddelenie) podov jednej aplikácie alebo súvisiacich služieb.

   # Príklad Pod Affinity
   affinity:
     podAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchLabels:
               app: database # Plánovanie aktuálnych podov na tých istých uzloch ako pody s etiketou app: database
           topologyKey: kubernetes.io/hostname
   

4. Pod Topology Spread Constraints v kombinácii s Affinity/Anti-Affinity: Pre jemnejšiu kontrolu sa často kombinujú Topology Spread Constraints s Node alebo Pod Affinity/Anti-Affinity.

5. Distribúcia load balancerov cez dátové centrá: Používajte globálne load balancery (Global Load Balancers - GLB) na úrovni DNS alebo špeciálnych sieťových riešení, ktoré smerujú prevádzku na rôzne klastre (alebo skupiny uzlov) v rôznych dátových centrách. Tým sa zabezpečí dostupnosť aj pri úplnej nedostupnosti jedného dátového centra.

6. Federácia klastrov (zastaralá, ale koncepčne relevantná) / Multi-Cluster Setupy: V zložitejších scenároch je možné použiť prístupy na správu viacerých klastrov. Hoci nativná Federation v Kubernetes je zastaraná, existujú projekty a nástroje (napríklad Kubefed, Karmada) na správu klastrov rozmiestnených v rôznych dátových centrách. To umožňuje používanie spoločných politík a zdrojov.

7. Partitioning StatefulSet: Pre StatefulSets je možné použiť partition v RollingUpdateStrategy na sekvenčné aktualizácie len časti podov, čo môže byť užitočné pri práci s distribuovanými databázami alebo inými Stateful aplikáciami.

Správny prístup závisí od konkrétnych požiadaviek na odolnosť, latenciu a zložitosť infraštruktúry. Zvyčajne sa používa kombinácia Topology Spread Constraints a Affinity/Anti-Affinity.

Tabuľka s hlavnými nástrojmi:

Nástroj	Účel	Úroveň riadenia
Topology Spread Constraints	Rozloženie podov podľa stanovených topologických domén na vyváženie.	Plánovač Kubernetes
Node Affinity / Anti-Affinity	Pripútanie podov ku konkrétnym uzlom alebo skupinám uzlov podľa značiek.	Plánovač Kubernetes
Pod Affinity / Anti-Affinity	Pripútanie podov k iným podom podľa značiek pre spoločné alebo oddelené rozmiestnenie.	Plánovač Kubernetes
Global Load Balancers (GLB)	Rozloženie vonkajšieho prevádzky medzi dátové centrá.	Externá infraštruktúra/DNS
Multi-Cluster Management (napr. Karmada)	Správa a synchronizácia zdrojov a politík medzi viacerými klastrami.	Úroveň riadenia klastrov