Problèmes connus de Google Distributed Cloud (logiciel uniquement) pour VMware

Secrets toujours chiffrés après la désactivation du chiffrement permanent des secrets

Après avoir désactivé le chiffrement des secrets toujours activé avec gkectl update cluster, les secrets sont toujours stockés dans etcd avec chiffrement. Ce problème ne concerne que les clusters d'utilisateur kubeception. Si votre cluster utilise Controlplane V2, ce problème ne vous concerne pas.

Pour vérifier si les secrets sont toujours chiffrés, exécutez la commande suivante, qui récupère le secret default/private-registry-creds stocké dans etcd :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    exec -it -n USER_CLUSTER_NAME kube-etcd-0 -c kube-etcd -- \
    /bin/sh -ec "export ETCDCTL_API=3; etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt \
    --key=/etcd.local.config/certificates/etcd.key \
    get /registry/secrets/default/private-registry-creds" | hexdump -C

Si le secret est stocké avec chiffrement, le résultat ressemble à ce qui suit :

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 3a 65 6e  63 3a 6b 6d 73 3a 76 31  |..k8s:enc:kms:v1|
00000040  3a 67 65 6e 65 72 61 74  65 64 2d 6b 65 79 2d 6b  |:generated-key-k|
00000050  6d 73 2d 70 6c 75 67 69  6e 2d 31 3a 00 89 65 79  |ms-plugin-1:..ey|
00000060  4a 68 62 47 63 69 4f 69  4a 6b 61 58 49 69 4c 43  |JhbGciOiJkaXIiLC|
...

Si le secret n'est pas stocké avec chiffrement, le résultat ressemble à ce qui suit :

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 70 72 69 76 61 74  |s/default/privat|
00000020  65 2d 72 65 67 69 73 74  72 79 2d 63 72 65 64 73  |e-registry-creds|
00000030  0d 0a 6b 38 73 00 0d 0a  0c 0d 0a 02 76 31 12 06  |..k8s.......v1..|
00000040  53 65 63 72 65 74 12 83  47 0d 0a b0 2d 0d 0a 16  |Secret..G...-...|
00000050  70 72 69 76 61 74 65 2d  72 65 67 69 73 74 72 79  |private-registry|
00000060  2d 63 72 65 64 73 12 00  1a 07 64 65 66 61 75 6c  |-creds....defaul|
...

Solution :

1. 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
       

2. 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
       

3. Réappliquez tous les secrets dans le cluster utilisateur pour que tous les secrets soient stockés dans etcd en texte brut :

       kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
         apply -f SECRETS_MANIFEST.yaml
       

Le champ hostgroups est manquant dans le fichier user-cluster.yaml généré

Le fichier de configuration du cluster d'utilisateur, user-cluster.yaml, généré par la commande gkectl get-config, ne comporte pas le champ hostgroups dans la section nodePools. La commande gkectl get-config génère le fichier user-cluster.yaml en fonction du contenu de la ressource personnalisée OnPremUserCluster. Toutefois, le champ nodePools[i].vsphere.hostgroups existe dans la ressource personnalisée OnPremNodePool et n'est pas copié dans le fichier user-cluster.yaml lorsque vous exécutez gkectl get-config.

Solution

Pour résoudre ce problème, ajoutez manuellement le champ nodePools[i].vsphere.hostgroups au fichier user-cluster.yaml. Le fichier modifié doit ressembler à l'exemple suivant :

apiVersion: v1
kind: UserCluster
...
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
  replicas: 3
  vsphere:
    hostgroups:
    - "hostgroup-1"
...

Vous pouvez utiliser le fichier de configuration de cluster d'utilisateur modifié pour mettre à jour votre cluster d'utilisateur sans déclencher d'erreurs. Le champ hostgroups est conservé.

L'entrée groupée n'est pas compatible avec les ressources gateway.networking.k8s.io

Les pods Istiod de l'entrée groupée ne peuvent pas être prêts si les ressources gateway.networking.k8s.io sont installées dans le cluster d'utilisateur. Le message d'erreur suivant peut être trouvé dans les journaux de pod :

    failed to list *v1beta1.Gateway: gateways.gateway.networking.k8s.io is forbidden: User \"system:serviceaccount:gke-system:istiod-service-account\" cannot list resource \"gateways\" in API group \"gateway.networking.k8s.io\" at the cluster scope"
    

Solution :

Appliquez les ClusterRole et ClusterRoleBinding suivants à votre cluster d'utilisateur :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: istiod-gateway
rules:
- apiGroups:
  - 'gateway.networking.k8s.io'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: istiod-gateway-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istiod-gateway
subjects:
- kind: ServiceAccount
  name: istiod-service-account
  namespace: gke-system
    

Les nœuds du plan de contrôle du cluster d'administrateur redémarrent sans cesse après l'exécution de gkectl create admin

Si les noms d'hôte du champ ipblocks contiennent des lettres majuscules, les nœuds du plan de contrôle du cluster d'administrateur peuvent redémarrer sans cesse.

Solution :

N'utilisez que des noms d'hôte en minuscules.

Runtime: out of memory "error" après l'exécution de gkeadm create ou upgrade

Lorsque vous créez ou mettez à niveau des postes de travail administrateur avec des commandes gkeadm, une erreur OOM peut s'afficher lors de la vérification de l'image OS téléchargée.

Par exemple,

Downloading OS image
"gs://gke-on-prem-release/admin-appliance/1.30.400-gke.133/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova"...

[==================================================>] 10.7GB/10.7GB

Image saved to
/anthos/gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova

Verifying image gke-on-prem-admin-appliance-vsphere-1.30.400-gke.133.ova...
|

runtime: out of memory

Solution :

Mise à niveau d'un cluster d'administrateur non HD bloquée à Creating or updating cluster control plane workloads

Lors de la mise à niveau d'un cluster d'administrateur non HD, la mise à niveau peut rester bloquée au niveau de Creating or updating cluster control plane workloads.

Ce problème se produit si, dans la VM maître de l'administrateur, ip a | grep cali renvoie un résultat non vide.

Par exemple,

ubuntu@abf8a975479b-qual-342-0afd1d9c ~ $ ip a | grep cali
4: cali2251589245f@if3:  mtu 1500 qdisc noqueue state UP group default

Solution :

1. Réparez le maître administrateur :

   gkectl repair admin-master --kubeconfig=ADMIN_KUBECONFIG \
       --config=ADMIN_CONFIG_FILE \
       --skip-validation
   

2. Sélectionnez le modèle de VM 1.30 si vous voyez une invite comme celle de l'exemple suivant :

   Please select the control plane VM template to be used for re-creating the
   admin cluster's control plane VM.
   

3. Reprenez la mise à niveau :

   gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG \
       --config ADMIN_CONFIG_FILE
   

Champ isControlPlane redondant dans le fichier de configuration du cluster sous network.controlPlaneIPBlock

Les fichiers de configuration de cluster générés par gkectl create-config dans la version 1.31.0 contiennent un champ isControlPlane redondant sous network.controlPlaneIPBlock :

    controlPlaneIPBlock:
    netmask: ""
    gateway: ""
    ips:
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    - ip: ""
      hostname: ""
      isControlPlane: false
    

Ce champ n'est pas nécessaire et peut être supprimé du fichier de configuration sans risque.

Les nœuds de modules complémentaires de l'administrateur sont bloqués sur "NotReady" lors de la migration d'un cluster d'administrateur standard vers un cluster d'administrateur à haute disponibilité

Lorsque vous migrez un cluster d'administrateur non HD qui utilise MetalLB vers un cluster HD, les nœuds de modules complémentaires d'administration peuvent rester bloqués à l'état NotReady, ce qui empêche la migration de se terminer.

Ce problème n'affecte que les clusters d'administrateur configurés avec MetalLB, où la réparation automatique n'est pas activée.

Ce problème est dû à une condition de concurrence lors de la migration, où les speakers MetalLB utilisent toujours l'ancien secret metallb-memberlist. En raison de la condition de concurrence, l'ancienne adresse IP virtuelle du plan de contrôle devient inaccessible, ce qui bloque la migration.

Solution :

1. Supprimez le secret metallb-memberlist existant :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       delete secret metallb-memberlist
   

2. Redémarrez le déploiement metallb-controller pour qu'il puisse générer le nouveau metallb-memberlist :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart deployment metallb-controller
   

3. Assurez-vous que le nouveau metallb-memberlist est généré :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       get secret metallb-memberlist
   

4. Mettez à jour updateStrategy.rollingUpdate.maxUnavailable dans le DaemonSet metallb-speaker de 1 à 100%.

   Cette étape est obligatoire, car certains pods DaemonSet s'exécutent sur les nœuds NotReady.

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       edit daemonset metallb-speaker
   

5. Redémarrez le DaemonSet metallb-speaker pour qu'il puisse récupérer la nouvelle liste des membres :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n kube-system \
       rollout restart daemonset metallb-speaker
   

   Au bout de quelques minutes, les nœuds de modules complémentaires d'administration redeviennent Ready et la migration peut se poursuivre.

6. Si la commande gkectl initiale a expiré après plus de trois heures, réexécutez gkectl update pour reprendre la migration qui a échoué.

Échec de la sauvegarde du cluster pour un cluster d'administrateur non haute disponibilité en raison de noms de datastore et de disque de données trop longs

Lorsque vous tentez de sauvegarder un cluster d'administrateur non HA, la sauvegarde échoue, car la longueur combinée des noms du datastore et du disque de données dépasse la longueur maximale autorisée.

La longueur maximale d'un nom de data store est de 80 caractères.
 Le chemin de sauvegarde d'un cluster d'administrateur non haute disponibilité respecte la syntaxe de nommage "__". Par conséquent, si le nom concaténé dépasse la longueur maximale, la création du dossier de sauvegarde échouera.

Solution :

Renommez le datastore ou le disque de données en lui attribuant un nom plus court.
 Assurez-vous que la longueur combinée des noms du datastore et du disque de données ne dépasse pas le nombre maximal de caractères.

Le nœud du plan de contrôle d'administrateur HA affiche une version antérieure après l'exécution de gkectl repair admin-master

Après l'exécution de la commande gkectl repair admin-master, un nœud de plan de contrôle de l'administrateur peut afficher une version antérieure à celle attendue.

Ce problème se produit, car le modèle de VM sauvegardé utilisé pour la réparation du nœud du plan de contrôle administrateur HA n'est pas actualisé dans vCenter après une mise à niveau. En effet, le modèle de VM de sauvegarde n'a pas été cloné lors de la création de la machine si le nom de la machine reste inchangé.

Solution :

1. Déterminez le nom de la machine qui utilise l'ancienne version de Kubernetes :

       kubectl get machine -o wide --kubeconfig=ADMIN_KUBECONFIG
       

2. Supprimez l'annotation onprem.cluster.gke.io/prevented-deletion :

       kubectl edit machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

   Enregistrez la modification.

3. Exécutez la commande suivante pour supprimer la machine :

       kubectl delete machine MACHINE_NAME --kubeconfig=ADMIN_KUBECONFIG
       

   Une nouvelle machine sera créée avec la version appropriée.

Terraform supprime des champs vCenter de manière inattendue

Lorsque vous mettez à jour un cluster d'utilisateur ou un pool de nœuds à l'aide de Terraform, il est possible que Terraform tente de définir les champs vCenter sur des valeurs vides.

Ce problème peut se produire si le cluster n'a pas été créé à l'origine à l'aide de Terraform.

Solution :

Pour éviter cette mise à jour inattendue, assurez-vous qu'elle est sûre avant d'exécuter terraform apply, comme décrit ci-dessous :

1. Exécuter terraform plan
2. Dans le résultat, vérifiez si les champs vCenter sont définis sur nil.
3. Si un champ vCenter est défini sur une valeur vide dans la configuration Terraform, ajoutez vcenter à la liste ignore_changes en suivant la documentation Terraform. Cela empêche la modification de ces champs.
4. Exécutez à nouveau terraform plan et vérifiez le résultat pour confirmer que la mise à jour est conforme à vos attentes.

Les nœuds du plan de contrôle du cluster d'utilisateur sont toujours redémarrés lors de la première opération de mise à jour du cluster d'administrateur.

Une fois les nœuds du plan de contrôle des clusters d'utilisateur kubeception créés, mis à jour ou mis à niveau, ils sont redémarrés un par un lors de la première opération du cluster d'administrateur lorsque celui-ci est créé ou mis à niveau vers l'une des versions concernées. Pour les clusters kubeception avec trois nœuds de plan de contrôle, cela ne devrait pas entraîner de temps d'arrêt du plan de contrôle. Le seul impact est que l'opération du cluster d'administrateur prend plus de temps.

Erreurs lors de la création de ressources personnalisées

Dans la version 1.31 de Google Distributed Cloud, des erreurs peuvent se produire lorsque vous essayez de créer des ressources personnalisées, telles que des clusters (tous types) et des charges de travail. Ce problème est dû à une modification incompatible introduite dans Kubernetes 1.31, qui empêche le champ caBundle d'une définition de ressource personnalisée de passer d'un état valide à un état non valide. Pour en savoir plus sur cette modification, consultez le journal des modifications de Kubernetes 1.31.

Avant Kubernetes 1.31, le champ caBundle était souvent défini sur une valeur de substitution \n, car dans les versions antérieures de Kubernetes, le serveur d'API n'autorisait pas le contenu vide du bundle d'autorité de certification. L'utilisation de \n était une solution de contournement raisonnable pour éviter toute confusion, car cert-manager met généralement à jour caBundle ultérieurement.

Si caBundle a été corrigé une fois pour passer d'un état non valide à un état valide, il ne devrait pas y avoir de problème. Toutefois, si la définition de la ressource personnalisée est réconciliée avec \n (ou une autre valeur non valide), l'erreur suivante peut se produire :

...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block]

Solution

Si vous disposez d'une définition de ressource personnalisée dans laquelle caBundle est défini sur une valeur non valide, vous pouvez supprimer le champ caBundle en toute sécurité. Cela devrait résoudre le problème.

cloud-init status renvoie toujours une erreur

Lors de la mise à niveau d'un cluster qui utilise l'image OS Container-Optimized OS (COS) vers la version 1.31, la commande cloud-init status échoue, même si cloud-init s'est terminé sans erreur.

Solution :

Exécutez la commande suivante pour vérifier l'état de cloud-init :

    systemctl show -p Result cloud-final.service
    

Si le résultat est semblable à ce qui suit, cela signifie que cloud-init s'est terminé correctement :

    Result=success
    

Échec de la vérification préliminaire du poste de travail administrateur lors de la mise à niveau vers la version 1.28 avec une taille de disque inférieure à 100 Go

Lors de la mise à niveau d'un cluster vers la version 1.28, la commande gkectl prepare échoue lors de l'exécution des vérifications préliminaires du poste de travail administrateur si la taille du disque du poste de travail administrateur est inférieure à 100 Go. Dans ce cas, la commande affiche un message d'erreur semblable à celui-ci :

    Workstation Hardware: Workstation hardware requirements are not satisfied
    

Dans la version 1.28, la taille de disque requise pour le poste de travail administrateur est passée de 50 Go à 100 Go.

Solution :

1. Effectuez le rollback du poste de travail administrateur.
2. Mettez à jour le fichier de configuration du poste de travail administrateur pour augmenter la taille du disque à au moins 100 Go.
3. Mettez à niveau le poste de travail administrateur.

gkectl renvoie une erreur "false" sur la classe de stockage NetApp

La commande gkectl upgrade renvoie une erreur incorrecte concernant la classe de stockage NetApp. Le message d'erreur ressemble à ceci :

    detected unsupported drivers:
      csi.trident.netapp.io
    

Solution :

Exécutez gkectl upgrade avec l'indicateur `--skip-pre-upgrade-checks`.

Un certificat CA non valide après la rotation des CA du cluster dans ClientConfig empêche l'authentification du cluster

Après avoir alterné les certificats de l'autorité de certification (CA) sur un cluster d'utilisateur, le champ spec.certificateAuthorityData du fichier ClientConfig contient un certificat CA non valide, ce qui empêche l'authentification auprès du cluster.

Solution :

Avant la prochaine authentification gcloud CLI, mettez à jour manuellement le champ spec.certificateAuthorityData dans ClientConfig avec le certificat d'autorité de certification approprié.

1. Copiez le certificat CA du cluster à partir du champ certificate-authority-data dans le fichier kubeconfig du cluster d'administrateur.
2. Modifiez le fichier ClientConfig et collez le certificat CA dans le champ spec.certificateAuthorityData.

       kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
       

Échec de la vérification préliminaire lors de la désactivation de l'entrée groupée

Lorsque vous désactivez l'entrée groupée en supprimant le champ loadBalancer.vips.ingressVIP dans le fichier de configuration du cluster, un bug dans la vérification préliminaire MetalLB entraîne l'échec de la mise à jour du cluster avec le message d'erreur "Adresse IP virtuelle d'entrée utilisateur non valide : adresse IP non valide".

Solution :

Ignorez le message d'erreur.
 Ignorez le contrôle avant vol à l'aide de l'une des méthodes suivantes :

• Ajoutez l'indicateur --skip-validation-load-balancer à la commande gkectl update cluster.
• Annoter l'objet onpremusercluster avec onprem.cluster.gke.io/server-side-preflight-skip: skip-validation-load-balancer
.

Échec de la mise à niveau du cluster en raison d'une règle de groupe d'anti-affinité manquante dans vCenter

Lors de la mise à niveau d'un cluster, les objets machine peuvent rester bloqués dans la phase "Création" et ne pas être associés aux objets nœud en raison d'une règle de groupe anti-affinité (AAG) manquante dans vCenter.

Si vous décrivez les objets de machine problématiques, vous pouvez voir des messages récurrents tels que "La tâche de reconfiguration de la règle DRS "task-xxxx" est terminée".

    kubectl --kubeconfig KUBECONFIG describe machine MACHINE_OBJECT_NAME
    

Solution :

Désactivez le paramètre de groupe d'anti-affinité dans la configuration du cluster d'administrateur et la configuration du cluster d'utilisateur, puis déclenchez la commande de mise à jour forcée pour débloquer la mise à niveau du cluster :

    gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
    

    gkectl update cluster --config USER_CLUSTER_CONFIG_FILE --kubeconfig USER_CLUSTER_KUBECONFIG --force
    

La migration d'un cluster d'utilisateur vers Controlplane V2 échoue si le chiffrement des secrets a déjà été activé

Lors de la migration d'un cluster d'utilisateur vers Controlplane V2, si le chiffrement permanent des secrets a déjà été activé, le processus de migration ne parvient pas à gérer correctement la clé de chiffrement des secrets. En raison de ce problème, le nouveau cluster Controlplane V2 ne peut pas déchiffrer les secrets. Si le résultat de la commande suivante n'est pas vide, cela signifie que le chiffrement permanent des secrets a été activé à un moment donné et que le cluster est affecté par ce problème :

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

Si vous avez déjà commencé la migration et qu'elle échoue, contactez Google pour obtenir de l'aide. Sinon, avant la migration, désactivez le chiffrement permanent des secrets et déchiffrez les secrets.

La migration d'un cluster d'administrateur de non-HD vers HD échoue si le chiffrement des secrets est activé

Si le chiffrement permanent des secrets est activé dans le cluster d'administrateur à la version 1.14 ou antérieure, et que vous avez effectué une mise à niveau depuis d'anciennes versions vers les versions 1.29 et 1.30 concernées, le processus de migration du cluster d'administrateur de non-HA vers HA ne parvient pas à gérer correctement la clé de chiffrement des secrets. En raison de ce problème, le nouveau cluster d'administrateur HA ne peut pas déchiffrer les secrets.

Pour vérifier si le cluster utilise l'ancienne clé formatée :

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

Si la sortie affiche la clé vide comme suit, cela signifie que le cluster sera affecté par ce problème :

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

Si vous avez déjà commencé la migration et qu'elle échoue, contactez Google pour obtenir de l'aide.

Sinon, avant de commencer la migration, faites pivoter la clé de chiffrement.

credential.yaml régénéré de manière incorrecte lors de la mise à niveau du poste de travail administrateur

Lors de la mise à niveau du poste de travail administrateur à l'aide de la commande gkeadm upgrade admin-workstation, le fichier credential.yaml est régénéré de manière incorrecte. Les champs "Nom d'utilisateur" et "Mot de passe" sont vides. De plus, la clé privateRegistry contient une faute de frappe.

La même faute d'orthographe de la clé privateRegistry se trouve également dans le fichier admin-cluster.yaml.
 Étant donné que le fichier credential.yaml est régénéré lors du processus de mise à niveau du cluster d'administrateur, la faute de frappe est toujours présente, même si vous l'avez corrigée précédemment.

Solution :

• Mettez à jour le nom de la clé de registre privé dans credential.yaml pour qu'il corresponde à privateRegistry.credentials.fileRef.entry dans admin-cluster.yaml.
• Mettez à jour le nom d'utilisateur et le mot de passe du registre privé dans le fichier credential.yaml.

Échec de la mise à niveau du cluster d'utilisateur en raison du délai d'attente de réconciliation avant la mise à niveau

Lors de la mise à niveau d'un cluster d'utilisateur, l'opération de réconciliation avant la mise à niveau peut prendre plus de temps que le délai d'attente défini, ce qui entraîne un échec de la mise à niveau. Le message d'erreur ressemble à ceci :

Failed to reconcile the user cluster before upgrade: the pre-upgrade reconcile failed, error message:
failed to wait for reconcile to complete: error: timed out waiting for the condition,
message: Cluster reconcile hasn't finished yet, please fix that before
rerun the upgrade.

Le délai avant expiration de l'opération de réconciliation avant mise à niveau est de cinq minutes, plus une minute par pool de nœuds dans le cluster d'utilisateur.

Solution :

Assurez-vous que la commande gkectl diagnose cluster s'exécute sans erreur.
 Ignorez l'opération de réconciliation avant la mise à niveau en ajoutant l'indicateur --skip-reconcile-before-preflight à la commande gkectl upgrade cluster. Exemple :

gkectl upgrade cluster --skip-reconcile-before-preflight --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG_FILE

La mise à jour de ForwardMode DataplaneV2 ne déclenche pas automatiquement le redémarrage du DaemonSet anetd

Lorsque vous mettez à jour le champ dataplaneV2.forwardMode du cluster d'utilisateur à l'aide de gkectl update cluster, la modification n'est mise à jour que dans le ConfigMap. Le DaemonSet anetd ne prendra pas en compte la modification de la configuration tant qu'il n'aura pas été redémarré, et vos modifications ne seront pas appliquées.

Solution :

Une fois la commande gkectl update cluster terminée, le résultat Done updating the user cluster s'affiche. Une fois ce message affiché, exécutez la commande suivante pour redémarrer le DaemonSet anetd et appliquer la modification de configuration :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG rollout restart daemonset anetd

Vérifiez que le DaemonSet est prêt après le redémarrage :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get daemonset anetd

Dans le résultat de la commande précédente, vérifiez que le nombre de la colonne DESIRED correspond à celui de la colonne READY.

Commande etcdctl introuvable lors de la mise à niveau du cluster au niveau de la sauvegarde du cluster d'administrateur

Lors de la mise à niveau d'un cluster d'utilisateur de la version 1.16 vers la version 1.28, le cluster d'administrateur est sauvegardé. Le processus de sauvegarde du cluster d'administrateur affiche le message d'erreur "etcdctl: command not found". La mise à niveau du cluster d'utilisateur réussit et le cluster d'administrateur reste opérationnel. Le seul problème est que le fichier de métadonnées du cluster d'administrateur n'est pas sauvegardé.

Le problème est dû au fait que le binaire etcdctl a été ajouté dans la version 1.28 et n'est pas disponible sur les nœuds 1.16.

La sauvegarde du cluster d'administrateur implique plusieurs étapes, y compris la création d'un instantané etcd, puis l'écriture du fichier de métadonnées pour le cluster d'administrateur. La sauvegarde etcd réussit toujours, car etcdctl peut toujours être déclenché après une exécution dans le pod etcd. Toutefois, l'écriture du fichier de métadonnées échoue, car elle repose toujours sur l'installation du binaire etcdctl sur le nœud. Toutefois, la sauvegarde du fichier de métadonnées n'empêche pas la sauvegarde. Le processus de sauvegarde réussit donc, tout comme la mise à niveau du cluster d'utilisateur.

Solution :

Si vous souhaitez sauvegarder le fichier de métadonnées, suivez la procédure décrite dans Sauvegarder et restaurer un cluster d'administrateur à l'aide de gkectl pour déclencher une sauvegarde distincte du cluster d'administrateur à l'aide de la version de gkectl correspondant à la version de votre cluster d'administrateur.

Échec de la création du cluster d'utilisateur avec équilibrage de charge manuel

Lors de la création d'un cluster d'utilisateur configuré pour l'équilibrage de charge manuel, une défaillance gkectl check-config se produit, indiquant que la valeur ingressHTTPNodePort doit être d'au moins 30 000, même lorsque l'entrée groupée est désactivée.

Ce problème se produit, que les champs ingressHTTPNodePort et ingressHTTPSNodePort soient définis ou laissés vides.

Solution :

Pour contourner ce problème, ignorez le résultat renvoyé par gkectl check-config. Pour désactiver l'entrée groupée, consultez Désactiver l'entrée groupée.

Après la migration d'un cluster d'utilisateur vers Controlplane V2, le PDB metrics-server du cluster d'administrateur peut être mal configuré.

Le problème lié au PodDisruptionBudget (PDB) se produit lorsque vous utilisez des clusters d'administrateur à haute disponibilité (HA) et qu'il y a 0 ou 1 nœud de cluster d'administrateur sans rôle après la migration. Pour vérifier s'il existe des objets de nœud sans rôle, exécutez la commande suivante :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes -o wide

S'il existe deux objets de nœud ou plus sans rôle après la migration, cela signifie que le PDB n'est pas mal configuré.

Symptômes :

Le résultat de admin cluster diagnose inclut les informations suivantes :

Checking all poddisruptionbudgets...FAILURE
  Reason: 1 pod disruption budget error(s).
  Unhealthy Resources:
  PodDisruptionBudget metrics-server: gke-managed-metrics-server/metrics-server might be configured incorrectly: the total replicas(1) should be larger than spec.MinAvailable(1).

Solution :

Exécutez la commande suivante pour supprimer le PDB :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete pdb metrics-server -n gke-managed-metrics-server

Le webhook d'autorisation binaire empêche le démarrage du plug-in CNI, ce qui fait qu'un des pools de nœuds ne démarre pas.

Dans de rares conditions de concurrence, une séquence d'installation incorrecte du webhook autorisation binaire et du pod gke-connect peut entraîner le blocage de la création du cluster d'utilisateur, car un nœud ne parvient pas à atteindre l'état prêt. Dans les scénarios concernés, la création d'un cluster d'utilisateur peut être bloquée si un nœud ne parvient pas à atteindre l'état prêt. Dans ce cas, le message suivant s'affiche :

     Node pool is not ready: ready condition is not true: CreateOrUpdateNodePool: 2/3 replicas are ready
    

Solution :

1. Supprimez la configuration autorisation binaire de votre fichier de configuration. Pour obtenir des instructions de configuration, veuillez consulter le guide d'installation de l'autorisation binaire pour GKE sur VMware.
2. Pour débloquer un nœud défectueux lors du processus de création du cluster actuel, supprimez temporairement la configuration du webhook d'autorisation binaire dans le cluster d'utilisateur à l'aide de la commande suivante.

           kubectl --kubeconfig USER_KUBECONFIG delete ValidatingWebhookConfiguration binauthz-validating-webhook-configuration
           

   Une fois le processus d'amorçage terminé, vous pouvez rajouter la configuration de webhook suivante.

   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingWebhookConfiguration
   metadata:
     name: binauthz-validating-webhook-configuration
   webhooks:
   - name: "binaryauthorization.googleapis.com"
     namespaceSelector:
       matchExpressions:
       - key: control-plane
         operator: DoesNotExist
     objectSelector:
       matchExpressions:
       - key: "image-policy.k8s.io/break-glass"
         operator: NotIn
         values: ["true"]
     rules:
     - apiGroups:
       - ""
       apiVersions:
       - v1
       operations:
       - CREATE
       - UPDATE
       resources:
       - pods
       - pods/ephemeralcontainers
     admissionReviewVersions:
     - "v1beta1"
     clientConfig:
       service:
         name: binauthz
         namespace: binauthz-system
         path: /binauthz
       # CA Bundle will be updated by the cert rotator.
       caBundle: Cg==
     timeoutSeconds: 10
     # Fail Open
     failurePolicy: "Ignore"
     sideEffects: None
           

La mise à niveau du cluster d'utilisateur CPV2 est bloquée en raison d'une machine en miroir avec deletionTimestamp

Lors de la mise à niveau d'un cluster d'utilisateur, l'opération de mise à niveau peut se bloquer si l'objet machine mis en miroir dans le cluster d'utilisateur contient un deletionTimestamp. Le message d'erreur suivant s'affiche si la mise à niveau est bloquée :

    machine is still in the process of being drained and subsequently removed
    

Ce problème peut se produire si vous avez déjà tenté de réparer le nœud du plan de contrôle utilisateur en exécutant gkectl delete machine sur la machine mise en miroir dans le cluster utilisateur.

Solution :

1. Récupérez l'objet de la machine mise en miroir et enregistrez-le dans un fichier local à des fins de sauvegarde.
2. Exécutez la commande suivante pour supprimer le finaliseur de la machine mise en miroir et attendez qu'il soit supprimé du cluster d'utilisateur.

       kubectl --kubeconfig ADMIN_KUBECONFIG patch machine/MACHINE_OBJECT_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge

3. Suivez les étapes décrites dans Nœud du plan de contrôle du cluster d'utilisateur Controlplane V2 pour déclencher la réparation des nœuds du plan de contrôle. La spécification de la machine source correcte sera ainsi resynchronisée dans le cluster d'utilisateur.
4. Exécutez à nouveau gkectl upgrade cluster pour reprendre la mise à niveau.

Échec de la création du cluster en raison de l'adresse IP virtuelle du plan de contrôle dans un sous-réseau différent

Pour un cluster d'administrateur à haute disponibilité ou un cluster d'utilisateur Controlplane V2, l'adresse IP virtuelle du plan de contrôle doit se trouver dans le même sous-réseau que les autres nœuds du cluster. Sinon, la création du cluster échoue, car kubelet ne peut pas communiquer avec le serveur d'API à l'aide de l'adresse IP virtuelle du plan de contrôle.

Solution :

Avant de créer le cluster, assurez-vous que l'adresse IP virtuelle du plan de contrôle est configurée dans le même sous-réseau que les autres nœuds du cluster.

Échec de la création/mise à niveau du cluster en raison d'un nom d'utilisateur vCenter non FQDN

La création ou la mise à niveau du cluster échoue et renvoie une erreur dans les pods CSI vSphere indiquant que le nom d'utilisateur vCenter n'est pas valide. Cela se produit, car le nom d'utilisateur utilisé n'est pas un nom de domaine complet. Message d'erreur dans le pod vsphere-csi-controller, comme indiqué ci-dessous :

    GetCnsconfig failed with err: username is invalid, make sure it is a fully qualified domain username
    

Ce problème ne se produit que dans la version 1.29 et ultérieures, car une validation a été ajoutée au pilote CSI vSphere pour forcer l'utilisation de noms d'utilisateur de domaine complets.

Solution :

Utilisez un nom de domaine complet pour le nom d'utilisateur vCenter dans le fichier de configuration des identifiants. Par exemple, au lieu d'utiliser "nomutilisateur1", utilisez "nomutilisateur1@example.com".

Échec de la mise à niveau du cluster administrateur pour les clusters créés dans la version 1.10 ou antérieure

Lors de la mise à niveau d'un cluster d'administrateur de la version 1.16 à la version 1.28, l'amorçage de la nouvelle machine maître d'administration peut échouer à générer le certificat du plan de contrôle. Ce problème est dû à des modifications apportées à la façon dont les certificats sont générés pour le serveur d'API Kubernetes dans la version 1.28 et les versions ultérieures. Le problème se reproduit pour les clusters créés sur les versions 1.10 et antérieures qui ont été mis à niveau jusqu'à la version 1.16 et dont le certificat feuille n'a pas été renouvelé avant la mise à niveau.

Pour déterminer si l'échec de la mise à niveau du cluster d'administrateur est dû à ce problème, procédez comme suit :

1. Connectez-vous à la machine maître administrateur défaillante à l'aide de SSH.
2. Ouvrez /var/log/startup.log et recherchez une erreur semblable à celle-ci :

Error adding extensions from section apiserver_ext
801B3213B57F0000:error:1100007B:X509 V3 routines:v2i_AUTHORITY_KEYID:unable to get issuer keyid:../crypto/x509/v3_akid.c:177:
801B3213B57F0000:error:11000080:X509 V3 routines:X509V3_EXT_nconf_int:error in extension:../crypto/x509/v3_conf.c:48:section=apiserver_ext, name=authorityKeyIdentifier, value=keyid>
   

Solution :

1. Connectez-vous à la machine maître de l'administrateur à l'aide de SSH. Pour en savoir plus, consultez Utiliser SSH pour se connecter à un nœud de cluster d'administrateur.
2. Créez une copie de /etc/startup/pki-yaml.sh et nommez-la /etc/startup/pki-yaml-copy.sh.
3. Modifier /etc/startup/pki-yaml-copy.sh. Recherchez authorityKeyIdentifier=keyidset et remplacez-le par authorityKeyIdentifier=keyid,issuer dans les sections des extensions suivantes : apiserver_ext, client_ext, etcd_server_ext et kubelet_server_ext. Exemple :

         [ apiserver_ext ]
         keyUsage = critical, digitalSignature, keyEncipherment
         extendedKeyUsage=serverAuth
         basicConstraints = critical,CA:false
         authorityKeyIdentifier = keyid,issuer
         subjectAltName = @apiserver_alt_names
   

4. Enregistrez les modifications apportées à /etc/startup/pki-yaml-copy.sh.
5. À l'aide d'un éditeur de texte, ouvrez /opt/bin/master.sh, recherchez et remplacez toutes les occurrences de /etc/startup/pki-yaml.sh par /etc/startup/pki-yaml-copy.sh, puis enregistrez les modifications.
6. Exécutez /opt/bin/master.sh pour générer le certificat et terminer le démarrage de la machine.
7. Exécutez à nouveau gkectl upgrade admin pour mettre à niveau le cluster d'administrateur.
8. Une fois la mise à niveau terminée, effectuez la rotation du certificat feuille pour les clusters d'administrateur et d'utilisateur, comme décrit dans Démarrer la rotation.
9. Une fois la rotation du certificat terminée, apportez les mêmes modifications à /etc/startup/pki-yaml-copy.sh que précédemment, puis exécutez /opt/bin/master.sh.

Message d'avertissement incorrect pour les clusters avec Dataplane V2 activé

Le message d'avertissement incorrect suivant s'affiche lorsque vous exécutez gkectl pour créer, mettre à jour ou migrer un cluster pour lequel Dataplane V2 est déjà activé :

WARNING: Your user cluster is currently running our original architecture with
[DataPlaneV1(calico)]. To enable new and advanced features we strongly recommend
to update it to the newer architecture with [DataPlaneV2] once our migration
tool is available.

Un bug dans gkectl l'empêche de ne pas afficher cet avertissement tant que l'option dataplaneV2.forwardMode n'est pas utilisée, même si vous avez déjà défini enableDataplaneV2: true dans le fichier de configuration de votre cluster.

Solution :

Vous pouvez ignorer cet avertissement.

La vérification préliminaire de l'installation du cluster d'administrateur à haute disponibilité indique un nombre incorrect d'adresses IP statiques requises

Lorsque vous créez un cluster d'administrateur à haute disponibilité, la vérification préliminaire affiche le message d'erreur incorrect suivant :

- Validation Category: Network Configuration
    - [FAILURE] CIDR, VIP and static IP (availability and overlapping): needed
    at least X+1 IP addresses for admin cluster with X nodes

L'exigence est incorrecte pour les clusters d'administrateur HA 1.28 et versions ultérieures, car ils ne comportent plus de nœuds complémentaires. De plus, comme les adresses IP des trois nœuds du plan de contrôle du cluster d'administrateur sont spécifiées dans la section network.controlPlaneIPBlock du fichier de configuration du cluster d'administrateur, les adresses IP du fichier de bloc d'adresses IP ne sont nécessaires que pour les nœuds du plan de contrôle du cluster d'utilisateur kubeception.

Solution :

Pour ignorer la vérification préliminaire incorrecte dans une version non corrigée, ajoutez --skip-validation-net-config à la commande gkectl.

L'agent Connect perd la connexion à Google Cloud après la migration d'un cluster d'administrateur standard vers un cluster d'administrateur à haute disponibilité

Si vous avez migré d'un cluster d'administrateur non HD vers un cluster d'administrateur HD, l'agent Connect du cluster d'administrateur perd la connexion à gkeconnect.googleapis.com et l'erreur "Échec de la validation de la signature JWT" s'affiche. En effet, lors de la migration, la clé de signature KSA est modifiée. Une nouvelle inscription est donc nécessaire pour actualiser les JWK OIDC.

Solution :

Pour reconnecter le cluster d'administrateur à Google Cloud, procédez comme suit pour déclencher un nouvel enregistrement :

Commencez par obtenir le nom du déploiement gke-connect :

kubectl --kubeconfig KUBECONFIG get deployment -n gke-connect

Supprimez le déploiement gke-connect :

kubectl --kubeconfig KUBECONFIG delete deployment GKE_CONNECT_DEPLOYMENT -n gke-connect

Déclenchez une réconciliation forcée pour onprem-admin-cluster-controller en ajoutant une annotation "force-reconcile" à votre CR onpremadmincluster :

kubectl --kubeconfig KUBECONFIG patch onpremadmincluster ADMIN_CLUSTER_NAME -n kube-system --type merge -p '
metadata:
  annotations:
    onprem.cluster.gke.io/force-reconcile: "true"
'

L'idée est que onprem-admin-cluster-controller redéploie toujours le déploiement gke-connect et réenregistre le cluster s'il ne trouve aucun déploiement gke-connect existant.

Après la solution de contournement (le contrôleur peut mettre quelques minutes à terminer la réconciliation), vous pouvez vérifier que l'erreur 400 "Échec de la validation de la signature JWT" a disparu des journaux gke-connect-agent :

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect

L'adresse IP de liaison Docker utilise 172.17.0.1/16 pour les nœuds du plan de contrôle du cluster COS

Google Distributed Cloud spécifie un sous-réseau dédié, --bip=169.254.123.1/24, pour l'adresse IP de la liaison Docker dans la configuration Docker afin d'éviter de réserver le sous-réseau par défaut 172.17.0.1/16. Toutefois, dans les versions 1.28.0 à 1.28.500 et 1.29.0, le service Docker n'a pas été redémarré après la personnalisation de la configuration Docker par Google Distributed Cloud en raison d'une régression dans l'image de l'OS COS. En conséquence, Docker sélectionne le paramètre 172.17.0.1/16 par défaut comme sous-réseau d'adresse IP de liaison. Cela peut entraîner un conflit d'adresses IP si vous avez déjà une charge de travail en cours d'exécution dans cette plage d'adresses IP.

Solution :

Pour contourner ce problème, vous devez redémarrer le service Docker :

sudo systemctl restart docker

Vérifiez que Docker sélectionne l'adresse IP de liaison correcte :

ip a | grep docker0

Cette solution ne persiste pas lors de la recréation des VM. Vous devez appliquer cette solution de contournement à chaque recréation de VM.

L'utilisation de plusieurs interfaces réseau avec le CNI standard ne fonctionne pas

Les binaires CNI standards bridge, ipvlan, vlan, macvlan, dhcp, tuning, host-local, ptp, portmap ne sont pas inclus dans les images OS des versions concernées. Ces binaires CNI ne sont pas utilisés par le plan de données V2, mais peuvent l'être pour des interfaces réseau supplémentaires dans la fonctionnalité d'interfaces réseau multiples.

Les interfaces réseau multiples ne fonctionnent pas avec ces plug-ins CNI.

Solution :

Si vous utilisez cette fonctionnalité, passez à la version qui corrige le problème.

Les dépendances Netapp Trident interfèrent avec le pilote CSI vSphere

L'installation de multipathd sur les nœuds de cluster interfère avec le pilote CSI vSphere, ce qui empêche le démarrage des charges de travail utilisateur.

Solution :

• Désactiver multipathd

Le webhook du cluster d'administrateur peut bloquer les mises à jour

Si certaines configurations requises sont vides dans le cluster d'administrateur, car des validations ont été ignorées, l'ajout de ces configurations peut être bloqué par le webhook du cluster d'administrateur. Par exemple, si le champ gkeConnect n'a pas été défini dans un cluster d'administrateur existant, l'ajout de ce champ avec la commande gkectl update admin peut générer le message d'erreur suivant :

admission webhook "vonpremadmincluster.onprem.cluster.gke.io" denied the request: connect: Required value: GKE connect is required for user clusters

failed to apply OnPremAdminCluster 'kube-system/gke-admin-btncc': Internal error occurred: failed calling webhook "monpremadmincluster.onprem.cluster.gke.io": failed to call webhook: Post "https://onprem-admin-cluster-controller.kube-system.svc:443/mutate-onprem-cluster-gke-io-v1alpha1-onpremadmincluster?timeout=10s": dial tcp 10.96.55.208:443: connect: connection refused

Solution :

• Pour les clusters d'administrateur 1.15, exécutez la commande gkectl update admin avec l'option --disable-admin-cluster-webhook. Exemple :

          gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --disable-admin-cluster-webhook
          

• Pour les clusters d'administrateur 1.16, exécutez les commandes gkectl update admin avec l'option --force. Exemple :

          gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig ADMIN_CLUSTER_KUBECONFIG --force
          

Le champ controlPlaneNodePort est défini par défaut sur 30968 lorsque la spécification manualLB est vide.

Si vous utilisez un équilibreur de charge manuel (loadBalancer.kind est défini sur "ManualLB"), vous n'avez pas besoin de configurer la section loadBalancer.manualLB dans le fichier de configuration pour un cluster d'administrateur à haute disponibilité (HA) dans les versions 1.16 et ultérieures. Toutefois, lorsque cette section est vide, Google Distributed Cloud attribue des valeurs par défaut à tous les NodePorts, y compris manualLB.controlPlaneNodePort, ce qui entraîne l'échec de la création du cluster avec le message d'erreur suivant :

- Validation Category: Manual LB
  - [FAILURE] NodePort configuration: manualLB.controlPlaneNodePort must
   not be set when using HA admin cluster, got: 30968

Solution :

Spécifiez manualLB.controlPlaneNodePort: 0 dans la configuration de votre cluster d'administrateur pour le cluster d'administrateur à haute disponibilité :

loadBalancer:
  ...
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 0
  ...

nfs-common est manquant dans l'image de l'OS Ubuntu

nfs-common est manquant dans l'image de l'OS Ubuntu, ce qui peut poser problème aux clients qui utilisent des pilotes dépendants de NFS tels que NetApp.

Warning FailedMount 63s (x8 over 2m28s) kubelet MountVolume.SetUp failed for volume "pvc-xxx-yyy-zzz" : rpc error: code = Internal desc = error mounting NFS volume 10.0.0.2:/trident_pvc_xxx-yyy-zzz on mountpoint /var/lib/kubelet/pods/aaa-bbb-ccc/volumes/kubernetes.io~csi/pvc-xxx-yyy-zzz/mount: exit status 32".
      

Solution :

Assurez-vous que vos nœuds peuvent télécharger des packages depuis Canonical.

Appliquez ensuite le DaemonSet suivant à votre cluster pour installer nfs-common :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: install-nfs-common
  labels:
    name: install-nfs-common
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: install-nfs-common
  minReadySeconds: 0
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%
  template:
    metadata:
      labels:
        name: install-nfs-common
    spec:
      hostPID: true
      hostIPC: true
      hostNetwork: true
      initContainers:
      - name: install-nfs-common
        image: ubuntu
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        command:
        - chroot
        - /host
        - bash
        - -c
        args:
        - |
          apt install -y nfs-common
        volumeMounts:
        - name: host
          mountPath: /host
      containers:
      - name: pause
        image: gcr.io/gke-on-prem-release/pause-amd64:3.1-gke.5
        imagePullPolicy: IfNotPresent
      volumes:
      - name: host
        hostPath:
          path: /
      

Le champ "Règles de stockage" est manquant dans le modèle de configuration du cluster d'administrateur

SPBM dans les clusters d'administrateur est compatible avec la version 1.28.0 et ultérieures. Toutefois, le champ vCenter.storagePolicyName est manquant dans le modèle de fichier de configuration.

Solution :

Ajoutez le champ "vCenter.storagePolicyName" dans le fichier de configuration de votre cluster d'administrateur si vous souhaitez configurer la règle de stockage pour le cluster d'administrateur. Veuillez consulter les instructions.

L'API de métadonnées Kubernetes n'est pas compatible avec VPC-SC

L'API kubernetesmetadata.googleapis.com récemment ajoutée n'est pas compatible avec VPC-SC. Par conséquent, l'agent de collecte de métadonnées ne pourra pas accéder à cette API sous VPC-SC. Les libellés de métadonnées des métriques seront alors manquants.

Solution :

Dans l'espace de noms `kube-system`, définissez le champ `featureGates.disableExperimentalMetadataAgent` du CR `stackdriver` sur `true` en exécutant la commande

`kubectl -n kube-system patch stackdriver stackdriver -p '{"spec":{"featureGates":{"disableExperimentalMetadataAgent":true}}}'`

Exécutez ensuite

`kubectl -n kube-system patch deployment stackdriver-operator -p '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","env":[{"name":"ENABLE_LEGACY_METADATA_AGENT","value":"true"}]}]}}}}'`

Le clusterapi-controller peut planter lorsque le cluster d'administrateur et un cluster d'utilisateur avec ControlPlane V2 activé utilisent des identifiants vSphere différents.

Lorsqu'un cluster d'administrateur et un cluster d'utilisateur avec ControlPlane V2 activé utilisent des identifiants vSphere différents (par exemple, après la mise à jour des identifiants vSphere pour le cluster d'administrateur), il est possible que clusterapi-controller ne parvienne pas à se connecter à vCenter après le redémarrage. Affichez le journal du clusterapi-controller exécuté dans l'espace de noms `kube-system` du cluster d'administrateur.

kubectl logs -f -l component=clusterapi-controllers -c vsphere-controller-manager \
    -n kube-system --kubeconfig KUBECONFIG

E1214 00:02:54.095668       1 machine_controller.go:165] Error checking existence of machine instance for machine object gke-admin-node-77f48c4f7f-s8wj2: Failed to check if machine gke-admin-node-77f48c4f7f-s8wj2 exists: failed to find datacenter "VSPHERE_DATACENTER": datacenter 'VSPHERE_DATACENTER' not found

Solution :

Mettez à jour les identifiants vSphere afin que le cluster d'administrateur et tous les clusters d'utilisateur avec Controlplane V2 activé utilisent les mêmes identifiants vSphere.

Nombre élevé de requêtes GRPC ayant échoué dans Prometheus Alert Manager

Prometheus peut signaler des alertes semblables à l'exemple suivant :

Alert Name: cluster:gke-admin-test1: Etcd cluster kube-system/kube-etcd: 100% of requests for Watch failed on etcd instance etcd-test-xx-n001.

Pour vérifier si cette alerte est un faux positif qui peut être ignoré, procédez comme suit :

1. Comparez la métrique grpc_server_handled_total brute à la valeur grpc_method indiquée dans le message d'alerte. Dans cet exemple, vérifiez le libellé grpc_code pour Watch.
   
   Vous pouvez vérifier cette métrique à l'aide de Cloud Monitoring avec la requête MQL suivante :

   fetch
       k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m

2. Vous pouvez ignorer les alertes concernant tous les codes autres que OK si le code ne fait pas partie de la liste suivante :

   Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solution :

Pour configurer Prometheus afin qu'il ignore ces fausses alertes positives, examinez les options suivantes :

1. Coupez le son de l'alerte depuis l'interface utilisateur Alert Manager.
2. Si vous ne pouvez pas désactiver l'alerte, suivez les étapes ci-dessous pour supprimer les faux positifs :
   1. Réduisez la capacité de l'opérateur de surveillance à 0 réplicas pour que les modifications puissent persister.
   2. Modifiez la configmap prometheus-config et ajoutez grpc_method!="Watch" à la configuration d'alerte etcdHighNumberOfFailedGRPCRequests, comme indiqué dans l'exemple suivant :
      • Original :

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code!="OK",job=~".*etcd.*"}[5m])

      • Modifié :

        rate(grpc_server_handled_total{cluster="CLUSTER_NAME",grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded",grpc_method!="Watch",job=~".*etcd.*"}[5m])

        Remplacez CLUSTER_NAME par le nom de votre cluster.
   3. Redémarrez le StatefulSet Prometheus et Alertmanager pour récupérer la nouvelle configuration.
3. Si le code fait partie de l'un des cas problématiques, consultez le journal etcd et le journal kube-apiserver pour en savoir plus.

Les connexions NAT de sortie de longue durée sont abandonnées

Les connexions NAT de sortie peuvent être abandonnées après 5 à 10 minutes d'établissement d'une connexion s'il n'y a pas de trafic.

Étant donné que conntrack n'a d'importance que dans le sens entrant (connexions externes au cluster), ce problème ne se produit que si la connexion ne transmet aucune information pendant un certain temps, puis que le côté de destination transmet quelque chose. Si le pod NAT de sortie instancie toujours la messagerie, ce problème ne se produira pas.

Ce problème se produit, car le garbage collector anetd supprime par inadvertance les entrées conntrack que le daemon pense inutilisées. Un correctif en amont a récemment été intégré à anetd pour corriger le comportement.

Solution :

Il n'existe aucune solution de contournement simple, et nous n'avons pas constaté de problèmes dans la version 1.16 liés à ce comportement. Si vous constatez que des connexions de longue durée sont abandonnées en raison de ce problème, vous pouvez utiliser une charge de travail sur le même nœud que l'adresse IP de sortie ou envoyer des messages de manière cohérente sur la connexion TCP.

Le signataire de la CSR ignore spec.expirationSeconds lors de la signature des certificats.

Si vous créez une demande de signature de certificat (CSR) avec expirationSeconds défini, expirationSeconds est ignoré.

Solution :

Si vous êtes concerné par ce problème, vous pouvez mettre à jour votre cluster d'utilisateur en ajoutant disableNodeIDVerificationCSRSigning: true dans le fichier de configuration du cluster d'utilisateur et en exécutant la commande gkectl update cluster pour mettre à jour le cluster avec cette configuration.

Échec de la validation de l'équilibreur de charge du cluster d'utilisateur pour disable_bundled_ingress

Si vous essayez de désactiver l'entrée groupée pour un cluster existant, la commande gkectl update cluster échoue et affiche une erreur semblable à l'exemple suivant :

[FAILURE] Config: ingress IP is required in user cluster spec

Cette erreur se produit, car gkectl recherche une adresse IP d'entrée d'équilibreur de charge lors des vérifications préliminaires. Bien que cette vérification ne soit pas requise lors de la désactivation de l'entrée groupée, la vérification préliminaire gkectl échoue lorsque disableBundledIngress est défini sur true.

Solution :

Utilisez le paramètre --skip-validation-load-balancer lorsque vous mettez à jour le cluster, comme indiqué dans l'exemple suivant :

gkectl update cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG  \
  --skip-validation-load-balancer

Pour en savoir plus, consultez Désactiver l'entrée groupée pour un cluster existant.

Échec des mises à jour du cluster d'administrateur après la rotation de l'autorité de certification

Si vous faites tourner les certificats de l'autorité de certification (CA) du cluster d'administrateur, les tentatives ultérieures d'exécution de la commande gkectl update admin échouent. L'erreur renvoyée ressemble à ce qui suit :

failed to get last CARotationStage: configmaps "ca-rotation-stage" not found

Solution :

Si vous êtes concerné par ce problème, vous pouvez mettre à jour votre cluster d'administrateur en utilisant l'indicateur --disable-update-from-checkpoint avec la commande gkectl update admin :

gkectl update admin --config ADMIN_CONFIG_file \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --disable-update-from-checkpoint

Lorsque vous utilisez l'option --disable-update-from-checkpoint, la commande update n'utilise pas le fichier de point de contrôle comme source de vérité lors de la mise à jour du cluster. Le fichier de point de contrôle est toujours mis à jour pour une utilisation ultérieure.

Échec de la vérification préliminaire de la charge de travail CSI en raison de l'échec du démarrage du pod

Lors des vérifications préalables, la vérification de la validation de la charge de travail CSI installe un pod dans l'espace de noms default. Le pod de charge de travail CSI valide que le pilote CSI vSphere est installé et peut provisionner des volumes de manière dynamique. Si ce pod ne démarre pas, le contrôle de validation de la charge de travail CSI échoue.

Plusieurs problèmes connus peuvent empêcher le démarrage de ce pod :

• Si aucune limite de ressources n'est spécifiée pour le pod (ce qui est le cas pour certains clusters avec des webhooks d'admission installés), le pod ne démarre pas.
• Si Cloud Service Mesh est installé dans le cluster avec l'injection side-car Istio automatique activée dans l'espace de noms default, le pod de charge de travail CSI ne démarre pas.

Si le pod de charge de travail CSI ne démarre pas, une erreur de délai avant expiration semblable à celle-ci s'affiche lors des validations préliminaires :

- [FAILURE] CSI Workload: failure in CSIWorkload validation: failed to create writer Job to verify the write functionality using CSI: Job default/anthos-csi-workload-writer-<run-id> replicas are not in Succeeded phase: timed out waiting for the condition

Pour vérifier si l'échec est dû à un manque de ressources de pod définies, exécutez la commande suivante pour vérifier l'état du job anthos-csi-workload-writer-<run-id> :

kubectl describe job anthos-csi-workload-writer-<run-id>

Si les limites de ressources ne sont pas correctement définies pour le pod de charge de travail CSI, l'état du job contient un message d'erreur semblable à celui-ci :

CPU and memory resource limits is invalid, as it are not defined for container: volume-tester

Si le pod de charge de travail CSI ne démarre pas en raison de l'injection side-car Istio, vous pouvez désactiver temporairement l'injection side-car Istio automatique dans l'espace de noms default. Vérifiez les libellés de l'espace de noms et utilisez la commande suivante pour supprimer le libellé qui commence par istio.io/rev :

kubectl label namespace default istio.io/rev-

Si le pod est mal configuré, vérifiez manuellement que le provisionnement dynamique de volumes avec le pilote CSI vSphere fonctionne :

1. Créez un PVC qui utilise la StorageClass standard-rwo.
2. Créez un pod qui utilise le PVC.
3. Vérifiez que le pod peut lire/écrire des données dans le volume.
4. Supprimez le pod et le PVC une fois que vous avez vérifié que l'opération s'est déroulée correctement.

Si le provisionnement dynamique de volumes avec le pilote CSI vSphere fonctionne, exécutez gkectl diagnose ou gkectl upgrade avec l'indicateur --skip-validation-csi-workload pour ignorer la vérification de la charge de travail CSI.

Délai d'expiration de la mise à jour du cluster d'utilisateur lorsque la version du cluster d'administrateur est 1.15

Lorsque vous êtes connecté à un poste de travail administrateur géré par l'utilisateur, la commande gkectl update cluster peut expirer et ne pas mettre à jour le cluster d'utilisateur. Cela se produit si la version du cluster d'administrateur est 1.15 et que vous exécutez gkectl update admin avant d'exécuter gkectl update cluster. En cas d'échec, l'erreur suivante s'affiche lorsque vous essayez de mettre à jour le cluster :

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
      

Lors de la mise à jour d'un cluster d'administrateur 1.15, le validation-controller qui déclenche les vérifications préliminaires est supprimé du cluster. Si vous essayez ensuite de mettre à jour le cluster d'utilisateur, la vérification préliminaire se bloque jusqu'à ce que le délai d'attente soit atteint.

Solution :

1. Exécutez la commande suivante pour redéployer validation-controller :

         gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
         

2. Une fois la préparation terminée, exécutez à nouveau gkectl update cluster pour mettre à jour le cluster d'utilisateur.

Délai d'expiration de la création du cluster d'utilisateur lorsque la version du cluster d'administrateur est 1.15

Lorsque vous êtes connecté à un poste de travail administrateur géré par l'utilisateur, la commande gkectl create cluster peut expirer et échouer à créer le cluster d'utilisateur. Cela se produit si la version du cluster d'administrateur est 1.15. Lorsque cet échec se produit, l'erreur suivante s'affiche lorsque vous essayez de créer le cluster :

      Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
Preflight check failed with failed to run server-side preflight checks: server-side preflight checks failed: timed out waiting for the condition
      

Étant donné que validation-controller a été ajouté dans la version 1.16, lorsque vous utilisez un cluster d'administrateur 1.15, le validation-controller responsable du déclenchement des vérifications préalables est manquant. Par conséquent, lorsque vous essayez de créer un cluster d'utilisateur, les vérifications préliminaires se bloquent jusqu'à ce que le délai d'expiration soit atteint.

Solution :

1. Exécutez la commande suivante pour déployer validation-controller :

         gkectl prepare --kubeconfig ADMIN_KUBECONFIG --bundle-path BUNDLE_PATH --upgrade-platform
         

2. Une fois la préparation terminée, exécutez à nouveau gkectl create cluster pour créer le cluster d'utilisateur.

La mise à jour ou la mise à niveau du cluster d'administrateur échoue si les projets ou les emplacements des services de complément ne correspondent pas.

Lorsque vous mettez à niveau un cluster d'administrateur de la version 1.15.x vers la version 1.16.x, ou que vous ajoutez une configuration connect, stackdriver, cloudAuditLogging ou gkeOnPremAPI lorsque vous mettez à jour un cluster d'administrateur, l'opération peut être refusée par le webhook du cluster d'administrateur. L'un des messages d'erreur suivants peut s'afficher :

• "projects for connect, stackdriver and cloudAuditLogging must be the same when specified during cluster creation."
• "locations for connect, gkeOnPremAPI, stackdriver and cloudAuditLogging must be in the same region when specified during cluster creation."
• "locations for stackdriver and cloudAuditLogging must be the same when specified during cluster creation."

Une mise à jour ou une mise à niveau du cluster d'administrateur nécessite que onprem-admin-cluster-controller réconcilie le cluster d'administrateur dans un cluster Kind. Lorsque l'état du cluster d'administrateur est restauré dans le cluster Kind, le webhook du cluster d'administrateur ne peut pas déterminer si l'objet OnPremAdminCluster concerne la création d'un cluster d'administrateur ou la reprise des opérations pour une mise à jour ou une mise à niveau. Certaines validations de création uniquement sont appelées de manière inattendue lors de la mise à jour et de la mise à niveau.

Solution :

Ajoutez l'annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true à l'objet OnPremAdminCluster :

1. Modifiez la ressource de cluster onpremadminclusters :

   kubectl edit onpremadminclusters ADMIN_CLUSTER_NAME -n kube-system –kubeconfig ADMIN_CLUSTER_KUBECONFIG

   Remplacez les éléments suivants :
   • ADMIN_CLUSTER_NAME : nom du cluster d'administrateur.
   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
2. Ajoutez l'annotation onprem.cluster.gke.io/skip-project-location-sameness-validation: true et enregistrez la ressource personnalisée.
3. En fonction du type de clusters d'administrateur, effectuez l'une des étapes suivantes :
   • Pour les clusters d'administrateur non HD avec un fichier de point de contrôle : ajoutez le paramètre disable-update-from-checkpoint dans la commande update, ou ajoutez le paramètre `disable-upgrade-from-checkpoint` dans la commande upgrade. Ces paramètres ne sont nécessaires que la prochaine fois que vous exécuterez la commande update ou upgrade :
     • gkectl update admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         --disable-update-from-checkpoint

     • gkectl upgrade admin --config ADMIN_CONFIG_file --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
         --disable-upgrade-from-checkpoint

   • Pour les clusters d'administrateur HD ou si le fichier de point de contrôle est désactivé : mettez à jour ou migrez le cluster d'administrateur comme d'habitude. Aucun paramètre supplémentaire n'est nécessaire pour les commandes de mise à jour ou de mise à niveau.

Échec de la suppression d'un cluster d'utilisateur lors de l'utilisation d'un poste de travail administrateur géré par l'utilisateur

Lorsque vous êtes connecté à un poste de travail administrateur géré par l'utilisateur, la commande gkectl delete cluster peut expirer et ne pas supprimer le cluster d'utilisateur. Cela se produit si vous avez d'abord exécuté gkectl sur le poste de travail géré par l'utilisateur pour créer, mettre à jour ou mettre à niveau le cluster d'utilisateur. Lorsque cet échec se produit, l'erreur suivante s'affiche lorsque vous essayez de supprimer le cluster :

      failed to wait for user cluster management namespace "USER_CLUSTER_NAME-gke-onprem-mgmt"
      to be deleted: timed out waiting for the condition
      

Lors de la suppression, un cluster supprime d'abord tous ses objets. La suppression des objets de validation (créés lors de la création, de la mise à jour ou de la mise à niveau) est bloquée à la phase de suppression. Cela se produit parce qu'un finaliseur bloque la suppression de l'objet, ce qui entraîne l'échec de la suppression du cluster.

Solution :

1. Obtenez les noms de tous les objets de validation :

            kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
              -n USER_CLUSTER_NAME-gke-onprem-mgmt
           

2. Pour chaque objet Validation, exécutez la commande suivante afin de supprimer le finaliseur de l'objet Validation :

         kubectl --kubeconfig ADMIN_KUBECONFIG patch validation/VALIDATION_OBJECT_NAME \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt -p '{"metadata":{"finalizers":[]}}' --type=merge
         

   Une fois le finaliseur supprimé de tous les objets de validation, les objets sont supprimés et l'opération de suppression du cluster utilisateur se termine automatiquement. Aucune action supplémentaire n'est requise de votre part.

Échec du trafic de la passerelle NAT de sortie vers le serveur externe

Si le pod source et le pod de passerelle NAT de sortie se trouvent sur deux nœuds de calcul différents, le trafic provenant du pod source ne peut pas atteindre les services externes. Si les pods sont situés sur le même hôte, la connexion au service ou à l'application externes est établie.

Ce problème est dû à vSphere qui supprime les paquets VXLAN lorsque l'agrégation de tunnels est activée. Il existe un problème connu avec NSX et VMware qui n'envoie que le trafic agrégé sur les ports VXLAN connus (4789).

Solution :

Modifiez le port VXLAN utilisé par Cilium sur 4789 :

1. Modifiez le fichier ConfigMap cilium-config :

   kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

2. Ajoutez ce qui suit au fichier ConfigMap cilium-config :

   tunnel-port: 4789

3. Redémarrez le DaemonSet anetd :

   kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

Cette solution de contournement est annulée chaque fois que le cluster est mis à niveau. Vous devez reconfigurer après chaque mise à niveau. VMware doit résoudre le problème dans vSphere pour une correction permanente.

Échec de la mise à niveau d'un cluster d'administrateur avec le chiffrement permanent des secrets activé

La mise à niveau du cluster d'administrateur de la version 1.14.x vers la version 1.15.x avec le chiffrement des secrets toujours activé échoue en raison d'une incompatibilité entre la clé de chiffrement générée par le contrôleur et celle qui persiste sur le disque de données maître de l'administrateur. Le résultat de gkectl upgrade admin contient le message d'erreur suivant :

      E0926 14:42:21.796444   40110 console.go:93] Exit with error:
      E0926 14:42:21.796491   40110 console.go:93] Failed to upgrade the admin cluster: failed to create admin cluster: failed to wait for OnPremAdminCluster "admin-cluster-name" to become ready: failed to wait for OnPremAdminCluster "admin-cluster-name" to be ready: error: timed out waiting for the condition, message: failed to wait for OnPremAdminCluster "admin-cluster-name" to stay in ready status for duration "2m0s": OnPremAdminCluster "non-prod-admin" is not ready: ready condition is not true: CreateOrUpdateControlPlane: Creating or updating credentials for cluster control plane
      

L'exécution de kubectl get secrets -A --kubeconfig KUBECONFIG` échoue avec l'erreur suivante :

      Internal error occurred: unable to transform key "/registry/secrets/anthos-identity-service/ais-secret": rpc error: code = Internal desc = failed to decrypt: unknown jwk
      

Solution

Si vous disposez d'une sauvegarde du cluster d'administrateur, procédez comme suit pour contourner l'échec de la mise à niveau :

1. Désactivez secretsEncryption dans le fichier de configuration du cluster d'administrateur, puis mettez à jour le cluster à l'aide de la commande suivante :

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

2. Une fois la nouvelle VM maître de l'administrateur créée, connectez-vous en SSH à la VM maître de l'administrateur, puis remplacez la nouvelle clé sur le disque de données par l'ancienne clé de la sauvegarde. La clé se trouve à l'adresse /opt/data/gke-k8s-kms-plugin/generatedkeys sur le système maître administrateur.
3. Mettez à jour le fichier manifeste Pod statique kms-plugin.yaml dans /etc/kubernetes/manifests pour mettre à jour --kek-id afin qu'il corresponde au champ kid de la clé de chiffrement d'origine.
4. Redémarrez le pod statique kms-plugin en déplaçant le fichier /etc/kubernetes/manifests/kms-plugin.yaml vers un autre répertoire, puis en le replaçant.
5. Reprenez la mise à niveau pour les administrateurs en exécutant à nouveau gkectl upgrade admin.

Éviter l'échec de la mise à niveau

Si vous ne l'avez pas encore fait, nous vous recommandons de ne pas passer à la version 1.15.0-1.15.4. Si vous devez passer à une version concernée, procédez comme suit avant de mettre à niveau le cluster d'administrateur :

1. Sauvegardez le cluster d'administrateur.
2. Désactivez secretsEncryption dans le fichier de configuration du cluster d'administrateur, puis mettez à jour le cluster à l'aide de la commande suivante :

   gkectl update admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG

3. Mettez à niveau le cluster d'administrateur.
4. Réactivez le chiffrement des secrets toujours activé.

Erreurs de disque et échecs d'association lors de l'utilisation du suivi des blocs modifiés (CBT)

Google Distributed Cloud n'est pas compatible avec le suivi des blocs modifiés (CBT) sur les disques. Certains logiciels de sauvegarde utilisent la fonctionnalité CBT pour suivre l'état du disque et effectuer des sauvegardes, ce qui empêche le disque de se connecter à une VM exécutant Google Distributed Cloud. Pour en savoir plus, consultez l'article de la base de connaissances VMware.

Solution :

Ne sauvegardez pas les VM Google Distributed Cloud, car les logiciels de sauvegarde tiers peuvent activer le CBT sur leurs disques. Il n'est pas nécessaire de sauvegarder ces VM.

N'activez pas CBT sur le nœud, car cette modification ne sera pas conservée lors des mises à jour ou des mises à niveau.

Si vous disposez déjà de disques avec CBT activé, suivez les étapes de la section Résolution de l'article de la base de connaissances VMware pour désactiver CBT sur le disque First Class.

Corruption de données sur NFSv3 lorsque des ajouts parallèles à un fichier partagé sont effectués à partir de plusieurs hôtes

Si vous utilisez des baies de stockage Nutanix pour fournir des partages NFSv3 à vos hôtes, vous risquez de rencontrer des problèmes de corruption de données ou d'impossibilité d'exécuter correctement les pods. Ce problème est dû à un problème de compatibilité connu entre certaines versions de VMware et de Nutanix. Pour en savoir plus, consultez l'article de la base de connaissances VMware associé.

Solution :

L'article de la base de connaissances VMware est obsolète, car il indique qu'il n'existe aucune solution actuelle. Pour résoudre ce problème, installez la dernière version d'ESXi sur vos hôtes et la dernière version de Nutanix sur vos baies de stockage.

Incompatibilité de version entre le kubelet et le plan de contrôle Kubernetes

Pour certaines versions de Google Distributed Cloud, le kubelet exécuté sur les nœuds utilise une version différente de celle du plan de contrôle Kubernetes. Il existe une incompatibilité, car le binaire kubelet préchargé sur l'image OS utilise une version différente.

Le tableau suivant répertorie les différences de version identifiées :

Solution :

Aucune action n'est requise de votre part. L'incohérence ne concerne que les versions correctives de Kubernetes. Ce décalage de version n'a causé aucun problème.

Échec de la mise à niveau ou de la mise à jour d'un cluster d'administrateur avec une version d'autorité de certification supérieure à 1

Lorsqu'un cluster d'administrateur possède une version d'autorité de certification supérieure à 1, une mise à jour ou une mise à niveau échoue en raison de la validation de la version de l'autorité de certification dans le webhook. Le résultat de la mise à niveau/mise à jour gkectl contient le message d'erreur suivant :

    CAVersion must start from 1
    

Solution :

• Réduisez le déploiement auto-resize-controller dans le cluster d'administrateur pour désactiver le redimensionnement automatique des nœuds. Cela est nécessaire, car un nouveau champ introduit dans la ressource personnalisée du cluster d'administrateur dans la version 1.15 peut entraîner une erreur de pointeur nul dans auto-resize-controller.

   kubectl scale deployment auto-resize-controller -n kube-system --replicas=0 --kubeconfig KUBECONFIG
        

•  Exécutez les commandes gkectl avec l'option --disable-admin-cluster-webhook.Par exemple :

          gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG_FILE --kubeconfig KUBECONFIG --disable-admin-cluster-webhook
          

La suppression d'un cluster Controlplane V2 sans haute disponibilité est bloquée jusqu'à expiration du délai

Lorsqu'un cluster Controlplane V2 sans haute disponibilité est supprimé, il reste bloqué au niveau de la suppression des nœuds jusqu'à ce qu'il expire.

Solution :

Si le cluster contient un StatefulSet avec des données critiques, contactez Cloud Customer Care pour résoudre ce problème.

Sinon, procédez comme suit :

• Supprimez toutes les VM du cluster de vSphere. Vous pouvez supprimer les VM via l'interface utilisateur vSphere ou exécuter la commande suivante :

        govc vm.destroy

  .
• Forcez à nouveau la suppression du cluster :

       gkectl delete cluster --cluster USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG --force
       

Des tâches attachvolume CNS constantes apparaissent toutes les minutes pour les PVC/PV intégrés après la mise à niveau vers la version 1.15 ou ultérieure.

Lorsqu'un cluster contient des volumes persistants vSphere "in-tree" (par exemple, des PVC créés avec la StorageClass standard), vous verrez des tâches com.vmware.cns.tasks.attachvolume déclenchées toutes les minutes à partir de vCenter.

Solution :

Modifiez le fichier ConfigMap de la fonctionnalité vSphere CSI et définissez list-volumes sur "false" :

     kubectl edit configmap internal-feature-states.csi.vsphere.vmware.com -n kube-system --kubeconfig KUBECONFIG
     

Redémarrez les pods du contrôleur CSI vSphere :

     kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    

Faux avertissements concernant les PVC

Lorsqu'un cluster contient des volumes persistants vSphere intégrés, les commandes gkectl diagnose et gkectl upgrade peuvent générer de faux avertissements concernant leurs demandes de volume persistant (PVC) lors de la validation des paramètres de stockage du cluster. Le message d'avertissement se présente comme suit :

    CSIPrerequisites pvc/pvc-name: PersistentVolumeClaim pvc-name bounds to an in-tree vSphere volume created before CSI migration enabled, but it doesn't have the annotation pv.kubernetes.io/migrated-to set to csi.vsphere.vmware.com after CSI migration is enabled
    

Solution :

Exécutez la commande suivante pour vérifier les annotations d'un PVC avec l'avertissement ci-dessus :

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -oyaml --kubeconfig KUBECONFIG
    

Si le champ annotations du résultat contient les éléments suivants, vous pouvez ignorer l'avertissement :

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
    

Échec de la rotation des clés de compte de service lorsque plusieurs clés ont expiré

Si votre cluster n'utilise pas de registre privé et que les clés de compte de service d'accès aux composants et de compte de service Logging-monitoring (ou Connect-register) ont expiré, lorsque vous faites pivoter les clés de compte de service, gkectl update credentials échoue et affiche une erreur semblable à la suivante :

Error: reconciliation failed: failed to update platform: ...

Solution :

Commencez par alterner la clé du compte de service d'accès aux composants. Bien que le même message d'erreur s'affiche, vous devriez pouvoir alterner les autres clés après la rotation des clés du compte de service d'accès aux composants.

Si la mise à jour ne fonctionne toujours pas, contactez l'assistance Cloud Customer Care pour résoudre ce problème.

1.15 : La machine maître utilisateur rencontre une recréation inattendue lorsque le contrôleur de cluster d'utilisateur est mis à niveau vers la version 1.16

Lors de la mise à niveau d'un cluster d'utilisateur, une fois le contrôleur de cluster d'utilisateur mis à niveau vers la version 1.16, si vous avez d'autres clusters d'utilisateur 1.15 gérés par le même cluster d'administrateur, leur machine maître utilisateur peut être recréée de manière inattendue.

Un bug dans le contrôleur de cluster d'utilisateur 1.16 peut déclencher la recréation de la machine maître utilisateur 1.15.

La solution de contournement dépend de la manière dont vous rencontrez ce problème.

Solution de contournement lors de la mise à niveau du cluster d'utilisateur à l'aide de la console Google Cloud  :

Option 1 : Utilisez une version 1.16.6 ou ultérieure de GKE sur VMware avec le correctif.

Option 2 : Procédez comme suit :

1. Ajoutez manuellement l'annotation de réexécution à l'aide de la commande suivante :

   kubectl edit onpremuserclusters USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt --kubeconfig ADMIN_KUBECONFIG

   L'annotation de rediffusion est la suivante :

   onprem.cluster.gke.io/server-side-preflight-rerun: true

2. Surveillez la progression de la mise à niveau en vérifiant le champ status de OnPremUserCluster.

Solution de contournement pour la mise à niveau du cluster d'utilisateur à l'aide de votre propre poste de travail administrateur :

Option 1 : Utilisez une version 1.16.6 ou ultérieure de GKE sur VMware avec le correctif.

Option 2 : Procédez comme suit :

1. Ajoutez le fichier d'informations sur la compilation /etc/cloud/build.info avec le contenu suivant. Les vérifications préliminaires sont alors exécutées localement sur votre poste de travail administrateur plutôt que sur le serveur.

   gke_on_prem_version: GKE_ON_PREM_VERSION

   Par exemple :

   gke_on_prem_version: 1.16.0-gke.669

2. Réexécutez la commande de mise à niveau.
3. Une fois la mise à niveau terminée, supprimez le fichier build.info.

La vérification préliminaire échoue lorsque le nom d'hôte ne figure pas dans le fichier de bloc d'adresses IP.

Lors de la création du cluster, si vous ne spécifiez pas de nom d'hôte pour chaque adresse IP du fichier de bloc d'adresses IP, la vérification préliminaire échoue et le message d'erreur suivant s'affiche :

multiple VMs found by DNS name  in xxx datacenter. Anthos Onprem doesn't support duplicate hostname in the same vCenter and you may want to rename/delete the existing VM.`
    

Un bug dans la vérification préliminaire considère un nom d'hôte vide comme un doublon.

Solution :

Option 1 : Utilisez une version contenant le correctif.

Option 2 : Contournez cette vérification préliminaire en ajoutant l'option --skip-validation-net-config.

Option 3 : Spécifiez un nom d'hôte unique pour chaque adresse IP dans le fichier de bloc d'adresses IP.

Échec du montage du volume lors de la mise à niveau/mise à jour du cluster d'administrateur si vous utilisez un cluster d'administrateur sans haute disponibilité et un cluster d'utilisateur avec plan de contrôle V1

Pour un cluster d'administrateur non HA et un cluster d'utilisateur de plan de contrôle v1, lorsque vous mettez à niveau ou à jour le cluster d'administrateur, la recréation de la machine maître du cluster d'administrateur peut se produire en même temps que le redémarrage de la machine maître du cluster d'utilisateur, ce qui peut entraîner une condition de concurrence. Cela empêche les pods du plan de contrôle du cluster d'utilisateur de communiquer avec le plan de contrôle du cluster d'administrateur, ce qui entraîne des problèmes d'association de volumes pour kube-etcd et kube-apiserver sur le plan de contrôle du cluster d'utilisateur.

Pour vérifier le problème, exécutez les commandes suivantes pour le pod concerné :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace USER_CLUSTER_NAME describe pod IMPACTED_POD_NAME

Events:
  Type     Reason       Age                  From               Message
  ----     ------       ----                 ----               -------
  Warning  FailedMount  101s                 kubelet            Unable to attach or mount volumes: unmounted volumes=[kube-audit], unattached volumes=[], failed to process volumes=[]: timed out waiting for the condition
  Warning  FailedMount  86s (x2 over 3m28s)  kubelet            MountVolume.SetUp failed for volume "pvc-77cd0635-57c2-4392-b191-463a45c503cb" : rpc error: code = FailedPrecondition desc = volume ID: "bd313c62-d29b-4ecd-aeda-216648b0f7dc" does not appear staged to "/var/lib/kubelet/plugins/kubernetes.io/csi/csi.vsphere.vmware.com/92435c96eca83817e70ceb8ab994707257059734826fedf0c0228db6a1929024/globalmount"

Solution :

1. Connectez-vous en SSH au nœud du plan de contrôle de l'utilisateur. Étant donné qu'il s'agit d'un cluster d'utilisateur Controlplane V1, le nœud du plan de contrôle de l'utilisateur se trouve dans le cluster d'administrateur.
2. Redémarrez kubelet à l'aide de la commande suivante :

       sudo systemctl restart kubelet
       

   Après le redémarrage, le kubelet peut reconstruire correctement le montage global de l'étape.

Échec de la création du nœud du plan de contrôle

Lors de la mise à niveau ou de la mise à jour d'un cluster d'administrateur, une condition de concurrence peut entraîner la suppression inattendue d'un nouveau nœud de plan de contrôle par le gestionnaire de contrôleur cloud vSphere. Cela entraîne le blocage du clusterapi-controller en attente de la création du nœud, et la mise à niveau/mise à jour finit par expirer. Dans ce cas, le résultat de la commande de mise à niveau/mise à jour gkectl ressemble à ce qui suit :

    controlplane 'default/gke-admin-hfzdg' is not ready: condition "Ready": condition is not ready with reason "MachineInitializing", message "Wait for the control plane machine "gke-admin-hfzdg-6598459f9zb647c8-0\" to be rebooted"...
    

Pour identifier le symptôme, exécutez la commande ci-dessous afin d'obtenir le journal du gestionnaire de contrôleur cloud vSphere dans le cluster d'administrateur :

    kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
    kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
    

Voici un exemple de message d'erreur généré par la commande ci-dessus :

    node name: 81ff17e25ec6-qual-335-1500f723 has a different uuid. Skip deleting this node from cache.
    

Solution :

1. Redémarrez la machine ayant échoué pour recréer l'objet nœud supprimé.
2. Connectez-vous en SSH à chaque nœud du plan de contrôle et redémarrez le pod statique du gestionnaire de contrôleur cloud vSphere :

         sudo crictl ps | grep vsphere-cloud-controller-manager | awk '{print $1}'
         sudo crictl stop PREVIOUS_COMMAND_OUTPUT
         

3. Réexécutez la commande de mise à niveau/mise à jour.

Un nom d'hôte en double dans le même centre de données entraîne l'échec de la mise à niveau ou de la création du cluster

La mise à niveau d'un cluster 1.15 ou la création d'un cluster 1.16 avec des adresses IP statiques échouent si des noms d'hôte en double existent dans le même centre de données. Cet échec se produit, car le gestionnaire de contrôleur de cloud vSphere ne parvient pas à ajouter d'adresse IP externe ni d'ID de fournisseur dans l'objet de nœud. Cela entraîne l'expiration du délai d'attente pour la mise à niveau ou la création du cluster.

Pour identifier le problème, obtenez les journaux du pod vSphere Cloud Controller Manager pour le cluster. La commande que vous utilisez dépend du type de cluster, comme suit :

• Cluster d'administrateur :

        kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n kube-system
        

• Cluster d'utilisateur avec enableControlplaneV2 false :

        kubectl get pods --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAME
        

• Cluster d'utilisateur avec enableControlplaneV2 true :

        kubectl get pods --kubeconfig USER_KUBECONFIG -n kube-system | grep vsphere-cloud-controller-manager
        kubectl logs -f vsphere-cloud-controller-manager-POD_NAME_SUFFIX --kubeconfig USER_KUBECONFIG -n kube-system
        

Voici un exemple de message d'erreur :

    I1003 17:17:46.769676       1 search.go:152] Finding node admin-vm-2 in vc=vcsa-53598.e5c235a1.asia-northeast1.gve.goog and datacenter=Datacenter
    E1003 17:17:46.771717       1 datacenter.go:111] Multiple vms found VM by DNS Name. DNS Name: admin-vm-2
    

Vérifiez si le nom d'hôte est en double dans le centre de données :

          export GOVC_DATACENTER=GOVC_DATACENTER
          export GOVC_URL=GOVC_URL
          export GOVC_USERNAME=GOVC_USERNAME
          export GOVC_PASSWORD=GOVC_PASSWORD
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName HOSTNAME
          

          export GOVC_DATACENTER=mtv-lifecycle-vc01
          export GOVC_URL=https://mtv-lifecycle-vc01.anthos/sdk
          export GOVC_USERNAME=xxx
          export GOVC_PASSWORD=yyy
          export GOVC_INSECURE=true
          govc find . -type m -guest.hostName f8c3cd333432-lifecycle-337-xxxxxxxz
          ./vm/gke-admin-node-6b7788cd76-wkt8g
          ./vm/gke-admin-node-6b7788cd76-99sg2
          ./vm/gke-admin-master-5m2jb
          

La solution de contournement à appliquer dépend de l'opération qui a échoué.

Solution de contournement pour les mises à niveau :

Appliquez la solution de contournement pour le type de cluster concerné.

• Cluster d'utilisateur :
  1. Remplacez le nom d'hôte de la machine concernée dans user-ip-block.yaml par un nom unique, puis déclenchez une mise à jour forcée :
     

               gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config NEW_USER_CLUSTER_CONFIG --force
               

  2. Réexécuter gkectl upgrade cluster
• Cluster d'administrateur :
  1. Modifiez le nom d'hôte de la machine concernée dans admin-ip-block.yaml en lui attribuant un nom unique, puis déclenchez une mise à jour forcée :
     

               gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config NEW_ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
               

  2. S'il s'agit d'un cluster d'administrateur non haute disponibilité et que vous constatez que la VM maître d'administrateur utilise un nom d'hôte en double, vous devez également :
     Obtenir le nom de la machine maître d'administrateur

               kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
               

     Mettez à jour l'objet de la machine maître de l'administrateur.
     Remarque : NEW_ADMIN_MASTER_HOSTNAME doit être identique à ce que vous avez défini dans admin-ip-block.yaml à l'étape 1.
     

               kubectl patch machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG --type='json' -p '[{"op": "replace", "path": "/spec/providerSpec/value/networkSpec/address/hostname", "value":"NEW_ADMIN_MASTER_HOSTNAME"}]'
               

     Vérifiez que le nom d'hôte est mis à jour dans l'objet de la machine maître de l'administrateur :
     

               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -oyaml
               kubectl get machine ADMIN_MASTER_MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG -o jsonpath='{.spec.providerSpec.value.networkSpec.address.hostname}'
               

  3. Relancez la mise à niveau du cluster d'administrateur avec le point de contrôle désactivé :
     

               gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint
               

Solution pour les installations :

Appliquez la solution de contournement pour le type de cluster concerné.

• Cluster d'administrateur :
  1. Supprimez la machine du nœud d'administrateur.
  2. Supprimez le disque de données.
  3. Supprimez le fichier de point de contrôle du cluster d'administrateur.
  4. Modifiez le nom d'hôte de la machine concernée dans admin-ip-block.yaml en lui attribuant un nom unique.
  5. Réexécutez gkectl create admin.
• Cluster d'utilisateur :
  1. Nettoyez les ressources.
  2. Modifiez le nom d'hôte de la machine concernée dans user-ip-block.yaml en lui attribuant un nom unique.
  3. Réexécutez gkectl create cluster.

$ et ` ne sont pas acceptés dans le nom d'utilisateur ni le mot de passe vSphere.

Les opérations suivantes échouent lorsque le nom d'utilisateur ou le mot de passe vSphere contiennent $ ou ` :

• Mettre à niveau un cluster d'utilisateur 1.15 avec Controlplane V2 activé vers la version 1.16
• Mettre à niveau un cluster d'administrateur haute disponibilité (HD) 1.15 vers la version 1.16
• Créer un cluster d'utilisateur 1.16 avec Controlplane V2 activé
• Créer un cluster d'administrateur haute disponibilité 1.16

Utilisez une version 1.16.4 ou ultérieure de Google Distributed Cloud avec le correctif, ou appliquez la solution de contournement ci-dessous. La solution de contournement à appliquer dépend de l'opération qui a échoué.

Solution de contournement pour les mises à niveau :

1. Modifiez le nom d'utilisateur ou le mot de passe vCenter côté vCenter pour supprimer $ et `.
2. Mettez à jour le nom d'utilisateur ou le mot de passe vCenter dans votre fichier de configuration des identifiants.
3. Déclenchez une mise à jour forcée du cluster.
• Cluster d'utilisateur :

          gkectl update cluster --kubeconfig ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG --force
          

• Cluster d'administrateur :

          gkectl update admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --force --skip-cluster-ready-check
          

Solution pour les installations :

1. Modifiez le nom d'utilisateur ou le mot de passe vCenter côté vCenter pour supprimer $ et `.
2. Mettez à jour le nom d'utilisateur ou le mot de passe vCenter dans votre fichier de configuration des identifiants.
3. Appliquez la solution de contournement pour le type de cluster concerné.
• Cluster d'administrateur :
  1. Supprimez la machine du nœud d'administrateur.
  2. Supprimez le disque de données.
  3. Supprimez le fichier de point de contrôle du cluster d'administrateur.
  4. Réexécutez gkectl create admin.
• Cluster d'utilisateur :
  1. Nettoyez les ressources.
  2. Réexécutez gkectl create cluster.

Échec de la création de PVC après la recréation du nœud avec le même nom

Après la suppression d'un nœud, puis sa recréation avec le même nom, il est possible qu'une création ultérieure de PersistentVolumeClaim (PVC) échoue avec une erreur semblable à la suivante :

    The object 'vim.VirtualMachine:vm-988369' has already been deleted or has not been completely created

Cela est dû à une condition de concurrence dans laquelle le contrôleur CSI vSphere ne supprime pas une machine supprimée de son cache.

Solution :

Redémarrez les pods du contrôleur CSI vSphere :

    kubectl rollout restart deployment vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
    

gkectl repair admin-master renvoie une erreur de désérialisation kubeconfig

Lorsque vous exécutez la commande gkectl repair admin-master sur un cluster d'administrateur HA, gkectl renvoie le message d'erreur suivant :

  Exit with error: Failed to repair: failed to select the template: failed to get cluster name from kubeconfig, please contact Google support. failed to decode kubeconfig data: yaml: unmarshal errors:
    line 3: cannot unmarshal !!seq into map[string]*api.Cluster
    line 8: cannot unmarshal !!seq into map[string]*api.Context
  

Solution :

Ajoutez l'indicateur --admin-master-vm-template= à la commande et fournissez le modèle de VM de la machine à réparer :

  gkectl repair admin-master --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --admin-master-vm-template=/DATA_CENTER/vm/VM_TEMPLATE_NAME
  

Pour trouver le modèle de VM de la machine :

1. Accédez à la page Hôtes et clusters dans le client vSphere.
2. Cliquez sur Modèles de VM et filtrez par nom de cluster d'administrateur.

   Vous devriez voir les trois modèles de VM pour le cluster d'administrateur.

3. Copiez le nom du modèle de VM qui correspond au nom de la machine que vous réparez, puis utilisez ce nom dans la commande de réparation.

  gkectl repair admin-master \
      --config=/home/ubuntu/admin-cluster.yaml \
      --kubeconfig=/home/ubuntu/kubeconfig \
      --admin-master-vm-template=/atl-qual-vc07/vm/gke-admin-98g94-zx...7vx-0-tmpl

VM Seesaw défectueuse en raison d'un manque d'espace disque

Si vous utilisez Seesaw comme type d'équilibreur de charge pour votre cluster et que vous constatez qu'une VM Seesaw est hors service ou ne cesse d'échouer au démarrage, le message d'erreur suivant peut s'afficher dans la console vSphere :

    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd
    

Cette erreur indique que l'espace disque est faible sur la VM, car fluent-bit exécuté sur la VM Seesaw n'est pas configuré avec la rotation des journaux appropriée.

Solution :

Localisez les fichiers journaux qui consomment le plus d'espace disque à l'aide de du -sh -- /var/lib/docker/containers/* | sort -rh. Nettoyez le fichier journal le plus volumineux et redémarrez la VM.

Remarque : Si la VM est complètement inaccessible, associez le disque à une VM fonctionnelle (par exemple, une station de travail d'administrateur), supprimez le fichier du disque associé, puis réassociez le disque à la VM Seesaw d'origine.

Pour éviter que le problème ne se reproduise, connectez-vous à la VM et modifiez le fichier /etc/systemd/system/docker.fluent-bit.service. Ajoutez --log-opt max-size=10m --log-opt max-file=5 dans la commande Docker, puis exécutez systemctl restart docker.fluent-bit.service.

Erreur de clé publique SSH de l'administrateur après la mise à niveau ou la mise à jour du cluster d'administrateur

Lorsque vous essayez de mettre à niveau (gkectl upgrade admin) ou de mettre à jour (gkectl update admin) un cluster d'administrateur non haute disponibilité avec le point de contrôle activé, la mise à niveau ou la mise à jour peut échouer et générer des erreurs telles que les suivantes :

Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).

failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)

error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...

Solution :

Si vous ne parvenez pas à passer à une version corrective de Google Distributed Cloud contenant le correctif, contactez l'assistance Google pour obtenir de l'aide.

La mise à niveau d'un cluster d'administrateur enregistré dans l'API GKE On-Prem peut échouer

Lorsqu'un cluster d'administrateur est enregistré dans l'API GKE On-Prem, la mise à niveau du cluster d'administrateur vers les versions concernées peut échouer, car l'appartenance au parc n'a pas pu être mise à jour. Lorsque cet échec se produit, l'erreur suivante s'affiche lorsque vous essayez de mettre à niveau le cluster :

    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated
    

Un cluster d'administrateur est enregistré dans l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client d'API GKE On-Prem.

Solution :

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

L'annotation du lien de ressource du cluster d'administrateur enregistré n'est pas conservée

Lorsqu'un cluster d'administrateur est enregistré dans l'API GKE On-Prem, son annotation de lien de ressource est appliquée à la ressource personnalisée OnPremAdminCluster, qui n'est pas conservée lors des mises à jour ultérieures du cluster d'administrateur en raison de la clé d'annotation incorrecte utilisée. Cela peut entraîner l'enregistrement du cluster d'administrateur dans l'API GKE On-Prem par erreur.

Un cluster d'administrateur est enregistré dans l'API lorsque vous enregistrez explicitement le cluster ou lorsque vous mettez à niveau un cluster d'utilisateur à l'aide d'un client d'API GKE On-Prem.

Solution :

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
    

CoreDNS orderPolicy non reconnu

OrderPolicy n'est pas reconnu comme paramètre et n'est pas utilisé. Google Distributed Cloud utilise toujours Random.

Ce problème se produit, car le modèle CoreDNS n'a pas été mis à jour, ce qui entraîne l'ignorance de orderPolicy.

Solution :

Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif est conservé jusqu'à une mise à niveau.

1. Modifiez le modèle existant :

   kubectl edit cm -n kube-system coredns-template

   Remplacez le contenu du modèle par le code suivant :

   coredns-template: |-
     .:53 {
       errors
       health {
         lameduck 5s
       }
       ready
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods insecure
         fallthrough in-addr.arpa ip6.arpa
       }
   {{- if .PrivateGoogleAccess }}
       import zones/private.Corefile
   {{- end }}
   {{- if .RestrictedGoogleAccess }}
       import zones/restricted.Corefile
   {{- end }}
       prometheus :9153
       forward . {{ .UpstreamNameservers }} {
         max_concurrent 1000
         {{- if ne .OrderPolicy "" }}
         policy {{ .OrderPolicy }}
         {{- end }}
       }
       cache 30
   {{- if .DefaultDomainQueryLogging }}
       log
   {{- end }}
       loop
       reload
       loadbalance
   }{{ range $i, $stubdomain := .StubDomains }}
   {{ $stubdomain.Domain }}:53 {
     errors
   {{- if $stubdomain.QueryLogging }}
     log
   {{- end }}
     cache 30
     forward . {{ $stubdomain.Nameservers }} {
       max_concurrent 1000
       {{- if ne $.OrderPolicy "" }}
       policy {{ $.OrderPolicy }}
       {{- end }}
     }
   }
   {{- end }}

L'état OnPremAdminCluster est incohérent entre le point de contrôle et le CR réel.

Certaines conditions de concurrence peuvent entraîner une incohérence de l'état OnPremAdminCluster entre le point de contrôle et le taux de couverture réel. Lorsque le problème se produit, l'erreur suivante peut s'afficher lorsque vous mettez à jour le cluster d'administrateur après l'avoir mis à niveau :

Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated

Le processus de réconciliation modifie les certificats d'administrateur sur les clusters d'administrateur

Google Distributed Cloud modifie les certificats d'administrateur sur les plans de contrôle du cluster d'administrateur à chaque processus de réconciliation, par exemple lors de la mise à niveau d'un cluster. Ce comportement augmente le risque d'obtenir des certificats non valides pour votre cluster d'administrateur, en particulier pour les clusters de version 1.15.

Si vous êtes concerné par ce problème, vous pouvez rencontrer les problèmes suivants :

• Des certificats non valides peuvent entraîner un délai d'expiration et des erreurs pour les commandes suivantes :
  • gkectl create admin
  • gkectl upgrade amdin
  • gkectl update admin

  Ces commandes peuvent renvoyer des erreurs d'autorisation telles que les suivantes :

  Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized

• Les journaux kube-apiserver de votre cluster d'administrateur peuvent contenir des erreurs telles que les suivantes :

  Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Solution :

Passez à une version de Google Distributed Cloud contenant le correctif : 1.13.10+, 1.14.6+ ou 1.15.2+. Si la mise à niveau n'est pas possible pour vous, contactez l'Cloud Customer Care pour résoudre ce problème.

Composants Anthos Network Gateway évincés ou en attente en raison d'une classe de priorité manquante

Les pods de passerelle réseau à l'état kube-system peuvent afficher l'état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé suivant :

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Ces erreurs indiquent des événements d'éviction ou l'impossibilité de planifier des pods en raison des ressources des nœuds. Comme les pods Anthos Network Gateway n'ont pas de PriorityClass, ils ont la même priorité par défaut que les autres charges de travail. Lorsque les ressources des nœuds sont limitées, les pods de passerelle réseau peuvent être évincés. Ce comportement est particulièrement problématique pour le DaemonSet ang-node, car ces pods doivent être planifiés sur un nœud spécifique et ne peuvent pas migrer.

Solution :

Effectuez une mise à niveau vers la version 1.15 ou ultérieure.

Pour résoudre le problème à court terme, vous pouvez attribuer manuellement une PriorityClass aux composants Anthos Network Gateway. Le contrôleur Google Distributed Cloud écrase ces modifications manuelles lors d'un processus de réconciliation, par exemple lors d'une mise à niveau du cluster.

• Attribuez la PriorityClass system-cluster-critical aux déploiements de contrôleurs de cluster ang-controller-manager et autoscaler.
• Attribuez la PriorityClass system-node-critical au DaemonSet de nœud ang-daemon.

Échec de la mise à niveau du cluster d'administrateur après l'enregistrement du cluster avec gcloud

Après avoir utilisé gcloud pour enregistrer un cluster d'administrateur avec une section gkeConnect non vide, l'erreur suivante peut s'afficher lorsque vous essayez de mettre à niveau le cluster :

failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Supprimez l'espace de noms gke-connect :

kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME

gkectl diagnose snapshot --log-since n'a pas réussi à limiter la période pour les commandes journalctl exécutées sur les nœuds du cluster.

Cela n'affecte pas la fonctionnalité de création d'un instantané du cluster, car l'instantané inclut toujours tous les journaux collectés par défaut en exécutant journalctl sur les nœuds du cluster. Par conséquent, aucune information de débogage n'est manquée.

Échec de gkectl prepare windows

gkectl prepare windows ne parvient pas à installer Docker sur les versions de Google Distributed Cloud antérieures à la version 1.13, car MicrosoftDockerProvider est obsolète.

Solution :

L'idée générale pour contourner ce problème est de passer à Google Distributed Cloud 1.13 et d'utiliser gkectl 1.13 pour créer un modèle de VM Windows, puis créer des pools de nœuds Windows. Il existe deux options pour passer de votre version actuelle à Google Distributed Cloud 1.13, comme indiqué ci-dessous.

Remarque : Nous avons des solutions pour contourner ce problème dans votre version actuelle sans avoir à passer à la version 1.13, mais cela nécessitera plus d'étapes manuelles. Veuillez contacter notre équipe d'assistance si vous souhaitez envisager cette option.

Option 1 : Mise à niveau bleu-vert

Vous pouvez créer un cluster à l'aide de Google Distributed Cloud version 1.13 ou ultérieure avec des pools de nœuds Windows, migrer vos charges de travail vers le nouveau cluster, puis supprimer le cluster actuel. Nous vous recommandons d'utiliser la dernière version mineure de Google Distributed Cloud.

Remarque : Cela nécessitera des ressources supplémentaires pour provisionner le nouveau cluster, mais le temps d'arrêt et les perturbations seront moindres pour les charges de travail existantes.

Option 2 : Supprimer les pools de nœuds Windows et les rajouter lors de la mise à niveau vers Google Distributed Cloud 1.13

Remarque : Avec cette option, les charges de travail Windows ne pourront pas s'exécuter tant que le cluster n'aura pas été mis à niveau vers la version 1.13 et que les pools de nœuds Windows n'auront pas été ajoutés.

1. Supprimez les pools de nœuds Windows existants en supprimant la configuration des pools de nœuds Windows du fichier user-cluster.yaml, puis exécutez la commande suivante :

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

2. Mettez à niveau les clusters d'administrateur et d'utilisateur Linux uniquement vers la version 1.12 en suivant le guide de mise à niveau pour la version mineure cible correspondante.
3. (Veillez à effectuer cette étape avant de passer à la version 1.13.) Assurez-vous que enableWindowsDataplaneV2: true est configuré dans le CR OnPremUserCluster. Sinon, le cluster continuera d'utiliser Docker pour les pools de nœuds Windows, ce qui ne sera pas compatible avec le modèle de VM Windows 1.13 nouvellement créé et sur lequel Docker n'est pas installé. Si elle n'est pas configurée ou si elle est définie sur "false", mettez à jour votre cluster pour la définir sur "true" dans user-cluster.yaml, puis exécutez la commande suivante :

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

4. Mettez à niveau les clusters d'administrateur et d'utilisateur Linux uniquement vers la version 1.13 en suivant le guide de mise à niveau.
5. Préparez le modèle de VM Windows à l'aide de gkectl 1.13 :

   gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG

6. Ajoutez à nouveau la configuration du pool de nœuds Windows à user-cluster.yaml, en définissant le champ OSImage sur le modèle de VM Windows que vous venez de créer.
7. Mettre à jour le cluster pour ajouter des pools de nœuds Windows

   gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

La configuration RootDistanceMaxSec ne prend pas effet pour les nœuds ubuntu.

La valeur par défaut de 5 secondes pour RootDistanceMaxSec sera utilisée sur les nœuds, au lieu de 20 secondes, qui devrait être la configuration attendue. Si vous vérifiez le journal de démarrage du nœud en vous connectant à la VM via SSH, qui se trouve à l'adresse `/var/log/startup.log`, vous pouvez trouver l'erreur suivante :

+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

L'utilisation d'un RootDistanceMaxSec de cinq secondes peut entraîner une désynchronisation de l'horloge système avec le serveur NTP lorsque la dérive de l'horloge est supérieure à cinq secondes.

Solution :

Appliquez le DaemonSet suivant à votre cluster pour configurer RootDistanceMaxSec :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-root-distance
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-root-distance
  template:
    metadata:
      labels:
        app: change-root-distance
    spec:
      hostIPC: true
      hostPID: true
      tolerations:
      # Make sure pods gets scheduled on all nodes.
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      containers:
      - name: change-root-distance
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            conf_file="/etc/systemd/timesyncd.conf.d/90-gke.conf"
            if [ -f $conf_file ] && $(grep -q "RootDistanceMaxSec=20" $conf_file); then
              echo "timesyncd has the expected RootDistanceMaxSec, skip update"
            else
              echo "updating timesyncd config to RootDistanceMaxSec=20"
              mkdir -p /etc/systemd/timesyncd.conf.d
              cat > $conf_file << EOF
          [Time]
          RootDistanceMaxSec=20
          EOF
              systemctl restart systemd-timesyncd
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

Échec de gkectl update admin en raison d'un champ osImageType vide

Lorsque vous utilisez la version 1.13 de gkectl pour mettre à jour un cluster d'administrateur en version 1.12, l'erreur suivante peut s'afficher :

Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Lorsque vous utilisez gkectl update admin pour les clusters des versions 1.13 ou 1.14, le message suivant peut s'afficher dans la réponse :

Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Si vous consultez le journal gkectl, vous verrez peut-être que les modifications multiples incluent la définition de osImageType, qui passe d'une chaîne vide à ubuntu_containerd.

Ces erreurs de mise à jour sont dues à un remplissage incorrect du champ osImageType dans la configuration du cluster d'administrateur, car il a été introduit dans la version 1.9.

Solution :

Passez à une version de Google Distributed Cloud incluant le correctif. Si vous ne pouvez pas effectuer la mise à niveau, contactez Cloud Customer Care pour résoudre ce problème.

Le SNI ne fonctionne pas sur les clusters d'utilisateur avec Controlplane V2

La possibilité de fournir un certificat de diffusion supplémentaire pour le serveur d'API Kubernetes d'un cluster d'utilisateur avec authentication.sni ne fonctionne pas lorsque Controlplane V2 est activé ( enableControlplaneV2: true).

Solution :

En attendant qu'un correctif Google Distributed Cloud soit disponible, si vous devez utiliser SNI, désactivez Controlplane V2 (enableControlplaneV2: false).

$ dans le nom d'utilisateur du registre privé entraîne l'échec du démarrage de la machine du plan de contrôle administrateur

La machine du plan de contrôle de l'administrateur ne parvient pas à démarrer lorsque le nom d'utilisateur du registre privé contient $. Lorsque vous vérifiez /var/log/startup.log sur la machine du plan de contrôle de l'administrateur, l'erreur suivante s'affiche :

++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Solution :

Utilisez un nom d'utilisateur de registre privé sans $ ou utilisez une version de Google Distributed Cloud avec le correctif.

Faux positifs concernant les modifications non compatibles lors de la mise à jour du cluster d'administrateur

Lorsque vous mettez à jour des clusters d'administrateur, les faux positifs suivants s'affichent dans le journal. Vous pouvez les ignorer.

    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      -         CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      +         CARotation:        nil,
      ...
    }

Échec de la mise à jour du cluster d'utilisateur après la rotation des clés de signature KSA

Après avoir fait pivoter les clés de signature KSA et mis à jour un cluster d'utilisateur, gkectl update peut échouer et afficher le message d'erreur suivant :

Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"

Solution :

1. Vérifiez le secret dans le cluster d'administrateur sous l'espace de noms USER_CLUSTER_NAME et obtenez le nom du secret ksa-signing-key :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key

2. Copiez le secret ksa-signing-key et renommez-le service-account-cert :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
   sed 's/ name: .*/ name: service-account-cert/' | \
   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -

3. Supprimez le secret ksa-signing-key précédent :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME

4. Mettez à jour le champ data.data dans le fichier de configuration ksa-signing-key-rotation-stage sur '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}' :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
   edit configmap ksa-signing-key-rotation-stage

5. Désactivez le webhook de validation pour modifier les informations sur la version dans la ressource personnalisée OnPremUserCluster :

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       resources:
       - onpremuserclusters
   '

6. Mettez à jour le champ spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation sur 1 dans votre ressource personnalisée OnPremUserCluster :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   edit onpremusercluster USER_CLUSTER_NAME

7. Attendez que le cluster d'utilisateur cible soit prêt. Vous pouvez vérifier son état en saisissant :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
   get onpremusercluster

8. Restaurez le webhook de validation pour le cluster d'utilisateur :

   kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
   webhooks:
   - name: vonpremnodepool.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremnodepools
   - name: vonpremusercluster.onprem.cluster.gke.io
     rules:
     - apiGroups:
       - onprem.cluster.gke.io
       apiVersions:
       - v1alpha1
       operations:
       - CREATE
       - UPDATE
       resources:
       - onpremuserclusters
   '

9. Évitez une autre rotation des clés de signature KSA tant que le cluster n'a pas été mis à niveau vers la version contenant le correctif.

Les serveurs virtuels F5-BIG-IP ne sont pas nettoyés lorsque Terraform supprime des clusters d'utilisateur

Lorsque vous utilisez Terraform pour supprimer un cluster d'utilisateur avec un équilibreur de charge F5 BIG-IP, les serveurs virtuels F5 BIG-IP ne sont pas supprimés après la suppression du cluster.

Solution :

Pour supprimer les ressources F5, suivez la procédure permettant de nettoyer la partition F5 d'un cluster d'utilisateur .

Le cluster kind extrait les images de conteneur de docker.io.

Si vous créez un cluster d'administrateur version 1.13.8 ou 1.14.4, ou si vous mettez à niveau un cluster d'administrateur vers la version 1.13.8 ou 1.14.4, le cluster kind extrait les images de conteneur suivantes de docker.io :

Si docker.io n'est pas accessible depuis votre poste de travail administrateur, la création ou la mise à niveau du cluster d'administrateur ne permet pas de lancer le cluster de genre. L'exécution de la commande suivante sur le poste de travail administrateur affiche les conteneurs correspondants en attente avec ErrImagePull :

docker exec gkectl-control-plane kubectl get pods -A

La réponse contient des entrées comme celles-ci :

...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

Ces images de conteneur doivent être préchargées dans l'image de conteneur du cluster Kind. Toutefois, kind v0.18.0 présente un problème avec les images de conteneurs préchargées, qui entraîne leur extraction à tort depuis Internet.

Solution :

Exécutez les commandes suivantes sur le poste de travail administrateur pendant que la création ou la mise à niveau de votre cluster d'administrateur est en attente :

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501

Échec du basculement sur un cluster d'utilisateur et un cluster d'administrateur Controlplane V2 à haute disponibilité lorsque le réseau filtre les requêtes GARP en double

Si les VM de votre cluster sont connectées à un commutateur qui filtre les requêtes GARP (gratuitous ARP) en double, l'élection du leader keepalived peut rencontrer une condition de concurrence, ce qui entraîne des entrées de table ARP incorrectes pour certains nœuds.

Les nœuds concernés peuvent ping l'adresse IP virtuelle du plan de contrôle, mais une connexion TCP à l'adresse IP virtuelle du plan de contrôle expirera.

Solution :

    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    

vsphere-csi-controller doit être redémarré après la rotation du certificat vCenter

vsphere-csi-controller doit actualiser son secret vCenter après la rotation du certificat vCenter. Toutefois, le système actuel ne redémarre pas correctement les pods de vsphere-csi-controller, ce qui entraîne le plantage de vsphere-csi-controller après la rotation.

Solution :

Pour les clusters créés avec la version 1.13 ou ultérieure, suivez les instructions ci-dessous pour redémarrer vsphere-csi-controller.

kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system

La création du cluster d'administrateur n'échoue pas en cas d'erreurs d'enregistrement du cluster.

Même lorsque l'enregistrement du cluster échoue lors de la création du cluster d'administrateur, la commande gkectl create admin ne génère pas d'erreur et peut réussir. En d'autres termes, la création du cluster d'administrateur peut "réussir" sans être enregistrée dans un parc.

Failed to register admin cluster

Vous pouvez également vérifier si vous trouvez le cluster parmi les clusters enregistrés dans la console Cloud.

Solution :

Pour les clusters créés avec la version 1.12 ou ultérieure, suivez les instructions pour réessayer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters créés avec des versions antérieures,

1. Ajoutez une fausse paire clé/valeur, comme "foo: bar", à votre fichier de clé SA connect-register.
2. Exécutez gkectl update admin pour réenregistrer le cluster d'administrateur.

Il est possible que la réinscription du cluster d'administrateur soit ignorée lors de la mise à niveau du cluster d'administrateur.

Si la mise à niveau des nœuds du plan de contrôle de l'utilisateur expire lors de la mise à niveau du cluster d'administrateur, le cluster d'administrateur ne sera pas réenregistré avec la version mise à jour de l'agent Connect.

Solution :

1. Ajoutez une fausse paire clé/valeur, comme "foo: bar", à votre fichier de clé SA connect-register.
2. Exécutez gkectl update admin pour réenregistrer le cluster d'administrateur.

Message d'erreur incorrect concernant vCenter.dataDisk

Pour un cluster d'administrateur à haute disponibilité, gkectl prepare affiche le faux message d'erreur suivant :

vCenter.dataDisk must be present in the AdminCluster spec

Solution :

Vous pouvez ignorer ce message d'erreur.

Échec de la création du pool de nœuds en raison de règles d'affinité VM-hôte redondantes

Lors de la création d'un pool de nœuds utilisant l'affinité VM-hôte, une condition de concurrence peut entraîner la création de plusieurs règles d'affinité VM-hôte portant le même nom. Cela peut entraîner l'échec de la création du pool de nœuds.

Solution :

Supprimez les anciennes règles redondantes pour que la création du pool de nœuds puisse se poursuivre. Ces règles sont nommées [USER_CLUSTER_NAME]-[HASH].

gkectl repair admin-master peut échouer en raison de failed to delete the admin master node object and reboot the admin master VM

La commande gkectl repair admin-master peut échouer en raison d'une condition de concurrence avec l'erreur suivante.

Failed to repair: failed to delete the admin master node object and reboot the admin master VM

Solution :

Cette commande est idempotente. Elle peut être réexécutée sans risque jusqu'à ce que la commande aboutisse.

Les pods restent à l'état "Échec" après la recréation ou la mise à jour d'un nœud du plan de contrôle

Après avoir recréé ou mis à jour un nœud de plan de contrôle, certains pods peuvent rester à l'état Failed en raison d'un échec du prédicat NodeAffinity. Ces pods en échec n'ont aucune incidence sur le fonctionnement ni l'état du cluster.

Solution :

Vous pouvez ignorer les pods en échec ou les supprimer manuellement.

Le cluster d'utilisateur OnPremUserCluster n'est pas prêt en raison des identifiants du registre privé

Si vous utilisez des identifiants préparés et un registre privé, mais que vous n'avez pas configuré d'identifiants préparés pour votre registre privé, il est possible que l'OnPremUserCluster ne soit pas prêt et que le message d'erreur suivant s'affiche :

failed to check secret reference for private registry …

Solution :

Préparez les identifiants du registre privé pour le cluster d'utilisateur en suivant les instructions de la section Configurer des identifiants préparés.

La commande gkectl upgrade admin renvoie une erreur StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

Lors de gkectl upgrade admin, la vérification préliminaire du stockage pour la migration CSI vérifie que les StorageClasses ne comportent pas de paramètres ignorés après la migration CSI. Par exemple, s'il existe une StorageClass avec le paramètre diskformat, gkectl upgrade admin signale la StorageClass et indique un échec de la validation avant vol. Les clusters d'administrateur créés dans Google Distributed Cloud 1.10 et versions antérieures disposent d'une StorageClass avec diskformat: thin, ce qui entraînera l'échec de cette validation. Toutefois, cette StorageClass fonctionnera toujours correctement après la migration CSI. Ces échecs doivent plutôt être interprétés comme des avertissements.

Pour en savoir plus, consultez la section sur les paramètres StorageClass dans Migrer les volumes vSphere dans l'arborescence vers le plug-in vSphere Container Storage.

Solution :

Après avoir confirmé que votre cluster dispose d'une StorageClass avec des paramètres ignorés après la migration CSI, exécutez gkectl upgrade admin avec l'indicateur --skip-validation-cluster-health.

Les volumes vSphere "in-tree" migrés à l'aide du système de fichiers Windows ne peuvent pas être utilisés avec le pilote CSI vSphere.

Dans certaines conditions, les disques peuvent être associés en lecture seule aux nœuds Windows. Le volume correspondant est alors en lecture seule dans un pod. Ce problème est plus susceptible de se produire lorsqu'un nouvel ensemble de nœuds remplace un ancien ensemble de nœuds (par exemple, lors de la mise à niveau d'un cluster ou de la mise à jour d'un pool de nœuds). Les charges de travail avec état qui fonctionnaient auparavant correctement peuvent ne pas pouvoir écrire dans leurs volumes sur le nouvel ensemble de nœuds.

Solution :

1. Obtenez l'UID du pod qui ne parvient pas à écrire sur son volume :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
       POD_NAME --namespace POD_NAMESPACE \
       -o=jsonpath='{.metadata.uid}{"\n"}'

2. Utilisez PersistentVolumeClaim pour obtenir le nom de PersistentVolume :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
       PVC_NAME --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.volumeName}{"\n"}'

3. Déterminez le nom du nœud sur lequel le pod est exécuté :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
       --namespace POD_NAMESPACE \
       -o jsonpath='{.spec.nodeName}{"\n"}'

4. Obtenez un accès PowerShell au nœud, soit via SSH, soit via l'interface Web vSphere.
5. Définissez les variables d'environnement :

   PS C:\Users\administrator> pvname=PV_NAME
   PS C:\Users\administrator> podid=POD_UID

6. Identifiez le numéro du disque associé au PersistentVolume :

   PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
   "C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber

7. Vérifiez que le disque est readonly :

   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

   Le résultat doit être True.
8. Définissez readonly sur false.

   PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
   PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly

9. Supprimez le pod pour qu'il redémarre :

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
       --namespace POD_NAMESPACE

10. Le pod doit être planifié sur le même nœud. Toutefois, si le pod est planifié sur un nouveau nœud, vous devrez peut-être répéter les étapes précédentes sur le nouveau nœud.

vsphere-csi-secret n'est pas mis à jour après gkectl update credentials vsphere --admin-cluster

Si vous mettez à jour les identifiants vSphere d'un cluster d'administrateur en suivant la procédure de mise à jour des identifiants du cluster, vous constaterez peut-être que vsphere-csi-secret sous l'espace de noms kube-system du cluster d'administrateur utilise toujours les anciens identifiants.

Solution :

1. Obtenez le nom secret vsphere-csi-secret :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret

2. Mettez à jour les données du secret vsphere-csi-secret que vous avez obtenu à l'étape ci-dessus :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
     "{\"data\":{\"config\":\"$( \
       kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
         | base64 -d \
         | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
         | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
         | base64 -w 0 \
       )\"}}"

3. Redémarrez vsphere-csi-controller :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller

4. Vous pouvez suivre l'état du déploiement avec :

   kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller

   Une fois le déploiement effectué, le contrôleur doit utiliser le vsphere-csi-secret mis à jour.

Boucle de plantage audit-proxy lors de l'activation de Cloud Audit Logs avec gkectl update cluster

audit-proxy peut être en boucle de plantage en raison d'un --cluster-name vide. Ce comportement est dû à un bug dans la logique de mise à jour, où le nom du cluster n'est pas propagé au fichier manifeste du pod / conteneur audit-proxy.

Solution :

Pour un cluster d'utilisateur Controlplane V2 avec enableControlplaneV2: true, connectez-vous à la machine du plan de contrôle de l'utilisateur à l'aide de SSH, puis mettez à jour /etc/kubernetes/manifests/audit-proxy.yaml avec --cluster_name=USER_CLUSTER_NAME.

Pour un cluster d'utilisateur avec plan de contrôle v1, modifiez le conteneur audit-proxy dans le StatefulSet kube-apiserver pour ajouter --cluster_name=USER_CLUSTER_NAME :

kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Redéploiement supplémentaire du plan de contrôle juste après gkectl upgrade cluster

Juste après gkectl upgrade cluster, les pods du plan de contrôle peuvent être redéployés. L'état du cluster gkectl list clusters est passé de RUNNING à RECONCILING. Les requêtes envoyées au cluster d'utilisateur peuvent expirer.

Ce comportement est dû à la rotation automatique des certificats du plan de contrôle après gkectl upgrade cluster.

Ce problème ne se produit que pour les clusters d'utilisateur qui n'utilisent PAS le plan de contrôle V2.

Solution :

Attendez que l'état du cluster redevienne RUNNING dans gkectl list clusters, ou passez aux versions incluant le correctif : 1.13.6+, 1.14.2+ ou 1.15+.

La version incorrecte 1.12.7-gke.19 a été supprimée.

Google Distributed Cloud 1.12.7-gke.19 est une version incorrecte et vous ne devez pas l'utiliser. Les artefacts ont été supprimés du bucket Cloud Storage.

Solution :

Utilisez plutôt la version 1.12.7-gke.20.

gke-connect-agent continue d'utiliser l'ancienne image après la mise à jour des identifiants du registre

Si vous mettez à jour les identifiants du registre à l'aide de l'une des méthodes suivantes :

• gkectl update credentials componentaccess si vous n'utilisez pas de registre privé
• gkectl update credentials privateregistry si vous utilisez un registre privé

Il est possible que gke-connect-agent continue d'utiliser l'ancienne image ou que les pods gke-connect-agent ne puissent pas être extraits en raison de ImagePullBackOff.

Ce problème sera résolu dans les versions 1.13.8 et 1.14.4 de Google Distributed Cloud, ainsi que dans les versions ultérieures.

Solution :

Option 1 : Redéployer gke-connect-agent manuellement :

1. Supprimez l'espace de noms gke-connect :

   kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect

2. Redéployez gke-connect-agent avec la clé de compte de service du registre d'origine (il n'est pas nécessaire de mettre à jour la clé) :
   Pour le cluster d'administrateur :

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster

   Pour le cluster d'utilisateur :

   gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

Option 2 : Vous pouvez modifier manuellement les données du secret d'extraction d'image regcred utilisé par le déploiement gke-connect-agent :

kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

Option 3 : Vous pouvez ajouter le secret d'extraction d'image par défaut pour votre cluster dans le déploiement gke-connect-agent en procédant comme suit :

1. Copiez le secret par défaut dans l'espace de noms gke-connect :

   kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -

2. Obtenez le nom du déploiement gke-connect-agent :

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent

3. Ajoutez le secret par défaut au déploiement gke-connect-agent :

   kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'

Échec de la vérification manuelle de la configuration de l'équilibreur de charge

Lorsque vous validez la configuration avant de créer un cluster avec un équilibreur de charge manuel en exécutant gkectl check-config, la commande échoue et affiche les messages d'erreur suivants.

 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

Solution :

Option 1 : Vous pouvez utiliser les versions de correctif 1.13.7 et 1.14.4 qui incluent le correctif.

Option 2 : Vous pouvez également exécuter la même commande pour valider la configuration, mais ignorer la validation de l'équilibreur de charge.

gkectl check-config --skip-validation-load-balancer

Pénurie de surveillance etcd

Les clusters exécutant la version 3.4.13 ou antérieure d'etcd peuvent rencontrer des problèmes de famine de surveillance et de surveillance de ressources non opérationnelle, ce qui peut entraîner les problèmes suivants :

• La planification des pods est interrompue
• Les nœuds ne peuvent pas s'enregistrer
• kubelet n'observe pas les modifications apportées aux pods

Ces problèmes peuvent rendre le cluster non fonctionnel.

Ce problème est résolu dans les versions 1.12.7, 1.13.6 et 1.14.3 de Google Distributed Cloud, ainsi que dans les versions ultérieures. Ces versions plus récentes utilisent etcd version 3.4.21. Toutes les versions antérieures de Google Distributed Cloud sont concernées par ce problème.

Solution

Si vous ne pouvez pas effectuer la mise à niveau immédiatement, vous pouvez réduire le risque de défaillance du cluster en diminuant le nombre de nœuds dans votre cluster. Supprimez des nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mbit/s.

Pour afficher cette métrique dans l'explorateur de métriques :

1. Accédez à l'explorateur de métriques dans la console Google Cloud  :

   Accéder à l'explorateur de métriques

2. Accédez à l'onglet Configuration.
3. Développez le menu Sélectionner une métrique, saisissez Kubernetes Container dans la barre de filtre, puis utilisez les sous-menus pour sélectionner la métrique :
   1. Dans le menu Ressources actives, sélectionnez Conteneur Kubernetes.
   2. Dans le menu Catégories de métriques actives, sélectionnez Anthos.
   3. Dans le menu Métriques actives, sélectionnez etcd_network_client_grpc_sent_bytes_total.
   4. Cliquez sur Appliquer.

GKE Identity Service peut entraîner des latences du plan de contrôle

Lors des redémarrages ou des mises à niveau de clusters, GKE Identity Service peut être submergé par le trafic composé de jetons JWT expirés transférés du kube-apiserver vers GKE Identity Service via le webhook d'authentification. Bien que GKE Identity Service ne boucle pas sur les erreurs, il ne répond plus et cesse de traiter les requêtes. Ce problème entraîne finalement des latences plus élevées du plan de contrôle.

Ce problème est résolu dans les versions suivantes de Google Distributed Cloud :

• 1.12.6+
• 1.13.6+
• 1.14.2+

Pour savoir si vous êtes concerné par ce problème, procédez comme suit :

1. Vérifiez si le point de terminaison GKE Identity Service est accessible de l'extérieur :

   curl -s -o /dev/null -w "%{http_code}" \
       -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

   Remplacez CLUSTER_ENDPOINT par l'adresse IP virtuelle du plan de contrôle et le port de l'équilibreur de charge du plan de contrôle de votre cluster (par exemple, 172.16.20.50:443).

   Si vous êtes concerné par ce problème, la commande renvoie un code d'état 400. Si la requête expire, redémarrez le pod ais et exécutez à nouveau la commande curl pour voir si cela résout le problème. Si vous obtenez un code d'état 000, le problème a été résolu. Si vous obtenez toujours un code d'état 400, cela signifie que le serveur HTTP de GKE Identity Service ne démarre pas. Dans ce cas, continuez.

2. Consultez les journaux de GKE Identity Service et de kube-apiserver :
   1. Consultez le journal GKE Identity Service :

      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
          --kubeconfig KUBECONFIG

      Si le journal contient une entrée semblable à la suivante, vous êtes concerné par ce problème :

      I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:

   2. Vérifiez les journaux kube-apiserver de vos clusters :

      Dans les commandes suivantes, KUBE_APISERVER_POD est le nom du pod kube-apiserver sur le cluster donné.

      Cluster d'administrateur :

      kubectl --kubeconfig ADMIN_KUBECONFIG logs \
          -n kube-system KUBE_APISERVER_POD kube-apiserver

      Cluster d'utilisateur :

      kubectl --kubeconfig ADMIN_KUBECONFIG logs \
          -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

      Si les journaux kube-apiserver contiennent des entrées comme celles ci-dessous, vous êtes concerné par ce problème :

      E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
      E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

Solution

Si vous ne pouvez pas mettre à niveau vos clusters immédiatement pour obtenir le correctif, vous pouvez identifier et redémarrer les pods concernés comme solution de contournement :

1. Augmentez le niveau de verbosité de GKE Identity Service à 9 :

   kubectl patch deployment ais -n anthos-identity-service --type=json \
       -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
       "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
       --kubeconfig KUBECONFIG

2. Consultez le journal GKE Identity Service pour connaître le contexte du jeton non valide :

   kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
       --kubeconfig KUBECONFIG

3. Pour obtenir la charge utile du jeton associée à chaque contexte de jeton non valide, analysez chaque secret de compte de service associé à l'aide de la commande suivante :

   kubectl -n kube-system get secret SA_SECRET \
       --kubeconfig KUBECONFIG \
       -o jsonpath='{.data.token}' | base64 --decode

4. Pour décoder le jeton et afficher le nom et l'espace de noms du pod source, copiez le jeton dans le débogueur sur jwt.io.
5. Redémarrez les pods identifiés à partir des jetons.

Problème d'augmentation de l'utilisation de la mémoire des pods etcd-maintenance

Les pods de maintenance etcd qui utilisent l'image etcddefrag:gke_master_etcddefrag_20210211.00_p0 sont concernés. Le conteneur `etcddefrag` ouvre une nouvelle connexion au serveur etcd à chaque cycle de défragmentation, et les anciennes connexions ne sont pas nettoyées.

Solution :

Option 1 : Mettez à niveau vers la dernière version de correctif de 1.8 à 1.11 contenant le correctif.

Option 2 : Si vous utilisez une version de correctif antérieure à 1.9.6 et 1.10.3, vous devez réduire le nombre de pods etcd-maintenance pour le cluster d'administrateur et le cluster d'utilisateur :

kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Échec des vérifications de l'état des pods du plan de contrôle du cluster utilisateur

Le contrôleur d'état du cluster et la commande gkectl diagnose cluster effectuent un ensemble de vérifications d'état, y compris celles des pods dans les espaces de noms. Toutefois, ils commencent à ignorer les pods du plan de contrôle utilisateur par erreur. Si vous utilisez le mode Controlplane V2, cela n'affectera pas votre cluster.

Solution :

Cela n'aura aucune incidence sur la gestion des charges de travail ni des clusters. Si vous souhaitez vérifier l'état des pods du plan de contrôle, vous pouvez exécuter les commandes suivantes :

kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG

La redirection k8s.gcr.io → registry.k8s.io peut affecter les mises à niveau des clusters d'administrateur 1.6 et 1.7.

Le 20/03/2023, Kubernetes a redirigé le trafic de k8s.gcr.io vers registry.k8s.io. Dans Google Distributed Cloud 1.6.x et 1.7.x, les mises à niveau du cluster d'administrateur utilisent l'image de conteneur k8s.gcr.io/pause:3.2. Si vous utilisez un proxy pour votre poste de travail administrateur et que le proxy n'autorise pas registry.k8s.io et que l'image de conteneur k8s.gcr.io/pause:3.2 n'est pas mise en cache localement, les mises à niveau du cluster d'administrateur échoueront lors de l'extraction de l'image de conteneur.

Solution :

Ajoutez registry.k8s.io à la liste d'autorisation du proxy pour votre poste de travail administrateur.

Échec de la validation Seesaw lors de la création de l'équilibreur de charge

gkectl create loadbalancer échoue avec le message d'erreur suivant :

- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

Cela est dû au fait que le fichier de groupe Seesaw existe déjà. La vérification préliminaire tente de valider un équilibreur de charge Seesaw inexistant.

Solution :

Supprimez le fichier de groupe Seesaw existant pour ce cluster. Le nom de fichier est seesaw-for-gke-admin.yaml pour le cluster d'administrateur et seesaw-for-{CLUSTER_NAME}.yaml pour un cluster d'utilisateur.

Expirations de délai de l'application causées par les échecs d'insertion de la table conntrack

La version 1.14 de Google Distributed Cloud est sensible aux échecs d'insertion des tables Netfilter Connection Tracking (conntrack) lors de l'utilisation d'images de système d'exploitation Ubuntu ou COS. Les échecs d'insertion entraînent des expirations de délai aléatoires de l'application et peuvent se produire même lorsque la table conntrack dispose de place pour de nouvelles entrées. Les échecs sont dus à des modifications apportées au noyau 5.15 et aux versions ultérieures qui limitent les insertions de table en fonction de la longueur de chaîne.

Pour savoir si vous êtes concerné par ce problème, vous pouvez vérifier les statistiques du système de suivi de la connexion au noyau sur chaque nœud à l'aide de la commande suivante :

sudo conntrack -S

La réponse est semblable à ce qui suit :

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, vous êtes concerné par ce problème.

Solution

La solution à court terme consiste à augmenter la taille de la table de hachage netfilter (nf_conntrack_buckets) et de la table de suivi des connexions netfilter (nf_conntrack_max). Utilisez les commandes suivantes sur chaque nœud de cluster pour augmenter la taille des tables :

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Remplacez TABLE_SIZE par la nouvelle taille en octets. La taille de tableau par défaut est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs du nœud. Par exemple, si votre nœud comporte huit cœurs, définissez la taille de la table sur 524288.

Boucle de plantage de calico-typha ou anetd-operator sur les nœuds Windows avec Controlplane V2

Lorsque Controlplane V2 est activé, calico-typha ou anetd-operator peuvent être planifiés sur des nœuds Windows et entrer dans une boucle de plantage.

En effet, les deux déploiements tolèrent toutes les contaminations, y compris la contamination des nœuds Windows.

Solution :

Mettez à niveau vers la version 1.13.3 ou ultérieure, ou exécutez les commandes suivantes pour modifier le déploiement `calico-typha` ou `anetd-operator` :

    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG
    

Supprimez les spec.template.spec.tolerations suivants :

    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists
    

Ajoutez ensuite la tolérance suivante :

    - key: node-role.kubernetes.io/master
      operator: Exists
    

Impossible de charger le fichier d'identifiants du registre privé du cluster d'utilisateur

Il est possible que vous ne puissiez pas créer de cluster d'utilisateur si vous spécifiez la section privateRegistry avec les identifiants fileRef. La vérification préliminaire peut échouer avec le message suivant :

[FAILURE] Docker registry access: Failed to login.

Solution :

• Si vous n'avez pas l'intention de spécifier le champ ou si vous souhaitez utiliser les mêmes identifiants de registre privé que le cluster d'administrateur, vous pouvez simplement supprimer ou commenter la section privateRegistry dans le fichier de configuration de votre cluster d'utilisateur.
• Si vous souhaitez utiliser des identifiants de registre privé spécifiques pour votre cluster d'utilisateur, vous pouvez spécifier temporairement la section privateRegistry de la manière suivante :

  privateRegistry:
    address: PRIVATE_REGISTRY_ADDRESS
    credentials:
      username: PRIVATE_REGISTRY_USERNAME
      password: PRIVATE_REGISTRY_PASSWORD
    caCertPath: PRIVATE_REGISTRY_CACERT_PATH

  (REMARQUE : Il s'agit uniquement d'une solution temporaire. Ces champs sont déjà obsolètes. Pensez à utiliser le fichier d'identifiants lorsque vous passez à la version 1.14.3 ou ultérieure.)

Cloud Service Mesh et autres service meshes non compatibles avec Dataplane V2

Dataplane V2 prend le relais pour l'équilibrage de charge et crée un socket de noyau au lieu d'un DNAT basé sur les paquets. Cela signifie que Cloud Service Mesh ne peut pas inspecter les paquets, car le pod est contourné et n'utilise jamais IPTables.

En mode libre kube-proxy, cela se traduit par une perte de connectivité ou un routage incorrect du trafic pour les services avec Cloud Service Mesh comme side-car, car il ne peut pas inspecter les paquets.

Ce problème est présent dans toutes les versions de Google Distributed Cloud 1.10. Toutefois, certaines versions plus récentes de 1.10 (1.10.2 et ultérieures) disposent d'une solution de contournement.

Solution :

Effectuez une mise à niveau vers la version 1.11 pour une compatibilité totale ou, si vous exécutez la version 1.10.2 ou ultérieure, exécutez la commande suivante :

    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
    

Ajoutez bpf-lb-sock-hostns-only: true au fichier ConfigMap, puis redémarrez le DaemonSet anetd :

      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
    

kube-controller-manager peut détacher les volumes persistants de force au bout de six minutes.

kube-controller-manager peut expirer lors du détachement des PV/PVC après six minutes et détacher de force les PV/PVC. Les journaux détaillés de kube-controller-manager affichent des événements semblables à ceux-ci :

$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

Pour vérifier le problème, connectez-vous au nœud et exécutez les commandes suivantes :

# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

Dans le journal kubelet, des erreurs semblables à celles-ci s'affichent :

Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

Solution :

Connectez-vous au nœud concerné à l'aide de SSH, puis redémarrez-le.

La mise à niveau du cluster est bloquée si un pilote CSI tiers est utilisé

Il est possible que vous ne puissiez pas mettre à niveau un cluster si vous utilisez un pilote CSI tiers. La commande gkectl cluster diagnose peut renvoyer l'erreur suivante :

"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"

Solution :

Effectuez la mise à niveau à l'aide de l'option --skip-validation-all.

gkectl repair admin-master crée la VM maître de l'administrateur sans mettre à niveau sa version matérielle

Le nœud maître administrateur créé via gkectl repair admin-master peut utiliser une version de matériel de VM inférieure à celle attendue. Lorsque le problème se produit, l'erreur s'affiche dans le rapport gkectl diagnose cluster.

CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.

Solution :

Arrêtez le nœud maître de l'administrateur, suivez https://kb.vmware.com/s/article/1003746 pour mettre à niveau le nœud vers la version attendue décrite dans le message d'erreur, puis démarrez le nœud.

La VM libère le bail DHCP lors de l'arrêt/du redémarrage de manière inattendue, ce qui peut entraîner des modifications d'adresse IP.

Dans systemd v244, systemd-networkd a un nouveau comportement par défaut pour la configuration KeepConfiguration. Avant cette modification, les VM n'envoyaient pas de message de libération du bail DHCP au serveur DHCP lors de l'arrêt ou du redémarrage. Après cette modification, les VM envoient un tel message et renvoient les adresses IP au serveur DHCP. Par conséquent, l'adresse IP libérée peut être réattribuée à une autre VM et/ou une autre adresse IP peut être attribuée à la VM, ce qui entraîne un conflit d'adresses IP (au niveau de Kubernetes, et non de vSphere) et/ou un changement d'adresse IP sur les VM, ce qui peut endommager les clusters de différentes manières.

Par exemple, vous pouvez constater les problèmes suivants.

• L'interface utilisateur vCenter indique qu'aucune VM n'utilise la même adresse IP, mais kubectl get nodes -o wide renvoie des nœuds avec des adresses IP en double.

  NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
  node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
  node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13

• Échec du démarrage des nouveaux nœuds en raison de l'erreur calico-node

  2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
  2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
  2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
  2023-01-19T22:07:08.828218856Z Calico node failed to start

Solution :

Déployez le DaemonSet suivant sur le cluster pour rétablir le changement de comportement par défaut de systemd-networkd. Les VM qui exécutent ce DaemonSet ne libèrent pas les adresses IP sur le serveur DHCP lors de l'arrêt ou du redémarrage. Les adresses IP seront automatiquement libérées par le serveur DHCP à l'expiration des baux.

      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule
      

La clé du compte de service d'accès aux composants est effacée après la mise à niveau du cluster d'administrateur depuis la version 1.11.x

Ce problème n'affecte que les clusters d'administrateur mis à niveau à partir de la version 1.11.x. Il n'affecte pas les clusters d'administrateur créés après la version 1.12.

Après la mise à niveau d'un cluster 1.11.x vers la version 1.12.x, le champ component-access-sa-key du secret admin-cluster-creds sera effacé. Vous pouvez le vérifier en exécutant la commande suivante :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'

Une fois la clé du compte de service d'accès aux composants supprimée, l'installation de nouveaux clusters d'utilisateur ou la mise à niveau de clusters d'utilisateur existants échoueront. Voici quelques messages d'erreur que vous pourriez rencontrer :

• Échec de la validation préliminaire lente avec le message d'erreur suivant : "Failed to create the test VMs: failed to get service account key: service account is not configured."
• Échec de la préparation d'ici le gkectl prepare avec le message d'erreur suivant : "Failed to prepare OS images: dialing: unexpected end of JSON input"
• Si vous mettez à niveau un cluster d'utilisateur 1.13 à l'aide de la console Google Cloud ou de gcloud CLI, lorsque vous exécutez gkectl update admin --enable-preview-user-cluster-central-upgrade pour déployer le contrôleur de plate-forme de mise à niveau, la commande échoue et affiche le message suivant : "failed to download bundle to disk: dialing: unexpected end of JSON input" (vous pouvez voir ce message dans le champ status de la sortie de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).

Solution  :

Ajoutez manuellement la clé du compte de service d'accès aux composants au secret en exécutant la commande suivante :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -

L'autoscaler de cluster ne fonctionne pas lorsque Controlplane V2 est activé

Pour les clusters d'utilisateur créés avec Controlplane V2 activé, les pools de nœuds avec l'autoscaling activé utilisent toujours leur autoscaling.minReplicas dans user-cluster.yaml. Le journal du pod cluster-autoscaler affiche une erreur semblable à la suivante :

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
  

  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s
  

Solution  :

Désactivez l'autoscaling dans tous les pools de nœuds avec `gkectl update cluster` jusqu'à ce que vous passiez à une version contenant le correctif.

Le format CIDR n'est pas autorisé dans le fichier de bloc d'adresses IP.

Lorsque les utilisateurs utilisent CIDR dans le fichier de bloc IP, la validation de la configuration échoue et renvoie l'erreur suivante :

- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30
  

Solution  :

Incluez des adresses IP individuelles dans le fichier de bloc d'adresses IP jusqu'à ce que vous passiez à une version contenant le correctif : 1.12.5, 1.13.4, 1.14.1 ou version ultérieure.

La mise à jour du type d'image de l'OS dans le fichier admin-cluster.yaml n'attend pas la recréation des machines du plan de contrôle utilisateur

Lorsque vous mettez à jour le type d'image de l'OS du plan de contrôle dans le fichier admin-cluster.yaml, et si le cluster d'utilisateur correspondant a été créé avec enableControlplaneV2 défini sur true, il est possible que les machines du plan de contrôle de l'utilisateur ne terminent pas leur recréation lorsque la commande gkectl se termine.

Solution  :

Une fois la mise à jour terminée, continuez d'attendre que les machines du plan de contrôle de l'utilisateur aient également terminé leur recréation en surveillant leurs types d'images OS de nœud à l'aide de kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Par exemple, si vous passez d'Ubuntu à COS, vous devez attendre que toutes les machines du plan de contrôle soient complètement passées d'Ubuntu à COS, même après l'exécution de la commande de mise à jour.

Erreurs de création ou de suppression de pods dues à un problème de jeton d'authentification du compte de service Calico CNI

Un problème lié à Calico dans Google Distributed Cloud 1.14.0 empêche la création et la suppression de pods, et génère le message d'erreur suivant dans la sortie de kubectl describe pods :