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

Migrer un cluster d'utilisateur vers Controlplane V2

Ce document explique comment migrer un cluster d'utilisateurs de la version 1.29 à l'aide de kubeception vers Controlplane V2. Si vos clusters sont en version 1.30 ou ultérieure, nous vous recommandons de suivre les instructions de la section Planifier la migration du cluster vers les fonctionnalités recommandées.

1.29 : Preview
1.28 : Non disponible

À propos des plans de contrôle de cluster utilisateur

Avant la version 1.13 de Google Distributed Cloud, le plan de contrôle d'un cluster d'utilisateur s'exécutait sur un ou plusieurs nœuds d'un cluster d'administrateur. Ce type de plan de contrôle est appelé kubeception. Dans la version 1.13, Controlplane V2 a été introduit pour les nouveaux clusters d'utilisateurs. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'utilisateur lui-même.

Controlplane V2 présente les avantages suivants:

Isolement des défaillances Une défaillance du cluster d'administrateur n'affecte pas les clusters d'utilisateur.
Séparation opérationnelle La mise à niveau d'un cluster d'administrateur n'entraîne pas de temps d'arrêt pour les clusters d'utilisateur.
Séparation des déploiements. Vous pouvez placer les clusters d'administrateur et d'utilisateur dans différents domaines de défaillance ou sites géographiques. Par exemple, un cluster d'utilisateur dans un emplacement périphérique peut se trouver dans un site géographique différent de celui du cluster d'administrateur.

Conditions requises

Pour migrer un cluster d'utilisateurs vers Controlplane V2, le cluster d'utilisateurs doit répondre aux exigences suivantes:

Le cluster utilisateur doit être en version 1.29 ou ultérieure. Le cluster d'administrateur et les pools de nœuds peuvent être une ou deux versions mineures en-dessous du cluster d'utilisateur. Si nécessaire, mettez à niveau le cluster.
Dataplane V2 doit être activé sur le cluster d'utilisateur. Ce champ étant immuable, si Dataplane V2 n'est pas activé sur le cluster, vous ne pouvez pas le migrer vers Controlplane V2.
Le cluster d'utilisateur doit être configuré pour utiliser MetalLB ou un équilibreur de charge manuel. Si le cluster d'utilisateur utilise l'équilibreur de charge Seesaw, vous pouvez le migrer vers MetalLB.
Consultez le document de planification des adresses IP et assurez-vous que vous disposez de suffisamment d'adresses IP disponibles pour les nœuds du plan de contrôle du cluster d'utilisateur. Les nœuds du plan de contrôle nécessitent des adresses IP statiques, et vous aurez besoin d'une adresse IP supplémentaire pour une nouvelle adresse IP virtuelle (VIP) du plan de contrôle.

Préparer la migration

Si le chiffrement permanent des secrets a déjà été activé sur le cluster utilisateur, vous devez suivre la procédure décrite dans Désactiver le chiffrement permanent des secrets et déchiffrer les secrets avant de commencer la migration. Sinon, le nouveau cluster Controlplane V2 ne pourra pas déchiffrer les secrets.

Avant de commencer la migration, exécutez la commande suivante pour vérifier si le chiffrement permanent des secrets a déjà été activé :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Si le résultat de la commande précédente est vide, le chiffrement permanent des secrets n'a jamais été activé. Vous pouvez lancer la migration.

Si le résultat de la commande précédente n'est pas vide, cela signifie que le chiffrement permanent des secrets était précédemment activé. Avant de procéder à la migration, vous devez suivre les étapes de la section suivante pour vous assurer que le nouveau cluster Control-Plane V2 peut déchiffrer les secrets.

L'exemple suivant montre une sortie non vide :

{"generatedKeyVersions":{"keyVersions":[1]}}

Désactiver le chiffrement permanent des secrets et déchiffrer les secrets si nécessaire

Pour désactiver le chiffrement permanent des secrets et déchiffrer les secrets, procédez comme suit :

Dans le fichier de configuration du cluster d'utilisateur, pour désactiver le chiffrement permanent des secrets, ajoutez un champ disabled: true à la section secretsEncryption :
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Mettez à jour le cluster :
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

Effectuez une mise à jour progressive sur un DaemonSet spécifique, comme suit :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Obtenez les fichiers manifestes de tous les secrets du cluster utilisateur au format YAML :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Pour que tous les secrets soient stockés dans etcd en texte brut, réappliquez tous les secrets dans le cluster utilisateur :
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Vous pouvez maintenant commencer la migration vers Control-plane V2. Une fois la migration terminée, vous pouvez réactiver le chiffrement des secrets toujours activé sur le cluster.

Corriger les webhooks de charge de travail mal configurés

Si vous disposez de webhooks incluant des pods système dans l'espace de noms kube-system, ajoutez namespaceSelector pour filtrer l'espace de noms kube-system.

Par exemple,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Mettre à jour le fichier de configuration du cluster utilisateur

Apportez les modifications suivantes au fichier de configuration du cluster utilisateur existant:

Définissez enableControlplaneV2 sur true.
Vous pouvez également rendre le plan de contrôle du cluster d'utilisateurs Controlplane V2 disponibilité élevée (HA). Pour passer d'un cluster non haute disponibilité à un cluster haute disponibilité, remplacez la valeur 1 par 3 pour masterNode.replicas.
Ajoutez l'adresse IP statique (ou les adresses IP statiques) du ou des nœuds du plan de contrôle du cluster d'utilisateur à la section network.controlPlaneIPBlock.ips.
Renseignez le masque de réseau et la passerelle dans la section network.controlPlaneIPBlock.
Si la section network.hostConfig est vide, remplissez-la.
Si le cluster d'utilisateurs utilise l'équilibrage de charge manuel, configurez votre équilibreur de charge comme décrit dans la section suivante.
Si le cluster d'utilisateurs utilise l'équilibrage de charge manuel, définissez loadBalancer.manualLB.controlPlaneNodePort et loadBalancer.manualLB.konnectivityServerNodePort sur 0, car ils ne sont pas requis lorsque Controlplane V2 est activé.
Remplacez le champ loadBalancer.vips.controlPlaneVIP par la nouvelle adresse IP pour l'adresse IP virtuelle du plan de contrôle. Notez qu'il doit se trouver dans le même VLAN que les adresses IP des nœuds du plan de contrôle.
Tous les champs précédents sont immuables, sauf lors de la mise à jour du cluster pour la migration. Veillez à vérifier tous les paramètres.
Exécutez gkectl diagnose cluster et corrigez les problèmes détectés par la commande.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- USER_CLUSTER_NAME : nom du cluster d'utilisateur.

Ajuster la configuration de l'équilibreur de charge manuel

Si votre cluster d'utilisateurs utilise l'équilibrage de charge manuel, suivez la procédure décrite dans cette section. Sinon, ignorez cette section.

Tout comme pour configurer votre équilibreur de charge pour un cluster d'utilisateur CPv2, pour chacune des trois nouvelles adresses IP de plan de contrôle que vous avez spécifiées dans la section network.controlPlaneIPBlock, configurez les mappages dans votre équilibreur de charge :

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Mettre à jour le cluster

Exécutez la commande suivante pour migrer le cluster vers Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

La commande :

Créez le plan de contrôle d'un nouveau cluster avec ControlPlane V2 activé.
Arrêtez le plan de contrôle Kubernetes du cluster kubeception.
Prendre un instantané etcd du cluster kubeception.
Éteignez les nœuds du plan de contrôle du cluster d'utilisateur du cluster kubeception. Notez que pour la reprise après échec (c'est-à-dire le basculement vers le cluster kubeception), les nœuds ne sont pas supprimés tant que la migration n'est pas terminée.
Restaurez les données du cluster dans le nouveau plan de contrôle à l'aide de l'instantané etcd mentionné ci-dessus.
Connectez les nœuds du pool de nœuds du cluster kubeception au nouveau plan de contrôle, accessible avec le nouveau controlPlaneVIP.
Consolidez le cluster d'utilisateur restauré pour qu'il corresponde à l'état final du cluster avec ControlPlane V2 activé.

Remarques

Pendant la migration, il n'y a pas d'interruption de service pour les charges de travail du cluster utilisateur.
Pendant la migration, le plan de contrôle du cluster d'utilisateur est indisponible pendant quelques minutes. Plus précisément, le plan de contrôle n'est pas disponible entre l'étape 2 et la fin de l'étape 6. (Le temps d'arrêt est inférieur à sept minutes, d'après nos tests, mais la durée réelle dépend de votre infrastructure.)
À la fin de la migration, les nœuds du plan de contrôle du cluster d'utilisateur des clusters kubeception sont supprimés. Si network.ipMode.type est défini sur "static" pour le cluster d'administrateur, vous pouvez recycler certaines des adresses IP statiques inutilisées en les supprimant du fichier de configuration du cluster d'administrateur, puis en exécutant gkectl update admin. Vous pouvez lister les objets de nœud du cluster d'administration avec kubectl get nodes -o wide pour voir quelles adresses IP sont utilisées.

Après la migration

Si vous avez désactivé le chiffrement permanent des secrets avant la migration, procédez comme suit pour réactiver la fonctionnalité :

Dans le fichier de configuration du cluster utilisateur, définissez secretsEncryption.generatedKey.disabled sur "false". Par exemple :
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Mettez à jour le cluster d'utilisateur :

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG