Cette page répertorie tous les problèmes connus de Google Distributed Cloud Virtual pour Bare Metal. Pour filtrer les problèmes connus par version ou catégorie de produit, sélectionnez vos filtres dans les menus déroulants suivants.
Sélectionnez la version de votre GDCV pour Bare Metal:
Sélectionnez la catégorie de votre problème:
Vous pouvez également rechercher votre problème:
Catégorie
Version(s) identifiée(s)
Problème et solution
Réinitialisation/Suppression
1.29.0
Échec de la tentative de suppression de l'espace de noms lors de la réinitialisation du cluster d'utilisateur
Lors de l'exécution de bmctl reset cluster -c ${USER_CLUSTER}, une fois toutes les tâches associées terminé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. La réinitialisation du cluster finit par dépasser le délai et renvoie une erreur.
Solution :
Pour supprimer l'espace de noms et réinitialiser le cluster d'utilisateur, procédez comme suit:
Supprimez le pod metrics-server du cluster d'administrateur :
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
Il manque un sélecteur de nœud dans le déploiement de l'autorisation binaire
Si vous avez activé l'autorisation binaire pour GKE sur bare metal et que vous utilisez une version de 1.16.0 à 1.16.7 ou de 1.28.0 à 1.28.400, il se peut que vous rencontriez un problème concernant l'emplacement de planification des pods de cette fonctionnalité. Dans ces versions, il manque un nodeSelector pour le déploiement de l'autorisation binaire. Les pods de la fonctionnalité peuvent donc être programmés sur des nœuds de calcul plutôt que sur des nœuds de plan de contrôle. Ce comportement n'entraîne aucun échec, mais n'est pas intentionnel.
Solution :
Pour tous les clusters concernés, procédez comme suit:
Ouvrez le fichier de déploiement de l'autorisation binaire :
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 de clusters créés avant la version 1.11.0 vers les versions 1.28.0-1.28.300 peut entraîner une erreur pour le pod déployeur du contrôleur de cycle de vie lors de la mise à niveau. Dans ce cas, les journaux du pod déployeur 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. Effectuez une mise à niveau vers la version 1.28.400 ou une version ultérieure pour résoudre le problème.
Si vous ne parvenez pas à effectuer la mise à niveau, exécutez les commandes suivantes pour résoudre le problème:
ID de projet incorrect affiché dans l'explorateur de journaux
Les journaux de cluster ou de conteneurs comportent parfois des tags avec un ID de projet différent dans resource.labels.project_id, dans l'explorateur de journaux.
Cela peut se produire lorsque le cluster est configuré pour utiliser l'observabilité PROJECT_ONE, définie dans le champ clusterOperations.projectID de la configuration du cluster.
Cependant, l'élément cloudOperationsServiceAccountKeyPath de la configuration dispose d'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 étiqueté PROJECT_TWO.
Solution :
Utilisez l'une des options suivantes pour résoudre le problème:
Utilisez un compte de service du même projet de destination.
Remplacez project_id dans le fichier JSON de la clé de compte de service par le projet actuel.
Modifiez project_id directement dans le filtre de journal à partir de l'explorateur de journaux.
Mise en réseau
1.29.0
Dégradation des performances des clusters utilisant l'équilibrage de charge groupé avec BGP
Pour les clusters de la version 1.29.0 utilisant l'équilibrage de charge groupé avec BGP, les performances de l'équilibrage de charge peuvent se dégrader lorsque le nombre total de services de type LoadBalancer approche de 2 000. Lorsque les performances se dégradent, les services nouvellement créés prennent 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 de défaillance, tels que la perte d'un nœud d'équilibreur de charge. Ces problèmes de service surviennent lorsque le déploiement ang-controller-manager est arrêté pour cause de mémoire insuffisante.
Si votre cluster est concerné par ce problème, les services qu'il contient sont inaccessibles et ne sont pas opérationnels, et le déploiement ang-controller-manager se trouve dans un CrashLoopBackOff. La réponse renvoyée lors de la création de la liste des déploiements ang-controller-manager est semblable à celle-ci :
Pour contourner ce problème, vous pouvez augmenter la limite de ressources de mémoire du déploiement ang-controller-manager de 100 Mio et supprimer la limite de processeur:
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é gcr.io du point de terminaison Container Registry peuvent bloquer les opérations du cluster
Plusieurs opérations de cluster pour les clusters d'administrateur créent un cluster d'amorçage. Avant de créer un cluster d'amorçage, bmctl effectue un contrôle de joignabilité Google Cloud à partir du poste de travail administrateur.
Cette vérification peut échouer en raison de problèmes de connectivité avec le point de terminaison Container Registry gcr.io. Un message d'erreur semblable à celui-ci peut s'afficher:
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, relancez l'opération avec l'option --ignore-validation-errors.
Mise en réseau
1,15, 1,16
GKE Dataplane V2 n'est pas compatible avec certains pilotes de stockage
Les clusters GKE sur Bare Metal utilisent GKE Dataplane V2, qui n'est pas compatible avec certains fournisseurs de stockage. Vous risquez de rencontrer des problèmes avec des volumes ou des pods NFS bloqués. Cela est particulièrement probable si vos charges de travail utilisent des volumes ReadWriteMany reposant sur des pilotes de stockage sensibles à ce problème:
Robin.io
Portworx (sharedv4 volumes de service)
csi-nfs
Cette liste n'est pas exhaustive.
Solution
Un correctif est disponible pour les versions d'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 aucune 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 le pod gke-metrics-agent qui existe sur le même nœud que kube-state-metrics est à court de mémoire (OOM).
Cela peut se produire dans les clusters comportant 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 pour utiliser la porte de fonctionnalité ksmNodePodMetricsOnly. Cette porte de fonctionnalité garantit que seul un petit nombre de métriques critiques sont exposées.
Pour contourner ce problème, procédez comme suit:
Consultez la définition de ressource personnalisée stackdriver pour connaître les portes de caractéristiques disponibles :
É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 une défaillance 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 en version preview pour GKE sur Bare Metal version 1.28.
Solution
Contournez l'erreur de vérification préliminaire en définissant spec.bypassPreflightCheck sur true sur votre ressource de 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 nombre élevé de services (plus de 10 000), le basculement peut prendre plus d'une heure. Cela est dû au fait que MetalLB utilise une file d'attente à débit limité qui, à grande échelle, peut prendre un certain temps pour accéder au service devant basculer.
Solution
Mettez à niveau votre cluster vers la version 1.28 ou une version 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 le 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 défaillances du 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 signale un message d'erreur signalant l'échec de l'appel de certains services Google, comme dans l'exemple suivant:
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 présente une propriété incorrecte
Dans certains cas, la propriété des groupes et des utilisateurs du fichier /var/log/apiserver/audit.log sur les nœuds du plan de contrôle est définie sur root.
Ce paramètre de propriété des fichiers entraîne l'échec de la mise à niveau des nœuds du plan de contrôle lors de la mise à niveau d'un cluster de la version 1.16.x vers la version 1.28.0-gke.435.
Ce problème ne concerne que les clusters créés avant la version 1.11 et pour lesquels Cloud Audit Logs est désactivé. Cloud Audit Logs est activé par défaut pour les clusters à partir de la version 1.9.
Solution
Si vous ne parvenez pas à mettre à niveau votre cluster vers la version 1.28.100-gke.146, procédez comme suit pour résoudre le problème:
Si Cloud Audit Logs est activé, supprimez le fichier /var/log/apiserver/audit.log.
Si Cloud Audit Logs est désactivé, définissez la propriété de /var/log/apiserver/audit.log sur la même propriété que le 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
GKE sur Bare Metal utilise MetalLB pour l'équilibrage de charge groupé. Dans la version 1.28.0-gke.435 de GKE sur Bare Metal, le modèle MetalLB groupé est mis à niveau vers la version 0.13, qui accepte les CRD pour IPAddressPools. Toutefois, comme les ConfigMaps autorisent tous les noms pour les IPAddressPool, les noms des pools ont dû être convertis en un nom compatible avec Kubernetes en ajoutant un hachage à la fin du nom du IPAddressPool.
Par exemple, une classe IPAddressPool nommée default est convertie en 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 de 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 pour 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 GKE sur Bare Metal.
Solution
Si vous ne parvenez pas à mettre à niveau votre cluster vers la version 1.28.100-gke.146, procédez comme suit pour contourner le problème:
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 GKE sur Bare Metal 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 celui-ci:
Ce problème est résolu dans GKE sur une solution Bare Metal 1.15.0 et versions ultérieures.
Installation
1,14
Création du cluster bloquée sur le job machine-init
Si vous essayez d'installer la version 1.14.x de Google Distributed Cloud Virtual pour Bare Metal, les tâches machine-init peuvent échouer, 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 entraîne l'échec de la tâche machine-init. Procédez comme suit sur un nœud de plan de contrôle opérationnel:
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 :
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 ayant échoué. 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 de nœud list et watch manquantes pour Cilium-operator
Dans Cilium 1.13, les autorisations ClusterRole cilium-operator sont incorrectes. Les autorisations du nœud list et watch sont manquantes. cilium-operator ne parvient pas à démarrer les récupérateurs de mémoire, 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 Deezer.
Les mappages de règles peuvent atteindre la limite de 16 000.
Impossible d'ajouter de nouvelles entrées.
Application NetworkPolicy incorrecte.
Les identités peuvent atteindre la limite de 64 000.
Impossible de créer des pods.
Un opérateur ne disposant pas des autorisations de nœud signale l'exemple de message de journal 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 signale un message d'erreur lorsqu'il ne parvient pas à insérer une entrée dans un mappage 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 illustré dans l'exemple suivant :
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
Enregistrez et fermez l'éditeur. L'opérateur détecte de manière dynamique 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. Si vous rencontrez cette erreur qui bloque la mise à niveau, exécutez à nouveau la commande de mise à niveau.
Si vous observez cette erreur lors de l'exécution de la requête préliminaire à l'aide de la commande bmctl preflightcheck, rien n'est bloqué par cet échec. Vous pouvez réexécuter la vérification préliminaire pour obtenir des informations précises lors de la vérification préliminaire.
Solution :
Exécutez à nouveau la commande de mise à niveau ou, si vous la rencontrez pendant 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
La vérification périodique de l'état du réseau échoue lorsqu'un nœud est remplacé ou supprimé
Ce problème affecte 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 fait l'objet de vérifications périodiques de l'état du réseau, celle-ci entraîne un échec après le remplacement ou la suppression d'un nœud, car le ConfigMap de l'inventaire réseau n'est pas mis à jour une fois créé.
Solution :
La solution recommandée consiste à supprimer le ConfigMap d'inventaire et la vérification de l'état périodique 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:
La passerelle réseau pour GDC ne peut pas appliquer votre configuration lorsque le nom de l'appareil contient un point
Si vous disposez d'un appareil réseau dont le nom comporte un point (.), tel que bond0.2, Network Gateway pour GDC traite ce point comme un chemin d'accès dans le répertoire lorsqu'il exécute sysctl pour apporter des modifications. Lorsque la passerelle réseau pour GDC vérifie si la détection d'adresses en double (DAD) est activée, la vérification peut échouer et l'opération ne se rapproche pas.
Le comportement est différent d'une version de cluster à l'autre:
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, vous ne remarquerez pas ce problème 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 une version 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 échoueront.
La version 1.16 de GKE sur Bare Metal 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 porte de fonctionnalité.
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érieures. 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 pour lesquels la valeur spec.clusterSecurity.enableSeccomp n'est pas définie ou définie sur true ne sont pas concernés.
Les métadonnées containerd peuvent être corrompues après le redémarrage lorsque /var/lib/containerd est installé.
Si vous avez éventuellement installé /var/lib/containerd, 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 une installation facultative est définie dans /etc/fstab pour /var/lib/containerd/ et si les options d'installation comportent nofail.
Solution :
Supprimez l'option d'installation nofail dans /etc/fstab ou mettez à niveau votre cluster vers la version 1.15.6 ou une version ultérieure.
Opération
1,13 ; 1,14 ; 1,15 ; 1,16 ; 1,28
Nettoyer les pods obsolètes dans le cluster
L'état Failed et l'état TaintToleration des pods gérés par un déploiement (ReplicaSet) peuvent s'afficher. Ces pods n'utilisent pas de ressources de cluster, mais doivent être supprimés.
Vous pouvez utiliser la commande kubectl suivante pour répertorier 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:
Pour chaque pod présentant les symptômes décrits, vérifiez le ReplicaSet auquel le pod appartient. Si vous êtes satisfait du ReplicaSet, 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
Récupérez le ReplicaSet et vérifiez que la valeur de status.replicas est identique à celle de 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
Les événements etcd peuvent 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 défaillances de pods liées à etcd-events peuvent bloquer l'opération. Plus précisément, la tâche de mise à niveau de nœud échoue pour l'étape TASK [etcd_events_install : Run etcdevents].
Si vous êtes concerné par ce problème, des échecs de pod se présentent comme suit:
Le pod kube-apiserver ne démarre pas avec l'erreur suivante :
Le pod etcd-events ne démarre pas avec l'erreur suivante :
Error: error syncing endpoints with etcd: context deadline exceeded
Solution :
Si vous ne parvenez pas à mettre à niveau votre cluster vers une version prenant en charge le correctif, utilisez la solution temporaire suivante pour résoudre les erreurs:
Utilisez SSH pour accéder au nœud du plan de contrôle avec les erreurs signalées.
Modifiez le fichier manifeste etcd-events /etc/kubernetes/manifests/etcd-events.yaml, puis 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
L'élément orderPolicy CoreDNS n'est pas reconnu
OrderPolicy n'est pas reconnu en tant que paramètre et n'est pas utilisé. À la place, GKE sur Bare Metal utilise toujours Random.
Ce problème est dû au fait que le modèle CoreDNS n'a pas été mis à jour, ce qui entraîne l'omission de orderPolicy.
Solution :
Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif persiste jusqu'à une mise à niveau.
Modifiez le modèle existant :
kubectl edit cm -n kube-system coredns-template
Remplacez le contenu du modèle par ce qui suit :
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, opérations
1,10, 1,11, 1,12, 1,13, 1,14
Passerelle réseau pour les composants GDC évincés ou en attente en raison d'une classe de priorité manquante
Les pods de passerelle réseau dans kube-system peuvent afficher un état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé suivant:
Ces erreurs indiquent des événements d'éviction ou une incapacité à planifier les pods en raison des ressources de nœud. Étant donné que la passerelle réseau des pods GDC n'a pas de classe de priorité, la priorité par défaut est la même que pour les autres charges de travail.
Lorsque les nœuds sont limités en ressources, les pods de la passerelle réseau peuvent être évincés. Ce comportement est particulièrement insatisfaisant pour le DaemonSet ang-node, car ces pods doivent être programmés sur un nœud spécifique et ne peuvent pas être migrés.
Solution :
Passez à la version 1.15 ou ultérieure.
En guise de solution à court terme, vous pouvez attribuer manuellement une classe PriorityClass à la passerelle réseau pour les composants GDC. Le contrôleur GKE sur Bare Metal écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau du cluster.
Attribuez la classe de priorité system-cluster-critical aux déploiements du contrôleur de cluster ang-controller-manager et autoscaler.
Attribuez la classe prioritaire 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 en version 1.15.0, 1.15.1 ou 1.15.2, ou la mise à niveau de clusters vers les versions 1.15.0, 1.15.1 ou 1.15.2 échoue lorsque le nom du cluster dépasse 48 caractères (version 1.15.0) ou 45 caractères (version 1.15.1 ou 2). Lors des opérations de création et de mise à niveau du cluster, GKE sur Bare Metal crée une ressource de vérification de l'état d'état dont le nom inclut le nom et la version du cluster:
Pour les clusters version 1.15.0, le nom de la ressource de vérification de l'état est CLUSTER_NAME-add-ons-CLUSTER_VER.
Pour les clusters version 1.15.1 ou 1.15.2, le nom de la ressource de 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 dépasse la limite de longueur Kubernetes 63 pour les noms d'étiquettes, ce qui empêche la création de la ressource de vérification de l'état d'état.
Si la vérification de l'état n'aboutit pas, l'opération du cluster échoue.
Pour savoir si vous êtes concerné par ce problème, vérifiez la ressource défaillante à l'aide de kubectl describe:
Si ce problème vous concerne, la réponse contient un avertissement pour une ReconcileError comme 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 contourner la vérification de l'état. Exécutez la commande suivante pour appliquer un correctif à la ressource personnalisée de vérification d'état en transmettant l'état: (status: {pass: true})
Les clusters des versions 1.14.0 et 1.14.1 avec des fonctionnalités en version preview ne peuvent pas être mis à niveau vers la version 1.15.x
Si une fonctionnalité d'aperçu est activée pour les clusters des versions 1.14.0 et 1.14.1, ils ne pourront pas passer à la version 1.15.x. Cela s'applique aux fonctionnalités en version 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:
Si vous êtes concerné par ce problème, un message d'erreur semblable à celui-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 a été résolu dans les clusters version 1.14.2 et ultérieures.
Solution :
Si vous ne parvenez pas à mettre à niveau vos clusters vers la version 1.14.2 ou une version ultérieure avant de passer à la version 1.15.x, vous pouvez effectuer une mise à niveau directement vers la version 1.15.x à l'aide d'un cluster d'amorçage:
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 de nouvelles 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 GKE sur Bare Metal version 1.15.0 ou ultérieure. Les adresses IP flottantes en double préexistantes ne provoquent pas d'erreurs. Le webhook empêche uniquement la création de ressources NetworkGatewayGroups personnalisées 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 a été reconnue par le rapprochement. Mise à jour de Network Gateway pour GDC, qui reconnaît désormais toutes les ressources personnalisées NetworkGatewayGroup dans l'espace de noms système. Les ressources personnalisées NetworkGatewayGroup existantes sont prises en compte en l'état.
Solution :
Des erreurs ne se produisent que lors de la création d'une ressource personnalisée NetworkGatewayGroup.
Pour résoudre l'erreur:
Exécutez la commande suivante pour répertorier NetworkGatewayGroups ressources personnalisées :
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) :
Pour appliquer vos modifications, fermez et enregistrez les ressources personnalisées modifiées.
Environnement d'exécution de VM sur GDC
1.13.7
Les VM peuvent ne pas démarrer sur des clusters 1.13.7 utilisant un registre privé
Lorsque vous activez l'environnement d'exécution des VM sur GDC sur un cluster de version 1.13.7 nouveau ou mis à niveau qui utilise un registre privé, les VM qui se connectent au réseau de nœuds ou qui utilisent un GPU risquent de ne pas démarrer correctement. Ce problème est dû au fait que certains pods système de l'espace de noms vm-system reçoivent des erreurs d'extraction d'image. Par exemple, si votre VM utilise le réseau de nœuds, certains pods peuvent signaler des erreurs d'extraction d'image semblables aux suivantes:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Ce problème a été résolu dans les clusters GKE sur Bare Metal version 1.14.0 et ultérieures.
Solution
Si vous ne pouvez 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é:
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 genre, le pod gke-metric-agent ne démarre pas.
Lors de la création du cluster dans le cluster du genre, le pod gke-metrics-agent ne parvient pas à démarrer 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 "failing to pull" 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 de genre est de faciliter le taux de réussite de la création du cluster, ainsi que pour 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 de genre est de faciliter le taux de réussite de la création du cluster, ainsi que pour 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 fait planter le nœud LoadBalancer sur CentOS ou RHEL
Lorsque vous accédez à un service double pile (un service possédant à la fois des points de terminaison IPv4 et IPv6) et que vous utilisez le point de terminaison IPv6, le nœud LoadBalancer qui diffuse le service peut planter. Ce problème affecte les clients qui utilisent des services à double pile avec CentOS ou RHEL et une version de noyau antérieure à kernel-4.18.0-372.46.1.el8_6.
Si vous pensez que ce problème vous concerne, 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 de noyau kernel-4.18.0-372.46.1.el8_6 ou une version ultérieure. Cette version de 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 avoir redémarré un nœud, vous pouvez rencontrer des problèmes de connectivité intermittente pour un service NodePort ou LoadBalancer. Par exemple, vous pouvez rencontrer des erreurs de handshake TLS intermittent ou de réinitialisation de la connexion. Ce problème est résolu pour les versions de cluster 1.14.1 et ultérieures.
Pour vérifier si ce problème vous affecte, consultez les règles de transfert iptables sur les nœuds sur lesquels le pod de backend du service concerné est exécuté:
sudo iptables -L FORWARD
Si la règle KUBE-FORWARD s'affiche avant la règle CILIUM_FORWARD dans iptables, vous pouvez être concerné par ce problème. L'exemple de résultat suivant montre un nœud où le problème se produit:
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 doit être correctement configurée.
L'exemple de résultat suivant montre que la règle CILIUM_FORWARD est maintenant 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é preview ne conserve pas l'autorisation ni les informations du propriétaire d'origine
La fonctionnalité d'aperçu d'un cluster 1.9.x utilisant bmctl 1.9.x ne conserve pas les informations d'origine sur l'autorisation et le propriétaire. 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 1.9.x. Si le metadata.json n'est pas présent, passez au cluster 1.10.x et utilisez bmctl 1.10.x pour sauvegarder/restaurer.
Mises à niveau et créations
1.14.2
clientconfig-operator bloqué à l'état "En attente" avec CreateContainerConfigError
Si vous avez créé ou mis à niveau un cluster vers la version 1.14.2 avec une configuration OIDC/LDAP, le pod clientconfig-operator peut être bloqué en attente. Ce problème survient avec 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 de cluster antérieures, telles que 1.14.0 et 1.14.1, ne sont pas affectées. Ce problème est résolu dans la version 1.14.3 et dans toutes les versions ultérieures, y compris les versions 1.15.0 et ultérieures.
Solution :
Pour contourner ce problème, vous pouvez corriger le déploiement clientconfig-operator afin d'ajouter du contexte de sécurité supplémentaire et de vous assurer que le déploiement est prêt.
Utilisez la commande suivante pour appliquer un correctif à clientconfig-operator dans le cluster cible:
CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig pour le 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 générer 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 de rotation de l'autorité de certification pour 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'une 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 des clusters à double pile
Lorsque vous déployez un cluster à double pile (c'est-à-dire un cluster avec des adresses IPv4 et IPv6), le ou les pods ipam-controller-manager peuvent subir un plantage en boucle. Ce comportement entraîne le passage des nœuds entre les états Ready et NotReady, ce qui peut entraîner l'échec de l'installation du cluster. Ce problème peut survenir lorsque le serveur d'API est soumis à une charge élevée.
Pour savoir si ce problème vous affecte, 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 montre les pods à l'état CrashLoopBackOff:
1,6, 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13 et 1,14
Besoin de faim de montre etcd
Les clusters exécutant etcd version 3.4.13 ou antérieure peuvent rencontrer des problèmes de pénurie de surveillance et de surveillance des ressources non opérationnelles, ce qui peut entraîner les problèmes suivants:
La planification des pods est interrompue
Impossible d'enregistrer les nœuds
le kubelet n'observe pas les modifications apportées aux pods
Ces problèmes peuvent rendre le cluster non fonctionnel.
Ce problème a été résolu dans les versions 1.12.9, 1.13.6, 1.14.3 et ultérieures de GDCV pour Bare Metal. Ces nouvelles versions utilisent la version 3.4.21 d'etcd. Toutes les versions précédentes de GDCV pour Bare Metal sont concernées par ce problème.
Solution
Si vous ne pouvez pas effectuer de mise à niveau immédiatement, vous pouvez limiter le risque de défaillance du cluster en réduisant le nombre de nœuds qu'il contient. Supprimez les nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mbit/s.
Pour afficher cette métrique dans l'Explorateur de métriques:
Accédez à l'Explorateur de métriques dans la console Google Cloud:
Développez 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
La valeur 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 indique "Échec", mettez à niveau votre cluster vers la version 1.11.7 ou ultérieure, ou 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 prêts après la mise à niveau
Une fois la mise à niveau terminée, la condition "Ready" 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 des incohérences
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 à celle-ci:
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 survenir dans les cas suivants:
Si vous avez effectué deux rotations manuelles de certificats émis par les gestionnaires de certificats sur un cluster de plus de 180 jours ou plus, et que vous n'avez jamais redémarré le anthos-cluster-operator.
Si vous avez effectué des rotations manuelles de certificats émis par cert-manager sur un cluster de plus de 90 jours et que vous n'avez jamais redémarré le anthos-cluster-operator.
Solution
Redémarrez le pod en arrêtant anthos-cluster-operator.
Mises à niveau et mises à jour
1.14.0
Pods de déployeurs de contrôleurs 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 déployeurs de contrôleurs de cycle de vie obsolètes peuvent être créés lors des mises à niveau du cluster d'utilisateur.
Ce problème concerne les clusters d'utilisateur créés initialement à des versions antérieures à la version 1.12. Les pods créés par inadvertance n'entravent pas les opérations de mise à niveau, mais 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 obsolètes du déployeur du contrôleur de cycle de vie, procédez comme suit:
Répertorier 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.
Supprimez les ressources dont la valeur dans la colonne PASS est true ou false.
Par exemple, pour supprimer les ressources de l'exemple de résultat précédent, utilisez les commandes suivantes:
L'état BGPSession change constamment en raison du grand nombre de routes entrantes
La mise en réseau avancée GKE sur Bare Metal ne parvient pas à gérer correctement les sessions BGP lorsque les 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 prend trop de temps pour rapprocher les sessions BGP et ne parvient pas à mettre à jour l'état. En l'absence de mises à jour d'état ou de vérification de l'état'état, la session est supprimée, car elle est obsolète.
Voici quelques exemples de comportements indésirables sur les sessions BGP que vous pourriez remarquer et indiquer un problème:
Suppression et recréation continue de bgpsession.
bgpsession.status.state ne devient jamais Established.
Les routes ne parviennent pas à s'annoncer, ou elles sont annoncées et retirées à plusieurs reprises.
Des problèmes d'équilibrage de charge BGP peuvent être perceptibles en cas de problèmes de connectivité aux services LoadBalancer.
Le problème BGP FlatIP peut être perceptible avec des problèmes de connectivité aux pods.
Pour déterminer si vos problèmes BGP sont causés par les pairs distants qui annoncent un trop grand nombre de routes, examinez les états et les résultats associés à l'aide des commandes suivantes:
Utilisez kubectl get bgpsessions sur le cluster concerné.
Le résultat affiche bgpsessions avec l'état "Non établi" et l'heure du dernier rapport est comptée en continu jusqu'à 10 à 12 secondes avant de paraître réinitialisées.
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 de journal indiquent que des sessions BGP obsolètes sont en cours de suppression :
kubectl logs ang-controller-manager-POD_NUMBER
Remplacez POD_NUMBER par le pod principal de votre cluster.
Solution :
Réduisez ou supprimez le nombre de routes annoncées par le pair distant vers le cluster à l'aide d'une règle d'exportation.
Dans les versions 1.14.2 et ultérieures d'un cluster GKE sur Bare Metal, 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 de tables Netfilter (conntrack). Des échecs d'insertion peuvent se produire même lorsque la table conntrack peut accueillir de nouvelles entrées. Les échecs sont causés par des modifications du noyau 5.15 et versions ultérieures qui limitent les insertions de tables en fonction de la longueur de la chaîne.
Pour savoir si vous êtes concerné par ce problème, vous pouvez consulter les statistiques du système de suivi des connexions dans le noyau à l'aide de la commande suivante:
Si une valeur chaintoolong dans la réponse est un nombre non nul, vous êtes concerné par ce problème.
Solution
L'atténuation à court terme consiste à augmenter la taille de la table de hachage Netfiler (nf_conntrack_buckets) et de la table de suivi des connexions Netfilter (nf_conntrack_max). Exécutez les commandes suivantes sur chaque nœud de cluster pour augmenter la taille des tables:
Remplacez TABLE_SIZE par la nouvelle taille en octets. La valeur par défaut de la taille de table est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs sur le nœud. Par exemple, si votre nœud comporte huit cœurs, définissez la taille de la table sur 524288.
Impossible de restaurer des sauvegardes de cluster avec bmctl pour certaines versions
Nous vous recommandons de sauvegarder vos clusters avant de procéder à la mise à niveau afin de pouvoir restaurer la version précédente si la mise à niveau échoue.
Un problème lié à la commande bmctl restore cluster entraîne l'échec de la restauration des sauvegardes des clusters avec les versions identifiées. Ce problème est spécifique aux mises à niveau, qui consistent à restaurer 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 vos clusters manuellement et les restaurer manuellement, 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 ne disposant pas à la fois 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 défaillant 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, il n'y a pas d'adresse IPv6 sur l'interface ens192. Des erreurs ARP similaires s'affichent s'il manque une adresse IPv4 au nœud.
NetworkGatewayGroup tente d'établir une connexion ARP et une connexion NDP à l'adresse IP de liaison locale. Si l'adresse IP n'existe pas (IPv4 pour ARP, IPv6 pour NDP), la connexion échoue et le daemon ne continue 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 qui contient 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, par exemple 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 passe à 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 concernées. Effectuez la mise à niveau vers l'une des versions corrigées
Pour contourner ce problème, exécutez la commande suivante:
IP_ADDRESS: adresse IP du nœud dans l'état d'une 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 clusters volumineux en raison d'une non-concordance des jetons
Lorsque vous installez GKE sur des clusters Bare Metal 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 GDCV pour Bare Metal 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 cluster pour ajouter des nœuds supplémentaires une fois l'installation terminée.
Journalisation et surveillance
1.10, 1.11, 1.12, 1.13.0
Limite de processeur basse pour metrics-server dans les clusters périphériques
Dans les clusters Edge GKE sur Bare Metal, des limites de processeur faibles 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 opérationnel.
Si la limite de processeur de 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:
Ce problème est résolu dans les clusters GKE sur Bare Metal version 1.13.1 ou ultérieure. Pour résoudre ce problème, mettez à niveau vos clusters.
Une solution à court terme avant de pouvoir mettre à niveau les clusters consiste à augmenter manuellement les limites de processeur pour metrics-server comme suit:
Supprimez la ligne --config-dir=/etc/config et augmentez les limites de processeur, comme illustré 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 metrics-server pour appliquer les modifications.
Mise en réseau
1,14 ; 1,15 ; 1,16
La connexion directe NodePort au 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 ciblé. Ce problème affecte les services LoadBalancer lorsqu'ils sont utilisés avec des pods hostNetwork. Avec plusieurs backends, il peut y avoir une défaillance 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 l'un des pods de backend est exécuté. Lorsque vous utilisez le service LoadBalancer, assurez-vous que les pods hostNetwork-ed ne s'exécutent pas sur des 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 de la version 1.12.3
Les clusters d'administrateur qui exécutent la version 1.13.0 ne peuvent pas gérer les clusters d'utilisateur qui exécutent la version 1.12.3. Les opérations exécutées sur un cluster d'utilisateur de la 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 comportant des pools de nœuds de calcul
Les clusters d'administrateur version 1.13.0 ou ultérieure ne peuvent pas contenir de pools de nœuds de calcul.
Les mises à niveau vers la version 1.13.0 ou une version 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 de 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 des clusters d'utilisateur. Pour savoir comment ajouter et supprimer des pools de nœuds, consultez la page 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 vos modifications d'entrée et planifiées.
Par exemple, vous pouvez essayer de modifier la ressource personnalisée Stackdriver comme suit. Pour ce faire, commencez par récupérer la ressource, puis appliquez une version mise à jour:
Activer des fonctionnalités ou mettre à jour la configuration dans le fichier YAML
Appliquez à nouveau le fichier YAML mis à jour :
kubectl apply -f stackdriver.yaml
La dernière étape pour kubectl apply est l'endroit où vous risquez de rencontrer des problèmes.
Solution :
N'utilisez pas kubectl apply pour modifier les ressources existantes. Utilisez plutôt kubectl edit ou kubectl patch, comme indiqué dans les exemples suivants:
Des fragments de backlog corrompus provoquent une boucle de plantage de stackdriver-log-forwarder
stackdriver-log-forwarder plante en boucle s'il tente de traiter un fragment de backlog corrompu. Les exemples d'erreurs suivants sont affichés dans les journaux du 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, les journaux ne s'affichent pas dans Cloud Logging.
Solution :
Pour résoudre ces erreurs, procédez comme suit:
Identifiez les fragments de backlog corrompus. Examinez 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 responsable du problème. Chaque fichier *.flb dont la vérification du format a échoué doit être supprimé.
Mettez fin aux pods en cours d'exécution pour stackdriver-log-forwarder :
Remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.
Vérifiez que les pods stackdriver-log-forwarder sont supprimés avant de passer à l'étape suivante.
Connectez-vous au nœud à l'aide de SSH, où stackdriver-log-forwarder est exécuté.
Sur le nœud, supprimez tous les fichiers *.flb corrompus dans var/log/fluent-bit-buffers/tail.1/.
Si le nombre de fichiers corrompus est trop important et que vous souhaitez appliquer un script pour nettoyer tous les fragments de backlog, utilisez les scripts suivants :
Déployez un DaemonSet pour nettoyer toutes les données modifiées dans les tampons dans fluent-bit :
Mise en réseau, environnement d'exécution des VM sur GDC
1.14.0
Le redémarrage de Dataplane V2 (anetd) sur les clusters peut empêcher les VM existantes de s'associer à un réseau autre qu'un pod
Sur les clusters dotés de plusieurs cartes d'interface réseau, le redémarrage de Dataplane V2 (anetd) peut empêcher les machines virtuelles de s'associer aux réseaux. Une erreur semblable à la suivante peut être observée dans les journaux des pods anetd:
could not find an allocator to allocate the IP of the multi-nic endpoint
Solution :
Le redémarrage de la VM constitue une solution rapide. Pour éviter que le problème se reproduise, mettez à niveau votre cluster vers la version 1.14.1 ou une version ultérieure.
Opération
1.13, 1.14.0, 1.14.1
gke-metrics-agent ne présente aucune limite de mémoire sur les clusters de profil périphérique
Selon la charge de travail du cluster, gke-metrics-agent peut utiliser plus de 4 608 Mio de mémoire. Ce problème ne concerne que les clusters de profil en périphérie GKE sur une solution Bare Metal. Les clusters de profil par défaut ne sont pas affectés.
Solution :
Mettez à niveau votre cluster vers la version 1.14.2 ou une version ultérieure.
Installation
1,12, 1,13
La création du cluster peut échouer en raison des conditions de concurrence
Lorsque vous créez des clusters à l'aide de kubectl, en raison des conditions de concurrence, la vérification préliminaire peut ne jamais se terminer. Par conséquent, la création du cluster peut échouer dans certains cas.
Le rapprochement des vérifications préliminaires 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 exploite les références au propriétaire et procède au rapprochement une fois la SecretForwarder terminée. Toutefois, dans de rares cas, les références propriétaire de l'élément SecretForwarder peuvent perdre la référence à la vérification préliminaire, ce qui peut entraîner son blocage. Par conséquent, la création du cluster échoue. Afin de poursuivre le rapprochement pour la vérification préliminaire pilotée par le contrôleur, supprimez le pod cluster-operator ou la ressource de vérification préliminaire. Lorsque vous supprimez la ressource de vérification préliminaire, elle en crée une autre et poursuit le rapprochement. 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 de localisation avec la fonctionnalité de cartes d'interface réseau multiples
Dans la fonctionnalité Multi-Nic, si vous utilisez le plug-in de localisation CNI et que vous utilisez 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 1.10.x. Lorsque le détecteur de problèmes de nœuds é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
Mettez à niveau le cluster d'administrateur vers la version 1.11.3 pour résoudre le problème.
Opération
1,14
Les nœuds de cluster IPv4 en mode insulaire 1.14 ont une taille de masque CIDR du 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).nCela peut entraîner l'épuisement du nombre d'adresses IP de pods plus tôt que prévu. Par exemple, si votre cluster a un masque CIDR de pod 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 au maximum. Votre cluster peut également rencontrer une instabilité du réseau en période de perte d'utilisateurs de pods élevée, lorsque maxPodsPerNode est défini sur 129 ou plus, et que la surcharge du CIDR des pods est insuffisante pour chaque nœud.
Si votre cluster est concerné, le pod anetd signale l'erreur suivante lorsque vous ajoutez un nœud au cluster et qu'aucun élément podCIDR n'est disponible:
error="required IPv4 PodCIDR not available"
Solution
Pour résoudre le problème, procédez comme suit:
Effectuez la mise à niveau vers la version 1.14.1 ou une version ultérieure.
Supprimez les nœuds de calcul, puis rajoutez-les.
Supprimez les nœuds du plan de contrôle, puis rajoutez-les, 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
Un rollback de mise à niveau peut échouer pour les clusters de la 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 d'effectuer un rollback vers la version 1.14.0 à l'aide de la commande bmctl restore cluster, une erreur semblable à l'exemple suivant peut s'afficher:
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 répertoriées à l'étape précédente :
Remplacez HEALTHCHECK_RESOURCE_NAME par le nom des ressources de vérification d'état.
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 dont le champ flatIPv4 est défini sur true, les services de type LoadBalancer ne sont pas accessibles via leur adresse IP externe.
Ce problème a été 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'option --use-bootstrap=false, la mise à niveau ne se termine jamais.
En raison d'une erreur avec l'opérateur preflight-check, le cluster ne planifie jamais les vérifications requises, ce qui signifie que la vérification préliminaire ne se termine jamais.
Solution :
Effectuez d'abord la mise à niveau vers 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'option --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 des rejets principaux
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 ceux-ci. Lorsque vous mettez à niveau des clusters GKE de la version 1.13 vers la version 1.14.0, les nœuds du plan de contrôle perdent les rejets requis suivants:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Ce problème ne provoque pas d'échecs de mise à niveau, mais les 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 surcharger les nœuds du plan de contrôle et provoquer une instabilité du cluster.
Déterminer si vous êtes concerné
Pour rechercher 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, exécutez la commande suivante :
Si aucun des rejets requis n'est indiqué, vous êtes affecté.
Solution
Procédez comme suit pour chaque nœud de plan de contrôle du cluster de la version 1.14.0 concerné afin de restaurer la fonction appropriée. Ces étapes concernent le rejet 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 rejet PreferNoSchedule, ajustez les étapes en conséquence.
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 bénéficient pas de 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
La création de VM échoue par intermittence en raison d'erreurs d'importation
La création d'une machine virtuelle (VM) à l'aide de la commande kubectl virt create vm échoue rarement lors de l'importation d'une image. 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 collecte gérée dans les clusters 1.11 ne sont pas conservés dans les mises à niveau vers la version 1.12
Les composants de collecte gérée font partie de Managed Service pour Prometheus.
Si vous avez déployé manuellement des composants de collecte gérée dans l'espace de noms gmp-system de vos clusters en version 1.11, les ressources associées ne sont pas conservées lorsque vous passez à la version 1.12.
À partir de la version 1.12.0 des clusters, 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 collection gérées manuellement, procédez comme suit:
Sauvegardez toutes les ressources personnalisées PodMonitoring existantes.
Redéployez les ressources personnalisées PodMonitoring sur votre cluster mis à niveau.
Mises à niveau et mises à jour
1.13
Certains clusters de la version 1.12 utilisant l'environnement d'exécution de conteneurs Docker ne peuvent pas être mis à niveau vers la version 1.13
Si un cluster de la 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:
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.
Ce problème est plus susceptible de se produire avec les clusters Docker de la 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 gérer l'environnement d'exécution du conteneur Docker. Dans ce cas, les clusters ne comportent pas cette 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 conteneur 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 ou après l'annulation et avant de réessayer.
Installation
1.11
bmctl se ferme avant la fin de la création du cluster
La création d'un cluster peut échouer pour la version 1.11.0 de GDCV pour Bare Metal (ce problème est résolu dans la version 1.11.1 de GDCV pour Bare Metal). Dans certains cas, la commande bmctl create cluster se ferme prématurément et écrit des erreurs semblables à celle-ci 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 des artefacts de cluster et réinitialiser la machine de nœuds, exécutez la commande suivante :
bmctl reset -c USER_CLUSTER_NAME
Pour lancer l'opération de création du cluster, exécutez la commande suivante :
L'option --keep-bootstrap-cluster est importante en cas d'échec de la commande.
Si la commande de création du cluster aboutit, vous pouvez ignorer les étapes restantes. Sinon, continuez.
Exécutez la commande suivante pour obtenir la version du cluster d'amorçage :
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, containerd et d'un proxy HTTPS
La création du cluster échoue lorsque les conditions suivantes sont remplies:
Le cluster est configuré pour utiliser containerd comme environnement d'exécution du conteneur (nodeConfig.containerRuntime défini sur containerd dans le fichier de configuration du cluster, la valeur par défaut pour GDCV pour Bare Metal 1.13 et versions ultérieures).
Le cluster est configuré pour fournir plusieurs interfaces réseau, avec plusieurs cartes d'interface réseau, aux 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 tentez de créer un cluster. Ce paramètre de proxy peut s'afficher en tant que variable d'environnement HTTPS_PROXY ou dans votre configuration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).
Solution
Ajoutez des CIDR de service (clusterNetwork.services.cidrBlocks) à la variable d'environnement NO_PROXY sur toutes les machines de nœuds.
Installation
1.10, 1.11, 1.12
Défaillance sur les systèmes dont le paramètre umask est restrictif
La version 1.10.0 de GDCV pour Bare Metal 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 échecs d'installation ou de mise à niveau sur les systèmes dont le paramètre umask est plus restrictif sur 0077.
Solution
Réinitialisez les nœuds du plan de contrôle et définissez le paramètre umask sur 0022 sur toutes les machines du plan de contrôle. Une fois les machines mises à jour, relancez l'installation.
Vous pouvez également modifier les autorisations de répertoire et de fichier de /etc/kubernetes sur les machines du plan de contrôle pour continuer l'installation ou la mise à niveau.
Rend /etc/kubernetes et tous ses sous-répertoires lisibles dans le monde entier: chmod o+rx.
Rendez tous les fichiers appartenant à l'utilisateur root dans le répertoire (de manière récursive) /etc/kubernetes lisibles par tous (chmod o+r). Excluez les fichiers de clé privée (.key) de ces modifications, car ils ont déjà été créés avec les droits de propriété et les autorisations appropriés.
Rend /usr/local/etc/haproxy/haproxy.cfg lisible par tous les utilisateurs.
Le
groupe de contrôle v2 (cgroup v2) n'est pas compatible avec les clusters GKE sur les clusters Bare Metal 1.13 et versions antérieures de la GDCV pour Bare Metal. Cependant, la version 1.14 est compatible avec cgroup v2 en tant que fonctionnalité de 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.
Vérifications préliminaires et identifiants du compte de service
Pour les installations déclenchées par des clusters d'administrateur ou hybrides (en d'autres termes, des clusters non créés avec bmctl, tels que des clusters d'utilisateur), la vérification préliminaire ne vérifie pas les identifiants du compte de service Google Cloud ni les autorisations associées.
Lors de l'installation de clusters GKE sur 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 associé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 GKE sur Bare Metal.
Solution
Exécutez la commande suivante sur chaque nœud pour vérifier les valeurs actuelles de ces indicateurs:
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 telles que les suivantes:
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Dans RHEL 8.4, ethtool indique parfois que ces indicateurs sont désactivés alors qu'ils ne le sont pas. Pour désactiver explicitement ces indicateurs, 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 indicateurs 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 anté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 version 1.N-1.Y, même si le cluster d'administrateur est également à la version 1.N.X.
Si vous êtes concerné par ce problème, vous devriez voir des journaux semblables à ce qui suit 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 de 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 du cluster vers la version 1.12.1 peuvent être bloquées
La mise à niveau des clusters vers la version 1.12.1 échoue parfois en raison de l'indisponibilité du serveur d'API. 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 points, 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. Par défaut, les journaux de mise à niveau se trouvent dans /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP.
Le upgrade-cluster.log peut contenir des erreurs telles que les suivantes:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Le journal de la machine peut contenir des erreurs telles que les suivantes (les échecs répétés indiquent que vous êtes concerné par ce problème) :
HAProxy et Keepalife doivent s'exécuter sur chaque nœud du plan de contrôle avant de réessayer 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:
Si HAProxy ou KeepaLive ne s'exécute pas sur un nœud, redémarrez kubelet sur le nœud:
systemctl restart kubelet
Mises à niveau et mises à jour, environnement d'exécution des VM sur GDC
1,11, 1,12
La mise à niveau des clusters vers la version 1.12.0 ou une version ultérieure échoue lorsque l'environnement d'exécution des VM sur GDC est activé
Dans la version 1.12.0 des clusters GKE sur Bare Metal, toutes les ressources liées à l'environnement d'exécution des VM sur GDC sont migrées vers l'espace de noms vm-system afin de mieux prendre en charge la version en disponibilité générale de l'environnement d'exécution de VM sur GDC. Si l'environnement d'exécution des VM sur GDC est activé dans un cluster de version 1.11.x ou antérieure, la mise à niveau vers la version 1.12.0 ou une version ultérieure échoue, sauf si vous avez préalablement désactivé l'environnement d'exécution de 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 des VM sur GDC:
Modifiez la ressource personnalisée VMRuntime :
kubectl edit vmruntime
Définissez enabled sur false dans la spécification :
Mise à niveau bloquée sur error during manifests operations
Dans certains cas, les mises à niveau du cluster échouent et la CLI bmctl ne répond plus. Ce problème peut être dû à une ressource mise à jour de manière incorrecte. Pour déterminer si vous êtes concerné par ce problème et le corriger, consultez les journaux anthos-cluster-operator et recherchez les 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 signalent une ressource mise à jour de manière incorrecte, où {RESOURCE_NAME} est le nom de la ressource problématique.
Solution
Si vous trouvez ces erreurs 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 comportant des fonctionnalités qui utilisent la passerelle réseau pour GDC
Les mises à niveau des clusters de la version 1.10.x vers la version 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 toutes deux la passerelle réseau pour GDC. Les mises à niveau du cluster sont bloquées au niveau du message de ligne de commande Waiting for upgrade to complete..., et anthos-cluster-operator consigne des erreurs semblables à ce qui suit:
apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...
Solution
Pour débloquer la mise à niveau, exécutez les commandes suivantes sur le cluster que vous mettez à niveau:
bmctl update ne supprime pas les blocs de maintenance
La commande bmctl update ne peut pas supprimer ni modifier la section maintenanceBlocks de la configuration des ressources de cluster.
Solution
Pour en savoir plus, y compris sur la manière de supprimer des nœuds du mode maintenance, consultez la page Mettre les nœuds en mode maintenance.
Opération
1.10, 1.11, 1.12
Nœuds retirés du nœud si vous n'utilisez pas la procédure en mode de maintenance
Si vous exécutez des clusters en version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou antérieure et que vous utilisez manuellement kubectl cordon sur un nœud, GKE sur Bare Metal peut marquer le nœud comme non ordonnançable avant que vous ne soyez prêt à rapprocher l'état attendu.
Solution
Pour les clusters version 1.12.0 et antérieures, utilisez le mode de maintenance pour marquer les nœuds comme non ordonnançables et les drainer en toute sécurité.
Dans la version 1.12.1 (anthosBareMetalVersion: 1.12.1) ou ultérieure, GKE sur Bare Metal ne marque pas les nœuds comme ordonnançables de manière inattendue lorsque vous utilisez kubectl cordon.
Opération
1.11
Les clusters d'administrateur 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 sur la version 1.11 et utilise un miroir de registre, il ne peut pas gérer les clusters d'utilisateur s'il s'agit d'une version mineure inférieure. Ce problème affecte les opérations de réinitialisation, de mise à jour et de mise à niveau du cluster d'utilisateur.
Pour déterminer si ce problème vous concerne, recherchez dans vos journaux 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é
La commande bmctl check cluster, lorsqu'elle est exécutée sur des clusters d'utilisateur, remplace le secret kubeconfig du cluster d'utilisateur par le fichier kubeconfig du cluster d'administrateur. L'écrasement de ce fichier entraîne l'échec des opérations standards, telles que la mise à jour et la mise à niveau, pour les clusters d'utilisateur concernés. Ce problème s'applique aux versions 1.11.1 et antérieures des clusters GKE sur Bare Metal.
Pour déterminer si ce problème affecte un cluster d'utilisateur, exécutez la commande suivante:
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 espaces de noms des clusters GKE sur Bare Metal 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 résultat suivant) est le nom du cluster d'administrateur, le cluster d'utilisateur spécifié est affecté.
Les étapes suivantes permettent de restaurer la fonction sur un cluster d'utilisateur concerné (USER_CLUSTER_NAME):
Localisez le fichier kubeconfig du cluster d'utilisateur. GKE sur 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 est le bon du cluster d'utilisateur kubeconfig :
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 détails sur les nœuds du cluster d'utilisateur. Vérifiez que les noms des machines sont corrects pour votre cluster.
Exécutez la commande suivante pour supprimer le fichier kubeconfig corrompu dans le cluster d'administrateur :
Prendre un instantané en tant qu'utilisateur de connexion non racine
Si vous utilisez containerd comme environnement d'exécution du conteneur, l'exécution de l'instantané en tant qu'utilisateur non racine nécessite que /usr/local/bin se trouve dans le chemin d'accès de l'utilisateur.
Sinon, elle échouera 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 d'instantané. Le PATH sudo peut différer du profil racine et ne peut 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) utilise une expression régulière incorrecte pour le temps d'analyse, les journaux du pod stackdriver-log-forwarder contiennent des erreurs et des avertissements tels que:
[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 une version 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 éviter l'annulation des modifications suivantes, réduisez la taille de stackdriver-operator :
[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
Pour les versions de cluster GKE sur Bare Metal 1.10 à 1.15, certains clients ont constaté une facturation anormalement élevée pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que si toutes les conditions suivantes s'appliquent:
La surveillance des applications est activée (enableStackdriverForApplications=true)
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:
Des options distinctes pour contrôler la collecte des journaux d'application par rapport aux métriques d'application
Google Cloud Managed Service pour Prometheus dans un package
Si vous ne parvenez pas à passer à la version 1.12, procédez comme suit:
Recherchez les pods et services sources concernés par 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é élevée de pods peut, dans des cas extrêmes, entraîner une surcharge de journalisation et de surveillance excessive, ce qui peut entraîner l'arrêt et le redémarrage du serveur de métriques. Vous pouvez modifier le ConfigMap metrics-server-config pour allouer plus de ressources afin que le service de métriques puisse fonctionner. Toutefois, en raison du rapprochement, la valeur par défaut des modifications apportées à metrics-server-config peut être rétablie 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 la prochaine fois qu'il redémarre, il récupère le ConfigMap annulé et est à nouveau vulnérable à une surcharge excessive.
Solution
Pour la version 1.11.x, vous pouvez créer un script pour la modification du ConfigMap et l'exécuter ainsi que des mises à jour ou des mises à niveau du cluster. À partir de la version 1.12, 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 GKE sur Bare Metal sont obsolètes. Depuis la version 1.11 de la GDCV pour Bare Metal, 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, aucune donnée ne pourra déclencher la condition d'alerte.
Le tableau suivant répertorie les métriques individuelles qui sont obsolètes et la métrique qui les remplace.
Dans les versions de cluster GKE sur Bare Metal antérieures à la version 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 les 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 et supprimez le tableau de bord État du nœud de cluster Anthos.
Cliquez sur l'onglet Exemple de bibliothèque et réinstallez le tableau de bord État du nœud de cluster Anthos.
"stackdriver-log-forwarder" comporte des erreurs CrashloopBackOff
Dans certains cas, l'agent Logging fluent-bit peut rester bloqué lors du traitement des fragments corrompus. Lorsque l'agent Logging ne parvient pas à contourner les fragments corrompus, vous pouvez constater que stackdriver-log-forwarder continue de planter et génère une erreur CrashloopBackOff. Si vous rencontrez ce problème, vos journaux contiennent des entrées semblables à ce qui suit :
[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 mémoire 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.
Erreur de métriques inconnue dans le journal gke-metrics-agent
gke-metrics-agent est un daemonset qui collecte des métriques sur chaque nœud et les transmet à Cloud Monitoring. Il peut générer les journaux suivants:
Ces journaux d'erreurs peuvent être ignorés en toute sécurité, car les métriques auxquelles ils font référence ne sont pas compatibles et ne sont pas essentielles à des fins de surveillance.
Journalisation et surveillance
1,10, 1,11
Interruptions intermittentes de l'exportation de métriques
Les clusters GKE sur Bare Metal peuvent subir des interruptions lors de l'exportation normale et continue des métriques, ou des métriques manquantes sur certains nœuds. Si ce problème affecte vos clusters, vous constaterez peut-être des écarts de données pour les métriques suivantes (au minimum):
Pour faire passer la demande de processeur pour gke-metrics-agent de 10m à 50m, ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver :
La commande trouve 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
La présence de plusieurs passerelles par défaut dans un nœud peut entraîner une interruption de la 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 de ressources personnalisées de mise en réseau sur les clusters d'utilisateur sont écrasées
Les clusters GKE sur Bare Metal version 1.12.x ne vous empêchent pas de modifier manuellement les ressources personnalisées réseau dans votre cluster d'utilisateur. GKE sur Bare Metal rapproche les ressources personnalisées des clusters d'utilisateur avec les ressources personnalisées de votre cluster d'administrateur lors des mises à niveau du cluster. Ce rapprochement écrase toutes les modifications apportées directement aux ressources personnalisées de mise en réseau dans le cluster d'utilisateur. Les ressources réseau personnalisées ne doivent être modifiées que dans le cluster d'administrateur, mais la version 1.12.x des clusters n'applique pas cette exigence.
Vous modifiez ces ressources personnalisées dans votre cluster d'administrateur, et l'étape de rapprochement 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 en conséquence avant la mise à niveau. Cette étape permet de garantir que vos modifications de configuration sont conservées. Les versions 1.13.0 et ultérieures des clusters GKE sur Bare Metal vous empêchent de modifier directement les ressources personnalisées de mise en réseau de 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
GKE sur Bare Metal configure le filtrage du chemin 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 du délai avant expiration de la communication hors nœud.
Le filtrage du chemin inverse est défini avec des 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 inverse dans un fichier de configuration de sécurité réseau tel que /etc/sysctl.d/60-gce-network-security.conf.
Solution
Vous pouvez restaurer la connectivité des pods en effectuant l'une des solutions suivantes:
Redéfinissez manuellement la valeur de net.ipv4.conf.all.rp_filter sur 0, puis exécutez la commande 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, utilisez les commandes suivantes afin de localiser et de supprimer le pod anetd. Un nouveau pod anetd démarrera alors à sa place:
Après avoir appliqué 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.
Chevauchement des adresses IP du cluster d'amorçage (genre) et des adresses IP des nœuds du 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 échoueront si elles chevauchent les adresses IP des machines des nœuds du cluster.
Solution
Pour éviter tout conflit, vous pouvez transmettre les options --bootstrap-cluster-pod-cidr et --bootstrap-cluster-service-cidr à bmctl pour spécifier différentes valeurs.
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'arrêt 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 à toutes les versions des clusters GKE sur Bare Metal.
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-*
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 du conteneur et que SELinux est activé sur votre système d'exploitation, il est possible que le fichier 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 semblable à celle-ci s'affiche:
Pour contourner ce problème, effectuez l'une des modifications suivantes :
Désactivez SELinux.
N'utilisez pas la fonctionnalité VOLUME dans le fichier 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 GKE sur des clusters Bare Metal, le détecteur de problèmes de nœuds n'est pas activé par défaut. Ce problème concerne les 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èmes de nœuds:
Vérifiez si le service node-problem-detector systemd est en cours d'exécution sur le nœud.
Utilisez la commande SSH et connectez-vous 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, cela signifie que le détecteur de problème de nœud n'est pas en cours d'exécution sur le nœud.
Pour activer le détecteur de problèmes de nœuds, exécutez la commande kubectl edit et modifiez le fichier ConfigMap node-problem-detector-config. Pour en savoir plus, consultez la page Détecteur de problèmes de nœuds.
Opération
1,9, 1,10
Échec de la sauvegarde du cluster lors de l'utilisation d'une connexion non racine
La commande bmctl backup cluster échoue si nodeAccess.loginUser est défini sur un nom d'utilisateur non racine.]
Solution :
Ce problème concerne les versions 1.9.x, 1.10.0 et 1.10.1. Il est résolu dans les versions 1.10.2 et ultérieures.
Mise en réseau
1.10, 1.11, 1.12
Les services d'équilibrage de charge ne fonctionnent pas avec les conteneurs du réseau hôte du plan de contrôle
Dans anetd, les paquets sont supprimés pour les services LoadBalancer si les pods backend s'exécutent à la fois sur le nœud de plan de contrôle et utilisent le champ hostNetwork: true dans la spécification du conteneur.
Le bug n'existe pas dans la version 1.13 ou ultérieure.
Solution :
Les solutions de contournement suivantes peuvent vous aider si vous utilisez un service LoadBalancer reposant sur des pods hostNetwork:
Exécutez-les sur des nœuds de calcul (pas sur des nœuds de plan de contrôle).
Le pod anthos-version-$version$ orphelin n'a pas réussi à extraire l'image
La mise à niveau du cluster de la version 1.12.x vers la version 1.13.x peut observer un échec du pod anthos-version-$version$ avec une erreur "ImagePullBackOff".
Cela se produit, car la condition de concurrence de anthos-cluster-operator est mise à niveau et cela ne devrait pas affecter les fonctionnalités standards des clusters.
Le bug n'existe plus à partir de la version 1.13.
Solution :
Supprimez la tâche de dynamic-version-installer par kubectl delete job anthos-version-$version$ -n kube-system
.
Mises à niveau et mises à jour
1.13
Les clusters 1.12 mis à niveau depuis la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0
Les clusters de la 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 dans la version 1.12.
Pour déterminer si vous êtes concerné, consultez les journaux de la tâche de mise à niveau contenant la chaîne upgrade-first-no* dans le cluster d'administrateur.
Si le message d'erreur suivant s'affiche, cela signifie que vous êtes concerné.
Utilisation élevée du processeur pour stackdriver-operator
stackdriver-operator présente un problème qui entraîne une consommation de temps CPU plus élevée que d'habitude. L'utilisation normale du processeur est inférieure à 50 milliCPU (50m) pour stackdriver-operator en état inactif. La cause est une non-concordance des ressources de certificat que stackdriver-operator applique avec les attentes de cert-manager. Cette non-concordance entraîne une condition de concurrence entre cert-manager et stackdriver-operator lors de la mise à jour de ces ressources.
Ce problème peut réduire les performances sur les clusters ayant une disponibilité limitée des processeurs.
Solution :
En attendant de pouvoir passer à une version qui corrige ce bug, utilisez la solution suivante:
Pour réduire temporairement le nombre d'instances répliquées de stackdriver-operator à zéro, appliquez une ressource personnalisée AddonConfiguration :
La récupération des métriques basées sur les annotations ne fonctionne pas
Dans la version mineure GDCV pour Bare Metal 1.16, 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 utilisez une collecte de métriques déclenchée par les annotations prometheus.io/scrape sur vos charges de travail, vous pouvez utiliser l'indicateur de porte de fonctionnalité annotationBasedApplicationMetrics pour conserver l'ancien comportement. Cependant, un problème empêche le bon fonctionnement de annotationBasedApplicationMetrics, ce qui empêche la collecte de métriques depuis les applications dans Cloud Monitoring.
Solution :
Pour résoudre ce problème, mettez à niveau votre cluster vers la version 1.16.2 ou une version ultérieure.
La collecte de métriques de charge de travail basée sur les annotations activée par la porte de fonctionnalité annotationBasedApplicationMetrics collecte des métriques pour les objets comportant l'annotation prometheus.io/scrape. De nombreux systèmes logiciels à l'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 pour ne pas être surpris par les frais liés aux métriques dans Cloud Monitoring.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/05/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/05/03 (UTC)."],[],[]]
Tableaux de bord et supprimez le tableau de bord État du nœud de cluster Anthos.