Jak začít s bezpečným upgradem

Tento článek představuje postupy bezpečného upgradu (SUP) Azure Operator Service Manageru (AOSM). Tato sada funkcí umožňuje upgrady na komplexní funkci sítě kontejneru (CNF) hostované na platformě Azure Operator Nexus. Tyto upgrady obecně podporují metody a požadavky partnera pro upgrade softwaru za provozu (ISSU). I když tento článek představuje základní koncepty, hledejte další články, které rozšiřují pokročilé funkce a možnosti SUP.

Úvod do bezpečných upgradů

Daná síťová služba podporovaná AOSM, která se skládá z jedné až mnoha CNF, zahrnuje komponenty, které v průběhu času vyžadují změny softwaru a/nebo konfigurace. Pokud chcete tyto změny na úrovni komponent provést, je nutné spustit jednu nebo více operací Helmu, upgradovat každou aplikaci síťových funkcí (nfApp) v daném pořadí a způsobem, který co nejméně ovlivní síťovou službu. Postupy bezpečného upgradu AOSM používají následující základní funkce pro zpracování procesu upgradu a požadavků na pracovní postup:

Podpora SNS Reput - Proveďte operaci upgradu Helm napříč všemi aplikacemi nfApps ve verzi návrhu síťových funkcí (NFDV).
Nexus Platform – Podpora reputačních operací SNS na cílech platformy Nexus
Časové limity operací - Schopnost nastavit časové limity pro jednotlivé operace nfApp.
Synchronní operace – možnost spustit jednu sériovou operaci nfApp najednou
Pořadí upgradu řízení – Definujte jinou sekvenci nfApp pro instalaci a upgrade.
Pozastavit při selhání – výchozí chování se pozastaví po selhání operace nfApp.
Vrácení při selhání – Volitelné chování, kdy se provádí vrácení dokončených nfApps před selháním nfApp.
Ověření testu s jedním grafem – spuštění testovací operace helmu po vytvoření nebo aktualizaci
Přeskočit nfApp při žádné změně - Přeskočit zpracování nfApps, kde nedochází ke změnám.
Předběžné načítání obrazů – možnost předběžného načtení obrazů do edge úložiště

Přístup k bezpečnému upgradu

Pokud chcete aktualizovat stávající síťovou službu lokality AOSM (SNS), operátor vykoná reputační žádost vůči nasazenému zdroji SNS. Pokud SNS obsahuje CNFy s více aplikacemi nfApps, požadavek se rozdělí do všech nfApps podle verze definice síťové funkce (NFDV). Ve výchozím nastavení v pořadí, ve kterém se zobrazují, nebo volitelně v pořadí definovaném updateDependsOn parametrem.

U každé aplikace nfApp žádost o reputaci podporuje různé změny, včetně zvýšení verze chartu Helm, přidání nebo odebrání hodnot helmu nebo přidání nebo odebrání všech aplikací nfApps. I když je možné nastavit časové omezení pro nfApp na základě známých povolených časů běhu, nfApps lze zpracovat pouze v sériovém pořadí, jeden za druhým. Aktualizace reputace implementuje následující logiku zpracování:

Aplikace nfApps se zpracovávají buď podle updateDependsOn pořadí, nebo podle pořadí, v jakém jsou uvedeny sekvenčně.
Aplikace nf s parametrem applicationEnabled zakázaným se přeskočí.
nfApps s parametrem skipUpgrade nastaveným na enabled jsou přeskočeny, pokud nejsou zjištěny žádné změny.
nfApps, které jsou společné mezi starým a novým NFDV, jsou upgradovány pomocí helm upgrade.
nfApps, které jsou pouze v novém NFDV, jsou nainstalovány pomocí helm install.
nfApps nasazené, ale neodkazované na nový NFDV, jsou odstraněny pomocí helm delete.

Aby se zajistily výsledky, testování nfApp je podporováno pomocí metod helmu, buď testů aktivovaných před helmem, nebo po háku, nebo pomocí samostatného testovacího háku helmu. V případě selhání při pre nebo post hooku je parametr atomic respektován. Při použití atomického/pravdivého (bezpečného) režimu se neúspěšný graf vrátí zpět. S volbou atomic/false se neprovede žádné vrácení zpět. Pro selhání samostatného testovacího háku helmu rollbackOnTestFailure se dodržuje podobná logika jako atomická. Další informace o samostatném testování helmu najdete v následujícím článku: Spuštění testů po instalaci nebo upgradu

Po selhání operace nfApp a následném zpracování selhané nfApp prostřednictvím parametrů atomic nebo rollbackOnTestFailure může operátor řídit způsob, jakým se zpracovávají všechny změny v nfApps, které nastaly před selháním nfApp. Při pozastavení při chybě může operátor vynutit přerušení AOSM po vyřešení selhání aplikace nfApp, čímž zachová prostředí s různými verzemi. Při vrácení do původního stavu při selhání může operátor donutit systém AOSM, aby se vrátil zpět a obnovil předchozí verzi aplikace nfApp a původní snímek prostředí. Další informace o řízení chování při selhání upgradu najdete v následujícím článku: Řízení chování při selhání upgradu

Úvahy o upgradech během provozu

Azure Operator Service Manager obecně podporuje upgrady služeb, což je metoda upgradu, která přejde na verzi nasazení bez přerušení spuštěné služby. Některé aspekty vlastníka síťové funkce jsou nezbytné k zajištění správného chování AOSM během operací ISSU.

Kde AOSM provádí upgrade na seřazenou sadu více aplikací nfApps, AOSM nejprve upgraduje nebo vytvoří všechny nové aplikace nfApps a pak odstraní všechny staré aplikace nfApps. Tento přístup zajišťuje, že služba nebude ovlivněna, dokud nebudou připraveny všechny nové aplikace nfApps, ale vyžaduje dodatečnou kapacitu platformy pro přechodné hostování starých i nových nfApps.
Když AOSM upgraduje nfApp s více replikami, respektuje nastavení profilu nasazení pro postupné nasazení nebo obnovu. Při použití válcování zpřístupňte hodnoty maxUnavailable a maxSurge jako parametry CGS, které je pak možné nastavit prostřednictvím operátoru CGV za běhu.

Schopnost dané služby se v konečném důsledku upgradovat bez přerušení je funkcí samotné služby. Další informace o možnostech upgradu v rámci služby najdete v vydavateli služby a ujistěte se, že jsou v souladu se správnými možnostmi chování AOSM.

Požadavky na bezpečný upgrade

Při plánování upgradu pomocí AOSM vyřešte následující požadavky před provedením upgradu, abyste optimalizovali čas strávený pokusem a zajistili úspěch upgradu.

Začlenění aktualizovaných artefaktů pomocí pracovních postupů vydavatele nebo návrháře
- Ve většině případů použijte existujícího vydavatele k hostování artefaktů nové verze.
  - Použití existujícího vydavatele umožňuje helm upgrade aktualizaci SNS na jinou verzi.
  - Použití nového vydavatele vyžaduje provedení helm delete na stávajícím SNS a poté helm install pro novou verzi SNS.
- Úložiště artefaktů, skupina návrhu síťových služeb (NSDG) a skupina návrhu síťových funkcí (NFDG) jsou neměnné a nemůžou se měnit.
  - Změna některého z těchto prostředků vyžaduje nasazení nového SNS.
- K uložení nových grafů a obrázků je potřeba nový manifest artefaktů.
  - Podrobnosti o nahrávání nových grafů a obrázků najdete v dokumentaci k onboardingu .
- Je potřeba nová verze návrhu NFDV a volitelně i verze návrhu síťové služby (NSDV).
  - Změny NFDV můžou být složité. Probereme pouze základní změny v tomto článku.
  - Nová verze NSDV se vyžaduje jenom v případě, že se zavádí nová verze schématu skupiny konfigurace (CGS).
- V případě potřeby nové CGS.
  - Vyžaduje se, pokud upgrade zavádí nové vystavené konfigurační parametry.

Poznámka:

Ve stejných NSDG a NFDG lze podporovat NSDV a NFDV s různými hlavními verzemi.

Vytvořte aktualizované artefakty pomocí pracovního postupu Operátora
- V případě potřeby vytvořte nové hodnoty skupiny konfigurace (CGV) na základě nových CGS.
- Znovu použijte a vytvořte užitečné zatížení tak, že ověříte existující objekty lokality a objektů síťových služeb lokality.
Aktualizujte šablony, aby se zajistilo, že jsou parametry upgradu nastavené na základě spolehlivosti upgradu a požadovaného chování selhání.
- Nastavení použitá pro produkční prostředí můžou potlačit podrobnosti o chybách, zatímco nastavení použitá pro ladění nebo testování se mohou rozhodnout tyto podrobnosti zveřejnit.

Postup bezpečného upgradu

Pokud chcete aktivovat upgrade pomocí AOSM, postupujte podle následujícího postupu.

Vytvoření nového prostředku NFDV
- U nových verzí NFDV musí být v platném formátu SemVer. Nová verze může být upgrade, vyšší hodnota oproti nasazené verzi nebo downgrade, nižší než nasazená verze. Nová verze se může lišit podle hlavní verze, vedlejší verze nebo opravné verze.
Aktualizace nových parametrů NFDV
- Verze chartů Helm nebo hodnoty Helm lze aktualizovat či parametrizovat podle potřeby. Nové aplikace nfApps je možné přidat také tam, kde v nasazené verzi neexistují.
Aktualizace NFDV pro požadovanou objednávku nfApp
- UpdateDependsOn je parametr NFDV použitý k určení pořadí nfApps během operací aktualizace. Pokud updateDependsOn není k dispozici, použije se sériové řazení aplikací CNF, jak se zobrazuje v NFDV.
Aktualizujte šablonu ARM pro požadované chování při upgradu
- Nezapomeňte nastavit požadovanou aplikaci CNF timeout, parametr atomic a parametr rollbackOnTestFailure. Může být užitečné tyto parametry v průběhu času změnit, protože při upgradu se získává větší jistota.
Vystavení reputace SNS
- Po dokončení onboardingu se odešle operace související s reputací. V závislosti na počtu, velikosti a složitosti nfApps může dokončení operace reput trvat delší dobu (několik hodin).
Prozkoumání výsledků reputace
- Pokud reputace hlásí úspěšný výsledek, upgrade se dokončí a uživatel by měl ověřit stav a dostupnost služby. Pokud zpráva oznamuje selhání, pokračujte podle kroků uvedených v části "Obnova po selhání upgradu".

Bezpečná procedura opakování upgradu

V případech, kdy dojde k selhání aktualizace reputace, je možné provést následující proces a zkusit operaci zopakovat.

Diagnostika selhání aplikace nfApp
- Vyřešte původní příčinu selhání nfApp analýzou protokolů a dalších informací o ladění.
Ruční přeskočení dokončených grafů
- Po opravě neúspěšné aplikace nfApp, ale před pokusem o opakování aktualizace, zvažte změnu parametru applicationEnablement, aby se urychlilo chování při opakování. Tento parametr může být nastaven na false, kde by se měla přeskočit aplikace nfApp. Tento parametr může být užitečný v případě, že nfApp nevyžaduje upgrade.
Problém s opakovanými pokusy SNS (opakovat až do úspěchu)
- Ve výchozím nastavení reputace opakuje nfApps v deklarované pořadí aktualizací, pokud nejsou přeskočeny pomocí applicationEnablement příznaku.

Řízení časových limitů pomocí installOptions a UpgradeOptions

Když operace SNS spustí buď helm install nebo helm upgrade, použije se výchozí hodnota časového limitu 27 minut. I když tuto hodnotu lze přizpůsobit na úrovni globální síťové funkce (NF), doporučujeme tuto hodnotu přizpůsobit na úrovni NF komponenty pomocí roleOverrideValues šablony datové části NF. Další zpřístupnění roleOverrideValues v CGS/CGV umožňuje řízení operátorem během provozu. Následující příklad ukazuje podporované parametry installOptions a upgradeOptions použité ve dvou komponentách nfApp;

{
  "roleOverrideValues": [
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1"
            } } } } }
  ]
}

Přeskočit nfApps pomocí funkce applicationEnablement

V prostředku NFDV je v části deployParametersMappingRuleProfile podporovaná vlastnost applicationEnablement výčtu typu, která přebírá hodnoty Unknown, Enabled nebo disabled. Dá se použít k ručnímu vyloučení operací nfApp během nasazování síťových funkcí. Následující příklad ukazuje obecnou metodu parametrizovat applicationEnablement jako zahrnutou hodnotu ve roleOverrideValues vlastnosti.

Změny šablon NFDV

I když nejsou nutné žádné změny NFDV, volitelně může vydavatel použít NFDV k nastavení výchozí hodnoty vlastnosti applicationEnablement . Použije se výchozí hodnota, pokud se nezmění prostřednictvím roleOverrideValues. Pomocí šablony NFDV nastavte výchozí hodnotu pro applicationEnablement. Následující příklad nastaví enabled stav jako výchozí hodnotu pro hellotest networkfunctionApplication.

      "location":"<location>", 
      "properties": {
      "networkFunctionTemplate": {
        "networkFunctionApplications": [
            "deployParametersMappingRuleProfile": {
              "applicationEnablement": "Enabled"
            },
            "name": "hellotest"
        ],
        "nfviType": "AzureArcKubernetes"
        },
      }

Pokud chcete hodnotu spravovat applicationEnablement dynamicky, operátor může předat hodnotu v reálném čase pomocí vlastnosti šablony roleOverrideValues NF. I když je možné, aby operátor manipuloval se šablonou NF přímo, místo toho parametrizovat roleOverrideValues, aby hodnoty mohly být předány prostřednictvím šablony CGV za běhu. Následující příklady ukazují potřebné úpravy CGS, šablon NF a nakonec CGV.

Změny šablony CGS

Šablona CGS musí být aktualizována tak, aby obsahovala jednu deklaraci proměnné pro každý řádek, který se má parametrizovat v části roleOverrideValues. Následující příklad ukazuje tři přepisové hodnoty.

        "roleOverrideValues0": {
          "type": "string"        
        },    
        "roleOverrideValues1": {
          "type": "string"        
        },        
        "roleOverrideValues2": {
          "type": "string"
        }

Změny šablony datové části NF

Šablona NF musí být aktualizována třemi způsoby. Nejprve musí být implicitní konfigurační parametr definován jako objekt typu. Za druhé, roleOverrideValues0, roleOverrideValues1a roleOverrideValues2 musí být deklarovány jako proměnné mapované na parametr konfigurace. Za třetí, roleOverrideValues0, roleOverrideValues1 a roleOverrideValues2 musí být použity jako náhrada ve roleOverrideValues ve správném pořadí a při dodržení správné syntaxe.

  "parameters": {
    "config": {
      "type": "object",
      "defaultValue": {}
    }
  }
  "variables": {
    "roleOverrideValues0": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues1": "[string(parameters('config').roleOverrideValues1)]",
    "roleOverrideValues2": "[string(parameters('config').roleOverrideValues2)]"
  },
  "resources": [
  {
<snip>
     "roleOverrideValues": [
          "[variables('roleOverrideValues0')]",
          "[variables('roleOverrideValues1')]",
          "[variables('roleOverrideValues2')]"
        ]
   }

Změny šablon CGV

Šablonu CGV je teď možné aktualizovat tak, aby zahrnovala obsah každé proměnné, která se má nahradit vlastností roleOverrideValues za běhu. Následující příklad nastaví rollbackEnabled na true, a poté přepíše sady pro hellotest a hellotest1 nfApplications.

{
    "roleOverrideValues0": "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",
    "roleOverrideValues1": "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\":\"Enabled\",\"helmMappingRuleProfile\":{\"releaseName\":\"override-release\",\"releaseNamespace\":\"override-namespace\",\"helmPackageVersion\":\"1.0.0\",\"values\":\"\",\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"30\",\"injectArtifactStoreDetails\":\"true\"}}}}}",
    "roleOverrideValues2": "{\"name\":\"hellotest1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Enabled\"}}"
}

S tímto rámcem na místě může operátor spravovat libovolnou z roleOverrideValues pomocí jednoduchých aktualizací CGV, a poté připojit tento CGV k požadované operaci SNS.

Přeskočte nfApps, které jsou bez změn

Tato skipUpgrade funkce je navržená tak, aby optimalizovala dobu potřebnou pro upgrady CNF. Pokud vydavatel povolí tento příznak v roleOverrideValues části upgradeOptions, vrstva služby AOSM provádí určité předběžné kontroly, aby určila, zda je možné přeskočit upgrade konkrétního nfApplication objektu. Pokud jsou splněna všechna kritéria předběžné kontroly, upgrade se pro tuto aplikaci přeskočí. V opačném případě se upgrade spustí na úrovni clusteru.

Předběžná kontrola kritérií

Upgrade je možné přeskočit, pokud jsou splněny všechny následující podmínky:

Stav nfApplication zřizování je dokončen.
Název nebo verze chartu Helm se nijak nemění.
Hodnoty Helmu se nemění.

Povolení nebo zakázání funkce skipUpgrade

Funkce skipUpgrade je ve výchozím nastavení zakázaná. Pokud tento volitelný parametr není zadaný v roleOverrideValues části upgradeOptions, upgrady CNF probíhají tradičním způsobem, kde nfApplications se upgradují na úrovni clusteru.

Povolení funkce SkipUpgrade v prostředku síťové funkce

Pokud chcete funkci SkipUpgrade povolit prostřednictvím roleOverrideValues, projděte si následující příklad.

{
    "location": "eastus2euap",
    "properties": {
        "publisherName": "xyAzureArcRunnerPublisher",
        "publisherScope": "Private",
        "networkFunctionDefinitionGroupName": "AzureArcRunnerNFDGroup",
        "networkFunctionDefinitionVersion": "1.0.0",
        "networkFunctionDefinitionOfferingLocation": "eastus2euap",
        "nfviType": "AzureArcKubernetes",
        "nfviId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourcegroups/ashutosh_test_rg/providers/microsoft.extendedlocation/customlocations/ashutosh_test_cl",
        "deploymentValues": "",
        "roleOverrideValues": [
            "{\"name\":\"hellotest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"1\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\",\"skipUpgrade\":\"true\"}}}}}",
            "{\"name\":\"runnerTest\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"5\"}}}}}"
        ]
    }
}

Vysvětlení příkladu

nfApplication: hellotest
- Příznak skipUpgrade je povolený. Pokud žádost o upgrade hellotest splňuje kritéria předběžné kontroly, upgrade se přeskočí.
nfApplication: runnerTest
- Příznak skipUpgrade není zadaný. runnerTest Proto provede tradiční upgrade Helmu na úrovni clusteru, i když jsou splněna kritéria předběžné kontroly.

Úplný odkaz na možnost roleOverrideValues

Spojení všech příkladů v tomto a jiných článcích následující odkaz demonstruje všechny momentálně podporované možnosti dostupné skrze mechanismus roleOverrideValues.

{
  "roleOverrideValues": [
    {
      "nfConfiguration": {
        "rollbackEnabled": "true"
      }
    },
    {
      "name": "nfApplication1",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    },
    {
      "name": "nfApplication2",
      "deployParametersMappingRuleProfile": {
        "helmMappingRuleProfile": {
          "options": {
            "installOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            },
            "upgradeOptions": {
              "atomic": "true",
              "wait": "true",
              "timeout": "1",
              "skipUpgrade": "true",
              "testOptions": {
                "enable": "true",
                "timeout": "true",
                "rollbackOnTestFailure": "true",
                "filter": [
                  "test1",
                  "test2"
                ]
              }
            }
          }
        }
      }
    }
  ]
}

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-05-21