Version 1.6. 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.7, consultez la page Mettre à niveau Anthos sur solution Bare Metal dans la documentation de la version 1.7.

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.

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.

Mises à niveau et mises à jour

La mise à niveau n'est pas disponible dans les versions Anthos clusters on Bare Metal 1.6.x.

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

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

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

Identifiants du cluster d'utilisateur

La commande bmctl reset repose sur la section des identifiants de premier niveau dans le fichier de configuration du cluster. Pour les clusters d'utilisateur, vous devez mettre à jour manuellement le fichier pour ajouter la section des identifiants.

Points d'installation et `fstab`

La réinitialisation ne permet pas de désinstaller les points d'installation sous /mnt/anthos-system et /mnt/localpv-share/. Elle ne nettoie pas non plus 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.

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.

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

Échecs de connectivité du pod et filtrage du chemin d'accès inverse

Anthos clusters on bare metal configure le filtrage du chemin d'accès inverse sur les nœuds afin de désactiver la validation des sources (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 des délais d'inactivité associés aux communications hors nœud.

Le filtrage du chemin d'accès inverse est défini par les fichiers rp_filter dans le dossier de configuration IPv4 (net/ipv4/conf/all). Cette valeur peut également être remplacée par sysctl, qui stocke les paramètres de filtrage du chemin d'accès inverse dans un fichier de configuration de sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf.

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, exécutez les commandes suivantes afin de localiser et de supprimer le pod anetd, et un nouveau pod anetd démarrera à 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.

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

Le nœud affiche l'état `NotReady`

Dans certaines conditions de chargement, l'état des clusters Anthos on bare metal 1.6.x peut afficher un état NotReady en raison de la présence d'un générateur d'événements de cycle de vie de pod (PLEG) non opérationnel. L'état du nœud contient l'entrée suivante :

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

Comment savoir si je suis concerné ?

Ce problème est probablement dû à la version binaire de runc. Pour vérifier si la version problématique est installée, connectez-vous à l'une des machines du cluster à l'aide de SSH, puis exécutez la commande suivante :

/usr/bin/runc -v

Si la sortie donne 1.0.0-rc93, la version problématique est installée.

Solutions possibles

Pour résoudre ce problème, nous vous recommandons de passer à des clusters Anthos on bare metal 1.7.0 ou ultérieurs.

Si cette mise à jour n'est pas possible, vous pouvez rétablir la version précédente du package containerd.io sur les machines problématiques exécutant des nœuds. Pour ce faire, connectez-vous à la machine exécutant des nœuds via SSH et exécutez la commande suivante :

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.