Version 1.8. Cette version est compatible conformément à la politique de compatibilité avec les versions d'Anthos, en fournissant les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant les clusters Anthos sur Bare Metal. Pour en savoir plus, consultez les notes de version 1.8. Pour obtenir la liste complète des releases mineures et des correctifs par ordre chronologique, reportez-vous aux notes de version combinées.

Versions disponibles : 1.10  |   1.9  | 1.8

Problèmes connus des clusters Anthos sur Bare Metal

Installation

Incompatibilité du groupe de contrôle v2

Le groupe de contrôle v2 (cgroup v2) n'est pas compatible avec la version 1.6 des clusters Anthos sur Bare Metal. Kubernetes 1.18 n'est pas compatible avec cgroup v2. En outre, Docker n'offre une compatibilité expérimentale qu'à partir de 20.10. systemd est passé à cgroup v2 par défaut dans la version 247.2-2. La présence de /sys/fs/cgroup/cgroup.controllers indique que votre système utilise cgroup v2.

Les vérifications préliminaires permettent de vérifier que cgroup v2 n'est pas utilisé sur la machine du cluster.

Messages d'erreur anodins pendant l'installation

En examinant les journaux de création de clusters, vous remarquerez peut-être des défaillances temporaires concernant l'enregistrement des clusters ou l'appel des webhooks. Ces erreurs peuvent être ignorées en toute sécurité, car l'installation effectuera de nouveau ces opérations jusqu'à ce qu'elles aboutissent.

Vérifications préliminaires et identifiants du compte de service

Pour les installations déclenchées par des clusters d'administrateur ou hybrides (autrement dit, des clusters qui n'ont pas été créés avec bmctl, comme les clusters d'utilisateurs), la vérification préalable ne vérifie pas les identifiants du compte de service Google Cloud Platform ou les autorisations qui leur sont associées.

Vérifications préliminaires et autorisation refusée

Lors de l'installation, vous pouvez rencontrer des erreurs concernant /bin/sh: /tmp/disks_check.sh: Permission denied. Ces messages d'erreur surviennent, car /tmp est installé avec l'option noexec. Pour que bmctl fonctionne, vous devez supprimer l'option noexec du point d'installation /tmp.

Créer un espace de travail Cloud Monitoring avant d'afficher les tableaux de bord

Vous devez créer un espace de travail Cloud Monitoring via Google Cloud Console avant de pouvoir afficher les tableaux de bord de surveillance des clusters Anthos sur Bare Metal.

Identifiants par défaut de l'application et bmctl

bmctl utilise les identifiants par défaut de l'application pour valider la valeur d'emplacement de l'opération de cluster dans les spécifications de cluster cluster spec lorsqu'elle n'est pas définie sur global.

Pour que les identifiants par défaut de l'application fonctionne, vous devez faire pointer la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS vers un fichier d'identifiants de compte de service, ou exécuter gcloud auth application-default login.

Ubuntu 20.04 LTS et bmctl

Sur les clusters Anthos sur versions Bare Metal antérieures à 1.8.2, certaines distributions Ubuntu 20.04 LTS avec un noyau Linux plus récent (y compris les images GCP Ubuntu 20.04 LTS sur le noyau 5.8) faisaient passer /proc/sys/net/netfilter/nf_conntrack_max en lecture seule dans les espaces de noms réseau non init. Cela empêche bmctl de définir la taille maximale pour la table de suivi des connexions, ce qui bloque le démarrage du cluster d'amorçage. Une taille de table incorrecte peut entraîner une boucle de plantage du pod kube-proxy du cluster d'amorçage, comme illustré dans l'exemple de journal d'erreurs suivant :

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

La solution consiste à définir manuellement net/netfilter/nf_conntrack_max sur la valeur requise sur l'hôte : sudo sysctl net.netfilter.nf_conntrack_max=393216 Notez que la valeur requise dépend du nombre de cœurs pour le nœud. Utilisez la commande kubectl logs ci-dessus pour confirmer la valeur souhaitée dans les journaux kube-proxy.

Ce problème est résolu dans les clusters Anthos sur version Bare Metal 1.8.2 et versions ultérieures.

Service Docker

Sur les machines du 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 échoue et renvoie le message Docker service is not active. Pour corriger cette erreur, supprimez Docker ou activez le service Docker.

Miroir de registre et Cloud Audit Logging

Sur les clusters Anthos sur une version Bare Metal antérieure à la version 1.8.2, le package de miroir de registre bmctl ne contient pas l'image gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00. Pour activer la fonctionnalité Cloud Audit Logging lors de l'utilisation d'un miroir de registre, vous devez télécharger manuellement l'image manquante et la transférer vers votre serveur de registre à l'aide des commandes suivantes :

docker pull gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker tag gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker push REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00

Containerd requiert /usr/local/bin dans PATH

Les clusters avec l'environnement d'exécution Containerd nécessitent que /usr/local/bin se trouve dans le PATH de l'utilisateur SSH pour que la commande kubeadm init puisse trouver le binaire crictl. Si crictl est introuvable, la création du cluster échoue.

Lorsque vous n'êtes pas connecté en tant qu'utilisateur racine, sudo permet d'exécuter la commande kubeadm init. Le chemin d'accès sudo peut différer du profil racine et peut ne pas contenir /usr/local/bin.

Pour corriger cette erreur, mettez à jour le fichier secure_path dans /etc/sudoers afin d'inclure /usr/local/bin. Vous pouvez également créer un lien symbolique pour crictl dans un autre répertoire /bin.

À partir de la version 1.8.2, les clusters Anthos sur Bar Metal ajoutent /usr/local/bin au chemin d'accès lors de l'exécution de commandes. Toutefois, l'exécution d'un instantané en tant qu'utilisateur non racine contiendra toujours crictl: command not found (qui peut être corrigé par la solution ci-dessus).

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 options sont liées au déchargement de la segmentation matérielle effectué par le pilote vSphere VMXNET3 et ne fonctionnent pas avec le tunnel GENEVE des clusters Anthos sur Bare Metal.

Exécutez la commande suivante sur chaque nœud pour vérifier les valeurs actuelles de ces options. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ...Remplacez NET_INTFC par l'interface réseau associée à l'adresse IP du nœud.

Parfois, dans RHEL 8.4, ethtool indique que ces options sont désactivées alors qu'elles ne le sont pas. Pour les désactiver explicitement, activez-les, puis désactivez-les à l'aide des commandes suivantes.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Cette modification d'option ne persiste pas lors des redémarrages. Configurez les scripts de démarrage pour définir explicitement ces options au démarrage du système.

Oscillation du niveau de préparation du nœud

Les clusters peuvent parfois présenter un comportement d'oscillation du niveau de préparation des nœuds (l'état des nœuds change rapidement entre Ready et NotReady). Ce comportement est dû à un générateur d'événements de cycle de vie des pods (PLEG) non opérationnel. Le PLEG est un module dans kubelet.

Pour confirmer qu'un PLEG non opérationnel est à l'origine de ce comportement, utilisez la commande journalctl suivante afin de rechercher les entrées de journal PLEG :

journalctl -f | grep -i pleg

Les entrées de journal telles que les suivantes indiquent que le PLEG n'est pas opérationnel :

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Une condition de concurrence runc connue est la cause probable d'un PLEG non opérationnel. Les processus runc bloqués sont un symptôme de la condition de concurrence. Exécutez la commande suivante pour vérifier l'état du processus runc init :

ps aux | grep 'runc init'

Pour résoudre ce problème :

  1. Déterminez l'environnement d'exécution du cluster.

    Pour pouvoir mettre à jour la version de runc, vous devez déterminer l'environnement d'exécution des conteneurs utilisé par votre cluster. Le champ containerRuntime du fichier de configuration du cluster identifie l'environnement d'exécution du conteneur utilisé par votre cluster. Lorsque containerRuntime est défini sur containerd, votre cluster utilise l'environnement d'exécution containerd. Si le champ est défini sur docker ou n'est pas défini, votre cluster utilise l'environnement d'exécution Docker.

    Pour obtenir la valeur, ouvrez le fichier de configuration du cluster avec votre éditeur favori ou, si vous avez accès au fichier kubeconfig du cluster d'administrateur, exécutez la commande suivante :

    kubctl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE | grep -i runtime
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster à sauvegarder.
    • 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-.
  2. Pour installer containerd.io ou docker-ce et extraire le dernier outil de ligne de commande runc, exécutez les commandes correspondant à votre système d'exploitation et à l'environnement d'exécution du conteneur sur chaque nœud.

    Ubuntu Containerd

    sudo apt update
    sudo apt install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    

    Ubuntu Docker

    sudo apt update
    sudo apt install docker-ce
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    

    CentOS/RHEL Containerd

    sudo dnf install containerd.io
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    

    CentOS/RHEL Docker

    sudo dnf install docker-ce
    # Back up current runc
    cp /usr/local/sbin/runc ~/
    sudo cp /usr/bin/runc /usr/local/sbin/runc
    # runc version should be > 1.0.0-rc93
    /usr/local/sbin/runc --version
    
  3. Redémarrez le nœud si des processus runc init sont bloqués.

    Vous pouvez également libérer manuellement tous les processus bloqués.

Mettre à jour Anthos clusters on bare metal

Les mises à niveau vers les clusters d'administrateur, hybrides et autonomes 1.8.0 et 1.8.1 ne se terminent pas

La mise à niveau des clusters d'administration, hybrides ou autonomes de la version 1.7.x vers la version 1.8.0 ou 1.8.1 échoue parfois. Cet échec de mise à niveau s'applique aux clusters que vous avez mis à jour après leur création.

La sortie de la console Waiting for upgrade to complete ..., qui ne mentionne pas le nœud en cours de mise à niveau, indique ce problème de mise à niveau. Ce symptôme indique également que votre cluster d'administrateur a bien été mis à niveau vers la version v1.20.8-gke.1500 de Kubernetes, la version Kubernetes pour les clusters Anthos sur Bare Metal versions 1.8.0 et 1.8.1.

Ce problème de mise à niveau est résolu pour les clusters Anthos sur Bare Metal version 1.8.2.

Pour vérifier si ce problème affecte la mise à niveau de votre cluster vers la version 1.8.0 ou 1.8.1, procédez comme suit :

  1. Créez le script shell suivant :

    if [ $(kubectl get cluster <var>CLUSTER\_NAME -n <var>CLUSTER\_NAMESPACE
        --kubeconfig bmctl-workspace/.kindkubeconfig -o=jsonpath='{.metadata.generation}')
        -le $(kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
        --kubeconfig bmctl-workspace/.kindkubeconfig
        -o=jsonpath='{{.status.systemServiceConditions[?(@.type=="Reconciling")].observedGeneration}}') ];
        then echo "Bug Detected"; else echo "OK"; fi
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster en cours de vérification.
    • CLUSTER_NAMESPACE : espace de noms du cluster.
  2. Exécutez le script pendant la mise à niveau, mais une fois les vérifications préliminaires terminées.

    Lorsque la valeur observedGeneration n'est pas inférieure à la valeur generation, Bug Detected est écrit dans le résultat de la console. Ce résultat indique que la mise à niveau de votre cluster est affectée.

  3. Pour débloquer la mise à niveau, exécutez la commande suivante :

    kubectl get --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
        --kubeconfig bmctl-workspace/.kindkubeconfig | \
        sed -e 's/\("systemServiceConditions":\[{[^{]*"type":"DashboardReady"}\),{[^{}]*}/\1/g' | \
        kubectl replace --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
        --kubeconfig bmctl-workspace/.kindkubeconfig -f-
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster en cours de vérification.
    • CLUSTER_NAMESPACE : espace de noms du cluster.

Mises à niveau vers la version 1.8.3 ou 1.8.4

La mise à niveau des clusters Anthos sur Bare Metal vers la version 1.8.3 ou 1.8.4 échoue parfois avec une erreur de contexte nulle. Si la mise à niveau de votre cluster échoue avec une erreur de contexte nulle, procédez comme suit pour terminer la mise à niveau :

  1. Définissez la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS de manière à ce qu'elle pointe vers le fichier de clé de votre compte de service.

    export GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH
    

    Remplacez KEY_PATH par le chemin du fichier JSON contenant la clé de votre compte de service.

  2. Exécutez à nouveau la commande bmctl upgrade cluster.

Limite de mise à niveau des correctifs du cluster d'utilisateur

Les clusters d'utilisateur gérés par un cluster d'administrateur doivent appartenir aux mêmes clusters Anthos sur une version Bare Metal ou inférieure, et dans une version mineure. Par exemple, un cluster d'administrateur de version 1.7.1 (anthosBareMetalVersion: 1.7.1) gérant les clusters d'utilisateur version 1.6.2 est acceptable.

Une limitation de mise à niveau vous empêche de mettre à niveau vos clusters d'utilisateur vers un nouveau correctif de sécurité lorsque le correctif est publié après la version utilisée par le cluster d'administrateur. Par exemple, si votre cluster d'administrateur est à la version 1.7.2, qui a été publiée le 2 juin 2021, vous ne pouvez pas mettre à niveau vos clusters d'utilisateur vers la version 1.6.4, car elle a été publiée le 13 août 2021.

Incompatibilité avec Ubuntu 18.04 et 18.04.1

Pour mettre à niveau vers la version 1.8.1 ou 1.8.2, les machines de nœud de cluster et le poste de travail qui exécute bmctl doivent disposer du noyau Linux 4.17.0 ou version ultérieure. Sinon, le contrôleur réseau anetd ne fonctionnera pas. Le problème est que les pods avec le préfixe anet dans l'espace de noms kube-system continueront de planter avec le message d'erreur suivant : BPF NodePort services needs kernel 4.17.0 or newer.

Ce problème affecte Ubuntu 18.04 et 18.04.1, car ils se trouvent dans la version de noyau 4.15.

Ce problème a été résolu dans les clusters Anthos sur solution Bare Metal 1.8.3.

Mettre à niveau les clusters 1.7.x qui utilisent Containerd

Les mises à niveau vers les versions 1.8.x sont bloquées pour les clusters 1.7.x configurés pour utiliser la fonctionnalité d'aperçu containerd. L'aperçu containerd utilise le pilote de groupe de contrôle (cgroup) cgroupfs incorrect, au lieu du pilote systemd recommandé. Des cas d'instabilité de cluster ont été signalés lorsque des clusters utilisant le pilote cgroupfs sont soumis à une pression des ressources. La fonctionnalité containerd en disponibilité générale dans la version 1.8.0 utilise le pilote systemd approprié.

Si vous possédez des clusters 1.7.x utilisant la fonctionnalité d'environnement d'exécution des conteneurs d'aperçu containerd, nous vous recommandons de Créer des clusters 1.8.0 configurés pour containerd et de migrer les applications et charges de travail existantes. Cela garantit la plus grande stabilité du cluster lors de l'utilisation de l'environnement d'exécution des conteneurs containerd.

Échecs de mise à niveau de SELinux

La mise à niveau des clusters 1.7.1 configurés avec l'environnement d'exécution des conteneurs containerd et exécutant SELinux sur RHEL ou CentOS échouera. Nous vous recommandons de créer des clusters 1.8.0 configurés pour utiliser containerd et de migrer vos charges de travail.

Le drainage de 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 si le nœud est 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. Ceci est rare. Pour minimiser le risque de rencontrer ce problème, assurez-vous que vos nœuds fonctionnent correctement avant de lancer une mise à niveau.

Réinitialisation/Suppression

Suppression d'un espace de noms

La suppression d'un espace de noms empêche la création de nouvelles ressources dans ce dernier, y compris les tâches permettant de réinitialiser les machines. Lors de la suppression d'un cluster d'utilisateur, vous devez d'abord supprimer l'objet du cluster avant de supprimer son espace de noms. Autrement, 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.

Service containerd

La commande bmctl reset ne supprime aucun fichier de configuration containerd ni fichier binaire. Le service containerd systemd est conservé à l'état opérationnel. La commande supprime les conteneurs qui exécutent des pods programmés sur le nœud.

Sécurité

L'autorité de certification/le certificat du cluster font l'objet d'une rotation lors de la mise à niveau. La compatibilité avec la rotation à la demande est une fonctionnalité bêta.

Les clusters Anthos sur Bare Metal procèdent automatiquement à la rotation des certificats de diffusion kubelet. Chaque agent de nœud kubelet peut envoyer une demande de signature de certificat (CSR) lorsqu'un certificat arrive à expiration. Un contrôleur dans vos clusters d'administrateur valide et approuve la demande CRS.

Rotation de l'autorité de certification du cluster (fonctionnalité Bêta)

Après avoir effectué une rotation des autorités de certification d'utilisateur (CA) sur un cluster, tous les flux d'authentification utilisateur échouent. Ces défaillances se produisent car la ressource personnalisée ClientConfig utilisée dans les flux d'authentification n'est pas mise à jour avec les nouvelles données de la CA lors de la rotation de l'autorité de certification. Si vous avez effectué une rotation de l'autorité de certification sur votre cluster, vérifiez si le champ certificateAuthorityData dans l'objet ClientConfig default de l'espace de noms kube-public contient l'ancienne autorité de certification du cluster.

Pour résoudre le problème manuellement, mettez à jour le champ certificateAuthorityData avec l'autorité de certification du cluster actuelle.

Réseau

La modification de firewalld entraîne la suppression des chaînes des règles iptable Cilium

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 sur le réseau hôte. Les chaînes iptables sont ajoutées par le pod anetd à son démarrage. La perte des chaînes iptables Cilium entraîne la perte de la connectivité réseau en dehors du nœud du pod sur le nœud.

Les modifications apportées à firewalld qui suppriment les chaînes iptables incluent, sans s'y limiter, les éléments suivants :

  • Le redémarrage de firewalld avec systemctl
  • L'actualisation du fichier firewalld avec le client de ligne de commande (firewall-cmd --reload)

Vous pouvez résoudre ce problème de connectivité en redémarrant anetd sur le nœud. Localisez et supprimez le pod anetd à l'aide des commandes suivantes pour redémarrer anetd :

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Remplacez ANETD_XYZ par le nom du pod anetd.

Dupliquer les adresses egressSourceIP

Lorsque vous utilisez la fonctionnalité d'aperçu de la passerelle NAT de sortie, il est possible de définir des règles de sélection de trafic qui spécifient una adresse egressSourceIP déjà utilisée pour un autre objet EgressNATPolicy. Cela peut provoquer des conflits de routage du trafic de sortie. Collaborez avec votre équipe de développement pour déterminer les adresses IP flottantes à utiliser avant de spécifier l'adresse egressSourceIP dans votre ressource personnalisée EgressNATPolicy.

Échecs de connectivité des pods en raison du délai avant expiration des E/S et du filtrage du chemin d'accès inverse

Les clusters Anthos sur Bare Metal configurent le filtrage du chemin d'accès inverse sur les nœuds pour désactiver la validation source (net.ipv4.conf.all.rp_filter=0). Si le paramètre rp_filter est défini sur 1 ou 2, les pods échouent en raison de délais de communication hors nœud.

L'observation des échecs de connectivité lors de la communication avec les adresses IP du service Kubernetes est un symptôme du problème. Voici quelques exemples d'erreurs que vous pouvez rencontrer :

  • Si tous les pods d'un nœud donné ne communiquent pas avec les adresses IP du service, le pod istiod peut signaler une erreur semblable à celle-ci :

     {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
        "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
        Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
        dial tcp 172.26.0.1:443: i/o timeout"}
    
  • Pour l'ensemble daemon localpv qui s'exécute sur chaque nœud, le journal peut afficher un délai d'expiration semblable à celui-ci :

     I1112 17:24:33.191654       1 main.go:128] Could not get node information
    (remaining retries: 2): Get
    https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
    dial tcp 172.26.0.1:443: i/o timeout
    

Le filtrage des chemins inverses est défini à l'aide des fichiers rp_filter du dossier de configuration IPv4 (net/ipv4/conf/all). La commande sysctl stocke les paramètres de filtrage du chemin d'accès inverse dans un fichier de configuration de sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf. La commande sysctl peut remplacer le paramètre de filtrage du chemin inverse.

Pour restaurer la connectivité du pod, redéfinissez net.ipv4.conf.all.rp_filter manuellement sur 0 ou redémarrez le pod anetd pour redéfinir net.ipv4.conf.all.rp_filter sur 0. Pour redémarrer le pod anetd, utilisez les commandes suivantes pour localiser et supprimer le pod anetd. Un nouveau pod anetd démarre à sa place :

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

Remplacez ANETD_XYZ par le nom du pod anetd.

Pour définir net.ipv4.conf.all.rp_filter manuellement, exécutez la commande suivante :

sysctl -w net.ipv4.conf.all.rp_filter = 0

Chevauchement des adresses IP de cluster d'amorçage (genre) et des adresses IP des nœuds de cluster

192.168.122.0/24 et 10.96.0.0/27 sont les CIDR de pod et de service par défaut utilisés par le cluster d'amorçage (genre). Les vérifications préliminaires échouent s'ils chevauchent les adresses IP des machines du nœud de cluster. Pour éviter ce conflit, vous pouvez transmettre les options --bootstrap-cluster-pod-cidr et --bootstrap-cluster-service-cidr à bmctl pour spécifier des valeurs différentes.

Chevauchement d'adresses IP dans différents clusters

Les adresses IP qui se chevauchent sur différents clusters ne sont pas validées lors de la mise à jour. La validation ne s'applique qu'au moment de la création du cluster/pool de nœuds.

Limites des points de terminaison du système d'exploitation

Sur RHEL et CentOS, une limite de 100 000 points de terminaison est définie au niveau du cluster. Ce nombre correspond à la somme de tous les pods référencés par un service Kubernetes. Si deux services font référence au même ensemble de pods, cela compte comme deux ensembles de points de terminaison distincts. Cette limite est due à la mise en œuvre sous-jacente de nftable sur RHEL et CentOS. Il ne s'agit pas d'une limite intrinsèque des clusters Anthos sur Bare Metal.

Configuration

Spécifications du plan de contrôle et de l'équilibreur de charge

Les spécifications du pool de nœuds d'équilibreur de charge et du plan de contrôle sont spéciales. Ces spécifications déclarent et contrôlent les ressources critiques du cluster. La source canonique de ces ressources correspond à leurs sections respectives dans le fichier de configuration du cluster :

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

Par conséquent, ne modifiez pas directement les ressources de premier niveau du pool de nœuds d'équilibreur de charge et du plan de contrôle. Modifiez plutôt les sections associées dans le fichier de configuration du cluster.

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 complète de leur adresse IP. Si l'adresse IP d'une VM change, cela n'affecte pas la joignabilité des applications de VM exposées en tant que service Kubernetes. Si l'adresse IP est perdue, vous devez exécuter dhclient à partir de la VM pour acquérir une adresse IP pour la VM.

SELinux

Erreurs SELinux lors de la création du pod

Il arrive que la création de pod échoue lorsque SELinux empêche l'environnement d'exécution du conteneur de définir des libellés sur les installations tmpfs. Cette défaillance 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 du pod, utilisez la commande suivante afin de rechercher les erreurs dans les journaux kubelet :

journalctl -u kubelet

Si SELinux entraîne l'échec de la création de pod, la réponse de la commande contient une erreur semblable à la suivante :

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 forcée de SELinux, exécutez la commande suivante :

ausearch -m avc

Cette commande recherche dans les journaux d'audit les erreurs d'autorisation concernant le cache des vecteurs d'accès. Le avc: denied de l'exemple de réponse suivant confirme que les échecs de création du pod sont liés à l'application forcée de SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

La cause principale de ce problème de création de pod avec SELinux est un bug du noyau trouvé 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

Le redémarrage de la machine permet de résoudre le problème.

Pour éviter les erreurs de création de pod, 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.

Instantanés

Prendre un instantané en tant qu'utilisateur de connexion non racine

Pour Anthos clusters on bare metal 1.8.1 et versions antérieures, si vous n'êtes pas connecté en tant qu'utilisateur racine, vous ne pouvez pas prendre d'instantané de cluster à l'aide de la commande bmctl. À partir de la version 1.8.2, Anthos clusters on bare metal respecte la valeur nodeAccess.loginUser dans la spécification de cluster. Si le cluster d'administrateur est inaccessible, vous pouvez spécifier l'utilisateur de connexion à l'aide de l'option --login-user.

Notez que si vous utilisez containerd en tant qu'environnement d'exécution de conteneur, l'instantané ne parvient toujours pas à exécuter les commandes crictl. Consultez la section Containerd nécessite /usr/local/bin dans PATH pour obtenir une solution de contournement. Les paramètres PATH utilisés pour SUDO sont à l'origine de ce problème.

GKE Connect

Pod gke-connect-agent en boucle de plantage

Une utilisation intensive de la passerelle GKE Connect peut parfois entraîner des problèmes de mémoire saturée pour le pod gke-connect-agent. Les symptômes de ces problèmes de mémoire saturée sont les suivants :

  • Le pod gke-connect-agent affiche un grand nombre de redémarrages ou se retrouve en état de boucle de plantage.
  • La passerelle de connexion cesse de fonctionner.

Pour résoudre ce problème de mémoire saturée, modifiez le déploiement avec le préfixe gke-connect-agent sous l'espace de noms gke-connect et augmentez la limite de mémoire jusqu'à 256 Mio ou plus.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

Ce problème est résolu dans les clusters Anthos sur Bare Metal 1.8.2 et versions ultérieures.

Journalisation et surveillance

stackdriver-log-forwarder pod bloqué à l'état de redémarrage

Pour les clusters Anthos sur versions sur Bare Metal antérieures à la version 1.9, si un nœud est arrêté de force, le pod stackdriver-log-forwarder peut rester bloqué à l'état de redémarrage. Dans ce cas, une entrée de journal semblable à celle-ci peut s'afficher :

[error] [input:storage_backlog:storage_backlog.7] chunk validation failed, data might
be corrupted. Found 0 valid records, failed content starts right after byte 0.

Lorsque le pod stackdriver-log-forwarder est bloqué, la plupart des journaux sont bloqués pour accéder à Cloud Logging et toutes les données non vidées sont perdues. Pour résoudre ce problème, réinitialisez le pipeline de journalisation.

Pour réinitialiser le pipeline de journalisation :

  1. Supprimez le DaemonSet stackdriver-log-forwarder :

    kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
        stackdriver-log-forwarder \
        -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    

    Vérifiez que les pods stackdriver-log-forwarder ont été supprimés avant de passer à l'étape suivante.

  2. Déployez le DaemonSet suivant pour nettoyer les données corrompues dans les tampons fluent-bit :

    kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF
    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: fluent-bit-cleanup
      namespace: kube-system
    spec:
      selector:
        matchLabels:
          app: fluent-bit-cleanup
      template:
        metadata:
          labels:
            app: fluent-bit-cleanup
        spec:
          containers:
          - name: fluent-bit-cleanup
            image: debian:10-slim
            command: ["bash", "-c"]
            args:
            - |
              rm -rf /var/log/fluent-bit-buffers/
              echo "Fluent Bit local buffer is cleaned up."
              sleep 3600
            volumeMounts:
            - name: varlog
              mountPath: /var/log
            securityContext:
              privileged: true
          tolerations:
          - key: "CriticalAddonsOnly"
            operator: "Exists"
          - key: node-role.kubernetes.io/master
            effect: NoSchedule
          - key: node-role.gke.io/observability
            effect: NoSchedule
          volumes:
          - name: varlog
            hostPath:
              path: /var/log
    EOF
    
  3. Assurez-vous que le DaemonSet a nettoyé tous les nœuds.

    Le résultat des commandes suivantes doit être égal au nombre de nœuds de votre cluster.

    kubectl --kubeconfig KUBECONFIG logs -n kube-system -l app=fluent-bit-cleanup | \
        grep "cleaned up" | wc -l
    kubectl --kubeconfig KUBECONFIG -n kube-system get pods -l app=fluent-bit-cleanup \
        --no-headers | wc -l
    
  4. Supprimez le DaemonSet de nettoyage :

    kubectl --kubeconfig KUBECONFIG -n kube-system delete ds fluent-bit-cleanup
    
  5. Effectuez un scaling à la hausse de l'opérateur et attendez qu'il redéploie le pipeline de journalisation.

    kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
        stackdriver-operator --replicas=1
    

Ce problème est résolu dans les clusters Anthos sur Bare Metal 1.9.0 et versions ultérieures.