Migrieren einer einfachen App von Service Fabric zu AKS
Dieser Artikel enthält ein Beispiel für eine Workloadmigration, mit der Sie einige der konzeptionellen Informationen implementieren können, die unter Migrieren Ihrer Workload von Service Fabric zu AKS bereitgestellt werden. Dieser Artikel enthält Informationen zu Azure Kubernetes Service (AKS) und einen Vergleich von AKS mit Azure Service Fabric. Außerdem werden Überlegungen beschrieben, die bei der Migration Ihrer Workloads berücksichtigt werden müssen.
Dieses Beispiel konzentriert sich auf Windows-basierte Service Fabric-Anwendungen, die bereits containerisiert wurden. Azure Service Fabric und Azure Kubernetes Service unterstützen Windows- und Linux-Container. Wenn Ihre Anwendung nicht containerisiert ist, sollten Sie prüfen, ob Sie sie containerisieren können. Wenn Sie die Anwendung in Azure Kubernetes Service bereitstellen wollen, müssen Sie für Ihre Anwendung ein Containerimage erstellen. Wenn die Anwendung von Service Fabric-Programmiermodellen (Reliable Services, Reliable Actors, ASP.NET Core und ausführbare Gastdateien) abhängt, müssen Sie wahrscheinlich ein Refactoring vornehmen.
Informationen zum Containerisieren Ihrer Anwendung finden Sie unter Vorbereiten einer Anwendung für AKS. Informationen zum Containerisieren einer ASP.NET-Anwendung finden Sie unter Containerisieren und Migrieren von ASP.NET-Apps zu Azure Kubernetes Service.
Voraussetzungen
Bevor Sie mit der Migration beginnen, benötigen Sie:
Ein Anwendungscontainer, der in Azure Container Registry gespeichert ist
Eine Bash-Umgebung, die Sie zum Konfigurieren Ihrer Azure-Ressourcen verwenden können
Mit Azure Cloud Shell können Sie über den Browser arbeiten. Weitere Informationen finden Sie unter Schnellstart für Bash in Azure Cloud Shell.
Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Informationen zu anderen Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.
Wenn Sie die Azure CLI zum ersten Mal verwenden, müssen Sie die Azure CLI-Erweiterung installieren, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden von Erweiterungen mit der Azure CLI.
Das Kubernetes-Befehlszeilentool kubectl. Wenn es noch nicht in Ihrer Umgebung verfügbar ist, können Sie es installieren, indem Sie den folgenden Befehl ausführen:
az aks install-cli
Schritte bei der Migration
Der erste Schritt besteht darin, die Ressourcen einzurichten, die Sie zum Erstellen eines Windows-Knotenpools in Kubernetes benötigen. Folgen Sie dazu dem Leitfaden unter Erstellen eines Windows Server-Containers auf einem Azure Kubernetes Service (AKS)-Cluster mit der Azure-Befehlszeilenschnittstelle, aber hören Sie auf, wenn Sie den Abschnitt „Bereitstellen der Anwendung“ erreichen. Befolgen Sie dann die Anweisungen in diesem Artikel.
Die Übersetzung des Service Fabric-Konfigurationsmanifests in ein AKS-Manifest ist ein wichtiger Schritt. Die folgenden Abschnitte zeigen:
- Dienstmanifest-XML, die Sie für eine grundlegende Service Fabric-Bereitstellung verwenden könnten.
- Ein funktionell gleichwertiges AKS-Manifest, das Deployment- und Service-Objekte in Kubernetes erstellt.
Die beiden Manifeste lassen sich nicht eins zu eins zuordnen, da sie auf den Funktionsparadigmen basieren, die für jeden Dienst spezifisch sind, aber ihre Absichten sind identisch. (In diesen Beispielen verwenden Variablen das Format <VARIABLE DESCRIPTION>
.)
Im AKS-Manifest bietet ein Deployment
-Objekt deklarative Aktualisierungen für Pods und ReplicaSets. Ein Service
-Objekt stellt eine Anwendung, die auf einer Gruppe von Pods läuft, als Netzwerkdienst zur Verfügung.
Beispiel für Service Fabric-Dienstmanifest
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="<APP NAME>"
Version="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<StatelessServiceType ServiceTypeName="<SERVICE NAME>" UseImplicitHost="true" />
</ServiceTypes>
<!-- Code package is your service executable file. -->
<CodePackage Name="code" Version="1.0.0">
<EntryPoint>
<ContainerHost>
<ImageName><YOUR IMAGE></ImageName>
<Commands></Commands>
</ContainerHost>
</EntryPoint>
<!-- Pass environment variables to your container. -->
<EnvironmentVariables>
<EnvironmentVariable Name="HttpGatewayPort" Value=""/>
<EnvironmentVariable Name="BackendServiceName" Value=""/>
</EnvironmentVariables>
</CodePackage>
<ConfigPackage Name="Config" Version="1.0.0" />
<Resources>
<Endpoints>
<Endpoint Name="<HTTP ENDPOINT NAME>" UriScheme="http" Port="80" Protocol="http"/>
</Endpoints>
</Resources>
</ServiceManifest>
Beispiel für AKS-Manifest
apiVersion: apps/v1
kind: Deployment
metadata:
name: <APP NAME>
labels:
app: <APP NAME>
spec:
replicas: 1
template:
metadata:
name: <APP NAME>
labels:
app: <APP NAME>
spec:
nodeSelector:
"kubernetes.io/os": windows
containers:
- name: <SERVICE NAME>
image: <YOUR IMAGE>
resources:
limits:
cpu: 1
memory: 800M
ports:
- containerPort: 80
- env:
- name: HttpGatewayPort
value: ""
- name: BackendServiceName
value: ""
selector:
matchLabels:
app: <APP NAME>
---
apiVersion: v1
kind: Service
metadata:
name: <SERVICE NAME>
spec:
type: LoadBalancer
ports:
- protocol: TCP
port: 80
selector:
app: <SERVICE NAME>
Kubernetes bietet eine Vielzahl von Konfigurationsoptionen, die für erfahrene Entwickler nützlich sind. Manifeste können jedoch groß und komplex werden, wenn Sie zu viele davon verwenden. Informationen zur Implementierung einer einfachen Migration finden Sie unter Bereitstellungen und YAML-Manifeste.
Nachdem Sie Ihr Manifest haben, müssen Sie es nur noch anwenden, und schon können Sie Ihre App beobachten:
kubectl apply -f <YOUR MANIFEST>.yaml
kubectl get deploy <APP NAME>
kubectl get service <SERVICE NAME> --watch
Hinweis
In diesem Beispiel wird der Standardnamespace von Kubernetes verwendet, der in der Regel nur für grundlegende Szenarien verwendet wird. In Kubernetes bieten Namespaces einen Mechanismus zur Isolierung von Ressourcengruppen innerhalb eines einzelnen Clusters. Namespaces sind wichtig für die Durchsetzung von Sicherheits-, Netzwerk- und Ressourcengrenzen. Informationen zum Ermitteln der für Ihre Anwendung am besten geeignete Konfiguration finden Sie in der Dokumentation zu Kuberetes-Namespaces.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Ally Ford | Product Manager II
- Paolo Salvatori | Principal Customer Engineer
- Brandon Smith | Program Manager II
Andere Mitwirkende:
- Mick Alberts | Technical Writer
- Ayobami Ayodeji | Senior Program Manager
- Moumita Dey Verma | Senior Cloud Solutions Architect
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Bleiben Sie mit den AKS-Versionshinweisen, der AKS-Roadmap und Azure-Updates auf dem Laufenden über AKS.
- Verwenden Sie die aktuellen Windows Server-Images, um die Sicherheit zu gewährleisten, die Leistung zu verbessern und den Mehraufwand zu reduzieren.
- Nutzen Sie den AKS-Releasetracker, um über die aktuelle Version von Kubernetes auf dem Laufenden zu bleiben.
- Verwenden Sie das aktuelle SDK für .NET-Workloads.
- Erwägen Sie die Durchführung von Auslastungstests und Leistungsoptimierung und überprüfen Sie regelmäßig die CPU- und Speicherquoten, die auf AKS-Pods angewendet werden: Überwachen von Azure Kubernetes Service (AKS) mit Azure Monitor.
- Verwenden Sie den Beschleuniger für AKS-Zielzonen, um Workloads in AKS zu implementieren und bewährte Methoden anzuwenden.