Condividi tramite

Eseguire la migrazione da Amazon EKS a servizio Azure Kubernetes (AKS)

  • Articolo

Questo articolo fornisce strategie per la migrazione di carichi di lavoro tipici senza stato e con stato da Amazon EKS a servizio Azure Kubernetes (servizio Azure Kubernetes).

Considerazioni

Il processo di distribuzione effettivo di un carico di lavoro di produzione reale può variare a seconda dei fattori seguenti:

  • Strategie di distribuzione: la scelta tra i metodi tradizionali di integrazione continua/distribuzione continua DevOps (CI/CD) influisce in modo significativo sull'approccio alla distribuzione. GitOps assegna priorità all'infrastruttura dichiarativa gestita tramite repository controllati dalla versione, mentre DevOps CI/CD è incentrata sui flussi di lavoro automatizzati per la distribuzione di applicazioni.

  • Artefatti di distribuzione: la selezione degli artefatti di distribuzione svolge un ruolo fondamentale nella definizione della struttura di distribuzione. I file YAML, i file manifesto, i grafici Helm e le configurazioni Kustomize rappresentano vari approcci per specificare e personalizzare le impostazioni di distribuzione, ognuna con i relativi punti di forza e casi d'uso.

  • Autenticazione e autorizzazione del carico di lavoro: a seconda della configurazione, i metodi di autenticazione e autorizzazione possono variare. È possibile usare i ruoli di Gestione delle identità e degli accessi (IAM) di Amazon Web Services (AWS), meccanismi di identità del carico di lavoro o stringa di connessione per il controllo di accesso.

  • Monitoraggio: l'implementazione delle soluzioni di monitoraggio è un aspetto critico che può coinvolgere vari strumenti e metodologie per garantire le prestazioni e l'integrità dei carichi di lavoro distribuiti. Per altre informazioni sul confronto tra il monitoraggio del servizio Azure Kubernetes e il servizio Azure Kubernetes, vedere Monitoraggio e registrazione di Kubernetes.

Prima di iniziare la migrazione, esaminare e prendere in considerazione le linee guida generali e le risorse consigliate seguenti:

  • Esaminare le procedure consigliate per gli sviluppatori e l'operatore del cluster.
  • Definire la strategia di monitoraggio e avviso per assicurarsi che l'applicazione funzioni come previsto.
  • Definire i requisiti di sicurezza e conformità per l'applicazione e l'ambiente del servizio Azure Kubernetes.
  • Definire i criteri di controllo di accesso e il modo in cui vengono applicati. Identificare tutti gli standard di conformità a cui deve essere rispettato.
  • Definire il ripristino di emergenza e il piano di continuità aziendale per l'ambiente del servizio Azure Kubernetes e l'applicazione.
  • Definire i criteri e le procedure di backup e ripristino. Identificare l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO).
  • Identificare eventuali rischi o problemi che potrebbero verificarsi durante la distribuzione.
  • Testare la funzionalità per assicurarsi che l'applicazione funzioni come previsto prima di reindirizzare il traffico in tempo reale al nuovo cluster del servizio Azure Kubernetes.

Considerazioni sulla migrazione del carico di lavoro

Questa sezione esamina alcuni aspetti da considerare prima di eseguire la migrazione dei carichi di lavoro da Amazon EKS al servizio Azure Kubernetes.

Informazioni sull'ambiente Amazon EKS esistente

Analizzare l'ambiente EKS esistente per comprendere l'architettura, le risorse e le configurazioni correnti.

  • Esaminare la configurazione del servizio Azure Kubernetes: valutare la configurazione del cluster EKS, ad esempio i tipi di nodo, il numero di nodi, la versione di Kubernetes e i criteri di supporto e la configurazione del ridimensionamento.

    Nota

    Il servizio Azure Kubernetes consente la creazione di immagini AMI personalizzate per i nodi del servizio Azure Kubernetes. Il servizio Azure Kubernetes non consente l'uso di immagini di nodi personalizzate. Se la distribuzione richiede la personalizzazione del nodo, è possibile applicare la personalizzazione kubelet e/o DaemonSet per personalizzare i nodi.

  • Esaminare i carichi di lavoro dell'applicazione: identificare tutti i carichi di lavoro Kubernetes in esecuzione nel cluster EKS, inclusi distribuzioni, servizi, set con stato, configurazioni in ingresso e attestazioni di volume persistente. Assicurarsi di disporre di un elenco completo delle applicazioni e delle relative risorse associate.

  • Controllare le dipendenze: identificare eventuali dipendenze dai servizi AWS specifici del servizio Azure Kubernetes.

    Servizio AWS Dipendenza
    AWS Secret Manager Azure Key Vault
    Agente di AWS Guard Duty Microsoft Defender per contenitori
    Agente identità pod del servizio Azure Kubernetes Identità del carico di lavoro dell'ID Microsoft Entra
    Driver Amazon Elastic File System (EFS) o Elastic Block Store (EBS) Container Storage Interface (CSI) Driver CSI del servizio Azure Kubernetes

  • Cluster del servizio Azure Kubernetes di backup: è possibile usare uno strumento non Microsoft come Velero per eseguire il backup e la migrazione di risorse Kubernetes e volumi permanenti.

Preparare l'ambiente del servizio Azure Kubernetes

Amazon Virtual Private Cloud (VPC) Container Networking Interface (CNI) è il plug-in di rete predefinito supportato dal servizio Azure Kubernetes. Un cluster del servizio Azure Kubernetes supporta più plug-in di rete e metodi per distribuire un cluster in una rete virtuale, tra cui:

Per preparare il cluster del servizio Azure Kubernetes, seguire questa procedura:

  1. Creare un nuovo cluster del servizio Azure Kubernetes in Azure, configurando le impostazioni di rete desiderate in base ai requisiti.
  2. Esaminare i manifesti kubernetes e i file YAML usati nel servizio Azure Kubernetes. Verificare la presenza di eventuali potenziali incompatibilità della versione dell'API Kubernetes o configurazioni specifiche del servizio Azure Kubernetes non supportate dal servizio Azure Kubernetes.
  3. Assicurarsi che le immagini Docker e il percorso del registro immagini del contenitore siano accessibili dal cluster del servizio Azure Kubernetes. Verificare la connettività di rete e le eventuali impostazioni di autenticazione e autorizzazione necessarie per l'accesso alle immagini.

Seguendo questa procedura, è possibile creare correttamente un cluster del servizio Azure Kubernetes e garantire la compatibilità per i manifesti e le immagini Docker di Kubernetes, garantendo un processo di migrazione uniforme dal servizio Azure Kubernetes al servizio Azure Kubernetes.

Panoramica della migrazione

La migrazione da Amazon EKS al servizio Azure Kubernetes prevede diversi passaggi, ad esempio:

  • Migrazione delle immagini del contenitore: la migrazione delle immagini del contenitore è un passaggio fondamentale quando si passa dal servizio Azure Kubernetes al servizio Azure Kubernetes. È possibile usare strumenti come kubectl, Docker o registri contenitori per esportare e importare immagini.

    1. Esportare immagini da EKS.
    2. Configurare un Registro Azure Container e collegarlo al servizio Azure Kubernetes, se non è già stato fatto.
    3. Eseguire il push delle immagini nel Registro Contenitori.

    Le immagini del contenitore possono anche essere importate in Registro Contenitori direttamente da un repository pubblico o privato di Azure. Per altre informazioni, vedere Importare immagini del contenitore.

  • Migrazione del manifesto kubernetes: il servizio Azure Kubernetes usa il manifesto del file YAML di Kubernetes per definire gli oggetti Kubernetes. Le distribuzioni vengono in genere create e gestite con kubectl create o kubectl apply. Creare una distribuzione definendo un file manifesto nel formato YAML. Per altre informazioni, vedere questo manifesto del servizio Azure Kubernetes di esempio. Per altre informazioni sul funzionamento dei file YAML in Kubernetes, vedere Distribuzioni e manifesti YAML.

  • Migrazione dei dati: pianificare attentamente la migrazione di applicazioni con stato per evitare perdite di dati o tempi di inattività imprevisti. Per altre informazioni, vedere la sezione Considerazioni sulla migrazione del carico di lavoro con stato.

Considerazioni sulla migrazione del carico di lavoro senza stato

La migrazione dei manifesti Kubernetes comporta l'adattamento della configurazione per il funzionamento nell'ambiente Azure, inclusi i passaggi seguenti:

  1. Aggiornare i manifesti: aggiornare i manifesti kubernetes per usare i nuovi percorsi di immagine nel Registro Container. Sostituire i riferimenti alle immagini nei file YAML con il percorso del Registro Container.

    1. Esaminare i file manifesto di Kubernetes esistenti per configurazioni specifiche di AWS, ad esempio i ruoli VPC e IAM.
    2. Esaminare i ruoli IAM del servizio Azure Kubernetes associati a nodi, account del servizio e altre risorse. Eseguirne il mapping con ruoli di controllo degli accessi in base al ruolo (RBAC) del servizio Azure Kubernetes equivalenti. Per altre informazioni, vedere Identità e accesso del carico di lavoro Kubernetes.
    3. Modificare i file manifesto per sostituire le impostazioni specifiche di AWS con le impostazioni specifiche di Azure, ad esempio le annotazioni.

  2. Applicare manifesti al servizio Azure Kubernetes:

    1. Connettersi al cluster del servizio Azure Kubernetes.
    2. Applicare i file manifesto kubernetes modificati usando kubectl apply -f.

Considerazioni sulla migrazione del carico di lavoro con stato

Se le applicazioni usano volumi persistenti (PVS) o attestazioni di volumi permanenti (PVC) per l'archiviazione dei dati, assicurarsi di eseguire il backup di questi dati. È possibile usare strumenti come Velero per eseguire backup del cluster, inclusi i dati PVS e PVC. Per altre informazioni, vedere Backup e ripristino delle risorse del cluster Amazon EKS con Velero.

Le applicazioni con stato hanno in genere requisiti di archiviazione dei dati persistenti, che aggiungono complessità al processo di migrazione. Per un confronto tra le funzionalità di archiviazione di Amazon EKS e servizio Azure Kubernetes, vedere Opzioni di archiviazione per un cluster Kubernetes.

Per eseguire il backup dei dati persistenti, seguire questa procedura:

  1. Configurare Velero nel cluster del servizio Azure Kubernetes e del servizio Azure Kubernetes .
  2. Eseguire un backup del cluster del servizio Azure Kubernetes.
  3. Copiare il backup di Velero dal bucket S3 all'archivio BLOB di Azure usando il comando az copy.
  4. Poiché il servizio Azure Kubernetes e il servizio Azure Kubernetes potrebbero usare diversi storageClassNames per le attestazioni di volume persistente, creare un configMap oggetto che converte l'origine storageClassNames in un nome di classe compatibile con il servizio Azure Kubernetes. È possibile ignorare questo passaggio se si usa la stessa soluzione di archiviazione nel servizio Azure Kubernetes e nei cluster Kubernetes del servizio Azure Kubernetes.
  5. Ripristinare il backup nel servizio Azure Kubernetes usando il comando di ripristino di Velero.
  6. Applicare le modifiche necessarie agli oggetti ripristinati, ad esempio i riferimenti alle immagini del contenitore in Amazon Elastic Container Registry (ECR) o l'accesso ai segreti.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

  • Dixit Arora | Senior Customer Engineer, ISV DN CoE
  • Ketan Chawda | Senior Customer Engineer, ISV DN CoE

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi