Eseguire la migrazione di un'app semplice da Service Fabric al servizio Azure Kubernetes
Questo articolo fornisce un esempio di migrazione del carico di lavoro che consente di implementare alcune delle informazioni concettuali fornite in Eseguire la migrazione del carico di lavoro da Service Fabric al servizio Azure Kubernetes. Questo articolo fornisce informazioni su servizio Azure Kubernetes (servizio Azure Kubernetes) e un confronto tra il servizio Azure Kubernetes e Azure Service Fabric. Vengono inoltre descritte le considerazioni da tenere in considerazione quando si esegue la migrazione dei carichi di lavoro.
Questo esempio è incentrato sulle applicazioni di Service Fabric basate su Windows che sono già state incluse in contenitori. Azure Service Fabric e servizio Azure Kubernetes supportano entrambi i contenitori Windows e Linux. Se l'applicazione non è in contenitori, valutare se è possibile includerla in contenitori. La compilazione di un'immagine del contenitore per l'applicazione è un prerequisito per la distribuzione dell'applicazione in servizio Azure Kubernetes. Se l'applicazione dipende dai modelli di programmazione di Service Fabric (Reliable Services, Reliable Actors, ASP.NET Core ed eseguibili guest), è probabile che sia necessario eseguire il refactoring.
Per informazioni sulla containerizzazione dell'applicazione, vedere Preparare un'applicazione per il servizio Azure Kubernetes. Per informazioni sul contenitore di un'applicazione ASP.NET, vedere ASP.NET containerizzazione e migrazione di app al servizio Azure Kubernetes.
Prerequisiti
Prima di iniziare la migrazione, è necessario:
Immagine del contenitore dell'applicazione archiviata in Registro Azure Container.
Un ambiente Bash che è possibile usare per configurare le risorse di Azure.
Azure Cloud Shell consente di lavorare dal browser. Per altre informazioni, vedere Avvio rapido su Bash in Azure Cloud Shell.
Se si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure con il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Accedere tramite l'interfaccia della riga di comando di Azure.
La prima volta che si usa l'interfaccia della riga di comando di Azure, è necessario installare l'estensione dell'interfaccia della riga di comando di Azure quando richiesto. Per altre informazioni sulle estensioni, vedere Usare le estensioni con l'interfaccia della riga di comando di Azure.
Strumento da riga di comando kubectl Kubernetes. Se non è già disponibile nell'ambiente, è possibile installarlo eseguendo questo comando:
az aks install-cli
Passaggi per la migrazione
Il primo passaggio consiste nel configurare le risorse necessarie per creare un pool di nodi Windows in Kubernetes. A tale scopo, seguire le indicazioni riportate in Creare un contenitore Windows Server in un cluster del servizio Azure Kubernetes, ma assicurarsi di arrestarsi quando si raggiunge la sezione "Distribuire l'applicazione". A questo punto, seguire le istruzioni riportate in questo articolo.
La conversione del manifesto della configurazione di Service Fabric in un manifesto del servizio Azure Kubernetes è un passaggio importante. Le sezioni seguenti mostrano:
- XML del manifesto del servizio che è possibile usare per una distribuzione di Base di Service Fabric.
- Manifesto del servizio Azure Kubernetes equivalente a livello funzionale che crea oggetti Servizio e distribuzione Kubernetes.
I due manifesti non eseguono il mapping uno-a-uno perché si basano sui paradigmi funzionali specifici di ogni servizio, ma le loro finalità sono le stesse. In questi esempi le variabili usano il formato <VARIABLE DESCRIPTION>.
Nel manifesto del servizio Azure Kubernetes un Deployment oggetto fornisce aggiornamenti dichiarativi per Pod e ReplicaSet. Un Service oggetto espone un'applicazione in esecuzione in un set di pod come servizio di rete.
Manifesto del servizio Service Fabric di esempio
<?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>
Manifesto del servizio Azure Kubernetes di esempio
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 offre un ampio set di opzioni di configurazione, utile per sviluppatori esperti. Ma i manifesti possono diventare grandi e complessi quando si usano troppi di essi. Per informazioni sull'implementazione di una migrazione semplice, è consigliabile esaminare Distribuzioni e manifesti YAML.
Dopo aver ottenuto il manifesto, è sufficiente applicarlo ed è possibile guardare l'app:
kubectl apply -f <YOUR MANIFEST>.yaml
kubectl get deploy <APP NAME>
kubectl get service <SERVICE NAME> --watch
Nota
Questo esempio usa lo spazio dei nomi Kubernetes predefinito, generalmente usato solo per gli scenari di base. In Kubernetes gli spazi dei nomi forniscono un meccanismo per isolare gruppi di risorse all'interno di un singolo cluster. Gli spazi dei nomi sono importanti per applicare limiti di sicurezza, rete e risorse. Per determinare una configurazione ottimale per l'applicazione, vedere la documentazione relativa agli spazi dei nomi Kuberetes.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Ally Ford | Product Manager II
- Paolo Salvatori | Principal Customer Engineer
- Brandon Smith | Program Manager II
Altri contributori:
- Mick Alberts | Writer tecnico
- Ayobami Ayodeji | Senior Program Manager
- Moumita Dey Verma | Senior Cloud Solutions Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Mantenere aggiornati il servizio Azure Kubernetes con le note sulla versione del servizio Azure Kubernetes, la Roadmap del servizio Azure Kubernetes e gli aggiornamenti di Azure.
- Usare le immagini più recenti di Windows Server per mantenere la sicurezza, migliorare le prestazioni e ridurre il sovraccarico.
- Usare lo strumento di rilevamento delle versioni del servizio Azure Kubernetes per mantenere aggiornato la versione più recente di Kubernetes.
- Usare l'SDK più recente per i carichi di lavoro .NET.
- Prendere in considerazione l'esecuzione di test di carico e l'ottimizzazione delle prestazioni e valutare periodicamente le quote di CPU e memoria applicate ai pod del servizio Azure Kubernetes: Monitorare il servizio Azure Kubernetes con Monitoraggio di Azure.
- Usare l'acceleratore di zona di destinazione del servizio Azure Kubernetes per implementare i carichi di lavoro nel servizio Azure Kubernetes e applicare le procedure consigliate.