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

Cette page répertorie tous les problèmes connus de Google Distributed Cloud on VMware. Pour filtrer les problèmes connus par version ou catégorie de produit, sélectionnez les filtres de votre choix dans les menus déroulants suivants.

Sélectionnez votre version de Google Distributed Cloud :

Sélectionnez la catégorie du problème :

Vous pouvez également rechercher votre problème:

Catégorie Version(s) identifiée(s) Problème et solution
Configuration 1.29.0

Message d'avertissement incorrect pour les clusters sur lesquels Dataplane V2 est activé

Le message d'avertissement incorrect suivant s'affiche lorsque vous exécutez gkectl pour créer, mettre à jour ou mettre à niveau un cluster sur 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.

En raison d'un bug dans gkectl, cet avertissement s'affiche toujours tant que dataplaneV2.forwardMode n'est pas utilisé, même si vous avez déjà défini enableDataplaneV2: true dans le fichier de configuration du cluster.

Solution :

Vous pouvez ignorer cet avertissement.
Configuration 1.28.0-1.28.400, 1.29.0

La vérification préliminaire de l'installation du cluster d'administrateur haute disponibilité signale 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 haute disponibilité 1.28 et supérieurs, car ils ne disposent 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 blocs 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 fixe, ajoutez --skip-validation-net-config à la commande gkectl.
Opération 1.29.0-1.29.100

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

Si vous avez migré d'un cluster d'administrateur standard vers un cluster d'administrateur haute disponibilité, l'agent Connect du cluster d'administrateur perd la connexion à gkeconnect.googleapis.com avec l'erreur "Échec de la validation de la signature JWT". En effet, lors de la migration, la clé de signature du KSA est modifiée. Par conséquent, une réinscription est nécessaire pour actualiser les JWK OIDC.

Solution :

Pour reconnecter le cluster d'administrateur à Google Cloud, procédez comme suit afin de déclencher un ré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 un rapprochement forcé pour onprem-admin-cluster-controller en ajoutant une annotation "forcer rapprochement" à votre RS 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 disponible.

Après avoir résolu ce problème (le contrôleur peut mettre quelques minutes à terminer le rapprochement), vous pouvez vérifier que l'erreur 400 "Failed to Verify JWT signature" (Échec de la validation de la signature JWT) n'apparaît plus dans les journaux gke-connect-agent:

kubectl --kubeconfig KUBECONFIG logs GKE_CONNECT_POD_NAME -n gke-connect
Installation, système d'exploitation 1.28.0-1.28.500, 1.29.0

L'adresse IP du pont 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 du pont Docker dans la configuration Docker afin d'empêcher la réservation du sous-réseau 172.17.0.1/16 par défaut. 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 que Google Distributed Cloud a personnalisé la configuration Docker en raison d'une régression dans l'image de l'OS COS. Par conséquent, Docker choisit la valeur 172.17.0.1/16 par défaut comme sous-réseau d'adresses IP de pont. Cela peut entraîner un conflit d'adresses IP si une charge de travail est déjà 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 de VM. Vous devez appliquer à nouveau cette solution chaque fois que des VM sont recréées.
mettre-à-jour 1.28.0-1.28.400, 1.29.0-1.29.100

L'utilisation de plusieurs interfaces réseau avec une 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 de l'OS des versions concernées. Ces binaires CNI ne sont pas utilisés par le plan de données v2, mais peuvent être utilisés pour des interfaces réseau supplémentaires dans la fonctionnalité d'interface réseau multiple.

Plusieurs interfaces réseau avec ces plug-ins CNI ne fonctionneront pas.

Solution :

Si vous utilisez cette fonctionnalité, passez à la version qui contient le correctif.
mettre-à-jour 1,15, 1,16 et 1,28

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

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

Solution :

  • Désactiver multipathd
Mises à jour 1,15, 1,16

Le webhook du cluster d'administrateur peut bloquer les mises à jour lorsque vous ajoutez les configurations requises.

Si certaines configurations requises sont vides dans le cluster d'administrateur parce que les validations ont été ignorées, leur ajout 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 et que vous l'ajoutez à l'aide de la commande gkectl update admin, le message d'erreur suivant peut s'afficher:

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

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
Configuration 1.15.0-1.15.10, 1.16.0-1.16.6, 1.28.0-1.28.200

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é 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 et 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
  ...
Espace de stockage 1.28.0-1.28.100

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

nfs-common est manquant dans l'image de l'OS Ubuntu, ce qui peut causer des problèmes pour les clients utilisant des pilotes dépendants de NFS tels que NetApp.

Si le journal contient une entrée semblable à la suivante après la mise à niveau vers la version 1.28, vous êtes alors concerné par ce problème : 
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 à partir de 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: /
Espace de stockage 1.28.0-1.28.100

Le champ "Règle de stockage" n'apparaît pas dans le modèle de configuration du cluster d'administrateur

Le protocole SPBM dans les clusters d'administrateur est compatible avec les versions 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" au 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.
Journalisation et surveillance 1.28.0-1.28.100

L'API Kubernetes Metadata 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. Par la suite, les étiquettes des métadonnées des métriques seront manquantes.

Solution :

Dans l'espace de noms "kube-system", la RS "stackdriver" définit le champ "featureGates.disableExperimentalMetadataAgent" sur "true" en exécutant la commande

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

puis exécutez

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

Mises à niveau et mises à jour 1.15.0-1.15.7, 1.16.0-1.16.4, 1.28.0

Le contrôleur clusterapi peut planter lorsque le cluster d'administrateur et tout cluster d'utilisateur pour lequel ControlPlane V2 est activé utilisent des identifiants vSphere différents.

Lorsqu'un cluster d'administrateur et un cluster d'utilisateur pour lequel ControlPlane V2 est activé utilisent des identifiants vSphere différents. Par exemple, après la mise à jour des identifiants vSphere pour le cluster d'administrateur, le contrôleur clusterapi-controller peut ne pas se connecter à vCenter après le redémarrage. Affichez le journal du contrôleur 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
Si le journal contient une entrée semblable à la suivante, vous êtes alors concerné par ce problème : 
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 pour lesquels Controlplane V2 est activé utilisent les mêmes identifiants vSphere.

Journalisation et surveillance 1,14

etcd : nombre élevé de requêtes gRPC ayant échoué dans le gestionnaire d'alertes Prometheus

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 pouvant être ignoré, procédez comme suit:

  1. Comparez la métrique grpc_server_handled_total brute au grpc_method indiqué dans le message d'alerte. Dans cet exemple, vérifiez l'étiquette grpc_code pour Watch.

    Vous pouvez vérifier cette métrique à l'aide de Cloud Monitoring à l'aide de la requête MQL suivante :
    fetch
    k8s_container | metric 'kubernetes.io/anthos/grpc_server_handled_total' | align rate(1m) | every 1m
  2. Une alerte sur tous les codes autres que OK peut être ignorée en toute sécurité si le code n'est pas l'un des suivants : 
    Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded

Solution :

Pour configurer Prometheus afin qu'il ignore ces alertes de faux positifs, consultez les options suivantes:

  1. Désactivez l'alerte à partir de l'interface utilisateur d'Alert Manager.
  2. Si vous ne pouvez pas couper le son de l'alerte, procédez comme suit pour supprimer les faux positifs :
    1. Réduisez l'opérateur Monitoring à 0 instances répliquées afin que les modifications puissent persister.
    2. Modifiez le ConfigMap prometheus-config et ajoutez grpc_method!="Watch" à la configuration de l'alerte etcdHighNumberOfFailedGRPCRequests, comme indiqué dans l'exemple suivant :
      • Version d'origine: 
        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 le CLUSTER_NAME suivant par le nom de votre cluster.
    3. Redémarrez Prometheus et Alertmanager Statefulset pour récupérer la nouvelle configuration.
  3. Si le code correspond à l'un des cas problématiques, consultez le journal etcd et le journal kube-apiserver pour en déboguer d'autres.
Mise en réseau 1.16.0-1.16.2, 1.28.0

Les connexions NAT à longue durée de vie de sortie sont supprimées

Les connexions NAT de sortie peuvent être supprimées après 5 à 10 minutes d'établissement d'une connexion en l'absence de trafic.

Comme conntrack n'a d'importance que dans la direction entrante (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é destination transmet quelque chose. Si le pod avec NAT de sortie instancie toujours la messagerie, ce problème ne sera pas observé.

Ce problème se produit car la récupération de mémoire anetd supprime par inadvertance les entrées conntrack que le daemon considère comme inutilisées. Un correctif en amont a été récemment intégré à anetd pour corriger le comportement.


Solution :

Il n'existe pas de solution de secours simple, et nous n'avons rencontré aucun problème lié à ce comportement dans la version 1.16. Si vous remarquez que les connexions de longue durée ont été abandonnées en raison de ce problème, des solutions de contournement consistent à utiliser une charge de travail sur le même nœud que l'adresse IP de sortie ou à envoyer systématiquement des messages via la connexion TCP.
Opération 1,14, 1,15, 1,16

Le signataire de la requête de signature de certificat ignore spec.expirationSeconds lors de la signature des certificats

Si vous créez une requête CertificateSigningRequest (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.
Mise en réseau, mises à niveau et mises à jour 1.16.0-1.16.3

É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 génère une erreur semblable à l'exemple suivant:

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

Cette erreur se produit, car gkectl recherche l'adresse IP d'entrée de l'é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 illustré dans l'exemple suivant:

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

Pour en savoir plus, découvrez comment désactiver les entrées groupées pour un cluster existant.
Mises à niveau et mises à jour 1.13, 1.14, 1.15.0-1.15.6

Les mises à jour du cluster d'administrateur échouent après la rotation de l'autorité de certification

Si vous effectuez une rotation des certificats de l'autorité de certification du cluster d'administrateur, les tentatives suivantes d'exécution de la commande gkectl update admin échouent. L'erreur renvoyée est semblable à celle-ci:

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'option --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 référence lors de la mise à jour du cluster. Le fichier de point de contrôle est toujours mis à jour pour une utilisation ultérieure.
Espace de stockage 1.15.0-1.15.6, 1.16.0-1.16.2

É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éliminaires, la vérification de validation de la charge de travail CSI installe un pod dans l'espace de noms default. Le pod de charge de travail CSI vérifie que le pilote CSI vSphere est installé et peut effectuer un provisionnement dynamique de volume. 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 sur lesquels des webhooks d'admission sont installés, le pod ne démarre pas.
  • Si Anthos 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 savoir si l'échec est dû à un manque de ressources de pod définies, exécutez la commande suivante afin de vérifier l'état de la tâche 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 étiquettes de l'espace de noms, puis utilisez la commande suivante pour supprimer l'étiquette commençant par istio.io/rev:

kubectl label namespace default istio.io/rev-

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

  1. Créez une PVC qui utilise la StorageClass standard-rwo.
  2. Créer un pod qui utilise le PVC
  3. Vérifiez que le pod peut lire et écrire des données sur le volume.
  4. Après avoir vérifié que le fonctionnement fonctionne, supprimez le pod et le PVC.

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

Opération 1.16.0-1.16.2

Expiration du délai de 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 gkectl update cluster. Lorsque cet échec se produit, l'erreur suivante s'affiche lorsque vous tentez 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 avant expiration 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
Opération 1.16.0-1.16.2

Expirations de délai lors 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 à la création du cluster d'utilisateur. Cela se produit si la version du cluster d'administrateur est 1.15. Dans ce cas, 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, lors de l'utilisation du cluster d'administrateur 1.15, le validation-controller chargé de déclencher les vérifications préliminaires est manquant. Par conséquent, lorsque vous tentez de créer un cluster d'utilisateur, les vérifications préliminaires se bloquent jusqu'à ce que le délai 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.
Mises à niveau et mises à jour 1.16.0-1.16.2

La mise à jour ou la mise à niveau du cluster d'administrateur échoue si les projets ou les emplacements des services complémentaires 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 lors de la mise à jour d'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 du cluster d'administrateur nécessite que onprem-admin-cluster-controller rapproche le cluster d'administrateur dans un cluster de genre. Lorsque l'état du cluster d'administrateur est restauré dans le cluster de genre, le webhook du cluster d'administrateur ne peut pas déterminer si l'objet OnPremAdminCluster est destiné à la création d'un cluster d'administrateur ou à la reprise des opérations en vue d'une mise à jour ou d'une mise à niveau. Certaines validations de type "création uniquement" sont appelées lors d'une mise à jour ou d'une mise à niveau inattendue.


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 ce qui suit :
    • 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. Selon le type de cluster d'administrateur, effectuez l'une des opérations suivantes :
    • Pour les clusters d'administrateur standards disposant d'un fichier de point de contrôle:ajoutez le paramètre disable-update-from-checkpoint dans la commande de mise à jour ou ajoutez le paramètre "disable-upgrade-from-checkpoint" à la commande de mise à niveau. Ces paramètres ne seront 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 haute disponibilité ou le fichier de point de contrôle, mettez à jour ou mettez à niveau le cluster d'administrateur normalement. Aucun paramètre supplémentaire n'est requis sur les commandes de mise à jour ou de mise à niveau.
Opération 1.16.0-1.16.2

Échec de la suppression du 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. Dans ce cas, l'erreur suivante s'affiche lorsque vous tentez 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 commence par supprimer tous ses objets. La suppression des objets Validation (créés lors de la création, de la mise à jour ou de la mise à niveau) reste bloquée lors de la phase de suppression. En effet, un finaliseur bloque la suppression de l'objet, ce qui entraîne l'échec de la suppression du cluster.

Solution :

  1. Obtenez le nom de tous les objets Validation : 
             kubectl  --kubeconfig ADMIN_KUBECONFIG get validations \
           -n USER_CLUSTER_NAME-gke-onprem-mgmt
  2. Pour chaque objet de validation, exécutez la commande suivante afin de supprimer le finaliseur de l'objet de 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 Validation, ceux-ci sont supprimés et l'opération de suppression du cluster d'utilisateur se termine automatiquement. Aucune autre action n'est requise de votre part.

Mise en réseau 1,15, 1,16

É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 du pod source ne peut atteindre aucun service externe. Si les pods sont situés sur le même hôte, la connexion au service ou à l'application externes aboutit.

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


Solution :

Remplacez le port VXLAN utilisé par Cilium par 4789:

  1. Modifiez le ConfigMap cilium-config : 
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG
  2. Ajoutez le code suivant au 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 est rétablie à chaque mise à niveau du cluster. Vous devez la reconfigurer après chaque mise à niveau. VMware doit résoudre son problème dans vSphere pour un correctif permanent.
Mises à niveau 1.15.0-1.15.4

Échec de la mise à niveau d'un cluster d'administrateur pour lequel le chiffrement des secrets est activé en permanence

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 incohérence entre la clé de chiffrement générée par le contrôleur et la clé qui persiste sur le disque de données principal de l'administrateur. La sortie 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 VM maître administrateur créée, connectez-vous en SSH à la VM maîtresse administrateur et remplacez la nouvelle clé sur le disque de données par l'ancienne sauvegarde. La clé se trouve dans l'emplacement /opt/data/gke-k8s-kms-plugin/generatedkeys du maître administrateur.
  3. Mettez à jour le fichier manifeste statique du pod kms-plugin.yaml dans /etc/kubernetes/manifests pour modifier le --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 dans un autre répertoire, puis en le replaçant.
  5. Reprenez la mise à niveau de l'administrateur en exécutant à nouveau gkectl upgrade admin.

Éviter l'échec de la mise à niveau

Si vous n'avez pas encore effectué la mise à niveau, nous vous recommandons de ne pas passer à la version 1.15.0-1.15.4. Si vous devez effectuer une mise à niveau vers une version affecté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 permanent des secrets.
Espace de stockage 1,11-1,16

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 de VMware.


Solution :

Ne sauvegardez pas les VM Google Distributed Cloud, car un logiciel de sauvegarde tiers peut entraîner l'activation de CBT sur leurs disques. Il n'est pas nécessaire de sauvegarder ces VM.

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

Si vous disposez déjà de disques avec CBT activé, suivez la procédure de résolution décrite dans l'article de la base de connaissances VMware pour désactiver le CBT sur le disque de première classe.
Espace de stockage 1,14, 1,15, 1,16

Corruption des 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 des données ou l'incapacité des pods à s'exécuter. 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 associé de la base de connaissances de VMware.


Solution :

L'article de la base de connaissances VMware est obsolète, car il indique qu'il n'y a actuellement aucune solution. 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.
Système d'exploitation 1.13.10, 1.14.6, 1.15.3

Non-concordance des versions 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 incohérence, car le binaire du kubelet préchargé sur l'image de l'OS utilise une version différente.

Le tableau suivant répertorie les incohérences au niveau des versions identifiées:

Version de Google Distributed Cloud Version du kubelet Version de Kubernetes
1.13.10 v1.24.11-gke.1200 v1.24.14-gke.2100
1.14.6 v1.25.8-gke.1500 v1.25.10-gke.1200
1.15.3 v1.26.2-gke.1001 v1.26.5-gke.2100

Solution :

Aucune action n'est requise de votre part. L'incohérence ne concerne que les versions de correctif Kubernetes, et ce décalage entre les versions n'a causé aucun problème.

Mises à niveau et mises à jour 1.15.0-1.15.4

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

Lorsqu'un cluster d'administrateur possède une version de l'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 de gkectl contient le message d'erreur suivant: 

    CAVersion must start from 1

Solution :

  • Effectuez un scaling à la baisse du déploiement auto-resize-controller dans le cluster d'administrateur pour désactiver le redimensionnement automatique des nœuds. Cette étape 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
Opération 1.13, 1.14.0-1.14.8, 1.15.0-1.15.4, 1.16.0-1.16.1

La suppression des clusters non haute disponibilité dans Controlplane V2 est bloquée jusqu'à expiration du délai d'inactivité.

Lorsqu'un cluster Controlplane V2 standard est supprimé, il est bloqué à la suppression du nœud jusqu'à l'expiration du délai.

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 de 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

Espace de stockage 1.15.0, 1.16.0 et ultérieures

Des tâches d'association de volume CNS constantes apparaissent toutes les minutes pour les PVC et les PV "in-tree" 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éées avec la StorageClass standard), vous verrez les tâches com.vmware.cns.tasks.attachvolume déclenchées toutes les minutes depuis vCenter.


Solution :

Modifiez le configMap de la fonctionnalité CSI vSphere 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 vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Espace de stockage 1.16.0

Faux avertissements concernant les PVC

Lorsqu'un cluster contient des volumes persistants vSphere Intree, 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 associé à 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 cet avertissement en toute sécurité:

      pv.kubernetes.io/bind-completed: "yes"
      pv.kubernetes.io/bound-by-controller: "yes"
      volume.beta.kubernetes.io/storage-provisioner: csi.vsphere.vmware.com
Mises à niveau et mises à jour 1.15.0, 1.16.0 et ultérieures

La rotation des clés de compte de service échoue lorsque plusieurs clés arrivent à expiration

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

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

Solution :

Commencez par alterner la clé de compte de service d'accès au composant. 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 au composant.

Si la mise à jour échoue toujours, contactez Cloud Customer Care pour résoudre ce problème.
Mises à niveau 1.16.0-1.16.5

1.15 La machine principale de l'utilisateur rencontre une recréation inattendue lors de la mise à niveau du contrôleur de cluster d'utilisateur vers la version 1.16

Lors de la mise à niveau d'un cluster d'utilisateur, après la mise à niveau du contrôleur de cluster d'utilisateur vers la version 1.16, si 1.15 autres clusters d'utilisateur sont gérés par le même cluster d'administrateur, il se peut que leur machine maître d'utilisateur soit recréée de manière inattendue.

Le contrôleur de cluster d'utilisateur 1.16 présente un bug qui peut déclencher la recréation de la machine principale de l'utilisateur 1.15.

La solution 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 réexécution 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 lors de 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 de 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
    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.
Créer 1.16.0-1.16.5, 1.28.0-1.28.100

La vérification préliminaire échoue lorsque le nom d'hôte ne figure pas dans le fichier de blocs 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 dans le fichier de blocs d'adresses IP, la vérification préliminaire échoue avec le message d'erreur suivant : 

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

La vérification préliminaire comporte un bug qui suppose que le nom d'hôte vide est en double.

Solution :

Option 1: Utilisez une version avec 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 blocs d'adresses IP.
Mises à niveau et mises à jour 1.16

Échec de l'installation du volume lors de la mise à niveau ou de la mise à jour du cluster d'administrateur si vous utilisez un cluster d'administrateur standard et un cluster d'utilisateur de plan de contrôle v1

Pour un cluster d'administrateur standard et un cluster d'utilisateur de plan de contrôle v1, la recréation de la machine principale du cluster d'administrateur peut se produire en même temps que la machine maître du cluster d'utilisateur, ce qui peut mettre en évidence une condition de concurrence. Dans ce cas, les pods du plan de contrôle du cluster d'utilisateur ne peuvent pas communiquer avec le plan de contrôle du cluster d'administrateur, ce qui entraîne des problèmes d'association de volume 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
Vous verrez également les événements suivants : 
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 d'utilisateur : comme il s'agit d'un cluster d'utilisateur du plan de contrôle v1, le nœud du plan de contrôle d'utilisateur se trouve dans le cluster d'administrateur.
  2. Redémarrez le kubelet à l'aide de la commande suivante : 
        sudo systemctl restart kubelet
    Après le redémarrage, le kubelet peut reconstruire correctement l'installation globale de l'étape.
Mises à niveau et mises à jour 1.16.0

É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 amener le gestionnaire de contrôleurs cloud vSphere à supprimer de manière inattendue un nouveau nœud de plan de contrôle. Cela provoque le blocage du contrôleur clusterapi dans l'attente de la création du nœud, et même l'expiration du délai de mise à niveau/mise à jour. Dans ce cas, le résultat de la commande de mise à niveau/mise à jour gkectl se présente comme 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 problème, exécutez la commande ci-dessous pour vous connecter au gestionnaire de contrôleurs 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 de 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 défaillante pour recréer l'objet de 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ôleurs 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.
Opération 1.16

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 échoue s'il existe des noms d'hôte en double dans le même centre de données. Cet échec est dû au fait que le gestionnaire du contrôleur cloud vSphere ne parvient pas à ajouter une adresse IP externe et un ID de fournisseur dans l'objet de nœud. Cela entraîne l'expiration du délai de mise à niveau/de création du cluster.

Pour identifier le problème, récupérez les journaux de pod du gestionnaire de contrôleur cloud vSphere pour le cluster. La commande à utiliser 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 (kubeception) : 
          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: (Controlplane V2) : 
          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 existe en double dans le centre de données:

Vous pouvez utiliser l'approche suivante pour vérifier si le nom d'hôte est dupliqué et contourner le problème si nécessaire. 
          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
Exemples de commandes et de résultats : 
          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 dépend de l'opération ayant échoué.

Solution pour les mises à niveau:

Procédez comme suit pour le type de cluster applicable.

  • 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. Remplacez le nom d'hôte de la machine concernée dans admin-ip-block.yaml avec 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 standard et que vous constatez que la VM maître administrateur utilise un nom d'hôte en double, vous devez également:
      Obtenir le nom de la machine principale d'administration 
                kubectl get machine --kubeconfig ADMIN_KUBECONFIG -owide -A
      Mettre à jour l'objet de la machine administrateur maître
      Remarque:Le nom d'hôte NEW_ADMIN_MASTER_HOSTNAME doit être identique à celui 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 a été mis à jour dans l'objet machine maître 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. Réexécutez la mise à niveau du cluster d'administrateur en désactivant le point de contrôle:
                gkectl upgrade admin --kubeconfig ADMIN_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --disable-upgrade-from-checkpoint

Solution pour les installations:

Procédez comme suit pour le type de cluster applicable.
Opération 1.16.0, 1.16.1, 1.16.2, 1.16.3

$ et ` ne sont pas compatibles avec le nom d'utilisateur ou le mot de passe vSphere

Les opérations suivantes échouent lorsque le nom d'utilisateur ou le mot de passe vSphere contient $ 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é 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 effectuez la solution ci-dessous. La solution de contournement dépend de l'opération ayant échoué.

Solution 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éclencher 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. Procédez comme suit pour le type de cluster applicable.
Espace de stockage 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16

Échec de la création de la PVC une fois le nœud recréé avec le même nom

Lorsqu'un nœud est supprimé, puis recréé avec le même nom de nœud, il se peut qu'une création ultérieure de PersistentVolumeClaim (PVC) échoue avec une erreur semblable à celle-ci:

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

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


Solution :

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

    kubectl rollout restart vsphere-csi-controller -n kube-system --kubeconfig KUBECONFIG
Opération 1.16.0

gkectl Repair admin-master renvoie une erreur kubeconfig unmarshall

Lorsque vous exécutez la commande gkectl repair admin-master sur un cluster d'administrateur haute disponibilité, 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'option --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, procédez comme suit:

  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.

    Les trois modèles de VM du cluster d'administrateur doivent s'afficher.

  3. Copiez le nom du modèle de VM correspondant au nom de la machine que vous réparez et utilisez le nom du modèle 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
Mise en réseau 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0-1.14.7, 1.15.0-1.15.3, 1.16.0

VM Seesaw interrompue en raison d'un espace disque insuffisant

Si vous utilisez Seesaw comme type d'équilibreur de charge pour votre cluster et que vous constatez qu'une VM Seesaw est arrêtée ou ne parvient pas à démarrer, 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 insuffisant sur la VM, car le fluent-bit exécuté sur la VM Seesaw n'est pas configuré avec une rotation des journaux correcte.


Solution :

À l'aide de du -sh -- /var/lib/docker/containers/* | sort -rh, recherchez les fichiers journaux qui consomment le plus d'espace disque. Nettoyez le fichier journal dont la taille est la plus importante et redémarrez la VM.

Remarque:Si la VM est totalement inaccessible, associez le disque à une VM en état de fonctionnement (par exemple, un poste de travail administrateur), retirez le fichier du disque installé, 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 à la commande Docker, puis exécutez systemctl restart docker.fluent-bit.service.
Opération 1.13, 1.14.0-1.14.6, 1.15

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 (gkectl update admin) un cluster d'administrateur sans haute disponibilité avec un point de contrôle activé, la mise à niveau peut échouer et renvoyer des erreurs telles que : 

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 de correctif de Google Distributed Cloud avec ce correctif, contactez l'assistance Google pour obtenir de l'aide.
Mises à niveau 1.13.0-1.13.9, 1.14.0-1.14.6, 1.15.1-1.15.2

La mise à niveau d'un cluster d'administrateur enregistré dans l'API GKE On-Prem pourrait é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. Dans ce cas, l'erreur suivante s'affiche lorsque vous tentez 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 API GKE On-Prem.


Solution :

Désinscrivez le cluster d'administrateur : 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
, puis reprenez la mise à niveau du cluster d'administrateur. L'erreur obsolète "Échec de l'enregistrement du cluster" peut s'afficher temporairement. Après un certain temps, il devrait être mis à jour automatiquement.
Mises à niveau et mises à jour 1.13.0-1.13.9, 1.14.0-1.14.4, 1.15.0

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 l'utilisation d'une clé d'annotation incorrecte. Cela peut entraîner l'enregistrement à nouveau du cluster d'administrateur dans l'API GKE On-Prem.

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 API GKE On-Prem.


Solution :

Désinscrivez le cluster d'administrateur 
    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
, puis réenregistrez le cluster d'administrateur.
Mise en réseau 1.15.0-1.15.2

orderPolicy CoreDNS non reconnu

OrderPolicy n'est pas reconnu en tant que paramètre et n'est pas utilisé. À la place, Google Distributed Cloud utilise toujours Random.

Ce problème est dû au fait que le modèle CoreDNS n'a pas été mis à jour. orderPolicy est donc ignoré.


Solution :

Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif persiste jusqu'à la 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 }}
Mises à niveau et mises à jour 1.10, 1.11, 1.12, 1.13.0-1.13.7, 1.14.0-1.14.3

État OnPremAdminCluster incohérent entre le point de contrôle et la RS réelle

Certaines conditions de concurrence peuvent entraîner des incohérences entre l'état du OnPremAdminCluster et celui de la RS. Lorsque le problème se produit, vous pouvez rencontrer l'erreur suivante 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
Pour contourner ce problème, vous devez modifier le point de contrôle ou désactiver celui pour la mise à niveau ou la mise à jour. Veuillez contacter notre équipe d'assistance pour trouver une solution.
Opération 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Le processus de rapprochement 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 rapprochement, par exemple lors d'une 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 version 1.15.

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

  • Les certificats non valides peuvent entraîner l'expiration du délai des commandes suivantes et renvoyer des erreurs :
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Ces commandes peuvent renvoyer des erreurs d'autorisation semblables à celles-ci:

    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 :

Effectuez une mise à niveau vers une version de Google Distributed Cloud comprenant les correctifs suivants : 1.13.10+, 1.14.6+, 1.15.2+. Si vous ne pouvez pas effectuer la mise à niveau, contactez Cloud Customer Care pour résoudre ce problème.
Mise en réseau, exploitation 1,10, 1,11, 1,12, 1,13, 1,14

Composants de passerelle réseau Anthos supprimés ou en attente en raison d'une classe de priorité manquante

Les pods de passerelle réseau dans 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 une incapacité à planifier des pods en raison des ressources de nœuds. Comme les pods de passerelle réseau Anthos n'ont pas de classe PriorityClass, ils ont la même priorité par défaut que les autres charges de travail. Lorsque les nœuds sont limités en ressources, les pods de la passerelle réseau peuvent être supprimés. Ce comportement est particulièrement préjudiciable pour le DaemonSet ang-node, car ces pods doivent être programmés sur un nœud spécifique et ne peuvent pas être migrés.


Solution :

Passez à la version 1.15 ou ultérieure.

À court terme, vous pouvez attribuer manuellement une classe PriorityClass aux composants de la passerelle réseau Anthos. Le contrôleur Google Distributed Cloud Controller écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau d'un cluster.

  • Attribuez la classe PriorityClass system-cluster-critical aux déploiements du contrôleur de cluster ang-controller-manager et autoscaler.
  • Attribuez la classe PriorityClass system-node-critical au DaemonSet du nœud ang-daemon.
Mises à niveau et mises à jour 1.12, 1.13, 1.14, 1.15.0-1.15.2

La mise à niveau du cluster d'administrateur échoue après l'enregistrement du cluster avec gcloud

Une fois que vous avez 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
Obtenez le nom du cluster d'administrateur : 
kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Supprimez l'appartenance au parc : 
gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
et reprenez la mise à niveau du cluster d'administrateur.
Opération 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

gkectl diagnose snapshot --log-since ne parvient pas à limiter la période des commandes journalctl exécutées sur les nœuds du cluster

Cela n'affecte pas la fonctionnalité permettant de prendre un instantané du cluster, car celui-ci 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.
Installation, mises à niveau et mises à jour 1.9+, 1.10+, 1.11+, 1.12+

É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 :

Pour contourner ce problème, l'idée générale consiste à effectuer une mise à niveau vers Google Distributed Cloud 1.13 et à utiliser le gkectl 1.13 pour créer un modèle de VM Windows, puis à créer des pools de nœuds Windows. Deux options s'offrent à vous pour accéder à Google Distributed Cloud 1.13 à partir de votre version actuelle, comme indiqué ci-dessous.

Remarque:Il existe des options pour contourner ce problème dans votre version actuelle sans avoir à effectuer une mise à niveau complète vers la version 1.13. Toutefois, des étapes supplémentaires sont nécessaires. 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 la version Google Distributed Cloud 1.13 ou version ultérieure avec des pools de nœuds Windows, puis migrer vos charges de travail vers le nouveau cluster, puis supprimer le cluster actuel. Il est recommandé d'utiliser la dernière version mineure de Google Distributed Cloud.

Remarque:Le provisionnement du nouveau cluster nécessitera des ressources supplémentaires, mais les temps d'arrêt et les perturbations seront réduits pour les charges de travail existantes.


Option 2:supprimez les pools de nœuds Windows et rajoutez-les lors de la mise à niveau vers Google Distributed Cloud 1.13.

Remarque:Pour 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é rajouté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 administrateur+utilisateur Linux vers la version 1.12 en suivant le guide de mise à niveau de l'utilisateur pour la version mineure cible correspondante.
  3. (Assurez-vous d'effectuer cette étape avant de passer à la version 1.13.) Assurez-vous que enableWindowsDataplaneV2: true est configuré dans la RS OnPremUserCluster. Sinon, le cluster continuera à utiliser les pools de nœuds Docker pour Windows, qui ne seront pas compatibles avec le modèle de VM Windows 1.13 nouvellement créé sur lequel Docker n'est pas installé. Si cette règle n'est pas configurée ou si elle est définie sur "false", mettez à jour votre cluster pour qu'elle soit définie 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 de l'utilisateur.
  5. Préparez un modèle de VM Windows à l'aide de la version 1.13 de gkectl : 
    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Ajoutez de nouveau la configuration du pool de nœuds Windows à user-cluster.yaml en définissant le champ OSImage sur le nouveau modèle de VM Windows.
  7. Mettez à jour le cluster pour ajouter des pools de nœuds Windows 
    gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installation, mises à niveau et mises à jour 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

La valeur par défaut de 5 secondes pour RootDistanceMaxSec sera utilisée sur les nœuds, au lieu de 20 secondes, qui devraient être la configuration attendue. Si vous consultez le journal de démarrage du nœud en vous connectant en SSH à la VM, située dans/var/log/startup.log, vous pouvez obtenir 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 5 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 à 5 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: /
Mises à niveau et mises à jour 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

Échec de gkectl update admin, car le champ osImageType est vide

Lorsque vous utilisez la version 1.13 gkectl pour mettre à jour un cluster d'administrateur 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 des clusters version 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 constaterez peut-être que les différentes modifications incluent la définition de osImageType depuis une chaîne vide sur ubuntu_containerd.

Ces erreurs de mise à jour sont dues à un remplissage incorrect du champ osImageType dans la configuration du cluster d'administrateur depuis son introduction dans la version 1.9.


Solution :

Passez à une version de Google Distributed Cloud avec le correctif. Si la mise à niveau n'est pas possible, contactez Cloud Customer Care pour résoudre ce problème.
Installation, sécurité 1,13, 1,14, 1,15, 1,16

L'extension 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 le plan de contrôle V2 est activé ( enableControlplaneV2: true).


Solution :

Tant qu'un correctif Google Distributed Cloud ne sera pas disponible avec le correctif, si vous devez utiliser l'extension SNI, désactivez Controlplane V2 (enableControlplaneV2: false).
Installation 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ 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 administrateur ne parvient pas à démarrer lorsque le nom d'utilisateur du registre privé contient $. Lorsque vous vérifiez le /var/log/startup.log sur la machine du plan de contrôle 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 une version de Google Distributed Cloud avec le correctif.
Mises à niveau et mises à jour 1.12.0-1.12.4

Avertissements de faux positifs concernant des modifications non acceptées lors de la mise à jour du cluster d'administrateur

Lorsque vous mettez à jour des clusters d'administrateur, les avertissements de 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,
      ...
    }
Mises à niveau et mises à jour 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

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

Une fois que vous avez procédé à la rotation des clés de signature KSA, puis mis à jour un cluster d'utilisateur, gkectl update peut échouer avec 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 :

Redéfinissez la version de votre clé de signature KSA sur 1, tout en conservant les données de clé les plus récentes :
  1. Vérifiez le secret dans le cluster d'administrateur sous l'espace de noms USER_CLUSTER_NAME, puis récupérez 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 nommez le secret copié en tant que 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 configmap 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 de 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 l'état à l'aide de l'une des méthodes suivantes : 
    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 jusqu'à ce que le cluster soit mis à niveau vers la version avec le correctif.
Opération 1.13.1+, 1.14, 1., 1.16

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 .
Installation, mises à niveau et mises à jour 1.13.8, 1.14.4

Le cluster de genre extrait des images de conteneur de docker.io

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

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • 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 d'afficher le genre de cluster. 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 semblables à celle-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 le genre de l'image de conteneur du cluster. Cependant, le genre v0.18.0 présente un problème avec les images de conteneur préchargées, qui sont alors extraites d'Internet par erreur.


    Solution :

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

    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
    Opération 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

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

    Si vos VM de cluster sont connectées avec un commutateur qui filtre les requêtes GARP (ARP gratuites) en double, l'élection du leader keepaLiving 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 à cette adresse IP virtuelle expire.


    Solution :

    Exécutez la commande suivante sur chaque nœud du plan de contrôle du cluster concerné : 
        iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Mises à niveau et mises à jour 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

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

    vsphere-csi-controller doit actualiser son secret vCenter après la rotation des certificats vCenter. Cependant, 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 à partir de la version 1.13, suivez les instructions ci-dessous pour redémarrer vsphere-csi-controller 

    kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Installation 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    La création du cluster d'administrateur n'échoue pas en cas d'erreur 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 n'échoue pas et peut aboutir. En d'autres termes, la création du cluster d'administrateur a pu "réussir" sans être enregistré dans un parc.

    Pour identifier le symptôme, recherchez les messages d'erreur suivants dans le journal de "gkectl create admin", 
    Failed to register admin cluster
    .

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

    Solution :

    Pour les clusters créés à partir de la version 1.12, suivez les instructions permettant de réessayer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters créés dans des versions antérieures,

    1. En ajoutant une fausse paire clé-valeur telle que "foo: bar" au fichier de clé connect-register
    2. Exécutez gkectl update admin pour réenregistrer le cluster d'administrateur.

    Mises à niveau et mises à jour 1.10, 1.11, 1.12, 1.13.0-1.13.1

    Le réenregistrement du cluster d'administrateur peut être ignoré lors de la mise à niveau du cluster d'administrateur

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


    Solution :

    Vérifiez si le cluster figure parmi les clusters enregistrés. Vous pouvez aussi vous connecter au cluster après avoir configuré l'authentification. Si le cluster est toujours enregistré, vous pouvez ignorer les instructions ci-dessous pour effectuer une nouvelle tentative d'enregistrement. Pour les clusters mis à niveau vers la version 1.12 et les versions ultérieures, suivez les instructions permettant de réessayer l'enregistrement du cluster d'administrateur après la création du cluster. Pour les clusters mis à niveau vers des versions antérieures :
    1. En ajoutant une fausse paire clé-valeur telle que "foo: bar" au fichier de clé connect-register
    2. Exécutez gkectl update admin pour réenregistrer le cluster d'administrateur.

    Configuration 1.15.0

    Faux message d'erreur concernant vCenter.dataDisk

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

    vCenter.dataDisk must be present in the AdminCluster spec

    Solution :

    Vous pouvez ignorer ce message d'erreur.
    VMware 1.15.0

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

    Lors de la création d'un pool de nœuds qui utilise 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 pouvoir continuer la création du pool de nœuds. Ces règles sont nommées [USER_CLUSTER_NAME]-[HASH].
    Opération 1.15.0

    gkectl repair admin-master peut échouer pour la raison suivante : 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 en toute sécurité jusqu'à ce que la commande aboutisse.
    Mises à niveau et mises à jour 1.15.0

    Les pods restent à l'état "Échec" après la recréation ou la mise à jour d'un nœud de 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 de l'échec du prédicat NodeAffinity. Ces pods défaillants n'affectent pas le fonctionnement normal du cluster ni son état.


    Solution :

    Vous pouvez ignorer les pods en échec ou les supprimer manuellement.
    Sécurité, configuration 1.15.0-1.15.1

    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é, l'OnPremUserCluster risque de ne pas être prêt et le message d'erreur suivant peut s'afficher : 

    failed to check secret reference for private registry …


    Solution :

    Préparez les identifiants du registre privé pour le cluster d'utilisateur conformément aux instructions de la section Configurer les identifiants préparés.

    Mises à niveau et mises à jour 1.15.0

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

    Pendant gkectl upgrade admin, la vérification préliminaire du stockage pour la migration CSI vérifie que les ressources StorageClass 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 la signale et signale un échec lors de la validation préliminaire. Les clusters d'administrateur créés dans Google Distributed Cloud 1.10 et versions antérieures disposent d'une StorageClass avec diskformat: thin qui échouera à cette validation. Cependant, cette StorageClass fonctionne toujours après la migration CSI. Ces échecs doivent être interprétés comme des avertissements.

    Pour en savoir plus, consultez la section sur le paramètre StorageClass dans Migrer des volumes vSphere In-Tree vers le plug-in de stockage de conteneurs vSphere.


    Solution :

    Après avoir vérifié 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'option --skip-validation-cluster-health.
    Espace de stockage 1,15, 1,16

    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 d'une mise à niveau du cluster ou de la mise à jour d'un pool de nœuds). Il est possible que les charges de travail avec état qui fonctionnaient correctement auparavant ne puissent pas écrire dans leurs volumes sur le nouvel ensemble de nœuds.


    Solution :

    1. Obtenez l'UID du pod qui ne peut pas écrire sur son volume : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Utilisez la PersistentVolumeClaim pour obtenir le nom du 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 en cours d'exécution : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Obtenez un accès PowerShell au nœud, via SSH ou 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 programmé sur le même nœud. Toutefois, si le pod est programmé sur un nouveau nœud, vous devrez peut-être répéter les étapes précédentes sur ce nouveau nœud.

    Mises à niveau et mises à jour 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

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

    Si vous mettez à jour les identifiants vSphere d'un cluster d'administrateur après avoir mis à jour les identifiants du cluster, il est possible que vsphere-csi-secret sous l'espace de noms kube-system du cluster d'administrateur utilise toujours l'ancien identifiant.


    Solution :

    1. Obtenez le nom du 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 correctement déployé, le contrôleur doit utiliser le vsphere-csi-secret mis à jour.
    Mises à niveau et mises à jour 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

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

    audit-proxy risque de subir une 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 conteneur / du pod audit-proxy.


    Solution :

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

    Pour un cluster d'utilisateur de 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
    Mises à niveau et mises à jour 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    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 à nouveau. L'état du cluster de gkectl list clusters passe de RUNNING à RECONCILING. Les requêtes adressé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 concerne que 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 à des versions avec le correctif suivant: 1.13.6+, 1.14.2+ ou 1.15+.
    Mises à niveau et mises à jour 1.12.7

    La version 1.12.7-gke.19 incorrecte 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.
    Mises à niveau et mises à jour 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    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é

    Vous constaterez peut-être que gke-connect-agent continue d'utiliser l'ancienne image ou que les pods gke-connect-agent ne peuvent pas être extraits en raison de l'erreur 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éployez 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 d'enregistrement 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 de la clé secrète pour l'extraction d'images regcred qui est utilisée par le déploiement de 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 la clé secrète pour l'extraction d'images par défaut pour votre cluster dans le déploiement gke-connect-agent. Pour ce faire, procédez 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"}]}}}}'
    Installation 1,13, 1,14

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

    Si vous validez la configuration avant de créer un cluster avec un équilibreur de charge manuel en exécutant gkectl check-config, la commande échouera et affichera 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 1.13.7 et 1.14.4 du correctif qui incluraient 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
    Opération 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 et 1.14

    faim de la montre etcd

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

    • La planification des pods est interrompue
    • Impossible d'enregistrer les nœuds
    • Le kubelet n'observe pas les changements de 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 la version 3.4.21 d'etcd. Toutes les versions précédentes de Google Distributed Cloud sont affectées par ce problème.

    Solution

    Si vous ne pouvez pas effectuer une mise à niveau immédiate, vous pouvez limiter le risque de défaillance d'un cluster en réduisant le nombre de nœuds qu'il contient. Supprimez les 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 Sélectionner une métrique, saisissez Kubernetes Container dans la barre de filtre, puis sélectionnez la métrique à l'aide des sous-menus :
      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.
    Mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13 et 1,14

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

    Lors des redémarrages ou des mises à niveau du cluster, le service GKE Identity Service peut être submergé par le trafic constitué de jetons JWT expirés transférés depuis kube-apiserver vers GKE Identity Service via le webhook d'authentification. Bien que GKE Identity Service n'effectue pas de boucle de plantage, il ne répond plus et cesse de traiter les requêtes à venir. Ce problème conduit 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 en externe : 
      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 pour 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 réexécutez la commande curl pour voir si le problème est résolu. Si le code d'état 000 s'affiche, le problème a été résolu et vous avez terminé. Si vous obtenez toujours un code d'état 400, le serveur HTTP Identity Service de GKE ne démarre pas. Dans ce cas, continuez.

    2. Vérifiez les journaux GKE Identity Service et 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 à celle-ci, vous êtes alors 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 semblables aux suivantes, 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 problématiques comme solution de contournement:

    1. Augmentez le niveau de verbosité du service 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. Recherchez le contexte de jeton non valide dans le journal GKE Identity Service : 
      kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Pour obtenir la charge utile de 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 à l'adresse jwt.io.
    5. Redémarrez les pods identifiés à partir des jetons.
    Opération 1,8, 1,9, 1,10

    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 affecté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: effectuez la mise à niveau vers la dernière version du correctif, de la version 1.8 à la version 1.11, qui contient le correctif.

    Option 2: Si vous utilisez des versions de correctif antérieures à 1.9.6 et 1.10.3, vous devez effectuer un scaling à la baisse du pod etcd-maintenance pour le cluster d'administrateur et 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
    Opération 1,9, 1,10, 1,11, 1,12, 1,13

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

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


    Solution :

    Cela n'affectera pas la gestion des charges de travail ou 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
    Mises à niveau et mises à jour 1.6+, 1.7+

    Les mises à niveau du cluster d'administrateur 1.6 et 1.7 peuvent être affectées par la redirection k8s.gcr.io -> registry.k8s.io

    Kubernetes a redirigé le trafic de k8s.gcr.io vers registry.k8s.io le 20/03/2023. 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 du conteneur.


    Solution :

    Ajoutez registry.k8s.io à la liste d'autorisation du proxy pour votre poste de travail administrateur.
    Mise en réseau 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    É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 qu'il existe déjà un fichier de groupe à bascule. 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 du fichier est seesaw-for-gke-admin.yaml pour le cluster d'administrateur et seesaw-for-{CLUSTER_NAME}.yaml pour un cluster d'utilisateur.
    Mise en réseau 1,14

    Délais d'inactivité de l'application causés par les échecs d'insertion de la table conntrack

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

    Pour savoir si vous êtes concerné par ce problème, vous pouvez consulter les statistiques du système de suivi des connexions 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 une valeur non nulle, vous êtes concerné par ce problème.

    Solution

    L'atténuation à court terme consiste à augmenter la taille de la table de hachage netfiler (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 valeur par défaut de la taille de la table est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs sur le nœud. Par exemple, si votre nœud a huit cœurs, définissez la taille de la table sur 524288.
    Mise en réseau 1.13.0-1.13.2

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

    Avec le plan de contrôle v2 ou un nouveau modèle d'installation, calico-typha ou anetd-operator peut être programmé sur les nœuds Windows et entrer dans une boucle de plantage.

    La raison est que les deux déploiements tolèrent tous les rejets, y compris ceux des nœuds Windows.


    Solution :

    Effectuez la mise à 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 l'élément spec.template.spec.tolerations suivant:

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

    Ajoutez la tolérance suivante:

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

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

    Vous ne pourrez peut-être pas créer de cluster d'utilisateur si vous spécifiez la section privateRegistry avec l'identifiant fileRef. La vérification préliminaire peut échouer et afficher le message suivant :

    [FAILURE] Docker registry access: Failed to login.


    Solution :

    • Si vous n'aviez 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és 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 d'une correction temporaire et ces champs sont déjà obsolètes. Envisagez d'utiliser le fichier d'identifiants lors de la mise à niveau vers la version 1.14.3+.)

    Opérations 1.10+

    Anthos Service Mesh et autres maillages de services non compatibles avec Dataplane v2

    Dataplane V2 prend en charge l'équilibrage de charge et crée un socket de noyau au lieu d'une DNAT basée sur des paquets. Cela signifie qu'Anthos Service Mesh ne peut pas effectuer d'inspection des paquets, car le pod est contourné et n'utilise jamais d'IPTables.

    Cela se manifeste en mode sans frais kube-proxy en raison d'une perte de connectivité ou d'un routage de trafic incorrect pour les services avec Anthos Service Mesh, car le side-car ne peut pas effectuer d'inspection de paquets.

    Ce problème est présent dans toutes les versions de GKE sur Bare Metal 1.10, mais certaines versions plus récentes de la version 1.10 (1.10.2+) proposent une solution de contournement.


    Solution :

    Passez à la version 1.11 pour une compatibilité totale. Si vous utilisez la version 1.10.2 ou une version 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 ConfigMap, puis redémarrez le daemonset anetd:

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

    Espace de stockage 1.12+, 1.13.3

    kube-controller-manager peut dissocier les volumes persistants de force après six minutes.

    kube-controller-manager peut expirer lors de la dissociation des PV/PVC au bout de six minutes et entraîner la dissociation forcée des 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 du kubelet, des erreurs semblables aux suivantes 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é via SSH, puis redémarrez le nœud.
    Mises à niveau et mises à jour 1.12+, 1.13+, 1.14+

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

    Vous ne pourrez peut-être 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.
    Opération 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

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

    Le nœud maître administrateur créé via gkectl repair admin-master peut utiliser une version matérielle de VM inférieure à celle attendue. Lorsque le problème se produit, l'erreur apparaît 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 administrateur, suivez les instructions de la page 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.
    Système d'exploitation 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+, 1.16+

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

    Dans systemd v244, systemd-networkd présente un changement de comportement par défaut sur la configuration KeepConfiguration. Avant cette modification, les VM n'envoyaient pas de message de version DHCP au serveur DHCP lors de l'arrêt ou du redémarrage. Après cette modification, les VM envoient ce message et renvoient les adresses IP au serveur DHCP. Par conséquent, l'adresse IP libérée peut être réaffecté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 au niveau de vSphere) et/ou un changement d'adresse IP sur les VM, ce qui peut briser les clusters de différentes manières.

    Par exemple, vous pouvez constater les symptômes suivants.

    • L'interface utilisateur de vCenter montre qu'aucune VM n'utilise la même adresse IP, mais kubectl get nodes -o wide renvoie les 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
    • Les nouveaux nœuds ne démarrent pas 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 annuler 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 d'un arrêt ou d'un redémarrage. Les adresses IP sont 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

    Fonctionnement, mises à niveau et mises à jour 1.12.0-1.12.5, 1.13.0-1.13.5, 1.14.0-1.14.1

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

    Ce problème n'affectera que les clusters d'administrateur mis à niveau à partir de la version 1.11.x. Il n'affectera 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 est effacé et vide. Pour vérifier si c'est le cas, exécutez la commande suivante : 

    kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Si la sortie est vide, cela signifie que la clé est effacée.

    Une fois la clé de compte de service d'accès au composant supprimée, l'installation de nouveaux clusters d'utilisateur ou la mise à niveau des clusters d'utilisateur existants échouera. Voici une liste de messages d'erreur que vous pouvez rencontrer:

    • Échec lent de la validation préliminaire avec le message d'erreur: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Échec de la préparation par gkectl prepare avec le message d'erreur : "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 la 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 avec le message suivant: "failed to download bundle to disk: dialing: unexpected end of JSON input" (vous pouvez voir ce message dans le champ status dans le résultat de kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Solution:

    Ajoutez manuellement la clé du compte de service d'accès au composant 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 -
    Opération 1.13.0, 1.14.0 et ultérieures

    L'autoscaler de cluster ne fonctionne pas lorsque Controlplane V2 est activé

    Pour les clusters d'utilisateur créés avec Controlplane V2 ou un nouveau modèle d'installation, les pools de nœuds pour lesquels l'autoscaling est activé utilisent toujours leur instance autoscaling.minReplicas dans le fichier user-cluster.yaml. Le journal du pod de l'autoscaler de cluster indique également qu'il n'est pas opérationnel. 

      > 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
    Vous pouvez trouver le pod de l'autoscaler de cluster en exécutant les commandes suivantes. 
      > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Solution:

    Désactiver l'autoscaling dans tous les pools de nœuds avec "gkectl update cluster" jusqu'à la mise à niveau vers une version avec le correctif
    Installation 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    CIDR n'est pas autorisé dans le fichier de blocs d'adresses IP

    Lorsque les utilisateurs utilisent le routage CIDR dans le fichier de blocs d'adresses IP, la validation de la configuration échoue et l'erreur suivante s'affiche : 

    - 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 blocs d'adresses IP jusqu'à la mise à niveau vers une version avec le correctif suivant: 1.12.5, 1.13.4, 1.14.1+.
    Mises à niveau et mises à jour 1.14.0-1.14.1

    La mise à jour du type d'image de l'OS dans admin-cluster.yaml n'attend pas que les machines du plan de contrôle d'utilisateur soient recréées

    Lors de la mise à jour du 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éé via Controlplane V2, les machines du plan de contrôle d'utilisateur risquent de ne pas terminer leur recréation une fois la commande gkectl terminée.


    Solution:

    Une fois la mise à jour terminée, attendez également que les machines du plan de contrôle utilisateur terminent également leur recréation en surveillant les types d'images d'OS des nœuds à l'aide de kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. Par exemple, si vous passez d'Ubuntu à COS, nous devons attendre que toutes les machines du plan de contrôle passent complètement d'Ubuntu à COS, même après l'exécution de la commande de mise à jour.

    Opération 1.10, 1.11, 1.12, 1.13, 1.14.0

    Erreurs de création ou de suppression de pod en raison d'un problème de jeton d'authentification de compte de service CNI Calico

    Un problème lié à Calico dans Google Distributed Cloud 1.14.0 entraîne l'échec de la création et de la suppression du pod. Le message d'erreur suivant s'affiche dans le résultat de kubectl describe pods:

      error getting ClusterInformation: connection is unauthorized: Unauthorized

    Ce problème n'est observé que 24 heures après la création du cluster ou la mise à niveau vers la version 1.14 avec Calico.

    Les clusters d'administrateur utilisent toujours Calico. Pour les clusters d'utilisateur, il existe un champ de configuration "enableDataPlaneV2" dans user-cluster.yaml. Si ce champ est défini sur "false" ou n'est pas spécifié, cela signifie que vous utilisez Calico dans le cluster d'utilisateur.

    Le conteneur install-cni des nœuds crée un fichier kubeconfig avec un jeton valide pendant 24 heures. Ce jeton doit être régulièrement renouvelé par le pod calico-node. Le pod calico-node ne peut pas renouveler le jeton, car il n'a pas accès au répertoire contenant le fichier kubeconfig du nœud.


    Solution :

    Ce problème a été résolu dans la version 1.14.1 de Google Distributed Cloud. Effectuez une mise à niveau vers cette version ou une version ultérieure.

    Si vous ne pouvez pas effectuer la mise à niveau immédiatement, appliquez le correctif suivant au DaemonSet calico-node de votre cluster d'administrateur et d'utilisateur:

      kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Remplacez les éléments suivants :
    • ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
    • USER_CLUSTER_CONFIG_FILE: chemin d'accès au fichier de configuration de votre cluster d'utilisateur.
    Installation 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Échec de la validation des blocs d'adresses IP lors de l'utilisation d'une plage CIDR

    La création du cluster échoue bien que l'utilisateur dispose de la configuration appropriée. L'utilisateur constate l'échec de la création en raison du manque d'adresses IP du cluster.


    Solution:

    Diviser les CIDR en plusieurs blocs CIDR plus petits, tels que 10.0.0.0/30, devient 10.0.0.0/31, 10.0.0.2/31. Tant qu'il existe des CIDR N+1, où N est le nombre de nœuds du cluster, cela devrait suffire.

    Opération, mises à niveau et mises à jour 1.11.0 à 1.11.1, 1.10.0 à 1.10.4, 1.9.0 à 1.9.6

    La sauvegarde du cluster d'administrateur n'inclut pas la configuration et les clés de chiffrement des secrets toujours activées

    Lorsque la fonctionnalité de chiffrement des secrets toujours activé est activée avec la sauvegarde du cluster, la sauvegarde du cluster d'administrateur n'inclut pas les clés de chiffrement ni la configuration requises par la fonctionnalité de chiffrement des secrets en mode Always-on. Par conséquent, la réparation de l'instance maître administrateur avec cette sauvegarde à l'aide de gkectl repair admin-master --restore-from-backup entraîne l'erreur suivante : 

    Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Opération, mises à niveau et mises à jour 1.10+

    Recréer la VM maître administrateur avec un nouveau disque de démarrage (par exemple, gkectl repair admin-master) échoue si la fonctionnalité de chiffrement permanent des secrets est activée à l'aide de la commande "gkectl update".

    Si la fonctionnalité de chiffrement permanent des secrets n'est pas activée lors de la création du cluster, mais qu'elle l'est ultérieurement à l'aide de l'opération gkectl update, gkectl repair admin-master ne parvient pas à réparer le nœud du plan de contrôle du cluster d'administrateur. Il est recommandé d'activer la fonctionnalité de chiffrement permanent des secrets lorsque vous créez le cluster. Il n'existe actuellement aucune mesure d'atténuation.

    Mises à niveau et mises à jour 1.10

    La mise à niveau du premier cluster d'utilisateur de la version 1.9 à la version 1.10 recrée les nœuds dans d'autres clusters d'utilisateur

    La mise à niveau du premier cluster d'utilisateur de la version 1.9 vers la version 1.10 pourrait recréer des nœuds dans d'autres clusters d'utilisateur sous le même cluster d'administrateur. La recréation s'effectue par roulement.

    disk_label a été supprimé de MachineTemplate.spec.template.spec.providerSpec.machineVariables, ce qui a déclenché une mise à jour inattendue de toutes les MachineDeployment.


    Solution :
    Mises à niveau et mises à jour 1.10.0

    Docker redémarre fréquemment après la mise à niveau du cluster

    La mise à niveau du cluster d'utilisateur vers la version 1.10.0 peut entraîner un redémarrage fréquent de Docker.

    Vous pouvez détecter ce problème en exécutant kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Une condition de nœud indique si le docker redémarre fréquemment. Voici un exemple de résultat:

    Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Pour comprendre l'origine du problème, vous devez vous connecter en SSH au nœud qui présente le symptôme et exécuter des commandes telles que sudo journalctl --utc -u docker ou sudo journalctl -x.


    Solution :
    Mises à niveau et mises à jour 1,11, 1,12

    Composants GMP autodéployés non conservés après la mise à niveau vers la version 1.12

    Si vous utilisez une version de Google Distributed Cloud antérieure à la version 1.12 et que vous avez configuré manuellement des composants Prometheus géré par Google (GMP) dans l'espace de noms gmp-system pour votre cluster, ils ne sont pas conservés lorsque vous passez à la version 1.12.x.

    À partir de la version 1.12, les composants GMP dans l'espace de noms gmp-system et les CRD sont gérés par un objet stackdriver, avec l'option enableGMPForApplications définie sur false par défaut. Si vous déployez manuellement des composants GMP dans l'espace de noms avant la mise à niveau vers la version 1.12, les ressources seront supprimées par stackdriver.


    Solution :
    Opération 1.11, 1.12, 1.13.0 à 1.13.1

    Objets ClusterAPI manquants dans le scénario system de l'instantané de cluster

    Dans le scénario system, l'instantané du cluster n'inclut aucune ressource sous l'espace de noms default.

    Cependant, certaines ressources Kubernetes telles que les objets de l'API Cluster qui se trouvent sous cet espace de noms contiennent des informations de débogage utiles. L'instantané du cluster doit les inclure.


    Solution :

    Vous pouvez exécuter manuellement les commandes suivantes pour recueillir les informations de débogage.

    export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    où:

    USER_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'utilisateur.
    Mises à niveau et mises à jour 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Suppression du cluster d'utilisateur bloquée lors du drainage des nœuds pour la configuration vSAN

    Lors de la suppression, de la mise à jour ou de la mise à niveau d'un cluster d'utilisateur, le drainage des nœuds peut être bloqué dans les cas suivants:

    • Le cluster d'administrateur utilise le pilote CSI vSphere sur vSAN depuis la version 1.12.x.
    • Il n'existe pas d'objets PVC/PV créés par des plug-ins vSphere "in-tree" dans le cluster d'administrateur et d'utilisateur.

    Pour identifier le symptôme, exécutez la commande ci-dessous:

    kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Voici un exemple de message d'erreur de la commande ci-dessus:

    E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols est le répertoire par défaut pour le pilote "in-tree" vSphere. Si aucun objet PVC/PV n'est créé, il se peut que vous rencontriez un bug indiquant que le drainage des nœuds sera bloqué à la recherche de kubevols, car l'implémentation actuelle suppose que kubevols existe toujours.


    Solution :

    Créez le répertoire kubevols dans le datastore où le nœud est créé. Ce paramètre est défini dans le champ vCenter.datastore des fichiers user-cluster.yaml ou admin-cluster.yaml.
    Configuration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14

    Cluster Autoscaler clusterrolebinding et clusterrole sont supprimés après la suppression d'un cluster d'utilisateur.

    Lors de la suppression du cluster d'utilisateur, les valeurs clusterrole et clusterrolebinding correspondantes pour l'autoscaler de cluster sont également supprimées. Cela affecte tous les autres clusters d'utilisateur du même cluster d'administrateur sur lesquels l'autoscaler de cluster est activé. En effet, les mêmes clustersrole et clusterrolebinding sont utilisés pour tous les pods de l'autoscaler de cluster au sein du même cluster d'administrateur.

    Les symptômes sont les suivants:

    • Journaux cluster-autoscaler
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur. Voici un exemple de messages d'erreur susceptibles de s'afficher : 
      2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Solution :

    Configuration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    Le cluster d'administrateur cluster-health-controller et vsphere-metrics-exporter ne fonctionnent pas après la suppression du cluster d'utilisateur

    Lors de la suppression du cluster d'utilisateur, le clusterrole correspondant est également supprimé, ce qui empêche la réparation automatique et l'exportateur de métriques vSphere de ne pas fonctionner.

    Les symptômes sont les suivants:

    • Journaux cluster-health-controller
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur. Voici un exemple de messages d'erreur susceptibles de s'afficher : 
      error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • Journaux vsphere-metrics-exporter
      • kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      , où ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur. Voici un exemple de messages d'erreur susceptibles de s'afficher : 
      vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Solution :

    Configuration 1.12.1-1.12.3, 1.13.0-1.13.2

    Échec de gkectl check-config lors de la validation de l'image de l'OS

    Il s'agit d'un problème connu qui peut faire échouer le gkectl check-config sans exécuter gkectl prepare. Cette situation prête à confusion, car nous vous suggérons d'exécuter la commande avant d'exécuter gkectl prepare.

    Ce problème survient lorsque la commande gkectl check-config échoue avec le message d'erreur suivant:

    Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Solution :

    Option 1: exécutez gkectl prepare pour importer les images d'OS manquantes.

    Option 2: Utilisez gkectl check-config --skip-validation-os-images pour ignorer la validation des images d'OS.
    Mises à niveau et mises à jour 1,11, 1,12, 1,13

    Échec de la mise à jour des groupes d'anti-affinité par gkectl update admin/cluster

    Il s'agit d'un problème connu qui peut faire échouer gkectl update admin/cluster lors de la mise à jour de anti affinity groups.

    Ce problème survient lorsque la commande gkectl update échoue avec le message d'erreur suivant:

    Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Solution :
    Installation, mises à niveau et mises à jour 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    L'enregistrement des nœuds échoue si le nom d'hôte configuré contient un point

    L'enregistrement des nœuds échoue lors de la création, de la mise à niveau, de la mise à jour et de la réparation automatique du cluster, lorsque ipMode.type est défini sur static et que le nom d'hôte configuré dans le fichier de blocs d'adresses IP contient un ou plusieurs points. Dans ce cas, les demandes de signature de certificat (CSR) pour un nœud ne sont pas automatiquement approuvées.

    Pour afficher les demandes de signature de certificat en attente pour un nœud, exécutez la commande suivante:

    kubectl get csr -A -o wide

    Recherchez les messages d'erreur dans les journaux suivants:

    • Affichez les journaux du cluster d'administrateur pour le conteneur clusterapi-controller-manager dans le pod clusterapi-controllers :
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Pour afficher les mêmes journaux dans le cluster d'utilisateur, exécutez la commande suivante : 
      kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      où :
      • ADMIN_CLUSTER_KUBECONFIG est le fichier kubeconfig du cluster d'administrateur.
      • USER_CLUSTER_NAME est le nom du cluster d'utilisateur.
      Voici un exemple de messages d'erreur susceptibles de s'afficher: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Affichez les journaux kubelet sur le nœud problématique : 
      journalctl --u kubelet
      Voici un exemple de messages d'erreur que vous pouvez voir: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Si vous spécifiez un nom de domaine dans le champ "Nom d'hôte" d'un fichier de bloc d'adresses IP, tous les caractères suivant le premier point seront ignorés. Par exemple, si vous spécifiez le nom d'hôte en tant que bob-vm-1.bank.plc, le nom d'hôte et le nom du nœud de la VM seront définis sur bob-vm-1.

    Lorsque la validation de l'ID de nœud est activée, l'approbateur CSR compare le nom du nœud avec le nom d'hôte indiqué dans les spécifications de la machine et ne parvient pas à rapprocher le nom. L'approbateur rejette la requête de signature de certificat, et le nœud ne parvient pas à démarrer.


    Solution :

    Cluster d'utilisateur

    Désactivez la validation de l'ID de nœud en procédant comme suit:

    1. Ajoutez les champs suivants dans le fichier de configuration de votre cluster d'utilisateur : 
      disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Enregistrez le fichier et mettez à jour le cluster d'utilisateur en exécutant la commande suivante : 
      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Remplacez ce qui suit :
      • ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
      • USER_CLUSTER_CONFIG_FILE: chemin d'accès au fichier de configuration de votre cluster d'utilisateur.

    Cluster d'administrateur

    1. Ouvrez la ressource personnalisée OnPremAdminCluster pour la modifier :
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Ajoutez l'annotation suivante à la ressource personnalisée : 
      features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Modifiez le fichier manifeste kube-controller-manager dans le plan de contrôle du cluster d'administrateur :
      1. Connectez-vous en SSH au nœud du plan de contrôle du cluster d'administrateur.
      2. Ouvrez le fichier manifeste kube-controller-manager pour le modifier : 
        sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Recherchez la liste de controllers : 
        --controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Mettez à jour cette section comme indiqué ci-dessous : 
        --controllers=*,bootstrapsigner,tokencleaner
    4. Ouvrez le contrôleur de l'API de cluster de déploiement pour modifier : 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Remplacez les valeurs de node-id-verification-enabled et node-id-verification-csr-signing-enabled par false : 
      --node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installation, mises à niveau et mises à jour 1.11.0-1.11.4

    Échec du démarrage de la machine du plan de contrôle administrateur causé par le groupe de certificats du registre privé

    La création/mise à niveau du cluster d'administrateur est bloquée indéfiniment dans le journal suivant et expire à terme:

    Waiting for Machine gke-admin-master-xxxx to become ready...

    Le journal du contrôleur de l'API Cluster dans l' instantané du cluster externe inclut le journal suivant:

    Invalid value 'XXXX' specified for property startup-data

    Voici un exemple de chemin d'accès pour le journal du contrôleur de l'API Cluster:

    kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes marked unhealthy from concurrent status update conflict

    In networkgatewaygroups.status.nodes, some nodes switch between NotHealthy and Up.

    Logs for the ang-daemon Pod running on that node reveal repeated errors: 

    2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    L'état NotHealthy empêche la manette d'attribuer des adresses IP flottantes supplémentaires au nœud. Cela peut entraîner une charge plus importante sur les autres nœuds ou un manque de redondance pour une haute disponibilité.

    Sinon, l'activité Dataplane n'est pas affectée.

    Des conflits sur l'objet networkgatewaygroup entraînent l'échec de certaines mises à jour de l'état en raison d'une erreur dans le traitement des nouvelles tentatives. Si un trop grand nombre de mises à jour d'état échoue, ang-controller-manager considère que le nœud a dépassé sa limite de temps de pulsation et le marque comme NotHealthy.

    L'erreur liée au traitement des nouvelles tentatives a été corrigée dans les versions ultérieures.


    Solution :

    Effectuez la mise à niveau vers une version corrigée, le cas échéant.
    Mises à niveau et mises à jour 1.12.0-1.12.2, 1.13.0

    Une condition de concurrence bloque la suppression d'objets machine pendant et la mise à jour ou la mise à niveau

    Il s'agit d'un problème connu qui peut bloquer la mise à niveau du cluster en attendant la suppression de l'ancien objet machine. En effet, le finaliseur ne peut pas être supprimé de l'objet machine. Cela affecte les opérations de mise à jour progressive des pools de nœuds.

    Ce problème survient lorsque la commande gkectl expire avec le message d'erreur suivant:

    E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Dans les journaux de pods clusterapi-controller, les erreurs se présentent comme suit:

    $ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    L'erreur se répète sur la même machine pendant plusieurs minutes pour les exécutions réussies, même sans ce problème. La plupart du temps, elle peut s'exécuter rapidement. Toutefois, dans de rares cas, elle peut être bloquée dans cette condition de concurrence pendant plusieurs heures.

    Le problème est que la VM sous-jacente est déjà supprimée dans vCenter, mais que l'objet machine correspondant ne peut pas être supprimé, car il est bloqué au moment de la suppression du finaliseur en raison de mises à jour très fréquentes d'autres contrôleurs. Cela peut entraîner l'expiration de la commande gkectl, mais le contrôleur continue de rapprocher le cluster pour que le processus de mise à niveau ou de mise à jour finisse par se terminer.


    Solution :

    Nous avons préparé plusieurs options d'atténuation de ce problème, qui dépendent de votre environnement et de vos exigences.

    • Option 1: Attendez que la mise à niveau soit terminée d'elle-même.

      En fonction de l'analyse et de la reproduction dans votre environnement, la mise à niveau peut finir par se terminer d'elle-même sans aucune intervention manuelle. L'inconvénient de cette option est qu'il est impossible de savoir combien de temps il faudra pour que la suppression du finaliseur soit effective pour chaque objet machine. Elle peut être appliquée immédiatement si le temps le permet, ou plusieurs heures si le rapprochement du contrôleur de jeu de machines est trop rapide et que le contrôleur de machine n'a jamais la possibilité de supprimer le finaliseur entre les rapprochements.

      L'avantage est que cette option ne nécessite aucune action de votre part et que les charges de travail ne seront pas interrompues. La mise à niveau a simplement besoin de plus de temps.
    • Option 2: Appliquer une annotation de réparation automatique à tous les anciens objets machine

      Le contrôleur de machineset filtre les machines dont l'annotation de réparation automatique et le code temporel de suppression sont différents de zéro, et ne continue plus à émettre des appels de suppression sur ces machines, ce qui permet d'éviter la condition de concurrence.

      L'inconvénient est que les pods des machines sont supprimés directement au lieu d'être évincés, ce qui signifie qu'ils ne respectent pas la configuration du PDB. Cela peut entraîner des temps d'arrêt pour vos charges de travail.

      Commande permettant d'obtenir tous les noms de machines : 
      kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Commande permettant d'appliquer une annotation de réparation automatique pour chaque machine : 
      kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Si vous rencontrez ce problème et que la mise à niveau ou la mise à jour ne peuvent toujours pas se terminer après un long moment, contactez notre équipe d'assistance pour obtenir des solutions.
    Installation, mises à niveau et mises à jour 1.10.2, 1.11, 1.12, 1.13

    gkectl : échec de la préparation de la validation de l'image de l'OS avant la vérification

    Échec de la commande gkectl prepare:

    - Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    Les vérifications préliminaires de gkectl prepare incluaient une validation incorrecte.


    Solution :

    Exécutez la même commande avec l'option supplémentaire --skip-validation-os-images.
    Installation 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    L'URL vCenter avec le préfixe https:// ou http:// peut entraîner un échec du démarrage du cluster

    Échec de la création du cluster d'administrateur avec:

    Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    L'URL est utilisée dans une clé secrète qui ne prend pas en charge "/" ni ":".


    Solution :

    Supprimez le préfixe https:// ou http:// du champ vCenter.Address dans le fichier YAML de configuration du cluster d'administrateur ou du cluster d'utilisateur.
    Installation, mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    gkectl prepare panique sur util.CheckFileExists

    gkectl prepare peut paniquer avec la trace de pile suivante:

    panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Le problème vient du fait que gkectl prepare a créé le répertoire de certificat de registre privé avec une autorisation incorrecte.


    Solution :

    Pour résoudre ce problème, veuillez exécuter les commandes suivantes sur le poste de travail administrateur:

    sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    gkectl repair admin-master et la mise à niveau administrateur avec reprise ne fonctionnent pas ensemble

    Après l'échec de la tentative de mise à niveau du cluster d'administrateur, n'exécutez pas gkectl repair admin-master. Cela peut entraîner l'échec des tentatives ultérieures de mise à niveau administrateur et des problèmes tels que la mise sous tension de l'administrateur maître en cas de défaillance ou l'accès à la VM.


    Solution :

    Si vous avez déjà rencontré ce scénario de défaillance, contactez l'assistance.
    Mises à niveau et mises à jour 1,10, 1,11

    La reprise de la mise à niveau du cluster d'administrateur peut entraîner l'absence d'un modèle de VM pour le plan de contrôle d'administrateur

    Si la machine du plan de contrôle administrateur n'est pas recréée après la reprise de la tentative de mise à niveau du cluster d'administrateur, le modèle de VM du plan de contrôle administrateur est supprimé. Le modèle de VM du plan de contrôle administrateur est le modèle du maître administrateur utilisé pour récupérer la machine du plan de contrôle avec gkectl repair admin-master.


    Solution :

    Le modèle de VM du plan de contrôle d'administrateur sera régénéré lors de la prochaine mise à niveau du cluster d'administrateur.
    Système d'exploitation 1,12, 1,13

    cgroup v2 pourrait affecter les charges de travail

    Dans la version 1.12.0, cgroup v2 (unifié) est activé par défaut pour les nœuds Container Optimized OS (COS). Cela pourrait potentiellement provoquer une instabilité de vos charges de travail dans un cluster COS.


    Solution :

    Nous sommes revenus à cgroup v1 (hybride) dans la version 1.12.1. Si vous utilisez des nœuds COS, nous vous recommandons de passer à la version 1.12.1 dès qu'elle est disponible.
    Identité 1,10, 1,11, 1,12, 1,13

    Ressource personnalisée ClientConfig

    gkectl update annule toutes les modifications manuelles que vous avez apportées à la ressource personnalisée ClientConfig.


    Solution :

    Nous vous recommandons vivement de sauvegarder la ressource ClientConfig après chaque modification manuelle.
    Installation 1,10, 1,11, 1,12, 1,13

    Échec de la validation de gkectl check-config: impossible de trouver les partitions F5 BIG-IP

    La validation échoue, car les partitions F5 BIG-IP sont introuvables, même si elles existent.

    Un problème avec l'API F5 BIG-IP peut entraîner l'échec de la validation.


    Solution :

    Essayez d'exécuter gkectl check-config à nouveau.
    Installation 1.12

    L'installation du cluster d'utilisateur a échoué en raison d'un problème lié à l'élection du responsable de cert-manager/ca-injector

    Vous pouvez constater un échec de l'installation dû à cert-manager-cainjector dans la boucle de plantage, lorsque le serveur d'API/etcd est lent:

    # These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system
  cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition

E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core:
  Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded

I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition

E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

    Solution :
    VMware 1,10, 1,11, 1,12, 1,13

    Redémarrer ou mettre à niveau vCenter pour les versions antérieures à la version 7.0U2

    Si vCenter, pour les versions antérieures à 7.0U2, redémarre après une mise à niveau ou autre, le nom du réseau indiqué dans les informations de VM de vCenter est incorrect et l'état de la machine est Unavailable. Cela entraîne à terme la réparation automatique des nœuds pour en créer d'autres.

    Bug govmomi associé.


    Solution :

    Cette solution est fournie par l'assistance VMware :

    1. Ce problème est résolu dans les versions 7.0U2 et ultérieures de vCenter.
    2. Pour les versions antérieures, effectuez un clic droit sur l'hôte, puis sélectionnez Connexion > Déconnecter. Ensuite, reconnectez-vous, ce qui force la mise à jour du groupe de ports de la VM.
    Système d'exploitation 1,10, 1,11, 1,12, 1,13

    Connexion SSH fermée par l'hôte distant

    Pour les versions 1.7.2 et ultérieures de Google Distributed Cloud, les images de l'OS Ubuntu sont renforcées à l'aide du benchmark de serveur CIS L1.

    Pour respecter la règle CIS "5.2.16 Assurez-vous que l'intervalle du délai d'inactivité SSH est configuré", /etc/ssh/sshd_config dispose des paramètres suivants:

    ClientAliveInterval 300
ClientAliveCountMax 0

    Ces paramètres visent à mettre fin à une session client après cinq minutes d'inactivité. Cependant, la valeur ClientAliveCountMax 0 entraîne un comportement inattendu. Lorsque vous utilisez la session SSH sur le poste de travail administrateur ou un nœud de cluster, la connexion SSH peut être déconnectée même si votre client SSH n'est pas inactif, par exemple lors de l'exécution d'une commande chronophage. Votre commande peut être interrompue avec le message suivant:

    Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Solution :

    Vous disposez des options suivantes :

    • Utilisez nohup pour empêcher l'arrêt de votre commande lors de la déconnexion SSH,
      nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
      .
    • Mettez à jour sshd_config pour utiliser une valeur ClientAliveCountMax non nulle. La règle CIS recommande d'utiliser une valeur inférieure à 3 :
      sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Veillez à reconnecter votre session SSH.
    Installation 1,10, 1,11, 1,12, 1,13

    Installation de cert-manager en conflit

    Dans les versions 1.13, monitoring-operator installe cert-manager dans l'espace de noms cert-manager. Si, pour certaines raisons, vous devez installer votre propre gestionnaire de certificats, suivez les instructions suivantes pour éviter les conflits:

    Vous n'avez besoin d'appliquer cette solution de contournement qu'une seule fois pour chaque cluster, et les modifications seront conservées lors de la mise à niveau du cluster.

    Remarque: L'installation de votre propre cert-manager entraîne souvent le rétablissement de l'ancienne version de l'image ou de la version de cert-manager (par exemple, v1.7.2). Cela est dû au fait que monitoring-operator tente de rapprocher cert-manager et d'annuler la version lors du processus.

    Solution :

    <pÉvitez les conflits lors de la mise à niveau

    1. Désinstallez votre version de cert-manager. Si vous avez défini vos propres ressources, vous pouvez les sauvegarder .
    2. Procédez à la mise à niveau.
    3. Suivez les instructions suivantes pour restaurer votre propre cert-manager.

    Restaurer votre propre cert-manager dans les clusters d'utilisateur

    • Mise à l'échelle du déploiement monitoring-operator à 0 : 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Faites passer à 0 les déploiements cert-manager gérés par monitoring-operator :
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Réinstallez votre version de cert-manager. Restaurez vos ressources personnalisées, le cas échéant.
    • Vous pouvez ignorer cette étape si vous utilisez l' installation cert-manager par défaut en amont ou si vous êtes certain que cert-manager est installé dans l'espace de noms cert-manager. Sinon, copiez le certificat cert-manager.io/v1 metrics-ca et les ressources de l'émetteur metrics-pki.cluster.local de cert-manager dans l'espace de noms des ressources de cluster du gestionnaire de certificats installé.
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Restaurer votre propre cert-manager dans les clusters d'administrateur

    En général, vous n'avez pas besoin de réinstaller cert-manager dans les clusters d'administrateur, car les clusters d'administrateur n'exécutent que les charges de travail du plan de contrôle Google Distributed Cloud. Dans les rares cas où vous devez également installer votre propre gestionnaire de certificats dans des clusters d'administrateur, veuillez suivre les instructions suivantes pour éviter les conflits. Veuillez noter que si vous êtes un client Apigee et que vous n'avez besoin que de cert-manager pour Apigee, vous n'avez pas besoin d'exécuter les commandes du cluster d'administrateur.

    • Faites passer le déploiement monitoring-operator à 0. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Faites passer à 0 les déploiements cert-manager gérés par monitoring-operator. 
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Réinstallez votre version de cert-manager. Restaurez vos ressources personnalisées, le cas échéant.
    • Vous pouvez ignorer cette étape si vous utilisez l' installation cert-manager par défaut en amont ou si vous êtes certain que cert-manager est installé dans l'espace de noms cert-manager. Sinon, copiez le certificat cert-manager.io/v1 metrics-ca et les ressources de l'émetteur metrics-pki.cluster.local de cert-manager dans l'espace de noms des ressources de cluster du gestionnaire de certificats installé.
      relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    </p
    Système d'exploitation 1,10, 1,11, 1,12, 1,13

    Faux positifs lors de l'analyse des failles docker, containerd et runc

    Les images Docker, containerd et runc des images de l'OS Ubuntu fournies avec Google Distributed Cloud sont épinglées à des versions spéciales à l'aide de Ubuntu PPA. Ainsi, toutes les modifications apportées à l'environnement d'exécution des conteneurs seront qualifiées par Google Distributed Cloud avant chaque version.

    Cependant, les versions spéciales sont inconnues de l'outil de suivi CVE Ubuntu, qui est utilisé comme flux des failles par divers outils d'analyse CVE. Par conséquent, vous constaterez des faux positifs dans les résultats de l'analyse des failles Docker, containerd et runc.

    Par exemple, les faux positifs suivants peuvent apparaître dans les résultats de l'analyse CVE. Ces failles CVE sont déjà corrigées dans les dernières versions correctives de Google Distributed Cloud.

    Reportez-vous aux notes de version pour obtenir des corrections CVE.


    Solution :

    Canonical est au courant de ce problème, et son correctif est disponible à l'adresse https://github.com/canonical/sec-cvescan/issues/73.
    Mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    La connexion réseau entre le cluster d'administrateur et d'utilisateur peut être indisponible pendant une courte période lors de la mise à niveau d'un cluster standard

    Si vous mettez à niveau des clusters standards de la version 1.9 vers la version 1.10, vous remarquerez peut-être que kubectl exec, kubectl log et le webhook peuvent être indisponibles pendant une courte période sur les clusters d'utilisateur. Ce temps d'arrêt peut durer jusqu'à une minute. En effet, la requête entrante (kubectl exec, kubectl log et webhook) est gérée par kube-apiserver pour le cluster d'utilisateur. L'utilisateur kube-apiserver est un ensemble avec état. Dans un cluster standard, il n'y a qu'une seule instance dupliquée pour l'ensemble avec état. Ainsi, lors de la mise à niveau, il est possible que l'ancien kube-apiserver soit indisponible alors que le nouveau kube-apiserver ne soit pas encore prêt.


    Solution :

    Ce temps d'arrêt ne se produit que pendant le processus de mise à niveau. Si vous souhaitez un temps d'arrêt plus court pendant la mise à niveau, nous vous recommandons de passer aux clusters haute disponibilité.
    Installation, mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    Échec de la vérification de la préparation de la konnectivity dans le diagnostic de cluster haute disponibilité après la création ou la mise à niveau du cluster

    Si vous créez ou mettez à niveau un cluster à haute disponibilité et remarquez l'échec de la vérification de la préparation de la connectivité lors du diagnostic du cluster, cela n'affectera pas la plupart des fonctionnalités de Google Distributed Cloud (kubectl exec, kubectl log et webhook). Cela est dû au fait qu'une ou deux des instances répliquées de conjonction peuvent parfois ne pas être prêtes pendant un certain temps en raison d'une mise en réseau instable ou d'autres problèmes.


    Solution :

    L'instance konnectivity se rétablira seule. Attendez de 30 minutes à une heure, puis relancez le diagnostic du cluster.
    Système d'exploitation 1,7, 1,8, 1,9, 1,10, 1,11

    /etc/cron.daily/aide Problème de pic de mémoire et de processeur

    À partir de la version 1.7.2 de Google Distributed Cloud, les images de l'OS Ubuntu sont renforcées grâce au benchmark serveur CIS L1.

    Par conséquent, le script Cron /etc/cron.daily/aide a été installé afin de planifier une vérification aide afin de garantir que la règle du serveur CIS L1 "1.4.2 Assurez-vous que l'intégrité du système de fichiers est régulièrement vérifiée" est suivie.

    La job Cron'exécute tous les jours à 6h25 UTC. En fonction du nombre de fichiers dans le système de fichiers, vous pouvez rencontrer des pics d'utilisation du processeur et de la mémoire à ce moment-là, dus à ce processus aide.


    Solution :

    Si les pics affectent votre charge de travail, vous pouvez désactiver les job Cron quotidiennes:

    sudo chmod -x /etc/cron.daily/aide
    Mise en réseau 1,10, 1,11, 1,12, 1,13

    Les équilibreurs de charge et les règles de pare-feu distribué avec état NSX-T interagissent de manière imprévisible

    Lors du déploiement de Google Distributed Cloud version 1.9 ou ultérieure, si le déploiement inclut l'équilibreur de charge groupé Seesaw dans un environnement utilisant des règles de pare-feu distribués avec état NSX-T, stackdriver-operator peut ne pas créer le fichier ConfigMap gke-metrics-agent-conf et entraîner l'arrivée de gke-connect-agent pods dans une boucle de plantage.

    Le problème sous-jacent est que les règles de pare-feu distribué avec état NSX-T interrompent la connexion d'un client au serveur d'API du cluster d'utilisateur via l'équilibreur de charge Seesaw, car Seesaw utilise des flux de connexion asymétriques. Les problèmes d'intégration avec les règles de pare-feu distribué NSX-T affectent toutes les versions de Google Distributed Cloud qui utilisent Seesaw. Vous pouvez rencontrer des problèmes de connexion similaires sur vos propres applications lorsqu'elles créent des objets Kubernetes volumineux dont la taille est supérieure à 32 Ko.


    Solution :

    Suivez ces instructions pour désactiver les règles de pare-feu distribuées NSX-T ou pour utiliser des règles de pare-feu distribuées sans état pour les VM Seesaw.

    Si vos clusters utilisent un équilibreur de charge manuel, suivez ces instructions pour configurer votre équilibreur de charge afin qu'il réinitialise les connexions client lorsqu'il détecte une défaillance du nœud backend. Sans cette configuration, les clients du serveur d'API Kubernetes peuvent cesser de répondre pendant plusieurs minutes en cas de panne d'une instance de serveur.
    Journalisation et surveillance 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Facturation de la surveillance inattendue

    Pour les versions 1.10 à 1.15 de Google Distributed Cloud, certains clients ont constaté une facturation élevée de manière inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que lorsque toutes les circonstances suivantes sont réunies:

    • La journalisation et la surveillance des applications sont activées (enableStackdriverForApplications=true)
    • Les pods d'application comportent l'annotation prometheus.io/scrap=true. (L'installation d'Anthos Service Mesh peut également ajouter cette annotation.)

    Pour vérifier si vous êtes concerné par ce problème, répertoriez vos métriques définies par l'utilisateur. Si vous constatez que des métriques indésirables sont facturées avec le préfixe de nom external.googleapis.com/prometheus et que enableStackdriverForApplications est également défini sur "true" dans la réponse de kubectl -n kube-system get stackdriver stackdriver -o yaml, ce problème vous concerne.


    Solution

    Si vous êtes concerné par ce problème, nous vous recommandons de mettre à niveau vos clusters vers la version 1.12 ou une version ultérieure, de cesser d'utiliser l'indicateur enableStackdriverForApplications et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus qui ne repose plus sur l'annotation prometheus.io/scrap=true. Avec la nouvelle solution, vous pouvez également contrôler la collecte des journaux et des métriques séparément pour vos applications, à l'aide des options enableCloudLoggingForApplications et enableGMPForApplications, respectivement.

    Pour cesser d'utiliser l'indicateur enableStackdriverForApplications, ouvrez l'objet "stackdriver" pour le modifier:

    kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

    Supprimez la ligne enableStackdriverForApplications: true, enregistrez et fermez l'éditeur.

    Si vous ne pouvez pas quitter la collecte de métriques basées sur les annotations, procédez comme suit:

    1. Recherchez les pods et services sources contenant les métriques facturées indésirables. 
      kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Supprimez l'annotation prometheus.io/scrap=true du pod ou du service. Si l'annotation est ajoutée par Anthos Service Mesh, vous pouvez configurer Anthos Service Mesh sans l'option Prometheus ou désactiver la fonctionnalité de fusion des métriques Istio.
    Installation 1,11, 1,12, 1,13

    Échec du programme d'installation lors de la création du disque de données vSphere

    Le programme d'installation Google Distributed Cloud peut échouer si les rôles personnalisés sont liés au mauvais niveau d'autorisation.

    Lorsque la liaison de rôle est incorrecte, la création d'un disque de données vSphere avec govc se bloque et le disque est créé avec une taille égale à 0. Pour résoudre le problème, vous devez lier le rôle personnalisé au niveau de vSphere vCenter (racine).


    Solution :

    Si vous souhaitez lier le rôle personnalisé au niveau du contrôleur de domaine (ou à un niveau inférieur à la racine), vous devez également lier le rôle en lecture seule à l'utilisateur au niveau racine vCenter.

    Pour en savoir plus sur la création de rôles, consultez la section Droits de compte d'utilisateur vCenter.
    Journalisation et surveillance 1.9.0-1.9.4, 1.10.0-1.10.1

    Trafic réseau élevé vers monitoring.googleapis.com

    Vous pouvez constater un trafic réseau élevé vers monitoring.googleapis.com, même dans un nouveau cluster qui ne comporte aucune charge de travail utilisateur.

    Ce problème affecte la version 1.10.0-1.10.1 et la version 1.9.0-1.9.4. Ce problème est résolu dans les versions 1.10.2 et 1.9.5.


    Solution :
    Journalisation et surveillance 1,10, 1,11

    gke-metrics-agent présente des erreurs CrashLoopBackOff récurrentes

    Pour Google Distributed Cloud version 1.10 et ultérieure, le DaemonSet "gke-metrics-agent" présente des erreurs CrashLoopBackOff fréquentes lorsque "enableStackdriverForApplications" est défini sur "true" dans l'objet "stackdriver"


    Solution :

    Pour atténuer ce problème, désactivez la collecte de métriques d'application en exécutant les commandes suivantes. Ces commandes ne désactivent pas la collecte des journaux d'application.

    1. Pour éviter l'annulation des modifications suivantes, effectuez un scaling à la baisse de stackdriver-operator : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
    2. Ouvrez le ConfigMap gke-metrics-agent-conf pour le modifier : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Sous services.pipelines, mettez en commentaire toute la section metrics/app-metrics : 
      services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Fermez la session de modification.
    5. Redémarrez le DaemonSet gke-metrics-agent : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Journalisation et surveillance 1,11, 1,12, 1,13

    Remplacer les métriques obsolètes dans le tableau de bord

    Si des métriques obsolètes sont utilisées dans vos tableaux de bord de type "OOTB", vous verrez des graphiques vides. Pour rechercher les métriques obsolètes dans les tableaux de bord Monitoring, exécutez les commandes suivantes:

    gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Les métriques obsolètes suivantes doivent être migrées vers leurs valeurs de remplacement.

    ObsolèteRemplacement
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Solution :

    Pour remplacer les métriques obsolètes

    1. Supprimez "État du nœud GKE On-Prem" dans le tableau de bord Google Cloud Monitoring. Réinstallez "État du nœud GKE On-Prem" en suivant ces instructions.
    2. Supprimez "Utilisation des nœuds GKE On-Prem" dans le tableau de bord Google Cloud Monitoring. Réinstallez la section "Utilisation des nœuds GKE On-Prem" en suivant ces instructions.
    3. Supprimez "État de la VM vSphere GKE On-Prem" dans le tableau de bord Google Cloud Monitoring. Réinstallez "État de la VM vSphere GKE On-Prem" en suivant ces instructions.

      4. Cet abandon est dû à la mise à niveau de l'agent kube-state-metrics de la version 1.9 à la version 2.4, qui est requise pour Kubernetes 1.22. Vous pouvez remplacer toutes les métriques kube-state-metrics obsolètes, qui portent le préfixe kube_, dans vos tableaux de bord personnalisés ou vos règles d'alerte.
    Journalisation et surveillance 1,10, 1,11, 1,12, 1,13

    Données de métriques inconnues dans Cloud Monitoring

    Pour Google Distributed Cloud version 1.10 et ultérieure, les données des clusters dans Cloud Monitoring peuvent contenir des entrées de métriques récapitulatives non pertinentes, telles que les suivantes:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    D'autres types de métriques peuvent être associés à des métriques récapitulatives non pertinentes :

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Bien que ces métriques de type récapitulatif figurent dans la liste des métriques, elles ne sont pas compatibles avec gke-metrics-agent pour le moment.
    Journalisation et surveillance 1,10, 1,11, 1,12, 1,13

    Métriques manquantes sur certains nœuds

    Vous constaterez peut-être que les métriques suivantes sont manquantes sur certains nœuds, mais pas sur tous:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Solution :

    Pour résoudre ce problème, procédez comme suit : Pour [version 1.9.5+, 1.10.2+, 1.11.0]: augmentez le processeur pour gke-metrics-agent en suivant les étapes 1 à 4.

    1. Ouvrez votre ressource stackdriver pour la modifier : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Pour faire passer la demande de processeur pour gke-metrics-agent de 10m à 50m, limitez la limite de processeur de 100m à 200m, ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver : 
      spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      Votre ressource modifiée doit ressembler à ce qui suit : 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Enregistrez les modifications et fermez l'éditeur de texte.
    4. Pour vérifier que vos modifications ont bien été prises en compte, exécutez la commande suivante : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      La commande recherche cpu: 50m si vos modifications ont été appliquées.
    Journalisation et surveillance 1.11.0-1.11.2, 1.12.0

    Métriques des programmeurs et des gestionnaires de contrôleur manquantes dans le cluster d'administrateur

    Si votre cluster d'administrateur est affecté par ce problème, les métriques du programmeur et du gestionnaire du contrôleur sont manquantes. Par exemple, il manque ces deux métriques

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solution :

    Effectuez la mise à niveau vers la version 1.11.3 ou ultérieure, la version 1.12.1 ou ultérieure, ou la version 1.13 ou ultérieure.
    1.11.0-1.11.2, 1.12.0

    Métriques des programmeurs et des gestionnaires de contrôleur manquantes dans le cluster d'utilisateur

    Si votre cluster d'utilisateur est affecté par ce problème, les métriques du programmeur et du gestionnaire du contrôleur sont manquantes. Par exemple, ces deux métriques sont manquantes:

    # scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Solution :

    Ce problème est résolu dans Google Distributed Cloud 1.13.0 et versions ultérieures. Mettez à niveau votre cluster vers une version avec le correctif.
    Installation, mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    Échec de l'enregistrement du cluster d'administrateur lors de la création

    Si vous créez un cluster d'administrateur pour la version 1.9.x ou 1.10.0 et que le cluster d'administrateur ne s'enregistre pas avec la spécification gkeConnect fournie lors de sa création, l'erreur suivante est renvoyée.

    Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Vous pourrez toujours utiliser ce cluster d'administrateur, mais vous obtiendrez l'erreur suivante si vous tentez ultérieurement de le mettre à niveau vers la version 1.10.y.

    failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Solution :
    Identité 1,10, 1,11, 1,12, 1,13

    L'utilisation de GKE Identity Service peut entraîner le redémarrage imprévisible de l'agent Connect

    Si vous utilisez la fonctionnalité GKE Identity Service pour gérer GKE Identity Service ClientConfig, l' agent Connect peut redémarrer de manière inattendue.


    Solution :

    Si vous rencontrez ce problème avec un cluster existant, vous pouvez effectuer l'une des opérations suivantes:

    • Désactiver GKE Identity Service La désactivation de GKE Identity Service ne supprime ni le binaire GKE Identity Service déployé, ni la ClientConfig de GKE Identity Service. Pour désactiver GKE Identity Service, exécutez la commande suivante : 
      gcloud container fleet identity-service disable \
    --project PROJECT_ID
      Remplacez PROJECT_ID par l'ID du projet hôte de parc du cluster.
    • Mettez à jour le cluster vers la version 1.9.3 ou ultérieure, ou vers la version 1.10.1 ou ultérieure, afin de mettre à niveau la version de l'agent Connect.
    Mise en réseau 1,10, 1,11, 1,12, 1,13

    Cisco ACI ne fonctionne pas avec Direct Server Return (DSR)

    Seesaw s'exécute en mode DSR. Par défaut, il ne fonctionne pas dans Cisco ACI en raison de l'apprentissage des adresses IP du plan de données.


    Solution :

    Une solution de contournement possible consiste à désactiver l'apprentissage IP en ajoutant l'adresse IP Seesaw en tant qu'adresse IP virtuelle L4-L7 dans le contrôleur d'infrastructure APIC (Application Policy Application Controller) de Cisco.

    Vous pouvez configurer l'option d'adresse IP virtuelle L4-L7 en accédant à Locataire > Profils d'application > EPG d'application ou uSeg EPG. Si vous ne désactivez pas l'apprentissage des adresses IP, le point de terminaison de l'adresse IP va basculer entre différents emplacements dans la structure d'API Cisco.
    VMware 1,10, 1,11, 1,12, 1,13

    Problèmes liés à la mise à niveau 3 de vSphere 7.0

    VMWare a récemment identifié des problèmes critiques dans les versions suivantes de vSphere 7.0 Update 3:

    • vSphere ESXi 7.0 Update 3 (build 18644231)
    • vSphere ESXi 7.0 Update 3a (build 18825058)
    • vSphere ESXi 7.0 Update 3b (build 18905247)
    • vSphere vCenter 7.0, mise à niveau 3b (version 18901211)

    Solution :

    VMWare a depuis supprimé ces versions. Vous devez mettre à niveau les serveurs ESXi et vCenter vers une version plus récente.
    Système d'exploitation 1,10, 1,11, 1,12, 1,13

    Échec de l'installation du volume emptyDir en tant que exec dans le pod s'exécutant sur des nœuds COS

    Pour les pods s'exécutant sur des nœuds qui utilisent des images COS (Container-Optimized OS), vous ne pouvez pas installer de volume emptyDir en tant que exec. Il s'installe en tant que noexec et vous obtenez l'erreur suivante: exec user process caused: permission denied. Par exemple, ce message d'erreur s'affiche si vous déployez le pod de test suivant:

    apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Si vous exécutez mount | grep test-volume dans le pod de test, l'option "noexec" s'affiche:

    /dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Solution :
    Mises à niveau et mises à jour 1,10, 1,11, 1,12, 1,13

    La mise à jour de l'instance répliquée du pool de nœuds du cluster ne fonctionne pas une fois l'autoscaling désactivé sur le pool de nœuds

    Les instances dupliquées de pools de nœuds ne sont pas mises à jour une fois l'autoscaling activé et désactivé sur un pool de nœuds.


    Solution :

    Suppression des annotations cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size et cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size du déploiement de machines du pool de nœuds correspondant.
    Journalisation et surveillance 1,11, 1,12, 1,13

    Les tableaux de bord de surveillance Windows affichent les données des clusters Linux

    À partir de la version 1.11, les tableaux de bord de surveillance prêts à l'emploi, le tableau de bord d'état du pod Windows et le tableau de bord d'état des nœuds Windows affichent également les données des clusters Linux. En effet, les métriques de nœud et de pod Windows sont également exposées sur les clusters Linux.
    Journalisation et surveillance 1.10, 1.11, 1.12

    stackdriver-log-forwarder dans CrashLoopBackOff constante

    Pour les versions 1.10, 1.11 et 1.12 de Google Distributed Cloud, le DaemonSet stackdriver-log-forwarder peut présenter des erreurs CrashLoopBackOff en cas de journaux mis en mémoire tampon interrompus sur le disque.


    Solution :

    Pour atténuer ce problème, nous devons nettoyer les journaux mis en mémoire tampon sur le nœud.

    1. Pour éviter ce comportement inattendu, effectuez un scaling à la baisse de stackdriver-log-forwarder : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
    2. Déployez le DaemonSet de nettoyage pour nettoyer les fragments endommagés : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Pour vous assurer que le DaemonSet de nettoyage a nettoyé tous les fragments, vous pouvez exécuter les commandes suivantes. Le résultat des deux commandes doit être égal au nombre de nœuds dans le cluster :
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Supprimez le DaemonSet de nettoyage : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Reprendre stackdriver-log-forwarder :
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Journalisation et surveillance 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    stackdriver-log-forwarder n'envoie pas de journaux à Cloud Logging

    Si les journaux de vos clusters ne s'affichent pas dans Cloud Logging, et que l'erreur suivante s'affiche dans vos journaux : 

    2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Il est probable que le taux d'entrée des journaux dépasse la limite de l'agent Logging. Par conséquent, stackdriver-log-forwarder n'envoie pas de journaux. Ce problème se produit dans toutes les versions de Google Distributed Cloud.

    Solution :

    Pour atténuer ce problème, vous devez augmenter la limite de ressources sur l'agent Logging.

    1. Ouvrez votre ressource stackdriver pour la modifier : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Pour augmenter la demande de processeur pour stackdriver-log-forwarder, ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver : 
      spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      Votre ressource modifiée doit ressembler à ceci : 
      spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Enregistrez les modifications et fermez l'éditeur de texte.
    4. Pour vérifier que vos modifications ont bien été prises en compte, exécutez la commande suivante : 
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      La commande recherche cpu: 1200m si vos modifications ont été appliquées.
    Sécurité 1.13

    Le service Kubelet sera temporairement indisponible après NodeReady

    le nœud est prêt pendant une courte période, mais le certificat du serveur kubelet n'est pas prêt. kubectl exec et kubectl logs sont indisponibles pendant ces dizaines de secondes. En effet, il faut un certain temps au nouvel approbateur de certificat de serveur pour voir les adresses IP valides mises à jour du nœud.

    Ce problème n'affecte que le certificat du serveur de kubelet et n'affecte pas la planification des pods.
    Mises à niveau et mises à jour 1.12

    La mise à niveau partielle du cluster d'administrateur ne bloque pas la mise à niveau ultérieure du cluster d'utilisateur

    Échec de la mise à niveau du cluster d'utilisateur avec:

    .LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Le cluster d'administrateur n'est pas entièrement mis à niveau, et la version d'état est toujours 1.10. La mise à niveau du cluster d'utilisateur vers la version 1.12 ne sera bloquée par aucune vérification préliminaire et échoue en raison d'un problème de décalage entre les versions.


    Solution :

    Effectuez la mise à niveau du cluster d'administrateur vers la version 1.11, puis mettez à niveau le cluster d'utilisateur vers la version 1.12.
    Espace de stockage 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore signale à tort que l'espace disponible est insuffisant

    Échec de la commande gkectl diagnose cluster avec : 

    Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    La validation de l'espace disponible du datastore ne doit pas être utilisée pour les pools de nœuds de cluster existants. Elle a été ajoutée dans gkectl diagnose cluster par erreur.


    Solution :

    Vous pouvez ignorer le message d'erreur ou ignorer la validation à l'aide de --skip-validation-infra.
    Opération, Mise en réseau 1.11, 1.12.0-1.12.1

    Échec de l'ajout du cluster d'utilisateur lorsque le cluster d'administrateur utilise l'équilibreur de charge MetalLB

    Vous ne pourrez peut-être pas ajouter de cluster d'utilisateur si votre cluster d'administrateur est configuré avec une configuration d'équilibreur de charge MetalLB.

    Le processus de suppression du cluster d'utilisateur peut se bloquer pour une raison quelconque, ce qui entraîne l'invalidation du fichier ConfigMap de MatalLB. Cet état ne permettra pas d'ajouter un nouveau cluster d'utilisateur.


    Solution :

    Vous pouvez forcer la suppression de votre cluster d'utilisateur.
    Installation, système d'exploitation 1,10, 1,11, 1,12, 1,13

    Échec lors de l'utilisation de Container-Optimized OS (COS) pour le cluster d'utilisateur

    Si osImageType utilise cos pour le cluster d'administrateur, et lorsque gkectl check-config est exécuté après la création du cluster d'administrateur et avant la création du cluster d'utilisateur, l'opération échoue pour :

    Failed to create the test VMs: VM failed to get IP addresses on the network.

    La VM de test créée pour le cluster d'utilisateur check-config utilise par défaut le même osImageType que celui du cluster d'administrateur. La VM de test actuelle n'est pas encore compatible avec COS.


    Solution :

    Pour éviter la vérification préliminaire lente qui crée la VM de test, utilisez gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Journalisation et surveillance 1.12.0-1.12.1

    Grafana du cluster d'administrateur ne parvient pas à atteindre les clusters d'utilisateur

    Ce problème affecte les clients qui utilisent Grafana dans le cluster d'administrateur pour surveiller les clusters d'utilisateur dans les versions 1.12.0 et 1.12.1 de Google Distributed Cloud. Elle est due à une incohérence entre les certificats pushprox-client des clusters d'utilisateur et la liste d'autorisation du serveur pushprox du cluster d'administrateur. Le symptôme est le client pushprox-client dans les clusters d'utilisateur qui imprime des journaux d'erreurs comme suit:

    level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Solution :
    Autre 1.11.3

    gkectl repair admin-master ne fournit pas le modèle de VM à utiliser pour la récupération

    Échec de la commande gkectl repair admin-master avec : 

    Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master ne peut pas récupérer le modèle de VM à utiliser pour réparer la VM du plan de contrôle administrateur si le nom de la VM du plan de contrôle administrateur se termine par les caractères t, m, p ou l.


    Solution :

    Réexécutez la commande avec --skip-validation.
    Journalisation et surveillance 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    Échec de Cloud Audit Logging en raison d'un refus d'autorisation

    Cloud Audit Logs nécessite une configuration d'autorisation spéciale, qui n'est actuellement effectuée automatiquement que pour les clusters d'utilisateur via GKE Hub. Il est recommandé d'avoir au moins un cluster d'utilisateur utilisant le même ID de projet et le même compte de service avec le cluster d'administrateur pour Cloud Audit Logs afin que le cluster d'administrateur dispose de l'autorisation requise.

    Toutefois, dans les cas où le cluster d'administrateur utilise un ID de projet ou un compte de service différent de celui d'un cluster d'utilisateur, les journaux d'audit du cluster d'administrateur ne pourront pas être injectés dans Google Cloud. Ce symptôme est une série d'erreurs Permission Denied dans le pod audit-proxy du cluster d'administrateur.

    Solution :
    Opérations, Sécurité 1.11

    Échec de la vérification des certificats par gkectl diagnose

    Si votre station de travail n'a pas accès aux nœuds de calcul du cluster d'utilisateur, elle recevra les échecs suivants lors de l'exécution de gkectl diagnose:

    Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Si votre station de travail n'a pas accès aux nœuds de calcul du cluster d'administrateur ou aux nœuds de calcul du cluster d'administrateur, elle rencontrera les échecs suivants lors de l'exécution de gkectl diagnose:

    Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Solution :

    Si vous pouvez les ignorer sans risque.
    Système d'exploitation 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    /var/log/audit/ remplit l'espace disque sur les VM

    Le champ /var/log/audit/ contient des journaux d'audit. Vous pouvez vérifier l'espace disque utilisé en exécutant sudo du -h -d 1 /var/log/audit.

    Certaines commandes gkectl sur le poste de travail administrateur (par exemple, gkectl diagnose snapshot) contribuent à l'utilisation de l'espace disque.

    Depuis la version 1.8 de Google Distributed Cloud, l'image Ubuntu est renforcée avec le benchmark CIS de niveau 2. Et l'une des règles de conformité, "4.1.2.2 Assurez-vous que les journaux d'audit ne sont pas automatiquement supprimés", garantit le paramètre auditd max_log_file_action = keep_logs. Toutes les règles d'audit sont ainsi conservées sur le disque.


    Solution :
    Mise en réseau 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup Conflits d'adresses IP flottantes avec l'adresse du nœud

    Les utilisateurs ne peuvent pas créer ou mettre à jour des objets NetworkGatewayGroup en raison de l'erreur de webhook de validation suivante:

    [1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    Dans les versions concernées, le kubelet peut se lier par erreur à une adresse IP flottante attribuée au nœud et la signaler en tant qu'adresse de nœud dans node.status.addresses. Le webhook de validation vérifie les adresses IP flottantes de NetworkGatewayGroup par rapport à toutes les node.status.addresses du cluster et considère cela comme un conflit.


    Solution :

    Dans le cluster où la création ou la mise à jour des objets NetworkGatewayGroup échoue, désactivez temporairement le webhook de validation ANG et envoyez votre modification:

    1. Enregistrez la configuration du webhook afin de pouvoir la restaurer à la fin : 
      kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Modifiez la configuration du webhook : 
      kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Supprimez l'élément vnetworkgatewaygroup.kb.io de la liste de configuration du webhook et fermez-le pour appliquer les modifications.
    4. Créez ou modifiez votre objet NetworkGatewayGroup.
    5. Appliquez à nouveau la configuration du webhook d'origine : 
      kubectl -n kube-system apply -f webhook-config.yaml
    Installation, mises à niveau et mises à jour 1.10.0-1.10.2

    Création ou mise à niveau du délai avant expiration du cluster d'administrateur

    Lors d'une tentative de mise à niveau du cluster d'administrateur, la VM du plan de contrôle administrateur peut rester bloquée lors de la création. La VM du plan de contrôle administrateur passe en boucle d'attente infinie lors du démarrage, et l'erreur de boucle infinie suivante s'affiche dans le fichier /var/log/cloud-init-output.log:

    + echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    En effet, lorsque Google Distributed Cloud tente d'obtenir l'adresse IP du nœud dans le script de démarrage, il utilise grep -v ADMIN_CONTROL_PLANE_VIP pour ignorer l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur, qui peut également être attribuée à la carte d'interface réseau. Cependant, la commande ignore également toute adresse IP comportant un préfixe de l'adresse IP virtuelle du plan de contrôle, ce qui entraîne le blocage du script de démarrage.

    Par exemple, supposons que l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur soit 192.168.1.25. Si l'adresse IP de la VM du plan de contrôle du cluster d'administrateur possède le même préfixe, par exemple 192.168.1.254, la VM du plan de contrôle sera bloquée lors de la création. Ce problème peut également être déclenché si l'adresse de diffusion a le même préfixe que l'adresse IP virtuelle du plan de contrôle (par exemple, 192.168.1.255).


    Solution :

    • Si le délai avant expiration de la création du cluster d'administrateur est dû à l'adresse IP de diffusion, exécutez la commande suivante sur la VM du plan de contrôle du cluster d'administrateur : 
      ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Une ligne sans adresse de diffusion sera créée et le processus de démarrage sera débloqué. Une fois le script de démarrage débloqué, supprimez cette ligne ajoutée en exécutant la commande suivante :
      ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Toutefois, si le délai avant expiration de la création du cluster d'administrateur est dû à l'adresse IP de la VM du plan de contrôle, vous ne pouvez pas débloquer le script de démarrage. Utilisez une autre adresse IP, puis recréez ou mettez à niveau vers la version 1.10.3 ou une version ultérieure.
    Système d'exploitation, mises à jour et mises à jour 1.10.0-1.10.2

    L'état du cluster d'administrateur utilisant l'image COS sera perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation du maître d'administrateur

    DataDisk ne peut pas être installé correctement sur le nœud maître du cluster d'administrateur lorsque vous utilisez l'image COS. L'état du cluster d'administrateur utilisant cette image sera perdu lors de la mise à niveau du cluster d'administrateur ou de la réparation du maître d'administrateur. (Le cluster d'administrateur utilisant une image COS est une fonctionnalité en version preview)


    Solution :

    Recréer le cluster d'administrateur en définissant osImageType sur Ubuntu_containerd

    Après avoir créé le cluster d'administrateur avec osImageType défini sur "cos", récupérez la clé SSH du cluster d'administrateur et connectez-vous en SSH au nœud maître administrateur. df -h résultat contient /dev/sdb1 98G 209M 93G 1% /opt/data. Et lsblk résultat contient -sdb1 8:17 0 100G 0 part /opt/data
    Système d'exploitation 1.10

    La résolution DNS par systemd-resolved a échoué sur les domaines .local

    Dans la version 1.10.0 de Google Distributed Cloud, les résolutions de noms sur Ubuntu sont acheminées par défaut vers l'écoute locale systemd-resolved sur 127.0.0.53. En effet, sur l'image Ubuntu 20.04 utilisée dans la version 1.10.0, /etc/resolv.conf est lié symboliquement à /run/systemd/resolve/stub-resolv.conf, qui pointe vers le bouchon DNS de l'hôte local 127.0.0.53.

    Par conséquent, la résolution de noms DNS localhost refuse de rechercher sur les serveurs DNS en amont (spécifiés dans /run/systemd/resolve/resolv.conf) les noms portant un suffixe .local, sauf s'ils sont spécifiés en tant que domaines de recherche.

    Cela entraîne l'échec des recherches de noms .local. Par exemple, au démarrage du nœud, kubelet ne parvient pas à extraire des images d'un registre privé avec un suffixe .local. La spécification d'une adresse vCenter avec un suffixe .local ne fonctionnera pas sur un poste de travail administrateur.


    Solution :

    Vous pouvez éviter ce problème pour les nœuds de cluster si vous spécifiez le champ searchDomainsForDNS dans le fichier de configuration de votre cluster d'administrateur et le fichier de configuration du cluster d'utilisateur pour inclure les domaines.

    Actuellement, gkectl update ne permet pas de mettre à jour le champ searchDomainsForDNS.

    Par conséquent, si vous n'avez pas configuré ce champ avant la création du cluster, vous devez vous connecter en SSH aux nœuds et contourner le bouchon local résolu par systemd en remplaçant le lien symbolique de /etc/resolv.conf (qui contient le bouchon local 127.0.0.53) par /run/systemd/resolve/resolv.conf (qui pointe vers le DNS en amont) :

    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
    /run/systemd/resolve/stub-resolv.conf

    Comme pour le poste de travail administrateur, gkeadm ne permet pas de spécifier des domaines de recherche. Vous devez donc contourner ce problème à l'aide de cette étape manuelle.

    Cette solution ne persiste pas lors de la recréation de VM. Vous devez appliquer à nouveau cette solution chaque fois que des VM sont recréées.
    Installation, système d'exploitation 1.10

    L'adresse IP du pont Docker utilise 172.17.0.1/16 au lieu de 169.254.123.1/24

    Google Distributed Cloud spécifie un sous-réseau dédié à l'adresse IP du pont Docker qui utilise --bip=169.254.123.1/24 afin qu'il ne réserve pas le sous-réseau 172.17.0.1/16 par défaut. Toutefois, dans la version 1.10.0, il existe un bug dans l'image de l'OS Ubuntu qui a entraîné le rejet de la configuration Docker personnalisée.

    Par conséquent, Docker choisit la valeur 172.17.0.1/16 par défaut comme sous-réseau d'adresses IP de pont. Cela peut entraîner un conflit d'adresses IP si une charge de travail est déjà en cours d'exécution dans cette plage d'adresses IP.


    Solution :

    Pour contourner ce problème, vous devez renommer le fichier de configuration systemd suivant pour dockerd, puis redémarrer le service:

    sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

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 de VM. Vous devez appliquer à nouveau cette solution chaque fois que des VM sont recréées.
    Mises à niveau et mises à jour 1.11

    Mise à niveau vers la version 1.11 bloquée par la disponibilité de Stackdriver

    Dans la version 1.11.0 de Google Distributed Cloud, la définition des ressources personnalisées associées à la journalisation et la surveillance a changé:

    • Le nom du groupe de la ressource personnalisée stackdriver (addons.sigs.k8s.io) a été remplacé par addons.gke.io.
    • Le nom du groupe associé aux ressources personnalisées monitoring et metricsserver est passé de addons.k8s.io à addons.gke.io.
    • Les spécifications des ressources ci-dessus commencent à être validées par rapport à leur schéma. En particulier, les spécifications "resourceAttrOverride" et "storageSizeOverride" de la ressource personnalisée stackdriver doivent comporter un type de chaîne dans les valeurs des requêtes et limites de taille de processeur, de mémoire et de stockage.

    Les modifications apportées aux noms des groupes sont apportées pour se conformer aux mises à jour de CustomResourceDefinition dans Kubernetes 1.22.

    Si vous ne disposez pas d'une logique supplémentaire pour appliquer ou modifier les ressources personnalisées concernées, aucune action n'est requise. Le processus de mise à niveau de Google Distributed Cloud assurera la migration des ressources concernées et conservera leurs spécifications existantes après le changement de nom du groupe.

    Toutefois, si vous exécutez une logique qui applique ou modifie les ressources concernées, une attention particulière est requise. Tout d'abord, ils doivent être référencés avec le nouveau nom de groupe dans votre fichier manifeste. Exemple :

    apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    Ensuite, assurez-vous que les valeurs des spécifications resourceAttrOverride et storageSizeOverride sont de type "string" (chaîne). Exemple :

    spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work 
        memory: 3000Mi

    Sinon, l'application et les modifications ne prendront pas effet et peuvent entraîner un état inattendu des composants de journalisation et de surveillance. Les symptômes potentiels peuvent inclure:

    • Journaux des erreurs de rapprochement dans onprem-user-cluster-controller, par exemple: 
      potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Échec dans kubectl edit stackdriver stackdriver, par exemple: 
      Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Si vous rencontrez les erreurs ci-dessus, cela signifie qu'un type non compatible selon la spécification de la RS Stackdriver était déjà présent avant la mise à niveau. Pour contourner ce problème, vous pouvez modifier manuellement la RS Stackdriver sous l'ancien nom de groupe kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver et procéder comme suit:

    1. Passer les demandes et les limites de ressources au type de chaîne
    2. Supprimez toute annotation addons.gke.io/migrated-and-deprecated: true, le cas échéant.
    Ensuite, reprenez ou recommencez le processus de mise à niveau.

    Système d'exploitation 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16

    Les VM COS n'affichent aucune adresse IP lorsque les VM sont déplacées lors d'un arrêt non progressif de l'hôte.

    En cas de défaillance d'un serveur ESXi et que la fonction vCenter HA a été activée pour le serveur, toutes les VM du serveur ESXi défaillant déclenchent le mécanisme vMotion et sont déplacées vers un autre serveur ESXi normal. Les VM COS migrées perdraient leurs adresses IP.

    Solution :

    Redémarrer la VM
    Mise en réseau toutes les versions antérieures à 1.14.7, 1.15.0-1.15.3, 1.16.0

    La réponse GARP envoyée par Seesaw ne définit pas l'adresse IP cible

    L'ARP gratuit (GARP) périodique envoyé par Seesaw ne définit pas l'adresse IP cible dans l'en-tête ARP. Certains réseaux peuvent ne pas accepter de tels paquets (comme Cisco ACI). Cela peut entraîner un temps d'arrêt du service plus long après la récupération d'un split-brain (en raison de la suppression de paquets VRRP).

    Solution :

    Déclenchez un basculement Sees en exécutant sudo seesaw -c failover sur l'une des VM Seesaw. Cela devrait restaurer le trafic.
    Système d'exploitation 1.16, 1.28.0-1.28.200

    Le kubelet est inondé de journaux indiquant que "/etc/kubernetes/manifests" n'existe pas sur les nœuds de calcul

    "staticPodPath" a été défini par erreur pour les nœuds de calcul

    Solution :

    Créer manuellement le dossier "/etc/kubernetes/manifests"
    Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.