Eseguire la migrazione al servizio Azure Kubernetes

Articolo
10/31/2024

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:

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:

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:

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

Interfaccia della riga di comando di Azure
Terraform

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.

Creare un gruppo di risorse usando il comando az group create.
```
az group create --name myResourceGroup --location eastus
```

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

Il codice seguente crea un gruppo di risorse e un cluster Kubernetes in Azure, con scalabilità automatica abilitata e impostazioni di rete specifiche usando Terraform.

Nota

Il codice di esempio per questo articolo si trova nel repository GitHub di Azure Terraform. È possibile visualizzare il file di log contenente i risultati del test delle versioni correnti e precedenti di Terraform.

Vedere altri articoli e codice di esempio che illustrano come usare Terraform per gestire le risorse di Azure

Creare una directory in cui testare ed eseguire il codice Terraform di esempio e impostarla come directory corrente.

Creare un file denominato main.tfe inserire il codice seguente:

resource "random_pet" "rg_name" {
  prefix = var.resource_group_name_prefix
}

resource "azurerm_resource_group" "rg" {
  location = var.resource_group_location
  name     = random_pet.rg_name.id
}

resource "random_string" "aks_cluster_name" {
  length  = 12
  special = false
}

resource "azurerm_kubernetes_cluster" "aks_cluster" {
  name                = random_string.aks_cluster_name.result
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "myakscluster"

  default_node_pool {
    type                = "VirtualMachineScaleSets"
    name                = "default"
    node_count          = 1
    max_count           = 3
    min_count           = 1
    vm_size             = "Standard_DS2_v2"
    enable_auto_scaling = true
    upgrade_settings {
      drain_timeout_in_minutes      = 90
      max_surge                     = "10%"
      node_soak_duration_in_minutes = 0
    }
  }

  network_profile {
    network_plugin    = "azure"
    load_balancer_sku = "standard"
  }

  identity {
    type = "SystemAssigned"
  }

  tags = {
    Environment = "Production"
  }
}

Creare un file denominato outputs.tfe inserire il codice seguente:

output "resource_group_name" {
  value = azurerm_resource_group.rg.name
}

output "aks_cluster_name" {
  value = azurerm_kubernetes_cluster.aks_cluster.name
}

Creare un file denominato providers.tfe inserire il codice seguente:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>3.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Creare un file denominato variables.tfe inserire il codice seguente:

variable "resource_group_location" {
  type        = string
  default     = "eastus"
  description = "Location of the resource group."
}

variable "resource_group_name_prefix" {
  type        = string
  default     = "rg"
  description = "Prefix of the resource group name that's combined with a random ID so name is unique in your Azure subscription."
}

Inizializzare Terraform.

Per inizializzare la distribuzione di Terraform, eseguire terraform init. Questo comando scarica il provider di Azure necessario per gestire le risorse di Azure.
```
terraform init -upgrade
```
Punti principali:
- Il parametro -upgrade aggiorna i plug-in del provider necessari alla versione più recente conforme ai vincoli di versione della configurazione.
Creare un piano di esecuzione di Terraform.

Eseguire terraform plan per creare un piano di esecuzione.
```
terraform plan -out main.tfplan
```
Punti principali:
- Il comando terraform plan consente di creare un piano di esecuzione, ma non di eseguirlo. Determina invece le azioni necessarie per creare la configurazione specificata nei file di configurazione. Questo modello consente di verificare se il piano di esecuzione corrisponde alle aspettative prima di apportare modifiche alle risorse effettive.
- Il parametro -out facoltativo consente di specificare un file di output per il piano. L'uso del parametro -out garantisce che il piano esaminato sia esattamente quello che viene applicato.
Applicare un piano di esecuzione terraform.

Eseguire terraform apply per applicare il piano di esecuzione all'infrastruttura cloud.
```
terraform apply main.tfplan
```
Punti principali:
- Il comando terraform apply di esempio presuppone che in precedenza sia stato eseguito terraform plan -out main.tfplan.
- Se è stato specificato un nome file diverso per il parametro -out, usare lo stesso nome file nella chiamata a terraform apply.
- Se non è stato usato il parametro -out, chiamare terraform apply senza parametri.

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:

Applicare le definizioni delle risorse (YAML o Helm) al nuovo cluster.
Assicurarsi che tutto funzioni come previsto.
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:

Verificare che l'applicazione funzioni correttamente.
Indirizzare il traffico attivo al nuovo cluster del servizio Azure Kubernetes.
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:

Disattivare la scrittura nell'applicazione.
- Questo passaggio è facoltativo e richiede tempi di inattività.
Creare snapshot dei dischi.
Creare nuovi dischi gestiti dagli snapshot.
Creare volumi permanenti in servizio Azure Kubernetes.
Aggiornare le specifiche del Pod per usare i volumi esistenti anziché PersistentVolumeClaims (provisioning statico).
Distribuire l'applicazione nel servizio Azure Kubernetes.
Verificare che l'applicazione funzioni correttamente.
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:

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

Condividi tramite