Dela via

Migrera en enkel app från Service Fabric till AKS

  • Artikel

Den här artikeln innehåller ett exempel på migrering av arbetsbelastningar som hjälper dig att implementera en del av den konceptuella informationen i Migrera din arbetsbelastning från Service Fabric till AKS. Den artikeln innehåller information om Azure Kubernetes Service (AKS) och en jämförelse av AKS med Azure Service Fabric. Den beskriver även överväganden som du bör tänka på när du migrerar dina arbetsbelastningar.

Det här exemplet fokuserar på Windows-baserade Service Fabric-program som redan har containeriserats. Azure Service Fabric och Azure Kubernetes Service stöder både Windows- och Linux-containrar. Om ditt program inte är containerbaserat kan du överväga att undersöka om du kan containerisera det. Att skapa en containeravbildning för ditt program är en förutsättning för att distribuera programmet till Azure Kubernetes Service. Om programmet är beroende av Service Fabric-programmeringsmodeller (Reliable Services, Reliable Actors, ASP.NET Core och körbara gästfiler) måste du förmodligen omstrukturera.

Information om hur du containeriserar ditt program finns i Förbereda ett program för AKS. Information om hur du containeriserar ett ASP.NET program finns i ASP.NET appcontainerisering och migrering till AKS.

Förutsättningar

Innan du påbörjar migreringen behöver du:

  • En programcontaineravbildning som lagras i Azure Container Registry.

  • En Bash-miljö som du kan använda för att konfigurera dina Azure-resurser.

  • Kommandoradsverktyget kubectl Kubernetes. Om den inte redan är tillgänglig i din miljö kan du installera den genom att köra det här kommandot:

    az aks install-cli

Migreringssteg

Det första steget är att konfigurera de resurser som du behöver för att skapa en Windows-nodpool i Kubernetes. För att göra det följer du riktlinjerna i Skapa en Windows Server-container i ett AKS-kluster, men se till att stoppa när du når avsnittet "Distribuera programmet". Följ då anvisningarna i den här artikeln.

Översättningen av Service Fabric-konfigurationsmanifestet till ett AKS-manifest är ett viktigt steg. Följande avsnitt visar:

  • Tjänstmanifest-XML som du kan använda för en grundläggande Service Fabric-distribution.
  • Ett funktionellt motsvarande AKS-manifest som skapar Kubernetes-distributions- och tjänstobjekt.

De två manifesten mappar inte en-till-en eftersom de baseras på de funktionella paradigm som är specifika för varje tjänst, men deras avsikter är desamma. (I de här exemplen använder variabler formatet <VARIABLE DESCRIPTION>.)

I AKS-manifestet innehåller ett Deployment objekt deklarativa uppdateringar för poddar och repliker. Ett Service objekt exponerar ett program som körs på en uppsättning poddar som en nätverkstjänst.

Exempel på Service Fabric-tjänstmanifest

<?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>

AKS-exempelmanifest

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 tillhandahåller en stor uppsättning konfigurationsalternativ, vilket är användbart för erfarna utvecklare. Men manifest kan bli stora och komplexa när du använder för många av dem. Om du vill veta mer om att implementera en enkel migrering rekommenderar vi att du läser Distributioner och YAML-manifest.

När du har ditt manifest behöver du bara tillämpa det och du kan titta på din app:

kubectl apply -f <YOUR MANIFEST>.yaml
kubectl get deploy <APP NAME>
kubectl get service <SERVICE NAME> --watch

Kommentar

I det här exemplet används kubernetes-standardnamnområdet, som vanligtvis endast används för grundläggande scenarier. I Kubernetes tillhandahåller namnrymder en mekanism för att isolera grupper av resurser i ett enda kluster. Namnområden är viktiga för att framtvinga säkerhets-, nätverks- och resursgränser. Information om hur du fastställer en konfiguration som fungerar bäst för ditt program finns i dokumentationen om Kuberetes-namnområden.

Deltagare

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

Huvudsakliga författare:

Övriga medarbetare:

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

Nästa steg