Migrer un cluster d'administrateur vers un cluster haute disponibilité

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment migrer vers un cluster d'administrateur haute disponibilité (HD) à partir d'un cluster d'administrateur standard de la version 1.29.

Remarque : Si vos clusters sont à la version 1.30 ou ultérieure, nous vous recommandons d'utiliser l'approche simplifiée décrite dans la section Planifier la migration du cluster vers les fonctionnalités recommandées.

1.29 : Aperçu
1.28 : Non disponible

Avant et après la migration, le cluster d'administration comporte trois nœuds :

• Un cluster d'administrateur standard comporte un nœud de plan de contrôle et deux nœuds complémentaires.
• Un cluster d'administrateur HD comporte trois nœuds de plan de contrôle et aucun nœud de module complémentaire, et la disponibilité est considérablement améliorée.

Préparer la migration

Si la version de votre cluster d'administrateur est 1.29.0-1.29.600 ou 1.30.0-1.30.100, et si le chiffrement permanent des secrets était activé dans le cluster d'administrateur à la version 1.14 ou antérieure, vous devez changer la clé de chiffrement avant de commencer la migration. Sinon, le nouveau cluster d'administrateur HD ne pourra pas déchiffrer les secrets.

Pour vérifier si le cluster utilise une ancienne clé de chiffrement, procédez comme suit :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Si le résultat affiche une clé vide, comme dans l'exemple suivant, vous devez effectuer une rotation de la clé de chiffrement.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Effectuer une rotation de clé de chiffrement si nécessaire

Si les étapes de la section précédente ont montré que vous devez faire tourner la clé de chiffrement, procédez comme suit :

1. Augmentez la valeur de keyVersion dans le fichier de configuration du cluster d'administrateur.

2. Mettez à jour le cluster d'administrateur :

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   Cette opération crée une clé correspondant au nouveau numéro de version, rechiffre chaque secret et efface l'ancien. Tous les nouveaux secrets sont chiffrés à l'aide de la nouvelle clé de chiffrement.

Avertissement : Si vous avez commencé la migration sans changer la clé de chiffrement, contactez l'assistance Google.

Présentation de la procédure

La migration implique les étapes principales suivantes :

1. Modifiez le fichier de configuration du cluster d'administration.

2. Exécutez gkectl update admin. Cette commande effectue les opérations suivantes :

   • Affiche un cluster externe (Kind) et s'assure que le cluster d'administrateur standard actuel est opérationnel.

   • Crée un plan de contrôle de cluster d'administrateur à l'aide de la spécification HD et d'une nouvelle adresse IP virtuelle de plan de contrôle.

   • Désactive le plan de contrôle du cluster d'administrateur existant.

   • Prend un instantané etcd du cluster d'administrateur existant.

   • Restaure les anciennes données du cluster d'administrateur dans le nouveau plan de contrôle à haute disponibilité.

   • Réconcilie le cluster d'administrateur restauré pour qu'il corresponde à l'état final du cluster d'administrateur à haute disponibilité.

Remarques

• Pendant la migration, il n'y a pas d'interruption de service pour la charge de travail du cluster d'utilisateur.

• Pendant la migration, le plan de contrôle du cluster d'administrateur est indisponible pendant quelques instants. (Le temps d'arrêt est inférieur à 18 minutes, d'après nos tests, mais la durée réelle dépend des environnements d'infrastructure individuels.)

• Les exigences concernant les clusters d'administrateur HD s'appliquent toujours pour la migration d'un cluster standard vers un cluster HD. Par exemple, les clusters d'administrateur HD ne sont pas compatibles avec Seesaw. Par conséquent, si vous utilisez l'équilibreur de charge Seesaw pour un cluster d'administrateur standard, vous devez d'abord migrer vers MetalLB avant de migrer vers un cluster d'administrateur HD.

• Une fois la migration terminée, les ressources restantes, telles que la VM principale d'administration standard, sont conservées intentionnellement pour le rétablissement en cas d'échec.

Avant et après la migration

Le tableau suivant présente les principales différences dans le cluster avant et après la migration :

	Avant la migration	Après la migration
Instances dupliquées du nœud du plan de contrôle	1	3
Nœuds complémentaires	2	0
Instances répliquées de pods du plan de contrôle (kube-apiserver, kube-etcd, etc.)	1	3
Taille du disque de données	100Go * 1	25Go * 3
Chemin d'accès aux disques de données	Défini par vCenter.dataDisk dans le fichier de configuration du cluster d'administrateur	Généré automatiquement dans le répertoire /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Équilibreur de charge pour l'adresse IP virtuelle du plan de contrôle	Défini par loadBalancer.kind dans le fichier de configuration du cluster d'administrateur	keepalived + haproxy
Allocation d'adresses IP pour les nœuds du plan de contrôle du cluster d'administrateur	DHCP ou statique, en fonction de network.ipMode.type	3 adresses IP statiques
Allocation d'adresses IP pour les nœuds de plan de contrôle du cluster d'utilisateur kubeception	DHCP ou statique, en fonction de network.ipMode.type	DHCP ou statique, en fonction de network.ipMode.type
Fichier de point de contrôle	Activée par défaut	Non utilisé

Modifier le fichier de configuration du cluster d'administrateur

Vous devez spécifier quatre adresses IP supplémentaires :

• Trois adresses IP pour les nœuds du plan de contrôle du cluster d'administrateur
• Une nouvelle adresse IP virtuelle du plan de contrôle pour l'équilibreur de charge du cluster d'administrateur

Vous devez également modifier quelques autres champs dans le fichier de configuration de votre cluster d'administrateur, comme décrit dans les sections suivantes.

Spécifier des adresses IP

1. Dans le fichier de configuration du cluster d'administrateur, remplissez la section network.controlPlaneIPBlock. Exemple :

   controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    – ip: "172.16.20.50"
      hostname: "admin-cp-node-1"
    – ip: "172.16.20.51"
      hostname: "admin-cp-node-2"
    – ip: "172.16.20.52"
      hostname: "admin-cp-node-3"
   

2. Remplissez la section hostconfig. Si votre cluster d'administrateur utilise des adresses IP statiques, cette section est déjà remplie. Exemple :

   hostConfig:
    dnsServers:
    – 203.0.113.1
    – 198.51.100.1
    ntpServers:
    – 216.239.35.12
   

3. Remplacez la valeur de loadBalancer.vips.controlPlaneVIP par une nouvelle IP virtuelle. Exemple :

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Mettre à jour d'autres champs de configuration

1. Définissez adminMaster.replicas sur 3 :

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Supprimez le champ vCenter.dataDisk. Pour un cluster d'administrateur HD, les chemins d'accès aux trois disques de données utilisés par les nœuds du plan de contrôle sont générés automatiquement sous le répertoire racine anthos dans le datastore.

3. Si loadBalancer.manualLB.controlPlaneNodePort a une valeur non nulle, définissez-la sur 0.

Ajuster la configuration de l'équilibreur de charge manuel

Si votre cluster d'administrateur utilise l'équilibrage de charge manuel, suivez cette section. Sinon, ignorez cette section.

Pour chacune des trois nouvelles adresses IP de nœud du plan de contrôle que vous avez spécifiées dans la section network.controlPlaneIPBlock, configurez le mappage suivant dans votre équilibreur de charge :

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Ce mappage garantit que l'ancienne adresse IP virtuelle du plan de contrôle fonctionne pendant la migration.

Mettez à jour le cluster d'administrateur

Examinez les modifications de configuration que vous avez apportées, car les champs sont immuables. Une fois que vous avez confirmé que les modifications sont correctes, mettez à jour le cluster.

1. Lancer la migration :

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

   • ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

2. La commande affiche la progression de la migration.

   Lorsque vous y êtes invité, saisissez Y pour continuer.

3. Une fois la migration terminée, le fichier kubeconfig du cluster d'administrateur est automatiquement mis à jour pour utiliser la nouvelle adresse IP virtuelle du plan de contrôle. L'ancienne adresse IP virtuelle du plan de contrôle continue de fonctionner et peut également être utilisée pour accéder au nouveau cluster d'administrateur à haute disponibilité.