Osvědčené postupy pro provozní kontinuitu a zotavení po havárii v Azure Kubernetes Service (AKS)

Při správě clusterů v Azure Kubernetes Service (AKS) je doba provozu aplikace důležitá. Ve výchozím nastavení poskytuje AKS vysokou dostupnost pomocí více uzlů ve škálovací sadě virtuálních počítačů (VMSS). Tyto více uzlů ale váš systém nechrání před selháním oblasti. Pokud chcete maximalizovat dobu provozu, naplánujte si dopředu zachování provozní kontinuity a přípravy na zotavení po havárii.

Tento článek se zaměřuje na plánování provozní kontinuity a zotavení po havárii v AKS. Získáte informace o těchto tématech:

  • Naplánujte clustery AKS ve více oblastech.
  • Směrování provozu napříč několika clustery pomocí Azure Traffic Manager
  • Pro registry imagí kontejnerů použijte geografickou replikaci.
  • Naplánujte stav aplikace napříč několika clustery.
  • Replikace úložiště napříč několika oblastmi

Plánování nasazení ve více oblastech

Osvědčených

Když nasadíte více clusterů AKS, zvolte oblasti, ve kterých je AKS k dispozici. Použijte spárované oblasti.

Cluster AKS se nasadí do jedné oblasti. Pokud chcete chránit systém před selháním oblasti, nasaďte aplikaci do několika clusterů AKS napříč různými oblastmi. Při plánování nasazení clusteru AKS zvažte:

  • Dostupnost oblasti AKS
    • Zvolte oblasti blízko uživatelů.
    • AKS se průběžně rozšiřuje do nových oblastí.
  • Spárované oblasti Azure
    • Pro svoji geografickou oblast zvolte dvě spárované oblasti.
    • Aktualizace platformy AKS (plánovaná údržba) se serializují se zpožděním nejméně 24 hodin mezi spárovanými oblastmi.
    • Úsilí o obnovení spárovaných oblastí je v případě potřeby upřednostňováno.
  • Dostupnost služby
    • Rozhodněte se, jestli vaše spárované oblasti mají být horké/ horké, teplé nebo teplé nebo studené.
    • Chcete současně spouštět obě oblasti, přičemž jedna oblast je připravená začít obsluhovat provoz? Nebo:
    • Chcete dát čas na jednu oblast, abyste se mohli připravit na provoz?

Dostupnost oblastí AKS a spárované oblasti jsou společným aspektem. Nasaďte clustery AKS do spárovaných oblastí navržených ke správě zotavení po havárii oblasti. Například AKS je k dispozici v oblasti USA – východ a USA – západ. Tyto oblasti jsou spárované. Tyto dvě oblasti vyberte při vytváření strategie AKS BC/DR.

Když nasadíte aplikaci, přidejte do kanálu CI/CD další krok, který nasadí do těchto několika clusterů AKS. Aktualizace kanálů nasazení brání aplikacím v nasazení pouze do jedné z vašich oblastí a clusterů AKS. V tomto scénáři nebude zákaznický provoz směrovaný do sekundární oblasti dostávat nejnovější aktualizace kódu.

Směrování provozu pomocí Azure Traffic Manager

Osvědčených

Azure Traffic Manager vás může nasměrovat na nejbližší cluster AKS a instanci aplikace. Pokud chcete dosáhnout nejlepšího výkonu a redundance, nasměrujte veškerý provoz aplikací přes Traffic Manager, než přejdete do clusteru AKS.

Pokud máte v různých oblastech více clusterů AKS, použijte Traffic Manager k řízení toku provozu do aplikací spuštěných v jednotlivých clusterech. Azure Traffic Manager je nástroj pro vyrovnávání zatížení provozu založený na DNS, který dokáže distribuovat síťový provoz mezi oblasti. Pomocí Traffic Manager můžete směrovat uživatele na základě doby odezvy clusteru nebo na základě zeměpisné oblasti.

AKS with Traffic Manager

Pokud máte jeden cluster AKS, obvykle se připojujete k IP adrese služby nebo názvu DNS dané aplikace. V nasazení s více clustery byste se měli připojit k Traffic Manager názvu DNS, který odkazuje na služby v každém clusteru AKS. Definujte tyto služby pomocí Traffic Manager koncových bodů. Každý koncový bod je IP adresa nástroje pro vyrovnávání zatížení služby. Pomocí této konfigurace můžete směrovat síťový provoz z koncového bodu Traffic Manager v jedné oblasti na koncový bod v jiné oblasti.

Geographic routing through Traffic Manager

Traffic Manager provede vyhledávání DNS a vrátí nejvhodnější koncový bod. Vnořené profily můžou určit prioritu primárního umístění. Měli byste se například připojit k nejbližší geografické oblasti. Pokud má tato oblast problém, Traffic Manager vás nasměruje do sekundární oblasti. Tento přístup zajišťuje, že se můžete připojit k instanci aplikace i v případě, že vaše nejbližší geografická oblast není k dispozici.

Informace o tom, jak nastavit koncové body a směrování, najdete v tématu Konfigurace metody směrování geografického provozu pomocí Traffic Manager.

Směrování aplikací pomocí služby Azure Front Door Service

Pomocí rozděleného protokolu TCP anycast služba Azure Front Door Service okamžitě připojí koncové uživatele k nejbližšímu protokolu POP služby Front Door (bod přítomnosti). Další funkce služby Azure Front Door Service:

  • Ukončení šifrování TLS
  • Vlastní doména
  • Firewall webových aplikací
  • Přepsání adresy URL
  • Spřažení relací

Projděte si potřeby provozu vaší aplikace, abyste pochopili, které řešení je nejvhodnější.

Propojení oblastí s globálním partnerským vztahem virtuálních sítí

Připojení obě virtuální sítě navzájem prostřednictvím partnerského vztahu virtuálních sítí, aby bylo možné komunikovat mezi clustery. Partnerský vztah virtuálních sítí propojuje virtuální sítě a poskytuje velkou šířku pásma v páteřní síti Microsoftu – i v různých geografických oblastech.

Před partnerským vztahem virtuálních sítí se spuštěnými clustery AKS použijte standardní Load Balancer v clusteru AKS. Díky tomuto předpokladu jsou služby Kubernetes dostupné napříč partnerským vztahem virtuálních sítí.

Povolení geografické replikace pro image kontejnerů

Osvědčených

Uložte image kontejnerů do Azure Container Registry a geograficky replikujte registr do každé oblasti AKS.

K nasazení a spuštění aplikací v AKS potřebujete způsob, jak ukládat a načíst image kontejneru. Container Registry se integruje s AKS, aby mohl bezpečně ukládat image kontejnerů nebo charty Helm. Container Registry podporuje multimaster geografickou replikaci, která automaticky replikuje image do oblastí Azure po celém světě.

Zvýšení výkonu a dostupnosti:

  1. Geografickou replikaci služby Container Registry použijte k vytvoření registru v každé oblasti, ve které máte cluster AKS.
  2. Každý cluster AKS pak načítá image kontejneru z místního registru kontejneru ve stejné oblasti:

Container Registry geo-replication for container images

Pokud ke stažení imagí ze stejné oblasti použijete geografickou replikaci služby Container Registry, výsledky jsou následující:

  • Rychlejší: Načítání imagí z vysokorychlostních síťových připojení s nízkou latencí ve stejné oblasti Azure
  • Spolehlivější: Pokud je oblast nedostupná, cluster AKS načítá image z dostupného registru kontejneru.
  • Levnější: Mezi datovými centry se neúčtují žádné poplatky za výchozí přenos dat.

Geografická replikace je funkce registru kontejneru Premium skladové položky. Informace o konfiguraci geografické replikace najdete v tématu Geografická replikace služby Container Registry.

Odebrání stavu služby z kontejnerů

Osvědčených

Vyhněte se ukládání stavu služby v kontejneru. Místo toho použijte platformu Azure jako službu (PaaS), která podporuje replikaci mezi více oblastmi.

Stav služby odkazuje na data v paměti nebo na disku požadovaná službou pro funkci. Stav zahrnuje datové struktury a členské proměnné, které služba čte a zapisuje. V závislosti na tom, jak je služba navržena, může stát obsahovat také soubory nebo jiné prostředky uložené na disku. Například stav může obsahovat soubory, které databáze používá k ukládání dat a transakčních protokolů.

Stav může být externě nebo spolusoustavěn s kódem, který pracuje se stavem. Obvykle provádíte externalizaci stavu pomocí databáze nebo jiného úložiště dat, které běží na různých počítačích přes síť nebo které na stejném počítači dochází k procesu.

Kontejnery a mikroslužby jsou nejodolnější, když procesy spuštěné uvnitř nich nezachovají stav. Vzhledem k tomu, že aplikace téměř vždy obsahují nějaký stav, použijte řešení PaaS, například:

  • Azure Cosmos DB
  • Azure Database for PostgreSQL
  • Azure Database for MySQL
  • Azure SQL Database

Pokud chcete vytvářet přenosné aplikace, projděte si následující pokyny:

Vytvoření plánu migrace úložiště

Osvědčených

Pokud používáte Azure Storage, připravte a otestujte, jak migrovat úložiště z primární oblasti do oblasti zálohování.

Vaše aplikace můžou pro svá data používat Azure Storage. Pokud ano, vaše aplikace jsou rozložené do více clusterů AKS v různých oblastech. Úložiště je potřeba udržovat synchronizované. Úložiště můžete replikovat dvěma běžnými způsoby:

  • Asynchronní replikace založená na infrastruktuře
  • Asynchronní replikace založená na aplikacích

Asynchronní replikace založená na infrastruktuře

Vaše aplikace můžou vyžadovat trvalé úložiště i po odstranění podu. V Kubernetes můžete k trvalému ukládání dat použít trvalé svazky. Trvalé svazky se připojují k virtuálnímu počítači uzlu a pak jsou vystavené podům. Trvalé svazky sledují pody, i když se pody přesunou do jiného uzlu ve stejném clusteru.

Strategie replikace, kterou používáte, závisí na vašem řešení úložiště. Následující běžná řešení úložiště poskytují vlastní pokyny k zotavení po havárii a replikaci:

Obvykle zadáte běžný bod úložiště, kde aplikace zapisují svá data. Tato data se pak replikují napříč oblastmi a přistupuje se k nim místně.

Infrastructure-based asynchronous replication

Pokud používáte Azure Spravované disky, můžete použít Velero v Azure a Kasten ke zpracování replikace a zotavení po havárii. Tyto možnosti jsou zálohovat řešení nativní pro Kubernetes, ale nepodporuje je.

Asynchronní replikace založená na aplikacích

Kubernetes v současné době neposkytuje žádnou nativní implementaci pro asynchronní replikaci založenou na aplikacích. Vzhledem k tomu, že kontejnery a Kubernetes jsou volně svázané, měl by fungovat jakýkoli tradiční přístup k aplikacím nebo jazykům. Aplikace samy obvykle replikují požadavky na úložiště, které se pak zapisují do podkladového úložiště dat každého clusteru.

Application-based asynchronous replication

Další kroky

Tento článek se zaměřuje na aspekty provozní kontinuity a zotavení po havárii pro clustery AKS. Další informace o operacích clusteru v AKS najdete v těchto článcích o osvědčených postupech: