Eseguire la migrazione al servizio Azure Kubernetes

Per pianificare ed eseguire correttamente la migrazione al servizio Azure Kubernetes, questa guida fornisce informazioni dettagliate sulla configurazione corrente del servizio Azure Kubernetes. Anche se questo articolo non tratta tutti gli scenari, contiene collegamenti a informazioni più dettagliate per la pianificazione di una migrazione corretta.

In questo articolo vengono riepilogati i dettagli della migrazione per:

• Containerizzazione di applicazioni tramite Azure Migrate
• Servizio Azure Kubernetes con Load Balancer Standard e set di scalabilità di macchine virtuali
• Servizi di Azure esistenti collegati
• Verificare le quote valide
• Disponibilità elevata e continuità aziendale
• Considerazioni per le applicazioni senza stato
• Considerazioni per le applicazioni con stato
• Distribuzione della configurazione del cluster

Nota

A seconda dello scenario, gli strumenti open source seguenti possono essere utili per la migrazione:

• Velero (richiede Kubernetes 1.7+)
• Estensione dell'interfaccia della riga di comando di Azure Kube

Operazioni preliminari

• Assicurarsi che la versione di Kubernetes di destinazione si trovi all'interno della finestra supportata per il servizio Azure Kubernetes. Le versioni precedenti potrebbero non essere incluse nell'intervallo supportato e richiedono un aggiornamento della versione per il supporto del servizio Azure Kubernetes. Per altre informazioni, vedere Versioni Kubernetes supportate nel servizio Azure Kubernetes.
• Se si esegue la migrazione a una versione più recente di Kubernetes, esaminare i criteri di supporto della versione Kubernetes e dello sfasamento della versione.

Una procedura importante da includere nel processo di migrazione è ricordare di seguire i modelli di distribuzione e test di uso comune. Il test dell'applicazione prima della distribuzione è un passaggio importante per garantire la qualità, la funzionalità e la compatibilità con l'ambiente di destinazione. Consente di identificare e correggere eventuali errori, bug o problemi che potrebbero influire sulle prestazioni, sulla sicurezza o sull'usabilità dell'applicazione o dell'infrastruttura sottostante.

Usare Azure Migrate per eseguire le migrazione delle applicazioni al servizio Azure Kubernetes

Azure Migrate offre una piattaforma centralizzata per la valutazione e la migrazione ad Azure dei server, dell'infrastruttura, delle applicazioni e dei dati locali. Per il servizio Azure Kubernetes, è possibile usare Azure Migrate per le attività seguenti:

• Containerizzazione di applicazioni ASP.NET e migrazione al servizio Azure Kubernetes.
• Containerizzazione di applicazioni Web Java e migrazione al servizio Azure Kubernetes.

Servizio Azure Kubernetes con Load Balancer Standard e set di scalabilità di macchine virtuali

Il servizio Azure Kubernetes è un servizio gestito che offre funzionalità esclusive con un sovraccarico di gestione inferiore. Poiché il servizio Azure Kubernetes è un servizio gestito, è necessario selezionare un set di aree supportate dal servizio Azure Kubernetes. Potrebbe essere necessario modificare le applicazioni esistenti per mantenerle integre nel piano di controllo gestito dal servizio Azure Kubernetes durante la transizione dal cluster esistente al servizio Azure Kubernetes.

È consigliabile usare i cluster del servizio Azure Kubernetes supportati da set di scalabilità di macchine virtuali e Load Balancer Standard di Azure per assicurarsi di ottenere le funzionalità seguenti:

• Pool di nodi multipli,
• Zone di disponibilità,
• Intervalli IP autorizzati,
• AutoScaler del cluster,
• Criteri di Azure per il servizio Azure Kubernetes e
• Altre nuove funzionalità non appena vengono rilasciate.

I cluster del servizio Azure Kubernetes supportati dai set di disponibilità delle macchine virtuali non supportano molte di queste funzionalità.

Creare un cluster del servizio Azure Kubernetes con Load Balancer Standard e set di scalabilità di macchine virtuali

L'esempio seguente crea un cluster del servizio Azure Kubernetes con un pool a nodo singolo supportato da un set di scalabilità di macchine virtuali. Abilita il componente di scalabilità automatica del cluster nel pool di nodi per il cluster e imposta un minimo di uno e un massimo di tre nodi.

1. Creare un gruppo di risorse usando il comando az group create.

   az group create --name myResourceGroup --location eastus
   

2. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create.

   az aks create \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --node-count 1 \
     --vm-set-type VirtualMachineScaleSets \
     --load-balancer-sku standard \
     --enable-cluster-autoscaler \
     --min-count 1 \
     --max-count 3
   

Servizi di Azure esistenti collegati

Quando si esegue la migrazione dei cluster, è possibile che siano stati collegati servizi esterni di Azure. Anche se i servizi seguenti non richiedono la ricreazione delle risorse, richiedono l'aggiornamento delle connessioni precedenti ai nuovi cluster per mantenere le funzionalità.

• Registro Azure Container
• Log Analytics
• Application Insights
• Gestione traffico
• Account di archiviazione
• Database esterni

Verificare le quote valide

Poiché altre macchine virtuali vengono distribuite nella sottoscrizione durante la migrazione, è necessario verificare che i limiti e le quote siano sufficienti per tali risorse. Se necessario, richiedere un aumento della quota di vCPU.

Potrebbe essere necessario richiedere un aumento delle quote di rete per assicurarsi di non esaurire gli indirizzi IP. Per altre informazioni, vedere reti e intervalli IP per il servizio Azure Kubernetes.

Per altre informazioni, vedere Limiti dei servizi e della sottoscrizione di Azure. Per controllare le quote correnti, nel portale di Azure, andare sul pannello delle sottoscrizioni, selezionare la sottoscrizione, quindi selezionare Uso + quote.

Disponibilità elevata e continuità aziendale

Se l'applicazione non riesce a gestire i tempi di inattività, è necessario seguire le procedure consigliate per gli scenari di migrazione a disponibilità elevata. Altre informazioni sulle Procedure consigliate per la pianificazione complessa della continuità aziendale, il ripristino di emergenza e l’ottimizzazione del tempo di attività nel servizio Azure Kubernetes.

Per le applicazioni complesse, in genere si esegue la migrazione nel tempo anziché contemporaneamente, vale a dire che gli ambienti vecchi e nuovi potrebbero dover comunicare in rete. Le applicazioni che in precedenza usavano i servizi ClusterIP per comunicare potrebbero necessitare di essere esposte come tipo LoadBalancer e protette in modo appropriato.

Per completare la migrazione è opportuno indirizzare i client per i nuovi servizi in esecuzione in servizio Azure Kubernetes. È consigliabile reindirizzare il traffico tramite l'aggiornamento di DNS in modo che punti al servizio di bilanciamento del carico posizionato davanti ai cluster del servizio Azure Kubernetes.

Gestione traffico di Microsoft Azure può indirizzare i clienti al Kubernetes cluster e all'istanza dell'applicazione desiderati. Gestione traffico è un servizio di bilanciamento del carico del traffico basato su DNS in grado di distribuire il traffico di rete tra le aree. Per prestazioni e ridondanza ottimali, indirizzare tutto il traffico dell'applicazione tramite Gestione traffico prima di passare al cluster del servizio Azure Kubernetes.

In una distribuzione a più cluster, i clienti devono connettersi a un nome DNS di Gestione traffico che punta ai servizi in ogni cluster del servizio Azure Kubernetes. Definire questi servizi tramite gli endpoint di Gestione traffico. Ogni endpoint è l'IP del servizio di bilanciamento del carico. Usare questa configurazione per indirizzare il traffico di rete dall'endpoint di Gestione traffico in un'area all'endpoint in un'altra area.

Il servizio Frontdoor di Azure è un'altra opzione per il routing del traffico per i cluster del servizio Azure Kubernetes. Con il servizio Frontdoor di Azure è possibile definire, gestire e monitorare il routing globale del traffico Web, rendendo le prestazioni ottimali e il failover globale immediato per una disponibilità elevata.

Considerazioni per le applicazioni senza stato

La migrazione di applicazioni senza stato comprende i passaggi seguenti:

1. Applicare le definizioni delle risorse (YAML o Helm) al nuovo cluster.
2. Assicurarsi che tutto funzioni come previsto.
3. Reindirizzare il traffico per attivare il nuovo cluster.

Considerazioni per le applicazioni con stato

Pianificare attentamente la migrazione delle applicazioni con stato per evitare la perdita di dati o tempi di inattività imprevisti.

• Se si usa File di Azure, è possibile montare la condivisione file come volume nel nuovo cluster. Vedere Montare file di Azure statici come volume.
• Se si usa Azure Managed Disks, è possibile montare il disco solo se non è stato eseguito il collegamento a una macchina virtuale. Vedere Montare un disco statico di Azure come volume.
• Se nessuno di questi approcci funziona, è possibile usare le opzioni di backup e ripristino. Vedere Velero in Azure.

File di Azure

A differenza dei dischi, i file di Azure possono essere montati simultaneamente da più host. Nel cluster del servizio Azure Kubernetes, Azure e Kubernetes non impediscono di creare un pod che il cluster del servizio Azure Kubernetes usa ancora. Per evitare la perdita di dati e il comportamento imprevisto, assicurarsi che i cluster non vengano scritti contemporaneamente negli stessi file.

Se l'applicazione può ospitare più repliche che puntano alla stessa condivisione di file, seguire i passaggi della migrazione senza stato e distribuire le definizioni di YAML nel nuovo cluster.

In caso contrario, un approccio di migrazione possibile prevede i passaggi seguenti:

1. Verificare che l'applicazione funzioni correttamente.
2. Indirizzare il traffico attivo al nuovo cluster del servizio Azure Kubernetes.
3. Disconnettere il cluster precedente.

Se si desidera iniziare con una condivisione vuota ed eseguire un copia dei dati di origine, è possibile usare il comando az storage file copy per effettuare la migrazione dei dati.

Migrazione di volumi persistenti

Se si esegue la migrazione di volumi persistenti esistenti al servizio Azure Kubernetes, in genere seguire questa procedura:

1. Disattivare la scrittura nell'applicazione.
   • Questo passaggio è facoltativo e richiede tempi di inattività.
2. Creare snapshot dei dischi.
3. Creare nuovi dischi gestiti dagli snapshot.
4. Creare volumi permanenti in servizio Azure Kubernetes.
5. Aggiornare le specifiche del Pod per usare i volumi esistenti anziché PersistentVolumeClaims (provisioning statico).
6. Distribuire l'applicazione nel servizio Azure Kubernetes.
7. Verificare che l'applicazione funzioni correttamente.
8. Indirizzare il traffico attivo al nuovo cluster del servizio Azure Kubernetes.

Importante

Se si sceglie di non disattivare le scritture, è necessario replicare i dati nella nuova distribuzione. In caso contrario, i dati scritti dopo aver creato gli snapshot del disco non vengono visualizzati.

I seguenti strumenti open source consentono di creare dischi gestiti ed eseguire la migrazione dei volumi tra i cluster Kubernetes:

• L’estensione Disk Copy dell’interfaccia della riga di comando di Azure copia e converte i dischi in gruppi di risorse e aree di Azure.
• L’estensione dell’interfaccia della riga di comando di Azure Kube enumera i volumi Kubernetes ACS ed esegue la migrazione a un cluster del servizio Azure Kubernetes.

Distribuzione della configurazione del cluster

È consigliabile usare la pipeline di integrazione continua (CI) e recapito continuo (CD) esistente per distribuire una configurazione valida nota nel servizio Azure Kubernetes. È possibile usare Azure Pipelines per compilare e distribuire le applicazioni nel servizio Azure Kubernetes. Clonare le attività di distribuzione esistenti e assicurarsi che kubeconfig faccia riferimento al nuovo cluster del servizio Azure Kubernetes.

Se non è possibile, esportare le definizioni delle risorse dal cluster Kubernetes esistente e quindi applicarle al servizio Azure Kubernetes. È possibile usare kubectl per esportare gli oggetti. Ad esempio:

kubectl get deployment -o yaml > deployments.yaml

Assicurarsi di esaminare l'output e rimuovere eventuali campi dati in tempo reale non necessari.

Spostamento delle risorse esistenti in un'altra area

È possibile spostare il cluster del servizio Azure Kubernetes in un'area diversa supportata dal servizio Azure Kubernetes. È consigliabile creare un nuovo cluster nell'altra area e quindi distribuire le risorse e le applicazioni nel nuovo cluster.

Se nel cluster del servizio Azure Kubernetes sono in esecuzione servizi, è necessario installare e configurare tali servizi nel cluster nella nuova area.

In questo articolo sono stati riepilogati i dettagli della migrazione per:

• Containerizzazione di applicazioni tramite Azure Migrate
• Servizio Azure Kubernetes con Load Balancer Standard e set di scalabilità di macchine virtuali
• Servizi di Azure esistenti collegati
• Verificare le quote valide
• Disponibilità elevata e continuità aziendale
• Considerazioni per le applicazioni senza stato
• Considerazioni per le applicazioni con stato
• Distribuzione della configurazione del cluster