Delen via

Uw workload migreren van Service Fabric naar AKS

  • Artikel

Veel organisaties gaan over naar apps in containers als onderdeel van een push naar moderne app-ontwikkeling, aanbevolen procedures voor onderhoud en cloudeigen architecturen. Omdat technologieën zich blijven ontwikkelen, moeten organisaties de vele platformen voor in containers geplaatste apps evalueren die beschikbaar zijn in de openbare cloud.

Er is geen oplossing die geschikt is voor alle apps, maar organisaties vinden vaak dat Azure Kubernetes Service (AKS) voldoet aan de vereisten voor veel van hun containertoepassingen. AKS is een beheerde Kubernetes-service die toepassingsimplementaties via Kubernetes vereenvoudigt door het besturingsvlak te beheren om kernservices voor toepassingsworkloads te bieden. Veel organisaties gebruiken AKS als hun primaire infrastructuurplatform en zetten workloads over die op andere platforms worden gehost naar AKS.

In dit artikel wordt beschreven hoe u container-apps migreert van Azure Service Fabric naar AKS. In het artikel wordt ervan uitgegaan dat u bekend bent met Service Fabric, maar wilt weten hoe de functies en functionaliteit zich verhouden tot die van AKS. Het artikel bevat ook aanbevolen procedures die u tijdens de migratie kunt overwegen.

AKS vergelijken met Service Fabric

Als u wilt beginnen, raadpleegt u Een Azure-rekenservice kiezen, naast andere Azure-rekenservices. In deze sectie worden opvallende overeenkomsten en verschillen gemarkeerd die relevant zijn voor migratie.

Zowel Service Fabric als AKS zijn containerorchestrators. Service Fabric biedt ondersteuning voor verschillende programmeermodellen, maar AKS ondersteunt alleen containers.

  • Programmeermodellen: Service Fabric ondersteunt meerdere manieren om uw services te schrijven en te beheren, waaronder Linux- en Windows-containers, Reliable Services, Reliable Actors, ASP.NET Core en uitvoerbare gastbestanden.

  • Containers op AKS: AKS biedt alleen ondersteuning voor containerisatie met Windows- en Linux-containers die worden uitgevoerd op de containerruntime die automatisch wordt beheerd.

Service Fabric en AKS bieden integraties met andere Azure-services, waaronder Azure Pipelines, Azure Monitor, Azure Key Vault en Microsoft Entra ID.

Belangrijke verschillen

Wanneer u een traditioneel Service Fabric-cluster implementeert in plaats van een beheerd cluster, moet u expliciet een clusterresource definiëren samen met veel ondersteunende resources in uw ARM-sjablonen (Azure Resource Manager-sjablonen) of Bicep-modules. Deze resources omvatten een virtuele-machineschaalset voor elk clusterknooppunttype, netwerkbeveiligingsgroepen en load balancers. Het is uw verantwoordelijkheid om ervoor te zorgen dat deze resources correct zijn geconfigureerd. Het inkapselingsmodel voor beheerde Service Fabric-clusters bestaat daarentegen uit één beheerde clusterresource. Alle onderliggende resources voor het cluster worden verwijderd en beheerd door Azure.

AKS vereenvoudigt de implementatie van een beheerd Kubernetes-cluster in Azure door de operationele overhead naar Azure te offloaden. Omdat AKS een gehoste Kubernetes-service is, verwerkt Azure kritieke taken, zoals statuscontrole en onderhoud van de infrastructuur. Azure beheert de Kubernetes-hoofdknooppunten, dus u hoeft alleen de agentknooppunten te beheren en te onderhouden.

Als u uw workload van Service Fabric naar AKS wilt verplaatsen, moet u de verschillen in de onderliggende infrastructuur begrijpen, zodat u uw containertoepassingen met vertrouwen kunt migreren. In de volgende tabel worden de mogelijkheden en functies van de twee hostingplatforms vergeleken.

Mogelijkheid of onderdeel Service Fabric AKS
Niet-containertoepassingen Ja Nr.
Linux- en Windows-containers Ja Ja
Door Azure beheerd besturingsvlak Nr. Ja
Ondersteuning voor staatloze en stateful workloads Ja Ja
Plaatsing van werkknooppunten Virtuele-machineschaalsets, klant geconfigureerd Virtuele-machineschaalsets, beheerd door Azure
Configuratiemanifest XML YAML
Azure Monitor-integratie Ja Ja
Systeemeigen ondersteuning voor Reliable Services en Reliable Actor-patroon Ja Nr.
Op WCF gebaseerde communicatiestack voor Reliable Services Ja Nr.
Permanente opslag Volumestuurprogramma voor Azure Files Ondersteuning voor verschillende opslagsystemen, zoals beheerde schijven, Azure Files en Azure Blob Storage via CSI-opslagklassen, permanent volume en permanente volumeclaims
Netwerkmodi Azure Virtual Network-integratie Ondersteuning voor meerdere netwerkinvoegtoepassingen (Azure CNI, kubenet, BYOCNI), netwerkbeleid (Azure, Calico) en toegangsbeheerobjectcontrollers (Controller voor inkomend verkeer van Application Gateway, NGINX en meer)
Toegangsbeheerobjectcontrollers Een omgekeerde proxy die is ingebouwd in Service Fabric. Het helpt microservices die worden uitgevoerd in een Service Fabric-cluster te detecteren en te communiceren met andere services met HTTP-eindpunten. U kunt Traefik ook gebruiken in Service Fabric Beheerde NGINX-ingangscontroller, BYO-toegangsbeheerobjectcontroller en commerciële controllers die gebruikmaken van door het platform beheerde openbare of interne load balancers, zoals NGINX-ingangscontroller en Application Gateway-ingangscontroller

Notitie

Als u Windows-containers in Service Fabric gebruikt, raden we u aan deze te gebruiken in AKS om uw migratie eenvoudiger te maken.

Migratiestappen

Over het algemeen zijn de migratiestappen van Service Fabric naar AKS als volgt.

Diagram met de migratiestappen van Service Fabric naar AKS.

  1. Stel de implementatiearchitectuur in en maak het AKS-cluster. AKS biedt verschillende opties voor het configureren van de clustertoegang, schaalbaarheid van knooppunten en pods, netwerktoegang en configuratie, en meer. Zie Voorbeeldarchitectuur voor meer informatie over een typische implementatiearchitectuur. De AKS-basislijnarchitectuur biedt ook richtlijnen voor clusterimplementatie en bewaking. AKS-constructie biedt quickstartsjablonen voor het implementeren van uw AKS-cluster op basis van zakelijke en technische vereisten.

  2. De Service Fabric-toepassing opnieuw ontwerpen. Als u programmeermodellen zoals Reliable Services of Reliable Actors gebruikt of als u andere specifieke Service Fabric-constructies gebruikt, moet u mogelijk uw toepassing opnieuw ontwerpen. Gebruik Distributed Application Runtime (Dapr) om statusbeheer te implementeren wanneer u migreert vanuit Reliable Services. Kubernetes biedt patronen en voorbeelden voor het migreren van Reliable Actors.

  3. Verpak de toepassing als containers. Visual Studio biedt opties voor het genereren van het Dockerfile en het verpakken van de toepassing als containers. Push de containerinstallatiekopieën die u maakt naar Azure Container Registry.

  4. Herschrijf XML-bestanden van de Service Fabric-configuratie als Kubernetes YAML-bestanden. U implementeert de toepassing in AKS met behulp van YAML-bestanden of als een pakket met behulp van Helm-grafieken. Zie toepassings- en servicemanifest voor meer informatie.

  5. Implementeer de toepassing in het AKS-cluster.

  6. Verplaats verkeer naar het AKS-cluster op basis van uw implementatiestrategieën en bewaak het gedrag, de beschikbaarheid en prestaties van de toepassing.

Voorbeeldarchitectuur

AKS en Azure bieden flexibiliteit voor het configureren van uw omgeving aan uw bedrijfsbehoeften. AKS is goed geïntegreerd met andere Azure-services. De AKS-basislijnarchitectuur is een voorbeeld.

Diagram met een AKS-basislijnarchitectuur.

Als uitgangspunt moet u vertrouwd raken met enkele belangrijke Kubernetes-concepten en vervolgens enkele voorbeeldarchitecturen bekijken:

Notitie

Wanneer u een workload migreert van Service Fabric naar AKS, kunt u Service Fabric Reliable Actors vervangen door de bouwstenen van Dapr-actoren. U kunt Betrouwbare Service Fabric-verzamelingen vervangen door de bouwsteen dapr-statusbeheer.

Dapr biedt API's waarmee de microserviceconnectiviteit wordt vereenvoudigd. Zie Inleiding tot Dapr voor meer informatie. U wordt aangeraden Dapr te installeren als een AKS-extensie.

Toepassings- en servicemanifest

Service Fabric en AKS hebben verschillende bestandstypen voor toepassings- en servicemanifesten en -constructies. Service Fabric maakt gebruik van XML-bestanden voor toepassings- en servicedefinities. AKS maakt gebruik van het Kubernetes YAML-bestandsmanifest om Kubernetes-objecten te definiëren. Er zijn geen hulpprogramma's die specifiek zijn bedoeld voor het migreren van een Service Fabric XML-bestand naar een Kubernetes YAML-bestand. U kunt echter leren hoe YAML-bestanden werken in Kubernetes door de volgende resources te bekijken.

U kunt Helm gebruiken om geparameteriseerde YAML-manifesten te definiëren en algemene sjablonen te maken door statische, vastgelegde waarden te vervangen door tijdelijke aanduidingen die u kunt vervangen door aangepaste waarden die tijdens de implementatie worden opgegeven. De resulterende sjablonen die de aangepaste waarden bevatten, worden weergegeven als geldige manifesten voor Kubernetes.

Kustomize introduceert een sjabloonvrije manier om toepassingsconfiguratie aan te passen die het gebruik van kant-en-klare toepassingen vereenvoudigt. U kunt Kustomize samen met Helm gebruiken of als alternatief voor Helm.

Zie de volgende bronnen voor meer informatie over Helm en Kustomize:

Netwerken

AKS biedt twee opties voor het onderliggende netwerk:

  • Bring your own Azure virtual network to provision the AKS cluster nodes into a subnet from a virtual network that you provide.

  • Laat de AKS-resourceprovider een nieuw virtueel Azure-netwerk voor u maken in de knooppuntresourcegroep die alle Azure-resources bevat die door een cluster worden gebruikt.

Als u de tweede optie kiest, beheert Azure het virtuele netwerk.

Service Fabric biedt geen keuze uit netwerkinvoegtoepassingen. Als u AKS gebruikt, moet u een van de volgende opties kiezen:

  • kubenet. Als u kubenet gebruikt, krijgen knooppunten een IP-adres van het subnet van het virtuele Azure-netwerk. Pods ontvangen een IP-adres van een adresruimte die logisch verschilt van die van het subnet van het virtuele Azure-netwerk van de knooppunten. NAT (Network Address Translation) wordt vervolgens zo geconfigureerd dat de pods resources kunnen bereiken in het virtuele Azure-netwerk. Het bron-IP-adres van het verkeer wordt omgezet via NAT naar het primaire IP-adres van het knooppunt. Deze aanpak vermindert het aantal IP-adressen dat u in uw netwerkruimte moet reserveren om pods te kunnen gebruiken.

  • Azure CNI. Als u CNI (Container Networking Interface) gebruikt, krijgt elke pod een IP-adres van het subnet en kan deze rechtstreeks worden geopend. Deze IP-adressen moeten uniek zijn binnen uw netwerkruimte en moeten van tevoren worden gepland. Elk knooppunt heeft een configuratieparameter voor het maximum aantal pods dat wordt ondersteund. Vervolgens reserveert u het equivalente aantal IP-adressen voor elk knooppunt. Deze aanpak vereist meer planning en leidt vaak tot uitputting van IP-adressen of tot de noodzaak om clusters in een groter subnet opnieuw samen te stellen naarmate de vraag naar uw toepassing toeneemt. U kunt het maximum aantal pods configureren dat kan worden geïmplementeerd op een knooppunt wanneer u het cluster maakt of wanneer u nieuwe knooppuntgroepen maakt.

  • Azure CNI Overlay-netwerken. Als u Azure CNI-overlay gebruikt, worden de clusterknooppunten geïmplementeerd in een Azure Virtual Network-subnet. Pods worden toegewezen IP-adressen van een privé-CIDR die logisch afwijken van het adres van het virtuele netwerk dat als host fungeert voor de knooppunten. Pod- en knooppuntverkeer binnen het cluster maakt gebruik van een overlaynetwerk. NAT gebruikt het IP-adres van het knooppunt om resources buiten het cluster te bereiken. Met deze oplossing wordt een aanzienlijk aantal IP-adressen van virtuele netwerken opgeslagen en kunt u uw cluster naadloos schalen naar grote grootten. Een extra voordeel is dat u de privé-CIDR opnieuw kunt gebruiken in verschillende AKS-clusters, waardoor de IP-ruimte die beschikbaar is voor toepassingen in containers in AKS, wordt uitgebreid.

  • Azure CNI Powered by Cilium. Azure CNI Powered by Cilium combineert het robuuste besturingsvlak van Azure CNI met het gegevensvlak van Cilium om netwerken met hoge prestaties en verbeterde beveiliging te bieden.

  • Neem uw eigen CNI-invoegtoepassing mee. Kubernetes biedt standaard geen netwerkinterfacesysteem. Deze functionaliteit wordt geleverd door netwerkinvoegtoepassingen. AKS biedt verschillende ondersteunde CNI-invoegtoepassingen. Zie Netwerkconcepten voor toepassingen in AKS voor meer informatie over ondersteunde invoegtoepassingen.

Windows-containers ondersteunen momenteel alleen de Azure CNI-invoegtoepassing . Er zijn verschillende opties beschikbaar voor netwerkbeleid en toegangsbeheerobjectcontrollers.

In AKS kunt u Kubernetes-netwerkbeleid gebruiken om communicatie tussen services te scheiden en te beveiligen door te bepalen welke onderdelen met elkaar kunnen communiceren. Standaard kunnen alle pods in een Kubernetes-cluster zonder beperkingen verkeer verzenden en ontvangen. Om de beveiliging te verbeteren, kunt u Azure-netwerkbeleid of Calico-netwerkbeleid gebruiken om regels te definiëren waarmee de verkeersstroom tussen microservices wordt beheerd.

Als u Azure Network Policy Manager wilt gebruiken, moet u de Azure CNI-invoegtoepassing gebruiken. U kunt Calico-netwerkbeleid gebruiken met de Azure CNI-invoegtoepassing of de kubenet CNI-invoegtoepassing. Het gebruik van Azure Network Policy Manager voor Windows-knooppunten wordt alleen ondersteund in Windows Server 2022. Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS voor meer informatie. Zie Netwerken in AKS voor meer informatie over AKS-netwerken.

In Kubernetes fungeert een toegangsbeheerobjectcontroller als een serviceproxy en tussenliggende tussen een service en de buitenwereld, waardoor extern verkeer toegang heeft tot de service. De serviceproxy biedt doorgaans verschillende functies zoals TLS-beëindiging, padgebaseerde aanvraagroutering, taakverdeling en beveiligingsfuncties zoals verificatie en autorisatie. Toegangsbeheerobjectcontrollers bieden ook een andere abstractielaag en controle voor het routeren van extern verkeer naar Kubernetes-services op basis van HTTP- en HTTPS-regels. Deze laag biedt meer verfijnde controle over verkeersstroom en verkeersbeheer.

In AKS zijn er meerdere opties om een ingangscontroller te implementeren, uit te voeren en te gebruiken. Eén optie is de controller voor inkomend verkeer van Application Gateway, waarmee u Azure-toepassing Gateway kunt gebruiken als ingangscontroller voor TLS-beëindiging, padgebaseerde routering en als een firewall voor webtoegang. Een andere optie is de beheerde NGINX-ingangscontroller, die de door Azure beheerde optie biedt voor de veelgebruikte NGINX-ingangscontroller. De controller voor inkomend verkeer van Traefik is een andere populaire ingangscontroller voor Kubernetes.

Elk van deze ingangscontrollers heeft sterke en zwakke punten. Als u wilt bepalen welke toepassing moet worden gebruikt, moet u rekening houden met de vereisten van de toepassing en de omgeving. Zorg ervoor dat u de nieuwste versie van Helm gebruikt en toegang hebt tot de juiste Helm-opslagplaats wanneer u een niet-beheerde toegangscontroller installeert.

Permanente opslag

Zowel Service Fabric als AKS hebben mechanismen om permanente opslag te bieden aan toepassingen in containers. In Service Fabric biedt het Azure Files-volumestuurprogramma, een Docker-volumeinvoegtoepassing, Azure Files-volumes voor Linux- en Windows-containers. Het is verpakt als een Service Fabric-toepassing die u in een Service Fabric-cluster kunt implementeren om volumes te bieden voor andere Service Fabric-toepassingen in containers binnen het cluster. Zie het Volumestuurprogramma van Azure Files voor Service Fabric voor meer informatie.

Toepassingen die in AKS worden uitgevoerd, moeten mogelijk gegevens opslaan en ophalen uit een permanent bestandssysteem. AKS kan worden geïntegreerd met Azure Storage-services zoals azure managed disks, Azure Files, Blob Storage en Azure NetApp Storage (ANF). Het kan ook worden geïntegreerd met niet-Microsoft-opslagsystemen zoals Rook en GlusterFS via CSI-stuurprogramma's (Container Storage Interface).

CSI is een standaard voor het beschikbaar maken van blok- en bestandsopslagsystemen voor workloads in containers in Kubernetes. Niet-Microsoft-opslagproviders die gebruikmaken van CSI kunnen invoegtoepassingen schrijven, implementeren en bijwerken om nieuwe opslagsystemen beschikbaar te maken in Kubernetes of om bestaande systemen te verbeteren, zonder dat u de kerncode van Kubernetes hoeft te wijzigen en te wachten op de releasecycli.

Met de ondersteuning voor CSI-opslagstuurprogramma's in AKS kunt u deze Azure Storage-services systeemeigen gebruiken:

  • Azure Disks. U kunt Azure Disks gebruiken om een Kubernetes DataDisk-resource te maken. Schijven kunnen Gebruikmaken van Azure Premium-opslag die wordt ondersteund door SSD's met hoge prestaties of Azure Standard-opslag die wordt ondersteund door standard-HDD's of SSD's. Gebruik Premium Storage voor de meeste productie- en ontwikkelingsworkloads. Azure Disks worden gekoppeld als ReadWriteOnce en zijn alleen beschikbaar voor één knooppunt in AKS. Gebruik Azure Files voor opslagvolumes waartoe meerdere pods gelijktijdig toegang hebben.

    Service Fabric ondersteunt daarentegen het maken van een cluster of een knooppunttype dat gebruikmaakt van beheerde schijven, maar niet toepassingen die dynamisch gekoppelde beheerde schijven maken via een declaratieve benadering. Zie Een Service Fabric-clusterknooppunttype implementeren met beheerde gegevensschijven voor meer informatie.

  • Azure Files. U kunt Azure Files gebruiken om een SMB 3.0- of 3.1-share te koppelen die wordt ondersteund door een Azure-opslagaccount aan pods. Met Azure Files kunt u gegevens delen over meerdere knooppunten en pods. Azure Files kan gebruikmaken van Azure Standard Storage die wordt ondersteund door standard-HDD's of Azure Premium-opslag die wordt ondersteund door krachtige SSD's.

    Service Fabric biedt een Azure Files-volumestuurprogramma als een Docker-volumeinvoegtoepassing die Azure Files-volumes biedt voor Docker-containers. Service Fabric biedt één versie van het stuurprogramma voor Windows-clusters en één voor Linux-clusters.

  • Blob Storage. U kunt Blob Storage gebruiken om blobopslag (of objectopslag) als bestandssysteem te koppelen aan een container of pod. Met Blob Storage kan een AKS-cluster toepassingen ondersteunen die werken met grote ongestructureerde gegevenssets, zoals logboekbestandsgegevens, afbeeldingen of documenten en HPC-workloads. Als u gegevens opneemt in Azure Data Lake Storage, kunt u de opslag rechtstreeks koppelen en gebruiken in AKS zonder een ander tussentijds bestandssysteem te configureren. Service Fabric biedt geen ondersteuning voor het koppelen van blobopslag in de declaratieve modus.

Zie Storage in AKS voor meer informatie over opslagopties.

Toepassings- en clusterbewaking

Zowel Service Fabric als AKS bieden systeemeigen integratie met Azure Monitor en de bijbehorende services, zoals Log Analytics. Bewaking en diagnose zijn essentieel voor het ontwikkelen, testen en implementeren van workloads in elke cloudomgeving. Bewaking omvat infrastructuur- en toepassingsbewaking.

U kunt bijvoorbeeld bijhouden hoe uw toepassingen worden gebruikt, de acties die het Service Fabric-platform uitvoert, uw resourcegebruik via prestatiemeteritems en de algehele status van uw cluster. U kunt deze informatie gebruiken om problemen vast te stellen en op te lossen en deze in de toekomst te voorkomen. Zie Bewaking en diagnose voor Service Fabric voor meer informatie. Wanneer u containertoepassingen in een Service Fabric-cluster host en gebruikt, moet u de containerbewakingsoplossing instellen om containergebeurtenissen en logboeken weer te geven.

AKS heeft echter ingebouwde integratie met Azure Monitor en Container Insights, die is ontworpen voor het bewaken van de prestaties van in containers geïmplementeerde workloads in de cloud. Container Insights biedt inzicht in de prestaties door metrische geheugen- en processorgegevens te verzamelen van controllers, knooppunten en containers die beschikbaar zijn in Kubernetes via de Metrics-API.

Nadat u bewaking vanuit Kubernetes-clusters hebt ingeschakeld, worden metrische gegevens en containerlogboeken automatisch verzameld via een containerversie van de Log Analytics-agent voor Linux. Metrische gegevens worden verzonden naar de database met metrische gegevens in Azure Monitor. Logboekgegevens worden verzonden naar uw Log Analytics-werkruimte. Hiermee kunt u bewakings- en telemetriegegevens ophalen voor zowel het AKS-cluster als de toepassingen in containers die erop worden uitgevoerd. Zie AKS bewaken met Azure Monitor voor meer informatie.

Als alternatieve of aanvullende oplossing voor Container Insights kunt u uw AKS-cluster configureren voor het verzamelen van metrische gegevens in de beheerde Azure Monitor-service voor Prometheus. U kunt deze configuratie gebruiken om metrische gegevens op schaal te verzamelen en te analyseren met behulp van een met Prometheus compatibele bewakingsoplossing, die is gebaseerd op het Prometheus-project . Met de volledig beheerde service kunt u de Prometheus-querytaal (PromQL) gebruiken om de prestaties van bewaakte infrastructuur en workloads te analyseren. Hiermee kunt u ook waarschuwingen ontvangen zonder dat u de onderliggende infrastructuur hoeft te gebruiken.

De beheerde Azure Monitor-service voor Prometheus is een onderdeel van metrische gegevens van Azure Monitor. Het biedt meer flexibiliteit in de typen metrische gegevens die u kunt verzamelen en analyseren met behulp van Azure Monitor. Metrische prometheus-gegevens delen enkele functies met platform- en aangepaste metrische gegevens, maar ze hebben extra functies om opensource-hulpprogramma's zoals PromQLen Grafana beter te ondersteunen.

U kunt de beheerde Azure Monitor-service voor Prometheus configureren als gegevensbron voor zowel Azure Managed Grafana als zelf-hostende Grafana, die kan worden uitgevoerd op een virtuele Azure-machine. Zie Azure Monitor Managed Service voor Prometheus gebruiken als gegevensbron voor Grafana met behulp van een beheerde systeemidentiteit voor meer informatie.

Invoegtoepassingen voor AKS

Wanneer u migreert van Service Fabric naar AKS, kunt u overwegen om invoegtoepassingen en extensies te gebruiken. AKS biedt extra ondersteunde functionaliteit voor uw clusters via invoegtoepassingen en extensies zoals Kubernetes Event-driven Autoscaling (KEDA) en GitOps Flux v2. Veel meer integraties die worden geleverd door opensource-projecten en derden worden vaak gebruikt met AKS. Het AKS-ondersteuningsbeleid heeft geen betrekking op opensource- en niet-Microsoft-integraties. Zie Invoegtoepassingen, extensies en andere integraties met AKS voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen