Cette page a été traduite par l'API Cloud Translation.

Migrer un cluster d'administrateur vers la haute disponibilité

Ce document explique comment migrer vers un cluster d'administrateur haute disponibilité à partir d'un cluster d'administrateur standard.

1.29: Aperçu
1.28: Non disponible
1.16: Non disponible

Un cluster d'administrateur haute disponibilité comporte trois nœuds de plan de contrôle, mais aucun nœud complémentaire. Un cluster d'administrateur standard dispose d'un nœud de plan de contrôle et de deux nœuds complémentaires.

Présentation de la procédure

Voici les principales étapes d'une migration:

Modifiez le fichier de configuration du cluster d'administrateur.
Exécutez gkectl update admin. Cette commande effectue les opérations suivantes :
- Activez un cluster externe (genre) et assurez-vous que le cluster d'administrateur standard actuel est opérationnel.
- Créez un plan de contrôle de cluster d'administrateur à l'aide d'une spécification haute disponibilité et d'une nouvelle adresse IP virtuelle de plan de contrôle.
- Désactivez le plan de contrôle existant du cluster d'administrateur.
- Prenez un instantané etcd du cluster d'administrateur existant.
- Restaurez les données de l'ancien cluster d'administrateur dans le nouveau plan de contrôle haute disponibilité.
- Rapprochez le cluster d'administrateur restauré pour qu'il réponde à l'état final du cluster d'administrateur haute disponibilité.

Remarques

Pendant la migration, la charge de travail du cluster d'utilisateur n'entraîne aucun temps d'arrêt.
Pendant la migration, le plan de contrôle du cluster d'administrateur présente des temps d'arrêt. (Le temps d'arrêt est inférieur à 18 minutes d'après notre test, mais la durée réelle dépend des environnements d'infrastructure individuels.)
Les exigences relatives aux clusters d'administrateur à haute disponibilité sont toujours valables pour la migration vers la haute disponibilité. Autrement dit, si vous utilisez l'équilibreur de charge Seesaw pour un cluster d'administrateur standard, vous devez d'abord migrer vers MetalLB, puis migrer vers un cluster d'administrateur à haute disponibilité. En effet, un cluster d'administrateur haute disponibilité n'est pas compatible avec Seesaw.
Une fois la migration terminée, il reste des ressources (par exemple, la VM maîtresse d'administration standard) que nous conservons intentionnellement à des fins de reprise après échec. Vous pouvez les nettoyer manuellement si nécessaire.

Avant et après la migration

Voici les principales différences qui existent 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	100 Go x 1	25 Go x 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ée 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, selon network.ipMode.type	3 adresses IP statiques
Attribuer des adresses IP aux nœuds du plan de contrôle du cluster d'utilisateur kubeception	DHCP ou statique, selon network.ipMode.type	DHCP ou statique, selon network.ipMode.type
Fichier de point de contrôle	Activée par défaut	Non utilisées

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 de plan de contrôle du cluster d'administrateur
Une nouvelle adresse IP virtuelle de 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.

Spécifier des adresses IP

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"

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
```
Remplacez la valeur de loadBalancer.vips.controlPlaneVIP par une nouvelle adresse IP virtuelle. Exemple :
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

Mettre à jour les autres champs de configuration

Définissez adminMaster.replicas sur 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Supprimez le champ vCenter.dataDisk. En effet, pour un cluster d'administrateur haute disponibilité, les chemins d'accès des trois disques de données utilisés par les nœuds du plan de contrôle sont automatiquement générés sous le répertoire racine anthos dans le datastore.
Si loadBalancer.manualLB.controlPlaneNodePort a une valeur non nulle, définissez-la sur 0.

Ajuster la configuration manuelle de l'équilibreur de charge

Si votre cluster d'administrateur utilise l'équilibrage de charge manuel, effectuez l'étape décrite dans cette section. Sinon, ignorez cette section.

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

(ancien controlPlaneVIP:443) -> (NOUVELLE_ADRESSE_IP_NODE:ancien controlPlaneNodePort)

Ainsi, l'ancienne adresse IP virtuelle du plan de contrôle fonctionnera pendant la migration.

Mettre à jour le cluster d'administrateur

Lancez 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
La commande affiche la progression de la migration.

Lorsque vous y êtes invité, saisissez Y pour continuer.
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. Pendant ce temps, l'ancienne adresse IP virtuelle du plan de contrôle fonctionne toujours et peut également être utilisée pour accéder au nouveau cluster d'administrateur haute disponibilité.

Nettoyez manuellement les ressources restantes, si nécessaire.

Lors de la migration, gkectl ne supprime pas la VM du plan de contrôle du cluster d'administrateur. Au lieu de cela, il arrête simplement la VM au lieu de la supprimer de vSphere. Si vous souhaitez supprimer l'ancienne VM du plan de contrôle après une migration réussie, vous devez effectuer la suppression manuellement.

Pour supprimer manuellement l'ancienne VM du plan de contrôle et les ressources associées, procédez comme suit:

Assurez-vous que la VM maîtresse administrateur standard gke-admin-master-xxx est déjà désactivée.
Supprimez la VM maîtresse administrateur standard gke-admin-master-xxx de vSphere.
Supprimez le modèle de VM maître administrateur standard gke-admin-master-xxx-tmpl de vSphere.
Supprimez le disque de données administrateur standard et le fichier de point de contrôle administrateur.
Nettoyez les fichiers temporaires enregistrés dans /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Voici les commandes govc si vous préférez utiliser la CLI:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml