Migrer d’Amazon EKS vers Azure Kubernetes Service (AKS)

  • Article

Cet article propose des stratégies pour migrer des charges de travail standard avec et sans état d’Amazon EKS vers Azure Kubernetes Service (AKS).

À propos de l’installation

Dans la pratique, le processus de déploiement d’une charge de travail de production réelle peut varier en fonction des facteurs suivants :

  • Stratégies de déploiement : le choix entre GitOps et les méthodes traditionnelles d'intégration continue/de déploiement continu (CI/CD) de DevOps influence considérablement l’approche de déploiement. GitOps hiérarchise l’infrastructure déclarative via des référentiels par contrôle de version, tandis que DevOps CI/CD se concentre sur des charges de travail automatisées pour la livraison d’applications.

  • Artefacts de déploiement : la sélection d’artefacts de déploiement joue un rôle essentiel dans la définition de la structure de déploiement. Les fichiers YAML, les fichiers manifeste, les graphiques Helm et les configurations Kustomize sont autant d'approches différentes permettant de préciser et de personnaliser les paramètres de déploiement, chacun avec ses points forts et ses cas d'utilisation.

  • Authentification et autorisation de la charge de travail : selon la configuration, les méthodes d’authentification et d’autorisation peuvent différer. Vous pouvez utiliser les rôles de gestion des identités et des accès (IAM) d'Amazon Web Services (AWS), des mécanismes d’identité de charge de travail ou des chaînes de connexion pour le contrôle des accès.

  • Monitoring : la mise en œuvre de solutions de monitoring est un aspect essentiel qui peut impliquer le recours à plusieurs outils et méthodologies en vue d'assurer la performance et l'intégrité des charges de travail déployées. Pour plus d'informations sur la comparaison entre le monitoring AKS à EKS, consultez Monitoring et journalisation Kubernetes.

Avant de commencer votre migration, passez en revue et tenez compte des bonnes pratiques et des conseils généraux suivants :

Considérations relatives à la migration des charges de travail

Cette section passe en revue un certain nombre d'éléments que vous devez prendre en compte avant de migrer vos charges de travail d’Amazon EKS vers AKS.

Comprenez l'environnement Amazon EKS existant

Analysez l’environnement EKS existant pour comprendre l’architecture, les ressources et les configurations actuelles.

  • Analysez la configuration EKS : évaluez la configuration du cluster EKS, notamment les types de nœuds, le nombre de nœuds, la version et la stratégie de prise en charge de Kubernetes, et la configuration de mise à l’échelle.

    Remarque

    EKS permet la création d’images AMI personnalisées pour les nœuds EKS. AKS ne permet pas l’utilisation d’images de nœud personnalisées. Si votre déploiement nécessite la personnalisation ds nœuds, vous pouvez appliquer la personnalisation kubelet et/ou DaemonSet.

  • Analysez les charges de travail d’application : identifiez toutes les charges de travail Kubernetes en cours d’exécution sur le cluster EKS, comme les déploiements, les services, les StatefulSet, les configurations d’entrée et les revendications de volume persistant. Assurez-vous que la liste des applications et de leurs ressources associées est bien complète.

  • Vérifiez les dépendances : identifiez les dépendances sur les services AWS propres à EKS.

    Service AWS Dépendance
    Gestionnaire de secrets AWS Azure Key Vault
    Agent AWS Guard Duty Microsoft Defender pour les conteneurs
    Agent EKS Pod Identity Identité de charge de travail Microsoft Entra ID
    Pilotes Container Storage Interface (CSI) Amazon Elastic File System (EFS) ou Elastic Block Store (EBS) Pilotes CSI AKS

  • Cluster EKS de sauvegarde : vous pouvez utiliser un outil non-Microsoft comme Velero pour sauvegarder et migrer des ressources Kubernetes et des volumes persistants.

Préparez l’environnement AKS dans Azure

La Container Networking Interface (CNI) du cloud privé virtuel (VPC) Amazon est le plug-in de mise en réseau par défaut pris en charge par EKS. Un cluster AKS prend en charge plusieurs plug-ins et méthodes réseau pour déployer un cluster dans un réseau virtuel, notamment :

Pour préparer votre cluster AKS, procédez comme suit :

  1. Créez un nouveau cluster AKS dans Azure, en configurant les paramètres de mise en réseau de façon à répondre à vos besoins.
  2. Passez en revue les manifestes Kubernetes et fichiers YAML utilisés dans EKS. Recherchez toute incompatibilité éventuelle de la version d’API Kubernetes ou des configurations EKS spécifiques non prises en charge par AKS.
  3. Vérifiez que vos images Docker et que l'emplacement du registre d’images conteneur sont accessibles à partir du cluster AKS. Vérifiez la connectivité réseau et tous les paramètres d’authentification et d’autorisation nécessaires pour accéder aux images.

Si vous suivez ces étapes, vous pouvez créer un cluster AKS et veiller à la compatibilité de vos manifestes Kubernetes et de vos images Docker, ce qui vous garantit un processus de migration en douceur d’EKS vers AKS.

Vue d’ensemble de la migration

La migration d’Amazon EKS vers AKS comporte plusieurs étapes, qui sont les suivantes :

  • Migration des images conteneur : la migration des images conteneur est une étape cruciale du passage d’EKS à AKS. Vous pouvez utiliser des outils comme kubectl, Docker ou des registres de conteneurs pour exporter et importer des images.

    1. Exportez les images depuis EKS.
    2. Configurez Azure Container Registry et attachez-le à AKS si vous ne l’avez pas déjà fait.
    3. Envoyez les images vers Container Registry.

    Des images conteneur peuvent également être importées dans Container Registry directement à partir d’un référentiel public ou privé non Azure. Pour plus d’informations, consultez Importer des images conteneur.

  • Migration du manifeste Kubernetes : AKS utilise le manifeste de fichier YAML Kubernetes pour définir les objets Kubernetes. En règle générale, les déploiements sont créés et gérés avec kubectl create ou kubectl apply. Créez un déploiement en définissant un fichier manifeste au format YAML. Pour plus d’informations, consultez cet exemple de manifeste AKS. Pour en savoir plus sur le fonctionnement des fichiers YAML sur Kubernetes, consultez Déploiements et manifestes YAML.

  • Migration des données : planifiez soigneusement la migration des applications avec état afin d’éviter la perte de données ou un temps d’arrêt imprévu. Pour plus d’informations, consultez la section Considérations relatives à la migration des charges de travail avec état.

Considérations relatives à la migration des charges de travail sans état

La migration de vos manifestes Kubernetes exige d'adapter la configuration de façon à ce qu'elle fonctionne dans l'environnement Azure, en procédant de la manière suivante :

  1. Mettre à jour les manifestes : mettez à jour vos manifestes Kubernetes pour utiliser les nouveaux emplacements des images dans Container Registry. Remplacez les références des images dans vos fichiers YAML par le chemin d’accès de Container Registry.

    1. Passez en revue les configurations propres à AWS de vos fichiers manifeste Kubernetes existants, comme les rôles VPC et IAM.
    2. Passez en revue les rôles IAM EKS associés aux nœuds, comptes de service et autres ressources. Mappez-les avec des rôles de contrôle d’accès en fonction du rôle (RBAC) équivalents Azure AKS. Pour plus d’informations, consultez Identité et accès des charges de travail Kubernetes.
    3. Modifiez les fichiers manifeste pour remplacer les paramètres propres à AWS par des paramètres propres à Azure, comme les annotations.

  2. Appliquez les manifestes à AKS :

    1. Connectez-vous au cluster AKS.
    2. Appliquez les fichiers manifeste Kubernetes modifiés à l’aide de kubectl apply -f.

Considérations relatives à la migration des charges de travail avec état

Si vos applications utilisent des Volumes persistants (PV) ou des Revendications de volume persistant (PVC) pour le stockage des données, veillez à sauvegarder ces données. Vous pouvez utiliser des outils tels que Velero pour la sauvegarde des clusters, notamment pour les données PV et PVC. Pour plus d’informations, consultez Sauvegardez et restaurez les ressources de vos clusters Amazon EKS avec Velero.

En règle générale, les applications avec état ont des besoins de stockage de données persistantes, ce qui rend le processus de migration encore plus complexe. Pour obtenir une comparaison des fonctionnalités de stockage d’Amazon EKS et AKS, consultez Options de stockage pour un cluster Kubernetes.

Procédez comme suit pour sauvegarder les données persistantes :

  1. Configurez Velero dans le cluster AKS et EKS.
  2. Effectuez une sauvegarde de votre cluster EKS.
  3. Copiez la sauvegarde Velero à partir du compartiment S3 vers le stockage Blob Azure à l’aide de la commande az copy.
  4. Dans la mesure où AKS et EKS peuvent utiliser différents storageClassNames pour les revendications de volume persistant, créez un configMap qui traduit la source storageClassNames en nom de classe compatible AKS. Si vous utilisez la même solution de stockage sur les clusters Kubernetes EKS et AKS, vous pouvez ignorer cette étape.
  5. Restaurez la sauvegarde sur AKS (à l’aide de la commande de restauration de Velero).
  6. Appliquez les modifications nécessaires aux objets restaurés, comme les références aux images conteneur dans Amazon Elastic Container Registry (ERC) ou l’accès aux secrets.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

  • Dixit Arora | Ingénieur client senior, ISV DN CoE
  • Ketan Chawda | Ingénieur client senior, ISV DN CoE

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes