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

Operazioni preliminari

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:

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) per assicurarsi di ottenere le funzionalità seguenti:

I cluster del servizio Azure Kubernetes supportati da set di disponibilità di macchine virtuali (VM) 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 \
        --generate-ssh-keys
    

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 di Azure
  • Azure Application Insights
  • Gestione traffico di Azure
  • account di archiviazione di Azure
  • 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 dall'endpoint di Gestione traffico in un'area all'endpoint in un'altra area.

Servizio Azure Kubernetes con Gestione traffico

Frontdoor di Azure è un'altra opzione per il routing del traffico per i cluster del servizio Azure Kubernetes. Con Frontdoor di Azure è possibile definire, gestire e monitorare il routing globale per il traffico Web ottimizzando le prestazioni ottimali e il failover globale immediato per la 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.

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 sono stati visualizzati.

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

Distribuzione della configurazione del cluster

È consigliabile usare l'integrazione continua esistente e la pipeline di recapito continuo 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
  • Verifica delle quote valide
  • Disponibilità elevata e continuità aziendale
  • Considerazioni per le applicazioni senza stato
  • Considerazioni per le applicazioni con stato
  • Distribuzione della configurazione del cluster