Cette page répertorie tous les problèmes connus liés aux clusters Anthos sur bare metal. Pour filtrer les problèmes connus par version ou catégorie de produit, sélectionnez les filtres de votre choix dans les menus déroulants suivants.
Sélectionnez la version de vos clusters Anthos sur bare metal :
Sélectionnez la catégorie de problème que vous rencontrez :
Vous pouvez également rechercher le problème rencontré:
Catégorie
Version(s) identifiée(s)
Problème et solution
Mise en réseau, fonctionnement
1.10, 1.11, 1.12, 1.13 et 1.14
Composants de la passerelle réseau Anthos évincés ou en attente, car la classe de priorité est manquante
Les pods de passerelle réseau dans kube-system peuvent afficher l'état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé suivant:
Ces erreurs indiquent des événements d'éviction ou une incapacité à planifier les pods en raison de ressources de nœuds. Comme les pods de passerelle réseau Anthos n'ont pas de PriorityClass, ils ont la même priorité par défaut que les autres charges de travail.
Lorsque les nœuds sont limités en ressources, les pods de passerelle réseau peuvent être évincés. Ce comportement est particulièrement mauvais pour le DaemonSet ang-node, car ces pods doivent être planifiés sur un nœud spécifique et ne peuvent pas être migrés.
Solution :
Passez à la version 1.15 ou ultérieure.
Pour résoudre ce problème à court terme, vous pouvez attribuer manuellement une classe PriorityClass aux composants de la passerelle réseau Anthos. Le contrôleur de clusters Anthos sur bare metal écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau d'un 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 Class de classe system-node-critical au DaemonSet du nœud ang-daemon.
Installation, mises à niveau et mises à jour
1.15.0, 1.15.1, 1.15.2
La création et la mise à niveau des clusters échouent en raison de leur longueur
La création des clusters de la version 1.15.0, 1.15.1 ou 1.15.2 ou la mise à niveau vers la version 1.15.0, 1.15.1 ou 1.15.2 échoue s'ils comportent plus de 48 caractères (version 1.15.0) ou 45 caractères (version 1.15.1 ou 1). Lors des opérations de création et de mise à niveau des clusters, les clusters Anthos sur bare metal créent une ressource de vérification de l'état d'état dont le nom intègre 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.
Si ce problème vous concerne, la réponse contient un avertissement pour un ReconcileError comme suit:
...
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 d'état. Exécutez la commande suivante pour appliquer un correctif à la ressource personnalisée de vérification d'état: (status: {pass: true}).
Les clusters version 1.14.0 et 1.14.1 avec fonctionnalités d'aperçu ne peuvent pas être mis à niveau vers la version 1.15.x
Si une fonctionnalité d'aperçu est activée sur les clusters version 1.14.0 et 1.14.1, ils ne peuvent pas passer à la version 1.15.x. Cela s'applique à des fonctionnalités en preview, telles que la possibilité de créer un cluster sans kube-proxy, qui est activé avec l'annotation suivante dans le fichier de configuration du cluster:
Si vous êtes affecté par ce problème, vous obtenez un message d'erreur semblable à celui-ci lors de la mise à niveau du cluster:
[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version
Ce problème est résolu dans les clusters Anthos sur bare metal version 1.14.2 ou ultérieure.
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 passer directement à la version 1.15.x en utilisant un cluster d'amorçage:
bmctl upgrade cluster --use-bootstrap=true
Opération
1.15
Les clusters version 1.15 n'acceptent pas les adresses IP flottantes en double
La passerelle réseau Anthos ne vous permet pas de créer des ressources personnalisées NetworkGatewayGroup contenant des adresses IP dans spec.floatingIPs qui sont déjà utilisées dans des ressources personnalisées NetworkGatewayGroup existantes. Cette règle est appliquée par un webhook dans les clusters Anthos sur bare metal version 1.15.0 ou ultérieure. Les adresses IP flottantes en double existantes ne génèrent pas d'erreurs. Le webhook empêche uniquement la création de ressources personnalisées NetworkGatewayGroups contenant des adresses IP en double.
Le message d'erreur du webhook identifie l'adresse IP en conflit et la ressource personnalisée existante qui l'utilise déjà:
IP address exists in other gateway with name default
La documentation initiale sur les fonctionnalités réseau avancées, telles que la passerelle de sortie NAT, ne tient pas compte des adresses IP en double.
Au départ, seule la ressource NetworkGatewayGroup nommée default a été reconnue par le rapprochement. La passerelle réseau Anthos reconnaît désormais l'ensemble des ressources personnalisées NetworkGatewayGroup dans l'espace de noms du système. Les ressources personnalisées NetworkGatewayGroup existantes sont honorées telles quelles.
Solution :
Des erreurs se produisent lors de la création d'une ressource personnalisée NetworkGatewayGroup uniquement.
Pour corriger l'erreur:
Utilisez la commande suivante pour répertorier les ressources personnalisées NetworkGatewayGroups:
kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
-n kube-system -o yaml
Ouvrez les ressources personnalisées NetworkGatewayGroup existantes et supprimez toutes 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 des VM Anthos
1.13.7
Les VM peuvent ne pas démarrer sur des clusters 1.13.7 qui utilisent un registre privé
Lorsque vous activez l'environnement d'exécution des VM Anthos sur un cluster version 1.13.7 nouvelle ou mise à niveau qui utilise un registre privé, les VM qui se connectent au réseau de nœuds ou utilisent un GPU peuvent ne pas démarrer correctement. Ce problème est dû au fait que certains pods système de l'espace de noms vm-system obtiennent 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 comme suit:
macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m
Ce problème est résolu dans les clusters Anthos sur bare metal version 1.14.0 et supérieures.
Solution
Si vous ne parvenez pas à mettre à niveau vos clusters immédiatement, vous pouvez extraire des images manuellement. Les commandes suivantes extraient l'image du plug-in CNI macvtap de 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 et 1,12
Lors de la création du cluster dans le cluster de genre, le pod gke-metric-agent ne démarre pas
Lors de la création du cluster dans le cluster de genre, le pod gke-metrics-agent ne démarre pas en raison d'une erreur d'extraction d'image:
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"
En outre, 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"
Le pod affiche l'erreur suivante:
gcr.io/gke-on-prem-staging/gke-metrics-agent
Solution
Malgré les erreurs, le processus de création de 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 de 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 de 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 de cluster, ainsi que pour le suivi et la surveillance internes.
Vous pouvez donc ignorer cette erreur.
Opération, mise en réseau
1.12, 1.13, 1.14, 1.15
L'accès à un point de terminaison de service IPv6 entraîne le plantage du nœud LoadBalancer sur CentOS ou RHEL
Lorsque vous accédez à un service double pile (un service qui comporte à 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 concerne les clients qui utilisent des services double pile avec CentOS ou RHEL, et la version du 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 kernel-4.18.0-372.46.1.el8_6 ou ultérieure du noyau. Cette version du noyau est disponible par défaut dans CentOS et RHEL 8.6 et versions ultérieures.
Mise en réseau
1.11, 1.12, 1.13, 1.14.0
Problèmes de connectivité intermittents après le redémarrage du nœud
Après avoir redémarré un nœud, vous pouvez rencontrer des problèmes de connectivité intermittents pour un service NodePort ou LoadBalancer. Par exemple, vous pouvez rencontrer des erreurs de handshake TLS intermittentes ou de réinitialisation de la connexion. Ce problème est résolu pour les clusters Anthos sur bare metal versions 1.14.1 et ultérieures.
Pour vérifier si ce problème vous concerne, consultez les règles de transfert iptables sur les nœuds sur lesquels le pod de backend du service concerné est en cours d'exécution:
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 affiche un nœud dans lequel le problème existe:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */
KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */
Solution :
Redémarrez le pod anetd sur le nœud mal configuré. Après avoir redémarré le pod anetd, la règle de transfert dans iptables doit être configurée correctement.
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 et 1,10
La fonctionnalité en preview ne conserve pas les informations d'origine concernant l'autorisation et le propriétaire
La fonctionnalité d'aperçu du cluster 1.9.x utilisant bmctl 1.9.x ne conserve pas les informations initiales 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 que metadata.json est présent et que bmctlVersion est 1.9.x. Si metadata.json n'est pas présent, effectuez une mise à niveau vers le cluster 1.10.x et utilisez bmctl 1.10.x pour effectuer une sauvegarde/restauration.
Migrations et créations
1.14.2
clientconfig-operator reste en attente avec CreateContainerConfigError
Si vous avez mis à niveau ou créé un cluster de version 1.14.2 avec une configuration OIDC/LDAP, le pod clientconfig-operator peut rester bloqué. Avec ce problème, deux pods clientconfig-operator sont en cours d'exécution, l'un en attente.
Ce problème s'applique uniquement aux clusters Anthos sur bare metal version 1.14.2. Les versions antérieures, telles que 1.14.0 et 1.14.1, ne sont pas concernées. Ce problème est résolu dans la version 1.14.3 et toutes les versions ultérieures, y compris la version 1.15.0 et ultérieures.
Solution :
Pour contourner ce problème, vous pouvez appliquer un correctif au déploiement clientconfig-operator afin d'ajouter un contexte de sécurité supplémentaire et 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 du cluster cible.
Opération
1.11, 1.12, 1.13, 1.14 et 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 affecté 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 échoue. Le journal de rotation des autorités de certification pour un cluster avec trois plans de contrôle peut inclure des entrées telles que:
[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")
ipam-controller-manager parcours dans les clusters à double pile
Lorsque vous déployez un cluster double pile (cluster avec des adresses IPv4 et IPv6), le ou les pods ipam-controller-manager peuvent planter. Ce comportement entraîne le basculement des nœuds entre les états Ready et NotReady, et peut entraîner l'échec de l'installation du cluster. Ce problème peut se produire lorsque le serveur d'API est soumis à une charge élevée.
Pour voir si ce problème vous concerne, vérifiez si le ou les pods ipam-controller-manager présentent des erreurs CrashLoopBackOff:
kubectl -n kube-system get pods | grep ipam-controller-manager
L'exemple de résultat suivant affiche les pods à l'état CrashLoopBackOff:
1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 et 1.14
etcd
Les clusters exécutant la version 3.4.13 ou antérieure d' etcd peuvent rencontrer des problèmes de surveillance des ressources 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
Kubelet n'observe pas les modifications du pod
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 et 1.14.3 des clusters Anthos sur bare metal et dans les versions ultérieures. Ces versions plus récentes utilisent la version 3.4.21 d'Etd. Toutes les versions précédentes des clusters Anthos sur bare metal sont affectées par ce problème.
Solution
Si vous ne pouvez pas procéder à une mise à niveau immédiate, vous pouvez réduire 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 et 1.12.3
État "Échec " de l'opérateur vfio-pci du mode SR-IOV
Le syncStatus de l'objet SriovNetworkNodeState peut signaler la valeur "Failed" pour un nœud configuré. Pour afficher l'état d'un nœud et déterminer si le problème vous concerne, exécutez la commande suivante:
kubectl -n gke-operators get \
sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
-o jsonpath='{.status.syncStatus}'
Remplacez NODE_NAME par le nom du nœud à vérifier.
Solution :
Si l'état de l'objet SriovNetworkNodeState est "Failed", passez aux clusters Anthos sur bare metal version 1.11.7 ou ultérieure ou 1.12.4 ou ultérieure.
Mises à niveau et mises à jour
1.10, 1.11, 1.12, 1.13, 1.14.0 et 1.14.1
Certains nœuds de calcul ne sont pas prêts pour la mise à niveau
Une fois la mise à niveau terminée, la condition Prêt de certains nœuds de calcul peut être définie sur false. Sur la ressource du nœud, une erreur s'affiche à côté de la condition 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 à une machine à l'arrêt, 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
La rotation de plusieurs certificats à partir de cert-manager entraîne des incohérences
Après plusieurs rotations de certificats manuelles ou automatiques, 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 se produire dans les cas suivants:
Vous avez effectué deux rotations de certificats manuelles effectuées par cert-manager sur un cluster de plus de 180 jours et n'avez jamais redémarré l'opérateur anthos-cluster-operator.
Si vous avez effectué une rotation manuelle des certificats cert-manager sur un cluster datant de plus de 90 jours ou plus et que vous n'avez jamais redémarré l'opérateur anthos-cluster-operator.
Solution
Redémarrez le pod en arrêtant anthos-cluster-operator.
Mises à niveau et mises à jour
1.14.0
Pods obsolètes de déployeurs de contrôleurs de cycle de vie créés lors de la mise à niveau du cluster d'utilisateur
Dans les clusters d'administrateur version 1.14.0, un ou plusieurs pods de déployeurs de contrôleurs de cycle de vie obsolètes peuvent être créés lors des mises à niveau des clusters d'utilisateur.
Ce problème s'applique aux clusters d'utilisateur initialement créés dans des versions antérieures à la version 1.12. Les pods créés par inadvertance n'empêchent pas les opérations de mise à niveau, mais ils peuvent se trouver dans un état anormal. 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 déployeurs de contrôleurs de cycle de vie obsolètes:
Répertoriez 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 de BGPSession change constamment en raison d'un grand nombre de routes entrantes
La mise en réseau avancée des clusters Anthos sur bare metal ne parvient pas à gérer correctement les sessions BGP lorsque des pairs externes annoncent un grand nombre de routes (environ 100 ou plus). Avec un grand nombre de routes entrantes, le contrôleur BGP local des nœuds 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, la session est supprimée pour cause d'obsolescence.
Voici quelques exemples de comportements indésirables sur les sessions BGP que vous pourriez remarquer et indiquer:
Suppression et recréation d'bgpsession en continu.
bgpsession.status.state ne devient jamais Established.
Routes ne diffusant pas d'annonces, ou dont la publicité et le retrait sont répétés.
Les problèmes d'équilibrage de charge BGP peuvent survenir en raison de problèmes de connectivité aux services LoadBalancer.
Le problème BGP de FlatIP peut être perceptible avec des problèmes de connectivité aux pods.
Pour déterminer si les problèmes BGP sont causés par les pairs distants qui annoncent trop de routes, utilisez les commandes suivantes pour examiner les états et le résultat associés:
Utilisez kubectl get bgpsessions sur le cluster concerné.
La sortie affiche bgpsessions avec l'état "Non établi" et la dernière heure du rapport compte jusqu'à environ 10 à 12 secondes avant qu'il ne soit remis à zéro.
La sortie de kubectl get bgpsessions indique que les sessions concernées sont recréées à plusieurs reprises:
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 leader de votre cluster.
Solution :
Réduisez ou supprimez le nombre de routes annoncées par le pair distant vers le cluster avec une règle d'exportation.
Dans les clusters Anthos sur bare metal version 1.14.2 ou ultérieure, 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 et 1,15
Délais d'expiration de l'application causés par les échecs d'insertion de la table conntrack
Les clusters exécutés sur un système d'exploitation Ubuntu exécutant le noyau 5.15 ou une version ultérieure sont susceptibles d'échouer lors de l'insertion d'une table netfilter. Des échecs d'insertion peuvent se produire même lorsque la table "conntrack" peut accueillir de nouvelles entrées. Les échecs sont dus à des modifications apportées à partir de la version 5.15 du noyau, qui restreignent l'insertion de la table en fonction de la longueur de la chaîne.
Pour savoir si vous êtes concerné par ce problème, vous pouvez consulter les statistiques système du système de suivi des connexions du noyau à l'aide de la commande suivante:
Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, 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 de connexion netfilter (nf_conntrack_max). Utilisez les commandes suivantes sur chaque nœud du cluster pour augmenter la taille des tables:
Remplacez TABLE_SIZE par une nouvelle taille en octets. La valeur de la taille de la table par défaut 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 les sauvegardes du cluster avec bmctl pour certaines versions
Nous vous recommandons de sauvegarder vos clusters avant la mise à niveau afin de pouvoir restaurer la version précédente en cas d'échec.
Un problème avec la commande bmctl restore cluster entraîne l'échec de la restauration des sauvegardes de clusters avec les versions identifiées. Ce problème est spécifique aux mises à niveau, où vous restaurez une sauvegarde d'une version antérieure.
Si votre cluster est affecté, 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 si nécessaire.
Mise en réseau
1.10, 1.11, 1.12, 1.13 et 1.14.0-1.14.2
NetworkGatewayGroup plante si aucune adresse IP ne s'affiche sur l'interface
NetworkGatewayGroup ne crée pas de daemons pour les nœuds qui ne comportent pas à la fois des interfaces IPv4 et IPv6. Cela entraîne l'échec de fonctionnalités telles que BGP LB et EgressNAT. Si vous vérifiez les journaux du pod ang-node défaillant dans l'espace de noms kube-system, des erreurs semblables à l'exemple suivant s'affichent lorsqu'il manque une adresse IPv6:
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'existe pas d'adresse IPv6 sur l'interface ens192. Des erreurs ARP similaires s'affichent si aucune adresse IPv4 n'est associée au nœud.
NetworkGatewayGroup tente d'établir une connexion ARP et une connexion NDP à l'adresse IP locale de la liaison. Si l'adresse IP n'existe pas (IPv4 pour ARP, IPv6 pour NDP), la connexion échoue et le daemon ne se poursuit pas.
Ce problème a été résolu dans la version 1.14.3.
Solution :
Connectez-vous au nœud à l'aide de SSH et ajoutez une adresse IPv4 ou IPv6 au lien contenant l'adresse IP du nœud. Dans l'exemple d'entrée de journal précédent, cette interface était ens192:
ip address add dev INTERFACE scope link ADDRESS
Remplacez les éléments suivants :
INTERFACE: interface de votre nœud, 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
anthos-cluster-operator boucle de plantage 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 de Cluster.Spec, anthos-cluster-operator entre dans une boucle de plantage qui bloque toutes les autres opérations.
Solution :
Problème résolu dans les versions 1.13.3 et 1.14.0 et ultérieures. Toutes les autres versions sont affectées. Mettre à 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 une boucle de plantage.
CLUSTER_NAMESPACE: espace de noms du cluster.
Installation
1.13.1, 1.13.2 et 1.13.3
kubeadm join échoue dans les clusters volumineux en raison d'une non-concordance des jetons
Lorsque vous installez des clusters Anthos sur bare metal avec un grand nombre de nœuds, un message d'erreur kubeadmin join 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 les clusters Anthos sur bare metal version 1.13.4 et ultérieure.
Si vous devez utiliser une version affectée, commencez par créer un cluster avec moins de 20 nœuds, puis redimensionnez le cluster pour ajouter des nœuds supplémentaires après l'installation.
Journalisation et surveillance
1.10, 1.11, 1.12 et 1.13.0
Limite de processeur faible pour metrics-server dans les clusters périphériques
Dans les clusters Anthos sur des clusters Edge 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 ne fonctionne pas, car metrics-server est non opérationnel.
Si la limite de processeur metrics-server est inférieure à 40m, vos clusters peuvent être affectés. Pour vérifier les limites de processeur metrics-server, examinez l'un des fichiers suivants:
Ce problème est résolu dans les clusters Anthos sur bare metal version 1.13.1 ou ultérieure. Pour résoudre ce problème, mettez à niveau vos clusters.
Une solution de contournement à court terme jusqu'à ce que vous puissiez mettre à niveau les clusters consiste à augmenter manuellement les limites de processeur pour metrics-server:
Supprimez la ligne --config-dir=/etc/config et augmentez les limites de processeur, comme indiqué dans l'exemple suivant:
[...]
- command:
- /pod_nanny
# - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase 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 et 1,15
La connexion directe NodePort au pod hostNetwork ne fonctionne pas
La connexion à un pod activé avec hostNetwork via le 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'il est utilisé avec des pods hostNetwork-ed. Avec plusieurs backends, il peut y avoir une défaillance sporadique de la connexion.
Ce problème est dû à un bug du programme eBPF.
Solution :
Lorsque vous utilisez un service Nodeport, ne ciblez pas le nœud sur lequel le pod de backend s'exécute. Lorsque vous utilisez le service LoadBalancer, assurez-vous que les pods hébergés par hostNetwork ne s'exécutent pas sur les nœuds LoadBalancer.
Mises à niveau et mises à jour
1.12.3 et 1.13.0
Les clusters d'administrateur 1.13.0 ne peuvent pas gérer 1.12.3 cluster(s) d'utilisateur
Les clusters d'administrateur exécutant la version 1.13.0 ne peuvent pas gérer les clusters d'utilisateur exécutant la version 1.12.3. Les opérations sur un cluster d'utilisateur 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 et supérieures 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 comportant des pools de nœuds de calcul sont bloquées. Si la mise à niveau du cluster d'administrateur est bloquée, vous pouvez vérifier si les pools de nœuds de calcul en sont la cause en vérifiant 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 de procéder à 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 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 et 1.15
Erreurs lors de la mise à jour des ressources avec kubectl apply
Si vous mettez à jour des ressources existantes telles que les ressources personnalisées ClientConfig ou Stackdriver à l'aide de kubectl apply, le contrôleur peut renvoyer une erreur ou annuler votre entrée et les modifications souhaitées.
Par exemple, vous pouvez essayer de modifier la ressource personnalisée Stackdriver comme suit : commencez par l'obtenir, puis appliquez une version mise à jour :
Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML.
Appliquez à nouveau le fichier YAML mis à jour:
kubectl apply -f stackdriver.yaml
La dernière étape pour kubectl apply est l'étape à laquelle vous pouvez rencontrer des problèmes.
Solution :
N'utilisez pas kubectl apply pour modifier les ressources existantes. Utilisez plutôt kubectl edit ou kubectl patch, comme illustré dans les exemples suivants:
Des fragments de tâches en attente corrompus génèrent stackdriver-log-forwarder boucle de plantage
Le plantage de stackdriver-log-forwarder se produit s'il tente de traiter un fragment de tâches en attente 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 tâches en attente corrompus. Consultez les exemples de messages d'erreur suivants:
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
Dans cet exemple, le fichier tail.1/1-1659339894.252926599.flb stocké dans var/log/fluent-bit-buffers/tail.1/ est responsable. 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 à votre fichier kubeconfig du 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 en cours d'exécution.
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 élevé et que vous souhaitez appliquer un script pour nettoyer tous les segments en attente, utilisez les scripts suivants :
Déployez un DaemonSet pour nettoyer toutes les données modifiées dans des tampons dans fluent-bit:
Mise en réseau, environnement d'exécution des VM Anthos
1.14.0
Si vous redémarrez Dataplane V2 (anetd) sur des clusters, les VM existantes ne pourront pas être associées à des réseaux autres que des pods
Sur les clusters dotés de plusieurs cartes 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 du pod anetd:
could not find an allocator to allocate the IP of the multi-nic endpoint
Solution :
Pour résoudre ce problème, vous pouvez redémarrer la VM. Pour éviter que le problème survienne à nouveau, passez aux clusters Anthos sur bare metal 1.14.1 ou version ultérieure.
Opération
1.13, 1.14.0 et 1.14.1
gke-metrics-agent n'a pas de limite de mémoire sur les clusters de profils périphériques
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 Anthos sur des clusters de profil Edge Bare Metal. Les clusters de profils 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 et 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, il est possible que les vérifications préliminaires ne soient jamais terminées en raison des conditions de concurrence. Par conséquent, la création de cluster peut échouer dans certains cas.
Le rapprochement de la vérification préliminaire crée un SecretForwarder pour copier le secret ssh-key par défaut dans l'espace de noms cible.
En règle générale, la vérification préliminaire s'appuie sur les références propriétaire et les rapprochements une fois la SecretForwarder terminée. Toutefois, dans de rares cas, les références du propriétaire de SecretForwarder peuvent perdre la référence à la vérification préliminaire, ce qui la bloque. Par conséquent, la création du cluster échoue. Pour continuer le rapprochement de la vérification préliminaire préliminaire basée sur le contrôleur, supprimez le pod de l'opérateur de cluster ou la ressource de vérification préalable. 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 et 1.15
Les adresses IP réservées ne sont pas libérées lors de l'utilisation du plug-in WHEREwhere avec la fonctionnalité avec plusieurs cartes d'interface réseau
Dans la fonctionnalité multi-nic, si vous utilisez le plug-in de destination CNI et que vous utilisez l'opération CNI DEL pour supprimer une interface réseau pour un pod, certaines adresses IP réservées risquent de ne pas être 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 (ippools) qui ne sont pas utilisées.
Installation
1.10, 1.11.0, 1.11.1 et 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 Anthos Bare Metal 1.10.x, lorsque les clusters d'administrateur Anthos Bare Metal 1.11.0, 1.11.1 ou 1.11.2 gèrent des clusters d'utilisateur 1.10.x. En cas de défaillance du détecteur de problèmes de nœuds, 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
1.14 Les nœuds de cluster IPv4 en mode île ont un masque CIDR de pod de 24
Dans la version 1.14, le paramètre maxPodsPerNode n'est pas pris en compte pour les clusters en mode insulaire. Par conséquent, les nœuds se voient attribuer une taille de masque CIDR de 24 (256 adresses IP). Le cluster risque alors de manquer d'adresses IP de pod plus que prévu. Par exemple, si le cluster a une taille de masque CIDR de 22 pods, un masque CIDR de pod de 24 sera attribué à chaque nœud, et le cluster ne pourra gérer que 4 nœuds au maximum. Votre cluster peut également subir une instabilité du réseau pendant une période de perte de pods élevée lorsque maxPodsPerNode est défini sur 129 ou plus et lorsque la surcharge du CIDR des pods est insuffisante pour chaque nœud.
Si votre cluster est affecté, le pod anetd signale l'erreur suivante lorsque vous ajoutez un nœud au cluster et qu'aucun podCIDR n'est disponible:
error="required IPv4 PodCIDR not available"
Solution
Pour résoudre le problème, procédez comme suit:
Passez à la version 1.14.1 ou à une version ultérieure.
Supprimez les nœuds de calcul et ajoutez-les à nouveau.
Supprimez les nœuds du plan de contrôle, puis ajoutez-les de préférence, un par un, afin d'éviter les temps d'arrêt du cluster.
Mises à niveau et mises à jour
1.14.0 et 1.14.1
Échec du rollback de la mise à niveau du cluster
Un rollback de mise à niveau peut échouer pour les clusters Anthos sur bare metal 1.14.0 vers la version 1.14.1.
Si vous mettez à niveau un cluster de la version 1.14.0 vers la version 1.14.1, puis essayez de 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 pour lequel flatIPv4 est défini sur true, les services de type LoadBalancer ne sont pas accessibles par leurs adresses IP externes.
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 et 1.14
Les mises à niveau sur place de la version 1.13.0 vers la version 1.14.x ne s'arrêtent jamais
Lorsque vous essayez d'effectuer une mise à niveau sur place de la version 1.13.0 vers la version 1.14.x à l'aide de bmctl 1.14.0 et de l'indicateur --use-bootstrap=false, la mise à niveau ne se termine jamais.
Une erreur liée à l'opérateur preflight-check empêche le cluster de planifier les vérifications requises, ce qui signifie que la vérification préliminaire ne se termine jamais.
Solution :
Effectuez 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'indicateur --use-bootstrap=false.
Mises à niveau et mises à jour, sécurité
1,13 et 1,14
Les clusters mis à niveau vers la version 1.14.0 perdent des rejets maîtres.
Les nœuds du plan de contrôle nécessitent l'un des deux rejets spécifiques pour empêcher la planification des pods de charge de travail sur ces nœuds. Lorsque vous mettez à niveau des clusters Anthos version 1.13 vers la version 1.14.0, les nœuds de plan de contrôle perdent les rejets requis suivants:
node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule
Ce problème n'entraîne pas d'échec de la 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 entraîner une instabilité de cluster.
Déterminer si vous êtes concerné
Recherchez les nœuds du plan de contrôle à l'aide de la commande suivante:
kubectl get node -l 'node-role.kubernetes.io/control-plane' \
-o name --kubeconfig KUBECONFIG_PATH
Pour vérifier la liste des rejets sur un nœud, utilisez la commande suivante:
Si aucun des rejets requis ne s'affiche, cela signifie que vous êtes concerné.
Solution
Procédez comme suit pour chaque nœud de plan de contrôle du cluster de 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 n'ont pas la tolérance node-role.kubernetes.io/master:NoSchedule:
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
Opération, environnement d'exécution des VM Anthos
1.11, 1.12, 1.13, 1.14 et 1.15
Échec de la création intermittente de la VM avec des erreurs d'importation
La création d'une machine virtuelle (VM) avec la commande kubectl virt create vm échoue rarement lors de l'importation de l'image. Ce problème s'applique à la fois 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
Réessayez la commande kubectl virt create vm pour créer votre VM.
Mises à niveau et mises à jour, journalisation et surveillance
1.11
Les composants de collections gérées dans les clusters 1.11 ne sont pas conservés dans les mises à niveau vers la version 1.12.
Les composants de collection gérée font partie de Managed Service pour Prometheus.
Si vous avez déployé manuellement des composants de collection gérée dans l'espace de noms gmp-system de vos clusters Anthos 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 Anthos sur bare metal, les composants de service géré 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 les composants Managed Service pour Prometheus dans l'espace de noms avant la mise à niveau vers la version 1.12, les ressources sont supprimées par stackdriver-operator.
Solution
Pour conserver des ressources de collection gérées manuellement:
Sauvegardez toutes les ressources personnalisées de PodMonitoring.
Redéployez les ressources personnalisées de PodMonitoring sur votre cluster mis à niveau.
Mises à niveau et mises à jour
1.13
Certains clusters version 1.12 avec l'environnement d'exécution de conteneurs Docker ne peuvent pas être mis à niveau vers la version 1.13
Si un cluster version 1.12 qui utilise l'environnement d'exécution de conteneurs Docker ne comporte pas l'annotation suivante, il ne peut pas être mis à niveau vers la version 1.13:
Si vous êtes affecté par ce problème, bmctl écrit l'erreur suivante dans le fichier upgrade-cluster.log du dossier bmctl-workspace:
Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.
Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.
Cela peut se produire avec les clusters Docker 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 maintenir l'environnement d'exécution du conteneur Docker. Dans ce cas, les clusters ne comportent pas l'annotation lorsqu'ils passent à 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 affecté par ce problème, mettez à jour la ressource du cluster avec l'annotation manquante. Vous pouvez ajouter l'annotation pendant la mise à niveau ou après l'annulation et avant de la relancer.
Installation
1.11
bmctl se ferme avant la fin de la création du cluster
La création de clusters peut échouer pour les clusters Anthos sur bare metal version 1.11.0 (ce problème est résolu dans la version 1.11.1 des clusters Anthos sur bare metal). Dans certains cas, la commande bmctl create cluster se ferme de façon anticipée et écrit des erreurs comme celles-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é génère des artefacts, mais le cluster n'est pas opérationnel. Si ce problème vous concerne, procédez comme suit pour nettoyer les artefacts et créer un cluster:
Afficher la procédure de contournement
Pour supprimer les artefacts du cluster et réinitialiser la machine de nœud, exécutez la commande suivante:
bmctl reset -c USER_CLUSTER_NAME
Pour lancer l'opération de création de cluster, exécutez la commande suivante :
L'option --keep-bootstrap-cluster est importante si cette commande échoue.
Si la commande de création de 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, de containerd et d'un proxy HTTPS
La création du cluster échoue lorsque vous combinez les conditions suivantes:
Le cluster est configuré pour utiliser containerd comme environnement d'exécution de conteneur (nodeConfig.containerRuntime défini sur containerd dans le fichier de configuration de cluster, la version par défaut pour les clusters Anthos sur bare metal version 1.13).
Le cluster est configuré pour fournir plusieurs interfaces réseau, à plusieurs cartes d'interface réseau, pour les pods (clusterNetwork.multipleNetworkInterfaces défini sur true dans le fichier de configuration du cluster).
Le cluster est configuré pour utiliser un proxy (spec.proxy.url est spécifié dans le fichier de configuration du cluster). Même si la création du cluster échoue, ce paramètre est propagé lorsque vous tentez de créer un cluster. Ce paramètre 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 les CIDR des services (clusterNetwork.services.cidrBlocks) à la variable d'environnement NO_PROXY sur toutes les machines de nœud.
Installation
1.10, 1.11, 1.12
Échec sur les systèmes avec le paramètre umask restrictif
La version 1.10.0 des clusters Anthos sur 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 avec un paramètre umask plus restrictif de 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. Relancez l'installation après la mise à jour des machines.
Vous pouvez également modifier les autorisations de répertoire et de fichier de /etc/kubernetes sur les machines de plan de contrôle pour l'installation ou la mise à niveau pour continuer.
/etc/kubernetes et tous ses sous-répertoires lisibles: chmod o+rx
Rendez tous les fichiers appartenant à l'utilisateur root dans le répertoire (de manière récursive) /etc/kubernetes lisibles dans le monde entier (chmod o+r). Excluez les fichiers de clé privée (.key) de ces modifications, car ils sont déjà créés avec les bonnes propriétés et autorisations.
Rendez /usr/local/etc/haproxy/haproxy.cfg utilisable dans le monde entier.
Rendez /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml utilisable dans le monde entier.
Installation
1.10, 1.11, 1.12 et 1.13
Incompatibilité du groupe de contrôle v2
Le
groupe de contrôle v2 (cgroup v2) n'est pas compatible avec les clusters Anthos sur bare metal versions 1.13 et antérieures. Cependant, la version 1.14 est compatible avec cgroup v2 en tant que fonctionnalité Preview
. La présence de /sys/fs/cgroup/cgroup.controllers indique que votre système utilise cgroup v2.
Solution
Si votre système utilise cgroup v2, passez à la version 1.14 des clusters Anthos sur bare metal.
Installation
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
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, comme des clusters d'utilisateur), la vérification préliminaire ne vérifie pas les identifiants du compte de service Google Cloud ni leurs autorisations associées.
Installation
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Identifiants par défaut de l'application et bmctl
bmctl utilise les identifiants par défaut de l'application (ADC) pour valider la valeur de localisation de l'opération de cluster dans cluster spec lorsqu'elle n'est pas définie sur global.
Solution
Pour que l'ADC fonctionne, vous devez soit diriger la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS vers un fichier d'identifiants de compte de service, soit exécuter gcloud auth application-default login.
Installation
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Service Docker
Sur les machines de nœud de cluster, si l'exécutable Docker est présent dans la variable d'environnement PATH, mais que le service Docker n'est pas actif, la vérification préliminaire échouera et indiquera Docker service
is not active.
Solution
Supprimez Docker ou activez le service Docker.
Installation
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Installer sur vSphere
Lorsque vous installez des clusters Anthos sur bare metal sur des VM vSphere, vous devez désactiver les options tx-udp_tnl-segmentation et tx-udp_tnl-csum-segmentation. Ces indicateurs sont liés au déchargement de segmentation matérielle effectué par le pilote vSphere VMXNET3 et ne fonctionnent pas avec le tunnel GENEVE de clusters Anthos 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 les entrées 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. Pour les désactiver, 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 ces indicateurs de manière explicite 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 la version 1.N-1.Y, même si le cluster d'administrateur se trouve également dans la version 1.N.X.
Si vous êtes affecté par ce problème, vous devriez voir des journaux semblables à ceux ci-dessous 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 is not supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported
Solution :
Utilisez kubectl pour créer, modifier ou supprimer la ressource personnalisée du cluster d'utilisateur dans le cluster d'administrateur.
La mise à niveau des clusters d'utilisateur n'est pas affectée.
Mises à niveau et mises à jour
1.12
La mise à niveau des clusters vers la version 1.12.1 peut être bloquée
La mise à niveau des clusters vers la version 1.12.1 s'interrompt parfois, car le serveur d'API devient indisponible. Ce problème affecte tous les types de clusters et tous les systèmes d'exploitation compatibles. Lorsque ce problème se produit, la commande bmctl
upgrade cluster peut échouer à plusieurs moments, y compris au cours de la deuxième phase des vérifications préliminaires.
Solution
Vous pouvez consulter vos journaux de mise à niveau pour déterminer si vous êtes concerné par ce problème. Les journaux de mise à niveau sont situés dans /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP par défaut.
upgrade-cluster.log peut contenir des erreurs semblables à celles-ci:
Failed to upgrade cluster: preflight checks failed: preflight check failed
Le journal de la machine peut contenir les erreurs suivantes (les échecs répétés indiquent que vous êtes affecté par ce problème):
GCS et Keepalife doivent être exécutés sur chaque nœud de 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 GAIA ou Keepalife 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 Anthos
1,11 et 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 Anthos est activé
Dans la version 1.12.0 des clusters Anthos sur bare metal, toutes les ressources liées à l'environnement d'exécution des VM Anthos sont migrées vers l'espace de noms vm-system pour une meilleure compatibilité avec la version en disponibilité générale des VM d'Anthos. Si l'environnement d'exécution des VM Anthos est activé dans un cluster version 1.11.x ou antérieure, la mise à niveau vers la version 1.12.0 ou ultérieure échoue, sauf si vous désactivez d'abord l'environnement d'exécution des VM Anthos. Lorsque vous êtes concerné par ce problème, l'opération de mise à niveau signale l'erreur suivante:
Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version
Solution
Pour désactiver l'environnement d'exécution de VM Anthos, procédez comme suit:
Modifiez la ressource personnalisée VMRuntime :
kubectl edit vmruntime
Définissez enabled sur false dans la spécification:
Migration bloquée à error during manifests operations
Dans certaines situations, les mises à niveau des clusters échouent et la CLI bmctl ne répond plus. Ce problème peut être dû à une ressource mal mise à jour. 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 sont le symptôme d'une ressource mal mise à jour, où {RESOURCE_NAME} est le nom de la ressource problématique.
Solution
Si vous constatez 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 dotés de fonctionnalités qui utilisent la passerelle réseau Anthos
Les mises à niveau 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 Anthos Network Gateway. Les mises à niveau des clusters sont bloquées au niveau du message de ligne de commande Waiting for upgrade to complete... et le anthos-cluster-operator consigne les erreurs suivantes:
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 de la ressource de cluster.
Solution
Pour en savoir plus, y compris sur les instructions de suppression de nœuds du mode de maintenance, consultez la section Mettre des nœuds en mode de maintenance.
Mises à niveau et mises à jour
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Le drainage du nœud ne peut pas démarrer lorsque le nœud est hors de portée
Le processus de drainage des nœuds ne démarre pas s'ils sont hors de portée des clusters Anthos sur bare metal. Par exemple, si un nœud se déconnecte pendant un processus de mise à niveau du cluster, la mise à niveau peut cesser de répondre. Cela se produit rarement.
Solution
Pour minimiser la probabilité que vous rencontriez ce problème, assurez-vous que vos nœuds fonctionnent correctement avant de lancer une mise à niveau.
Mises à niveau et mises à jour
1.12
containerd 1.5.13 nécessite libseccomp 2.5 ou une version ultérieure
Les clusters Anthos sur bare metal version 1.12.1 sont fournis avec containerd version 1.5.13, et cette version de containerd nécessite libseccomp version 2.5 ou ultérieure.
Si la version 2.5 ou ultérieure de libseccomp n'est pas installée sur votre système, mettez-la à jour avant de mettre à niveau les clusters existants vers la version 1.12.1. Dans le cas contraire, vous pouvez voir des erreurs dans les pods cplb-update pour les nœuds d'équilibrage de charge, par exemple:
runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond
Solution
Pour installer la dernière version de libseccomp dans Ubuntu, exécutez la commande suivante:
sudo apt-get install libseccomp-dev
Pour installer la dernière version de libseccomp dans CentOS ou RHEL, exécutez la commande suivante:
sudo dnf -y install libseccomp-devel
Opération
1.10, 1.11, 1.12
Nœuds non codés si vous n'utilisez pas la procédure en mode de maintenance
Si vous exécutez des clusters Anthos sur bare metal version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou antérieure et utilisez manuellement kubectl cordon sur un nœud, les clusters Anthos sur bare metal peuvent annuler le marquage du nœud avant que vous ne soyez prêt à rapprocher l'état attendu.
Solution
Pour les clusters Anthos sur bare metal version 1.12.0 ou antérieure, utilisez le mode de maintenance pour marquer et décharger les nœuds en toute sécurité.
À partir de la version 1.12.1 (anthosBareMetalVersion: 1.12.1) ou d'une version ultérieure, les clusters Anthos sur bare metal n'annulent pas le marquage inattendu de vos nœuds 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 version 1.10
Si votre cluster d'administrateur est en version 1.11 et utilise un miroir de registre, il ne peut pas gérer les clusters d'utilisateur qui utilisent une version mineure. 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, consultez les journaux des 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 affecté par le problème, vos journaux contiennent le message d'erreur suivant:
flag provided but not defined: -registry-mirror-host-to-endpoints
Opération
1,10 et 1,11
Secret kubeconfig écrasé
Lorsqu'elle est exécutée sur des clusters d'utilisateur, la commande bmctl check cluster écrase le secret kubeconfig du cluster d'utilisateur par le fichier kubeconfig du cluster d'administrateur. Le remplacement du fichier entraîne l'échec des opérations standards du cluster, telles que la mise à jour et la mise à niveau, pour les clusters d'utilisateur concernés. Ce problème s'applique aux clusters Anthos sur bare metal 1.11.1 et versions antérieures.
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 Anthos sur bare metal sont le 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é.
Pour restaurer la fonction dans un cluster d'utilisateur concerné (USER_CLUSTER_NAME), procédez comme suit :
Localisez le fichier kubeconfig du cluster d'utilisateur. Les clusters Anthos sur bare metal génèrent le fichier kubeconfig sur le poste de travail administrateur lorsque vous créez un cluster. Par défaut, le fichier se trouve dans le répertoire bmctl-workspace/USER_CLUSTER_NAME.
Vérifiez que le fichier kubeconfig du cluster d'utilisateur est correct :
kubectl get nodes \
--kubeconfig PATH_TO_GENERATED_FILE
Remplacez PATH_TO_GENERATED_FILE par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur. La réponse renvoie des informations sur les nœuds du cluster d'utilisateur. Vérifiez que les noms des machines sont corrects pour votre cluster.
Exécutez la commande suivante pour supprimer le fichier kubeconfig corrompu du cluster d'administrateur:
Prendre un instantané en tant qu'utilisateur de connexion non racine
Si vous utilisez containerd comme environnement d'exécution de conteneur, l'exécution d'un instantané en tant qu'utilisateur non racine nécessite que /usr/local/bin se trouve dans le chemin d'accès de l'utilisateur.
Sinon, il é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 chemin d'accès sudo peut être différent du profil racine et peut ne pas contenir /usr/local/bin.
Solution
Mettez à jour secure_path dans /etc/sudoers pour inclure /usr/local/bin. Vous pouvez également créer un lien symbolique pour crictl dans un autre répertoire /bin.
Opération, environnement d'exécution des VM Anthos
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Environnement d'exécution des VM Anthos : le redémarrage d'un pod entraîne la modification des adresses IP des VM ou la perte de leur adresse IP.
Si l'adresse IP d'une VM change, cela n'a aucune incidence sur la joignabilité des applications de VM exposées en tant que service Kubernetes.
Solution
Si l'adresse IP est perdue, vous devez exécuter dhclient à partir de la VM pour en obtenir une.
Journalisation et surveillance
1.10
stackdriver-log-forwarder comporte [parser:cri] invalid
time format journaux d'avertissement
Si l'analyseur d'interface de conteneur (CRI) utilise une expression régulière incorrecte pour l'analyse, les journaux du pod stackdriver-log-forwarder contiennent des erreurs et des avertissements semblables à ceux-ci:
[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 les clusters Anthos sur bare metal 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 que vos modifications suivantes ne soient annulées, réduisez la taille de stackdriver-operator:
Votre ressource modifiée doit ressembler à ce qui suit :
[PARSER]
# https://rubular.com/r/Vn30bO78GlkvyB
Name cri
Format regex
# The timestamp is described in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
{2}:[0-9]{2})) (?<stream>stdout|stderr)
(?<logtag>[^ ]*) (?<log>.*)$
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L%z
Time_Keep off
Pour les clusters Anthos sur bare metal versions 1.10 ou supérieures, certains clients ont constaté une facturation élevée inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que lorsque toutes les circonstances suivantes s'appliquent:
La surveillance des applications est activée (enableStackdriverForApplications=true)
Les pods d'application comportent l'annotation prometheus.io/scrap=true
Pour savoir si vous êtes concerné par ce problème, répertoriez-les. Si la facturation de métriques indésirables s'affiche, ce problème vous concerne.
Solution
Si vous êtes concerné par ce problème, nous vous recommandons de mettre à niveau vos clusters vers la version 1.12 et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus.
Indicateurs distincts pour contrôler la collecte des journaux d'application par rapport aux métriques d'application
Service Google Cloud Managed Service pour Prometheus inclus
Si vous ne pouvez pas passer à la version 1.12, procédez comme suit:
Recherchez les pods et services sources qui présentent une 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 et 1.15
Les modifications apportées à metrics-server-config ne sont pas conservées.
Une densité de pods élevée peut, dans des cas extrêmes, créer 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 davantage de ressources afin de maintenir le serveur de métriques en cours d'exécution. Toutefois, en raison du rapprochement, les valeurs par défaut peuvent être rétablies pour les modifications apportées à metrics-server-config lors d'une mise à jour ou d'une mise à niveau du cluster.
Le serveur de métriques n'est pas affecté immédiatement, mais au prochain redémarrage, il récupère le ConfigMap rétabli et est à nouveau vulnérable à une surcharge excessive.
Solution
Pour la version 1.11.x, vous pouvez rédiger le script de la modification du ConfigMap et l'exécuter avec des mises à jour ou des mises à niveau du cluster. Pour les versions 1.12 et ultérieures, veuillez contacter l'assistance.
Journalisation et surveillance
1,11 et 1,12
Les métriques obsolètes ont une incidence sur le tableau de bord Cloud Monitoring
Plusieurs métriques Anthos sont obsolètes. À partir de la version 1.11 des clusters Anthos sur bare metal, les données ne sont plus collectées. Si vous utilisez ces métriques dans l'une de vos règles d'alerte, aucune donnée ne déclenchera la condition d'alerte.
Le tableau suivant répertorie les métriques individuelles obsolètes et la métrique qui les remplace.
Dans les versions d'clusters Anthos sur bare metal antérieures à la version 1.11, le fichier de définition de stratégie 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, puis supprimez le tableau de bord État des nœuds du cluster Anthos.
Cliquez sur l'onglet Bibliothèque d'échantillons, puis réinstallez le tableau de bord État des nœuds du cluster Anthos.
"stackdriver-log-forwarder" comporte des erreurs CrashloopBackOff
Dans certains cas, l'agent Logging fluent-bit peut se retrouver bloqué lors du traitement de fragments corrompus. Lorsque l'agent Logging ne parvient pas à contourner les fragments corrompus, vous pouvez constater que stackdriver-log-forwarder continue de planter avec une erreur CrashloopBackOff. Si vous rencontrez ce problème, vos journaux comportent des entrées semblables aux suivantes :
[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 la mémoire tampon pour le redirecteur Stackdriver Log.
Remarque: Dans les commandes suivantes, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Données de métriques inconnues dans Cloud Monitoring
Les données dans les clusters Cloud Monitoring pour les versions 1.10.x peuvent contenir des entrées de métriques récapitulatives non pertinentes, telles que:
Bien que ces métriques de type récapitulatif figurent dans la liste des métriques, elles ne sont pas compatibles avec gke-metrics-agent pour le moment.
Journalisation et surveillance
1,10 et 1,11
Interruptions intermittentes de l'exportation de métriques
Les clusters Anthos sur bare metal peuvent rencontrer des interruptions lors de l'exportation continue et standard des métriques, ou des métriques manquantes sur certains nœuds. Si ce problème affecte vos clusters, vous risquez de constater des écarts de données pour les métriques suivantes (au minimum):
Pour augmenter la demande de processeur de 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
Le fait d'avoir plusieurs passerelles par défaut dans un nœud peut entraîner une interruption de la connectivité depuis un pod vers 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 des clusters d'utilisateur sont écrasées
La version 1.12.x des clusters Anthos sur bare metal ne vous empêche pas de modifier manuellement les ressources personnalisées de mise en réseau de votre cluster d'utilisateur. Les clusters Anthos sur bare metal fusionnent les ressources personnalisées des clusters d'utilisateur avec les ressources personnalisées de votre cluster d'administrateur lors des mises à niveau des clusters. Ce rapprochement écrase toutes les modifications apportées directement aux ressources personnalisées de mise en réseau du cluster d'utilisateur. Les ressources personnalisées de mise en réseau doivent être modifiées uniquement dans le cluster d'administrateur, mais les clusters Anthos sur bare metal version 1.12.x n'imposent pas cette exigence.
Vous modifiez ces ressources personnalisées dans votre cluster d'administrateur. 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 de votre cluster d'administrateur afin qu'elles correspondent avant la mise à niveau. Cette étape garantit que les modifications apportées à votre configuration sont conservées. Les clusters Anthos sur bare metal version 1.13.0 ou ultérieure 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.11, 1.12, 1.13, 1.14 et 1.15
Échec de la NAT avec trop de connexions parallèles
Pour un nœud donné de votre cluster, l'adresse IP du nœud fournit une traduction d'adresses réseau (NAT) pour les paquets acheminés vers une adresse en dehors du cluster. De même, lorsque des paquets entrants entrent dans un nœud d'équilibrage de charge configuré pour utiliser l'équilibrage de charge groupé (spec.loadBalancer.mode:
bundled), la traduction d'adresse réseau source (SNAT) achemine les paquets vers l'adresse IP du nœud avant leur transfert vers un pod de backend.
La plage de ports pour le NAT utilisée par les clusters Anthos sur bare metal est de 32768 à 65535. Cette plage limite le nombre de connexions parallèles à 32 767 par protocole sur ce nœud. Chaque connexion nécessite une entrée dans la table "conntrack". Si vous avez trop de connexions de courte durée, la table conntrack s'épuise des ports pour la NAT. Un récupérateur de mémoire nettoie les entrées obsolètes, mais le nettoyage n'est pas immédiat.
Lorsque le nombre de connexions sur votre nœud atteint 32 767, vous pouvez observer des pertes de paquets pour les connexions nécessitant une fonctionnalité NAT.
Pour identifier ce problème, exécutez la commande suivante sur le pod anetd du nœud problématique:
Les erreurs doivent s'afficher sous la forme suivante :
No mapping for NAT masquerade DROPPED
Solution
Répartissez votre trafic vers d'autres nœuds.
Mise en réseau
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Adresse IP client source avec équilibrage de charge de couche 2 groupé
Si vous définissez la règle de trafic externe sur Local, des erreurs de routage peuvent se produire, telles que No route to
host pour l'équilibrage de charge groupé de couche 2. La règle de trafic externe est définie par défaut sur Cluster (externalTrafficPolicy:
Cluster). Avec ce paramètre, Kubernetes gère le trafic à l'échelle du cluster. Les services de type LoadBalancer ou NodePort peuvent utiliser externalTrafficPolicy: Local pour conserver l'adresse IP source du client. Avec ce paramètre, Kubernetes ne gère toutefois que le trafic local des nœuds.
Solution
Si vous souhaitez conserver l'adresse IP source du client, une configuration supplémentaire peut être requise pour vous assurer que les adresses IP de service sont accessibles. Pour en savoir plus sur la configuration, consultez la section Conserver l'adresse IP source du client sous "Configurer l'équilibrage de charge groupé".
Mise en réseau
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
La modification de firewalld effacera les chaînes de règles Cilium iptable
Lorsque vous exécutez des clusters Anthos sur bare metal avec firewalld activé sur CentOS ou Red Had Enterprise Linux (RHEL), les modifications apportées à firewalld peuvent supprimer les chaînes Cilium iptables du réseau hôte. Les chaînes iptables sont ajoutées par le pod anetd au démarrage. La perte des chaînes Cilium iptables entraîne la perte de la connectivité réseau du pod sur le nœud en dehors du nœud.
Les modifications apportées à firewalld qui supprimeront les chaînes iptables incluent, sans s'y limiter:
Le redémarrage de firewalld avec systemctl
Actualiser firewalld avec le client de ligne de commande (firewall-cmd --reload)
Solution
Redémarrez anetd sur le nœud. Recherchez et supprimez le pod anetd à l'aide des commandes suivantes pour redémarrer anetd:
Lorsque vous utilisez la fonctionnalité de passerelle NAT de sortie, il est possible de définir des règles de sélection du trafic qui spécifient une adresse egressSourceIP déjà utilisée pour un autre objet EgressNATPolicy. Cela peut entraîner des conflits de routage du trafic de sortie.
Solution
Contactez votre équipe de développement pour déterminer les adresses IP flottantes disponibles avant de spécifier l'adresse egressSourceIP dans votre ressource personnalisée EgressNATPolicy.
Mise en réseau
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Échecs de connectivité du pod et filtrage du chemin d'accès inverse
Les clusters Anthos sur bare metal configure le filtrage au chemin inverse sur les nœuds pour désactiver la validation de la source (net.ipv4.conf.all.rp_filter=0). Si vous définissez le paramètre rp_filter sur 1 ou 2, les pods échoueront en raison de délais de communication hors nœud.
Le filtrage du chemin inverse est défini avec les fichiers rp_filter dans le dossier de configuration IPv4 (net/ipv4/conf/all). Cette valeur peut également être remplacée par sysctl, qui stocke les paramètres de filtrage du chemin inverse dans un fichier de configuration de la sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf.
Solution
Pour restaurer la connectivité du pod, redéfinissez net.ipv4.conf.all.rp_filter sur 0 manuellement ou redémarrez le pod anetd pour rétablir net.ipv4.conf.all.rp_filter sur 0. Pour redémarrer et supprimer le pod anetd, utilisez les commandes suivantes. Un nouveau pod anetd démarrera à sa place :anetd
Amorçage des adresses IP du cluster et des adresses IP des nœuds de cluster qui se chevauchent
192.168.122.0/24 et 10.96.0.0/27 sont les CIDR des pods et des services par défaut utilisés par le cluster d'amorçage (kind).
Les vérifications préliminaires échouent si elles se chevauchent avec les adresses IP de la machine du nœud du cluster.
Solution
Pour éviter le conflit, vous pouvez transmettre les options --bootstrap-cluster-pod-cidr et --bootstrap-cluster-service-cidr à bmctl afin de spécifier des valeurs différentes.
Système d'exploitation
1.11
Incompatibilité avec Ubuntu 18.04.6 sur le noyau GA
Les clusters Anthos sur bare metal versions 1.11.0 et 1.11.1 ne sont pas compatibles avec Ubuntu 18.04.6 sur le noyau GA (de 4.15.0-144-generic à 4.15.0-176-generic). L'incompatibilité provoque la configuration de l'agent réseau par le message d'erreur "Le programme BGP est trop volumineux" dans les journaux anetd. Il est possible que des pods restent bloqués à l'état ContainerCreating avec l'erreur networkPlugin cni failed to set up pod dans le journal des événements des pods. Ce problème ne s'applique pas aux noyaux HWE (Ubuntu Hardware Enablement).
Solution
Nous vous recommandons de télécharger le noyau HWE et de le mettre à niveau vers la dernière version compatible avec Ubuntu 18.04.
Système d'exploitation
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
É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é le abandon de CentOS. Le 31 janvier 2022, CentOS 8 est arrivé en fin de vie. Suite à la fin de vie, les dépôts yum ne fonctionnent plus 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 s'applique à toutes les versions des clusters Anthos sur bare metal.
Solution
Afficher la procédure de contournement
Pour contourner ce problème, exécutez les commandes suivantes afin que 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-*
Limites des points de terminaison du système d'exploitation
Sur RHEL et CentOS, la limite au niveau du cluster est de 100 000 points de terminaison. Service Kubernetes. Si deux services font référence au même ensemble de pods, cela compte pour deux ensembles de points de terminaison distincts. L'implémentation nftable sous-jacente sur RHEL et CentOS est à l'origine de cette limitation. Il ne s'agit pas d'une limitation intrinsèque des clusters Anthos sur bare metal.
Sécurité
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Le conteneur ne peut pas écrire dans VOLUME, défini dans Dockerfile avec containerd et SELinux
Si vous utilisez containerd comme environnement d'exécution de conteneur et que SELinux est activé sur votre système d'exploitation, le VOLUME défini dans le Dockerfile de l'application risque de ne pas être accessible en écriture. Par exemple, les conteneurs créés avec le 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 affecté par ce problème, vous verrez un message d'erreur denied semblable à celui-ci:
Pour contourner ce problème, effectuez l'une des modifications suivantes :
Désactivez SELinux.
N'utilisez pas la fonctionnalité VOLUME dans le Dockerfile.
Sécurité
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Erreurs SELinux lors de la création du pod
La création de pods échoue parfois lorsque SELinux empêche l'exécution du conteneur de définir des libellés sur les installations tmpfs. Cet échec est rare, mais peut se produire lorsque SELinux est en mode Enforcing et dans certains noyaux.
Pour vérifier que SELinux est à l'origine des échecs de création des pods, utilisez la commande suivante pour rechercher les erreurs dans les journaux kubelet:
journalctl -u kubelet
Si SELinux entraîne l'échec de la création du pod, la réponse de commande contient une erreur semblable à celle-ci:
error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied
Pour vérifier que ce problème est lié à l'application de SELinux, exécutez la commande suivante :
ausearch -m avc
Cette commande recherche dans les journaux d'audit des erreurs d'autorisation du cache du vecteur d'accès (AVC). Le avc: denied dans l'exemple de réponse suivant confirme que les échecs de création de pod sont liés à l'application de SELinux.
Ce problème de création de pod avec SELinux est à l'origine d'un bug du noyau détecté dans les images Linux suivantes:
Versions de Red Hat Enterprise Linux (RHEL) antérieures à la version 8.3
Versions de CentOS antérieures à la version 8.3
Solution
Le redémarrage de la machine permet de résoudre le problème.
Pour éviter les erreurs de création de pods, utilisez RHEL 8.3 ou version ultérieure ou CentOS 8.3 ou version ultérieure, car ces versions ont corrigé le bug du noyau.
Réinitialisation/Suppression
1.10, 1.11, 1.12
Suppression d'un espace de noms
La suppression d'un espace de noms empêche la création de ressources dans cet espace de noms, y compris les tâches de réinitialisation des machines.
Solution
Lorsque vous supprimez un cluster d'utilisateur, vous devez d'abord supprimer l'objet de cluster avant de supprimer son espace de noms. Sinon, les tâches de réinitialisation des machines ne peuvent pas être créées, et le processus de suppression ignore l'étape de nettoyage de la machine.
Réinitialisation/Suppression
1.10, 1.11, 1.12, 1.13, 1.14 et 1.15
Service containerd
La commande bmctl reset ne supprime aucun fichier de configuration ni aucun fichier binaire containerd. Le service containerd systemd est opérationnel. La commande supprime les conteneurs exécutant les pods planifiés sur le nœud.
Mises à niveau et mises à jour
1.10, 1.11, 1.12
Le détecteur de problèmes de nœuds n'est pas activé par défaut après la mise à niveau du cluster
Lorsque vous mettez à niveau des clusters Anthos sur bare metal, le détecteur de problèmes de nœuds n'est pas activé par défaut. Ce problème s'applique aux mises à niveau de la version 1.10 à la version 1.12.1 et a été corrigé dans la version 1.12.2.
Solution :
Pour activer l'outil de détection des 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 l'outil de détection des problèmes de nœuds, utilisez la commande kubectl edit et modifiez le ConfigMap node-problem-detector-config. Pour en savoir plus, consultez la section Détecteur de problèmes de nœuds.
Opération
1,9 et 1,10
Échec de la sauvegarde du cluster avec 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 s'applique aux clusters Anthos sur bare metal 1.9.x, 1.10.0 et 1.10.1 et 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'équilibreur de charge ne fonctionnent pas avec les conteneurs sur le réseau hôte du plan de contrôle
Dans anetd, un paquet est supprimé pour les services LoadBalancer si les pods de backend s'exécutent tous deux sur le nœud du plan de contrôle et utilisent le champ hostNetwork: true dans la spécification du conteneur.
Le bug n'est pas présent dans la version 1.13 ou ultérieure.
Solution :
Les solutions 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 les nœuds du plan de contrôle).
Le pod anthos-version-$version$ orphelin ne parvient pas à extraire l'image.
La mise à niveau du cluster de la version 1.12.x vers la version 1.13.x peut entraîner l'échec d'un pod anthos-version-$version$ avec une erreur ImagePullBackOff.
Cela est dû au fait que la condition de concurrence de anthos-cluster-operator est mise à niveau et ne devrait affecter aucune fonctionnalité de cluster standard.
Le bug n'est plus présent après 1.13 ou une version ultérieure.
Solution :
Supprimez la tâche de Dynamic-version-installer d'ici le kubectl delete job anthos-version-$version$ -n kube-system
Mises à niveau et mises à jour
1.13
1.12 clusters mis à niveau depuis la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0
Les clusters version 1.12 mis à niveau depuis 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é.
TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...
Solution :
Pour résoudre ce problème, procédez comme suit :
Exécutez les commandes suivantes sur votre poste de travail administrateur:
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 2023/08/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 2023/08/03 (UTC)."],[],[]]
Tableaux de bord, puis supprimez le tableau de bord État des nœuds du cluster Anthos.