Migrer vers Azure Kubernetes Service (AKS)

Article
10/31/2024

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 Azure Load Balancer (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 :

Velero (Nécessite Kubernetes 1.7+)
Extension Azure Kube CLI

Avant de commencer

Assurez-vous que la version de votre Kubernetes cible entre dans le cadre de la prise en charge pour AKS. Les versions antérieures peuvent ne pas figurer dans la plage prise en charge et nécessitent une mise à niveau pour être prises en charge par AKS. Pour plus d’informations, consultez la section Versions de Kubernetes prises en charge dans AKS.
Si vous effectuez une migration vers une version plus récente de Kubernetes, consultez la stratégie de prise en charge des versions et des différences de version Kubernetes.

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 Standard Load Balancer 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 recommandons d’utiliser des clusters AKS avec Virtual Machine Scale Sets et Azure Load Balancer (Standard) pour bénéficier des fonctionnalités suivantes :

Pools multinœuds,
Zones de disponibilité,
Plages IP autorisées,
Autoscaler de clusters,
Découvrir Azure Policy pour AKS Engine et
Autres nouvelles fonctionnalités à mesure qu’elles sont publiées.

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

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

Azure CLI
Terraform

L’exemple suivant crée un cluster AKS avec un pool de nœuds unique s’appuyant sur 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.

Créez un groupe de ressources avec la commande az group create.
```
az group create --name myResourceGroup --location eastus
```

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 \
    --generate-ssh-keys

Le code suivant crée un groupe de ressources et un cluster Kubernetes dans Azure, avec la mise à l’échelle automatique activée et des paramètres réseau spécifiques, en utilisant Terraform.

Remarque

L’exemple de code de cet article se trouve dans le dépôt GitHub Azure Terraform. Vous pouvez afficher le fichier journal contenant les résultats des tests des versions actuelles et précédentes de Terraform.

Consultez d’autres articles et exemples de code montrant comment utiliser Terraform pour gérer les ressources Azure.

Créez un répertoire dans lequel tester et exécuter l’exemple de code Terraform, et définissez-le en tant que répertoire actif.

Créez un fichier nommé main.tf et insérez le code suivant :

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

Créez un fichier nommé outputs.tf et insérez le code suivant :

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

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

Créez un fichier nommé providers.tf et insérez le code suivant :

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

provider "azurerm" {
  features {}
}

Créez un fichier nommé variables.tf et insérez le code suivant :

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."
}

Initialisez Terraform.

Exécutez terraform init pour initialiser le déploiement Terraform. Cette commande télécharge le fournisseur Azure à utiliser pour la gestion de vos ressources Azure.
```
terraform init -upgrade
```
Points essentiels :
- Le paramètre -upgrade met à niveau les plug-ins de fournisseur nécessaires vers la version la plus récente qui est conforme aux contraintes de version de la configuration.
Créer un plan d’exécution Terraform.

Exécutez terraform plan pour créer un plan d’exécution.
```
terraform plan -out main.tfplan
```
Points essentiels :
- La commande terraform plan crée un plan d’exécution, mais ne l’exécute pas. Au lieu de cela, elle détermine les actions nécessaires pour créer la configuration spécifiée dans vos fichiers de configuration. Ce modèle vous permet de vérifier si le plan d’exécution répond à vos attentes avant d’apporter des modifications aux ressources réelles.
- Le paramètre facultatif -out vous permet de spécifier un fichier de sortie pour le plan. L’utilisation du paramètre -out garantit que le plan que vous avez examiné correspond exactement à ce qui est appliqué.
Appliquez un plan d’exécution Terraform.

Exécutez terraform apply pour appliquer le plan d’exécution à votre infrastructure cloud.
```
terraform apply main.tfplan
```
Points essentiels :
- La commande exemple terraform apply part du principe que vous avez préalablement exécuté terraform plan -out main.tfplan.
- Si vous avez spécifié un autre nom de fichier pour le paramètre -out, utilisez ce même nom dans l’appel à terraform apply.
- Si vous n’avez pas utilisé le paramètre -out, appelez terraform apply sans aucun paramètre.

Services Azure attachés existants

Au cours de la migration des clusters, vous avez peut-être attaché des services Azure externes. Les services suivants ne nécessitent pas la recréation de ressources, mais ils nécessitent la mise à jour des connexions des précédents clusters vers les nouveaux clusters pour conserver les fonctionnalités.

Azure Container Registry
Azure Log Analytics
Azure Application Insights
Azure Traffic Manager
compte Stockage Azure
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 avec Traffic Manager

Azure Front Door est une autre option pour le routage du trafic des clusters AKS. Avec Azure Front Door, vous pouvez définir, gérer et surveiller le routage global de votre trafic web en privilégiant l’optimisation des performances et le basculement instantané global pour une haute disponibilité.

Considérations relatives aux applications sans état

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

Appliquez vos définitions de ressources (YAML ou Helm) au nouveau cluster.
Vérifiez que tout fonctionne correctement.
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.

Si vous utilisez Azure Files, vous pouvez monter le partage de fichiers en tant que volume dans le nouveau cluster. Voir Monter le service Azure Files statique en tant que volume.
Si vous utilisez des disques managés Azure, vous pouvez monter le disque uniquement s’il n’est pas attaché à une machine virtuelle. Voir Monter le service Azure Disk statique en tant que volume.
Si aucune de ces approches ne fonctionne, vous pouvez utiliser les options de sauvegarde et de restauration. Voir Velero sur Azure.

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 :

Vérifiez que votre application fonctionne correctement.
Pointez votre trafic en direct vers votre nouveau cluster AKS.
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 :

Suspendre l’écriture dans l’application.
- Cette étape est facultative et nécessite un temps d’arrêt.
Prendre des instantanés des disques.
Créer des disques managés à partir d’instantanés.
Créer des volumes persistants dans AKS.
Modifier les spécifications du pod pour qu’il utilise les volumes existants plutôt que PersistentVolumeClaims (provisionnement statique).
Déployez votre application sur AKS.
Vérifiez que votre application fonctionne correctement.
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, les données écrites après la réalisation des instantanés du disque sont manquantes.

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

L’extension Azure CLI Disk Copy copie et convertit des disques dans les groupes de ressources et les régions Azure.
L’extension Azure Kube CLI énumère les volumes Kubernetes ACS et effectue leur migration vers un cluster AKS.

Déploiement de la configuration du cluster

Nous vous recommandons d’utiliser votre pipeline existant d’intégration continue (CI) et de déploiement continu (CD) pour déployer une configuration réputée correcte 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 vers 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 Load Balancer (Standard) et Virtual Machine Scale Sets
Services Azure attachés existants
Garantir des quotas valides
Haute disponibilité et continuité de l’activité
Considérations relatives aux applications sans état
Points à prendre en compte sur les applications avec état
Déployer la configuration de votre cluster

Partager via