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

Versions compatibles : 1.14 | 1.13 | 1.12

Problèmes connus des clusters Anthos sur Bare Metal

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

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 Bare Metal version 1.8).
Le cluster est configuré pour fournir plusieurs interfaces réseau, avec plusieurs cartes d'interface réseau, pour les pods (spec.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.

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 proviennent du fait que /tmp a été 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.

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 :

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

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

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.

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

Échec de la mise à niveau des clusters 1.7.x pour certaines configurations d'équilibreur de charge

La mise à niveau des clusters de la version 1.7.x vers la version 1.8.y peut échouer pour les configurations d'équilibreur de charge suivantes :

Équilibreur de charge externe configuré manuellement (loadBalancer.mode défini sur manual)
Équilibrage de charge groupé (loadBalancer.mode défini sur bundled) et utilisant un pool de nœuds distinct (loadBalancer.nodePoolSpec.nodes est spécifié)

L'un des symptômes de cette défaillance est que la tâche cal-update sur un nœud de plan de contrôle échoue à la tâche Check apiserver health avec des messages d'erreur de connexion refusée.

Voici un exemple d'entrée de journal pour la tâche cal-update :

TASK [cal-update : Check apiserver health] *************************************
Thursday 20 January 2022  13:50:46 +0000 (0:00:00.033)       0:00:09.316 ******
FAILED - RETRYING: Check apiserver health (30 retries left).
FAILED - RETRYING: Check apiserver health (29 retries left).
FAILED - RETRYING: Check apiserver health (28 retries left).
FAILED - RETRYING: Check apiserver health (27 retries left).
FAILED - RETRYING: Check apiserver health (26 retries left).
...
FAILED - RETRYING: Check apiserver health (3 retries left).
FAILED - RETRYING: Check apiserver health (2 retries left).
FAILED - RETRYING: Check apiserver health (1 retries left).
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.
If you need to use command because get_url or uri is insufficient you can add
'warn: false' to this command task or set 'command_warnings=False' in
ansible.cfg to get rid of this message.
fatal: [10.50.116.79]: FAILED! => {"attempts": 30, "changed": true, "cmd": "curl
-k https://127.0.0.1/healthz", "delta": "0:00:00.008949", "end": "2022-01-20
19:22:30.381875", "msg": "non-zero return code", "rc": 7, "start": "2022-01-20
19:22:30.372926", "stderr": "  % Total    % Received % Xferd  Average Speed
Time    Time     Time  Current\n                                 Dload  Upload
Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --
:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to 127.0.0.1 port 443:
Connection refused", "stderr_lines": ["  % Total    % Received % Xferd  Average
Speed   Time    Time     Time  Current", "                                 Dload
Upload   Total   Spent    Left  Speed", "", "  0     0    0     0    0     0
0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to
127.0.0.1 port 443: Connection refused"], "stdout": "", "stdout_lines": []}

Pour contourner le problème, créez un transfert de port depuis le port 443 (où la vérification est effectuée) vers le port 6444 (où apiserver écoute) avant de procéder à la mise à niveau. Pour créer le transfert de port, exécutez la commande suivante sur chaque nœud du plan de contrôle :

sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

La tâche cal-update s'exécute en cas de rapprochement et de vérification sur le port 443. Vous devez donc conserver ce transfert de port pour vos clusters mis à niveau avec la version 1.8.x.

Après avoir effectué la mise à niveau vers la version 1.9.0 ou une version ultérieure, supprimez le transfert de port en exécutant la commande suivante sur chaque nœud du plan de contrôle :

sudo iptables -t nat -D OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

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 :

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.

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.

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 :

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

Operation

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

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.

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

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 :

Effectuez le scaling à la baisse de stackdriver-operator :

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

Supprimez le DaemonSet stackdriver-log-forwarder :
```
kubectl --kubeconfig KUBECONFIG -n kube-system delete daemonset \
    stackdriver-log-forwarder
```
Vérifiez que les pods stackdriver-log-forwarder ont été supprimés avant de passer à l'étape suivante.

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

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

Supprimez le DaemonSet de nettoyage :

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

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.

Problèmes connus des clusters Anthos sur Bare Metal

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

Incompatibilité du groupe de contrôle v2

Messages d'erreur anodins pendant l'installation

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

Vérifications préliminaires et autorisation refusée

Identifiants par défaut de l'application et bmctl

Ubuntu 20.04 LTS et bmctl

Service Docker

Miroir de registre et Cloud Audit Logging

Containerd requiert /usr/local/bin dans PATH

Installer sur vSphere

Oscillation du niveau de préparation du nœud

Ubuntu Containerd

Ubuntu Docker

CentOS/RHEL Containerd

CentOS/RHEL Docker

Mises à niveau et mises à jour

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

Mise à niveau bloquée à error during manifests operations

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

bmctl update ne supprime pas les blocs de maintenance.

Échec de la mise à niveau des clusters 1.7.x pour certaines configurations d'équilibreur de charge

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

Mises à niveau vers la version 1.8.3 ou 1.8.4

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

Incompatibilité avec Ubuntu 18.04 et 18.04.1

Mettre à niveau les clusters 1.7.x qui utilisent Containerd

Échecs de mise à niveau de SELinux

Le drainage de nœud ne peut pas démarrer lorsque le nœud est hors de portée

Operation

kubeconfig secret overwritten

Réinitialisation/Suppression

Suppression d'un espace de noms

Service containerd

Sécurité

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

Mise en réseau

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

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

Dupliquer les adresses egressSourceIP

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

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

Chevauchement d'adresses IP dans différents clusters

Système d'exploitation

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

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

Configuration

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

Environnement d'exécution des VM Anthos

SELinux

Erreurs SELinux lors de la création du pod

Instantanés

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

GKE Connect

Pod gke-connect-agent en boucle de plantage

Journalisation et surveillance

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

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

Identifiants par défaut de l'application et `bmctl`

Ubuntu 20.04 LTS et `bmctl`

Containerd requiert `/usr/local/bin` dans PATH

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

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

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

Dupliquer les adresses `egressSourceIP`

Pod `gke-connect-agent` en boucle de plantage

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