Azure Spring Apps migreren naar Azure Kubernetes Service
Notitie
De Basic-, Standard- en Enterprise-abonnementen worden afgeschaft vanaf medio maart 2025, met een pensioenperiode van 3 jaar. We raden u aan om over te stappen naar Azure Container Apps. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.
Het standaardverbruik en het speciale abonnement worden vanaf 30 september 2024 afgeschaft, met een volledige afsluiting na zes maanden. We raden u aan om over te stappen naar Azure Container Apps. Zie Azure Spring Apps Standard-verbruik en toegewezen abonnement migreren naar Azure Container Apps voor meer informatie.
Dit artikel is van toepassing op:✅ Basic/Standard ✅ Enterprise
Dit artikel bevat een overzicht van het migreren van Azure Spring Apps naar Azure Kubernetes Service (AKS).
Azure Spring Apps is een PaaS-oplossing (Platform as a Service) die speciaal is ontworpen voor Spring Boot-toepassingen. Het maakt het implementeren, uitvoeren en beheren van deze toepassingen eenvoudiger. Azure Spring Apps zorgt voor infrastructuur, schaalaanpassing en bewaking, zodat ontwikkelaars zich kunnen richten op hun code.
AKS is een IaaS-aanbieding (Infrastructure-as-a-Service) die een volledig beheerde Kubernetes-omgeving biedt. AKS geeft u meer controle over hoe uw toepassingen worden geïmplementeerd en beheerd. Het biedt ondersteuning voor een breed scala aan toepassingen in containers en maakt aanpassing mogelijk om te voldoen aan specifieke behoeften.
Het migreren van toepassingen van Azure Spring Apps naar AKS betekent dat u overstapt van een beheerde omgeving naar een omgeving die u meer flexibiliteit biedt. Voor dit proces moeten nieuwe hulpprogramma's en procedures worden gebruikt om dezelfde resultaten op AKS te bereiken als bij Azure Spring Apps.
Concepttoewijzing
Omdat Azure Spring Apps en AKS verschillende typen cloudserviceaanbiedingen zijn, is het niet helemaal nauwkeurig om Azure Spring Apps-concepten rechtstreeks toe te wijzen aan AKS. Azure Spring Apps is ook afhankelijk van veel interne onderdelen wanneer ze worden gebruikt in productieomgevingen, die hier niet worden vermeld. Het volgende diagram en de volgende tabel bieden een eenvoudige toewijzing van concepten van Azure Spring Apps aan AKS, zodat u inzicht krijgt in de basisbeginselen. In een echte productieomgeving moet u overwegen om veiligere en betrouwbare oplossingen te overwegen.
| Azure Spring Apps-service | Azure Kubernetes Service |
|---|---|
| Een service-exemplaar host en beveiligt een grens voor apps en andere resources en ondersteunt een aangepast virtueel netwerk. | Een cluster is de basiseenheid van de implementatie. Binnen een cluster is een naamruimte een virtuele onderverdeling die wordt gebruikt om resources te organiseren en te isoleren. Het deelt dezelfde onderliggende netwerkinfrastructuur die is gedefinieerd door het virtuele netwerk van het cluster. Het kiezen tussen een toegewezen cluster of een gedeeld cluster met naamruimten is afhankelijk van de behoeften van uw bedrijf. |
| Een app is een zakelijke app die fungeert als een onderliggende resource binnen een service-exemplaar. | Een zakelijke app is een virtueel concept in Azure Spring Apps en bestaat uit meerdere resources in AKS. Inkomend verkeer beheert externe toegang tot services en stelt regels in voor het routeren van verkeer naar verschillende services. Een service abstraheert de toegang tot een set pods. U kunt een blauwgroene implementatieswitch uitvoeren door een service bij te werken zodat deze verwijst naar een andere versie van een implementatie met behulp van labels. |
| Een implementatie is de versie van een app. Een app kan één productie-implementatie en één faseringsimplementatie hebben. | Een implementatie beheert de implementatie en levenscyclus van een specifieke toepassing of service. Het maakt ook rolling updates en terugdraaiacties mogelijk, waardoor gecontroleerde, naadloze toepassingswijzigingen zonder downtime mogelijk zijn. |
| Een toepassingsexemplaren zijn de minimale runtime-eenheid die wordt beheerd door de service. | Een pod vertegenwoordigt een of meer nauw gekoppelde containers en host één exemplaar van een actieve toepassing of workload. |
Overwegingen voor het netwerk
Voordat u een AKS-cluster inricht, is het belangrijk dat u zorgvuldig rekening houdt met de netwerkinstellingen. Deze beslissingen kunnen van invloed zijn op de prestaties, schaalbaarheid en beveiliging van uw toepassingen.
AKS is afhankelijk van CNI-invoegtoepassingen (Container Networking Interface) om netwerken binnen de clusters te beheren. Deze invoegtoepassingen verwerken kritieke taken, zoals het toewijzen van IP-adressen aan pods, het routeren van verkeer ertussen en het inschakelen van communicatie via Kubernetes Services. AKS ondersteunt meerdere CNI-invoegtoepassingen die zijn afgestemd op verschillende netwerkbehoeften en bieden flexibiliteit in clusterontwerp.
AKS biedt twee primaire netwerkmodellen: overlaynetwerken en platte netwerken. Overlay-netwerken wijzen privé-IP-adressen toe aan pods, gescheiden van het subnet van het virtuele Azure-netwerk van de AKS-knooppunten. Dit model is schaalbaar en bespaart IP-adressen van virtuele netwerken, maar maakt gebruik van NAT (Network Address Translation) voor verkeer dat het cluster verlaat. Platte netwerken wijzen daarentegen IP-adressen van pods rechtstreeks toe vanuit hetzelfde Subnet van azure Virtual Network als de knooppunten, waardoor externe services toegang hebben tot pods zonder NAT. Hoewel platte netwerken directe podcommunicatie mogelijk maken, vereisen ze uitgebreidere IP-adresruimte voor virtuele netwerken.
De juiste IP-planning is essentieel voor een soepele AKS-bewerking. Het is belangrijk om ervoor te zorgen dat subnetten voldoende IP-adressen hebben voor alle resources, overlappende bereiken voorkomen en ruimte laten voor toekomstige groei om verbindingsproblemen en onderbrekingen te voorkomen. Zie het overzicht van azure Kubernetes Service CNI-netwerken voor meer informatie.
Als u inkomend verkeer in AKS wilt verwerken, kunt u load balancers of ingangscontrollers gebruiken. Load balancers werken op Laag 4, distribueren verkeer op basis van protocollen en poorten, terwijl toegangsbeheerobjectcontrollers op Laag 7 werken, met geavanceerde functies zoals routering op basis van URL's en TLS/SSL-beëindiging. Toegangsbeheerobjectcontrollers verminderen de noodzaak voor meerdere openbare IP-adressen door verkeer naar meerdere toepassingen via één IP te beheren. Voor webtoepassingen hebben toegangsbeheercontrollers de voorkeur omdat ze betere verkeersbeheer en integratie met Kubernetes-resources bieden. Zie Beheerde NGINX-ingangen met de invoegtoepassing voor toepassingsroutering voor meer informatie.
Als u netwerkverkeer in AKS wilt beveiligen, gebruikt u Web Application Firewalls (WAF) zoals Azure-toepassing Gateway om te beschermen tegen aanvallen zoals scripts op meerdere sites en cookievergiftiging, terwijl u verkeersroutering en TLS/SSL-beëindiging beheert. Implementeer bovendien netwerkbeleid voor het beheren van pod-naar-pod-communicatie door regels te definiëren in YAML-manifesten, op basis van labels, naamruimten of poorten. Deze beleidsregels, die alleen beschikbaar zijn voor Linux-knooppunten, zorgen voor betere verkeersbeheer en -beveiliging binnen het cluster. Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS voor meer informatie.
inrichten
Als u een AKS-cluster wilt inrichten, kunt u Azure Portal, De Azure CLI of ARM-sjablonen gebruiken. Het proces omvat meestal het selecteren van de gewenste regio, het definiëren van de grootte en het type van de knooppuntgroep, en het kiezen van het netwerkmodel: Azure CNI of Kubenet. U moet ook verificatieopties configureren, zoals Microsoft Entra ID-integratie voor gebruikerstoegangsbeheer. Voor bewaking en schaalaanpassing kunt u Azure Monitor inschakelen en automatisch schalen configureren op basis van resourcegebruik. Na het inrichten kunt u het cluster beheren met behulp van kubectl of de Azure CLI. Ga naar Een AKS-cluster maken voor gedetailleerde instructies over het inrichten van AKS.
Toegang en identiteit
AKS biedt verschillende manieren om verificatie, autorisatie en toegangsbeheer voor Kubernetes-clusters te beheren. U kunt op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes gebruiken om gebruikers, groepen en serviceaccounts alleen toegang te geven tot de resources die ze nodig hebben. Zie RBAC-autorisatie gebruiken voor meer informatie. AKS biedt ook ondersteuning voor Microsoft Entra ID en Azure RBAC om de beveiliging en controle te verbeteren, zodat u machtigingen op een meer gestroomlijnde manier kunt toewijzen en beheren.
Voor de beste beveiliging raden we u aan AKS te integreren met Microsoft Entra ID. Deze integratie maakt gebruik van OpenID Connect- en OAuth 2.0-protocollen voor verificatie. Gebruikers verifiëren met behulp van Microsoft Entra-referenties bij interactie met het AKS-cluster, met hun toegangsmachtigingen die worden beheerd door de clusterbeheerder. Zie Azure Managed Identity Authentication inschakelen voor Kubernetes-clusters met kubelogin voor meer informatie
Microsoft Entra Workload-ID integreert systeemeigen functies van Kubernetes met externe id-providers via OpenID Connect (OIDC)-federatie. Het maakt gebruik van volumeprojectie van serviceaccounttoken om Kubernetes-identiteiten toe te wijzen aan pods via geannoteerde serviceaccounts. Met deze tokens kunnen Kubernetes-toepassingen Azure-resources veilig verifiëren en openen met behulp van Microsoft Entra-id. Deze installatie werkt naadloos samen met bibliotheken zoals Azure Identity-clientbibliotheken (Azure.Identity) of de Microsoft Authentication Library (MSAL) om de verificatie voor uw workloads te stroomlijnen. Zie Workloadidentiteit implementeren en configureren voor meer informatie over het instellen van een cluster en het configureren van uw toepassingspod met workloads identificeren.
Toepassingen containeriseren
Het containeriseren van toepassingen in containerinstallatiekopieën is essentieel voor implementatie op AKS. Het zorgt ervoor dat implementaties consistent, draagbaar en schaalbaar zijn. Het gebruik van containerinstallatiekopieën biedt flexibiliteit bij het beheren van verschillende versies van toepassingen. Het maakt updates en terugdraaien eenvoudiger en verbetert de efficiëntie van resources doordat meerdere containers op één host kunnen worden uitgevoerd.
Met Azure Spring Apps kunnen gebruikers containerinstallatiekopieën maken en toepassingen op verschillende manieren implementeren. U kunt implementeren vanuit broncode, van ingebouwde artefacten zoals JAR- of WAR-bestanden, of rechtstreeks vanuit een containerinstallatiekopie. Zie Een containerinstallatiekopieën bouwen vanuit een JAR- of WAR-bestand voor meer informatie over het implementeren vanuit een JAR- of WAR-bestand. Zie Containerize an application by using Paketo Buildpacks (Paketo Buildpacks) voor meer informatie over het implementeren vanuit broncode.
Als u de prestaties van toepassingen wilt bewaken die zijn geïmplementeerd op AKS, kunt u de APM-agent (Application Performance Monitoring) integreren tijdens het containerisatieproces. Zie Bewaking van toepassingsprestaties integreren in containerinstallatiekopieën voor meer informatie.
Toepassingen en Spring Cloud-onderdelen implementeren
Als u toepassingen wilt implementeren in AKS, kunt u implementaties gebruiken, die worden gebruikt door Azure Spring Apps of StatefulSets, afhankelijk van de behoeften van uw toepassing. Voor staatloze toepassingen, zoals microservices, gebruikt u doorgaans een implementatie, waarmee replica's van uw toepassing worden beheerd en ervoor zorgt dat ze probleemloos worden uitgevoerd. Dit type wordt gebruikt door Azure Spring Apps. StatefulSets zijn echter ideaal voor toepassingen die permanente opslag of stabiele identiteiten vereisen, zoals databases of services met stateful behoeften.
Naast de implementatie van de toepassing moet u ook een service definiëren om uw back-endpods beschikbaar te maken. Een service is een abstractie waarmee u een logische set pods kunt definiëren en netwerktoegang tot deze pods kunt inschakelen. Deze mogelijkheid is van cruciaal belang voor taakverdeling en communicatie tussen pods.
Bij het implementeren van Spring Cloud-onderdelen, zoals Spring Cloud-configuratie of Spring Cloud Gateway, gebruikt u over het algemeen implementaties voor staatloze services. Voor back-endservices die stabiele opslag of status nodig hebben, kunt u StatefulSets kiezen.
De volgende koppelingen bevatten referentievoorbeelden van containerinstallatiekopieën en manifestbestanden voor Spring Cloud Components:
Monitor
Bewaking is een cruciaal onderdeel van het beheren van toepassingen die zijn geïmplementeerd op AKS. AKS biedt verschillende hulpprogramma's voor het bijhouden en analyseren van de status van uw cluster en workloads, waaronder geïntegreerde oplossingen zoals Azure Monitor, Azure Log Analytics en Prometheus. Raadpleeg voor meer informatie de volgende artikelen:
- Beheerde Prometheus voor het verzamelen van metrische gegevens.
- Container insights voor logboekverzameling
- Azure Managed Grafana voor visualisatie.
Naast Azure Monitor en Prometheus kunt u ook andere bewakingsoplossingen gebruiken, zoals Datadog, New Relic of Elastic Stack (ELK). U kunt deze hulpprogramma's integreren in AKS om logboeken, metrische gegevens en traceringen te verzamelen en verschillende inzichten te bieden in clusterprestaties.
Zelfstudie
We bieden een zelfstudie om de end-to-end ervaring van het uitvoeren van de ACME Fitness Store-toepassing op AKS te demonstreren. Zie acme-fitness-store/azure-kubernetes-service voor meer informatie. Deze zelfstudie biedt praktische richtlijnen en is bedoeld voor referentie. AKS is zeer flexibel, dus u moet configuraties en aanpassingen kiezen op basis van uw specifieke vereisten.