Version 1.9. Cette version n'est plus compatible. Pour plus d'informations, consultez la politique de compatibilité avec les versions. Pour savoir comment passer à la version 1.10, consultez Mettre à niveau Anthos sur solution Bare Metal dans la documentation 1.10.

Versions compatibles: 1.14 | 1.13 | 1.12

Problèmes connus 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.

Installation

Échec de la création du cluster lors de l'utilisation de plusieurs cartes d'interface réseau, de `containerd` et d'un proxy HTTP

La création du cluster échoue lorsque vous disposez de la combinaison de conditions suivante :

Le cluster est configuré pour utiliser containerd comme environnement d'exécution de conteneur (nodeConfig.containerRuntime défini sur containerd dans le fichier de configuration du cluster, qui est la valeur par défaut pour les clusters Anthos sur solution Bare Metal version 1.9).
Le cluster est configuré pour fournir plusieurs interfaces réseau, avec plusieurs cartes d'interface réseau, pour les pods (clusterNetwork.multipleNetworkInterfaces défini sur true dans le fichier de configuration du cluster).
Le cluster est configuré pour utiliser un proxy (spec.proxy.url est spécifié dans le fichier de configuration du cluster). Même si la création du cluster échoue, ce paramètre est propagé lorsque vous essayez de créer un cluster. Vous pouvez voir ce paramètre proxy en tant que variable d'environnement HTTPS_PROXY ou dans votre configuration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Pour contourner ce problème, ajoutez les CIDR de service (clusterNetwork.services.cidrBlocks) à la variable d'environnement NO_PROXY sur toutes les machines de nœud.

L'option `containerRuntime` non spécifiée n'est pas définie par défaut sur containerd

Dans la version 1.9.0 des clusters Anthos sur solution Bare Metal, le nom par défaut containerRuntime a été mis à jour de docker vers containerd dans le fichier de configuration de cluster généré. Si le champ containerRuntime n'est pas défini ou s'il est supprimé du fichier de configuration de cluster, containerRuntime est défini sur docker lorsque vous créez des clusters. La valeur containerRuntime doit être définie par défaut sur containerd, sauf si elle est explicitement définie sur docker. Ce problème ne concerne que les versions 1.9.0 et 1.9.1.

Pour déterminer l'environnement d'exécution de conteneur utilisé par votre cluster, suivez les étapes décrites dans la section Récupérer les informations sur le cluster. Vérifiez la valeur de containerRuntime dans la section cluster.spec.nodeConfig.

Le seul moyen de modifier l'environnement d'exécution des conteneurs consiste à mettre à niveau vos clusters. Pour en savoir plus, consultez la page Modifier l'environnement d'exécution du conteneur.

Ce problème est résolu dans la version 1.9.2 d'Anthos clusters on bare metal.

Incompatibilité du groupe de contrôle v2

Le groupe de contrôle v2 (cgroup v2) n'est pas officiellement compatible avec Anthos Clusters on Bare Metal 1.9. 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.

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.

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.

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.

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 et renvoie 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, ce qui recrée le répertoire .manifests.

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

`bmctl` ne peut pas créer, mettre à jour ni réinitialiser des clusters d'utilisateur de version inférieure

La CLI bmctl ne peut pas créer, mettre à jour ni réinitialiser un cluster d'utilisateur avec une version mineure inférieure, quelle que soit la version du cluster d'administrateur. Par exemple, vous ne pouvez pas utiliser bmctl avec une version de1.N.X pour réinitialiser un cluster d'utilisateur de la version 1.N-1.Y, même si le cluster d'administrateur est également en version 1.N.X.

Si vous êtes concerné par ce problème, vous devriez voir les journaux semblables à l'exemple suivant lorsque vous utilisez bmctl :

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
    * cluster version 1.8.1 is not supported in bmctl version 1.9.5, only
cluster version 1.9.5 is supported

Pour contourner le problème, 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.

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.

Échec des mises à niveau pour les clusters de version 1.8 en mode de maintenance

Toute tentative de mise à niveau d'un cluster de version 1.8.x vers la version 1.9.x échoue si des machines de nœud ont été précédemment mises en mode de maintenance. Ceci est dû à une annotation qui persiste sur ces nœuds.

Pour savoir si vous êtes concerné par ce problème, procédez comme suit :

Obtenez la version du cluster que vous souhaitez mettre à niveau en exécutant la commande suivante :
```
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"
```
Si la valeur renvoyée est pour la version mineure 1.8, telle que 1.8.3, continuez. Dans le cas contraire, ce problème ne vous concerne pas.
Vérifiez si le cluster comporte des nœuds qui ont déjà été mis en mode de maintenance en exécutant la commande suivante :
```
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"
```
Si les annotations renvoyées contiennent baremetal.cluster.gke.io/maintenance-mode-duration, vous êtes concerné par ce problème connu.

Pour débloquer la mise à niveau du cluster, exécutez la commande suivante pour chaque machine de nœud affectée afin de supprimer l'annotation baremetal.cluster.gke.io/maintenance-mode-duration :

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

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

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.9.0 (anthosBareMetalVersion: 1.9.0) gérant les clusters d'utilisateur version 1.8.4 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.

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.

Operation

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

Ce problème s'applique aux clusters Anthos sur Bare Metal 1.9.x, 1.10.0 et 1.10.1. Il est corrigé dans les versions 1.10.2 et ultérieures.

Nœuds non ordonnés si vous n'utilisez pas la procédure de mode de maintenance

Si vous utilisez manuellement kubectl cordon sur un nœud, les clusters Anthos sur solution Bare Metal peuvent dissocier ce nœud avant que vous soyez prêt dans le but de rapprocher l'état attendu. Pour les clusters Anthos sur solution Bare Metal version 1.12.0 et antérieure, utilisez le mode de maintenance pour périmétrer et drainer les nœuds en toute sécurité. Dans la version 1.12.1 (anthosBareMetalVersion: 1.12.1) ou ultérieure, les clusters Anthos sur solution Bare Metal ne dissocient pas vos nœuds de manière inattendue lorsque vous utilisez kubectl cordon.

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

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

Si vous utilisez containerd en tant qu'environnement d'exécution du conteneur, l'exécution d'un instantané en tant qu'utilisateur non racine nécessite que /usr/local/bin se trouve dans le chemin d'accès à l'utilisateur. Sinon, l'opération échoue avec une erreur crictl: command not found.

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

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.

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.

Journalisation et surveillance

Journaux manquants après une panne réseau

Dans certains cas, lorsque votre cluster se rétablit après une panne réseau, vous pouvez constater que les nouveaux journaux n'apparaissent pas dans Cloud Logging. Vous pouvez également voir plusieurs messages semblables au suivant dans vos journaux pour stackdriver-log-forwarder :

re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds

Pour réactiver le transfert des journaux, redémarrez le pod stackdriver-log-forwarder. Si le transfert des journaux est redémarré dans les 4,5 heures suivant la panne, les journaux mis en mémoire tampon sont transférés vers Cloud Logging. Les journaux datant de plus de 4,5 heures sont supprimés.

Interruptions intermittentes de l'exportation de métriques

Les clusters Anthos sur Bare Metal 1.9.x et 1.10.x peuvent rencontrer des interruptions lors de l'exportation continue et normale des métriques. Des métriques peuvent également être manquantes sur certains nœuds. Si ce problème affecte vos clusters, vous risquez de rencontrer des écarts de données pour les métriques suivantes (au minimum) :

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

Pour résoudre ce problème, mettez à niveau vos clusters vers la version 1.10.3 ou une version ultérieure.

Si vous ne pouvez pas effectuer de mise à niveau, procédez comme suit :

Ouvrez votre ressource stackdriver pour la modifier :
```
kubectl -n kube-system edit stackdriver stackdriver
```

Pour augmenter la demande de processeur pour gke-metrics-agent de 10m à 50m, ajoutez la section resourceAttrOverride suivante au fichier manifeste stackdriver :

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Votre ressource modifiée doit ressembler à ce qui suit :

spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Enregistrez les modifications et fermez l'éditeur de texte.
Pour vérifier que vos modifications ont pris effet, exécutez la commande suivante :
```
kubectl -n kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
La commande détecte cpu: 50m si vos modifications ont été appliquées.
Pour empêcher l'annulation des modifications suivantes, effectuez un scaling à la baisse de stackdriver-operator :
```
kubectl -n kube-system scale deploy stackdriver-operator --replicas=0
```
Ouvrez gke-metrics-agent-conf pour y apporter des modifications :
```
kubectl -n kube-system edit configmap gke-metrics-agent-conf
```

Modifiez la configuration pour remplacer toutes les instances de probe_interval: 0.1s par probe_interval: 13s :

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Enregistrez les modifications et fermez l'éditeur de texte.

Redémarrez l'ensemble de daemons gke-metrics-agent :

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

Sécurité

Le conteneur ne peut pas écrire dans `VOLUME` défini dans Dockerfile avec containerd et SELinux

Si vous utilisez containerd en tant qu'environnement d'exécution de conteneur et que SELinux est activé sur votre système d'exploitation, il est possible que le VOLUME défini dans le fichier Dockerfile de l'application ne soit pas accessible en écriture. Par exemple, les conteneurs créés avec le fichier Dockerfile suivant ne peuvent pas écrire dans le dossier /tmp.

FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp

Pour vérifier si vous êtes concerné par ce problème, exécutez la commande suivante sur le nœud qui héberge le conteneur problématique :

ausearch -m avc

Si vous êtes concerné par ce problème, une erreur denied s'affiche comme suit :

time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979):
proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6
items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC
msg=audit(1649106092.768:10979): avc:  denied {
write } for  pid=76042 comm="bash"
name="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:container_t:s0:c701,c935
tcontext=system_u:object_r:container_ro_file_t:s0 tclass=dir permissive=0

Pour contourner ce problème, effectuez l'une des modifications suivantes :

Désactivez SELinux.
N'utilisez pas la fonctionnalité VOLUME dans Dockerfile.

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

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.

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.

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.

Mise en réseau

Plusieurs passerelles par défaut interrompent la connectivité à des points de terminaison externes

Le fait d'avoir plusieurs passerelles par défaut dans un nœud peut entraîner une rupture de connectivité entre un pod et des points de terminaison externes, tels que google.com.

Pour déterminer si vous êtes concerné par ce problème, exécutez la commande suivante sur le nœud :

ip route show

Plusieurs instances de default dans la réponse indiquent que vous êtes affecté.

Pour contourner ce problème, assurez-vous que l'interface de passerelle par défaut utilisée pour l'adresse IP de votre nœud Kubernetes est la première de la liste.

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

Système d'exploitation

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

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.

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.