Cette page fournit des informations et des recommandations qui vous aideront à migrer des charges de travail depuis des clusters Google Kubernetes Engine (GKE) standards vers des clusters Autopilot avec une interruption minimale de vos services. Cette page est destinée aux administrateurs de cluster qui ont déjà décidé de migrer vers Autopilot. Si vous avez besoin d'informations supplémentaires avant de décider de migrer, consultez les pages Choisir un mode d'opération GKE et Comparer GKE Autopilot et standard.
Fonctionnement de la migration
Les clusters en mode Autopilot automatisent de nombreuses fonctionnalités facultatives qui nécessitent une configuration manuelle dans les clusters en mode standard. De plus, les clusters Autopilot appliquent des configurations par défaut des applications plus sécurisées afin de fournir un environnement davantage prêt pour la production et de réduire les coûts de gestion requis par rapport au mode standard. Les clusters Autopilot appliquent par défaut de nombreuses bonnes pratiques et recommandations de GKE. Autopilot utilise un modèle de configuration centré sur la charge de travail qui vous permet de demander ce dont vous avez besoin dans vos fichiers manifestes Kubernetes, et GKE provisionne l'infrastructure correspondante.
Lorsque vous migrez vos charges de travail standards vers Autopilot, vous devez préparer vos fichiers manifestes de charge de travail pour vous assurer qu'elles sont compatibles avec des clusters Autopilot, par exemple en veillant à ce que vos fichiers manifestes demandent l'infrastructure que vous auriez normalement à provisionner vous-même.
Pour préparer et exécuter une migration réussie, vous devez effectuer les tâches de premier niveau suivantes :
- Exécutez une vérification préliminaire sur votre cluster standard existant pour confirmer la compatibilité avec Autopilot.
- Le cas échéant, modifiez vos fichiers manifestes de charge de travail pour qu'ils soient compatibles avec Autopilot.
- Faites une simulation pour vérifier que vos charges de travail fonctionnent correctement avec Autopilot.
- Planifiez et créez le cluster Autopilot.
- Le cas échéant, mettez à jour vos outils d'infrastructure en tant que code.
- Effectuez la migration.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update.
- Assurez-vous de disposer d'un cluster standard avec des charges de travail en cours d'exécution.
- Assurez-vous de disposer d'un cluster Autopilot sans charge de travail pour effectuer des simulations. Pour créer un cluster Autopilot, consultez la page Créer un cluster Autopilot.
Exécuter une vérification préliminaire sur votre cluster standard
Google Cloud CLI et l'API Google Kubernetes Engine fournissent un outil de vérification préliminaire qui valide les spécifications de vos charges de travail standards en cours d'exécution afin d'identifier les incompatibilités avec les clusters Autopilot. Cet outil est disponible dans GKE 1.26 et versions ultérieures.
- Pour utiliser cet outil dans la ligne de commande, exécutez la commande suivante :
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Remplacez CLUSTER_NAME par le nom de votre cluster standard. Vous pouvez également ajouter --format=json à cette commande pour obtenir le résultat dans un fichier JSON.
La sortie contient les résultats de toutes vos charges de travail standards en cours d'exécution, catégorisées et avec des recommandations exploitables pour garantir la compatibilité avec Autopilot, le cas échéant. Le tableau suivant décrit les catégories :
| Résultats de l'outil de vérification préliminaire | |
|---|---|
Passed |
La charge de travail s'exécute comme prévu sans configuration requise pour Autopilot. |
Passed with optional configuration |
La charge de travail s'exécute sur Autopilot, mais vous pouvez apporter des modifications de configuration facultatives pour optimiser l'expérience. Si vous n'apportez aucune modification à la configuration, Autopilot applique automatiquement la configuration par défaut. Par exemple, si votre charge de travail s'exécutait sur des machines N2 en mode standard, GKE applique la classe de calcul à usage général pour Autopilot. Vous pouvez éventuellement modifier la charge de travail pour demander la classe de calcul équilibrée qui s'appuie sur des machines N2. |
Additional configuration required |
La charge de travail ne s'exécutera pas sur Autopilot à moins que vous ne modifiiez la configuration. Prenons l'exemple d'un conteneur qui utilise la fonctionnalité NET_ADMIN en mode standard. Autopilot supprime par défaut cette fonctionnalité pour plus de sécurité. Vous devez donc activer NET_ADMIN sur le cluster avant de déployer la charge de travail. |
Incompatibility |
La charge de travail ne s'exécute pas sur Autopilot, car elle utilise une fonctionnalité non compatible avec Autopilot. Par exemple, les clusters Autopilot rejettent des pods privilégiés ( |
Modifier les spécifications de votre charge de travail en fonction des résultats de la vérification préliminaire
Après avoir exécuté la vérification préliminaire, parcourez les résultats JSON et identifiez les charges de travail à modifier. Nous vous recommandons d'implémenter aussi les recommandations de configuration facultatives. Chaque résultat fournit également un lien vers la documentation qui vous montre à quoi la spécification de la charge de travail doit ressembler.
La principale différence entre Autopilot et standard est que la configuration de l'infrastructure dans Autopilot est automatisée en fonction de la spécification de la charge de travail. Les contrôles de planification Kubernetes, tels que les tolérances et les rejets de nœuds, sont automatiquement ajoutés à vos charges de travail en cours d'exécution. Si nécessaire, vous devez également modifier vos configurations d'Infrastructure as Code, telles que des graphiques Helm ou des superpositions Kustomize, pour qu'elles correspondent.
Voici quelques modifications courantes que vous devez apporter à la configuration :
| Modifications de configuration courantes pour Autopilot | |
|---|---|
| Configuration de calcul et d'architecture | Les clusters Autopilot utilisent le type de machine Série E par défaut. Si vous avez besoin d'autres types de machines, la spécification de votre charge de travail doit demander une classe de calcul, qui indique à Autopilot de placer ces pods sur des nœuds utilisant des types de machines ou des architectures spécifiques. Pour en savoir plus, consultez la page Classes de calcul dans Autopilot. |
| Accélérateurs | Les charges de travail basées sur les GPU doivent demander des GPU dans la spécification de la charge de travail. Autopilot provisionne automatiquement les nœuds avec le type de machine et les accélérateurs requis. Pour en savoir plus, consultez la page Déployer des charges de travail GPU dans Autopilot. |
| Demandes de ressources | Toutes les charges de travail Autopilot doivent spécifier des valeurs pour Pour en savoir plus, consultez la section Demandes de ressources dans Autopilot. |
| Charges de travail tolérantes aux pannes sur les VM Spot | Si vos charges de travail s'exécutent sur des VM Spot en mode standard, demandez des pods Spot dans la configuration de la charge de travail en définissant un sélecteur de nœud pour Pour en savoir plus, consultez la section Pods Spot. |
Effectuer une simulation sur un cluster Autopilot de préproduction
Après avoir modifié chaque fichier manifeste de charge de travail, effectuez un déploiement de simulation sur un nouveau cluster de préproduction Autopilot pour vous assurer que la charge de travail s'exécute comme prévu.
Ligne de commande
Exécutez la commande suivante :
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Remplacez PATH_TO_MANIFEST par le chemin d'accès au fichier manifeste de la charge de travail modifiée.
IDE
Si vous utilisez l'éditeur Cloud Shell, la commande de simulation est intégrée et s'exécute sur tous les fichiers manifestes ouverts. Si vous utilisez des IDE Visual Studio Code ou Intellij, installez l'extension Cloud Code pour exécuter automatiquement la simulation sur tous les fichiers manifestes ouverts.
Le volet Problèmes de l'IDE affiche les problèmes de simulation, comme dans l'image suivante, qui montre une simulation d'échec pour un fichier manifeste qui spécifie privileged: true.
Planifier le cluster Autopilot de destination
Lorsque votre simulation n'affiche plus de problèmes, planifiez et créez le cluster Autopilot pour vos charges de travail. Ce cluster est différent du cluster Autopilot que vous avez utilisé pour tester vos modifications manifestes dans la section précédente.
Suivez les bonnes pratiques pour l'intégration à GKE afin de connaître les exigences de configuration de base. Consultez ensuite la présentation d'Autopilot, qui fournit des informations spécifiques à votre cas d'utilisation sur différents niveaux.
En outre, tenez compte des points suivants :
- Les clusters Autopilot sont des clusters de VPC natif. Nous vous déconseillons donc de migrer vers Autopilot à partir de clusters standards basés sur le routage.
- Utilisez le même VPC ou un VPC similaire pour le cluster Autopilot et le cluster standard, y compris les règles de pare-feu personnalisées et les paramètres VPC.
- Les clusters Autopilot utilisent GKE Dataplane V2 et ne sont compatibles qu'avec Cilium NetworkPolicies. Les règles de réseau Calico ne sont pas compatibles.
- Si vous souhaitez utiliser le masquage d'adresses IP dans Autopilot, utilisez une règle NAT de sortie.
- Si vous disposez d'un cluster standard privé, créez un cluster Autopilot privé avec des paramètres d'isolation similaires.
- Spécifiez la plage IPv4 principale du cluster lors de sa création, avec la même taille de plage que le cluster standard.
- Consultez les différences de quotas entre les modes, en particulier si vous disposez de clusters volumineux.
- Consultez les valeurs maximales des pods par nœud pour Autopilot, qui sont différentes de la version standard. Ce point est important si vous utilisez souvent l'affinité de nœuds ou de pods.
- Tous les clusters Autopilot utilisent Cloud DNS.
Créer le cluster Autopilot
Lorsque vous êtes prêt à créer le cluster, utilisez l'option Créer un cluster Autopilot. Tous les clusters Autopilot sont régionaux et sont automatiquement enregistrés dans une version disponible. Toutefois, vous pouvez spécifier le canal et la version du cluster. Nous vous recommandons de déployer un petit exemple de charge de travail sur le cluster afin de déclencher le provisionnement automatique des nœuds, de sorte que vos charges de travail de production puissent être planifiées immédiatement.
Mettre à jour vos outils d'Infrastructure as Code
Les fournisseurs d'Infrastructure as Code suivants sont compatibles avec Autopilot :
Consultez la documentation du fournisseur de votre choix et modifiez vos configurations.
Choisir une approche de migration
La méthode de migration que vous utilisez dépend de votre charge de travail individuelle et de votre maîtrise des concepts de mise en réseau comme les Services multiclusters et l'Ingress Imulticluster, ainsi que de la gestion de l'état des objets Kubernetes dans votre cluster.
| Type de charge de travail | Résultats de l'outil de vérification préliminaire | Approche de la migration |
|---|---|---|
| Sans état |
|
Pour les charges de travail |
| Avec état |
|
Pour ce faire, utilisez une des méthodes suivantes :
|
| Configuration supplémentaire requise | Mettez à jour vos fichiers manifestes Kubernetes et redéployez votre application sur Autopilot pendant les temps d'arrêt planifiés. Pour connaître les étapes générales, consultez la page Migrer manuellement des charges de travail avec état. |
Procédure générale de migration
Avant de commencer une migration, assurez-vous d'avoir résolu tous les résultats Incompatible ou Additional configuration required de la vérification préliminaire. Si vous déployez des charges de travail avec ces résultats sur Autopilot sans modification, les charges de travail échoueront.
Les sections suivantes offrent une vue d'ensemble d'une migration hypothétique. Les étapes réelles varient en fonction de votre environnement et de chacune de vos charges de travail. Planifiez, testez et retestez les charges de travail avant de migrer un environnement de production. Points à prendre en compte :
- La durée du processus de migration dépend du nombre de charges de travail à migrer.
- Les temps d'arrêt sont requis lors de la migration des charges de travail avec état.
- La migration manuelle vous permet de vous concentrer sur les charges de travail individuelles pendant la migration afin de résoudre les problèmes en temps réel au cas par cas.
- Dans tous les cas, veillez à migrer les services, les Ingress et d'autres objets Kubernetes qui facilitent les fonctionnalités de vos charges de travail sans état et avec état.
Migrer toutes les charges de travail à l'aide de Sauvegarde pour GKE
Si toutes les charges de travail (avec état et sans état) exécutées dans votre cluster standard sont compatibles avec Autopilot et que l'outil de vérification préliminaire renvoie Passed ou Passed with optional configuration pour chaque charge de travail, vous pouvez utiliser Sauvegarde pour GKE pour sauvegarder l'intégralité de l'état de votre cluster standard et de vos charges de travail, puis restaurer la sauvegarde sur le cluster Autopilot.
Cette approche présente les avantages suivants :
- Vous pouvez déplacer toutes les charges de travail de l'opération Standard à l'opération Autopilot avec une configuration minimale.
- Vous pouvez déplacer des charges de travail sans état et avec état, et conserver les relations entre les charges de travail ainsi que les ressources PersistentVolume associées.
- Les rollbacks sont intuitifs et gérés par Google. Vous pouvez effectuer un rollback de l'ensemble de la migration ou effectuer un rollback sélectif de charges de travail spécifiques.
- Vous pouvez migrer des charges de travail avec état dans plusieurs régions Google Cloud. La migration manuelle des charges de travail avec état ne peut s'effectuer que dans la même région.
Lorsque vous utilisez cette méthode, GKE applique les configurations Autopilot par défaut aux charges de travail qui ont reçu un résultat Passed with optional configuration de l'outil de vérification préliminaire. Avant de migrer ces charges de travail, assurez-vous de maîtriser ces valeurs par défaut.
Migrer des charges de travail sans état manuellement sans temps d'arrêt
Pour migrer des charges de travail sans état sans temps d'arrêt pour vos services, enregistrez les clusters source et de destination dans un parc GKE, et utilisez les Services multiclusters et Ingress multicluster pour vous assurer que vos charges de travail restent disponibles pendant la migration.
- Activez les Services multiclusters et Ingress multicluster pour votre cluster source et votre cluster de destination. Pour obtenir les instructions correspondantes, consultez les sections Configurer des Services multiclusters et Configurer un Ingress multicluster.
- Si vous avez des dépendances backend, telles qu'une charge de travail de base de données, exportez ces services de votre cluster standard à l'aide de Services multiclusters. Cela permet aux charges de travail de votre cluster Autopilot d'accéder aux dépendances du cluster standard. Pour obtenir des instructions, consultez la page Enregistrer un Service pour l'exportation.
- Déployez un Ingress multicluster et un Service multicluster pour contrôler le trafic entrant entre les clusters. Configurez le Service multicluster pour n'envoyer du trafic que vers le cluster standard. Pour obtenir des instructions, consultez la page Déployer Ingress sur plusieurs clusters.
- Déployez vos charges de travail sans état avec des fichiers manifestes mis à jour sur le cluster Autopilot. Vos Services multiclusters exportés correspondent et envoient automatiquement le trafic aux charges de travail avec état correspondantes.
- Mettez à jour votre Service multicluster pour diriger le trafic entrant vers le cluster Autopilot. Pour obtenir des instructions, consultez la page Sélection des clusters.
Vous diffusez maintenant vos charges de travail sans état à partir du cluster Autopilot. Si vous n'avez que des charges de travail sans état dans le cluster source et qu'il ne reste aucune dépendance, passez à la section Terminer la migration. Si vous avez des charges de travail avec état, passez à la section Migrer manuellement des charges de travail avec état.
Migrer des charges de travail avec état manuellement
Après avoir migré vos charges de travail sans état, vous devez suspendre et migrer vos charges de travail avec état à partir du cluster standard. Cette étape nécessite un temps d'arrêt pour votre cluster.
- Démarrez le temps d'arrêt pour votre environnement.
- Suspendez vos charges de travail avec état.
- Assurez-vous de modifier vos fichiers manifestes de charge de travail pour la compatibilité avec Autopilot. Pour en savoir plus, consultez la section Modifier vos spécifications de charge de travail en fonction des résultats de la vérification préliminaire.
Déployez les charges de travail sur votre cluster Autopilot.
Déployez les Services pour vos charges de travail avec état sur le cluster Autopilot.
Mettez à jour le réseau de votre cluster pour permettre à vos charges de travail sans état de communiquer avec leurs charges de travail backend :
- Si vous avez utilisé une adresse IP statique dans les services de backend de cluster standard, réutilisez-la dans Autopilot.
- Si vous autorisez Kubernetes à attribuer une adresse IP, déployez vos services de backend, obtenez la nouvelle adresse IP et mettez à jour votre DNS pour qu'il utilise la nouvelle adresse IP.
À ce stade, les conditions suivantes doivent être remplies :
- Vous exécutez toutes vos charges de travail sans état dans Autopilot.
- Toutes les charges de travail backend avec état s'exécutent également dans Autopilot.
- Vos charges de travail sans état et avec état peuvent communiquer entre elles.
- Votre Service multicluster dirige tout le trafic entrant vers votre cluster Autopilot.
Une fois que vous avez migré toutes les charges de travail et tous les objets Kubernetes vers le nouveau cluster, passez à la section Terminer la migration.
Autre solution : migrer manuellement toutes les charges de travail pendant les temps d'arrêt
Si vous ne souhaitez pas utiliser de Services multiclusters et d'Ingress multicluster pour migrer des charges de travail avec un temps d'arrêt minimal, migrez toutes vos charges de travail pendant les temps d'arrêt. Cette méthode entraîne des temps d'arrêt plus longs pour vos services, mais ne nécessite pas d'utiliser des fonctionnalités multicluster.
- Démarrez un temps d'arrêt.
- Déployer vos fichiers manifestes sans état sur le cluster Autopilot.
- Migrez manuellement vos charges de travail avec état. Pour savoir comment procéder, consultez la section Migrer manuellement des charges de travail avec état.
- Modifiez les enregistrements DNS du trafic externe entrant et du trafic interne au cluster pour utiliser les nouvelles adresses IP des Services.
- Mettez fin à votre temps d'arrêt.
Terminer la migration
Après avoir déplacé toutes vos charges de travail et vos Services vers le nouveau cluster Autopilot, mettez fin à votre temps d'arrêt et laissez votre environnement se stabiliser pendant une durée prédéterminée. Lorsque vous êtes satisfait de l'état de la migration et que vous êtes certain de ne pas avoir besoin d'effectuer un rollback, vous pouvez nettoyer les artefacts de migration et terminer la migration.
Facultatif : nettoyer les fonctionnalités multicluster
Si vous avez utilisé l'Ingress multicluster et les Services multiclusters pour migrer, et que vous ne souhaitez pas que votre cluster Autopilot reste enregistré dans un parc, procédez comme suit :
- Pour le trafic externe entrant, déployez un Ingress et définissez-le sur l'adresse IP des Services qui exposent vos charges de travail. Pour obtenir des instructions, consultez la page Ingress pour les équilibreurs de charge d'application externes.
- Pour le trafic interne au cluster, par exemple les charges de travail d'interface vers les dépendances avec état, mettez à jour les enregistrements DNS du cluster pour utiliser les adresses IP des Services.
- Supprimez les ressources Ingress multicluster et Service multicluster que vous avez créées lors de la migration.
- Désactiver les Services Ingress multiclusters et Ingress multicluster
- Annuler l'enregistrement du cluster Autopilot à partir du parc.
Supprimer le cluster standard
Une fois qu'un délai suffisant s'est écoulé après la fin de la migration et que vous êtes satisfait de l'état de votre nouveau cluster, supprimez le cluster standard. Nous vous recommandons de conserver vos fichiers manifestes standards sauvegardés.
Effectuer le rollback d'une migration défaillante
Si vous rencontrez des problèmes et souhaitez revenir au cluster standard, effectuez l'une des opérations suivantes, selon la manière dont vous avez effectué la migration :
Si vous avez utilisé Sauvegarde pour GKE pour créer des sauvegardes pendant la migration, restaurez les sauvegardes sur le cluster standard d'origine. Pour obtenir des instructions, consultez la section Restaurer une sauvegarde.
Si vous avez migré manuellement des charges de travail, répétez les étapes de migration dans les sections précédentes avec le cluster standard en tant que destination et le cluster Autopilot en tant que source. En règle générale, vous devez suivre les étapes ci-dessous :
- Démarrez un temps d'arrêt.
- Migrez manuellement des charges de travail avec état vers le cluster standard. Pour savoir comment procéder, consultez la section Migrer manuellement des charges de travail avec état.
- Déplacez les charges de travail sans état vers le cluster standard à l'aide des fichiers manifestes d'origine que vous avez sauvegardés avant la migration.
- Déployez votre Ingress sur le cluster standard et basculez vos DNS vers les nouvelles adresses IP pour les services.
- Supprimez le cluster Autopilot.
Étapes suivantes
- Planifier des demandes de ressources Autopilot
- Configurer la surveillance
- Configurer et utiliser le tableau de bord de stratégie de sécurité