Migrer vers Azure Kubernetes Service (AKS)

  • Article

Pour vous aider à planifier et à exécuter la migration vers le service Azure Kubernetes (AKS), ce guide fournit des détails sur la configuration recommandée d’AKS. Bien que cet article ne couvre pas tous les scénarios, il propose des liens vers des informations plus détaillées sur la planification d’une migration réussie.

Dans cet article, nous résumons les détails de la migration pour :

  • Conteneurisation d’applications via Azure Migrate
  • AKS avec équilibrer la charge standard et Virtual Machine Scale Sets
  • Services Azure attachés existants
  • Garantie de la validité des quotas
  • Haute disponibilité et continuité de l’activité
  • Considérations relatives aux applications sans état
  • Points à prendre en compte sur les applications avec état
  • Déploiement de la configuration du cluster

Notes

Selon votre scénario, les outils open source suivants peuvent vous aider à migrer :

Avant de commencer

Une pratique importante à inclure dans votre processus de migration est de vous rappeler de suivre les modèles de déploiement et de test couramment utilisés. Le test de votre application avant le déploiement est une étape importante visant à garantir sa qualité, sa fonctionnalité et sa compatibilité avec l’environnement cible. Il peut vous aider à identifier et à corriger des erreurs, des bogues ou des problèmes susceptibles d’affecter le niveau de performance, la sécurité ou la facilité d’utilisation de l’application ou de l’infrastructure sous-jacente.

Utiliser Azure Migrate pour migrer vos applications vers AKS

Azure Migrate fournit une plateforme unifiée pour évaluer et migrer vers Azure des serveurs, une infrastructure, des applications et des données locaux. Pour AKS, vous pouvez utiliser Azure Migrate pour effectuer les tâches suivantes :

AKS avec équilibrer la charge standard et Virtual Machine Scale Sets

AKS est un service managé offrant des fonctionnalités uniques, avec un traitement de gestion moindre. AKS étant un service managé, vous devez choisir à partir d’un ensemble de régions prises en charge par AKS. Vous devrez peut-être modifier vos applications existantes pour les conserver dans le plan de contrôle géré par AKS lors de la transition de votre cluster existant vers AKS.

Nous vous conseillons d’utiliser des clusters AKS avec Virtual Machine Scale Sets et Azure Standard Load Balancer pour vous assurer de disposer des fonctionnalités suivantes :

Les clusters AKS s’appuyant sur des groupes à haute disponibilité de machines virtuelles ne prennent pas en charge la plupart de ces fonctionnalités.

Créer un cluster AKS avec Standard Load Balancer et Virtual Machine Scale Sets

L’exemple suivant crée un cluster AKS avec un pool de nœuds unique soutenu par un groupe de machines virtuelles identiques. Cela active la mise à l’échelle automatique de cluster sur le pool de nœuds pour le cluster et définit un minimum de un et un maximum de trois nœuds.

  1. Créez un groupe de ressources avec la commande az group create.

    az group create --name myResourceGroup --location eastus

  2. Créez un cluster AKS avec la commande 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

Services Azure attachés existants

Au cours de la migration des clusters, vous avez peut-être attaché des services Azure externes. Bien que les services suivants ne demandent pas à recréer les ressources, ils exigent de mettre à jour les connexions des précédents clusters vers les nouveaux clusters pour conserver les fonctionnalités.

  • Azure Container Registry
  • Log Analytics
  • Application Insights
  • Traffic Manager
  • Compte de stockage
  • Bases de données externes

Garantie de la validité des quotas

Comme d’autres machines virtuelles seront déployées dans votre abonnement pendant la migration, vous devez vérifier que vos quotas et vos limites sont définis sur des valeurs suffisantes pour ces ressources. Si nécessaire, demandez une augmentation du quota de processeurs virtuels.

Vous devrez peut-être demander une augmentation des quotas réseau pour vous assurer de ne pas épuiser les adresses IP. Pour plus d’informations, consultez Mise en réseau et plages d’adresses IP pour AKS.

Pour plus d’informations, consultez Azure subscription and service limits (Limites de service et d’abonnement Azure). Pour vérifier vos quotas actuels, dans le Portail Azure, accédez au panneau Abonnements, sélectionnez votre abonnement, puis sélectionnez Utilisation + quotas.

Haute disponibilité et continuité de l’activité

Si votre application ne peut pas gérer les temps d’arrêt, vous devez suivre les meilleures pratiques établies pour les scénarios de migration en haute disponibilité. Plus d’informations sur les pratiques recommandées pour la planification de la continuité d’activité complexe, la reprise d’activité et l’optimisation du temps d’activité dans Azure Kubernetes Service (AKS).

Pour les applications complexes, vous effectuez généralement une migration progressive plutôt qu’en une seule fois, ce qui signifie que les anciens et nouveaux environnements devront peut-être communiquer sur le réseau. Les applications qui utilisaient les services ClusterIP pour communiquer devront peut-être être exposées en tant que type LoadBalancer et sécurisées de manière adéquate.

Pour effectuer la migration, vous devez pointer les clients vers les nouveaux services qui exécutent AKS. Nous vous recommandons de rediriger le trafic en mettant à jour le DNS pour qu’il pointe vers l’équilibreur de charge se trouvant devant votre cluster AKS.

Azure Traffic Manager peut diriger les clients vers le cluster Kubernetes et l’instance d’application souhaités. Traffic Manager est un équilibreur de charge de trafic DNS qui peut répartir le trafic réseau entre les régions. Pour optimiser les performances et la redondance, faites transiter l’ensemble du trafic d’application par Traffic Manager avant qu’il parvienne à votre cluster AKS.

Dans un déploiement impliquant plusieurs clusters, les clients doivent se connecter à un nom DNS Traffic Manager qui pointe vers les services sur chaque cluster AKS. Définissez ces services en utilisant des points de terminaison Traffic Manager. Chaque point de terminaison est l’adresse IP d’équilibreur de charge de service. Cette configuration vous permet de diriger le trafic réseau du point de terminaison Traffic Manager d’une région vers le point de terminaison d’une autre région.

AKS with Traffic Manager

Azure Front Door Service représente une autre solution pour le routage du trafic des clusters AKS. Avec Azure Front Door Service vous pouvez définir, gérer et superviser le routage global de votre trafic web en privilégiant l’optimisation des performances et le basculement instantané global à des fins de haute disponibilité.

Considérations relatives aux applications sans état

La migration d’applications sans état implique les étapes suivantes :

  1. Appliquez vos définitions de ressources (YAML ou Helm) au nouveau cluster.
  2. Vérifiez que tout fonctionne correctement.
  3. Redirigez le trafic pour activer votre nouveau cluster.

Points à prendre en compte sur les applications avec état

Planifiez soigneusement la migration des applications avec afin d’éviter la perte de données ou un temps d’arrêt imprévu.

Azure Files

Contrairement aux disques, Azure Files peut être monté sur plusieurs hôtes en même temps. Dans votre cluster AKS, Azure et Kubernetes ne vous empêchent pas de créer un pod toujours utilisé par votre cluster AKS. Pour éviter une perte de données et un comportement inattendu, vérifiez que les clusters n’écrivent pas en même temps dans les mêmes fichiers.

Si votre application peut héberger plusieurs réplicas pointant vers le même partage de fichiers, suivez les étapes de migration sans état et déployez vos définitions YAML sur votre nouveau cluster.

Si ce n’est pas le cas, essayez une migration avec les étapes suivantes :

  1. Vérifiez que votre application fonctionne correctement.
  2. Pointez votre trafic en direct vers votre nouveau cluster AKS.
  3. Déconnectez l’ancien cluster.

Si vous souhaitez commencer avec un partage vide et copier les données sources, vous pouvez utiliser la commande az storage file copy pour migrer vos données.

Migration des volumes persistants

Si vous migrez des volumes persistants existants vers AKS, vous suivez généralement les étapes ci-après :

  1. Suspendre l’écriture dans l’application.
    • Cette étape est facultative et nécessite un temps d’arrêt.
  2. Prendre des instantanés des disques.
  3. Créer des disques managés à partir d’instantanés.
  4. Créer des volumes persistants dans AKS.
  5. Modifier les spécifications du pod pour qu’il utilise les volumes existants plutôt que PersistentVolumeClaims (provisionnement statique).
  6. Déployez votre application sur AKS.
  7. Vérifiez que votre application fonctionne correctement.
  8. Pointez votre trafic en direct vers votre nouveau cluster AKS.

Important

Si vous ne souhaitez pas suspendre les écritures, vous devez répliquer les données vers le nouveau déploiement. Dans le cas contraire, vous allez manquer les données écrites après avoir pris les instantanés de disque.

Les outils open source suivants vous aident à créer des disques managés et à migrer des volumes d’un cluster Kubernetes à l’autre :

Déploiement de la configuration du cluster

Nous vous recommandons d’utiliser votre pipeline d’intégration continue (CI) et de déploiement continu (CD) existant pour déployer une configuration connue sur AKS. Vous pouvez utiliser Azure Pipelines pour générer et déployer vos applications sur AKS. Clonez vos tâches de déploiement existantes et vérifiez que kubeconfig pointe vers le nouveau cluster AKS.

Si ce n’est pas possible, exportez les définitions de ressources depuis votre cluster Kubernetes existant, puis appliquez-les à AKS. Vous pouvez utiliser kubectl pour exporter des objets. Par exemple :

kubectl get deployment -o yaml > deployments.yaml

Veillez à examiner la sortie et à supprimer tous les champs de données actifs inutiles.

Déplacement des ressources existantes dans une autre région

Vous pouvez déplacer votre cluster AKS dans une autre région prise en charge par AKS. Nous vous recommandons de créer un cluster dans l’autre région et de déployer vos ressources et vos applications sur le nouveau cluster.

Par ailleurs, si vous disposez de services en cours d’exécution sur votre cluster AKS, vous devez installer et configurer ces services sur votre cluster dans la nouvelle région.

Dans cet article, nous avons synthétisé les détails de la migration pour :

  • Conteneurisation d’applications via Azure Migrate
  • AKS avec équilibrer la charge standard et Virtual Machine Scale Sets
  • Services Azure attachés existants
  • Garantie de la validité des quotas
  • Haute disponibilité et continuité de l’activité
  • Considérations relatives aux applications sans état
  • Points à prendre en compte sur les applications avec état
  • Déploiement de la configuration du cluster