Dela via

Migrera din arbetsbelastning från Service Fabric till AKS

  • Artikel

Många organisationer övergår till containerbaserade appar som en del av en satsning på att införa modern apputveckling, metodtips för underhåll och molnbaserade arkitekturer. Eftersom tekniken fortsätter att utvecklas måste organisationer utvärdera de många containerbaserade appplattformar som är tillgängliga i det offentliga molnet.

Det finns ingen lösning som passar alla för appar, men organisationer upptäcker ofta att Azure Kubernetes Service (AKS) uppfyller kraven för många av deras containerbaserade program. AKS är en hanterad Kubernetes-tjänst som förenklar programdistributioner via Kubernetes genom att hantera kontrollplanet för att tillhandahålla kärntjänster för programarbetsbelastningar. Många organisationer använder AKS som sin primära infrastrukturplattform och övergångsarbetsbelastningar som finns på andra plattformar till AKS.

Den här artikeln beskriver hur du migrerar containerbaserade appar från Azure Service Fabric till AKS. Artikeln förutsätter att du är bekant med Service Fabric men är intresserad av att lära dig hur dess funktioner och funktioner kan jämföras med FUNKTIONERNA i AKS. Artikeln innehåller även metodtips som du kan överväga under migreringen.

Jämföra AKS med Service Fabric

Börja genom att läsa Välj en Azure-beräkningstjänst tillsammans med andra Azure-beräkningstjänster. Det här avsnittet belyser viktiga likheter och skillnader som är relevanta för migreringen.

Både Service Fabric och AKS är containerorkestrerare. Service Fabric har stöd för flera programmeringsmodeller, men AKS stöder endast containrar.

  • Programmeringsmodeller: Service Fabric har stöd för flera sätt att skriva och hantera dina tjänster, inklusive Linux- och Windows-containrar, Reliable Services, Reliable Actors, ASP.NET Core och körbara gästprogram.

  • Containrar på AKS: AKS stöder endast containerisering med Windows- och Linux-containrar som körs på containerkörningscontainern, som hanteras automatiskt.

Både Service Fabric och AKS tillhandahåller integreringar med andra Azure-tjänster, inklusive Azure Pipelines, Azure Monitor, Azure Key Vault och Microsoft Entra ID.

Viktiga skillnader

När du distribuerar ett traditionellt Service Fabric-kluster, i stället för ett hanterat kluster, måste du uttryckligen definiera en klusterresurs tillsammans med många stödresurser i dina Azure Resource Manager-mallar (ARM-mallar) eller Bicep-moduler. Dessa resurser omfattar en VM-skalningsuppsättning för varje klusternodtyp, nätverkssäkerhetsgrupper och lastbalanserare. Det är ditt ansvar att se till att dessa resurser är korrekt konfigurerade. Inkapslingsmodellen för Service Fabric-hanterade kluster består däremot av en enda hanterad klusterresurs. Alla underliggande resurser för klustret abstraheras bort och hanteras av Azure.

AKS förenklar distributionen av ett hanterat Kubernetes-kluster i Azure genom att avlasta driftkostnaderna till Azure. Eftersom AKS är en värdbaserad Kubernetes-tjänst hanterar Azure viktiga uppgifter som övervakning och underhåll av infrastrukturhälsa. Azure hanterar Kubernetes-huvudnoderna, så du behöver bara hantera och underhålla agentnoderna.

Om du vill flytta din arbetsbelastning från Service Fabric till AKS måste du förstå skillnaderna i den underliggande infrastrukturen så att du säkert kan migrera dina containerbaserade program. I följande tabell jämförs funktionerna och funktionerna i de två värdplattformarna.

Kapacitet eller komponent Service Fabric AKS
Program som inte är containerbaserade Ja Nej
Linux- och Windows-containrar Ja Ja
Azure-hanterat kontrollplan Nej Ja
Stöd för både tillståndslösa och tillståndskänsliga arbetsbelastningar Ja Ja
Arbetsnodplacering Vm-skalningsuppsättningar, kund konfigurerade Vm-skalningsuppsättningar, Azure-hanterade
Konfigurationsmanifest XML YAML
Azure Monitor-integrering Ja Ja
Internt stöd för Reliable Services och Reliable Actor-mönster Ja Nej
WCF-baserad kommunikationsstack för Reliable Services Ja Nej
Beständig lagring Azure Files-volymdrivrutin Stöd för olika lagringssystem, till exempel hanterade diskar, Azure Files och Azure Blob Storage via CSI Storage-klasser, beständiga volymer och beständiga volymanspråk
Nätverkslägen Azure Virtual Network-integrering Stöd för flera plugin-program för nätverk (Azure CNI, kubenet, BYOCNI), nätverksprinciper (Azure, Calico) och ingresskontrollanter (Application Gateway Ingress Controller, NGINX med mera)
Ingresskontrollanter En omvänd proxy som är inbyggd i Service Fabric. Det hjälper mikrotjänster som körs i ett Service Fabric-kluster att identifiera och kommunicera med andra tjänster som har HTTP-slutpunkter. Du kan också använda Traefik på Service Fabric Hanterad NGINX-ingresskontrollant, BYO-ingress öppen källkod och kommersiella styrenheter som använder plattformshanterade offentliga eller interna lastbalanserare, till exempel NGINX-ingresskontrollant och Application Gateway-ingresskontrollant

Kommentar

Om du använder Windows-containrar i Service Fabric rekommenderar vi att du använder dem i AKS för att göra migreringen enklare.

Migreringssteg

I allmänhet är migreringsstegen från Service Fabric till AKS följande.

Diagram som visar migreringsstegen från Service Fabric till AKS.

  1. Upprätta distributionsarkitektur och skapa AKS-klustret. AKS innehåller olika alternativ för att konfigurera klusteråtkomst, skalbarhet för noder och poddar, nätverksåtkomst och konfiguration med mera. Mer information om en typisk distributionsarkitektur finns i Exempelarkitektur. AKS-baslinjearkitekturen innehåller även riktlinjer för klusterdistribution och övervakning. AKS-konstruktionen innehåller snabbstartsmallar för att distribuera ditt AKS-kluster baserat på affärs- och tekniska krav.

  2. Gör om Service Fabric-programmet. Om du använder programmeringsmodeller som Reliable Services eller Reliable Actors, eller om du använder andra Service Fabric-specifika konstruktioner, kan du behöva göra om programmet. Om du vill implementera tillståndshantering när du migrerar från Reliable Services använder du Dapr (Distributed Application Runtime). Kubernetes innehåller mönster och exempel för migrering från Reliable Actors.

  3. Paketera programmet som containrar. Visual Studio innehåller alternativ för att generera Dockerfile och paketera programmet som containrar. Skicka de containeravbildningar som du skapar till Azure Container Registry.

  4. Skriv om XML-filer för Service Fabric-konfiguration som Kubernetes YAML-filer. Du distribuerar programmet till AKS med YAML-filer eller som ett paket med hjälp av Helm-diagram. Mer information finns i Program- och tjänstmanifest.

  5. Distribuera programmet till AKS-klustret.

  6. Flytta trafik till AKS-klustret baserat på dina distributionsstrategier och övervaka programmets beteende, tillgänglighet och prestanda.

Exempelarkitektur

AKS och Azure ger flexibilitet att konfigurera din miljö så att den passar dina affärsbehov. AKS är väl integrerat med andra Azure-tjänster. AKS-baslinjearkitekturen är ett exempel.

Diagram som visar en AKS-baslinjearkitektur.

Som utgångspunkt kan du bekanta dig med några viktiga Kubernetes-begrepp och sedan granska några exempelarkitekturer:

Kommentar

När du migrerar en arbetsbelastning från Service Fabric till AKS kan du ersätta Service Fabric Reliable Actors med byggblocket Dapr Actors . Du kan ersätta Service Fabric Reliable Collections med Byggblocket för dapr-tillståndshantering.

Dapr tillhandahåller API:er som förenklar mikrotjänstanslutningen. Mer information finns i Introduktion till Dapr. Vi rekommenderar att du installerar Dapr som ett AKS-tillägg.

Program- och tjänstmanifest

Service Fabric och AKS har olika filtyper och konstruktioner för program- och tjänstmanifest. Service Fabric använder XML-filer för program- och tjänstdefinition. AKS använder Kubernetes YAML-filmanifestet för att definiera Kubernetes-objekt. Det finns inga verktyg som är särskilt avsedda att migrera en Service Fabric XML-fil till en Kubernetes YAML-fil. Du kan dock lära dig mer om hur YAML-filer fungerar på Kubernetes genom att granska följande resurser.

Du kan använda Helm för att definiera parametriserade YAML-manifest och skapa allmänna mallar genom att ersätta statiska, hårdkodade värden med platshållare som du kan ersätta med anpassade värden som anges vid distributionstillfället. De resulterande mallarna som innehåller de anpassade värdena återges som giltiga manifest för Kubernetes.

Kustomize introducerar ett mallfritt sätt att anpassa programkonfigurationen som förenklar användningen av färdiga program. Du kan använda Kustomize tillsammans med Helm eller som ett alternativ till Helm.

Mer information om Helm och Kustomize finns i följande resurser:

Nätverk

AKS innehåller två alternativ för det underliggande nätverket:

  • Ta med ditt eget virtuella Azure-nätverk för att etablera AKS-klusternoderna i ett undernät från ett virtuellt nätverk som du anger.

  • Låt AKS-resursprovidern skapa ett nytt virtuellt Azure-nätverk åt dig i nodresursgruppen som innehåller alla Azure-resurser som ett kluster använder.

Om du väljer det andra alternativet hanterar Azure det virtuella nätverket.

Service Fabric tillhandahåller inte något val av nätverks-plugin-program. Om du använder AKS måste du välja något av följande:

  • kubenet. Om du använder kubenet får noderna en IP-adress från det virtuella Azure-nätverkets undernät. Poddar får en IP-adress från ett adressutrymme som skiljer sig logiskt från det virtuella Azure-nätverksundernätet för noderna. NAT (Network Address Translation) konfigureras sedan så att poddarna kan komma åt resurser i Azure Virtual Network. Källans IP-adress för trafiken översätts via NAT till nodens primära IP-adress. Den här metoden minskar avsevärt antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar att använda.

  • Azure CNI. Om du använder CNI (Container Networking Interface) får varje podd en IP-adress från undernätet och kan nås direkt. Dessa IP-adresser måste vara unika i nätverket och måste planeras i förväg. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Sedan reserverar du motsvarande antal IP-adresser för varje nod. Den här metoden kräver mer planering och leder ofta till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programkraven ökar. Du kan konfigurera det maximala antalet poddar som kan distribueras till en nod när du skapar klustret eller när du skapar nya nodpooler.

  • Azure CNI Overlay-nätverk. Om du använder Azure CNI Overlay distribueras klusternoderna till ett Azure Virtual Network-undernät. Poddar tilldelas IP-adresser från en privat CIDR som skiljer sig logiskt från adressen för det virtuella nätverk som är värd för noderna. Podd- och nodtrafik i klustret använder ett överläggsnätverk. NAT använder nodens IP-adress för att nå resurser utanför klustret. Den här lösningen sparar ett stort antal IP-adresser för virtuella nätverk och hjälper dig att smidigt skala klustret till stora storlekar. En extra fördel är att du kan återanvända den privata CIDR i olika AKS-kluster, vilket utökar DET IP-utrymme som är tillgängligt för containerbaserade program i AKS.

  • Azure CNI drivs av Cilium. Azure CNI Powered by Cilium kombinerar det robusta kontrollplanet i Azure CNI med dataplanet i Cilium för att ge högpresterande nätverk och förbättrad säkerhet.

  • Ta med ditt eget CNI-plugin-program. Kubernetes tillhandahåller inte något nätverksgränssnittssystem som standard. Den här funktionen tillhandahålls av nätverks-plugin-program. AKS innehåller flera CNI-plugin-program som stöds. Mer information om plugin-program som stöds finns i Nätverksbegrepp för program i AKS.

Windows-containrar stöder för närvarande endast Azure CNI-plugin-programmet . Det finns olika alternativ för nätverksprinciper och ingresskontrollanter.

I AKS kan du använda Kubernetes-nätverksprinciper för att separera och skydda kommunikation inom tjänsten genom att kontrollera vilka komponenter som kan kommunicera med varandra. Som standard kan alla poddar i ett Kubernetes-kluster skicka och ta emot trafik utan begränsningar. För att förbättra säkerheten kan du använda Azure-nätverksprinciper eller Calico-nätverksprinciper för att definiera regler som styr trafikflödet mellan mikrotjänster.

Om du vill använda Azure Network Policy Manager måste du använda Azure CNI-plugin-programmet. Du kan använda Calico-nätverksprinciper med antingen Azure CNI-plugin-programmet eller kubenet CNI-plugin-programmet. Användning av Azure Network Policy Manager för Windows-noder stöds endast på Windows Server 2022. Mer information finns i Skydda trafik mellan poddar med hjälp av nätverksprinciper i AKS. Mer information om AKS-nätverk finns i Nätverk i AKS.

I Kubernetes fungerar en ingresskontrollant som en tjänstproxy och mellanhand mellan en tjänst och omvärlden, vilket ger extern trafik åtkomst till tjänsten. Tjänstproxyn tillhandahåller vanligtvis olika funktioner som TLS-avslutning, sökvägsbaserad routning av begäranden, belastningsutjämning och säkerhetsfunktioner som autentisering och auktorisering. Ingresskontrollanter ger också ytterligare ett lager abstraktion och kontroll för routning av extern trafik till Kubernetes-tjänster baserat på HTTP- och HTTPS-regler. Det här lagret ger mer detaljerad kontroll över trafikflödet och trafikhanteringen.

I AKS finns det flera alternativ för att distribuera, köra och använda en ingresskontrollant. Ett alternativ är Application Gateway-ingresskontrollanten, som gör att du kan använda Azure Application Gateway som ingresskontrollant för TLS-avslutning, sökvägsbaserad routning och som en brandvägg för webbåtkomst. Ett annat alternativ är den hanterade NGINX-ingresskontrollanten, som tillhandahåller det Azure-hanterade alternativet för den allmänt använda NGINX-ingresskontrollanten. Traefik-ingresskontrollant är en annan populär ingresskontrollant för Kubernetes.

Var och en av dessa ingresskontrollanter har styrkor och svagheter. Ta hänsyn till kraven för programmet och miljön för att avgöra vilken som ska användas. Se till att du använder den senaste versionen av Helm och har åtkomst till rätt Helm-lagringsplats när du installerar en ohanterad ingresskontrollant.

Beständig lagring

Både Service Fabric och AKS har mekanismer för att tillhandahålla beständig lagring till containerbaserade program. I Service Fabric tillhandahåller Azure Files-volymdrivrutinen, som är ett Plugin-program för Docker-volymer, Azure Files-volymer för Linux- och Windows-containrar. Det paketeras som ett Service Fabric-program som du kan distribuera till ett Service Fabric-kluster för att tillhandahålla volymer för andra Service Fabric-containerbaserade program i klustret. Mer information finns i Azure Files-volymdrivrutin för Service Fabric.

Program som körs i AKS kan behöva lagra och hämta data från ett beständigt fillagringssystem. AKS integreras med Azure Storage-tjänster som Azure-hanterade diskar, Azure Files, Blob Storage och Azure NetApp Storage (ANF). Den integreras också med andra lagringssystem än Microsoft, till exempel Rook - och GlusterFS-drivrutiner via CSI-drivrutiner (Container Storage Interface).

CSI är en standard för att exponera block- och fillagringssystem för containerbaserade arbetsbelastningar på Kubernetes. Icke-Microsoft-lagringsleverantörer som använder CSI kan skriva, distribuera och uppdatera plugin-program för att exponera nya lagringssystem i Kubernetes, eller förbättra befintliga, utan att behöva ändra kubernetes-kärnkoden och vänta på dess lanseringscykler.

Med stöd för CSI-lagringsdrivrutinen i AKS kan du använda dessa Azure Storage-tjänster internt:

  • Azure Disks. Du kan använda Azure Disks för att skapa en Kubernetes DataDisk-resurs. Diskar kan använda Azure Premium Storage som backas upp av högpresterande SSD:er eller Azure Standard Storage som backas upp av standard HDD eller SSD. För de flesta produktions- och utvecklingsarbetsbelastningar använder du Premium Storage. Azure-diskar monteras som ReadWriteOnce och är endast tillgängliga för en nod i AKS. För lagringsvolymer som flera poddar kan komma åt samtidigt använder du Azure Files.

    Service Fabric stöder däremot skapandet av ett kluster eller en nodtyp som använder hanterade diskar, men inte program som dynamiskt skapar anslutna hanterade diskar via en deklarativ metod. Mer information finns i Distribuera en Service Fabric-klusternodtyp med hanterade datadiskar.

  • Azure Files. Du kan använda Azure Files för att montera en SMB 3.0- eller 3.1-resurs som backas upp av ett Azure Storage-konto till poddar. Med Azure Files kan du dela data över flera noder och poddar. Azure Files kan använda Azure Standard Storage som backas upp av standard-HDD eller Azure Premium Storage som backas upp av högpresterande SSD:er.

    Service Fabric tillhandahåller en Azure Files-volymdrivrutin som ett Plugin-program för Docker-volymer som tillhandahåller Azure Files-volymer för Docker-containrar. Service Fabric tillhandahåller en version av drivrutinen för Windows-kluster och en för Linux-kluster.

  • Blob Storage. Du kan använda Blob Storage för att montera bloblagring (eller objektlagring) som ett filsystem i en container eller podd. Blob Storage gör det möjligt för ett AKS-kluster att stödja program som fungerar med stora ostrukturerade datamängder, till exempel loggfilsdata, bilder eller dokument och HPC-arbetsbelastningar. Om du matar in data i Azure Data Lake Storage kan du montera lagringen direkt och använda den i AKS utan att konfigurera ett annat interimfilsystem. Service Fabric har inte stöd för någon mekanism för montering av bloblagring i deklarativt läge.

Mer information om lagringsalternativ finns i Lagring i AKS.

Program- och klusterövervakning

Både Service Fabric och AKS tillhandahåller intern integrering med Azure Monitor och dess tjänster, till exempel Log Analytics. Övervakning och diagnostik är viktiga för att utveckla, testa och distribuera arbetsbelastningar i alla molnmiljöer. Övervakning omfattar infrastruktur- och programövervakning.

Du kan till exempel spåra hur dina program används, vilka åtgärder som Service Fabric-plattformen vidtar, resursanvändningen via prestandaräknare och klustrets övergripande hälsa. Du kan använda den här informationen för att diagnostisera och korrigera problem och förhindra att de inträffar i framtiden. Mer information finns i Övervakning och diagnostik för Service Fabric. När du är värd för och använder containerbaserade program i ett Service Fabric-kluster måste du konfigurera containerövervakningslösningen för att visa containerhändelser och loggar.

AKS har dock inbyggd integrering med Azure Monitor och Container Insights, som är utformad för att övervaka prestanda för containerbaserade arbetsbelastningar som distribueras till molnet. Container Insights ger prestandasynlighet genom att samla in minnes- och processormått från kontrollanter, noder och containrar som är tillgängliga i Kubernetes via Mått-API:et.

När du har aktiverat övervakning från Kubernetes-kluster samlas mått och containerloggar automatiskt in via en containerbaserad version av Log Analytics-agenten för Linux. Mått skickas till måttdatabasen i Azure Monitor. Loggdata skickas till din Log Analytics-arbetsyta. På så sätt kan du hämta övervaknings- och telemetridata för både AKS-klustret och de containerbaserade program som körs ovanpå det. Mer information finns i Övervaka AKS med Azure Monitor.

Som en alternativ eller kompletterande lösning för Container Insights kan du konfigurera DITT AKS-kluster för att samla in mått i Azure Monitor-hanterad tjänst för Prometheus. Du kan använda den här konfigurationen för att samla in och analysera mått i stor skala med hjälp av en Prometheus-kompatibel övervakningslösning som baseras på Prometheus-projektet . Med den fullständigt hanterade tjänsten kan du använda Prometheus-frågespråket (PromQL) för att analysera prestanda för övervakad infrastruktur och arbetsbelastningar. Du kan också ta emot aviseringar utan att behöva använda den underliggande infrastrukturen.

Azure Monitor managed service for Prometheus är en komponent i Azure Monitor Metrics. Det ger större flexibilitet i de typer av måttdata som du kan samla in och analysera med hjälp av Azure Monitor. Prometheus-mått delar vissa funktioner med plattforms- och anpassade mått, men de har extra funktioner för att bättre stödja verktyg med öppen källkod som PromQLoch Grafana.

Du kan konfigurera den hanterade Azure Monitor-tjänsten för Prometheus som en datakälla för både Azure Managed Grafana och lokalt installerad Grafana, som kan köras på en virtuell Azure-dator. Mer information finns i Använda Azure Monitor-hanterad tjänst för Prometheus som datakälla för Grafana med hjälp av hanterad systemidentitet.

Tillägg för AKS

När du migrerar från Service Fabric till AKS bör du överväga att använda tillägg och tillägg. AKS tillhandahåller extra funktioner som stöds för dina kluster via tillägg och tillägg som Kubernetes Händelsedriven autoskalning (KEDA) och GitOps Flux v2. Många fler integreringar som tillhandahålls av projekt med öppen källkod och tredje part används ofta med AKS. AKS-supportprincipen omfattar inte integreringar med öppen källkod och icke-Microsoft. Mer information finns i Tillägg, tillägg och andra integreringar med AKS.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg