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 et aucun nœud complémentaire. Un cluster d'administrateur standard comporte un nœud de plan de contrôle et 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 :
- Affichez un cluster externe (kind) et assurez-vous que le cluster d'administrateur standard actuel est dans un état opérationnel.
- Créez un plan de contrôle de cluster d'administrateur à l'aide de la spécification haute disponibilité et d'une nouvelle adresse IP virtuelle de plan de contrôle.
- Désactivez le plan de contrôle du cluster d'administrateur existant.
- Prenez un instantané etcd du cluster d'administrateur existant.
- Restaurez les anciennes données du cluster d'administrateur dans le nouveau plan de contrôle haute disponibilité.
- Rapprochez le cluster d'administrateur restauré pour atteindre l'état final du cluster d'administrateur haute disponibilité.

Remarques

La charge de travail du cluster d'utilisateur n'entraîne aucun temps d'arrêt pendant la migration.
Lors de la migration, le plan de contrôle du cluster d'administrateur entraîne un temps d'arrêt. (D'après notre test, le temps d'arrêt est inférieur à 18 minutes, mais sa durée réelle dépend des environnements d'infrastructure individuels.)
Les conditions requises pour les clusters d'administrateur haute disponibilité restent valables pour une migration standard vers 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'administrateur standard) que nous avons volontairement conservées à 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 entre 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é 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	Trois adresses IP statiques
Allocation d'adresses IP pour les nœuds du plan de contrôle kubeception du cluster d'utilisateur	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é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 du plan de contrôle du cluster d'administrateur
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, renseignez 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 champs de configuration supplémentaires

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 du 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 du 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) -> (NEW_NODE_IP_ADDRESS:ancien controlPlaneNodePort)

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

Mettre à jour le cluster d'administrateur

Démarrez 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:

Assurez-vous que la VM maître administrateur administrateur standard gke-admin-master-xxx est déjà mise hors tension.
Supprimez la VM maître administrateur administrateur standard gke-admin-master-xxx de vSphere.
Supprimez le modèle de VM maître administrateur pour les administrateurs standards gke-admin-master-xxx-tmpl de vSphere.
Supprimez le disque de données d'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