Šíření prostředků Kubernetes z clusteru centra do členských clusterů
Tento článek popisuje koncept šíření prostředků Kubernetes z clusterů center do členských clusterů pomocí Azure Kubernetes Fleet Manageru (Fleet).
Správci platformy často potřebují nasadit prostředky Kubernetes do několika clusterů z různých důvodů, například:
- Správa řízení přístupu pomocí rolí a vazeb rolí napříč několika clustery
- Spouštění aplikací infrastruktury, jako je Například Prometheus nebo Flux, které musí být na všech clusterech.
Vývojáři aplikací často potřebují nasadit prostředky Kubernetes do několika clusterů z různých důvodů, například:
- Nasazení aplikace obsluhující video do několika clusterů v různých oblastech za účelem sledování nízké latence
- Nasazení aplikace nákupního košíku do dvou spárovaných oblastí, aby zákazníci mohli pokračovat v nákupu během výpadku jedné oblasti.
- Nasazení dávkové výpočetní aplikace do clusterů s levnými fondy spotových uzlů.
Je zdlouhavé vytvářet, aktualizovat a sledovat tyto prostředky Kubernetes napříč několika clustery ručně. Fleet poskytuje šíření prostředků Kubernetes, které umožňuje správu prostředků Kubernetes ve velkém měřítku. Pomocí fleetu můžete vytvořit prostředky Kubernetes v clusteru centra a rozšířit je do vybraných členských clusterů prostřednictvím vlastních prostředků Kubernetes: MemberCluster
a ClusterResourcePlacement
. Fleet podporuje tyto vlastní prostředky na základě opensourcového cloudového řešení nativního pro více clusterů. Další informace najdete v dokumentaci k upstreamové flotile.
Důležité
Funkce Azure Kubernetes Fleet Manageru ve verzi Preview jsou dostupné na samoobslužné bázi s výslovným souhlasem. Verze Preview jsou poskytovány "tak, jak jsou" a "dostupné", a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Verze Preview Azure Kubernetes Fleet Manageru jsou částečně pokryty zákaznickou podporou na základě maximálního úsilí. Proto tyto funkce nejsou určené pro produkční použití.
Pracovní postup šíření prostředků
Co je to MemberCluster
?
Jakmile se cluster připojí k vozovému parku, vytvoří se v clusteru centra odpovídající MemberCluster
vlastní prostředek. Tento vlastní prostředek můžete použít k výběru cílových clusterů při šíření prostředků.
Následující popisky lze použít pro výběr cílového clusteru při šíření prostředků a automaticky se přidají do všech členských clusterů:
fleet.azure.com/location
fleet.azure.com/resource-group
fleet.azure.com/subscription-id
Další informace najdete v referenčních informacích k rozhraní API MemberCluster.
Co je to ClusterResourcePlacement
?
Objekt ClusterResourcePlacement
se používá k tomu, aby plánovač Fleetu řekl, jak umístit danou sadu objektů v oboru clusteru z clusteru rozbočovače do členských clusterů. Objekty s oborem názvů, jako jsou Nasazení, StatefulSets, DaemonSets, Config Mapy, Tajné kódy a PersistentVolumeClaims jsou zahrnuty při výběru jejich oboru názvů.
Pomocí ClusterResourcePlacement
:
- Vyberte, které prostředky Kubernetes s oborem clusteru se mají rozšířit na členské clustery.
- Zadejte zásady umístění, které se mají ručně nebo automaticky vybrat podmnožinu nebo všechny členské clustery jako cílové clustery.
- Určete strategie zavedení pro bezpečné zavedení všech aktualizací vybraných prostředků Kubernetes do více cílových clusterů.
- Zobrazte průběh šíření směrem ke každému cílovému clusteru.
Objekt ClusterResourcePlacement
podporuje použití ConfigMap k obálce objektu , aby pomohl rozšířit do členských clusterů bez nežádoucích vedlejších efektů. Mezi metody výběru patří:
- Skupina, verze a druh: Vyberte a umístěte všechny prostředky daného typu.
- Skupina, verze, druh a název: Vyberte a umístěte jeden konkrétní prostředek daného typu.
- Seskupení, verze, druh a popisky: Vyberte a umístěte všechny prostředky daného typu, které odpovídají zadaným popiskům.
Další informace najdete v referenčních informacích k ClusterResourcePlacement
rozhraní API.
Při vytváření ClusterResourcePlacement
je možné zadat následující typy spřažení:
- requiredDuringSchedulingIgnoredDuringExecution: Vzhledem k tomu, že tento spřažení je požadovaný typ během plánování, filtruje clustery na základě jejich vlastností.
- preferredDuringSchedulingIgnoredDuringExecution: Vzhledem k tomu, že toto spřažení je pouze upřednostňovaným typem, ale není vyžadováno během plánování, poskytuje přednostní řazení pro clustery na základě vlastností určených vámi, jako jsou náklady nebo dostupnost prostředků.
K dispozici je více typů umístění pro řízení počtu clusterů, do kterých je potřeba prostředek Kubernetes rozšířit:
PickAll
umístí prostředky do všech dostupných členských clusterů. Tato zásada je užitečná pro umístění úloh infrastruktury, jako jsou monitorování clusteru nebo aplikace pro vytváření sestav.PickFixed
umístí prostředky do konkrétního seznamu členských clusterů podle názvu.PickN
je nejflexibilnější možností umístění a umožňuje výběr clusterů na základě omezení rozložení spřažení nebo topologie a je užitečný při šíření úloh mezi několik vhodných clusterů, aby se zajistila požadovaná dostupnost.
PickAll
zásady umístění
Zásady umístění můžete použít PickAll
k nasazení úlohy napříč všemi členskými clustery v vozovém parku (volitelně odpovídající sadě kritérií).
Následující příklad ukazuje, jak nasadit test-deployment
obor názvů a všechny jeho objekty ve všech clusterech označených environment: production
pomocí:
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: crp-1
spec:
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
Tato jednoduchá zásada převezme test-deployment
obor názvů a všechny prostředky, které jsou v něm obsažené, a nasadí ho do všech členských clusterů ve flotile s daným environment
popiskem. Pokud jsou všechny clustery žádoucí, můžete termín úplně odebrat affinity
.
PickFixed
zásady umístění
Pokud chcete nasadit úlohu do známé sady členských clusterů, můžete pomocí PickFixed
zásad umístění vybrat clustery podle názvu.
Následující příklad ukazuje, jak nasadit test-deployment
obor názvů do členských clusterů cluster1
a cluster2
:
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: crp-2
spec:
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
resourceSelectors:
- group: ""
kind: Namespace
name: test-deployment
version: v1
PickN
zásady umístění
Zásada PickN
umístění je nejflexibilnější možností a umožňuje umístění prostředků do konfigurovatelného počtu clusterů na základě omezení rozložení spřažení i topologie.
PickN
spřažením
Použití spřažení s funkcemi PickN
zásad umístění podobně jako použití spřažení s plánováním podů Můžete nastavit požadované i upřednostňované spřažení. Požadované spřažení brání umístění do clusterů, které se neshodují s těmito zadanými spřaženími, a upřednostňované spřažení umožňují uspořádat sadu platných clusterů při rozhodování o umístění.
Následující příklad ukazuje, jak nasadit úlohu do tří clusterů. Platné cíle umístění jsou pouze clustery s critical-allowed: "true"
popiskem a předvolba je udělena clusterům s popiskem critical-level: 1
:
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
numberOfClusters: 3
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
weight: 20
preference:
- labelSelector:
matchLabels:
critical-level: 1
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
critical-allowed: "true"
PickN
s omezeními rozložení topologie
Pomocí omezení rozložení topologie můžete vynutit rozdělení umístění clusteru napříč hranicemi topologie tak, aby splňovaly požadavky na dostupnost, například rozdělení umístění napříč oblastmi nebo aktualizačními kanály. Omezení rozložení topologie můžete také nakonfigurovat tak, aby se zabránilo plánování, pokud omezení nejde splnit (whenUnsatisfiable: DoNotSchedule
) nebo naplánovat co nejlépe (whenUnsatisfiable: ScheduleAnyway
).
Následující příklad ukazuje, jak rozložit danou sadu prostředků do více oblastí a jak se pokusit naplánovat mezi členské clustery s různými dny aktualizace:
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: region
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
Další informace najdete v dokumentaci k nadřazené topologii, která rozšiřuje omezení flotily.
Strategie aktualizace
Flotila používá strategii postupné aktualizace k řízení způsobu zavádění aktualizací napříč několika umístěními clusteru.
Následující příklad ukazuje, jak nakonfigurovat strategii kumulativní aktualizace pomocí výchozího nastavení:
apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Plánovač postupně zavede aktualizace jednotlivých clusterů a čeká alespoň unavailablePeriodSeconds
mezi clustery. Stav zavedení se považuje za úspěšný, pokud byly na cluster správně použity všechny prostředky. Kontrola stavu zavedení se nespadá do podřízených prostředků, například neověřila, že se pody vytvořené nasazením připraví.
Další informace najdete v dokumentaci k upstreamové strategii nasazení Fleet.
Stav umístění
Plánovač Flotily aktualizuje podrobnosti a stav rozhodnutí o umístění objektu ClusterResourcePlacement
. Tyto informace můžete zobrazit pomocí kubectl describe crp <name>
příkazu. Výstup obsahuje následující informace:
- Podmínky, které se aktuálně vztahují na umístění, mezi které patří, pokud bylo umístění úspěšně dokončeno.
- Oddíl stavu umístění pro každý členský cluster, který zobrazuje stav nasazení do tohoto clusteru.
Následující příklad ukazuje ClusterResourcePlacement
, že nasadili test
obor názvů a test-1
objekt ConfigMap do dvou členských clusterů pomocí PickN
. Umístění bylo úspěšně dokončeno a prostředky byly umístěny do clusterůaks-member-1
.aks-member-2
Name: crp-1
Namespace:
Labels: <none>
Annotations: <none>
API Version: placement.kubernetes-fleet.io/v1beta1
Kind: ClusterResourcePlacement
Metadata:
...
Spec:
Policy:
Number Of Clusters: 2
Placement Type: PickN
Resource Selectors:
Group:
Kind: Namespace
Name: test
Version: v1
Revision History Limit: 10
Status:
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: found all the clusters needed as specified by the scheduling policy
Observed Generation: 5
Reason: SchedulingPolicyFulfilled
Status: True
Type: ClusterResourcePlacementScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: All 2 cluster(s) are synchronized to the latest resources on the hub cluster
Observed Generation: 5
Reason: SynchronizeSucceeded
Status: True
Type: ClusterResourcePlacementSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources to 2 member clusters
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ClusterResourcePlacementApplied
Placement Statuses:
Cluster Name: aks-member-1
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
Observed Generation: 5
Reason: ScheduleSucceeded
Status: True
Type: ResourceScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully Synchronized work(s) for placement
Observed Generation: 5
Reason: WorkSynchronizeSucceeded
Status: True
Type: WorkSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ResourceApplied
Cluster Name: aks-member-2
Conditions:
Last Transition Time: 2023-11-10T08:14:52Z
Message: Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
Observed Generation: 5
Reason: ScheduleSucceeded
Status: True
Type: ResourceScheduled
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully Synchronized work(s) for placement
Observed Generation: 5
Reason: WorkSynchronizeSucceeded
Status: True
Type: WorkSynchronized
Last Transition Time: 2023-11-10T08:23:43Z
Message: Successfully applied resources
Observed Generation: 5
Reason: ApplySucceeded
Status: True
Type: ResourceApplied
Selected Resources:
Kind: Namespace
Name: test
Version: v1
Kind: ConfigMap
Name: test-1
Namespace: test
Version: v1
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal PlacementScheduleSuccess 12m (x5 over 3d22h) cluster-resource-placement-controller Successfully scheduled the placement
Normal PlacementSyncSuccess 3m28s (x7 over 3d22h) cluster-resource-placement-controller Successfully synchronized the placement
Normal PlacementRolloutCompleted 3m28s (x7 over 3d22h) cluster-resource-placement-controller Resources have been applied to the selected clusters
Změny umístění
Plánovač flotily upřednostňuje stabilitu stávajících umístění úloh. Toto stanovení priority může omezit počet změn, které způsobují odebrání a přeplánování úlohy. Následující scénáře můžou aktivovat změny umístění:
- Změny zásad umístění v objektu
ClusterResourcePlacement
můžou aktivovat odebrání a přeplánování úlohy.- Operace horizontálního navýšení kapacity (zvýšení
numberOfClusters
bez dalších změn) umísťují úlohy pouze do nových clusterů a nemají vliv na stávající umístění.
- Operace horizontálního navýšení kapacity (zvýšení
- Změny clusteru, včetně:
- Nový cluster, který se stane způsobilým, může aktivovat umístění, pokud splňuje zásady umístění, například zásadu
PickAll
. - Cluster s umístěním se z vozového parku pokusí nahradit všechny ovlivněné úlohy, aniž by to ovlivnilo jejich ostatní umístění.
- Nový cluster, který se stane způsobilým, může aktivovat umístění, pokud splňuje zásady umístění, například zásadu
Změny pouze prostředků (aktualizace prostředků nebo aktualizace objektu ResourceSelector
ClusterResourcePlacement
) se postupně zavádět v existujících umístěních, ale neaktivují opětovné plánování úlohy.
Tolerance
ClusterResourcePlacement
objekty podporují specifikaci tolerance, která se vztahuje na ClusterResourcePlacement
objekt. Každý objekt tolerance se skládá z následujících polí:
key
: Klíč tolerance.value
: Hodnota tolerance.effect
: Účinek tolerance, napříkladNoSchedule
.operator
: Operátor tolerance, napříkladExists
neboEqual
.
Každá tolerance se používá k tolerování jednoho nebo více specifických taintů použitých na ClusterResourcePlacement
. Jakmile jsou všechny tainty na serveru MemberCluster
tolerovány, plánovač pak může rozšířit prostředky do clusteru. Po vytvoření objektu ClusterResourcePlacement
není možné aktualizovat ani odebrat tolerance.
Další informace najdete v dokumentaci k upstreamové flotile.
Přístup k rozhraní API Kubernetes clusteru prostředků Fleet
Pokud jste vytvořili prostředek Azure Kubernetes Fleet Manager s povoleným clusterem centra, můžete ho použít k centrálnímu řízení scénářů, jako je šíření objektů Kubernetes. Pokud chcete získat přístup k rozhraní Kubernetes API clusteru prostředků Flotily, postupujte podle pokynů v části Přístup k rozhraní API Kubernetes clusteru prostředků Fleet pomocí Azure Kubernetes Fleet Manageru.
Další kroky
Nastavte šíření prostředků Kubernetes z clusteru centra do členských clusterů.