Freigeben über


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

  • 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:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte