Condividi tramite

Rilocare un cluster del servizio Azure Kubernetes in un'altra area

  • Articolo

Questo articolo include le indicazioni per la rilocazione di un cluster del servizio Azure Kubernetes in un'altra area.

Esistono diversi motivi per cui è possibile spostare le risorse di Azure esistenti da un'area a un'altra. È possibile:

  • Sfruttare i vantaggi di una nuova area di Azure.
  • Distribuire funzionalità o servizi disponibili solo in aree specifiche.
  • Soddisfare i requisiti di governance e criteri interni.
  • Allinearsi alle fusioni e alle acquisizioni aziendali
  • Soddisfare i requisiti di pianificazione della capacità.

Nota

I clienti con cicli di rilascio rapidi spesso sfruttano le pipeline CI/CD. In questi casi è consigliabile modificare le pipeline di compilazione e di rilascio invece di ridistribuire i cluster del servizio Azure Kubernetes nell'area di destinazione.

Prerequisiti

Prima di iniziare la fase di pianificazione della rilocazione, esaminare i prerequisiti seguenti:

  • Assicurarsi che l'area di destinazione abbia capacità sufficiente (SKU di macchine virtuali) per contenere i nuovi nodi del cluster.

  • Verificare di avere le autorizzazioni di creazione delle risorse per la sottoscrizione di destinazione. Verificare che il criterio di Azure non limiti le aree in cui è possibile distribuire il servizio Azure Kubernetes.

  • (Facoltativo) Raccogliere i modelli o gli script IaC (Infrastructure as code) con cui è stato effettuato il provisioning del cluster del servizio Azure Kubernetes di origine.

  • Raccogliere i manifesti Kubernetes per ricreare il carico di lavoro dell'applicazione all'interno del cluster di destinazione.

    Suggerimento

    Valutare un approccio GitOps alla distribuzione dei carichi di lavoro in cui i manifesti di configurazione di Kubernetes vengono archiviati in un repository Git e applicati automaticamente da un operatore GitOps in esecuzione all'interno del cluster, ad esempio Flux. Un approccio GitOps rende la ridistribuzione dei carichi di lavoro in cluster diversi facile quanto l'installazione del controller GitOps e la selezione del repository come riferimento.

  • Esaminare l'implementazione dell'ingresso del cluster.

  • Documentare le modifiche DNS necessarie per fare in modo che un dominio pubblico punti all'endpoint di ingresso del cluster.

  • Verificare se il cluster archivia dati sullo stato, ad esempio i volumi permanenti, di cui è necessario eseguire la migrazione al cluster di destinazione.

  • Documentare la gestione e la distribuzione dei certificati TLS pubblici.

  • Acquisire tutti gli indirizzi IP definiti nell'elenco di indirizzi consentiti del servizio dell'API Servizio Azure Kubernetes.

  • Informazioni su tutte le risorse dipendenti. Alcune delle risorse potrebbero essere:

    • Code, bus di messaggi, motori di cache
    • Azure Key Vault
    • Identità gestita
    • Configurazione della rete virtuale. Definire dimensioni di subnet sufficienti per consentire la crescita degli indirizzi IP dei contenitori se si usa il modello di rete avanzata di Azure
    • Indirizzo IP pubblico
    • Gateway di rete virtuale. Se la comunicazione da sito a sito è necessaria per un ambiente locale nell'area di destinazione, è necessario creare un gateway di rete virtuale nella rete virtuale di destinazione.
    • Endpoint privato di Azure. È necessario esaminare le risorse PaaS di Azure che usano endpoint di Collegamento privato e creare nuove istanze di Collegamento privato nell'area di destinazione, ad esempio Registro Azure Container, database SQL di Azure, KeyVault e così via.
    • Gateway applicazione di Azure
    • DNS Azure
    • Firewall di Azure
    • Monitoraggio di Azure (Informazioni dettagliate contenitore)
    • Il Registro Azure Container può replicare immagini tra istanze del Registro Azure Container. Per prestazioni ottimali durante il pull delle immagini, il registro deve esistere nell'area di destinazione.

      Nota

      Se si usa il Registro Azure Container per eseguire l'autenticazione nel registro contenitori, alla nuova identità gestita del cluster del servizio Azure Kubernetes può essere concesso il ruolo AcrPull del Controllo degli accessi in base al ruolo.

    • Azure Managed Disks
    • File di Azure

Preparazione

Prima di iniziare il processo di rilocazione del cluster, assicurarsi di completare le operazioni di preparazione seguenti:

  1. Per supportare i nodi e i pod del cluster del servizio Azure Kubernetes, se si usa la rete CNI di Azure, distribuire la rete virtuale con molte subnet di dimensioni sufficienti.

  2. Se si usa Azure Key Vault, Distribuire l'insieme di credenziali delle chiavi.

  3. Assicurarsi che i certificati di ingresso TLS pertinenti siano disponibili per la distribuzione, idealmente in un archivio sicuro, ad esempio Azure Key Vault.

  4. Distribuire un registro contenitori. Sincronizzare automaticamente le immagini del registro di origine o ricompilare ed eseguire il push di nuove immagini nel registro di destinazione usando una pipeline o uno script CI/CD.

  5. Distribuire un'area di lavoro di Monitoraggio di Azure.

  6. (Facoltativo) Distribuire il gateway applicazione di Azure per gestire il traffico in ingresso. Controller in ingresso del gateway applicazione può integrarsi strettamente con il cluster

  7. Distribuire tutte le origini dati richieste dal carico di lavoro del cluster e ripristinare o sincronizzare i dati di origine.

  8. Eseguire gli artefatti IaC esistenti definiti in una pipeline CI/CD e usati per distribuire il cluster di origine e i servizi da cui dipende. Modificare il codice o i parametri di input del modello per ridistribuire in un gruppo di risorse e un'area di Azure diversi.

Ripetere la distribuzione

Distribuire il cluster del servizio Azure Kubernetes senza alcuna migrazione dei dati seguendo questa procedura:

  1. Per creare l'ambiente di destinazione in Azure, eseguire manualmente gli artefatti IaC esistenti in una workstation locale.

  2. Se non sono presenti asset IaC esistenti, la configurazione del cluster corrente può essere esportata come modello di Resource Manager ed eseguita nell'area di destinazione. I modelli IaC vengono creati da zero o sono versioni modificate dei modelli di esempio tramite Bicep, JSON, Terraform o un'altra soluzione.

    Nota

    • Le connessioni a Collegamento privato, i registri connessi al Registro Azure Container e le origini dati dell'area di lavoro di Monitoraggio di Azure non vengono attualmente esportati usando questo metodo e devono quindi essere rimossi dal modello generato prima dell'esecuzione.

  3. Distribuire il carico di lavoro del contenitore nel cluster del servizio Azure Kubernetes. Questa operazione può essere eseguita in due modi:

    • Pull. Viene eseguito il pull dei manifesti da un repository e i manifesti vengono applicati da un controller in esecuzione all'interno del cluster. Si tratta dell'approccio GitOps.
    • Eseguire il push. Viene eseguito il push dei manifesti nel cluster usando il servizio API Kubernetes e lo strumento da riga di comando kubectl, da una pipeline CI/CD o da una workstation locale.

  4. Per assicurarsi che il nuovo cluster funzioni come previsto, eseguire test e convalida.

  5. Modificare le voci DNS pubbliche in modo che puntino all'indirizzo IP in ingresso esterno del cluster di destinazione (IP pubblico di Azure Load Balancer o IP pubblico del gateway applicazione).

  6. Una distribuzione che usa una soluzione di bilanciamento del carico globale, ad esempio DNS di Azure o Gestione traffico di Azure, deve aggiungere l'area alla configurazione.

Ridistribuire con la migrazione dei dati

I carichi di lavoro del servizio Azure Kubernetes che usano l'archiviazione locale, ad esempio volumi permanenti, per archiviare i dati oppure ospitare i servizi di database all'interno del cluster possono essere sottoposti a backup in un cluster di origine e ripristinati in un cluster di destinazione. Per informazioni su come eseguire il backup e il ripristino, vedere Eseguire il backup del servizio Azure Kubernetes usando l'interfaccia della riga di comando di Azure.

Contenuto correlato