Version 1.7. Cette version n'est plus compatible. Pour plus d'informations, consultez la politique de compatibilité avec les versions. Pour en savoir plus sur la mise à niveau vers la version 1.8, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.8.

Versions compatibles: 1.14 | 1.13 | 1.12

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.

À partir de la version 1.6.2 des clusters Anthos sur Bare Metal, les vérifications préalables permettent de vérifier que cgroup v2 n'est pas utilisé sur la machine du cluster.

Messages d'erreur anodins pendant l'installation

Lors de l'installation du cluster à haute disponibilité (HA), vous pouvez rencontrer des erreurs concernant etcdserver leader change. Ces messages d'erreur sont anodins et peuvent être ignorés.

Lorsque vous utilisez bmctl pour l'installation du cluster, un message de journal Log streamer failed to get BareMetalMachine peut s'afficher à la fin du create-cluster.log. Ce message d'erreur est anodin et peut être ignoré.

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.

Ubuntu 20.04.3+ LTS et HWE

Ubuntu 20.04.3 a activé le noyau 5.11 dans son package HWE (Hardware Enablement). Les clusters Anthos sur solution Bare Metal version 1.7.x ne sont pas compatibles avec ce noyau. Si vous souhaitez utiliser le noyau 5.11, téléchargez et mettez à jour vers les clusters Anthos sur solution Bare Metal 1.8.0 ou une version ultérieure.

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.

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

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 :

Exécutez les commandes suivantes sur chaque nœud pour installer la dernière version de containerd.io et extraire la dernière version de l'outil de ligne de commande runc :

Ubuntu

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

CentOS/RHEL

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

Redémarrez le nœud si des processus runc init sont bloqués.

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

Mises à niveau et mises à jour

Échec de `bmctl update cluster` si le répertoire `.manifests` est manquant

Si le répertoire .manifests est supprimé avant l'exécution de bmctl update cluster, la commande échoue avec une erreur semblable à celle-ci:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

Vous pouvez résoudre ce problème en exécutant d'abord bmctl check cluster, qui recréera le répertoire .manifests.

Ce problème s'applique aux clusters Anthos sur Bare Metal 1.10 et versions antérieures. Il est résolu dans les versions 1.11 et ultérieures.

Mise à niveau bloquée à `error during manifests operations`

Dans certains cas, les mises à niveau de cluster échouent et la CLI bmctl ne répond plus. Ce problème peut être causé par une ressource mal mise à jour. Pour savoir si vous êtes concerné par ce problème et le résoudre, procédez comme suit :

Consultez les journaux anthos-cluster-operator et recherchez des erreurs semblables aux entrées suivantes :
```
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
```
Ces entrées sont des symptômes d'une ressource mal mise à jour, où {RESOURCE_NAME} est le nom de la ressource problématique.
Si vous trouvez ces erreurs dans vos journaux, 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.

`bmctl update` ne supprime pas les blocs de maintenance.

La commande bmctl update ne peut ni supprimer ni modifier la section maintenanceBlocks de la configuration des ressources du cluster. Pour en savoir plus, y compris sur les instructions concernant la suppression de nœuds du mode de maintenance, consultez la section Passer des nœuds en mode de maintenance.

La mise à niveau des clusters depuis la version 1.7.5 vers la version 1.7.6 est bloquée

Vous ne pouvez pas mettre à niveau la version 1.7.5 d'Anthos on bare metal vers la version 1.7.6. Ce blocage n'a aucune incidence sur les autres versions d'Anthos clusters on bare metal. Par exemple, vous pouvez faire passer vos clusters d'une version 1.7.4 à une version 1.7.6. Si vous disposez de clusters version 1.7.5, pour obtenir les correctifs des failles de sécurité traités dans la version 1.7.6, vous devez effectuer une mise à niveau vers une version ultérieure lorsqu'elle sera disponible.

Mise à jour depuis la version 1.6.0

La mise à niveau n'est pas disponible dans la release 1.6.0.

Mise à jour de la version 1.7.0 à la version 1.7.x

Lors de la mise à jour de la version 1.7.0 à la version 1.7.x, votre cluster peut rester bloqué sur la mise à jour du nœud du plan de contrôle. Il est possible que MACHINE-IP-machine-upgrade tâches s'exécutent et échouent régulièrement. Ce problème affecte les clusters 1.7.0 sur lesquels :

Docker est préinstallé sur les nœuds du plan de contrôle ;
containerd est sélectionné comme environnement d'exécution.

Ce problème est dû à la configuration incorrecte du socket CRI par les clusters Anthos sur Bare Metal au lieu de containerd. Pour résoudre ce problème, vous devez définir les identifiants d'extraction d'images pour Docker :

Connectez-vous à Docker :
```
docker login gcr.io
```
Cette opération crée un fichier $HOME/.docker/config.json.
Répertoriez les adresses IP de tous les nœuds du plan de contrôle, séparées par un espace :
```
IPs=(NODE_IP1 NODE_IP2 ...)
```
Copiez la configuration Docker sur les nœuds :
```
for ip in "${IPs[@]}"; do
  scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
```
Remplacez USER_NAME par le nom d'utilisateur défini dans le fichier de configuration du cluster d'administrateur.

Définissez les identifiants d'extraction d'images pour Docker :

ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"

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.8.1 (anthosBareMetalVersion: 1.8.1) gérant les clusters d'utilisateurs version 1.7.2 est acceptable, mais les clusters d'utilisateur version 1.6.3 ne font pas l'objet d'une version mineure.

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.8.2, qui a été publiée le 29 juillet 2021, vous ne pouvez pas mettre à niveau vos clusters d'utilisateur vers la version 1.7.3, car elle a été publiée le 16 août 2021.

Le pilote du groupe de contrôle est configuré sur `cgroupfs` de manière incorrecte

Si vous rencontrez des problèmes liés au pilote du groupe de contrôle (cgroup), cela peut être dû à une configuration incorrecte sur cgroupfs par les clusters Anthos sur Bare Metal, au lieu de systemd.

Pour résoudre ce problème :

Connectez-vous à vos machines et ouvrez /etc/containerd/config.toml.

Sous [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options], ajoutez SystemdCgroup = true :

...
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
       runtime_type = "io.containerd.runc.v2"
       runtime_engine = ""
       runtime_root = ""
       privileged_without_host_devices = false
       base_runtime_spec = ""
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
         SystemdCgroup = true
 [plugins."io.containerd.grpc.v1.cri".cni]
   bin_dir = "/opt/cni/bin"
   conf_dir = "/etc/cni/net.d"
   max_conf_num = 1
   conf_template = ""
...

Enregistrez les modifications et fermez le fichier.
Ouvrir /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

À la fin du fichier, ajoutez --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service :

[Service]
Environment="HOME=/root"
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service

Enregistrez les modifications et redémarrez le serveur.
Vérifiez que systemd est le pilote du groupe de contrôle en exécutant la commande suivante :
```
systemd-cgls
```
Vérifiez qu'il existe une section kubepods.slice et que tous les pods se trouvent dans cette section.

Opération

kubeconfig secret overwritten

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 celui du cluster d'administrateur. L'écrasement du fichier entraîne l'échec des opérations de cluster standards, telles que les mises à jour et les mises à niveau, pour les clusters d'utilisateur concernés. Ce problème s'applique aux versions 1.11.1 et antérieures d'Anthos clusters on bare metal.

Pour déterminer si un cluster d'utilisateur est affecté par ce problème, exécutez la commande suivante :

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

Remplacez les éléments suivants :

ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
USER_CLUSTER_NAME : nom du cluster d'utilisateur à vérifier.

Si le nom du cluster dans la sortie (consultez contexts.context.cluster dans l'exemple de sortie suivant) correspond au nom du cluster d'administrateur, le cluster d'utilisateur spécifié est concerné.

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Les étapes suivantes permettent de restaurer une fonction sur un cluster d'utilisateur concerné (USER_CLUSTER_NAME) :

Localisez le fichier kubeconfig du cluster d'utilisateur.

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 de machine sont corrects pour votre cluster.
Exécutez la commande suivante pour supprimer le fichier kubeconfig corrompu dans le cluster d'administrateur :
```
kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
```

Exécutez la commande suivante pour enregistrer le secret kubeconfig approprié dans le cluster d'administrateur :

kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
    --from-file=value=PATH_TO_GENERATED_FILE

Réinitialisation/Suppression

Compatibilité du cluster utilisateur

Vous ne pouvez pas réinitialiser les clusters d'utilisateur à l'aide de la commande bmctl reset.

Points d'installation et `fstab`

La réinitialisation ne permet pas de désinstaller les points d'installation dans /mnt/localpv-share/, ni de nettoyer les entrées correspondantes dans /etc/fstab.

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 rotation à la demande n'est actuellement pas disponible.

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.

Journaux et surveillance

Les journaux de nœuds ne sont pas exportés vers Cloud Logging.

Les journaux de nœuds provenant de nœuds comportant un point (".") dans leur nom ne sont pas exportés vers Cloud Logging. Pour contourner ce problème, suivez les instructions ci-dessous pour ajouter un filtre à la ressource stackdriver-log-forwarder-config afin de permettre à l'opérateur Stackdriver de reconnaître et d'exporter ces journaux.

Effectuez le scaling à la baisse de l'opérateur Stackdriver, stackdriver-operator :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system scale \
    deploy stackdriver-operator --replicas=0

Modifiez le fichier ConfigMap du service de transfert de journaux, stackdriver-log-forwarder-config :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
    stackdriver-log-forwarder-config

Ajoutez le filtre suivant à la fin de la section input-systemd.conf du fichier ConfigMap :

   [FILTER]
       Name    lua
       Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
       script  replace_dot.lua
       call    replace

 replace_dot.lua: |
   function replace(tag, timestamp, record)
       new_record = record

       local local_resource_id_key = "logging.googleapis.com/local_resource_id"

       -- Locate the local_resource_id
       local local_resource_id = record[local_resource_id_key]

       local first = 1
       local new_local_resource_id = ""
       for s in string.gmatch(local_resource_id, "[^.]+") do
           new_local_resource_id = new_local_resource_id .. s
           if first == 1 then
               new_local_resource_id = new_local_resource_id .. "."
               first = 0
           else
               new_local_resource_id = new_local_resource_id .. "_"
           end
       end

       -- Remove the trailing underscore
       new_local_resource_id = new_local_resource_id:sub(1, -2)
       new_record[local_resource_id_key] = new_local_resource_id
       return 1, timestamp, new_record
   end

Supprimez tous les pods du service de transfert de journaux :

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

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

Déployez un daemonset pour nettoyer toutes les données non traitées dans les tampons en flux continu :

kubectl --kubeconfig ADMIN_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

Vérifiez que le DaemonSet a nettoyé tous les nœuds à l'aide des commandes suivantes.

kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
    -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
    -l app=fluent-bit-cleanup --no-headers | wc -l

Le résultat des deux commandes doit être égal au numéro de nœud du cluster.

Supprimez le DaemonSet de nettoyage :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system delete ds fluent-bit-cleanup

Redémarrez les pods :

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
    daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

Mise en réseau

Adresse IP source du client avec équilibrage de charge groupé de couche 2

La définition de la règle de trafic externe sur Local peut entraîner des erreurs de routage, 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 que le trafic de nœud local.

Si vous souhaitez conserver l'adresse IP source du client, une configuration supplémentaire peut être requise pour s'assurer que les adresses IP des services sont accessibles. Pour plus d'informations sur la configuration, consultez la section Conserver l'adresse IP source du client dans la section "Configurer l'équilibrage de charge groupé".

La modification de `firewalld` entraîne la suppression des chaînes de 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.

É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

Aucune vérification préalable n'est nécessaire pour valider les adresses IP qui se chevauchent dans différents clusters.

Fonctionnalité `hostport` dans les clusters Anthos sur Bare Metal

La fonctionnalité hostport de ContainerPort n'est actuellement pas disponible.

OS

Échec de la création ou de la mise à niveau du cluster sur CentOS

En décembre 2020, la communauté CentOS et Red Hat ont annoncé l'abandon de CentOS. Le 31 janvier 2022, CentOS 8 est arrivé en fin de vie. En raison de la fin de vie, les dépôts yum ont cessé de fonctionner pour CentOS, ce qui entraîne l'échec des opérations de création et de mise à niveau du cluster. Cela s'applique à toutes les versions compatibles de CentOS et affecte toutes les versions d'Anthos clusters sur solution Bare Metal.

Pour contourner ce problème, exécutez les commandes suivantes pour que votre CentOS utilise un flux d'archive:

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

En tant que solution à long terme, envisagez de migrer vers un autre système d'exploitation compatible, tel que Ubuntu ou RHEL.

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.

Champs modifiables dans la spécification du cluster et du pool de nœuds

Actuellement, seuls les champs de spécification de cluster et de pool de nœuds suivants dans le fichier de configuration de cluster peuvent être mis à jour après la création du cluster (il s'agit de champs modifiables) :

Pour l'objet Cluster (kind: Cluster), les champs suivants sont modifiables :
- spec.anthosBareMetalVersion
- spec.bypassPreflightCheck
- spec.controlPlane.nodePoolSpec.nodes
- spec.loadBalancer.nodePoolSpec.nodes
- spec.maintenanceBlocks
- spec.nodeAccess.loginUser
Pour l'objet NodePool (kind: NodePool), les champs suivants sont modifiables :
- spec.nodes

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.