Definování strategie zavedení pro umístění prostředků Azure Kubernetes Fleet Manageru

Během životnosti umístění prostředků (v rozsahu clusteru ClusterResourcePlacement nebo ve jmenném prostoru ResourcePlacement) mohou být provedeny změny, které mohou mít za následek jeden z následujících případů:

Nové úlohy můžou být potřeba umístit do všech vybraných clusterů.
Úlohy, které jsou už umístěné ve vybraném clusteru, se můžou aktualizovat nebo odstranit
Některé dříve vybrané clustery jsou nyní nevybrané a úlohy z těchto clusterů musí být odebrány.
Některé clustery jsou nově vybrány a úlohy je potřeba do nich přidat.

Většina scénářů může vést k přerušení služeb, protože úlohy spuštěné na členských clusterech můžou být dočasně nedostupné, protože Správce flotily odesílá aktualizované prostředky. Clustery, které už nejsou vybrány, ztratí všechny umístěné prostředky, což vede ke ztrátě provozu. Pokud je vybráno příliš mnoho nových clusterů a Správce flotily umístí prostředky na ně současně, clustery se můžou přetížit. Přesný způsob přerušení se může lišit v závislosti na umístěných prostředcích.

Aby se minimalizovalo přerušení, rozhraní API pro umísťování prostředků Fleet Manageru umožňují uživatelům konfigurovat strategii zavedení, podobně jako nativní nasazení Kubernetes, a co nejhladší přechod mezi změnami.

V tomto článku probereme možnosti strategie zavedení, které jsou k dispozici pro obě ClusterResourcePlacement a ResourcePlacement.

Note

Pokud ještě neznáte koncepty umístění prostředků Fleet Manageru, přečtěte si koncepční přehled umístění prostředků před přečtením tohoto článku.

Výchozí chování bez explicitní strategie

Obě ClusterResourcePlacement a ResourcePlacement nevyžadují, abyste definovali strategii zavedení. Pokud ho nezadáte, výchozím chováním je použití RollingUpdate strategie s maxSurge, který má hodnotu 25%, maxUnavailable s hodnotou 25%a unavailablePeriodSeconds s hodnotou 10 sekund.

Strategie postupné aktualizace

Explicitní strategii průběžné aktualizace lze použít přidáním strategy specifikace do ClusterResourcePlacement nebo ResourcePlacement, jak je znázorněno. Můžete definovat parametry, které řídí, jak moc narušuje rozmístění prostředků Fleet Manageru.

Příklad ClusterResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: westus
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Příklad ResourcePlacementu

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: rp-example
  namespace: test-namespace
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-app
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Konfigurační parametry

Strategie kumulativní aktualizace je možné nakonfigurovat s následujícími parametry:

maxUnavailable: považuje cluster za nedostupný, pokud se prostředky úspěšně neaplikují na cluster, a zajišťuje, že kdykoli je alespoň (N - maxUnavailable) počet clusterů k dispozici. Můžete nastavit jako absolutní číslo nebo procento. Výchozí hodnota je 25% a nemělo by se používat nula. Nastavení tohoto parametru na nižší hodnotu způsobí menší přerušení během změny, ale může vést k pomalejšímu zavedení.
maxSurge: zajišťuje, že kdykoli je k dispozici maximálně (N + maxSurge) počet clusterů. Můžete nastavit jako absolutní číslo nebo procento. Výchozí hodnota je 25% a nemělo by se používat nula. Nastavení tohoto parametru na nižší hodnotu vede k umístění méně prostředků na více clusterů Fleet Managerem, což zpomaluje průběh zavádění.
UnavailablePeriodSeconds umožňuje stanovit časové období, než budou prostředky posouzeny jako „připravené“. Výchozí hodnota je 60 sekund. Správce flotily považuje nově použité prostředky v clusteru za připravené až po unavailablePeriodSeconds sekundách od úspěšného aplikování prostředků na tento cluster. Nastavení nižší hodnoty pro tento parametr vede k rychlejšímu zavedení. Důrazně však doporučujeme, aby uživatelé nastavili hodnotu, která umožňuje dokončení inicializačních a přípravových úkolů.

Určení počtu clusterů

Správce flotily používá typ umístění k určení základního počtu clusterů (N), které se mají použít při výpočtu maxUnavailable nebo maxSurge:

PickFixed: počet zadaných clusterNames
PickAll: počet vybraných clusterů
PickN: numberOfClusters hodnota.

Pokud pro parametr použijete procento, Správce flotily ho také vypočítá podle N.

Strategie fázované aktualizace (Preview)

Fázovaná strategie aktualizací poskytuje jemně odstupňovanou kontrolu nad zaváděním prostředků uspořádáním clusterů do sekvenčních fází s konfigurovatelnými pravidly progrese. Na rozdíl od strategie postupné aktualizace se fázované aktualizace definují externě pomocí samostatných vlastních prostředků, které spolupracují na orchestraci nasazení.

Important

Funkce Azure Kubernetes Fleet Manageru ve verzi Preview jsou dostupné na samoobslužné bázi s výslovným souhlasem. Ukázky jsou poskytovány "jak jsou" a "podle aktuální dostupnosti" 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 s vynaložením maximálního úsilí. Proto tyto funkce nejsou určené pro produkční použití.

Jak fázované aktualizace fungují

Fázované aktualizace používají různé vlastní prostředky v závislosti na rozsahu:

Pro umístění v rozsahu clusteru:

ClusterResourcePlacement – Nakonfigurováno strategy.type: External pro označení správy externí strategie
ClusterStagedUpdateStrategy – definuje fáze, výběr clusteru a pravidla průběhu.
ClusterStagedUpdateRun – provede clusterStagedUpdateStrategy s konkrétním ClusterResourcePlacement a snímkem prostředků clusteru.

Pro umístění s oborem názvů:

ResourcePlacement – nakonfigurováno s strategy.type: External pro označení správy externí strategie
StagedUpdateStrategy – definuje fáze, výběr klastrů a pravidla postupu (v rámci oboru názvů)
StagedUpdateRun – provede stagedUpdateStrategy pro konkrétní ResourcePlacement snímek prostředku (obor názvů).

ClusterResourcePlacement s externí strategií

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

UmisťováníRessources s externí strategií

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: my-app-placement
  namespace: my-app
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by StagedUpdateRun, StagedUpdateStrategy.

ClusterStagedUpdateStrategy (v rozsahu clusteru)

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order

StagedUpdateStrategy (omezený na obor názvů)

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: StagedUpdateStrategy
metadata:
  name: three-stage-strategy
  namespace: my-app
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order

Konfigurace fáze

Každá fáze strategie může určovat:

Selektor štítků k určení clusterů, které patří do úrovně
Pořadí řazení pro clustery v rámci fáze pomocí sortingLabelKey (volitelné – clustery se seřadí abecedně podle názvu, pokud není zadáno).
Úkoly po fázi buď časově nastavené čekání, nebo požadavek na schválení (volitelné, až 2 úkoly na fázi, maximálně jeden z každého typu)

ClusterStagedUpdateRun (v rámci clusteru)

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # ClusterResourcePlacement name the update run is applied to.
  resourceSnapshotIndex: "0" # ClusterResourceSnapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

StagedUpdateRun (s omezením na obor názvů)

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: StagedUpdateRun
metadata:
  name: my-app-rollout
  namespace: my-app
spec:
  placementName: my-app-placement # ResourcePlacement name the update run is applied to.
  resourceSnapshotIndex: "0" # ResourceSnapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

Průběh fáze

Fáze řízení vozového parku se postupně zpracovávají:

Všechny clustery ve fázi přijímají aktualizace podle jejich pořadí řazení.
Po úspěšné aktualizaci všech clusterů ve fázi se spustí jakékoli nakonfigurované úkoly probíhající po fázi.
Další fáze začíná až po dokončení všech úkolů předchozích fází.

Pro průběh založený na schválení vytvoří Správce flotily prostředek ClusterApprovalRequest (pro umístění v oboru clusteru) nebo ApprovalRequest (pro umístění v oboru jmenného prostoru), který musí být schválen před pokračováním do další fáze.

Příklad vzoru nasazení

Následující diagram znázorňuje typický třífázový model nasazení:

Tento model umožňuje:

Nasadit nejprve do přípravných clusterů pro počáteční ověření
Než budete pokračovat v kanárských clusterech, počkejte určený čas.
Vyžadovat ruční schválení před uvedením do produkčního prostředí
Řízení pořadí aktualizací v kanárských a produkčních fázích

Kdy použít fázované aktualizace

Fázované strategie aktualizací jsou ideální, když potřebujete:

Nasazení na základě prostředí (vývojové → přípravné → produkční prostředí)
Zpoždění ověření a schvalovací brány mezi fázemi
Deterministické řazení aktualizací clusteru v rámci fází
Opakovaně použitelné vzory nasazení napříč několika umístěními prostředků

V případě jednodušších scénářů, kdy stačí zavedení založené na procentech, zvažte místo toho použití strategie postupné aktualizace.