Partager via

Déplacer un cluster Azure Kubernetes Service (AKS) vers une autre région

  • Article

Cet article fournit de l’aide pour déplacer un cluster Azure Kubernetes Service vers une autre région.

Il existe différentes raisons pour lesquelles vous pouvez avoir besoin de déplacer vos ressources Azure existantes d’une région à une autre. Vous pouvez :

  • Tirer parti d’une nouvelle région Azure.
  • Déployer des fonctionnalités ou des services disponibles uniquement dans des régions spécifiques.
  • Respecter les exigences de gouvernance et de stratégie internes.
  • Être en phase avec les fusions et acquisitions de l’entreprise
  • Répondez aux exigences de planification de la capacité.

Remarque

Les clients avec des cycles de mise en production rapides tirent souvent profit des pipelines CI/CD. Dans ces cas, vous pouvez envisager de modifier les pipelines de build et de mise en production au lieu de redéployer les clusters AKS dans la région cible.

Prérequis

Avant de commencer l’étape de planification du déplacement, passez en revue les prérequis suivant :

  • Assurez-vous que la région cible dispose d’une capacité suffisante (références SKU de machine virtuelle) pour prendre en charge les nouveaux nœuds de cluster.

  • Vérifiez que vous disposez d’autorisations de création de ressources pour l’abonnement cible. Vérifiez qu’Azure Policy ne restreint pas les régions dans lesquelles AKS peut être déployé.

  • (Facultatif) Collectez les modèles ou scripts IaC (infrastructure en tant que code) avec lesquels vous avez approvisionné le cluster AKS source.

  • Collectez les manifestes Kubernetes pour recréer la charge de travail d’application au sein du cluster cible.

    Conseil

    Évaluez une approche GitOps pour le déploiement de charge de travail où les manifestes de configuration Kubernetes sont stockés dans un dépôt Git et appliqués automatiquement par un opérateur GitOps s’exécutant dans le cluster, par exemple Flux. Grâce à une approche GitOps, il vous suffit d’installer le contrôleur GitOps et de le pointer vers le dépôt pour redéployer des charges de travail sur différents clusters.

  • Passez en revue l’implémentation d’entrée du cluster.

  • Documentez les modifications DNS nécessaires pour pointer un domaine public vers le point de terminaison d’entrée du cluster.

  • Déterminez si le cluster stocke des données d’état que vous devez migrer vers le cluster cible, notamment des volumes persistants.

  • Documentez la gestion et la distribution des certificats TLS publics.

  • Capturez toutes les adresses IP définies dans la liste d’autorisation du service d’API AKS.

  • Comprendre toutes les ressources dépendantes. Voici quelques ressources :

    • Files d’attente, bus de messages, moteurs de cache
    • Azure Key Vault
    • Identité gérée
    • Configuration du réseau virtuel. Définissez des tailles de sous-réseau suffisantes pour permettre la croissance IP du conteneur si vous utilisez le modèle de mise en réseau avancé Azure.
    • Adresse IP publique
    • Passerelle de réseau virtuel (VNG). Si une communication de site à site est requise vers un environnement local dans la région cible, vous devez créer une passerelle de réseau virtuel dans le réseau virtuel cible.
    • Point de terminaison privé Azure. Passez en revue les ressources PaaS Azure utilisant des points de terminaison de liaison privée et créez des instances de liaison privée dans la région cible (ACR, Azure SQL Database, KeyVault, etc.).
    • Application Gateway Azure
    • Azure DNS
    • Pare-feu Azure
    • Azure Monitor (Container Insights)
    • Azure Container Registry peut répliquer des images entre des instances ACR. Pour obtenir des performances optimales lors du tirage (pull) d’images, le registre doit exister dans la région cible.

      Remarque

      Si vous utilisez Azure Container Registry pour l’authentification auprès du registre de conteneurs, le rôle RBAC AcrPull peut être attribué à l’identité managée du nouveau cluster AKS.

    • Disques managés Azure
    • Azure Files

Préparer

Avant de commencer le processus de déplacement du cluster, veillez à effectuer les préparations suivantes :

  1. Pour prendre en charge les nœuds et les pods du cluster AKS si vous utilisez la mise en réseau Azure CNI, déployez le réseau virtuel avec de nombreux sous-réseaux de taille suffisante.

  2. Si vous utilisez Azure Key Vault, déployez le coffre de clés.

  3. Vérifiez que les certificats d’entrée TLS appropriés sont disponibles pour le déploiement. Dans l’idéal, ils se trouvent dans un magasin sécurisé comme Azure Key Vault.

  4. Déployez un registre de conteneurs. Synchronisez automatiquement les images du registre source ou regénérez de nouvelles images et envoyez-les (push) au registre cible à l’aide d’un pipeline ou d’un script CI/CD.

  5. Déployez un espace de travail Azure Monitor.

  6. (Facultatif) Déployez Azure Application Gateway pour gérer le trafic d’entrée. Le contrôleur d’entrée AGIC (Application Gateway Ingress Controller) peut s’intégrer étroitement au cluster.

  7. Déployez toutes les sources de données requises par la charge de travail du cluster et restaurez ou synchronisez les données sources.

  8. Exécutez les artefacts IaC existants définis dans un pipeline CI/CD et utilisés pour déployer le cluster source et les services dont il dépend. Modifiez les paramètres d’entrée du code ou du modèle pour effectuer le redéploiement sur un autre groupe de ressources et une autre région Azure.

Redeploy

Déployez le cluster AKS sans aucune migration des données en effectuant les étapes suivantes :

  1. Pour créer l’environnement cible dans Azure, exécutez manuellement les artefacts IaC existants sur une station de travail locale.

  2. En l’absence de ressources IaC existantes, la configuration actuelle du cluster peut être exportée en tant que modèle ARM et exécutée sur la région cible. Les modèles IaC sont créés à partir de zéro ou sont des versions modifiées d’exemples de modèles avec Bicep, JSON, Terraform ou une autre solution.

    Remarque

    • Les connexions Private Link, les registres connectés à ACR et les sources de données de l’espace de travail Azure Monitor ne sont pas actuellement exportés selon cette méthode et doivent donc être supprimés du modèle généré avant l’exécution.

  3. Déployez la charge de travail du conteneur sur le cluster AKS à l’aide de l’une des deux méthodes suivantes :

    • Tirage (pull) Les manifestes sont tirés d’un dépôt et appliqués par un contrôleur s’exécutant dans le cluster. C’est ce que l’on appelle une approche GitOps.
    • Pousser (push). Les manifestes sont envoyés au cluster à l’aide du service d’API Kubernetes et de l’outil en ligne de commande kubectl, à partir d’un pipeline CI/CD ou d’une station de travail locale.

  4. Pour vous assurer que le nouveau cluster fonctionne comme prévu, effectuez des tests et une validation.

  5. Modifiez vos entrées DNS publiques pour qu’elles pointent vers l’adresse IP d’entrée externe du cluster cible (adresse IP d’équilibreur de charge public Azure ou adresse IP publique d’Application Gateway).

  6. Un déploiement utilisant une solution d’équilibrage de charge globale comme Azure DNS ou Azure Traffic Manager doit ajouter la région à la configuration.

Redéployer avec une migration de données

Si vous avez des charges de travail AKS qui utilisent le stockage local, comme des volumes persistants, pour stocker des données ou héberger des services de base de données au sein du cluster, vous pouvez les sauvegarder sur un cluster source et les restaurer sur un cluster cible. Pour savoir comment effectuer une sauvegarde et une restauration, consultez Sauvegarder Azure Kubernetes Service à l’aide d’Azure CLI.

Contenu connexe