Sdílet prostřednictvím

Migrace úloh z Service Fabric do AKS

  • Článek

Mnoho organizací přechází do kontejnerizovaných aplikací jako součást přechodu na přijetí moderních vývojových aplikací, osvědčených postupů údržby a architektur nativních pro cloud. Vzhledem k tomu, že se technologie stále vyvíjejí, musí organizace vyhodnotit řadu kontejnerizovaných aplikačních platforem, které jsou dostupné ve veřejném cloudu.

Pro aplikace neexistuje žádné univerzální řešení, ale organizace často zjistí, že Azure Kubernetes Service (AKS) splňuje požadavky pro mnoho svých kontejnerizovaných aplikací. AKS je spravovaná služba Kubernetes, která zjednodušuje nasazení aplikací prostřednictvím Kubernetes tím, že spravuje řídicí rovinu a poskytuje základní služby pro úlohy aplikací. Řada organizací používá AKS jako primární platformu infrastruktury a přechodové úlohy hostované na jiných platformách do AKS.

Tento článek popisuje, jak migrovat kontejnerizované aplikace z Azure Service Fabric do AKS. Článek předpokládá, že jste obeznámeni se Service Fabric, ale zajímá vás, jak se jeho funkce a funkce porovnávají s funkcemi AKS. Článek obsahuje také osvědčené postupy, které byste měli zvážit během migrace.

Porovnání AKS s Service Fabric

Pokud chcete začít, přečtěte si téma Volba výpočetní služby Azure spolu s dalšími výpočetními službami Azure. Tato část popisuje významné podobnosti a rozdíly, které jsou relevantní pro migraci.

Service Fabric i AKS jsou orchestrátory kontejnerů. Service Fabric poskytuje podporu pro několik programovacích modelů, ale AKS podporuje pouze kontejnery.

  • Programovací modely: Service Fabric podporuje různé způsoby zápisu a správy služeb, včetně kontejnerů Linuxu a Windows, Reliable Services, Reliable Actors, ASP.NET Core a spustitelných souborů hosta.

  • Kontejnery v AKS: AKS podporuje kontejnerizaci pouze s kontejnery Windows a Linuxu, které běží v kontejneru runtime kontejneru, který se spravuje automaticky.

Service Fabric i AKS poskytují integrace s dalšími službami Azure, včetně Azure Pipelines, Azure Monitoru, Azure Key Vaultu a Microsoft Entra ID.

Klíčové rozdíly

Když nasadíte tradiční cluster Service Fabric místo spravovaného clusteru, musíte explicitně definovat prostředek clusteru společně s mnoha podpůrnými prostředky v šablonách Azure Resource Manageru (šablony ARM) nebo modulech Bicep. Mezi tyto prostředky patří škálovací sada virtuálních počítačů pro každý typ uzlu clusteru, skupiny zabezpečení sítě a nástroje pro vyrovnávání zatížení. Je vaší zodpovědností zajistit, aby byly tyto prostředky správně nakonfigurované. Naproti tomu model zapouzdření pro spravované clustery Service Fabric se skládá z jednoho prostředku spravovaného clusteru. Všechny základní prostředky pro cluster jsou abstrahovány a spravovány Azure.

AKS zjednodušuje nasazení spravovaného clusteru Kubernetes v Azure tím, že přesměruje provozní režii do Azure. Vzhledem k tomu, že AKS je hostovaná služba Kubernetes, Azure zpracovává důležité úlohy, jako je monitorování stavu infrastruktury a údržba. Azure spravuje hlavní uzly Kubernetes, takže stačí spravovat a udržovat uzly agenta.

Pokud chcete přesunout úlohu z Service Fabric do AKS, musíte porozumět rozdílům v základní infrastruktuře, abyste mohli bez obav migrovat kontejnerizované aplikace. Následující tabulka porovnává možnosti a funkce obou hostitelských platforem.

Schopnost nebo komponenta Service Fabric AKS
Nekotenerizované aplikace Yes No
Kontejnery Windows a Linuxu Ano Yes
Řídicí rovina spravovaná v Azure No Ano
Podpora bezstavových i stavových úloh Ano Yes
Umístění pracovního uzlu Škálovací sady virtuálních počítačů, nakonfigurované zákazníkem Škálovací sady virtuálních počítačů, spravované Azure
Manifest konfigurace XML YAML
Integrace služby Azure Monitor Ano Yes
Nativní podpora modelu Reliable Services a Reliable Actor Yes No
Komunikační zásobník založený na WCF pro Reliable Services Yes No
Trvalé úložiště Ovladač svazku Azure Files Podpora různých systémů úložiště, jako jsou spravované disky, Soubory Azure a Azure Blob Storage prostřednictvím tříd služby CSI Storage, trvalých svazků a deklarací trvalých svazků
Síťové režimy Integrace virtuální sítě Azure Podpora více síťových modulů plug-in (Azure CNI, kubenet, BYOCNI), zásad sítě (Azure, Calico) a kontrolerů příchozího přenosu dat (kontroler příchozího přenosu dat služby Application Gateway, NGINX a další)
Kontrolery příchozích dat Reverzní proxy server , který je integrovaný do Service Fabric. Pomáhá mikroslužbám, které běží v clusteru Service Fabric, zjišťovat a komunikovat s jinými službami, které mají koncové body HTTP. Traefik můžete použít také ve službě Service Fabric. Spravovaný kontroler příchozího přenosu dat NGINX, příchozí přenos dat BYO open source a komerční kontrolery, které používají veřejné nebo interní nástroje pro vyrovnávání zatížení spravované platformou, jako je kontroler příchozího přenosu dat NGINX a kontroler příchozího přenosu dat služby Application Gateway

Poznámka:

Pokud používáte kontejnery Windows v Service Fabric, doporučujeme je použít v AKS, abyste si usnadnili migraci.

Kroky migrace

Obecně platí, že kroky migrace z Service Fabric do AKS jsou následující.

Diagram znázorňující kroky migrace z Service Fabric do AKS

  1. Vytvořte architekturu nasazení a vytvořte cluster AKS. AKS nabízí různé možnosti konfigurace přístupu ke clusteru, škálovatelnosti uzlů a podů, síťového přístupu a konfigurace a dalších možností. Další informace o typické architektuře nasazení najdete v části Ukázková architektura. Základní architektura AKS poskytuje také pokyny pro nasazení a monitorování clusteru. Konstrukce AKS poskytuje šablony rychlého startu pro nasazení clusteru AKS na základě obchodních a technických požadavků.

  2. Změna architektury aplikace Service Fabric Pokud používáte programovací modely, jako jsou Reliable Services nebo Reliable Actors, nebo pokud používáte jiné konstrukce specifické pro Service Fabric, možná budete muset změnit architekturu aplikace. Pokud chcete implementovat správu stavu při migraci ze služby Reliable Services, použijte modul Runtime distribuované aplikace (Dapr). Kubernetes poskytuje vzory a příklady pro migraci z Reliable Actors.

  3. Zabalte aplikaci jako kontejnery. Visual Studio poskytuje možnosti pro generování souboru Dockerfile a zabalení aplikace jako kontejnery. Nasdílení imagí kontejneru, které vytvoříte, do služby Azure Container Registry

  4. Přepište konfigurační soubory XML Service Fabric jako soubory YAML Kubernetes. Aplikaci nasadíte do AKS pomocí souborů YAML nebo jako balíčku pomocí chartů Helm. Další informace naleznete v tématu Manifest aplikace a služby.

  5. Nasaďte aplikaci do clusteru AKS.

  6. Přesun provozu do clusteru AKS na základě strategií nasazení a monitorování chování, dostupnosti a výkonu aplikace.

Příklad architektury

AKS a Azure poskytují flexibilitu při konfiguraci prostředí tak, aby vyhovovaly vašim obchodním potřebám. AKS je dobře integrovaná s dalšími službami Azure. Příkladem je základní architektura AKS.

Diagram znázorňující základní architekturu AKS

Jako výchozí bod se seznamte s některými klíčovými koncepty Kubernetes a projděte si některé ukázkové architektury:

Poznámka:

Při migraci úlohy z Service Fabric do AKS můžete nahradit Service Fabric Reliable Actors stavebním blokem dapr actors. Spolehlivé kolekce Service Fabric můžete nahradit stavebním blokem správy stavu Dapr.

Dapr poskytuje rozhraní API, která zjednodušují připojení mikroslužeb. Další informace najdete v tématu Úvod do dapr. Jako rozšíření AKS doporučujeme nainstalovat Dapr.

Manifest aplikace a služby

Service Fabric a AKS mají různé typy a konstrukce souborů manifestu aplikací a služeb. Service Fabric používá soubory XML pro definici aplikace a služby. AKS používá manifest souboru YAML Kubernetes k definování objektů Kubernetes. Neexistují žádné nástroje, které by konkrétně měly migrovat soubor Service Fabric XML do souboru YAML Kubernetes. Informace o tom, jak soubory YAML fungují v Kubernetes, ale najdete v následujících zdrojích informací.

Helm můžete použít k definování parametrizovaných manifestů YAML a vytváření obecných šablon nahrazením statických, pevně zakódovaných hodnot zástupnými symboly, které můžete nahradit vlastními hodnotami, které jsou zadané v době nasazení. Výsledné šablony, které obsahují vlastní hodnoty, se vykreslí jako platné manifesty pro Kubernetes.

Kustomize představuje způsob, jak přizpůsobit konfiguraci aplikace bez šablon, která zjednodušuje používání aplikací mimo polici. Kustomize můžete použít společně s Helmem nebo jako alternativu k Helmu.

Další informace o Helmu a Kustomize najdete v následujících zdrojích informací:

Sítě

AKS poskytuje dvě možnosti pro podkladovou síť:

  • Přineste si vlastní virtuální síť Azure, abyste zřídili uzly clusteru AKS do podsítě z virtuální sítě, kterou zadáte.

  • Umožňuje poskytovateli prostředků AKS vytvořit novou virtuální síť Azure ve skupině prostředků uzlu, která obsahuje všechny prostředky Azure, které cluster používá.

Pokud zvolíte druhou možnost, Azure spravuje virtuální síť.

Service Fabric neposkytuje výběr síťových modulů plug-in. Pokud používáte AKS, musíte zvolit jednu z těchto možností:

  • kubenet. Pokud používáte kubenet, uzly z podsítě virtuální sítě Azure získají IP adresu. Pody přijímají IP adresu z adresního prostoru, který se logicky liší od podsítě virtuální sítě Azure uzlů. Překlad adres (NAT) se pak nakonfiguruje tak, aby pody mohly získat přístup k prostředkům ve virtuální síti Azure. Zdrojová IP adresa provozu se přeloží přes překlad adres (NAT) na primární IP adresu uzlu. Tento přístup výrazně snižuje počet IP adres, které potřebujete rezervovat v síťovém prostoru, aby se pody mohly používat.

  • Azure CNI. Pokud používáte rozhraní CNI (Container Networking Interface), každý pod získá IP adresu z podsítě a bude přístupný přímo. Tyto IP adresy musí být jedinečné v rámci vašeho síťového prostoru a musí být naplánovány předem. Každý uzel má parametr konfigurace pro maximální počet podů, které podporuje. Pak si pro každý uzel rezervujete ekvivalentní počet IP adres. Tento přístup vyžaduje větší plánování a často vede k vyčerpání IP adres nebo nutnosti znovu sestavit clustery ve větší podsíti s rostoucími požadavky vaší aplikace. Můžete nakonfigurovat maximální počet podů, které se dají nasadit do uzlu při vytváření clusteru nebo při vytváření nových fondů uzlů.

  • Překryvné sítě Azure CNI Pokud používáte Překryv Azure CNI, nasadí se uzly clusteru do podsítě služby Azure Virtual Network. Podům se přiřazují IP adresy z privátní ciDR, které se logicky liší od adresy virtuální sítě, která je hostitelem uzlů. Provoz podů a uzlů v rámci clusteru používá překryvnou síť. Překlad adres (NAT) používá IP adresu uzlu k přístupu k prostředkům mimo cluster. Toto řešení šetří velký počet IP adres virtuální sítě a pomáhá bezproblémově škálovat cluster na velké velikosti. Další výhodou je, že privátní CIDR můžete znovu použít v různých clusterech AKS, což rozšiřuje prostor IP adres, který je k dispozici pro kontejnerizované aplikace v AKS.

  • Azure CNI Powered by Cilium. Azure CNI Powered by Cilium kombinuje robustní řídicí rovinu Azure CNI s datovou rovinou Cilium , která pomáhá poskytovat vysoce výkonné sítě a lepší zabezpečení.

  • Přineste si vlastní modul plug-in CNI. Kubernetes ve výchozím nastavení neposkytuje systém síťového rozhraní. Tato funkce je poskytována síťovými moduly plug-in. AKS poskytuje několik podporovaných modulů plug-in CNI. Další informace o podporovaných modulech plug-in najdete v tématu Koncepty sítě pro aplikace v AKS.

Kontejnery Windows v současné době podporují pouze modul plug-in Azure CNI . K dispozici jsou různé volby zásad sítě a kontrolerů příchozího přenosu dat.

V AKS můžete použít zásady sítě Kubernetes k oddělení a zabezpečení komunikace uvnitř služby tím, že řídíte, které komponenty spolu můžou vzájemně komunikovat. Ve výchozím nastavení můžou všechny pody v clusteru Kubernetes odesílat a přijímat provoz bez omezení. Ke zlepšení zabezpečení můžete použít zásady sítě Azure nebo zásady sítě Calico k definování pravidel, která řídí tok provozu mezi mikroslužbami.

Pokud chcete použít Azure Network Policy Manager, musíte použít modul plug-in Azure CNI. Zásady sítě Calico můžete použít s modulem plug-in Azure CNI nebo modulem plug-in kubenet CNI. Použití Azure Network Policy Manageru pro uzly Windows je podporováno pouze v systému Windows Server 2022. Další informace najdete v tématu Zabezpečení provozu mezi pody pomocí zásad sítě v AKS. Další informace o sítích AKS najdete v tématu Sítě v AKS.

V Kubernetes funguje kontroler příchozího přenosu dat jako proxy služby a zprostředkuje mezi službou a vnějším světem, což umožňuje externí provoz pro přístup ke službě. Proxy služby obvykle poskytuje různé funkce, jako je ukončení protokolu TLS, směrování požadavků na základě cesty, vyrovnávání zatížení a funkce zabezpečení, jako je ověřování a autorizace. Kontrolery příchozího přenosu dat také poskytují další vrstvu abstrakce a řízení směrování externího provozu do služeb Kubernetes na základě pravidel HTTP a HTTPS. Tato vrstva poskytuje jemněji odstupňovanou kontrolu nad tokem provozu a správou provozu.

V AKS existuje několik možností pro nasazení, spuštění a provoz kontroleru příchozího přenosu dat. Jednou z možností je kontroler příchozího přenosu dat služby Application Gateway, který umožňuje používat Aplikace Azure lication Gateway jako kontroler příchozího přenosu dat pro ukončení protokolu TLS, směrování na základě cesty a jako bránu firewall pro webový přístup. Další možností je spravovaný kontroler příchozího přenosu dat NGINX, který poskytuje možnost spravovanou v Azure pro široce používaný kontroler příchozího přenosu dat NGINX. Kontroler příchozího přenosu dat Traefik je dalším oblíbeným kontrolerem příchozího přenosu dat pro Kubernetes.

Každý z těchto kontrolerů příchozího přenosu dat má silné a slabé stránky. Pokud se chcete rozhodnout, který z nich se má použít, zvažte požadavky aplikace a prostředí. Při instalaci nespravovaného kontroleru příchozího přenosu dat se ujistěte, že používáte nejnovější verzi Nástroje Helm a máte přístup k příslušnému úložišti Helm.

Trvalé úložiště

Service Fabric i AKS mají mechanismy pro zajištění trvalého úložiště kontejnerizovaným aplikacím. V Service Fabric poskytuje ovladač svazku Azure Files, což je modul plug-in svazku Dockeru, svazky Azure Files pro kontejnery Linuxu a Windows. Je zabalená jako aplikace Service Fabric, kterou můžete nasadit do clusteru Service Fabric, aby poskytovala svazky pro jiné kontejnerizované aplikace Service Fabric v rámci clusteru. Další informace najdete v tématu Ovladač svazku Azure Files pro Service Fabric.

Aplikace, které běží v AKS, můžou potřebovat ukládat a načítat data z trvalého systému úložiště souborů. AKS se integruje se službami úložiště Azure, jako jsou spravované disky Azure, Soubory Azure, Blob Storage a Azure NetApp Storage (ANF). Integruje se také s úložnými systémy jiných společností než Microsoft, jako jsou Rook a GlusterFS , prostřednictvím ovladačů rozhraní CSI (Container Storage Interface).

CsI je standard pro zveřejnění systémů blokového a souborového úložiště pro kontejnerizované úlohy v Kubernetes. Poskytovatelé úložiště jiných společností než Microsoft, kteří používají csI, můžou psát, nasazovat a aktualizovat moduly plug-in, aby zpřístupnil nové systémy úložiště v Kubernetes nebo zlepšily stávající moduly, aniž by museli měnit základní kód Kubernetes a čekat na jeho cykly vydávání.

Podpora ovladače úložiště CSI v AKS umožňuje nativně používat tyto služby úložiště Azure:

  • Disky Azure Disky Azure můžete použít k vytvoření prostředku Datového disku Kubernetes. Disky můžou využívat úložiště Azure Premium, které je založené na vysoce výkonných discích SSD, nebo úložiště Azure Standard, které je podporováno disky HDD úrovně Standard nebo SSD. Pro většinu produkčních a vývojových úloh použijte premium storage. Disky Azure se připojují jako ReadWriteOnce a jsou k dispozici pouze pro jeden uzel v AKS. Pro svazky úložiště, ke kterým má více podů přístup současně, použijte službu Azure Files.

    Service Fabric naproti tomu podporuje vytvoření clusteru nebo typu uzlu, který používá spravované disky, ale ne aplikace, které dynamicky vytvářejí připojené spravované disky prostřednictvím deklarativního přístupu. Další informace najdete v tématu Nasazení typu uzlu clusteru Service Fabric se spravovanými datovými disky.

  • Azure Files. Soubory Azure můžete použít k připojení sdílené složky SMB 3.0 nebo 3.1 zálohované účtem úložiště Azure k podům. Se službou Azure Files můžete sdílet data napříč několika uzly a pody. Služba Azure Files může využívat úložiště Azure Úrovně Standard založené na standardních pevných discích nebo azure Premium Storage s využitím disků SSD s vysokým výkonem.

    Service Fabric poskytuje ovladač svazku Azure Files jako modul plug-in svazku Dockeru, který poskytuje svazky Azure Files pro kontejnery Dockeru. Service Fabric poskytuje jednu verzi ovladače pro clustery s Windows a jednu pro clustery s Linuxem.

  • Blob Storage. Blob Storage můžete použít k připojení úložiště objektů blob (nebo úložiště objektů) jako systému souborů do kontejneru nebo podu. Úložiště objektů blob umožňuje clusteru AKS podporovat aplikace, které pracují s velkými nestrukturovanými datovými sadami, jako jsou data souborů protokolů, obrázky nebo dokumenty a úlohy prostředí HPC. Pokud ingestujete data do Azure Data Lake Storage, můžete úložiště přímo připojit a použít ho v AKS bez konfigurace jiného dočasného systému souborů. Service Fabric nepodporuje žádný mechanismus připojení úložiště objektů blob v deklarativním režimu.

Další informace o možnostech úložiště najdete v tématu Úložiště v AKS.

Monitorování aplikací a clusterů

Service Fabric i AKS poskytují nativní integraci se službou Azure Monitor a jejími službami, jako je Log Analytics. Monitorování a diagnostika jsou důležité pro vývoj, testování a nasazování úloh v jakémkoli cloudovém prostředí. Monitorování zahrnuje monitorování infrastruktury a aplikací.

Můžete například sledovat, jak se vaše aplikace používají, akce, které platforma Service Fabric přijímá, využití prostředků prostřednictvím čítačů výkonu a celkový stav clusteru. Tyto informace můžete použít k diagnostice a opravě problémů a zabránění jejich výskytu v budoucnu. Další informace najdete v tématu Monitorování a diagnostika pro Service Fabric. Když hostujete a provozujete kontejnerizované aplikace v clusteru Service Fabric, musíte nastavit řešení monitorování kontejnerů pro zobrazení událostí kontejneru a protokolů.

AKS má ale integrovanou integraci se službou Azure Monitor a Container Insights, která je navržená tak, aby monitorovala výkon kontejnerizovaných úloh nasazených do cloudu. Container Insights poskytuje přehled o výkonu shromažďováním metrik paměti a procesoru z kontrolerů, uzlů a kontejnerů dostupných v Kubernetes prostřednictvím rozhraní API metrik.

Po povolení monitorování z clusterů Kubernetes se metriky a protokoly kontejnerů automaticky shromažďují prostřednictvím kontejnerizované verze agenta Log Analytics pro Linux. Metriky se odesílají do databáze metrik ve službě Azure Monitor. Data protokolu se odesílají do pracovního prostoru služby Log Analytics. To vám umožní získat data monitorování a telemetrie pro cluster AKS i kontejnerizované aplikace, které na něm běží. Další informace najdete v tématu Monitorování AKS pomocí služby Azure Monitor.

Jako alternativní nebo doprovodné řešení container Insights můžete cluster AKS nakonfigurovat tak, aby shromažďovali metriky ve spravované službě Azure Monitor pro Prometheus. Tuto konfiguraci můžete použít ke shromažďování a analýze metrik ve velkém měřítku pomocí řešení pro monitorování kompatibilního s Prometheus, které je založené na projektu Prometheus . Plně spravovaná služba umožňuje použít dotazovací jazyk Prometheus (PromQL) k analýze výkonu monitorované infrastruktury a úloh. Umožňuje také přijímat výstrahy, aniž byste museli provozovat základní infrastrukturu.

Spravovaná služba Azure Monitor pro Prometheus je součástí metrik Azure Monitoru. Poskytuje větší flexibilitu v typech dat metrik, které můžete shromažďovat a analyzovat pomocí služby Azure Monitor. Metriky Prometheus sdílejí některé funkce s platformou a vlastními metrikami, ale mají další funkce pro lepší podporu opensourcových nástrojů, jako jsou PromQLa Grafana.

Spravovanou službu Azure Monitor pro Prometheus můžete nakonfigurovat jako zdroj dat pro Azure Managed Grafana i grafana v místním prostředí, která může běžet na virtuálním počítači Azure. Další informace najdete v tématu Použití spravované služby Azure Monitor pro Prometheus jako zdroje dat pro Grafana pomocí identity spravovaného systému.

Doplňky pro AKS

Při migraci z Service Fabric do AKS byste měli zvážit použití doplňků a rozšíření. AKS poskytuje pro vaše clustery další podporované funkce prostřednictvím doplňků a rozšíření, jako je automatické škálování řízené událostmi Kubernetes (KEDA) a Flux GitOps v2. S AKS se běžně používá mnoho dalších integrací poskytovaných opensourcovými projekty a třetími stranami. Zásady podpory AKS nepokrývají opensourcové integrace a integrace jiných společností než Microsoft. Další informace najdete v tématu Doplňky, rozšíření a další integrace s AKS.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky