s <0x0

Cette page répertorie tous les problèmes connus de Google Distributed Cloud (logiciel uniquement) pour Bare Metal (anciennement appelé Google Distributed Cloud Virtual, lui-même anciennement appelé clusters Anthos sur Bare Metal).

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, et qui s'occupent des alertes et des pages lorsque les objectifs de niveau de service (SLO) ne sont pas atteints ou que les applications présentent des défaillances. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez Rôles utilisateur et tâches courantes de GKE.

Si vous faites partie du Google Developer Program, enregistrez cette page pour recevoir des notifications lorsqu'une note de version la concernant est publiée. Pour en savoir plus, consultez Pages enregistrées.

Pour filtrer les problèmes connus en fonction d'une version ou d'une catégorie de produit, sélectionnez vos filtres dans les menus déroulants suivants.

Sélectionnez votre version de Google Distributed Cloud :

1,34 1.33 1,32 1.31 1,30 1,29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

Sélectionnez votre catégorie de problème :

Configuration Installation Mises à niveau et mises à jour Opération Journalisation et surveillance Mise en réseau Sécurité Réinitialisation/Suppression Environnement d'exécution de VM sur GDC

Vous pouvez également rechercher votre problème :

Catégorie	Version(s) identifiée(s)	Problème et solution
Mise en réseau, mises à niveau et mises à jour	1.30 et versions ultérieures	Le pod Istiod ne parvient pas à atteindre l'état prêt lors des mises à niveau La fonctionnalité d'Ingress fournie dans Google Distributed Cloud utilise istiod. Cette fonctionnalité n'utilise pas les définitions de ressources personnalisées définies par Istio. Toutefois, comme le code utilisé est Open Source, les pods sont sensibles aux installations Istio que vous pourriez avoir pour vos propres cas d'utilisation. Si aucune définition de ressource personnalisée Istio n'est présente dans les clusters, Istiod se déclare prêt sans attendre les définitions de ressources personnalisées. Toutefois, s'il existe des définitions de ressources personnalisées v1beta dans le cluster, Istiod attend v1 définitions de ressources personnalisées avant de déclarer l'état prêt. Par conséquent, le pod Istiod risque de ne pas atteindre l'état prêt, ce qui peut entraîner l'échec des mises à niveau du cluster. Validation : Pour vérifier que votre cluster est bien affecté, vérifiez l'état du pod Istiod dans l'espace de noms gke-system : kubectl get pods -n gke-system -l app=istiod Si l'état du pod est Running, mais que la vérification de l'état d'intégrité échoue (par exemple, 0/1 prêt), votre cluster est probablement affecté. Solution : Pour résoudre ce problème, utilisez l'une des solutions suivantes : Déployez manuellement les définitions de ressources personnalisées v1 d'Istio sur votre cluster. Désactivez la fonctionnalité d'entrée groupée si vous ne l'utilisez pas.
Installation, mises à niveau et mises à jour	1.30.400 et versions antérieures	lifecycle-controllers-manager plante lors de la vérification des ressources personnalisées PreflightCheck Les clusters dont la version est 1.30.400 ou antérieure peuvent rencontrer des plantages de pods lifecycle-controllers-manager lors de la validation des ressources personnalisées PreflightCheck. Ces plantages bloquent le provisionnement et les mises à niveau des clusters. Ce problème se produit en raison d'un déréférencement de pointeur nul lors de la validation des ressources PreflightCheck. Solution : Pour permettre le provisionnement ou la mise à niveau des clusters, contournez les vérifications préliminaires. Définissez le champ bypassPreflightCheck sur true dans le fichier de configuration de votre cluster : spec: bypassPreflightCheck: true Pour en savoir plus, consultez Contourner les vérifications préliminaires lors de l'application de ressources Kubernetes.
Opération, Réinitialisation/Suppression	1.33 et versions antérieures	Le détecteur de problèmes de nœuds ne démarre pas après la restauration du cluster Lorsque vous restaurez un cluster à l'aide de bmctl restore cluster, le service systemd Node Problem Detector (NPD) ne démarre pas sur les nœuds une fois l'opération de restauration terminée. Pour vérifier si vous êtes concerné, exécutez systemctl is-active node-problem-detector sur les nœuds de cluster après une opération de restauration. Si la commande renvoie inactive, vous êtes concerné par ce problème. Solution : Pour restaurer les données non personnelles, procédez comme suit : Désactivez NPD en suivant la procédure décrite dans Activer et désactiver le détecteur de problème de nœud. Activez NPD en suivant la procédure décrite dans Activer et désactiver le détecteur de problème de nœud. La désactivation et l'activation de NPD déclenchent explicitement les tâches du déployeur NPD, qui installent le service NPD sur tous les nœuds.
Mise en réseau, fonctionnement	1.28 et versions antérieures, 1.29.0-1.29.700, 1.30.0-1.30.300	Les pods de l'équilibreur de charge du plan de contrôle redémarrent tous les sept jours. Dans les clusters utilisant l'équilibreur de charge de couche 2 fourni, vous pouvez observer des erreurs "Connection Refused" (Connexion refusée) ou une brève indisponibilité du serveur API (environ une minute) tous les sept jours. Ce comportement se produit, car les pods haproxy et keepalived sur les nœuds du plan de contrôle sont redémarrés en raison d'un paramètre de durée de vie du job. Ce problème affecte les clusters des versions 1.29.0 à 1.29.700, 1.30.0 à 1.30.300, et 1.28 et antérieures. Validation : Pour confirmer que votre cluster est concerné par ce problème spécifique, vérifiez la configuration du job de mise à jour de l'équilibreur de charge en procédant comme suit : Recherchez le nom du job de mise à jour : kubectl get jobs -n kube-system | grep bm-system-cplb-update Vérifiez le paramètre de durée de vie du job : kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}' Remplacez JOB_NAME par le nom renvoyé à l'étape précédente. Si le résultat est 604800 (soit sept jours en secondes), votre cluster est affecté par ce problème. Solution : Pour éviter les redémarrages hebdomadaires, corrigez manuellement le champ ttlSecondsAfterFinished des tâches de mise à jour de l'équilibreur de charge existantes en lui attribuant une valeur plus élevée. Pour ce faire, procédez comme suit : Modifiez le job de mise à jour de l'équilibreur de charge : kubectl edit job JOB_NAME -n kube-system Dans l'éditeur, recherchez le champ ttlSecondsAfterFinished et remplacez la valeur par 7776000 (environ 90 jours). Enregistrez et quittez l'éditeur pour appliquer les modifications.
Opération	1.32.0-1.32.700, 1.33.0-1.33.300, 1.34.0	Le pod cluster-operator plante avec un déréférencement de pointeur nul Le pod cluster-operator peut planter ou entrer dans une boucle de plantage en raison d'un panic : assignment to entry in nil map dans un contrôleur. Cela peut se produire lorsque le contrôleur tente de mettre à jour des annotations sur une ressource personnalisée, telle qu'un NodePool, qui ne comporte aucune annotation (carte nulle). Solution : Pour éviter cette erreur, assurez-vous que la ressource personnalisée (par exemple, NodePool) comporte au moins une annotation. Vous pouvez ajouter une annotation factice à l'aide de la commande suivante : kubectl annotate nodepool NODEPOOL_NAME \ -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \ --kubeconfig=ADMIN_KUBECONFIG Remplacez les éléments suivants : NODEPOOL_NAME : nom de la ressource personnalisée NodePool. CLUSTER_NAMESPACE : espace de noms du cluster. ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Mises à niveau et mises à jour	1.34.0	Échec de la mise à niveau du nœud de calcul en raison d'une incompatibilité de nom d'hôte La mise à niveau des nœuds de calcul échoue en raison d'une régression (kubernetes/kubeadm#3244) dans kubeadm. La régression se produit lorsque le nom d'hôte Linux ne correspond pas à la valeur du libellé kubernetes.io/hostname sur les nœuds Kubernetes correspondants. Pour confirmer l'échec du nœud concerné, utilisez journalctl comme suit : [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm La réponse devrait ressembler à l'exemple suivant : Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found Dans cet exemple, le nom d'hôte Linux indiqué dans la réponse journalctl ne correspond pas au libellé kubernetes.io/hostname du nœud, ce qui confirme que la mise à niveau est concernée par ce problème : kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \ -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}' La réponse : lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos Solution : Pour que le nœud concerné termine la mise à niveau, essayez de modifier temporairement le nom d'hôte pour qu'il corresponde à la valeur du libellé kubernetes.io/hostname sur les nœuds Kubernetes correspondants, comme suit : [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
Mise en réseau	1.34.0	La migration fluide abandonne les connexions existantes lors de la mise en quarantaine des nœuds Lorsque vous activez le basculement rapide NAT de sortie, la mise en quarantaine d'un nœud de passerelle avec kubectl cordon <NODE_NAME> lance une migration fluide qui maintient les connexions de sortie existantes. Toutefois, dans la version 1.34.0 de Google Distributed Cloud exclusivement logicielle, la fonctionnalité de migration fluide ne fonctionne pas comme prévu. Si un administrateur isole un nœud de passerelle de sortie actif dans un cluster de version 1.34.0 qui utilise le basculement rapide, l'isolation se comporte comme une défaillance de nœud non planifiée et met fin immédiatement à toutes les connexions avec état existantes sur ce nœud. Solution : Il n'existe aucune solution pour contourner ce problème.
Mise en réseau	1.32.0	Échecs de communication du service ClusterIP Les services ClusterIP peuvent rencontrer des problèmes de connexion intermittents ou des échecs de connexion lorsque le trafic est acheminé vers des pods de backend sur différents nœuds. Cet échec de communication est dû à une régression dans Cilium v1.15 qui a entraîné la suppression des règles CILIUM_POST_nat de iptables. Les règles CILIUM_POST_nat sont nécessaires pour la traduction d'adresse réseau source (SNAT). Leur suppression entraîne un masquage non fiable par kube-proxy, ce qui entraîne des échecs de communication du service ClusterIP. Par exemple, si vous mettez à niveau un cluster et que l'opération est bloquée, vous pouvez voir des messages de journaux semblables à ceux ci-dessous, qui indiquent que le handshake TLS a expiré alors que le service ClusterIP tente de se connecter au serveur d'API dans le pool de nœuds np1 : I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out Ce problème est résolu dans la version 1.32.100 et ultérieures. Solution : Si vous ne pouvez pas passer à une version contenant le correctif, nous vous recommandons de mettre à niveau manuellement l'image Cilium vers la version v1.15.6-anthos1.32.50 ou ultérieure. Cette mise à jour résout ce problème en réintroduisant les règles CILIUM_POST_nat nécessaires. Remarque : Vous pouvez également rétablir la communication en mettant à jour manuellement les règles iptables pour ajouter la règle NAT manquante, mais nous ne recommandons pas ce type de modification. Les modifications de configuration de bas niveau comme celle-ci peuvent ne pas persister lors des redémarrages de nœuds ou des mises à jour de clusters. Pour mettre à niveau l'image Cilium, procédez comme suit : Modifiez le DaemonSet anetd dans l'espace de noms kube-system : kubectl edit ds anetd -n kube-system Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version. Example old image: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc... Exemple de nouvelle image : image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50 Enregistrez vos modifications et fermez l'éditeur.
Installation, mises à niveau et mises à jour	1.33	bmctl configure projects renvoie une erreur Identity Pool does not exist Lorsque vous tentez d'utiliser la commande bmctl configure projects pour configurer la fédération d'identité de charge de travail pour un nouveau projet Google Cloud , la commande échoue et affiche le message d'erreur suivant : Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.svc.id.goog). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id Cet échec se produit, car le pool d'identités de charge de travail par défaut nécessaire nommé projectID.svc.id.goog n'est pas provisionné automatiquement dans le nouveau projet. Solution : Procédez comme suit pour configurer la fédération d'identité de charge de travail pour votre projet : Créez manuellement le pool d'identités de charge de travail par défaut manquant : gcloud iam workload-identity-pools create PROJECT_ID.svc.id.goog \ --location=global \ --project=PROJECT_ID Remplacez PROJECT_ID par l'ID du projet. Sur votre poste de travail administrateur, mettez à jour la variable d'environnement GCP_ACCESS_TOKEN avec un jeton d'accès nouvellement récupéré : export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token) Par défaut, le jeton d'accès a une durée de vie de 3 600 secondes (une heure). Lorsque vous utilisez l'authentification de cluster Workload Identity, bmctl vérifie le délai d'expiration du jeton. Si le jeton expire dans les 1 800 secondes (30 minutes), bmctl signale une erreur et quitte. Exécutez bmctl configure projects à nouveau.
Mises à niveau et mises à jour, journalisation et surveillance	1.29, 1.30, 1.31, 1.32	Échec du playbook Ansible cal-update lors de la modification de l'indicateur de journalisation d'audit Le playbook Ansible cal-update contient des erreurs logiques qui entraînent son échec lors de la tentative de modification du flag disableCloudAuditLogging. Cela empêche l'activation ou la désactivation correcte des journaux d'audit. Lorsque disableCloudAuditLogging passe de true à false, les journaux d'audit ne peuvent pas être activés, car le script échoue avant d'appliquer la modification de configuration à kube-apiserver. Lorsque disableCloudAuditLogging passe de false à true, les journaux d'audit peuvent être désactivés, mais le job cal-update échoue en permanence, ce qui empêche le playbook d'atteindre les vérifications de l'état. Le message d'erreur observé est le suivant : The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines' Solution : Il n'existe pas de solution de contournement pour ce problème. Vous devez mettre à niveau votre cluster vers une version incluant le correctif. Pour effectuer la mise à niveau, procédez comme suit : Désactivez la journalisation d'audit en définissant disableCloudAuditLogging sur true. Lorsque le correctif sera disponible, mettez à niveau votre cluster vers l'une des versions de correctif suivantes (ou ultérieures), qui contiennent la correction : 1.30.1200 1.31.800 1.32.400 Pour réactiver les journaux d'audit Cloud, redéfinissez disableCloudAuditLogging sur false.
Mises à niveau et mises à jour	1.32+	Échec des mises à niveau pour les clusters d'administrateur à haute disponibilité (HA) après une opération de réparation Sur les clusters d'administrateur HA, la commande gkectl upgrade admin échoue et se bloque lorsque vous l'exécutez après la commande gkectl repair admin-master. La commande gkectl repair admin-master ajoute une annotation machine.onprem.gke.io/managed=false aux machines réparées. Cette annotation empêche le contrôleur cluster-api de se débloquer dans un état de réconciliation lorsque vous exécutez la commande gkectl upgrade admin. Les mises à niveau pour les clusters non HD incluent une logique de pivot qui supprime cette annotation, mais cette logique est absente des mises à niveau pour les clusters HD. Solution : Supprimez manuellement l'annotation machine.onprem.gke.io/managed des ressources Machine sur le cluster d'administrateur avant de commencer la mise à niveau.
Mises à niveau, configuration	1.32.0 à 1.32.200	Le miroir de registre entraîne l'échec de la vérification préliminaire de la mise à niveau Les clusters configurés avec un miroir de registre échouent à la vérification préliminaire check_gcr_pass lors d'une mise à niveau vers la version 1.32.0 ou ultérieure. Cet échec est dû à une modification de la façon dont la ressource personnalisée PreflightCheck est construite, en omettant les configurations de miroir de registre de la spécification de cluster utilisée dans la vérification. Ce problème a été découvert lors de tests internes sur des clusters avec des configurations de proxy et de mirror de registre. Solution : Pour contourner ce problème, vous pouvez utiliser l'une des options suivantes : Utilisez l'option --force lorsque vous déclenchez la mise à niveau. Obtenez la configuration actuelle du cluster à l'aide de bmctl get config et utilisez ce fichier de configuration nouvellement généré pour déclencher la mise à niveau.
Configuration, Mises à jour	1.15 à 1.30, 1.31.0 à 1.31.800, 1.32.0 à 1.32.300	Échec de la mise à jour de la tâche Cron de vérification de l'état périodique après modification de la spécification du cluster Dans certaines versions de cluster, il est possible que les CronJobs de vérification de l'état'état périodique ne mettent pas à jour leurs spécifications lorsque la configuration de la ressource de cluster est modifiée. Ces échecs de mise à jour entraînent des vérifications d'état obsolètes et des échecs potentiels de tâches. Ce problème est résolu dans les versions 1.31.900, 1.32.400 et 1.33.0 de Google Distributed Cloud, ainsi que dans les versions ultérieures. Solution : Pour les versions 1.30 et antérieures, vous pouvez utiliser la procédure suivante comme solution de contournement : Désactivez les vérifications périodiques de l'état. Cette action supprime la ressource HealthCheck actuelle. Réactivez les vérifications périodiques de l'état. Cette opération crée des ressources HealthCheck qui tiennent compte de la dernière configuration du cluster.
Mise en réseau	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	Entrelacement des ARP sans frais pour l'adresse IP virtuelle du plan de contrôle Keepalived est utilisé pour déplacer l'adresse IP virtuelle du plan de contrôle d'une machine à une autre afin d'assurer la haute disponibilité. Lorsque l'adresse IP virtuelle du plan de contrôle est gérée par l'équilibreur de charge de couche 2 fourni, il est possible que les basculements de l'instance Keepalived entraînent de brefs intervalles (moins d'une seconde) pendant lesquels des ARP sans frais avec différentes adresses MAC sont entrelacés. L'infrastructure du réseau de commutation peut interpréter cet entrelacement comme anormal et refuser d'autres messages ARP pendant des périodes pouvant aller jusqu'à 30 minutes. Les messages ARP bloqués peuvent, à leur tour, entraîner l'indisponibilité de l'adresse IP virtuelle du plan de contrôle pendant cette période. L'entrelacement des ARP sans frais est dû aux paramètres Keepalived utilisés dans la version 1.31 et les versions antérieures. Plus précisément, tous les nœuds ont été configurés pour utiliser la même priorité. Les modifications de la configuration Keepalived de la version 1.32 résolvent ce problème en configurant différentes priorités pour chaque instance Keepalived et en fournissant également un paramètre de cluster, controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat, pour réduire le nombre d'ARP sans frais. Solution : Pour les versions 1.31 et antérieures, vous pouvez réduire l'entrelacement des ARP sans frais en modifiant directement le fichier de configuration Keepalived, /usr/local/etc/keepalived/keepalived.conf. Pour chacun des nœuds qui exécutent l'équilibreur de charge du plan de contrôle, modifiez le fichier de configuration pour modifier les paramètres suivants : priority : définissez une valeur priority distincte pour chaque nœud (les valeurs valides sont comprises entre 1 et 254). weight : remplacez la valeur weight de -2 par -253 pour vous assurer qu'un basculement Keepalived est déclenché en cas d'échec d'une vérification de l'état'état.
Journalisation et surveillance	1.30, 1.31, 1.32, 1.33	Écart dans la métrique kubernetes.io/anthos/custom_resurce_watchers En raison d'une erreur de définition interne, la métrique kubernetes.io/anthos/custom_resurce_watchers peut afficher des données inexactes. Si vous êtes concerné par ce problème, des erreurs semblables à celles-ci peuvent s'afficher dans les journaux : One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE. Vous pouvez ignorer ces erreurs en toute sécurité. Cette métrique n'est pas utilisée pour les alertes système critiques, et les erreurs n'affectent pas le fonctionnement de votre projet ni de vos clusters.
Opération	1.30, 1.31, 1.32, 1.33	Échec de l'analyse du fichier de configuration du cluster lors de la capture de l'instantané Si le répertoire .manifests est manquant sur le poste de travail administrateur lorsque vous exécutez bmctl check cluster --snapshot, la commande échoue et affiche une erreur semblable à la suivante : Error message: failing while capturing snapshot failed to parse cluster config file failed to get CRD file Cet échec se produit, car la commande bmctl check cluster --snapshot nécessite les fichiers de définition de ressources personnalisées dans le répertoire .manifests pour valider la configuration du cluster. Ce répertoire est généralement créé lors de la configuration du cluster. Si vous supprimez accidentellement le répertoire ou exécutez bmctl à partir d'un autre emplacement, la commande ne peut pas poursuivre l'opération d'instantané. Solutions : Vous pouvez résoudre ce problème en régénérant manuellement le répertoire .manifests à l'aide de l'une des méthodes suivantes : Exécutez la commande bmctl check cluster : bmctl check cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG Lors de ses vérifications initiales, cette commande crée automatiquement le répertoire .manifests dans votre répertoire de travail actuel, que la commande se termine correctement ou non. Dans le répertoire contenant votre fichier de configuration de cluster actuel, exécutez la commande bmctl create cluster : bmctl create cluster --cluster TEST_CLUSTER Bien que cette commande génère probablement une erreur, telle que Unable to Parse Cluster Configuration File (Impossible d'analyser le fichier de configuration du cluster), le répertoire .manifests est toujours créé dans votre répertoire de travail actuel. Le répertoire temporaire bmctl-workspace/TEST_CLUSTER généré peut être supprimé en toute sécurité par la suite. Après avoir effectué l'une des solutions de contournement précédentes, réessayez la commande bmctl check cluster --snapshot.
Installation, mises à niveau et mises à jour	1.32.0, 1.32.100	L'adresse IP virtuelle du plan de contrôle n'est pas déplacée lorsque HAProxy n'est pas disponible Si l'instance HAProxy n'est pas disponible sur un nœud qui héberge l'adresse VIP du plan de contrôle, le paramètre nopreempt de l'instance Keepalived empêche l'adresse VIP du plan de contrôle de passer à un nœud avec un HAProxy opérationnel. Ce problème est lié à une fonctionnalité qui configure automatiquement les priorités du protocole VRRP (Virtual Router Redundancy Protocol) de Keepalived, qui est incompatible avec le paramètre nopreempt. Solution : Pour contourner ce problème, procédez comme suit pour désactiver la fonctionnalité Keepalived : Ajoutez l'annotation preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" au cluster : kubectl annotate --kubeconfig ADMIN_KUBECONFIG \ -n CLUSTER_NAMESPACE \ clusters.baremetal.cluster.gke.io/CLUSTER_NAME \ preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable" Supprimez nopreempt de /usr/local/etc/keepalived/keepalived.conf sur les nœuds qui exécutent l'équilibreur de charge du plan de contrôle. Selon la configuration de votre équilibreur de charge, il s'agit des nœuds du plan de contrôle ou des nœuds d'un pool de nœuds d'équilibrage de charge. Une fois nopreempt supprimé, les pods statiques keepalived doivent être redémarrés pour appliquer les modifications apportées aux fichiers de configuration. Pour ce faire, sur chaque nœud, utilisez la commande suivante pour redémarrer les pods keepalived : crictl rmp -f \ $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
Installation, mises à niveau et mises à jour	1.30, 1.31, 1.32.0	Les dossiers abm-tools-* ne sont pas nettoyés Les jobs de vérification de l'état et de prévol échoués peuvent laisser des artefacts dans des dossiers abm-tools-* horodatés sous /usr/local/bin. Si vous êtes concerné par ce problème, vous verrez peut-être de nombreux dossiers comme celui-ci : /usr/local/bin/abm-tools-preflight-20250410T114317. En cas d'échecs répétés, l'utilisation du disque peut augmenter. Solution Si vous rencontrez ce problème, supprimez manuellement les dossiers suivants : rm -rf /usr/local/bin/abm-tools-*
Mise en réseau	1.28.0-1.28.200	Le trafic de l'équilibreur de charge est abandonné lorsque vous utilisez une passerelle NAT de sortie Sur les clusters pour lesquels la passerelle NAT de sortie est activée, si un équilibreur de charge choisit des backends qui correspondent aux règles de sélection du trafic spécifiées par une ressource personnalisée EgressNATPolicy obsolète, le trafic de l'équilibreur de charge est abandonné. Ce problème se produit lors de la création et de la suppression de pods correspondant à une règle de sortie. Les règles de sortie ne sont pas nettoyées comme elles le devraient lorsque les pods sont supprimés. Les règles de sortie obsolètes entraînent la tentative d'envoi de trafic par les pods LoadBalancer vers une connexion qui n'existe plus. Ce problème est résolu dans les versions 1.28.300 et ultérieures de Google Distributed Cloud. Solution Pour nettoyer les ressources de la règle NAT de sortie, redémarrez chaque nœud qui héberge un backend en échec.
Mises à niveau et mises à jour, réinitialisation/suppression	1.28	Échec de l'initialisation de la machine : nouveau nœud du plan de contrôle bloqué lors du remplacement Lorsque vous remplacez (supprimez, ajoutez) un nœud de plan de contrôle dans Google Distributed Cloud 1.28, il est possible que le nouveau nœud ne parvienne pas à rejoindre le cluster. En effet, le processus responsable de la configuration du nouveau nœud (bm-system-machine-init) rencontre l'erreur suivante : Failed to add etcd member: etcdserver: unhealthy cluster Cette erreur se produit lorsqu'un ancien nœud de plan de contrôle est supprimé et que son appartenance à etcd-events n'est pas correctement supprimée, ce qui laisse un membre obsolète. Le membre obsolète empêche de nouveaux nœuds de rejoindre le cluster etcd-events, ce qui entraîne l'échec du processus machine-init et la recréation continue du nouveau nœud. Voici les conséquences de ce problème : Le nouveau nœud du plan de contrôle ne parvient pas à démarrer correctement. Le cluster peut rester bloqué dans l'état RECONCILING. Le nœud du plan de contrôle est supprimé et recréé en permanence en raison de l'échec machine-init. Ce problème est résolu dans la version 1.29 et les versions ultérieures. Solution : Si vous ne pouvez pas passer à la version 1.29, vous pouvez supprimer manuellement le membre etcd-events défectueux du cluster en suivant les instructions ci-dessous : Utilisez SSH pour accéder à un nœud du plan de contrôle fonctionnel. Exécutez la commande suivante : ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member list Si la réponse inclut le nœud supprimé dans la liste des membres, recherchez l'ID de membre du nœud dans la première colonne et exécutez la commande suivante : ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member remove MEMBER_ID Remplacez MEMBER_ID par l'ID du membre du nœud supprimé. Le nouveau nœud de plan de contrôle devrait rejoindre automatiquement le cluster au bout de quelques minutes.
Mises à niveau et mises à jour	1.30.500-gke.126, 1.30.600-gke.68, 1.31.100-gke.136, 1.31.200-gke.58	Échec de la mise à niveau du plan de contrôle en raison de l'absence du fichier super-admin.conf Lors de la mise à niveau d'un cluster, le processus de mise à niveau peut échouer sur le premier nœud de plan de contrôle avec un message d'erreur dans le job Ansible indiquant que le fichier super-admin.conf est manquant. Ce problème se produit, car le premier nœud du plan de contrôle à mettre à niveau n'est pas forcément le premier nœud provisionné lors de la création du cluster. Le processus de mise à niveau suppose que le premier nœud à mettre à niveau est celui qui contient le fichier super-admin.conf. Ce problème est résolu dans les mises à jour correctives suivantes : 1.30.500-gke.127, 1.30.600-gke.69 et 1.31.200-gke.59. Solution : Pour résoudre le problème, procédez comme suit sur le nœud concerné : Copiez le fichier /etc/kubernetes/admin.conf dans /etc/kubernetes/super-admin.conf : cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf Le processus de mise à niveau effectue automatiquement des nouvelles tentatives et devrait aboutir.
Mises à niveau et mises à jour	1.29.0 - 1.29.1100, 1.30.0 - 1.30.400	Le drainage des nœuds est bloqué si les pods tolèrent les rejets NoSchedule Les pods avec une tolérance NoSchedule sont considérés pour l'éviction lors des mises à niveau. Toutefois, en raison de la tolérance NoSchedule, le contrôleur Deployment ou DaemonSet peut replanifier le pod sur le nœud en cours de maintenance, ce qui peut retarder la mise à niveau. Pour savoir si vous êtes concerné par ce problème, procédez comme suit : Consultez les journaux des pods anthos-cluster-operator pour identifier ceux qui empêchent le nœud de se vider. Dans l'extrait de journal suivant, le pod node-problem-detector-mgmt-ydhc2 n'a pas encore été vidé : nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"} Pour chaque pod qui empêche le vidage du nœud, exécutez la commande suivante pour vérifier les tolérances : kubectl get po POD_NAME -n kube-system \ -o json | jq '.spec.tolerations' Remplacez POD_NAME par le nom du pod qui empêche le nœud de se vider. L'une des combinaisons suivantes devrait s'afficher : Tolérance avec l'effet NoSchedule et l'opérateur Exists Tolérance avec l'effet NoSchedule et la clé "baremetal.cluster.gke.io/maintenance" Tolérance avec un effet vide et une clé "baremetal.cluster.gke.io/maintenance" Par exemple, la réponse peut ressembler à ce qui suit : { "effect": "NoSchedule", "operator": "Exists" }, Solution : Pour empêcher le vidage du nœud, vous pouvez effectuer l'une des opérations suivantes : Ajoutez la tolérance baremetal.cluster.gke.io/maintenance:NoExecute aux pods qui ont une tolérance baremetal.cluster.gke.io/maintenance:Schedule et qui ne nécessitent pas d'arrêt optimal. Supprimez les combinaisons de tolérances identifiées des pods qui doivent être évincés lors de la vidange des nœuds.
Mise en réseau	1.28, 1.29 et 1.30	Les appels réseau aux pods avec hostPort activé échouent pour les requêtes provenant du même nœud. Les appels réseau vers les pods pour lesquels hostPort est activé échouent et les paquets sont supprimés si la requête provient du même nœud que celui sur lequel le pod est exécuté. Cela s'applique à tous les types de clusters et de nœuds. Toutefois, les clusters créés sans kube-proxy ne sont pas concernés. Pour savoir si vous êtes concerné par ce problème : Obtenez les noms des pods anetd : Les pods anetd sont chargés de contrôler le trafic réseau. kubectl get pods -l k8s-app=cilium -n kube-system Vérifiez l'état des pods anetd : kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters Remplacez ANETD_POD_NAME par le nom de l'un des pods anetd de votre cluster. Si la réponse inclut KubeProxyReplacement: Partial ..., vous êtes concerné par ce problème. Solution Si vous souhaitez envoyer des requêtes à des pods qui utilisent hostPort à partir du même nœud sur lequel ils s'exécutent, vous pouvez créer un cluster sans kube-proxy. Vous pouvez également configurer les pods pour qu'ils utilisent un portmap plug-in CNI (Container Network Interface).
Journalisation et surveillance	Identifié dans la version 1.29.100, mais peut également se produire dans d'autres versions	E/S disque élevées en raison d'une perte de connectivité réseau ou d'un compte de service incorrect Les pods stackdriver-log-forwarder peuvent perdre la connectivité ou avoir un compte de service expiré, ce qui empêche l'envoi de ces journaux à logging.googleapis.com. Cela entraîne une accumulation de journaux dans le tampon, ce qui se traduit par des E/S disque élevées. L'agent Cloud Logging (Fluent Bit), un DaemonSet nommé stackdriver-log-forwarder, utilise un tampon basé sur le système de fichiers avec une limite de 4 Go. Lorsqu'il est plein, l'agent tente de faire pivoter ou de vider le tampon, ce qui peut entraîner un nombre élevé d'E/S. À vérifier : Vérifiez si les clés du compte de service ont expiré. Si c'est le cas, faites-les pivoter pour résoudre le problème. Vous pouvez confirmer le compte de service actuellement utilisé à l'aide de la commande suivante et le valider dans IAM : kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode Solution : Avertissement : La suppression de la mémoire tampon entraînera la perte définitive de tous les journaux actuellement stockés dans la mémoire tampon (y compris les journaux des nœuds, des pods et des conteneurs Kubernetes).  Si l'accumulation de mémoire tampon est due à une perte de connectivité réseau avec le service de journalisation de Google Cloud, ces journaux seront définitivement perdus lorsque la mémoire tampon sera supprimée ou si elle est pleine et que l'agent ne peut pas envoyer les journaux. Supprimez le pod DaemonSet stackdriver-log-forwarder du cluster en ajoutant un sélecteur de nœud (cela conserve le DaemonSet stackdriver-log-forwarder, mais le désinscrit des nœuds) : kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Remplacez KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur. Vérifiez que les pods stackdriver-log-forwarder sont bien supprimés avant de passer à l'étape suivante. Si cela ne se produit que pour un ou plusieurs nœuds : Connectez-vous au nœud à l'aide de SSH où stackdriver-log-forwarder était en cours d'exécution (vérifiez que stackdriver-log-forwarder n'est plus en cours d'exécution sur ce nœud). Sur le nœud, supprimez tous les fichiers de tampon à l'aide de rm -rf /var/log/fluent-bit-buffers/, puis suivez l'étape 6. S'il y a trop de nœuds avec ces fichiers et que vous souhaitez appliquer un script pour nettoyer tous les nœuds qui ont ces blocs de backlog, utilisez les scripts suivants : Déployez un DaemonSet pour nettoyer toutes les données dans les tampons fluent-bit : kubectl --kubeconfig KUBECONFIG -n kube-system apply -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 Assurez-vous que le DaemonSet a nettoyé tous les nœuds. Le résultat des deux commandes suivantes doit être égal au nombre de nœuds du cluster : kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l Supprimez le DaemonSet de nettoyage : kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup Redémarrez les pods stackdriver-log-forwarder : kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Mises à niveau et mises à jour, opération	1.28, 1.29, 1.30.0 et 1.30.100	Mises à niveau bloquées par des pods bloqués en raison d'un problème containerd Les pods peuvent rester bloqués lors de l'arrêt lorsque les nœuds sont en cours de drainage. Les pods bloqués peuvent bloquer des opérations telles que les mises à niveau qui vident les nœuds. Les pods peuvent se bloquer lorsque le conteneur est indiqué comme étant en cours d'exécution, même si le processus principal sous-jacent du conteneur s'est déjà arrêté correctement. Dans ce cas, la commande crictl stop n'arrête pas non plus le conteneur. Pour savoir si vous êtes concerné par le problème, procédez comme suit : Vérifiez si des pods de votre cluster sont bloqués avec l'état Terminating : kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating Pour tout pod dont la terminaison est bloquée, utilisez kubectl describe pour rechercher des événements : kubectl describe pod POD_NAME \ --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE Si vous voyez des avertissements comme ceux ci-dessous avec Unhealthy et FailedKillPod comme raisons, vous êtes concerné par ce problème : Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"] Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown Ce problème est dû à un problème containerd en amont, qui a été résolu dans les versions Google Distributed Cloud 1.28.1000, 1.29.600, 1.30.200, 1.31 et ultérieures. Solution Pour débloquer l'opération du cluster : Forcez la suppression des pods bloqués : kubectl delete pod POD_NAME -n POD_NAMESPACE --force Une fois les pods redémarrés, réessayez l'opération de cluster.
Mises à niveau et mises à jour, opération	1.28, 1.29 et 1.30.0-1.30.100	Mises à niveau bloquées par des pods bloqués en raison de l'échec de la suppression de cgroups Les pods peuvent rester bloqués lors de l'arrêt lorsque les nœuds sont en cours de drainage. Les pods bloqués peuvent bloquer les opérations de cluster, telles que les mises à niveau, qui vident les nœuds. Les pods peuvent se bloquer lorsque le processus runc init se fige, ce qui empêche containerd de supprimer le cgroups associé à ce pod. Pour savoir si vous êtes concerné par le problème, procédez comme suit : Vérifiez si des pods de votre cluster sont bloqués avec l'état Terminating : kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating Vérifiez les journaux kubelet dans les nœuds dont les pods sont bloqués en cours d'arrêt : La commande suivante renvoie les entrées de journal contenant le texte Failed to remove cgroup. journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup" Si la réponse contient des avertissements tels que les suivants, vous êtes concerné par ce problème : May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... Solution Pour dégeler le processus runc init et débloquer les opérations du cluster : À l'aide du chemin d'accès cgroup des journaux kubelet, vérifiez si cgroup est figé en consultant le contenu du fichier freezer.state : cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state Le contenu de freezer.state indique l'état de cgroup. Avec un chemin d'accès issu des entrées de journal de l'exemple précédent, la commande ressemblerait à ceci : cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state Libérez les cgroups dont l'état est FREEZING ou FROZEN : echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state Lorsque les cgroups ont été THAWED, les processus runc init correspondants se ferment automatiquement et les cgroups sont automatiquement supprimés. Cela empêche l'affichage d'avertissements Failed to remove cgroup supplémentaires dans les journaux kubelet. Les pods bloqués dans l'état Terminating sont également supprimés automatiquement peu de temps après le nettoyage. Une fois les cgroups figés nettoyés et les pods bloqués supprimés, réessayez l'opération de cluster.
Configuration, mise en réseau	1.28.0 à 1.28.1000, 1.29.0 à 1.29.500 et 1.30.0 à 1.30.200	Événements NodeNotReady en raison d'échecs de mise à jour du bail Dans les versions identifiées de Google Distributed Cloud, kubelet peut ne pas mettre à jour les baux de nœud pendant plus de 40 secondes, ce qui entraîne des événements NodeNotReady. Le problème est intermittent et se produit environ tous les sept jours. Le basculement de l'adresse IP virtuelle du plan de contrôle peut se produire au moment des événements NodeNotReady. Ce problème est résolu dans les versions 1.28.1100, 1.29.600, 1.30.300 et ultérieures. Solution : Pour atténuer le problème, vous pouvez configurer kubelet en procédant comme suit : Créez /etc/default/kubelet et ajoutez-y les variables d'environnement suivantes : HTTP2_READ_IDLE_TIMEOUT_SECONDS=10 HTTP2_PING_TIMEOUT_SECONDS=5 Redémarrez kubelet : systemctl restart kubelet Obtenez le nouvel ID de processus (PID) pour kubelet : pgrep kubelet Vérifiez que les variables d'environnement prennent effet après le redémarrage de kubelet sur le nœud : cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS Remplacez KUBELET_PID par le résultat de la commande de l'étape précédente. La résultat de la commande cat doit lister les deux variables d'environnement ajoutées sur les deux dernières lignes.
Mises à jour	1,30	Erreur de champ immuable lors de la mise à jour des clusters d'utilisateur avec bmctl version 1.30.x Lorsque vous créez un cluster d'utilisateur à l'aide de la commande bmctl create cluster et que vous transmettez le champ cloudOperationsServiceAccountKeyPath dans l'en-tête, le champ spec.clusterOperations.serviceAccountSecret est ajouté à la ressource de cluster créée. Ce champ ne figure pas dans le fichier de configuration du cluster et est immuable. La commande bmctl update cluster ne remplit pas ce champ à partir de l'en-tête. Par conséquent, les tentatives de mise à jour du cluster avec la commande bmctl update cluster et le fichier de configuration de cluster d'origine échouent avec l'erreur suivante : [2025-01-15 16:38:46+0000] Failed to calculate diff: --- E000090: Unable to calculate diff An error occurred while calculating diff between live configuration and cluster.yaml file Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable. (A in old) (B in new) {"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1" A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090 Ce problème ne se produit que lorsque vous utilisez une version 1.30.x de bmctl pour effectuer des mises à jour. Solution : Pour contourner ce problème, vous pouvez obtenir la configuration du cluster de la ressource Cluster réelle avant d'effectuer vos modifications : Récupérez le fichier de configuration du cluster d'utilisateur en fonction de la ressource de cluster déployée : bmctl get config --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH La ressource personnalisée récupérée est écrite dans un fichier YAML nommé : bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml. Ce nouveau fichier de configuration inclut spec.clusterOperations.serviceAccountSecret, qui est nécessaire au bon fonctionnement de la commande de mise à jour. L'élément TIMESTAMP figurant dans le nom du fichier indique la date et l'heure de création du fichier. Remplacez le fichier de configuration de cluster existant par le fichier récupéré. Enregistrez la sauvegarde du fichier existant. Modifiez le nouveau fichier de configuration du cluster et utilisez bmctl update pour mettre à jour votre cluster d'utilisateur : bmctl update cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH
Mises à niveau et mises à jour, Sécurité	1.29, 1.30 et 1.31	Échec de la rotation des certificats kubelet lorsque les fichiers de certificats actuels ne sont pas des liens symboliques La rotation des certificats Kubelet échoue lorsque kubelet-client-current.pem et kubelet-server-current.pem sont des fichiers réels, et non des liens symboliques. Ce problème peut se produire après l'utilisation de bmctl restore pour restaurer un cluster à partir d'une sauvegarde. Solution : Si vous êtes concerné par ce problème, vous pouvez procéder comme suit pour le contourner : Sauvegardez les fichiers de certificat actuels : mkdir -p ~/kubelet-backup/ cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/ Vous pouvez également supprimer les fichiers de certificat accumulés : ls | grep -E "^kubelet-server-20*" | xargs rm -rf ls | grep -E "^kubelet-client-20*" | xargs rm -rf Renommez les fichiers kubelet-client-current.pem et kubelet-server-current.pem : L'utilisation d'un code temporel est une méthode courante pour renommer les fichiers. datetime=$(date +%Y-%m-%d-%H-%M-%S) mv kubelet-server-current.pem kubelet-server-${datetime}.pem mv kubelet-client-current.pem kubelet-client-${datetime}.pem Dans la même session que la commande précédente, créez des liens symboliques pointant vers les derniers certificats valides (renommés) : ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem Définissez les autorisations sur 777 pour les liens symboliques : chmod 777 kubelet-server-current.pem chmod 777 kubelet-client-current.pem Si la rotation des certificats a réussi, supprimez le répertoire de sauvegarde : rm -rf ~/kubelet-backup/
Installation, mises à niveau et mises à jour	1.31	Erreurs lors de la création de ressources personnalisées Dans la version 1.31 de Google Distributed Cloud, des erreurs peuvent se produire lorsque vous essayez de créer des ressources personnalisées, telles que des clusters (tous types) et des charges de travail. Ce problème est dû à une modification incompatible introduite dans Kubernetes 1.31, qui empêche le champ caBundle d'une définition de ressource personnalisée de passer d'un état valide à un état non valide. Pour en savoir plus sur cette modification, consultez le journal des modifications de Kubernetes 1.31. Avant Kubernetes 1.31, le champ caBundle était souvent défini sur une valeur de substitution \n, car dans les versions antérieures de Kubernetes, le serveur d'API n'autorisait pas le contenu vide du bundle d'autorité de certification. L'utilisation de \n était une solution de contournement raisonnable pour éviter toute confusion, car cert-manager met généralement à jour caBundle ultérieurement. Si caBundle a été corrigé une fois pour passer d'un état non valide à un état valide, il ne devrait pas y avoir de problème. Toutefois, si la définition de la ressource personnalisée est réconciliée avec \n (ou une autre valeur non valide), l'erreur suivante peut se produire : ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block] Solution Si vous disposez d'une définition de ressource personnalisée dans laquelle caBundle est défini sur une valeur non valide, vous pouvez supprimer complètement le champ caBundle. Cela devrait résoudre le problème.
Installation, mises à niveau et mises à jour	1.28, 1.29 et 1.30	Les mises à niveau des clusters prennent trop de temps Lors de la mise à niveau d'un cluster, chaque nœud du cluster est vidé et mis à niveau. Dans les versions 1.28 et ultérieures, Google Distributed Cloud est passé du drainage de nœud basé sur le rejet au drainage basé sur l'expulsion. De plus, pour gérer les interdépendances des pods, la vidange basée sur l'éviction suit un ordre de vidange en plusieurs étapes. À chaque étape du drainage, les pods disposent d'un délai de grâce de 20 minutes pour se terminer, alors que le drainage précédent basé sur les taints avait un délai d'expiration unique de 20 minutes. Si chaque étape nécessite les 20 minutes complètes pour évincer tous les pods, le temps nécessaire pour vider un nœud peut être beaucoup plus long que la vidange précédente basée sur les taints. En retour, l'augmentation du temps de vidange des nœuds peut augmenter considérablement le temps nécessaire pour effectuer une mise à niveau ou mettre un cluster en mode maintenance. Il existe également un problème Kubernetes en amont qui affecte la logique de délai avant expiration pour la vidange basée sur l'éviction. Ce problème peut également augmenter les temps de vidange des nœuds. Solution : Pour contourner ce problème, vous pouvez désactiver le drainage des nœuds basé sur l'éviction. Cette opération rétablit la vidange basée sur les taints. Toutefois, nous vous déconseillons le drainage basé sur les taints, car il ne respecte pas les PodDisruptionBudgets (PDB), ce qui peut entraîner des interruptions de service.
Installation, mises à niveau et mises à jour	1.16, 1.28 et 1.29	Une vérification préliminaire obsolète ayant échoué peut bloquer les opérations du cluster La réconciliation de cluster est une phase standard pour la plupart des opérations de cluster, y compris la création et la mise à niveau de clusters. Lors de la réconciliation du cluster, le contrôleur de cluster Google Distributed Cloud déclenche une vérification préliminaire. Si cette vérification préliminaire échoue, la réconciliation du cluster est bloquée. Par conséquent, les opérations de cluster qui incluent la réconciliation de cluster sont également bloquées. Cette vérification préliminaire n'est pas exécutée périodiquement, mais uniquement dans le cadre de la réconciliation du cluster. Par conséquent, même si vous corrigez le problème qui a provoqué l'échec initial des vérifications préliminaires et que les vérifications préliminaires à la demande s'exécutent correctement, la réconciliation du cluster reste bloquée en raison de cette vérification préliminaire obsolète ayant échoué. Si l'installation ou la mise à niveau d'un cluster est bloquée, vous pouvez vérifier si vous êtes concerné par ce problème en procédant comme suit : Consultez les journaux du pod anthos-cluster-operator pour rechercher des entrées telles que les suivantes : "msg"="Preflight check not ready. Won't reconcile" Vérifiez si la vérification préliminaire déclenchée par le contrôleur de cluster est en état d'échec : kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Remplacez les éléments suivants : PREFLIGHT_CHECK_NAME : nom du contrôle avant vol à supprimer. Dans ce cas, le nom est identique à celui du cluster. CLUSTER_NAMESPACE : espace de noms du cluster pour lequel le contrôle avant vol échoue. ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. Si la vérification préliminaire a échoué (Status.Pass est défini sur false), vous êtes probablement concerné par ce problème. Ce problème est résolu dans la version 1.30 et toutes les versions ultérieures. Solution Pour débloquer les opérations de cluster, supprimez manuellement la vérification préliminaire ayant échoué du cluster d'administrateur : kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Une fois la vérification préliminaire obsolète et ayant échoué supprimée, le contrôleur de cluster peut en créer une autre.
Installation, mises à niveau et mises à jour	1.30.100, 1.30.200 et 1.30.300	Il est possible que les opérations de création ou de mise à niveau de clusters d'utilisateur échouent. Il est possible que la création de clusters d'utilisateur dans les versions 1.30.100, 1.30.200 ou 1.30.300, ou la mise à niveau de clusters d'utilisateur existants vers ces versions, échoue. Ce problème ne se produit que lorsque kubectl ou un client de l'API GKE On-Prem (la console Google Cloud , la gcloud CLI ou Terraform) est utilisé pour les opérations de création et de mise à niveau du cluster d'utilisateur. Dans ce cas, l'opération de création de cluster d'utilisateur est bloquée à l'état Provisioning et la mise à niveau du cluster d'utilisateur est bloquée à l'état Reconciling. Pour vérifier si un cluster est concerné, procédez comme suit : Obtenez la ressource de cluster : kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Remplacez les éléments suivants : CLUSTER_NAME : nom du cluster d'utilisateur bloqué. USER_CLUSTER_NAMESPACE : nom de l'espace de noms du cluster d'utilisateur. ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster de gestion. Si la valeur CLUSTER STATE est Provisioning ou Reconciling, vous êtes peut-être concerné par ce problème. L'exemple de réponse suivant indique qu'une mise à niveau est bloquée : NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling Les versions incompatibles indiquent également que la mise à niveau du cluster n'est pas terminée. Recherchez le nom complet du pod anthos-cluster-operator : kubectl get pods -n kube-system -o=name \ -l baremetal.cluster.gke.io/lifecycle-controller-component=true \ --kubeconfig ADMIN_KUBECONFIG Comme le montre l'exemple suivant, le résultat est une liste de pods qui inclut le pod anthos-cluster-operator : pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7 Diffusez les journaux de pod anthos-cluster-operator pour un message récurrent, indiquant que le cluster est bloqué lors du provisionnement ou de la réconciliation : kubectl logs POD_NAME -n kube-system -f --since=15s \ --kubeconfig ADMIN_KUBECONFIG | \ grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" Remplacez POD_NAME par le nom complet du pod anthos-cluster-operator de l'étape précédente. À mesure que la commande s'exécute, recherchez un flux continu de lignes de journaux correspondantes, ce qui indique que l'opération de cluster est bloquée. L'exemple de résultat suivant ressemble à ce que vous voyez lorsqu'un cluster est bloqué lors de la réconciliation : ... I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926" I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n" ... Appuyez sur Ctrl+C pour arrêter le streaming des journaux. Vérifiez si ConfigMapForwarder est bloqué : kubectl get configmapforwarder metadata-image-digests-in-cluster \ -n USER_CLUSTER_NAMESPACE \ -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \ --kubeconfig ADMIN_KUBECONFIG La réponse contient des motifs et des messages de la ressource ConfigMapForwarder. Lorsque ConfigMapForwarder est bloqué, vous devriez obtenir un résultat semblable à ce qui suit : Reason: Stalled Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation Vérifiez que le ConfigMap metadata-image-digests n'est pas présent dans l'espace de noms du cluster d'utilisateur : kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG La réponse devrait ressembler à l'exemple ci-dessous : Error from server (NotFound): configmaps "metadata-image-digests" not found Solution Pour contourner ce problème, vous pouvez mettre à jour manuellement le ConfigMap afin d'ajouter l'annotation manquante : Ajoutez l'annotation manquante au fichier ConfigMap : kubectl annotate configmap metadata-image-digests \ -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \ --kubeconfig ADMIN_KUBECONFIG Lorsque l'annotation est correcte, le ConfigMap metadata-image-digests doit être créé automatiquement dans l'espace de noms du cluster d'utilisateur. Vérifiez que le fichier ConfigMap est automatiquement créé dans l'espace de noms du cluster d'utilisateur : kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Si le ConfigMap a été créé, la réponse de la commande ressemble à ce qui suit : NAME DATA AGE metadata-image-digests 0 7s Avec la correction et la vérification ci-dessus, l'opérateur de cluster devrait être débloqué et l'opération de cluster devrait se dérouler comme d'habitude.
Opération, Réinitialisation/Suppression	1.30.0 à 1.30.300, 1.29.0 à 1.29.700, 1.28.0 à 1.28.1100	Les utilisateurs non root ne peuvent pas exécuter bmctl restore pour restaurer le quorum. Lorsque vous exécutez bmctl restore --control-plane-node en tant qu'utilisateur non racine, un problème chown se produit lors de la copie de fichiers du nœud du plan de contrôle vers la machine de la station de travail. Solution : Exécutez la commande bmctl restore --control-plane-node avec sudo pour les utilisateurs non racine.
Mises à niveau	1.30.0-gke.1930	La tâche de vérification de l'état de la mise à niveau reste active en raison de l'image pause:3.9 manquante Lors d'une mise à niveau, il est possible que le job de vérification de l'état de la mise à niveau reste actif en raison de l'image pause:3.9 manquante. Ce problème n'a aucune incidence sur la réussite de la mise à niveau. Solution : Supprimez manuellement le job upgrade-health-check à l'aide de la commande suivante : kubectl delete job upgrade-health-check-JOB_ID --cascade=true
Système d'exploitation	1.28, 1.29, 1.30	Téléchargements lents dans des conteneurs sur RHEL 9.2 Le téléchargement d'artefacts dont la taille dépasse la limite memory.max du cgroup peut être extrêmement lent. Ce problème est dû à un bug dans le noyau Linux pour Red Hat Enterprise Linux (RHEL) 9.2. Les kernels pour lesquels cgroup v2 est activé sont concernés. Ce problème est résolu dans les versions 5.14.0-284.40.1.el_9.2 et ultérieures du noyau. Solution : Pour les pods concernés, augmentez les paramètres de limite de mémoire de leurs conteneurs (spec.containers[].resources.limits.memory) afin que les limites soient supérieures à la taille des artefacts téléchargés.
Mises à niveau	1.28 à 1.29.200	Échec de la mise à niveau du cluster en raison d'un conflit dans la définition de ressource personnalisée networks.networking.gke.io Lors de la mise à niveau d'un cluster bare metal, il est possible que la mise à niveau échoue et qu'un message d'erreur indique qu'il existe un conflit dans la définition de ressource personnalisée networks.networking.gke.io. Plus précisément, l'erreur indique que v1alpha1 n'est pas présent dans spec.versions. Ce problème se produit, car la version v1alpha1 de la définition de ressource personnalisée n'a pas été migrée vers v1 lors de la mise à niveau. Solution : Corrigez les clusters concernés à l'aide des commandes suivantes : kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/networks.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Installation, mises à niveau et mises à jour	1.28.0 à 1.28.600 et 1.29.0 à 1.29.200	Échecs des vérifications préliminaires de la machine pour les paramètres check_inotify_max_user_instances et check_inotify_max_user_watches Lors de l'installation ou de la mise à niveau du cluster, les vérifications préliminaires de la machine liées aux paramètres du noyau fs.inotify peuvent échouer. Si vous êtes concerné par ce problème, le journal de vérification préliminaire de la machine contient une erreur semblable à la suivante : Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. Ce problème se produit, car les valeurs fs.inotify max_user_instances et max_user_watches sont lues de manière incorrecte à partir du plan de contrôle et des hôtes d'amorçage, au lieu des machines de nœud prévues. Solution de contournement  : Pour contourner ce problème, ajustez fs.inotify.max_user_instances et fs.inotify.max_user_watches aux valeurs recommandées sur toutes les machines du plan de contrôle et d'amorçage : echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p Une fois l'installation ou la mise à niveau terminée, ces valeurs peuvent être rétablies si nécessaire.
Mises à niveau	1.28.0 - 1.28.500	Échec de la mise à niveau du cluster avec une erreur de vérification de l'accessibilité de Google Cloud Lorsque vous utilisez bmctl pour mettre à niveau un cluster, la mise à niveau peut échouer avec une erreur GCP reachability check failed, même si l'URL cible est accessible depuis le poste de travail administrateur. Ce problème est dû à un bug dans les versions 1.28.0 à 1.28.500 de bmctl. Solution : Avant d'exécuter la commande bmctl upgrade, définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS pour qu'elle pointe vers un fichier de clé de compte de service valide : export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG La définition des identifiants par défaut de l'application (ADC) de cette manière garantit que bmctl dispose des identifiants nécessaires pour accéder au point de terminaison de l'API Google.
Configuration, installation, mises à niveau et mises à jour, mise en réseau, sécurité	1.15, 1.16, 1.28, 1.29	Échec de l'installation et de la mise à niveau du cluster lorsque ipam-controller-manager est requis L'installation et la mise à niveau du cluster échouent lorsque ipam-controller-manager est requis et que votre cluster s'exécute sur Red Hat Enterprise Linux (RHEL) 8.9 ou version ultérieure (en fonction des modifications RHEL en amont) avec SELinux en mode "Enforcing" (Appliqué). Cela s'applique spécifiquement lorsque la version de container-selinux est supérieure à 2.225.0. Votre cluster nécessite ipam-controller-manager dans les situations suivantes : Votre cluster est configuré pour la mise en réseau à double pile IPv4/IPv6. Votre cluster est configuré avec clusterNetwork.flatIPv4 défini sur true. Votre cluster est configuré avec l'annotation preview.baremetal.cluster.gke.io/multi-networking: enable. L'installation et la mise à niveau du cluster échouent lorsque ipam-controller-manager est installé. Solution Définissez le contexte par défaut du répertoire /etc/kubernetes sur chaque nœud du plan de contrôle sur le type etc_t : semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes Ces commandes rétablissent la modification container-selinux dans le répertoire /etc/kubernetes. Une fois le cluster mis à niveau vers une version contenant le correctif, annulez la modification du contexte de fichier précédent sur chaque nœud du plan de contrôle : semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
Mises à niveau	1.28.0 - 1.28.500	Échec de la mise à niveau du cluster avec une erreur de vérification de l'accessibilité de Google Cloud Lorsque vous utilisez bmctl pour mettre à niveau un cluster, la mise à niveau peut échouer avec une erreur GCP reachability check failed, même si l'URL cible est accessible depuis le poste de travail administrateur. Ce problème est dû à un bug dans les versions 1.28.0 à 1.28.500 de bmctl. Solution : Avant d'exécuter la commande bmctl upgrade, définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS pour qu'elle pointe vers un fichier de clé de compte de service valide : export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG La définition des identifiants par défaut de l'application (ADC) de cette manière garantit que bmctl dispose des identifiants nécessaires pour accéder au point de terminaison de l'API Google.
Installation	1,29	Problème d'autorisation binaire pour un cluster avec un pool de nœuds d'équilibreur de charge distinct L'installation d'un cluster avec un pool de nœuds d'équilibreur de charge distinct peut échouer si vous activez la stratégie d'autorisation binaire lors de la création du cluster. Ce problème se produit, car la création du pod GKE Identity Service et d'autres pods critiques est bloquée par le webhook autorisation binaire. Pour savoir si vous êtes concerné par ce problème, procédez comme suit : Identifiez les pods qui échouent : kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG Décrivez le pod en échec. Recherchez le message suivant dans le résultat : admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} Si le message précédent s'affiche, cela signifie que votre cluster présente ce problème. Solution : Pour contourner ce problème, procédez comme suit : Annulez l'opération de création du cluster. Supprimez le bloc spec.binaryAuthorization du fichier de configuration du cluster. Créez le cluster avec l'autorisation binaire désactivée. Une fois l'installation terminée, activez la règle d'autorisation binaire pour un cluster existant.
Configuration, installation	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Les points de montage avec SELinux activé posent problème Si SELinux est activé et que vous installez des systèmes de fichiers dans des répertoires liés à Kubernetes, vous pouvez rencontrer des problèmes tels que l'échec de la création du cluster, des fichiers illisibles ou des problèmes d'autorisation. Pour déterminer si vous êtes concerné par ce problème, exécutez la commande suivante : ls -Z /var/lib/containerd . Si vous voyez system_u:object_r:unlabeled_t:s0 à la place d'un autre libellé, tel que system_u:object_r:container_var_lib_t:s0, vous êtes concerné. Solution : Si vous avez récemment installé des systèmes de fichiers dans des répertoires, assurez-vous que ces répertoires sont à jour avec votre configuration SELinux. Vous devez également exécuter les commandes suivantes sur chaque machine avant d'exécuter bmctl create cluster : restorecon -R -v /var restorecon -R -v /etc Cette correction ponctuelle persistera après le redémarrage, mais est requise chaque fois qu'un nouveau nœud avec les mêmes points de montage est ajouté. Pour en savoir plus, consultez Mounting File Systems (Montage de systèmes de fichiers) dans la documentation Red Hat.
Réinitialisation/Suppression	1.29.0	Échec de la réinitialisation du cluster d'utilisateur lors de la suppression de l'espace de noms Lorsque vous exécutez bmctl reset cluster -c ${USER_CLUSTER} après la fin de toutes les tâches associées, la commande ne parvient pas à supprimer l'espace de noms du cluster d'utilisateur. L'espace de noms du cluster d'utilisateur est bloqué à l'état Terminating. Le délai de réinitialisation du cluster finit par expirer et une erreur est renvoyée. Solution : Pour supprimer l'espace de noms et terminer la réinitialisation du cluster d'utilisateur, procédez comme suit : Supprimez le pod metrics-server du cluster d'administrateur : kubectl delete pods -l k8s-app=metrics-server \ -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH Dans ce cas, le pod metrics-server empêche la suppression de l'espace de noms du cluster. Dans le cluster d'administrateur, forcez la suppression du finaliseur dans l'espace de noms du cluster d'utilisateur : kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \ jq '.spec.finalizers = []' | \ kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f - Une fois le finaliseur supprimé, l'espace de noms du cluster est supprimé et la réinitialisation du cluster est terminée.
Configuration, installation, sécurité	1.16.0 à 1.16.7 et 1.28.0 à 1.28.400	Le déploiement de l'autorisation binaire ne comporte pas de nodeSelector Si vous avez activé l'autorisation binaire pour Google Distributed Cloud et que vous utilisez une version comprise entre 1.16.0 et 1.16.7 ou entre 1.28.0 et 1.28.400, vous pouvez rencontrer un problème concernant la planification des pods pour la fonctionnalité. Dans ces versions, le déploiement de l'autorisation binaire ne comporte pas de nodeSelector. Les pods de la fonctionnalité peuvent donc être planifiés sur des nœuds de calcul au lieu de nœuds de plan de contrôle. Ce comportement n'entraîne aucun échec, mais n'est pas prévu. Solution : Pour tous les clusters concernés, procédez comme suit : Ouvrez le fichier de déploiement de l'autorisation binaire : kubectl edit -n binauthz-system deployment binauthz-module-deployment Ajoutez le nodeSelector suivant dans le bloc spec.template.spec : nodeSelector: node-role.kubernetes.io/control-plane: "" Enregistrez les modifications. Une fois la modification enregistrée, les pods ne sont redéployés que sur les nœuds du plan de contrôle. Ce correctif doit être appliqué après chaque mise à niveau.
Mises à niveau et mises à jour	1.28.0, 1.28.100, 1.28.200, 1.28.300	Erreur lors de la mise à niveau d'un cluster vers la version 1.28.0-1.28.300 La mise à niveau des clusters créés avant la version 1.11.0 vers les versions 1.28.0 à 1.28.300 peut entraîner l'entrée du pod du déploiement du contrôleur de cycle de vie dans un état d'erreur lors de la mise à niveau. Dans ce cas, les journaux du pod de déploiement du contrôleur de cycle de vie contiennent un message d'erreur semblable à celui-ci : "inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions Solution : Ce problème a été résolu dans la version 1.28.400. Pour résoudre le problème, passez à la version 1.28.400 ou ultérieure. Si vous ne parvenez pas à effectuer la mise à niveau, exécutez les commandes suivantes pour résoudre le problème : kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Journalisation et surveillance	1.13.7, 1.14, 1.15, 1.16, 1.28	ID de projet incorrect affiché dans l'explorateur de journaux Il arrive que les journaux de cluster ou de conteneur soient tagués avec un ID de projet différent dans resource.labels.project_id de l'explorateur de journaux. Cela peut se produire lorsque le cluster est configuré pour utiliser l'observabilité PROJECT_ONE, qui est définie dans le champ clusterOperations.projectID de la configuration du cluster. Toutefois, le cloudOperationsServiceAccountKeyPath de la configuration possède une clé de compte de service provenant du projet PROJECT_TWO. Dans ce cas, tous les journaux sont acheminés vers PROJECT_ONE, mais resource.labels.project_id est libellé PROJECT_TWO. Solution : Pour résoudre le problème, utilisez l'une des options suivantes : Utilisez un compte de service du même projet de destination. Remplacez project_id dans le fichier JSON de clé de compte de service par le projet actuel. Modifiez project_id directement dans le filtre de journaux de l'explorateur de journaux.
Mise en réseau	1.29, 1.30	Dégradation des performances pour les clusters utilisant l'équilibrage de charge groupé avec BGP Pour les clusters de version 1.29.0 utilisant l'équilibrage de charge groupé avec BGP, les performances d'équilibrage de charge peuvent se dégrader à mesure que le nombre total de services de type LoadBalancer approche de 2 000. Lorsque les performances se dégradent, les services nouvellement créés mettent beaucoup de temps à se connecter ou ne peuvent pas être connectés par un client. Les services existants continuent de fonctionner, mais ne gèrent pas efficacement les modes d'échec, comme la perte d'un nœud d'équilibreur de charge. Ces problèmes de service se produisent lorsque le déploiement ang-controller-manager est arrêté en raison d'un manque de mémoire. Si votre cluster est concerné par ce problème, les services du cluster sont inaccessibles et non opérationnels, et le déploiement ang-controller-manager est dans un état CrashLoopBackOff. La réponse lors de la liste des déploiements ang-controller-manager est semblable à ce qui suit : ang-controller-manager-79cdd97b88-9b2rd 0/1 CrashLoopBackOff 639 (59s ago) 2d10h 10.250.210.152 vm-bgplb-centos4-n1-02 <none> <none> ang-controller-manager-79cdd97b88-r6tcl 0/1 CrashLoopBackOff 620 (4m6s ago) 2d10h 10.250.202.2 vm-bgplb-centos4-n1-11 <none> <none> Solution Pour contourner ce problème, vous pouvez augmenter la limite de ressources mémoire du déploiement ang-controller-manager de 100 Mio et supprimer la limite de processeur : kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG Une fois les modifications apportées et l'éditeur fermé, le résultat suivant doit s'afficher : deployment.apps/ang-controller-manager edited Pour vérifier que les modifications ont été appliquées, inspectez le fichier manifeste de ang-controller-manager dans le cluster : kubectl get deployment ang-controller-manager \ -n kube-system \ -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \ --kubeconfig ADMIN_KUBECONFIG La réponse devrait ressembler à ceci : NAME CPU_LIMITS MEMORY_LIMITS ang-controller-manager <none> 400Mi
Installation, mises à niveau, sauvegarde et restauration	1.28.0, 1.28.100	Les problèmes de connectivité du point de terminaison Artifact Registry gcr.io peuvent bloquer les opérations de cluster. Les opérations multiclusters pour les clusters d'administrateur créent un cluster d'amorçage. Avant de créer un cluster d'amorçage, bmctl effectue un test d'accessibilité Google Cloud depuis le poste de travail de l'administrateur. Ce contrôle peut échouer en raison de problèmes de connectivité avec le point de terminaison Artifact Registry, gcr.io. Vous pouvez alors voir un message d'erreur semblable à celui-ci : system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) Solution Pour contourner ce problème, réessayez l'opération avec l'indicateur --ignore-validation-errors.
Mise en réseau	1.15, 1.16	GKE Dataplane V2 incompatible avec certains pilotes de stockage Les clusters Bare Metal utilisent GKE Dataplane V2, qui est incompatible avec certains fournisseurs de stockage. Vous pouvez rencontrer des problèmes avec les volumes ou les pods NFS bloqués. Cela est particulièrement probable si vous avez des charges de travail utilisant des volumes ReadWriteMany sauvegardés par des pilotes de stockage susceptibles de présenter ce problème : Robin.io Portworx (volumes de service sharedv4) csi-nfs Cette liste n'est pas exhaustive. Solution Un correctif pour ce problème est disponible pour les versions Ubuntu suivantes : 20.04 LTS : utilisez une image de noyau 5.4.0 ultérieure à linux-image-5.4.0-166-generic 22.04 LTS : utilisez une image de noyau 5.15.0 ultérieure à linux-image-5.15.0-88-generic ou le noyau HWE 6.5. Si vous n'utilisez pas l'une de ces versions, contactez l'assistance Google.
Journalisation et surveillance	1.15, 1.16, 1.28	kube-state-metrics OOM dans un grand cluster Vous remarquerez peut-être que le pod kube-state-metrics ou gke-metrics-agent qui existe sur le même nœud que kube-state-metrics manque de mémoire (OOM). Cela peut se produire dans les clusters de plus de 50 nœuds ou avec de nombreux objets Kubernetes. Solution Pour résoudre ce problème, mettez à jour la définition de ressource personnalisée stackdriver afin d'utiliser la fonctionnalité ksmNodePodMetricsOnly. Cette fonctionnalité permet de s'assurer que seul un petit nombre de métriques critiques sont exposées. Pour utiliser cette solution de contournement, procédez comme suit : Consultez la définition de la ressource personnalisée stackdriver pour connaître les feature gates disponibles : kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly Mettez à jour la définition de ressource personnalisée stackdriver pour activer ksmNodePodMetricsOnly : kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
Installation	1.28.0-1.28.200	Échec de la vérification préliminaire sur RHEL 9.2 en raison de l'absence d'iptables Lorsque vous installez un cluster sur le système d'exploitation Red Hat Enterprise Linux (RHEL) 9.2, vous pouvez rencontrer un échec en raison du package iptables manquant. L'échec se produit lors des vérifications préliminaires et déclenche un message d'erreur semblable à celui-ci : 'check_package_availability_pass': "The following packages are not available: ['iptables']" RHEL 9.2 est disponible en version Preview pour Google Distributed Cloud version 1.28. Solution Contournez l'erreur de vérification préliminaire en définissant spec.bypassPreflightCheck sur true dans la ressource de votre cluster.
Opération	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16	Basculement MetalLB lent à grande échelle Lorsque MetalLB gère un grand nombre de services (plus de 10 000), le basculement peut prendre plus d'une heure. Cela se produit parce que MetalLB utilise une file d'attente à débit limité qui, à grande échelle, peut prendre un certain temps pour atteindre le service qui doit basculer. Solution Mettez à niveau votre cluster vers la version 1.28 ou ultérieure. Si vous ne parvenez pas à effectuer la mise à niveau, la modification manuelle du service (par exemple, l'ajout d'une annotation) entraîne un basculement plus rapide du service.
Opération	1.16.0-1.16.6, 1.28.0-1.28.200	Les variables d'environnement doivent être définies sur le poste de travail administrateur si le proxy est activé. bmctl check cluster peut échouer en raison de problèmes de proxy si les variables d'environnement HTTPS_PROXY et NO_PROXY ne sont pas définies sur le poste de travail administrateur. La commande bmctl renvoie un message d'erreur indiquant qu'elle n'a pas pu appeler certains services Google, comme dans l'exemple suivant : [2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred: * GKERegister check failed: 2 errors occurred: * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout Solution Définissez manuellement HTTPS_PROXY et NO_PROXY sur le poste de travail administrateur.
Mises à niveau et mises à jour	1.28.0-gke.435	Les mises à niveau vers la version 1.28.0-gke.435 peuvent échouer si audit.log n'appartient pas au bon propriétaire. Dans certains cas, le fichier /var/log/apiserver/audit.log sur les nœuds du plan de contrôle a la propriété du groupe et de l'utilisateur définie sur root. Ce paramètre de propriété de fichier entraîne des échecs de mise à niveau pour les nœuds du plan de contrôle lors de la mise à niveau d'un cluster de la version 1.16.x à la version 1.28.0-gke.435. Ce problème ne s'applique qu'aux clusters créés avant la version 1.11 et pour lesquels Cloud Audit Logs était désactivé. Cloud Audit Logs sont activés par défaut pour les clusters de version 1.9 et ultérieure. Solution Si vous ne parvenez pas à mettre à niveau votre cluster vers la version 1.28.100-gke.146, procédez comme suit pour mettre à niveau votre cluster vers la version 1.28.0-gke.435 : Si Cloud Audit Logs est activé, supprimez le fichier /var/log/apiserver/audit.log. Si Cloud Audit Logs est désactivé, définissez le propriétaire de /var/log/apiserver/audit.log sur le même que celui du répertoire parent, /var/log/apiserver.
Mise en réseau, mises à niveau et mises à jour	1.28.0-gke.435	MetalLB n'attribue pas d'adresses IP aux services VIP Google Distributed Cloud utilise MetalLB pour l'équilibrage de charge groupé. Dans la version 1.28.0-gke.435 de Google Distributed Cloud, le MetalLB fourni est mis à niveau vers la version 0.13, qui introduit la compatibilité CRD pour IPAddressPools. Toutefois, comme ConfigMaps autorise n'importe quel nom pour un IPAddressPool, les noms de pool ont dû être convertis en un nom compatible avec Kubernetes en ajoutant un hachage à la fin du nom du IPAddressPool. Par exemple, un IPAddressPool portant le nom default est converti en un nom tel que default-qpvpd lorsque vous mettez à niveau votre cluster vers la version 1.28.0-gke.435. Étant donné que MetalLB nécessite un nom spécifique d'IPPool pour la sélection, la conversion du nom empêche MetalLB de sélectionner un pool et d'attribuer des adresses IP. Par conséquent, les services qui utilisent metallb.universe.tf/address-pool comme annotation pour sélectionner le pool d'adresses d'une adresse IP ne reçoivent plus d'adresse IP du contrôleur MetalLB. Ce problème est résolu dans la version 1.28.100-gke.146 de Google Distributed Cloud. Solution Si vous ne pouvez pas mettre à niveau votre cluster vers la version 1.28.100-gke.146, procédez comme suit : Obtenez le nom converti de IPAddressPool : kubectl get IPAddressPools -n kube-system Mettez à jour le service concerné pour définir l'annotation metallb.universe.tf/address-pool sur le nom converti avec le hachage. Par exemple, si le nom IPAddressPool a été converti de default en un nom tel que default-qpvpd, remplacez l'annotation metallb.universe.tf/address-pool: default dans le service par metallb.universe.tf/address-pool: default-qpvpd. Le hachage utilisé dans la conversion de nom est déterministe. La solution de contournement est donc persistante.
Mises à niveau et mises à jour	1.14, 1.15, 1.16, 1.28, 1.29	Pods orphelins après la mise à niveau vers la version 1.14.x Lorsque vous mettez à niveau des clusters vers la version 1.14.x, certaines ressources de la version précédente ne sont pas supprimées. Plus précisément, vous pouvez voir un ensemble de pods orphelins comme suit : capi-webhook-system/capi-controller-manager-xxx capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx Ces objets orphelins n'ont pas d'incidence directe sur le fonctionnement du cluster, mais nous vous recommandons de les supprimer, car il s'agit d'une bonne pratique. Exécutez les commandes suivantes pour supprimer les objets orphelins : kubectl delete ns capi-webhook-system kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration Ce problème est résolu dans Google Distributed Cloud version 1.15.0 et ultérieure.
Installation	1,14	La création de cluster est bloquée sur le job machine-init Si vous essayez d'installer Google Distributed Cloud version 1.14.x, vous risquez de rencontrer un échec en raison des jobs machine-init, comme dans l'exemple de résultat suivant : "kubeadm join" task failed due to: error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members "kubeadm reset" task failed due to: panic: runtime error: invalid memory address or nil pointer dereference Solution : Supprimez le membre etcd obsolète qui provoque l'échec du job machine-init. Effectuez les étapes suivantes sur un nœud du plan de contrôle fonctionnel : Répertoriez les membres etcd existants : etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member list Recherchez les membres dont l'état est unstarted, comme indiqué dans l'exemple de résultat suivant : 5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false 99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false Supprimez le membre etcd défaillant : etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member remove MEMBER_ID Remplacez MEMBER_ID par l'ID du membre etcd défaillant. Dans l'exemple de résultat précédent, cet ID est bd1949bcb70e2cb5. L'exemple de résultat suivant montre que le membre a été supprimé : Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
Mise en réseau	1.28.0	Autorisations Cilium-operator et watch manquantes pour le nœud list Dans Cilium 1.13, les autorisations cilium-operator ClusterRole sont incorrectes. Les autorisations de nœud list et watch sont manquantes. Le cilium-operator ne parvient pas à démarrer les collecteurs de déchets, ce qui entraîne les problèmes suivants : Fuite de ressources Cilium. Les identités obsolètes ne sont pas supprimées des mappages de règles BFP. Les mappages de règles peuvent atteindre la limite de 16 000. Vous ne pouvez pas ajouter de nouvelles entrées. Application incorrecte de NetworkPolicy. Les identités peuvent atteindre la limite de 64 000. Vous ne pouvez pas créer de nouveaux pods. Un opérateur qui ne dispose pas des autorisations de nœud signale le message de journal d'exemple suivant : 2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s L'agent Cilium affiche un message d'erreur lorsqu'il ne parvient pas à insérer une entrée dans une carte de règles, comme dans l'exemple suivant : level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint Solution : Supprimez les identités Cilium, puis ajoutez les autorisations ClusterRole manquantes à l'opérateur : Supprimez les objets CiliumIdentity existants : kubectl delete ciliumid –-all Modifiez l'objet ClusterRole cilium-operator : kubectl edit clusterrole cilium-operator Ajoutez une section pour nodes qui inclut les autorisations manquantes, comme indiqué dans l'exemple suivant : - apiGroups: - "" resources: - nodes verbs: - get - list - watch Enregistrez et fermez l'éditeur. L'opérateur détecte dynamiquement le changement d'autorisation. Vous n'avez pas besoin de redémarrer l'opérateur manuellement.
Mises à niveau et mises à jour	1.15.0-1.15.7, 1.16.0-1.16.3	Problème temporaire rencontré lors de la vérification préliminaire L'une des tâches de vérification de l'état de l'état kubeadm qui s'exécute lors de la vérification préliminaire de la mise à niveau peut échouer avec le message d'erreur suivant : [ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found Vous pouvez ignorer cette erreur sans problème. Si vous rencontrez cette erreur qui bloque la mise à niveau, réexécutez la commande de mise à niveau. Si cette erreur s'affiche lorsque vous exécutez la vérification préliminaire à l'aide de la commande bmctl preflightcheck, rien n'est bloqué par cet échec. Vous pouvez exécuter à nouveau la vérification préliminaire pour obtenir des informations précises. Solution : Réexécutez la commande de mise à niveau ou, si l'erreur s'est produite lors de l'exécution de bmctl preflightcheck, réexécutez la commande preflightcheck.
Opération	1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0	Échec de la vérification d'état réseau périodique lorsqu'un nœud est remplacé ou supprimé Ce problème concerne les clusters qui effectuent des vérifications périodiques de l'état du réseau après le remplacement ou la suppression d'un nœud. Si votre cluster est soumis à des vérifications d'état périodiques, les résultats de la vérification de l'état du réseau périodique sont négatifs après le remplacement ou la suppression d'un nœud, car la ConfigMap de l'inventaire réseau n'est pas mise à jour une fois qu'elle est créée. Solution : La solution recommandée consiste à supprimer la ConfigMap d'inventaire et la vérification périodique de l'état du réseau. L'opérateur de cluster les recrée automatiquement avec les informations les plus récentes. Pour les clusters 1.14.x, exécutez les commandes suivantes : kubectl delete configmap \ $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ CLUSTER_NAME-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Pour les clusters 1.15.0 et versions ultérieures, exécutez les commandes suivantes : kubectl delete configmap \ $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ bm-system-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
Mise en réseau	1.14, 1.15, 1.16.0-1.16.2	Network Gateway for GDC ne peut pas appliquer votre configuration lorsque le nom de l'appareil contient un point. Si le nom d'un appareil réseau contient un point (.), comme bond0.2, la passerelle réseau pour GDC traite le point comme un chemin d'accès dans le répertoire lorsqu'elle exécute sysctl pour apporter des modifications. Lorsque la passerelle réseau pour GDC vérifie si la détection des adresses en double (DAD) est activée, la vérification peut échouer et la réconciliation ne sera donc pas effectuée. Le comportement varie selon les versions du cluster : 1.14 et 1.15 : cette erreur ne se produit que lorsque vous utilisez des adresses IP flottantes IPv6. Si vous n'utilisez pas d'adresses IP flottantes IPv6, ce problème ne se produira pas lorsque les noms de vos appareils contiennent un point. 1.16.0 à 1.16.2 : cette erreur se produit toujours lorsque le nom de vos appareils contient un point. Solution : Mettez à niveau votre cluster vers la version 1.16.3 ou ultérieure. En attendant de pouvoir mettre à niveau vos clusters, supprimez le point (.) du nom de l'appareil.
Mises à niveau et mises à jour, Mise en réseau, Sécurité	1.16.0	Les mises à niveau vers la version 1.16.0 échouent lorsque seccomp est désactivé Si seccomp est désactivé pour votre cluster (spec.clusterSecurity.enableSeccomp défini sur false), les mises à niveau vers la version 1.16.0 échouent. Google Distributed Cloud version 1.16 utilise Kubernetes version 1.27. Dans Kubernetes 1.27.0 et versions ultérieures, la fonctionnalité permettant de définir des profils seccomp est en disponibilité générale et n'utilise plus de feature gate. Cette modification de Kubernetes entraîne l'échec des mises à niveau vers la version 1.16.0 lorsque seccomp est désactivé dans la configuration du cluster. Ce problème est résolu dans les clusters version 1.16.1 et ultérieure. Si le champ cluster.spec.clusterSecurity.enableSeccomp est défini sur false, vous pouvez passer à la version 1.16.1 ou ultérieure. Les clusters dont la valeur spec.clusterSecurity.enableSeccomp n'est pas définie ou est définie sur true ne sont pas concernés.
Installation, fonctionnement	1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1	Les métadonnées containerd peuvent être corrompues après le redémarrage lorsque /var/lib/containerd est monté. Si vous avez monté /var/lib/containerd de manière facultative, les métadonnées containerd peuvent être corrompues après un redémarrage. Des métadonnées corrompues peuvent entraîner l'échec des pods, y compris des pods critiques pour le système. Pour vérifier si ce problème vous affecte, vérifiez si un montage facultatif est défini dans /etc/fstab pour /var/lib/containerd/ et comporte nofail dans les options de montage. Solution : Supprimez l'option de montage nofail dans /etc/fstab ou mettez à niveau votre cluster vers la version 1.15.6 ou ultérieure.
Opération	1.13, 1.14, 1.15, 1.16, 1.28	Nettoyer les pods obsolètes du cluster Il est possible que des pods gérés par un déploiement (ReplicaSet) soient dans l'état Failed et avec l'état TaintToleration. Ces pods n'utilisent pas de ressources de cluster, mais doivent être supprimés. Vous pouvez utiliser la commande kubectl suivante pour lister les pods que vous pouvez nettoyer : kubectl get pods –A | grep TaintToleration L'exemple de résultat suivant montre un pod avec l'état TaintToleration : kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 Solution : Pour chaque pod présentant les symptômes décrits, vérifiez le ReplicaSet auquel il appartient. Si le ReplicaSet est satisfait, vous pouvez supprimer les pods : Obtenez le ReplicaSet qui gère le pod et recherchez la valeur ownerRef.Kind : kubectl get pod POD_NAME -n NAMESPACE -o yaml Obtenez le ReplicaSet et vérifiez que status.replicas est identique à spec.replicas : kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml Si les noms correspondent, supprimez le pod : kubectl delete pod POD_NAME -n NAMESPACE.
Mises à niveau	1.16.0	etcd-events peut se bloquer lors de la mise à niveau vers la version 1.16.0 Lorsque vous mettez à niveau un cluster existant vers la version 1.16.0, les échecs de pod liés à etcd-events peuvent bloquer l'opération. Plus précisément, le job upgrade-node échoue à l'étape TASK [etcd_events_install : Run etcdevents]. Si vous êtes concerné par ce problème, des échecs de pods s'affichent comme suit : Le pod kube-apiserver ne démarre pas et renvoie l'erreur suivante : connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" Le pod etcd-events ne démarre pas et affiche l'erreur suivante : Error: error syncing endpoints with etcd: context deadline exceeded Solution : Si vous ne pouvez pas mettre à niveau votre cluster vers une version contenant le correctif, utilisez la solution de contournement temporaire suivante pour résoudre les erreurs : Utilisez SSH pour accéder au nœud du plan de contrôle présentant les erreurs signalées. Modifiez le fichier manifeste etcd-events, /etc/kubernetes/manifests/etcd-events.yaml, et supprimez l'indicateur initial-cluster-state=existing. Appliquez le fichier manifeste. La mise à niveau devrait se poursuivre.
Mise en réseau	1.15.0-1.15.2	orderPolicy CoreDNS non reconnu OrderPolicy n'est pas reconnu comme paramètre et n'est pas utilisé. Google Distributed Cloud utilise toujours Random. Ce problème se produit, car le modèle CoreDNS n'a pas été mis à jour, ce qui entraîne l'ignorance de orderPolicy. Solution : Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif est conservé jusqu'à une mise à niveau. 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 }}
Mise en réseau, fonctionnement	1.10, 1.11, 1.12, 1.13, 1.14	Composants de passerelle réseau pour GDC évincés ou en attente en raison d'une classe de priorité manquante Les pods de passerelle réseau à l'état kube-system peuvent afficher l'état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé suivant : $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h Ces erreurs indiquent des événements d'éviction ou l'impossibilité de planifier des pods en raison des ressources des nœuds. Comme les passerelles réseau pour les pods GDC n'ont pas de PriorityClass, elles ont la même priorité par défaut que les autres charges de travail. Lorsque les ressources des nœuds sont limitées, les pods de passerelle réseau peuvent être évincés. Ce comportement est particulièrement problématique pour le DaemonSet ang-node, car ces pods doivent être planifiés sur un nœud spécifique et ne peuvent pas migrer. Solution : Effectuez une mise à niveau vers la version 1.15 ou ultérieure. Pour résoudre le problème à court terme, vous pouvez attribuer manuellement une PriorityClass à la passerelle réseau pour les composants GDC. Le contrôleur Google Distributed Cloud écrase ces modifications manuelles lors d'un processus de réconciliation, par exemple lors d'une mise à niveau du cluster. Attribuez la PriorityClass system-cluster-critical aux déploiements de contrôleurs de cluster ang-controller-manager et autoscaler. Attribuez la PriorityClass system-node-critical au DaemonSet de nœud ang-daemon.
Installation, mises à niveau et mises à jour	1.15.0, 1.15.1, 1.15.2	Échec de la création et de la mise à niveau du cluster en raison de la longueur du nom du cluster La création de clusters version 1.15.0, 1.15.1 ou 1.15.2, ou la mise à niveau de clusters vers la version 1.15.0, 1.15.1 ou 1.15.2 échouent lorsque le nom du cluster comporte plus de 48 caractères (version 1.15.0) ou 45 caractères (version 1.15.1 ou 1.15.2). Lors des opérations de création et de mise à niveau de clusters, Google Distributed Cloud crée une ressource de vérification de l'état;état dont le nom inclut le nom et la version du cluster : Pour les clusters de la version 1.15.0, le nom de ressource de la vérification de l'état est CLUSTER_NAME-add-ons-CLUSTER_VER. Pour les clusters de version 1.15.1 ou 1.15.2, le nom de ressource de la vérification de l'état est CLUSTER_NAME-kubernetes-CLUSTER_VER. Pour les noms de cluster longs, le nom de la ressource de vérification de l'état de l'état dépasse la limite de 63 caractères imposée par Kubernetes pour les noms de libellés, ce qui empêche la création de la ressource de vérification de l'état de l'état. Si la vérification de l'état échoue, l'opération de cluster échoue également. Pour savoir si vous êtes concerné par ce problème, utilisez kubectl describe pour vérifier la ressource défaillante : kubectl describe healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG Si ce problème vous concerne, la réponse contient un avertissement pour un ReconcileError semblable à celui-ci : ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred: * failed to create job for health check db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch "bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters, spec.template.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters] Solution Pour débloquer la mise à niveau ou la création du cluster, vous pouvez ignorer le contrôle de l'état. Exécutez la commande suivante pour corriger la ressource personnalisée de vérification de l'état avec l'état "Réussite" : (status: {pass: true}) kubectl patch healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG --type=merge \ --subresource status --patch 'status: {pass: true}'
Mises à niveau et mises à jour	1.14, 1.15	Les clusters de versions 1.14.0 et 1.14.1 avec des fonctionnalités en preview ne peuvent pas être mis à niveau vers la version 1.15.x Si une fonctionnalité en preview est activée sur les clusters des versions 1.14.0 et 1.14.1, la mise à niveau vers la version 1.15.x est bloquée. Cela s'applique aux fonctionnalités en preview, comme la possibilité de créer un cluster sans kube-proxy, qui est activée avec l'annotation suivante dans le fichier de configuration du cluster : preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" Si vous êtes concerné par ce problème, une erreur semblable à celle-ci s'affiche lors de la mise à niveau du cluster : [2023-06-20 23:37:47+0000] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid: Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]: Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature isn't supported in 1.15.1 Anthos Bare Metal version Ce problème est résolu dans les clusters version 1.14.2 et ultérieure. Solution : Si vous ne parvenez pas à mettre à niveau vos clusters vers la version 1.14.2 ou ultérieure avant de passer à la version 1.15.x, vous pouvez passer directement à la version 1.15.x à l'aide d'un cluster bootstrap : bmctl upgrade cluster --use-bootstrap=true
Opération	1.15	Les clusters de la version 1.15 n'acceptent pas les adresses IP flottantes en double La passerelle réseau pour GDC ne vous permet pas de créer des ressources personnalisées NetworkGatewayGroup contenant des adresses IP dans spec.floatingIPs qui sont déjà utilisées dans des ressources personnalisées NetworkGatewayGroup existantes. Cette règle est appliquée par un webhook dans les clusters Bare Metal version 1.15.0 ou ultérieure. Les adresses IP flottantes en double préexistantes ne génèrent pas d'erreurs. Le webhook empêche uniquement la création de ressources personnalisées NetworkGatewayGroups contenant des adresses IP en double. Le message d'erreur du webhook identifie l'adresse IP en conflit et la ressource personnalisée existante qui l'utilise déjà : IP address exists in other gateway with name default La documentation initiale sur les fonctionnalités de mise en réseau avancées, telles que la passerelle NAT de sortie, ne met pas en garde contre les adresses IP en double. Au départ, seule la ressource NetworkGatewayGroup nommée default était reconnue par le réconciliateur. La passerelle réseau pour GDC reconnaît désormais toutes les ressources personnalisées NetworkGatewayGroup dans l'espace de noms système. Les ressources personnalisées NetworkGatewayGroup existantes sont respectées telles quelles. Solution : Les erreurs ne se produisent que lors de la création d'une ressource personnalisée NetworkGatewayGroup. Pour résoudre l'erreur : Utilisez la commande suivante pour lister les ressources personnalisées NetworkGatewayGroups : kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml Ouvrez les ressources personnalisées NetworkGatewayGroup existantes et supprimez les adresses IP flottantes en conflit (spec.floatingIPs) : kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system RESOURCE_NAME Pour appliquer vos modifications, fermez et enregistrez les ressources personnalisées modifiées.
Environnement d'exécution de VM sur GDC	1.13.7	Il est possible que les VM ne démarrent pas sur les clusters 1.13.7 qui utilisent un registre privé Lorsque vous activez VM Runtime sur GDC sur un nouveau cluster ou un cluster mis à niveau vers la version 1.13.7 qui utilise un registre privé, il est possible que les VM qui se connectent au réseau de nœuds ou qui utilisent un GPU ne démarrent pas correctement. Ce problème est dû à des erreurs d'extraction d'image pour certains pods système dans l'espace de noms vm-system. Par exemple, si votre VM utilise le réseau de nœuds, certains pods peuvent signaler des erreurs d'extraction d'image comme suit : macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m Ce problème est résolu dans les clusters version 1.14.0 et ultérieure. Solution Si vous ne parvenez pas à mettre à niveau vos clusters immédiatement, vous pouvez extraire les images manuellement. Les commandes suivantes extraient l'image du plug-in CNI macvtap pour votre VM et la transfèrent vers votre registre privé : docker pull \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker tag \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker push \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 Remplacez REG_HOST par le nom de domaine d'un hôte que vous mettez en miroir localement.
Installation	1.11, 1.12	Lors de la création d'un cluster dans le cluster kind, le pod gke-metric-agent ne démarre pas. Lors de la création du cluster dans le cluster kind, le pod gke-metrics-agent ne démarre pas en raison d'une erreur d'extraction d'image, comme suit : error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" De plus, l'entrée suivante s'affiche dans le journal containerd du cluster d'amorçage : Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" L'erreur "Échec de l'extraction" suivante s'affiche dans le pod : gcr.io/gke-on-prem-staging/gke-metrics-agent Solution Malgré les erreurs, le processus de création du cluster n'est pas bloqué, car l'objectif du pod gke-metrics-agent dans le cluster kind est de faciliter le taux de réussite de la création du cluster, ainsi que le suivi et la surveillance internes. Vous pouvez donc ignorer cette erreur. Solution Malgré les erreurs, le processus de création du cluster n'est pas bloqué, car l'objectif du pod gke-metrics-agent dans le cluster kind est de faciliter le taux de réussite de la création du cluster, ainsi que le suivi et la surveillance internes. Vous pouvez donc ignorer cette erreur.
Opérations, mise en réseau	1.12, 1.13, 1.14, 1.15, 1.16, 1.28	L'accès à un point de terminaison de service IPv6 provoque le plantage du nœud LoadBalancer sur CentOS ou RHEL Lorsque vous accédez à un service à double pile (un service qui possède des points de terminaison IPv4 et IPv6) et que vous utilisez le point de terminaison IPv6, le nœud LoadBalancer qui dessert le service peut planter. Ce problème concerne les clients qui utilisent des services à double pile avec CentOS ou RHEL et une version du noyau antérieure à kernel-4.18.0-372.46.1.el8_6. Si vous pensez que ce problème vous affecte, vérifiez la version du noyau sur le nœud LoadBalancer à l'aide de la commande uname -a. Solution : Mettez à jour le nœud LoadBalancer vers la version kernel-4.18.0-372.46.1.el8_6 ou ultérieure du noyau. Cette version du noyau est disponible par défaut dans CentOS et RHEL 8.6 et versions ultérieures.
Mise en réseau	1.11, 1.12, 1.13, 1.14.0	Problèmes de connectivité intermittents après le redémarrage du nœud Après le redémarrage d'un nœud, vous pouvez rencontrer des problèmes de connectivité intermittents pour un service NodePort ou LoadBalancer. Par exemple, vous pouvez rencontrer des erreurs intermittentes de handshake TLS ou de réinitialisation de la connexion. Ce problème est résolu pour les versions 1.14.1 et ultérieures des clusters. Pour vérifier si ce problème vous concerne, examinez les règles de transfert iptables sur les nœuds où le pod de backend du service concerné est en cours d'exécution : sudo iptables -L FORWARD Si la règle KUBE-FORWARD apparaît avant la règle CILIUM_FORWARD dans iptables, vous êtes peut-être concerné par ce problème. L'exemple de résultat suivant montre un nœud où le problème existe : Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */ CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ Solution : Redémarrez le pod anetd sur le nœud mal configuré. Après avoir redémarré le pod anetd, la règle de transfert dans iptables devrait être correctement configurée. L'exemple de résultat suivant montre que la règle CILIUM_FORWARD est désormais correctement configurée avant la règle KUBE-FORWARD : Chain FORWARD (policy ACCEPT) target prot opt source destination CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
Mises à niveau et mises à jour	1.9, 1.10	La fonctionnalité d'aperçu ne conserve pas les informations d'origine sur les autorisations et le propriétaire. La fonctionnalité d'aperçu du cluster 1.9.x utilisant bmctl 1.9.x ne conserve pas les informations d'autorisation et de propriétaire d'origine. Pour vérifier si vous êtes concerné par cette fonctionnalité, extrayez le fichier sauvegardé à l'aide de la commande suivante : tar -xzvf BACKUP_FILE Solution Vérifiez si metadata.json est présent et si bmctlVersion est défini sur 1.9.x. Si metadata.json n'est pas présent, passez à la version 1.10.x du cluster et utilisez bmctl 1.10.x pour la sauvegarde/restauration.
Mises à niveau et créations	1.14.2	clientconfig-operator bloqué à l'état "En attente" avec CreateContainerConfigError Si vous avez migré vers un cluster de version 1.14.2 ou en avez créé un avec une configuration OIDC/LDAP, il est possible que le pod clientconfig-operator soit bloqué à l'état "En attente". Dans ce cas, il existe deux pods clientconfig-operator, l'un en cours d'exécution et l'autre en attente. Ce problème ne concerne que les clusters de la version 1.14.2. Les versions antérieures des clusters, telles que 1.14.0 et 1.14.1, ne sont pas concernées. Ce problème est résolu dans la version 1.14.3 et toutes les versions ultérieures, y compris la version 1.15.0 et les versions ultérieures. Solution : Pour contourner ce problème, vous pouvez corriger le déploiement clientconfig-operator afin d'ajouter un contexte de sécurité supplémentaire et de vous assurer que le déploiement est prêt. Utilisez la commande suivante pour corriger clientconfig-operator dans le cluster cible : kubectl patch deployment clientconfig-operator -n kube-system \ -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \ --kubeconfig CLUSTER_KUBECONFIG Remplacez les éléments suivants : CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster cible.
Opération	1.11, 1.12, 1.13, 1.14, 1.15	Échec de la rotation de l'autorité de certification pour les clusters sans équilibrage de charge groupé Pour les clusters sans équilibrage de charge groupé (spec.loadBalancer.mode défini sur manual), la commande bmctl update credentials certificate-authorities rotate peut ne plus répondre et échouer avec l'erreur suivante : x509: certificate signed by unknown authority. Si vous êtes concerné par ce problème, la commande bmctl peut afficher le message suivant avant de ne plus répondre : Signing CA completed in 3/0 control-plane nodes Dans ce cas, la commande finit par échouer. Le journal rotate certificate-authority d'un cluster comportant trois plans de contrôle peut inclure des entrées telles que les suivantes : [2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK [2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK Signing CA completed in 0/0 control-plane nodes Signing CA completed in 1/0 control-plane nodes Signing CA completed in 2/0 control-plane nodes Signing CA completed in 3/0 control-plane nodes ... Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") Solution Si vous avez besoin d'aide supplémentaire, contactez l'assistance Google.
Installation, mise en réseau	1.11, 1.12, 1.13, 1.14.0-1.14.1	ipam-controller-manager Boucles de plantage dans les clusters à double pile Lorsque vous déployez un cluster à double pile (un cluster avec des adresses IPv4 et IPv6), le ou les pods ipam-controller-manager peuvent entrer dans une boucle de plantage. Ce comportement entraîne le cycle des nœuds entre les états Ready et NotReady, et peut entraîner l'échec de l'installation du cluster. Ce problème peut se produire lorsque le serveur d'API est soumis à une charge élevée. Pour savoir si ce problème vous concerne, vérifiez si le ou les pods ipam-controller-manager échouent avec des erreurs CrashLoopBackOff : kubectl -n kube-system get pods | grep ipam-controller-manager L'exemple de résultat suivant affiche des pods à l'état CrashLoopBackOff : ipam-controller-manager-h7xb8 0/1 CrashLoopBackOff 3 (19s ago) 2m ipam-controller-manager-vzrrf 0/1 CrashLoopBackOff 3 (19s ago) 2m1s ipam-controller-manager-z8bdw 0/1 CrashLoopBackOff 3 (31s ago) 2m2s Obtenez des informations sur le nœud à l'état NotReady : kubectl describe node <node-name> | grep PodCIDRs Dans un cluster présentant ce problème, aucun PodCIDR n'est attribué à un nœud, comme indiqué dans l'exemple de sortie suivant : PodCIDRs: Dans un cluster sain, tous les nœuds doivent avoir des PodCIDR à double pile qui leur sont attribués, comme le montre l'exemple de résultat suivant : PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 Solution : Redémarrez le ou les pods ipam-controller-manager : kubectl -n kube-system rollout restart ds ipam-controller-manager
Opération	1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 et 1.14	Pénurie de surveillance etcd Les clusters exécutant la version 3.4.13 ou antérieure d'etcd peuvent rencontrer des problèmes de famine de surveillance et de surveillance de ressources non opérationnelle, ce qui peut entraîner les problèmes suivants : La planification des pods est interrompue Les nœuds ne peuvent pas s'enregistrer kubelet n'observe pas les modifications apportées aux pods Ces problèmes peuvent rendre le cluster non fonctionnel. Ce problème est résolu dans les versions 1.12.9, 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 antérieures de Google Distributed Cloud sont concernées par ce problème. Solution Si vous ne pouvez pas effectuer la mise à niveau immédiatement, vous pouvez réduire le risque de défaillance du cluster en diminuant le nombre de nœuds dans votre cluster. Supprimez des nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mbit/s. Pour afficher cette métrique dans l'explorateur de métriques : Accédez à l'explorateur de métriques dans la console Google Cloud  : Accéder à l'explorateur de métriques Accédez à l'onglet Configuration. Développez le menu Sélectionner une métrique, saisissez Kubernetes Container dans la barre de filtre, puis utilisez les sous-menus pour sélectionner la métrique : Dans le menu Ressources actives, sélectionnez Conteneur Kubernetes. Dans le menu Catégories de métriques actives, sélectionnez Anthos. Dans le menu Métriques actives, sélectionnez etcd_network_client_grpc_sent_bytes_total. Cliquez sur Appliquer.
Mise en réseau	1.11.6, 1.12.3	État "Échec " du mode vfio-pci de l'opérateur SR-IOV L'syncStatus de l'objet SriovNetworkNodeState peut indiquer la valeur "Échec" pour un nœud configuré. Pour afficher l'état d'un nœud et déterminer si le problème vous concerne, exécutez la commande suivante : kubectl -n gke-operators get \ sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \ -o jsonpath='{.status.syncStatus}' Remplacez NODE_NAME par le nom du nœud à vérifier. Solution : Si l'état de l'objet SriovNetworkNodeState est "Échec", mettez à niveau votre cluster vers la version 1.11.7 ou ultérieure, ou vers la version 1.12.4 ou ultérieure.
Mises à niveau et mises à jour	1.10, 1.11, 1.12, 1.13, 1.14.0, 1.14.1	Certains nœuds de calcul ne sont pas à l'état "Prêt" après la mise à niveau Une fois la mise à niveau terminée, la condition "Prêt" de certains nœuds de calcul peut être définie sur false. Sur la ressource Node, une erreur s'affiche à côté de la condition "Ready" (Prêt), comme dans l'exemple suivant : container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized Lorsque vous vous connectez à la machine bloquée, la configuration CNI de la machine est vide : sudo ls /etc/cni/net.d/ Solution Redémarrez le pod anetd du nœud en le supprimant.
Mises à niveau et mises à jour, Sécurité	1.10	Plusieurs rotations de certificats à partir de cert-manager entraînent une incohérence Après plusieurs rotations manuelles ou automatiques des certificats, le pod de webhook, tel que anthos-cluster-operator, n'est pas mis à jour avec les nouveaux certificats émis par cert-manager. Toute mise à jour de la ressource personnalisée du cluster échoue et génère une erreur semblable à la suivante : Internal error occurred: failed calling webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "webhook-service.kube-system.svc") Ce problème peut se produire dans les cas suivants : Si vous avez effectué deux rotations manuelles de certificats émis par cert-manager sur un cluster datant de plus de 180 jours et que vous n'avez jamais redémarré anthos-cluster-operator. Si vous avez effectué des rotations manuelles de certificats cert-manager sur un cluster datant de 90 jours ou plus et que vous n'avez jamais redémarré anthos-cluster-operator. Solution Redémarrez le pod en arrêtant le anthos-cluster-operator.
Mises à niveau et mises à jour	1.14.0	Pods de déploiement du contrôleur de cycle de vie obsolètes créés lors de la mise à niveau du cluster d'utilisateur Dans les clusters d'administrateur de la version 1.14.0, un ou plusieurs pods de déploiement de contrôleur de cycle de vie obsolètes peuvent être créés lors de la mise à niveau des clusters d'utilisateur. Ce problème s'applique aux clusters d'utilisateur qui ont été initialement créés avec des versions antérieures à la version 1.12. Les pods créés involontairement n'empêchent pas les opérations de mise à niveau, mais ils peuvent se trouver dans un état inattendu. Nous vous recommandons de supprimer les pods obsolètes. Ce problème a été résolu dans la version 1.14.1. Solution : Pour supprimer les pods de déploiement du contrôleur de cycle de vie obsolètes : Lister les ressources de vérification préliminaire : kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A Le résultat ressemble à ceci : NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d où ci-87a021b9dcbb31c est le nom du cluster. Supprime les ressources dont la valeur dans la colonne "PASS" est true ou false. Par exemple, pour supprimer les ressources dans l'exemple de résultat précédent, utilisez les commandes suivantes : kubectl delete preflightchecks ci-87a021b9dcbb31c \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG
Mise en réseau	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	L'état BGPSession change constamment en raison du grand nombre de routes entrantes. La gestion avancée du réseau Google Distributed Cloud ne parvient pas à gérer correctement les sessions BGP lorsque des pairs externes annoncent un nombre élevé de routes (environ 100 ou plus). Avec un grand nombre de routes entrantes, le contrôleur BGP local au nœud met trop de temps à réconcilier les sessions BGP et ne parvient pas à mettre à jour l'état. L'absence de mises à jour de l'état ou de vérification de l'état;état entraîne la suppression de la session pour cause d'inactivité. Voici quelques exemples de comportements indésirables que vous pouvez observer dans les sessions BGP et qui peuvent indiquer un problème : Suppression et recréation continues de bgpsession. bgpsession.status.state ne devient jamais Established Routes qui ne sont pas annoncées ou qui sont annoncées et retirées de manière répétée. Les problèmes d'équilibrage de charge BGP peuvent se manifester par des problèmes de connectivité aux services LoadBalancer. Un problème lié à BGP FlatIP peut se manifester par des problèmes de connectivité aux pods. Pour déterminer si vos problèmes BGP sont dus à des pairs distants qui annoncent trop de routes, utilisez les commandes suivantes pour examiner les états et les résultats associés : Utilisez kubectl get bgpsessions sur le cluster concerné. La sortie affiche bgpsessions avec l'état "Not Established" (Non établi). La dernière heure de signalement augmente en continu jusqu'à environ 10 à 12 secondes avant de sembler revenir à zéro. Le résultat de kubectl get bgpsessions montre que les sessions concernées sont recréées de manière répétée : kubectl get bgpsessions \ -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}" Les messages du journal indiquent que les sessions BGP obsolètes sont supprimées : kubectl logs ang-controller-manager-POD_NUMBER Remplacez POD_NUMBER par le pod leader de votre cluster. Solution : Réduisez ou éliminez le nombre de routes annoncées par le pair distant au cluster à l'aide d'une règle d'exportation. Dans les versions 1.14.2 et ultérieures des clusters, vous pouvez également désactiver la fonctionnalité qui traite les routes reçues à l'aide d'un AddOnConfiguration. Ajoutez l'argument --disable-received-routes au conteneur bgpd du DaemonSet ang-daemon.
Mise en réseau	1.14, 1.15, 1.16, 1.28	Expirations de délai de l'application causées par les échecs d'insertion de la table conntrack Les clusters exécutés sur un système d'exploitation Ubuntu utilisant le noyau 5.15 ou une version ultérieure sont sensibles aux échecs d'insertion des tables Netfilter Connection Tracking (conntrack). Des échecs d'insertion peuvent se produire même lorsque la table conntrack dispose de place pour de nouvelles entrées. Les échecs sont dus à des modifications apportées au noyau 5.15 et aux versions ultérieures qui limitent les insertions de table en fonction de la longueur de chaîne. Pour savoir si vous êtes concerné par ce problème, vous pouvez vérifier les statistiques du système de suivi de la connexion au noyau à l'aide de la commande suivante : sudo conntrack -S La réponse ressemble à ce qui suit : cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 ... Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, vous êtes concerné par ce problème. Solution La solution à court terme consiste à augmenter la taille de la table de hachage netfilter (nf_conntrack_buckets) et de la table de suivi des connexions netfilter (nf_conntrack_max). Utilisez les commandes suivantes sur chaque nœud de cluster pour augmenter la taille des tables : sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE Remplacez TABLE_SIZE par la nouvelle taille en octets. La taille de tableau par défaut est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs du nœud. Par exemple, si votre nœud comporte huit cœurs, définissez la taille de la table sur 524288.
Mises à niveau et mises à jour	1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.5	Impossible de restaurer les sauvegardes de cluster avec bmctl pour certaines versions Nous vous recommandons de sauvegarder vos clusters avant de les mettre à niveau afin de pouvoir restaurer la version précédente en cas d'échec de la mise à niveau. Un problème lié à la commande bmctl restore cluster empêche la restauration des sauvegardes de clusters avec les versions identifiées. Ce problème est spécifique aux mises à niveau, où vous restaurez une sauvegarde d'une version antérieure. Si votre cluster est concerné, le journal bmctl restore cluster contient l'erreur suivante : Error: failed to extract image paths from profile: anthos version VERSION not supported Solution : En attendant que ce problème soit résolu, nous vous recommandons de suivre les instructions de la section Sauvegarder et restaurer des clusters pour sauvegarder et restaurer manuellement vos clusters, si nécessaire.
Mise en réseau	1.10, 1.11, 1.12, 1.13, 1.14.0-1.14.2	NetworkGatewayGroup plante s'il n'y a pas d'adresse IP sur l'interface. NetworkGatewayGroup ne parvient pas à créer des daemons pour les nœuds qui ne disposent pas d'interfaces IPv4 et IPv6. Cela entraîne l'échec de fonctionnalités telles que BGP LB et EgressNAT. Si vous consultez les journaux du pod ang-node en échec dans l'espace de noms kube-system, des erreurs semblables à l'exemple suivant s'affichent lorsqu'une adresse IPv6 est manquante : ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error": "creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""} Dans l'exemple précédent, aucune adresse IPv6 n'est associée à l'interface ens192. Des erreurs ARP similaires s'affichent si le nœud ne dispose pas d'adresse IPv4. NetworkGatewayGroup tente d'établir une connexion ARP et une connexion NDP à l'adresse IP locale de liaison. Si l'adresse IP n'existe pas (IPv4 pour ARP, IPv6 pour NDP), la connexion échoue et le daemon ne se poursuit pas. Ce problème a été résolu dans la version 1.14.3. Solution : Connectez-vous au nœud à l'aide de SSH et ajoutez une adresse IPv4 ou IPv6 au lien contenant l'adresse IP du nœud. Dans l'exemple d'entrée de journal précédent, cette interface était ens192 : ip address add dev INTERFACE scope link ADDRESS Remplacez les éléments suivants : INTERFACE : interface de votre nœud, telle que ens192. ADDRESS : adresse IP et masque de sous-réseau à appliquer à l'interface.
Réinitialisation/Suppression	1.10, 1.11, 1.12, 1.13.0-1.13.2	Boucle de plantage de anthos-cluster-operator lors de la suppression d'un nœud de plan de contrôle Lorsque vous essayez de supprimer un nœud de plan de contrôle en supprimant l'adresse IP du Cluster.Spec, le anthos-cluster-operator entre dans un état de boucle de plantage qui bloque toute autre opération. Solution : Ce problème a été résolu dans les versions 1.13.3 et 1.14.0 et ultérieures. Toutes les autres versions sont affectées. Passer à l'une des versions corrigées Pour contourner ce problème, exécutez la commande suivante : kubectl label baremetalmachine IP_ADDRESS \ -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply- Remplacez les éléments suivants : IP_ADDRESS : adresse IP du nœud en état de boucle de plantage. CLUSTER_NAMESPACE : espace de noms du cluster.
Installation	1.13.1, 1.13.2 et 1.13.3	Échec de kubeadm join dans les grands clusters en raison d'une inadéquation des jetons Lorsque vous installez des clusters avec un grand nombre de nœuds, un message d'erreur kubeadmin join semblable à l'exemple suivant peut s'afficher : TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] *** fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join --config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1, "start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n To see the stack trace of this error execute with --v=5 or higher", "stderr_lines": ["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"", "To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight] Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]} Solution : Ce problème est résolu dans Google Distributed Cloud version 1.13.4 et versions ultérieures. Si vous devez utiliser une version concernée, commencez par créer un cluster avec moins de 20 nœuds, puis redimensionnez-le pour ajouter des nœuds une fois l'installation terminée.
Journalisation et surveillance	1.10, 1.11, 1.12, 1.13.0	Limite de processeur faible pour metrics-server dans les clusters Edge Dans les clusters Google Distributed Cloud Edge, des limites de processeur basses pour metrics-server peuvent entraîner des redémarrages fréquents de metrics-server. L'autoscaling horizontal des pods (AHP) ne fonctionne pas, car metrics-server n'est pas sain. Si la limite de processeur metrics-server est inférieure à 40m, vos clusters peuvent être affectés. Pour vérifier les limites de processeur metrics-server, consultez l'un des fichiers suivants : Versions 1.x à 1.12 du cluster : kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml Versions 1.13 ou ultérieures du cluster : kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml Solution : Ce problème est résolu dans les versions de cluster 1.13.1 ou ultérieures. Pour résoudre ce problème, mettez à niveau vos clusters. En attendant de pouvoir mettre à niveau les clusters, vous pouvez augmenter manuellement les limites de processeur pour metrics-server comme suit : Réduisez la capacité de metrics-server-operator : kubectl scale deploy metrics-server-operator --replicas=0 Mettez à jour la configuration et augmentez les limites de processeur : Clusters versions 1.x à 1.12 : kubectl -n kube-system edit deployment metrics-server Clusters version 1.13 : kubectl -n gke-managed-metrics-server edit deployment metrics-server Supprimez la ligne --config-dir=/etc/config et augmentez les limites de processeur, comme indiqué dans l'exemple suivant : [...] - command: - /pod_nanny # - --config-dir=/etc/config # <--- Remove this line - --container=metrics-server - --cpu=50m # <--- Increase CPU, such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true [...] Enregistrez et fermez le fichier metrics-server pour appliquer les modifications.
Mise en réseau	1.14, 1.15, 1.16	La connexion NodePort directe à un pod hostNetwork ne fonctionne pas La connexion à un pod activé avec hostNetwork à l'aide du service NodePort échoue lorsque le pod de backend se trouve sur le même nœud que le NodePort cible. Ce problème affecte les services LoadBalancer lorsqu'ils sont utilisés avec des pods hostNetwork. Avec plusieurs backends, il peut y avoir un échec de connexion sporadique. Ce problème est dû à un bug dans le programme eBPF. Solution : Lorsque vous utilisez un service NodePort, ne ciblez pas le nœud sur lequel s'exécute l'un des pods de backend. Lorsque vous utilisez le service LoadBalancer, assurez-vous que les pods avec hostNetwork ne s'exécutent pas sur les nœuds LoadBalancer.
Mises à niveau et mises à jour	1.12.3, 1.13.0	Les clusters d'administrateur 1.13.0 ne peuvent pas gérer les clusters d'utilisateur 1.12.3 Les clusters d'administrateur exécutant la version 1.13.0 ne peuvent pas gérer les clusters d'utilisateur exécutant la version 1.12.3. Les opérations sur un cluster d'utilisateur en version 1.12.3 échouent. Solution : Mettez à niveau votre cluster d'administrateur vers la version 1.13.1 ou mettez à niveau le cluster d'utilisateur vers la même version que le cluster d'administrateur.
Mises à niveau et mises à jour	1.12	La mise à niveau vers la version 1.13.x est bloquée pour les clusters d'administrateur avec des pools de nœuds de calcul Les clusters d'administrateur de version 1.13.0 et ultérieure ne peuvent pas contenir de pools de nœuds de calcul. Les mises à niveau vers la version 1.13.0 ou ultérieure pour les clusters d'administrateur avec des pools de nœuds de calcul sont bloquées. Si la mise à niveau de votre cluster d'administrateur est bloquée, vous pouvez vérifier si les pools de nœuds de calcul sont à l'origine du problème en recherchant l'erreur suivante dans le fichier upgrade-cluster.log du dossier bmctl-workspace : Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed. Solution : Avant la mise à niveau, déplacez tous les pools de nœuds de calcul vers les clusters d'utilisateur. Pour savoir comment ajouter et supprimer des pools de nœuds, consultez Gérer les pools de nœuds dans un cluster.
Mises à niveau et mises à jour	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Erreurs lors de la mise à jour des ressources à l'aide de kubectl apply Si vous mettez à jour des ressources existantes telles que les ressources personnalisées ClientConfig ou Stackdriver à l'aide de kubectl apply, le contrôleur peut renvoyer une erreur ou annuler votre saisie et les modifications prévues. Par exemple, vous pouvez essayer de modifier la ressource personnalisée Stackdriver comme suit en récupérant d'abord la ressource, puis en appliquant une version mise à jour : Obtenez la définition YAML existante : kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML. Appliquez à nouveau le fichier YAML mis à jour : kubectl apply -f stackdriver.yaml C'est à la dernière étape de kubectl apply que vous risquez de rencontrer des problèmes. Solution : N'utilisez pas kubectl apply pour modifier des ressources existantes. Utilisez plutôt kubectl edit ou kubectl patch, comme indiqué dans les exemples suivants : Modifiez la ressource personnalisée Stackdriver : kubectl edit stackdriver -n kube-system stackdriver Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML. Enregistrer et quitter l'éditeur Autre approche utilisant kubectl patch : Obtenez la définition YAML existante : kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML. Appliquez à nouveau le fichier YAML mis à jour : kubectl patch stackdriver stackdriver --type merge \ -n kube-system --patch-file stackdriver.yaml
Journalisation et surveillance	1.12, 1.13, 1.14, 1.15, 1.16	Les blocs de backlog corrompus entraînent une boucle de plantage stackdriver-log-forwarder Le stackdriver-log-forwarder boucle sur les erreurs s'il tente de traiter un bloc de backlog corrompu. Les exemples d'erreurs suivants s'affichent dans les journaux de conteneur : [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks Lorsque cette boucle de plantage se produit, vous ne pouvez pas consulter les journaux dans Cloud Logging. Solution : Pour résoudre ces erreurs, procédez comme suit : Identifiez les blocs de backlog corrompus. Consultez les exemples de messages d'erreur suivants : [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks Dans cet exemple, le fichier tail.1/1-1659339894.252926599.flb stocké dans var/log/fluent-bit-buffers/tail.1/ est défectueux. Tous les fichiers *.flb dont le format n'a pas été validé doivent être supprimés. Arrêtez les pods en cours d'exécution pour stackdriver-log-forwarder : kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur. Vérifiez que les pods stackdriver-log-forwarder ont été supprimés avant de passer à l'étape suivante. Connectez-vous au nœud à l'aide de SSH sur lequel stackdriver-log-forwarder est en cours d'exécution. Sur le nœud, supprimez tous les fichiers *.flb corrompus dans var/log/fluent-bit-buffers/tail.1/. If there are too many corrupted files and you want to apply a script to clean up all backlog chunks, use the following scripts: Déployez un DaemonSet pour nettoyer toutes les données corrompues dans les tampons fluent-bit : kubectl --kubeconfig KUBECONFIG -n kube-system apply -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 Assurez-vous que le DaemonSet a nettoyé tous les nœuds. Le résultat des deux commandes suivantes doit être égal au nombre de nœuds du cluster : kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l Supprimez le DaemonSet de nettoyage : kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup Redémarrez les pods stackdriver-log-forwarder : kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
Mise en réseau, environnement d'exécution de VM sur GDC	1.14.0	Le redémarrage de Dataplane V2 (anetd) sur les clusters peut entraîner l'impossibilité pour les VM existantes de s'associer à un réseau autre que celui des pods. Sur les clusters à plusieurs cartes d'interface réseau, le redémarrage de Dataplane V2 (anetd) peut empêcher les machines virtuelles de se connecter aux réseaux. Une erreur semblable à la suivante peut être observée dans les journaux de pods anetd : could not find an allocator to allocate the IP of the multi-nic endpoint Solution : Vous pouvez redémarrer la VM pour résoudre rapidement le problème. Pour éviter que le problème ne se reproduise, mettez à niveau votre cluster vers la version 1.14.1 ou ultérieure.
Opération	1.13, 1.14.0, 1.14.1	gke-metrics-agent n'a pas de limite de mémoire sur les clusters de profil Edge En fonction de la charge de travail du cluster, le gke-metrics-agent peut utiliser plus de 4 608 Mio de mémoire. Ce problème n'affecte que les clusters de profil Edge Google Distributed Cloud pour Bare Metal. Les clusters de profils par défaut ne sont pas concernés. Solution : Mettez à niveau votre cluster vers la version 1.14.2 ou ultérieure.
Installation	1.12, 1.13	La création du cluster peut échouer en raison de conditions de concurrence Lorsque vous créez des clusters à l'aide de kubectl, il est possible que la vérification préliminaire ne se termine jamais en raison de conditions de concurrence. Par conséquent, la création de clusters peut échouer dans certains cas. Le rapprochement de vérification avant vol crée un SecretForwarder pour copier le secret ssh-key par défaut dans l'espace de noms cible. En règle générale, la vérification préliminaire s'appuie sur les références du propriétaire et effectue la réconciliation une fois que SecretForwarder est terminé. Toutefois, dans de rares cas, les références de propriétaire de SecretForwarder peuvent perdre la référence à la vérification préliminaire, ce qui bloque cette dernière. La création du cluster échoue alors. Pour poursuivre la réconciliation de la vérification préliminaire contrôlée par le contrôleur, supprimez le pod cluster-operator ou la ressource preflight-check. Lorsque vous supprimez la ressource de vérification avant vol, une autre est créée et la réconciliation se poursuit. Vous pouvez également mettre à niveau vos clusters existants (créés avec une version antérieure) vers une version corrigée.
Mise en réseau	1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Les adresses IP réservées ne sont pas libérées lorsque vous utilisez le plug-in "whereabouts" avec la fonctionnalité multi-NIC Dans la fonctionnalité multi-NIC, si vous utilisez le plug-in CNI whereabouts et l'opération CNI DEL pour supprimer une interface réseau pour un pod, il est possible que certaines adresses IP réservées ne soient pas libérées correctement. Cela se produit lorsque l'opération CNI DEL est interrompue. Vous pouvez vérifier les réservations d'adresses IP inutilisées des pods en exécutant la commande suivante : kubectl get ippools -A --kubeconfig KUBECONFIG_PATH Solution  : Supprimez manuellement les adresses IP (pools d'adresses IP) qui ne sont pas utilisées.
Installation	1.10, 1.11.0, 1.11.1, 1.11.2	Échec du détecteur de problèmes de nœuds dans le cluster d'utilisateur 1.10.4 Le détecteur de problèmes de nœuds peut échouer dans les clusters d'utilisateur de la version 1.10.x, lorsque les clusters d'administrateur des versions 1.11.0, 1.11.1 ou 1.11.2 gèrent les clusters d'utilisateur de la version 1.10.x. Lorsque le détecteur de problèmes de nœud échoue, le journal est mis à jour avec le message d'erreur suivant : Error - NPD not supported for anthos baremetal version 1.10.4: anthos version 1.10.4 not supported. Solution Pour résoudre le problème, mettez à niveau le cluster d'administrateur vers la version 1.11.3.
Opération	1,14	Les nœuds de cluster IPv4 en mode île 1.14 ont une taille de masque CIDR de pod de 24. Dans la version 1.14, le paramètre maxPodsPerNode n'est pas pris en compte pour les clusters en mode île. Les nœuds se voient donc attribuer une taille de masque CIDR de pod de 24 (256 adresses IP). Cela peut entraîner une pénurie d'adresses IP de pod plus tôt que prévu dans le cluster. Par exemple, si la taille du masque CIDR de pod de votre cluster est de 22, chaque nœud se verra attribuer un masque CIDR de pod de 24 et le cluster ne pourra accepter que quatre nœuds maximum. Votre cluster peut également rencontrer une instabilité du réseau en période de forte rotation des pods lorsque maxPodsPerNode est défini sur 129 ou plus et qu'il n'y a pas assez de marge dans le CIDR des pods pour chaque nœud. Ce problème n'affecte que les clusters IPv4 en mode île qui utilisent maxPodsPerNode en dehors de la plage de 65 à 128. Si votre cluster est concerné, le pod anetd signale l'erreur suivante lorsque vous ajoutez un nœud au cluster et qu'aucun podCIDR n'est disponible : error="required IPv4 PodCIDR not available" Solution Pour résoudre le problème, procédez comme suit : Effectuez une mise à niveau vers la version 1.14.1 ou une version ultérieure. Supprimez les nœuds de calcul, puis ajoutez-les à nouveau. Supprimez les nœuds du plan de contrôle et ajoutez-les à nouveau, de préférence un par un pour éviter les temps d'arrêt du cluster.
Mises à niveau et mises à jour	1.14.0, 1.14.1	Échec du rollback de la mise à niveau du cluster Le rollback d'une mise à niveau peut échouer pour les clusters en version 1.14.0 ou 1.14.1. Si vous mettez à niveau un cluster de la version 1.14.0 vers la version 1.14.1, puis que vous essayez de revenir à la version 1.14.0 à l'aide de la commande bmctl restore cluster, une erreur semblable à l'exemple suivant peut être renvoyée : I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff. Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io" denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid: Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690), Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil), CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable Solution : Supprimez toutes les ressources healthchecks.baremetal.cluster.gke.io sous l'espace de noms du cluster, puis réexécutez la commande bmctl restore cluster : Répertoriez toutes les ressources healthchecks.baremetal.cluster.gke.io : kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Remplacez les éléments suivants : CLUSTER_NAMESPACE : espace de noms du cluster. ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. Supprimez toutes les ressources healthchecks.baremetal.cluster.gke.io listées à l'étape précédente : kubectl delete healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_RESOURCE_NAME \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG Remplacez HEALTHCHECK_RESOURCE_NAME par le nom des ressources de vérification de l'état de santé. Exécutez à nouveau la commande bmctl restore cluster.
Mise en réseau	1.12.0	L'adresse IP externe du service ne fonctionne pas en mode plat Dans un cluster où flatIPv4 est défini sur true, les services de type LoadBalancer ne sont pas accessibles par leurs adresses IP externes. Ce problème est résolu dans la version 1.12.1. Solution : Dans le ConfigMap cilium-config, définissez enable-415 sur "true", puis redémarrez les pods anetd.
Mises à niveau et mises à jour	1.13.0, 1.14	Les mises à niveau sur place de la version 1.13.0 vers la version 1.14.x ne se terminent jamais Lorsque vous essayez d'effectuer une mise à niveau sur place de la version 1.13.0 vers la version 1.14.x à l'aide de bmctl 1.14.0 et de l'indicateur --use-bootstrap=false, la mise à niveau ne se termine jamais. Une erreur avec l'opérateur preflight-check empêche le cluster de planifier les vérifications requises, ce qui signifie que la vérification préliminaire ne se termine jamais. Solution : Passez d'abord à la version 1.13.1 avant de passer à la version 1.14.x. Une mise à niveau sur place de la version 1.13.0 vers la version 1.13.1 devrait fonctionner. Vous pouvez également passer de la version 1.13.0 à la version 1.14.x sans l'indicateur --use-bootstrap=false.
Mises à niveau et mises à jour, Sécurité	1.13 et 1.14	Les clusters mis à niveau vers la version 1.14.0 perdent les taints du maître Les nœuds du plan de contrôle nécessitent l'un des deux rejets spécifiques pour empêcher la planification des pods de charge de travail sur ces nœuds. Lorsque vous mettez à niveau des clusters de version 1.13 vers la version 1.14.0, les nœuds du plan de contrôle perdent les taintings requis suivants : node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule Remarque : Les clusters autogérés, tels que les clusters autonomes, utilisent la contamination PreferNoSchedule par défaut. Ce problème n'entraîne pas d'échec de la mise à niveau, mais des pods qui ne sont pas censés s'exécuter sur les nœuds du plan de contrôle peuvent commencer à le faire. Ces pods de charge de travail peuvent submerger les nœuds du plan de contrôle et entraîner l'instabilité du cluster. Déterminer si vous êtes concerné Pour trouver les nœuds du plan de contrôle, utilisez la commande suivante : kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH Pour vérifier la liste des rejets sur un nœud, utilisez la commande suivante : kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH Si aucun des taints requis n'est listé, vous êtes concerné. Solution Procédez comme suit pour chaque nœud de plan de contrôle de votre cluster version 1.14.0 concerné afin de restaurer le bon fonctionnement. Ces étapes concernent le taint node-role.kubernetes.io/master:NoSchedule et les pods associés. Si vous souhaitez que les nœuds du plan de contrôle utilisent le taint PreferNoSchedule, ajustez les étapes en conséquence. Afficher la procédure de contournement Appliquez le rejet manquant : kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH Recherchez les pods sans tolérance node-role.kubernetes.io/master:NoSchedule : kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq Supprimez les pods qui ne présentent pas la tolérance node-role.kubernetes.io/master:NoSchedule : kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Opération, environnement d'exécution de VM sur GDC	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31	Échec intermittent de la création de VM avec des erreurs d'importation La création d'une machine virtuelle (VM) avec la commande kubectl virt create vm échoue parfois lors de l'importation d'images. Ce problème s'applique aux VM Linux et Windows. L'erreur se présente comme suit : PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready Uploading data to https://10.200.0.51 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s fail to upload image: unexpected return value 500, ... Solution Relancez la commande kubectl virt create vm pour créer votre VM.
Mises à niveau et mises à jour, Journalisation et surveillance	1.11	Les composants de la collection gérée dans les clusters 1.11 ne sont pas conservés lors de la mise à niveau vers la version 1.12. Les composants de la collecte gérée font partie de Managed Service pour Prometheus. Si vous avez déployé manuellement des composants de collection gérée dans l'espace de noms gmp-system de vos clusters version 1.11, les ressources associées ne sont pas conservées lorsque vous passez à la version 1.12. À partir des clusters de la version 1.12.0, les composants Managed Service pour Prometheus dans l'espace de noms gmp-system et les définitions de ressources personnalisées associées sont gérés par stackdriver-operator avec le champ enableGMPForApplications. Le champ enableGMPForApplications est défini par défaut sur true. Par conséquent, si vous déployez manuellement des composants Managed Service pour Prometheus dans l'espace de noms avant de passer à la version 1.12, les ressources sont supprimées par stackdriver-operator. Solution Pour conserver les ressources de la collecte gérée manuellement : Sauvegardez toutes les ressources personnalisées PodMonitoring existantes. Mettez à niveau le cluster vers la version 1.12 et activez Managed Service pour Prometheus. Redéployez les ressources personnalisées PodMonitoring sur votre cluster mis à niveau.
Mises à niveau et mises à jour	1.13	Certains clusters de version 1.12 avec l'environnement d'exécution de conteneur Docker ne peuvent pas être mis à niveau vers la version 1.13. Si un cluster de version 1.12 qui utilise l'environnement d'exécution de conteneur Docker ne comporte pas l'annotation suivante, il ne peut pas passer à la version 1.13 : baremetal.cluster.gke.io/allow-docker-container-runtime: "true" Si vous êtes concerné par ce problème, bmctl écrit l'erreur suivante dans le fichier upgrade-cluster.log du dossier bmctl-workspace : Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook "vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources. Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file. Cela se produit le plus souvent avec les clusters Docker de version 1.12 qui ont été mis à niveau à partir de la version 1.11, car cette mise à niveau ne nécessite pas l'annotation pour conserver l'environnement d'exécution de conteneur Docker. Dans ce cas, les clusters ne comportent pas l'annotation lors de la mise à niveau vers la version 1.13. Notez qu'à partir de la version 1.13, containerd est le seul environnement d'exécution de conteneurs autorisé. Solution : Si vous êtes concerné par ce problème, mettez à jour la ressource de cluster avec l'annotation manquante. Vous pouvez ajouter l'annotation pendant l'exécution de la mise à niveau, ou après l'avoir annulée et avant de réessayer.
Installation	1.11	bmctl se ferme avant la fin de la création du cluster La création du cluster peut échouer pour Google Distributed Cloud version 1.11.0 (ce problème est résolu dans Google Distributed Cloud version 1.11.1). Dans certains cas, la commande bmctl create cluster se ferme tôt et écrit des erreurs telles que les suivantes dans les journaux : Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster Solution L'opération ayant échoué produit des artefacts, mais le cluster n'est pas opérationnel. Si ce problème vous concerne, procédez comme suit pour nettoyer les artefacts et créer un cluster : Afficher la procédure de contournement Pour supprimer les artefacts de cluster et réinitialiser la machine à nœuds, exécutez la commande suivante : bmctl reset -c USER_CLUSTER_NAME Pour lancer l'opération de création de cluster, exécutez la commande suivante : bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster L'option --keep-bootstrap-cluster est importante si cette commande échoue. Si la commande de création de cluster réussit, vous pouvez ignorer les étapes restantes. Sinon, continuez. Exécutez la commande suivante pour obtenir la version du cluster d'amorçage : kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} Le résultat doit être 1.11.0. Si le résultat 1.11.0 ne s'affiche pas, attendez une ou deux minutes, puis réessayez. Pour déplacer manuellement les ressources du cluster d'amorçage vers le cluster cible, exécutez la commande suivante : bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE Pour supprimer le cluster d'amorçage, exécutez la commande suivante : bmctl reset bootstrap
Installation, environnement d'exécution de VM sur GDC	1.11, 1.12	Erreur de rapprochement de l'environnement d'exécution de VM lors de l'installation L'opération de création de cluster peut signaler une erreur semblable à la suivante : I0423 01:17:20.895640 3935589 logs.go:82] "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError" Solution Cette erreur est bénigne et vous pouvez l'ignorer en toute sécurité.
Installation	1.10, 1.11, 1.12	Échec de la création du cluster lors de l'utilisation de plusieurs cartes d'interface réseau, de containerd et d'un proxy HTTP La création du cluster échoue lorsque vous disposez de la combinaison de conditions suivante : Le cluster est configuré pour utiliser containerd comme environnement d'exécution de conteneur (nodeConfig.containerRuntime défini sur containerd dans le fichier de configuration du cluster, qui est la valeur par défaut pour Google Distributed Cloud version 1.13 et ultérieure). Le cluster est configuré pour fournir plusieurs interfaces réseau, avec plusieurs cartes d'interface réseau, pour les pods (clusterNetwork.multipleNetworkInterfaces défini sur true dans le fichier de configuration du cluster). Le cluster est configuré pour utiliser un proxy (spec.proxy.url est spécifié dans le fichier de configuration du cluster). Même si la création du cluster échoue, ce paramètre est propagé lorsque vous essayez de créer un cluster. Vous pouvez voir ce paramètre proxy en tant que variable d'environnement HTTPS_PROXY ou dans votre configuration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf). Solution Ajoutez les CIDR de service (clusterNetwork.services.cidrBlocks) à la variable d'environnement NO_PROXY sur toutes les machines de nœud.
Installation	1.10, 1.11, 1.12	Échec sur les systèmes dotés du paramètre umask restrictif La version 1.10.0 de Google Distributed Cloud a introduit une fonctionnalité de plan de contrôle sans racine qui exécute tous les composants du plan de contrôle en tant qu'utilisateur non racine. L'exécution de tous les composants en tant qu'utilisateur non racine peut entraîner des pannes lors de l'installation ou d'une mise à niveau sur les systèmes dotés d'un paramètre umask plus restrictif de 0077. Solution Réinitialisez les nœuds du plan de contrôle et remplacez le paramètre umask par 0022 sur tous les systèmes du plan de contrôle. Une fois les systèmes mis à jour, relancez l'installation. Vous pouvez également modifier les autorisations des répertoires et des fichiers de /etc/kubernetes sur les machines du plan de contrôle pour que l'installation ou la mise à niveau aboutisse. Rendez /etc/kubernetes et tous ses sous-répertoires lisibles publiquement : chmod o+rx. Rendez tous les fichiers appartenant à l'utilisateur root dans le répertoire (de manière récursive) /etc/kubernetes lisibles publiquement (chmod o+r). Excluez les fichiers de clé privée (.key) de ces modifications, car ils ont déjà été créés avec les autorisations et la propriété appropriées. Rendez /usr/local/etc/haproxy/haproxy.cfg lisible publiquement. Rendez /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml lisible publiquement.
Installation	1.10, 1.11, 1.12, 1.13	Incompatibilité du groupe de contrôle v2 Le groupe de contrôle v2 (cgroup v2) n'est pas compatible avec les versions 1.13 et antérieures de Google Distributed Cloud. Toutefois, la version 1.14 est compatible avec cgroup v2 en tant que fonctionnalité Preview . La présence de /sys/fs/cgroup/cgroup.controllers indique que votre système utilise cgroup v2. Solution Si votre système utilise cgroup v2, mettez à niveau votre cluster vers la version 1.14.
Installation	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29	Vérifications préliminaires et identifiants du compte de service Pour les installations déclenchées par des clusters d'administrateur ou hybrides (autrement dit, des clusters qui n'ont pas été créés avec bmctl, comme les clusters d'utilisateurs), la vérification préalable ne vérifie pas les identifiants du compte de service Google Cloud ni les autorisations qui leur sont associées.
Installation	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Installer sur vSphere Lorsque vous installez des clusters Bare Metal sur des VM vSphere, vous devez désactiver les options tx-udp_tnl-segmentation et tx-udp_tnl-csum-segmentation. Ces options sont liées au déchargement de la segmentation matérielle effectué par le pilote vSphere VMXNET3 et ne fonctionnent pas avec le tunnel GENEVE des clusters Bare Metal. Solution Exécutez la commande suivante sur chaque nœud pour vérifier les valeurs actuelles de ces options : ethtool -k NET_INTFC | grep segm Remplacez NET_INTFC par l'interface réseau associée à l'adresse IP du nœud. La réponse doit comporter des entrées semblables à celles-ci : ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Parfois, dans RHEL 8.4, ethtool indique que ces options sont désactivées alors qu'elles ne le sont pas. Pour les désactiver explicitement, activez-les, puis désactivez-les à l'aide des commandes suivantes : ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \ tx-udp_tnl-csum-segmentation on ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \ tx-udp_tnl-csum-segmentation off Cette modification d'option ne persiste pas lors des redémarrages. Configurez les scripts de démarrage pour définir explicitement ces options au démarrage du système.
Mises à niveau et mises à jour	1.10	bmctl ne peut pas créer, mettre à jour ni réinitialiser des clusters d'utilisateur de version inférieure La CLI bmctl ne peut pas créer, mettre à jour ni réinitialiser un cluster d'utilisateur avec une version mineure inférieure, quelle que soit la version du cluster d'administrateur. Par exemple, vous ne pouvez pas utiliser bmctl avec une version de 1.N.X pour réinitialiser un cluster d'utilisateur de la version 1.N-1.Y, même si le cluster d'administrateur est également en version 1.N.X. Si vous êtes concerné par ce problème, vous devriez voir les journaux semblables à l'exemple suivant lorsque vous utilisez bmctl : [2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: * cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported Solution : Utilisez kubectl pour créer, modifier ou supprimer la ressource personnalisée du cluster d'utilisateur dans le cluster d'administrateur. La mise à niveau des clusters d'utilisateur n'est pas affectée.
Mises à niveau et mises à jour	1.12	Les mises à niveau de clusters vers la version 1.12.1 peuvent être bloquées La mise à niveau des clusters vers la version 1.12.1 est parfois bloquée, car le serveur d'API devient indisponible. Ce problème affecte tous les types de clusters et tous les systèmes d'exploitation compatibles. Lorsque ce problème se produit, la commande bmctl upgrade cluster peut échouer à plusieurs reprises, y compris lors de la deuxième phase des vérifications préliminaires. Solution Vous pouvez consulter vos journaux de mise à niveau pour déterminer si vous êtes concerné par ce problème. Les journaux de mise à niveau se trouvent dans /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP par défaut. Le champ upgrade-cluster.log peut contenir des erreurs telles que les suivantes : Failed to upgrade cluster: preflight checks failed: preflight check failed Le journal de l'ordinateur peut contenir des erreurs telles que les suivantes (les échecs répétés indiquent que vous êtes concerné par ce problème) : FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left). FAILED - RETRYING: Query CNI health endpoint (28 retries left). ... HAProxy et Keepalived doivent être en cours d'exécution sur chaque nœud du plan de contrôle avant que vous ne tentiez à nouveau de mettre à niveau votre cluster vers la version 1.12.1. Utilisez l' interface de ligne de commande crictl sur chaque nœud pour vérifier si les conteneurs haproxy et keepalived sont en cours d'exécution : docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived Si HAProxy ou Keepalived ne s'exécutent pas sur un nœud, redémarrez kubelet sur le nœud : systemctl restart kubelet
Mises à niveau et mises à jour, environnement d'exécution de VM sur GDC	1.11, 1.12	La mise à niveau des clusters vers la version 1.12.0 ou ultérieure échoue lorsque l'environnement d'exécution de VM sur GDC est activé Dans les clusters de version 1.12.0, toutes les ressources liées à l'environnement d'exécution de VM sur GDC sont migrées vers l'espace de noms vm-system pour mieux prendre en charge la version DG de l'environnement d'exécution de VM sur GDC. Si vous avez activé l'environnement d'exécution des VM sur GDC dans un cluster de version 1.11.x ou antérieure, la mise à niveau vers la version 1.12.0 ou ultérieure échoue, sauf si vous désactivez d'abord l'environnement d'exécution des VM sur GDC. Lorsque vous êtes concerné par ce problème, l'opération de mise à niveau signale l'erreur suivante : Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version Solution Pour désactiver l'environnement d'exécution de VM sur GDC : Modifiez la ressource personnalisée VMRuntime : kubectl edit vmruntime Définissez enabled sur false dans la spécification: apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... Enregistrez la ressource personnalisée dans votre éditeur. Une fois la mise à niveau du cluster terminée, réactivez l'environnement d'exécution de VM sur GDC. Pour en savoir plus, consultez Activer ou désactiver l'environnement d'exécution de VM sur GDC.
Mises à niveau et mises à jour	1.10, 1.11, 1.12	Mise à niveau bloquée à error during manifests operations Dans certains cas, les mises à niveau de cluster échouent et la CLI bmctl ne répond plus. Ce problème peut être causé par une ressource mal mise à jour. Pour savoir si vous êtes concerné par ce problème et le résoudre, consultez les journaux anthos-cluster-operator et recherchez des erreurs semblables aux entrées suivantes : controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update Ces entrées sont des symptômes d'une ressource mal mise à jour, où {RESOURCE_NAME} est le nom de la ressource problématique. Solution Si ces erreurs s'affichent dans vos journaux, procédez comme suit : Utilisez kubectl edit pour supprimer l'annotation kubectl.kubernetes.io/last-applied-configuration de la ressource contenue dans le message de journal. Enregistrez et appliquez vos modifications à la ressource. Réessayez d'effectuer la mise à niveau du cluster.
Mises à niveau et mises à jour	1.10, 1.11, 1.12	Les mises à niveau sont bloquées pour les clusters dotés de fonctionnalités qui utilisent Network Gateway pour GDC Les mises à niveau des clusters 1.10.x vers 1.11.x échouent pour les clusters qui utilisent une passerelle NAT de sortie ou un équilibrage de charge groupé avec BGP. Ces fonctionnalités utilisent la passerelle réseau pour GDC. Les mises à niveau des clusters sont bloquées au message de ligne de commande Waiting for upgrade to complete... et les erreurs de journal anthos-cluster-operator se présentent comme suit : apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... Solution Attention : La solution de contournement suivante supprime les fichiers manifestes et provoque un bref temps d'arrêt de 30 à 60 secondes pour l'équilibrage de charge groupé avec BGP. Les sessions BGP sont supprimées et rétablies, et les services LoadBalancer ne sont pas disponibles pendant cette période. La fonction est restaurée lorsque anthos-cluster-operator réinstalle les fichiers manifestes. Pour débloquer la mise à niveau, exécutez les commandes suivantes sur le cluster que vous mettez à niveau : kubectl -n kube-system delete deployment \ ang-controller-manager-autoscaler kubectl -n kube-system delete deployment \ ang-controller-manager kubectl -n kube-system delete ds ang-node
Mises à niveau et mises à jour	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	bmctl update ne supprime pas les blocs de maintenance La commande bmctl update ne peut ni supprimer ni modifier la section maintenanceBlocks de la configuration des ressources du cluster. Solution Pour en savoir plus, y compris sur les instructions concernant la suppression de nœuds du mode de maintenance, consultez la section Passer des nœuds en mode de maintenance.
Opération	1.10, 1.11, 1.12	Nœuds non ordonnés si vous n'utilisez pas la procédure de mode de maintenance Si vous exécutez des clusters version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou antérieure et que vous utilisez manuellement kubectl cordon sur un nœud, Google Distributed Cloud pour Bare Metal peut dissocier ce nœud avant que vous soyez prêt dans le but de rapprocher l'état attendu. Solution Pour les clusters en version 1.12.0 ou antérieure, utilisez le mode de maintenance pour réordonner et drainer les nœuds en toute sécurité. Dans la version 1.12.1 (anthosBareMetalVersion: 1.12.1) ou ultérieure, Google Distributed Cloud pour Bare Metal ne dissociera pas vos nœuds de manière inattendue lorsque vous utiliserez kubectl cordon.
Opération	1.11	Les clusters d'administrateur de la version 11 utilisant un miroir de registre ne peuvent pas gérer les clusters de la version 1.10 Si votre cluster d'administrateur est de version 1.11 et utilise un miroir de registre, il ne peut pas gérer de clusters d'utilisateur utilisant une version mineure inférieure. Ce problème affecte les opérations de réinitialisation, de mise à jour et de mise à niveau sur le cluster d'utilisateur. Pour déterminer si ce problème vous concerne, consultez vos journaux pour les opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation. Ces journaux se trouvent par défaut dans le dossier bmctl-workspace/CLUSTER_NAME/. Si vous êtes concerné par ce problème, vos journaux contiennent le message d'erreur suivant : flag provided but not defined: -registry-mirror-host-to-endpoints
Opération	1.10, 1.11	Secret kubeconfig écrasé Lorsqu'elle est exécutée sur des clusters d'utilisateur, la commande bmctl check cluster remplace le secret kubeconfig du cluster d'utilisateur par celui du cluster d'administrateur. L'écrasement du fichier entraîne l'échec des opérations de cluster standards, telles que les mises à jour et les mises à niveau, pour les clusters d'utilisateur concernés. Ce problème s'applique aux versions 1.11.1 et antérieures des clusters. Pour déterminer si ce problème affecte un cluster d'utilisateur, exécutez la commande suivante : kubectl --kubeconfig ADMIN_KUBECONFIG \ get secret -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME -kubeconfig \ -o json | jq -r '.data.value' | base64 -d Remplacez les éléments suivants : ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. USER_CLUSTER_NAMESPACE : espace de noms du cluster. Par défaut, les noms des espaces de noms de cluster correspondent au nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms par défaut est cluster-test. USER_CLUSTER_NAME : nom du cluster d'utilisateur à vérifier. Si le nom du cluster dans la sortie (voir contexts.context.cluster dans l'exemple de sortie suivant) correspond au nom du cluster d'administrateur, le cluster d'utilisateur spécifié est concerné. apiVersion: v1 clusters: - cluster: certificate-authority-data:LS0tLS1CRU...UtLS0tLQo= server: https://10.200.0.6:443 name: ci-aed78cdeca81874 contexts: - context: cluster: ci-aed78cdeca81 user: ci-aed78cdeca81-admin name: ci-aed78cdeca81-admin@ci-aed78cdeca81 current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81 kind: Config preferences: {} users: - name: ci-aed78cdeca81-admin user: client-certificate-data: LS0tLS1CRU...UtLS0tLQo= client-key-data: LS0tLS1CRU...0tLS0tCg== Solution Les étapes suivantes permettent de restaurer une fonction sur un cluster d'utilisateur concerné (USER_CLUSTER_NAME) : Localisez le fichier kubeconfig du cluster d'utilisateur. Google Distributed Cloud pour Bare Metal génère le fichier kubeconfig sur le poste de travail administrateur lorsque vous créez un cluster. Par défaut, le fichier se trouve dans le répertoire bmctl-workspace/USER_CLUSTER_NAME. Vérifiez que le fichier kubeconfig du cluster d'utilisateur est correct : kubectl get nodes \ --kubeconfig PATH_TO_GENERATED_FILE Remplacez PATH_TO_GENERATED_FILE par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur. La réponse renvoie des informations sur les nœuds du cluster d'utilisateur. Vérifiez que les noms de machine sont corrects pour votre cluster. Exécutez la commande suivante pour supprimer le fichier kubeconfig corrompu dans le cluster d'administrateur : kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig Exécutez la commande suivante pour enregistrer le secret kubeconfig approprié dans le cluster d'administrateur : kubectl create secret generic \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
Opération	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30	Prendre un instantané en tant qu'utilisateur de connexion non racine Si vous utilisez containerd en tant qu'environnement d'exécution du conteneur, l'exécution d'un instantané en tant qu'utilisateur non racine nécessite que /usr/local/bin se trouve dans le chemin d'accès à l'utilisateur. Sinon, l'opération échoue avec une erreur crictl: command not found. Lorsque vous n'êtes pas connecté en tant qu'utilisateur racine, sudo permet d'exécuter les commandes de l'instantané. Le chemin d'accès sudo peut différer du profil racine et peut ne pas contenir /usr/local/bin. Solution Mettez à jour secure_path dans /etc/sudoers pour inclure /usr/local/bin. Vous pouvez également créer un lien symbolique pour crictl dans un autre répertoire /bin.
Journalisation et surveillance	1.10	stackdriver-log-forwarder comporte [parser:cri] invalid time format journaux d'avertissement Si l'analyseur d'interface d'exécution de conteneur (CRI, Container runtime interface) utilise une expression régulière incorrecte pour l'analyse, les journaux du pod stackdriver-log-forwarder contiennent des erreurs et des avertissements semblables aux suivants : [2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' Solution : Afficher la procédure de contournement Mettez à niveau votre cluster vers la version 1.11.0 ou ultérieure. Si vous ne parvenez pas à mettre à niveau vos clusters immédiatement, procédez comme suit pour mettre à jour l'expression régulière d'analyse CRI : Pour empêcher l'annulation des modifications suivantes, effectuez un scaling à la baisse de stackdriver-operator : kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 Modifiez l'entrée Regex dans le fichier ConfigMap stackdriver-log-forwarder-config : kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config Votre ressource modifiée doit ressembler à ce qui suit : [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off Redémarrez les pods du transfert de journaux : kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
Journalisation et surveillance	1.10, 1.11, 1.12, 1.13, 1.14, 1.15	Facturation de la surveillance inattendue  Pour les versions de cluster 1.10 à 1.15, certains clients ont trouvé une facturation inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que si toutes les conditions suivantes sont remplies : La surveillance des applications est activée (enableStackdriverForApplications=true). Managed Service pour Prometheus n'est pas activé (enableGMPForApplications) Les pods d'application comportent l'annotation prometheus.io/scrap=true. Pour vérifier si vous êtes concerné par ce problème, répertoriez vos métriques définies par l'utilisateur. Si vous constatez une facturation pour des métriques indésirables, 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 et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus qui résout ce problème : Indicateurs distincts pour contrôler la collecte des journaux d'application par rapport aux métriques d'application Google Cloud Managed Service pour Prometheus groupé Si vous ne pouvez pas passer à la version 1.12, procédez comme suit : Recherchez les pods et services sources contenant la facturation indésirable : 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"' Supprimez l'annotation prometheus.io/scrap=true du pod ou du service.
Journalisation et surveillance	1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Les modifications apportées à metrics-server-config ne sont pas conservées Une densité de pods élevée peut, dans des cas extrêmes, créer des coûts de journalisation et de surveillance excessifs, ce qui peut entraîner l'arrêt et le redémarrage du serveur de métriques. Vous pouvez modifier le fichier ConfigMap metrics-server-config pour allouer davantage de ressources de façon à maintenir l'exécution du serveur de métriques. Toutefois, en raison du rapprochement, les modifications apportées à metrics-server-config peuvent être rétablies à la valeur par défaut lors d'une opération de mise à jour ou de mise à niveau du cluster. Le serveur de métriques n'est pas affecté immédiatement, mais au prochain redémarrage, il récupère le fichier ConfigMap restauré et peut de nouveau entraîner des coûts excessifs. Solution Pour la version 1.11.x, vous pouvez créer un script de modification de ConfigMap et l'exécuter avec les mises à jour ou les mises à niveau du cluster. Pour la version 1.12 et les versions ultérieures, contactez l'assistance.
Journalisation et surveillance	1.11, 1.12	Les métriques obsolètes affectent le tableau de bord Cloud Monitoring Plusieurs métriques Google Distributed Cloud (logiciel uniquement) sont obsolètes et, à partir de la version 1.11 de Google Distributed Cloud, les données ne sont plus collectées pour ces métriques obsolètes. Si vous utilisez ces métriques dans l'une de vos règles d'alerte, il n'y aura aucunes données pour déclencher la condition d'alerte. Le tableau suivant répertorie les métriques individuelles obsolètes et la métrique qui les remplace. Métriques obsolètes Métrique de remplacement 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 Dans les versions de cluster antérieures à 1.11, le fichier de définition de règle pour l'alerte Anthos on baremetal node cpu usage exceeds 80 percent (critical) recommandée utilise des métriques obsolètes. Le fichier de définition JSON node-cpu-usage-high.json est mis à jour pour les versions 1.11.0 et ultérieures. Solution Pour migrer vers les métriques de remplacement, procédez comme suit : Dans la console Google Cloud , sélectionnez Monitoring ou cliquez sur le bouton suivant : Accéder à Monitoring Dans le volet de navigation, sélectionnez Tableaux de bord, puis supprimez le tableau de bord État du nœud du cluster Anthos. Cliquez sur l'onglet Exemple de bibliothèque et réinstallez le tableau de bord État du nœud du cluster Anthos. Suivez les instructions de la page Créer des règles d'alerte pour créer une règle à l'aide du fichier de définition de règle node-cpu-usage-high.json mis à jour.
Journalisation et surveillance	1.10, 1.11	"stackdriver-log-forwarder" comporte des erreurs CrashloopBackOff Dans certains cas, l'agent de journalisation fluent-bit peut bloquer le traitement des fragments corrompus. Lorsque l'agent de journalisation ne parvient pas à contourner les fragments corrompus, vous pouvez constater que stackdriver-log-forwarder continue de planter avec une erreur CrashloopBackOff. Si vous rencontrez ce problème, vos journaux contiennent des entrées de ce type : [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5 in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232 #1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523 #2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105 #3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490 #4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0 Solution : Nettoyez les fragments de tampon pour le transfert de journaux Stackdriver. Remarque : Dans les commandes suivantes, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur. Arrêtez tous les pods stackdriver-log-forwarder : kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \ stackdriver-log-forwarder -p \ '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' Vérifiez que les pods stackdriver-log-forwarder sont bien supprimés avant de passer à l'étape suivante. Déployez le DaemonSet suivant pour nettoyer les données corrompues dans les tampons fluent-bit : kubectl --kubeconfig KUBECONFIG -n kube-system apply -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 Utilisez les commandes suivantes pour vérifier que le DaemonSet a nettoyé tous les nœuds : kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l \ app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG -n \ kube-system get pods -l \ app=fluent-bit-cleanup --no-headers | wc -l Le résultat des deux commandes doit être égal au nombre de nœuds de votre cluster. Supprimez le DaemonSet de nettoyage : kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup Redémarrez les pods du transfert de journaux : kubectl --kubeconfig 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, 1.28	Erreur de métriques inconnue dans le journal gke-metrics-agent gke-metrics-agent est un daemonset qui collecte les métriques sur chaque nœud et les transmet à Cloud Monitoring. Il peut générer des journaux tels que les suivants : Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile Des erreurs similaires peuvent se produire pour d'autres types de métriques, y compris (mais sans s'y limiter) : 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 Vous pouvez ignorer ces journaux d'erreurs, car les métriques auxquelles ils font référence ne sont pas prises en charge et ne sont pas critiques à des fins de surveillance.
Journalisation et surveillance	1.10, 1.11	Interruptions intermittentes de l'exportation de métriques Les clusters peuvent rencontrer des interruptions lors de l'exportation continue et normale des métriques. Des métriques peuvent également être manquantes sur certains nœuds. Si ce problème affecte vos clusters, vous risquez de rencontrer des écarts de données pour les métriques suivantes (au minimum) : 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 Mettez à niveau vos clusters vers la version 1.11.1 ou ultérieure. Si vous ne pouvez pas effectuer de mise à niveau, procédez comme suit : Ouvrez votre ressource stackdriver pour la modifier : kubectl -n kube-system edit stackdriver stackdriver Pour augmenter la demande de processeur pour gke-metrics-agent de 10m à 50m, ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver : spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi Votre ressource modifiée doit ressembler à ce qui suit : spec: anthosDistribution: baremetal 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: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi Enregistrez les modifications et fermez l'éditeur de texte. Pour vérifier que vos modifications ont pris effet, exécutez la commande suivante : kubectl -n kube-system get daemonset \ gke-metrics-agent -o yaml | grep "cpu: 50m" La commande détecte cpu: 50m si vos modifications ont été appliquées.
Mise en réseau	1.10	Plusieurs passerelles par défaut interrompent la connectivité à des points de terminaison externes Le fait d'avoir plusieurs passerelles par défaut dans un nœud peut entraîner une rupture de connectivité entre un pod et des points de terminaison externes, tels que google.com. Pour déterminer si vous êtes concerné par ce problème, exécutez la commande suivante sur le nœud : ip route show Plusieurs instances de default dans la réponse indiquent que vous êtes affecté.
Mise en réseau	1.12	Les modifications apportées aux ressources personnalisées de mise en réseau sur les clusters d'utilisateur sont écrasées Les clusters de la version 1.12.x ne vous empêchent pas de modifier manuellement les ressources personnalisées réseau dans votre cluster d'utilisateur. Google Distributed Cloud rapproche les ressources personnalisées dans les clusters d'utilisateur avec les ressources personnalisées de votre cluster d'administrateur lors des mises à niveau des clusters. Cette réconciliation écrase toutes les modifications apportées directement aux ressources personnalisées de mise en réseau dans le cluster d'utilisateur. Les ressources personnalisées de mise en réseau ne doivent être modifiées que dans le cluster d'administrateur, mais les clusters de la version 1.12.x n'appliquent pas cette exigence. Les fonctionnalités de mise en réseau avancées, telles que l'équilibrage de charge groupé avec BGP, la passerelle NAT de sortie, la mise en réseau SR-IOV, le mode plat avec BGP et les cartes d'interface réseau multiples pour les pods, utilisent les ressources personnalisées suivantes : BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode Vous modifiez ces ressources personnalisées dans votre cluster d'administrateur, et l'étape de réconciliation applique les modifications à vos clusters d'utilisateur. Solution Si vous avez modifié l'une des ressources personnalisées mentionnées précédemment sur un cluster d'utilisateur, modifiez les ressources personnalisées correspondantes sur votre cluster d'administrateur pour qu'elles correspondent avant la mise à niveau. Cette étape permet de s'assurer que les modifications apportées à votre configuration sont conservées. Les versions 1.13.0 et ultérieures des clusters vous empêchent de modifier directement les ressources personnalisées de mise en réseau sur vos clusters d'utilisateur.
Mise en réseau	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Échecs de connectivité du pod et filtrage du chemin d'accès inverse Google Distributed Cloud configure le filtrage du chemin d'accès inverse sur les nœuds pour désactiver la validation de la source (net.ipv4.conf.all.rp_filter=0). Si le paramètre rp_filter est défini sur 1 ou 2, les pods échouent en raison de délais de communication hors nœud. Le filtrage du chemin d'accès inverse est défini par les fichiers rp_filter dans le dossier de configuration IPv4 (net/ipv4/conf/all). Cette valeur peut également être remplacée par sysctl, qui stocke les paramètres de filtrage du chemin d'accès inverse dans un fichier de configuration de sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf. Solution Vous pouvez rétablir la connectivité des pods en appliquant l'une des solutions de contournement suivantes : Définissez manuellement la valeur de net.ipv4.conf.all.rp_filter sur 0, puis exécutez sudo sysctl -p pour appliquer la modification. Ou Redémarrez le pod anetd pour redéfinir net.ipv4.conf.all.rp_filter sur 0. Pour redémarrer le pod anetd, exécutez les commandes suivantes afin de localiser et de supprimer le pod anetd, et un nouveau pod anetd démarrera à sa place : kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ Remplacez ANETD_XYZ par le nom du pod anetd. Après avoir effectué l'une des solutions de contournement, vérifiez que la valeur net.ipv4.conf.all.rp_filter est définie sur 0 en exécutant sysctl net.ipv4.conf.all.rp_filter sur chaque nœud.
Mise en réseau	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28, 1.29, 1.30, 1.31, 1.32, 1.33, 1.34	Chevauchement des adresses IP de cluster d'amorçage (genre) et des adresses IP des nœuds de cluster 192.168.122.0/24 et 10.96.0.0/27 sont les CIDR de pod et de service par défaut utilisés par le cluster d'amorçage (genre). Les vérifications préliminaires échouent s'ils chevauchent les adresses IP des machines du nœud de cluster. Solution Pour éviter ce conflit, vous pouvez transmettre les options --bootstrap-cluster-pod-cidr et --bootstrap-cluster-service-cidr à bmctl pour spécifier des valeurs différentes.
Système d'exploitation	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Échec de la création ou de la mise à niveau du cluster sur CentOS En décembre 2020, la communauté CentOS et Red Hat ont annoncé l'abandon de CentOS. Le 31 janvier 2022, CentOS 8 est arrivé en fin de vie. En raison de la fin de vie, les dépôts yum ont cessé de fonctionner pour CentOS, ce qui entraîne l'échec des opérations de création et de mise à niveau du cluster. Cela s'applique à toutes les versions compatibles de CentOS et affecte toutes les versions de clusters. Solution Afficher la procédure de contournement Pour contourner ce problème, exécutez les commandes suivantes pour que votre CentOS utilise un flux d'archive : sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* En tant que solution à long terme, envisagez de migrer vers un autre système d'exploitation compatible.
Sécurité	1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.28	Le conteneur ne peut pas écrire dans VOLUME défini dans Dockerfile avec containerd et SELinux Si vous utilisez containerd comme environnement d'exécution de conteneur et que SELinux est activé sur votre système d'exploitation, il est possible que le VOLUME défini dans le fichier Dockerfile de l'application ne soit pas accessible en écriture. Par exemple, les conteneurs créés avec le fichier Dockerfile suivant ne peuvent pas écrire dans le dossier /tmp. FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp Pour vérifier si vous êtes concerné par ce problème, exécutez la commande suivante sur le nœud qui héberge le conteneur problématique : ausearch -m avc Si vous êtes concerné par ce problème, une erreur denied s'affiche comme suit : time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc: denied { write } for pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0 Solution Pour contourner ce problème, effectuez l'une des modifications suivantes : Désactivez SELinux. N'utilisez pas la fonctionnalité VOLUME dans Dockerfile.
Mises à niveau et mises à jour	1.10, 1.11, 1.12	Le détecteur de problèmes de nœuds n'est pas activé par défaut après la mise à niveau du cluster Lorsque vous mettez à niveau des clusters, le détecteur de problèmes de nœuds n'est pas activé par défaut. Ce problème s'applique aux mises à niveau de la version 1.10 vers la version 1.12.1. Il a été résolu dans la version 1.12.2. Solution : Pour activer le détecteur de problème de nœud : Vérifiez si le service node-problem-detector systemd est en cours d'exécution sur le nœud. Utilisez la commande SSH pour vous connecter au nœud. Vérifiez si le service node-problem-detector systemd est en cours d'exécution sur le nœud : systemctl is-active node-problem-detector Si le résultat de la commande affiche inactive, le détecteur de problèmes de nœuds n'est pas en cours d'exécution sur le nœud. Pour activer le détecteur de problème de nœud, utilisez la commande kubectl edit et modifiez le fichier ConfigMap node-problem-detector-config. Pour en savoir plus, consultez Node Problem Detector.
Opération	1.9, 1.10	Échec de la sauvegarde du cluster lors de l'utilisation d'une connexion non root La commande bmctl backup cluster échoue si nodeAccess.loginUser est défini sur un nom d'utilisateur non racine.] Solution : Ce problème s'applique aux versions 1.9.x, 1.10.0 et 1.10.1. Il est résolu dans la version 1.10.2 et les versions ultérieures.
Mise en réseau	1.10, 1.11, 1.12	Les services d'équilibreur de charge ne fonctionnent pas avec les conteneurs sur le réseau hôte du plan de contrôle. Un bug dans anetd entraîne la perte de paquets pour les services LoadBalancer si les pods de backend s'exécutent tous les deux sur le nœud du plan de contrôle et utilisent le champ hostNetwork: true dans la spécification du conteneur. Ce bug n'est pas présent dans la version 1.13 ni les versions ultérieures. Solution : Les solutions de contournement suivantes peuvent vous aider si vous utilisez un service LoadBalancer soutenu par des pods hostNetwork : Exécutez-les sur des nœuds de calcul (et non sur des nœuds de plan de contrôle). Utilisez externalTrafficPolicy: local dans la spécification du service et assurez-vous que vos charges de travail s'exécutent sur les nœuds d'équilibreur de charge.
Mises à niveau et mises à jour	1.12, 1.13	Échec de l'extraction de l'image par le pod anthos-version-$version$ orphelin Lors de la mise à niveau d'un cluster de la version 1.12.x vers la version 1.13.x, un pod anthos-version-$version$ peut échouer avec une erreur ImagePullBackOff. Cela se produit en raison de la condition de concurrence de la mise à niveau de anthos-cluster-operator et ne devrait pas affecter les capacités habituelles du cluster. Le bug n'est pas présent dans la version 1.13 ni les versions ultérieures. Solution : Supprimez le job dynamic-version-installer en exécutant la commande suivante : kubectl delete job anthos-version-$version$ -n kube-system
Mises à niveau et mises à jour	1.13	Les clusters 1.12 mis à niveau à partir de la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0. Les clusters de version 1.12 qui ont été mis à niveau à partir de la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0. Ce problème de mise à niveau ne s'applique pas aux clusters créés avec la version 1.12. Pour déterminer si vous êtes concerné, consultez les journaux du job de mise à niveau qui contient la chaîne upgrade-first-no* dans le cluster d'administrateur. Si le message d'erreur suivant s'affiche, vous êtes concerné. TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] ******* ... [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name. ... Solution : Pour résoudre ce problème, procédez comme suit : Exécutez les commandes suivantes sur votre poste de travail administrateur : echo '[{ "op": "remove", "path": \ "/spec/clusterConfiguration/featureGates" }]' \ > remove-feature-gates.patch export KUBECONFIG=$ADMIN_KUBECONFIG kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \ 'kubectl patch kubeadmconfig $1 -n $0 --type json \ --patch-file remove-feature-gates.patch' Réessayez de mettre à niveau le cluster.
Journaux et surveillance	1.16.2, 1.16.3	Utilisation élevée du processeur pour stackdriver-operator Un problème dans stackdriver-operator entraîne une consommation de temps CPU plus élevée que la normale. L'utilisation normale du processeur est inférieure à 50 milliCPU (50m) pour stackdriver-operator à l'état inactif. La cause est une incompatibilité des ressources de certificat que stackdriver-operator applique avec les attentes de cert-manager. Cette incohérence entraîne une condition de concurrence entre cert-manager et stackdriver-operator lors de la mise à jour de ces ressources. Ce problème peut entraîner une baisse des performances sur les clusters dont la disponibilité du processeur est limitée. Solution : En attendant de pouvoir passer à une version qui corrige ce bug, utilisez la solution de contournement suivante : Pour réduire temporairement stackdriver-operator à zéro instance dupliquée, appliquez une ressource personnalisée AddonConfiguration : kubectl scale deploy stackdriver-operator --replicas=0 Une fois que vous avez effectué la mise à niveau vers une version qui corrige ce problème, augmentez à nouveau la valeur de stackdriver-operator : kubectl scale deploy stackdriver-operator --replicas=1
Journaux et surveillance	1.16.0, 1.16.1	Le scraping des métriques basées sur les annotations ne fonctionne pas Dans la version mineure 1.16 de Google Distributed Cloud, le champ enableStackdriverForApplications de la spécification de ressource personnalisée stackdriver est obsolète. Ce champ est remplacé par deux champs, enableCloudLoggingForApplications et enableGMPForApplications, dans la ressource personnalisée Stackdriver. Nous vous recommandons d'utiliser Google Cloud Managed Service pour Prometheus afin de surveiller vos charges de travail. Utilisez le champ enableGMPForApplications pour activer cette fonctionnalité. Si vous vous appuyez sur la collecte de métriques déclenchée par les annotations prometheus.io/scrape sur vos charges de travail, vous pouvez utiliser l'indicateur de fonctionnalité annotationBasedApplicationMetrics pour conserver l'ancien comportement. Toutefois, un problème empêche annotationBasedApplicationMetrics de fonctionner correctement, ce qui empêche la collecte de métriques à partir de vos applications dans Cloud Monitoring. Solution : Pour résoudre ce problème, mettez à niveau votre cluster vers la version 1.16.2 ou ultérieure. La collecte de métriques de charge de travail basée sur les annotations, activée par le feature gate annotationBasedApplicationMetrics, collecte les métriques pour les objets qui comportent l'annotation prometheus.io/scrape. De nombreux systèmes logiciels d'origine Open Source peuvent utiliser cette annotation. Si vous continuez à utiliser cette méthode de collecte de métriques, tenez compte de cette dépendance afin de ne pas être surpris par les frais liés aux métriques dans Cloud Monitoring.
Journaux et surveillance	1.15, 1.16, 1.28.0-1.28.900, 1.29.0-1.29.400, 1.30.0, 1.30.100	Échec de Cloud Audit Logging en raison d'une autorisation refusée Cloud Audit Logs nécessite une configuration d'autorisation spéciale qui est effectuée automatiquement par cluster-operator via GKE Hub. Toutefois, dans le cas où un cluster d'administrateur gérait plusieurs clusters avec des ID de projet différents, un bug dans cluster-operator entraînait l'ajout répété du même compte de service à la liste d'autorisation et l'échec de la demande d'ajout à la liste d'autorisation en raison de la limite de taille. Par conséquent, les journaux d'audit de certains ou de tous ces clusters ne seront pas injectés dans Google Cloud. Le symptôme est une série d'erreurs Permission Denied dans le pod audit-proxy du cluster concerné. Un autre symptôme est l'état d'erreur et une longue liste de comptes de service en double lorsque vous vérifiez la liste d'autorisation de journalisation d'audit Cloud via GKE Hub : curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging { "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging", "spec": { "cloudauditlogging": { "allowlistedServiceAccounts": [ "SERVICE-ACCOUNT-EMAIL", ... ... multiple lines of the same service account ] } }, "state": { "state": { "code": "ERROR" } } } Pour résoudre le problème, vous pouvez mettre à niveau votre cluster vers la version 1.28.1000, 1.29.500 ou 1.30.200 (ou une version ultérieure) où le problème est résolu. Vous pouvez également appliquer la solution de contournement suivante : Afficher la procédure de contournement Supprimez et recréez la fonctionnalité Cloud Audit Logging de GKE Hub pour forcer le déclenchement de l'automatisation de la liste d'autorisation. Supprimez la fonctionnalité de hub cloudauditlogging en : curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging Recréez la fonctionnalité de hub cloudauditlogging en : curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' Dans les commandes ci-dessus : Remplacez PROJECT_ID par le projet d'opérations du cluster. Remplacez SERVICE_ACCOUNT_EMAIL par l'adresse e-mail du compte de service de journalisation et de surveillance du cluster.
Configuration	Toutes les versions de correctif de la version 1.29 et antérieures, de la version 1.30.400 et antérieures, et de la version 1.31.0	La configuration du miroir de registre sur les nœuds n'est pas mise à jour lorsque seul le champ hosts est modifié. Lorsque vous mettez à jour le champ containerRuntime.registryMirrors.hosts pour un point de terminaison de mirror de registre dans la spécification du cluster, les modifications ne sont pas automatiquement appliquées aux nœuds du cluster. Ce problème est dû au fait que la logique de réconciliation ne détecte pas les modifications apportées exclusivement au champ hosts. Par conséquent, les tâches de mise à jour de la machine chargées de mettre à jour la configuration containerd sur les nœuds ne sont pas déclenchées. Validation : Pour vérifier ce problème, modifiez uniquement le champ hosts pour un miroir de registre, puis inspectez le fichier de configuration containerd (le chemin d'accès peut être /etc/containerd/config.toml ou d'autres chemins d'accès tels que /etc/containerd/config.d/01-containerd.conf selon la version et la configuration) sur un nœud de calcul. Le fichier n'affiche pas la liste hosts mise à jour pour le point de terminaison du miroir. Solution : Choisissez l'une des options suivantes : Passez à une version incluant le correctif : mettez à niveau vos clusters vers la version 1.30.500-gke.126 ou ultérieure, la version 1.31.100-gke.136 ou ultérieure, ou la version 1.32.0. Déclenchez une mise à jour en modifiant un NodePool : apportez une modification triviale à la spécification NodePool pour les nœuds concernés. Par exemple, ajoutez un libellé ou une annotation temporaire. Cela déclenche le processus de mise à jour de la machine, qui prend en compte les modifications apportées au miroir du registre. Vous pourrez supprimer la modification triviale par la suite.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care. Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris en ce qui concerne les thématiques suivantes :

• Conditions requises pour ouvrir une demande d'assistance
• Outils pour vous aider à résoudre les problèmes liés à la configuration de votre environnement, les journaux et les métriques
• Composants acceptés