Version 1.10. 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.11, consultez Mettre à niveau Anthos sur solution Bare Metal dans la documentation 1.11.

Versions compatibles : 1.14 | 1.13 | 1.12

Problèmes connus des clusters Anthos sur Bare Metal

Cette page répertorie tous les problèmes connus liés aux clusters Anthos sur bare metal. Pour filtrer les problèmes connus par version ou catégorie de produit, sélectionnez les filtres de votre choix dans les menus déroulants suivants.

Sélectionnez la version de vos clusters Anthos sur bare metal :

Sélectionnez la catégorie de problème que vous rencontrez :

Vous pouvez également rechercher le problème rencontré:

Catégorie Version(s) identifiée(s) Problème et solution

Mise en réseau

1.15.0 à 1.15.2

`orderPolicy` (DNS) non reconnu

OrderPolicy n'est pas reconnu en tant que paramètre et n'est pas utilisé. À la place, les clusters Anthos sur bare metal utilisent toujours Random.

Ce problème est dû au fait que le modèle CoreDNS n'a pas été mis à jour, ce qui explique que orderPolicy soit ignoré.

Solution :

Mettez à jour le modèle CoreDNS et appliquez le correctif. Ce correctif persiste jusqu'à une mise à niveau.

Modifiez le modèle existant:

kubectl edit cm -n kube-system coredns-template

Remplacez le contenu du modèle par ce qui suit:

coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}

Mise en réseau, fonctionnement

1.10, 1.11, 1.12, 1.13 et 1.14

Composants de la passerelle réseau Anthos évincés ou en attente, car la classe de priorité est manquante

Les pods de passerelle réseau dans kube-system peuvent afficher l'état Pending ou Evicted, comme illustré dans l'exemple de résultat condensé suivant:

$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Ces erreurs indiquent des événements d'éviction ou une incapacité à planifier les pods en raison de ressources de nœuds. Comme les pods de passerelle réseau Anthos n'ont pas de PriorityClass, ils ont la même priorité par défaut que les autres charges de travail. Lorsque les nœuds sont limités en ressources, les pods de passerelle réseau peuvent être évincés. Ce comportement est particulièrement mauvais pour le DaemonSet ang-node, car ces pods doivent être planifiés sur un nœud spécifique et ne peuvent pas être migrés.

Solution :

Passez à la version 1.15 ou ultérieure.

Pour résoudre ce problème à court terme, vous pouvez attribuer manuellement une classe PriorityClass aux composants de la passerelle réseau Anthos. Le contrôleur de clusters Anthos sur bare metal écrase ces modifications manuelles lors d'un processus de rapprochement, par exemple lors d'une mise à niveau d'un cluster.

Attribuez la classe de priorité system-cluster-critical aux déploiements du contrôleur de cluster ang-controller-manager et autoscaler.
Attribuez la classe Class de classe system-node-critical au DaemonSet du nœud ang-daemon.

Installation, mises à niveau et mises à jour

1.15.0, 1.15.1, 1.15.2

La création et la mise à niveau des clusters échouent en raison de leur longueur

La création des clusters de la version 1.15.0, 1.15.1 ou 1.15.2 ou la mise à niveau vers la version 1.15.0, 1.15.1 ou 1.15.2 échoue s'ils comportent plus de 48 caractères (version 1.15.0) ou 45 caractères (version 1.15.1 ou 1). Lors des opérations de création et de mise à niveau des clusters, les clusters Anthos sur bare metal créent une ressource de vérification de l'état d'état dont le nom intègre le nom et la version du cluster:

Pour les clusters version 1.15.0, le nom de la ressource de vérification de l'état est CLUSTER_NAME-add-ons-CLUSTER_VER.
Pour les clusters version 1.15.1 ou 1.15.2, le nom de la ressource de vérification de l'état est CLUSTER_NAME-kubernetes-CLUSTER_VER.

Pour les noms de cluster longs, le nom de la ressource de vérification de l'état dépasse la limite de longueur de caractères dans Kubernetes 63 pour les noms de libellés, ce qui empêche la création de la ressource de vérification de l'état d'état. Sans vérification de l'état réussie, le cluster échoue.

Pour savoir si vous êtes concerné par ce problème, utilisez kubectl describe pour vérifier la ressource défaillante:

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Si ce problème vous concerne, la réponse contient un avertissement pour un ReconcileError comme suit:

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Solution

Pour débloquer la mise à niveau ou la création du cluster, vous pouvez contourner la vérification d'état. Exécutez la commande suivante pour appliquer un correctif à la ressource personnalisée de vérification d'état: (status: {pass: true}).

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'

Mises à niveau et mises à jour

1,14 et 1,15

Les clusters version 1.14.0 et 1.14.1 avec fonctionnalités d'aperçu ne peuvent pas être mis à niveau vers la version 1.15.x

Si une fonctionnalité d'aperçu est activée sur les clusters version 1.14.0 et 1.14.1, ils ne peuvent pas passer à la version 1.15.x. Cela s'applique à des fonctionnalités en preview, telles que la possibilité de créer un cluster sans kube-proxy, qui est activé avec l'annotation suivante dans le fichier de configuration du cluster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Si vous êtes affecté par ce problème, vous obtenez un message d'erreur semblable à celui-ci lors de la mise à niveau du cluster:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Ce problème est résolu dans les clusters Anthos sur bare metal version 1.14.2 ou ultérieure.

Solution :

Si vous ne parvenez pas à mettre à niveau vos clusters vers la version 1.14.2 ou une version ultérieure avant de passer à la version 1.15.x, vous pouvez passer directement à la version 1.15.x en utilisant un cluster d'amorçage:

bmctl upgrade cluster --use-bootstrap=true

Opération

1.15

Les clusters version 1.15 n'acceptent pas les adresses IP flottantes en double

La passerelle réseau Anthos ne vous permet pas de créer des ressources personnalisées NetworkGatewayGroup contenant des adresses IP dans spec.floatingIPs qui sont déjà utilisées dans des ressources personnalisées NetworkGatewayGroup existantes. Cette règle est appliquée par un webhook dans les clusters Anthos sur bare metal version 1.15.0 ou ultérieure. Les adresses IP flottantes en double existantes ne génèrent pas d'erreurs. Le webhook empêche uniquement la création de ressources personnalisées NetworkGatewayGroups contenant des adresses IP en double.

Le message d'erreur du webhook identifie l'adresse IP en conflit et la ressource personnalisée existante qui l'utilise déjà:

IP address exists in other gateway with name default

La documentation initiale sur les fonctionnalités réseau avancées, telles que la passerelle de sortie NAT, ne tient pas compte des adresses IP en double. Au départ, seule la ressource NetworkGatewayGroup nommée default a été reconnue par le rapprochement. La passerelle réseau Anthos reconnaît désormais l'ensemble des ressources personnalisées NetworkGatewayGroup dans l'espace de noms du système. Les ressources personnalisées NetworkGatewayGroup existantes sont honorées telles quelles.

Solution :

Des erreurs se produisent lors de la création d'une ressource personnalisée NetworkGatewayGroup uniquement.

Pour corriger l'erreur:

Utilisez la commande suivante pour répertorier les ressources personnalisées NetworkGatewayGroups:

kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system -o yaml

Ouvrez les ressources personnalisées NetworkGatewayGroup existantes et supprimez toutes les adresses IP flottantes en conflit (spec.floatingIPs):
```
kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
    -n kube-system RESOURCE_NAME
```
Pour appliquer vos modifications, fermez et enregistrez les ressources personnalisées modifiées.

Environnement d'exécution des VM Anthos

1.13.7

Les VM peuvent ne pas démarrer sur des clusters 1.13.7 qui utilisent un registre privé

Lorsque vous activez l'environnement d'exécution des VM Anthos sur un cluster version 1.13.7 nouvelle ou mise à niveau qui utilise un registre privé, les VM qui se connectent au réseau de nœuds ou utilisent un GPU peuvent ne pas démarrer correctement. Ce problème est dû au fait que certains pods système de l'espace de noms vm-system obtiennent des erreurs d'extraction d'image. Par exemple, si votre VM utilise le réseau de nœuds, certains pods peuvent signaler des erreurs d'extraction d'image comme suit:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Ce problème est résolu dans les clusters Anthos sur bare metal version 1.14.0 et supérieures.

Solution

Si vous ne parvenez pas à mettre à niveau vos clusters immédiatement, vous pouvez extraire des images manuellement. Les commandes suivantes extraient l'image du plug-in CNI macvtap de votre VM et la transfèrent vers votre registre privé:

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Remplacez REG_HOST par le nom de domaine d'un hôte que vous mettez en miroir localement.

Installation

1,11 et 1,12

Lors de la création du cluster dans le cluster de genre, le pod gke-metric-agent ne démarre pas

Lors de la création du cluster dans le cluster de genre, le pod gke-metrics-agent ne démarre pas en raison d'une erreur d'extraction d'image:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

En outre, l'entrée suivante s'affiche dans le journal containerd du cluster d'amorçage:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Le pod affiche l'erreur suivante:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Solution

Malgré les erreurs, le processus de création de cluster n'est pas bloqué, car l'objectif du pod gke-metrics-agent dans le cluster de genre est de faciliter le taux de réussite de la création de cluster, ainsi que pour le suivi et la surveillance internes. Vous pouvez donc ignorer cette erreur.

Solution

Opération, mise en réseau

1.12, 1.13, 1.14, 1.15

L'accès à un point de terminaison de service IPv6 entraîne le plantage du nœud LoadBalancer sur CentOS ou RHEL

Lorsque vous accédez à un service double pile (un service qui comporte à la fois des points de terminaison IPv4 et IPv6) et que vous utilisez le point de terminaison IPv6, le nœud LoadBalancer qui diffuse le service peut planter. Ce problème concerne les clients qui utilisent des services double pile avec CentOS ou RHEL, et la version du noyau antérieure à kernel-4.18.0-372.46.1.el8_6.

Si vous pensez que ce problème vous concerne, vérifiez la version du noyau sur le nœud LoadBalancer à l'aide de la commande uname -a.

Solution :

Mettez à jour le nœud LoadBalancer vers la version kernel-4.18.0-372.46.1.el8_6 ou ultérieure du noyau. Cette version du noyau est disponible par défaut dans CentOS et RHEL 8.6 et versions ultérieures.

Mise en réseau

1.11, 1.12, 1.13, 1.14.0

Problèmes de connectivité intermittents après le redémarrage du nœud

Après avoir redémarré un nœud, vous pouvez rencontrer des problèmes de connectivité intermittents pour un service NodePort ou LoadBalancer. Par exemple, vous pouvez rencontrer des erreurs de handshake TLS intermittentes ou de réinitialisation de la connexion. Ce problème est résolu pour les clusters Anthos sur bare metal versions 1.14.1 et ultérieures.

Pour vérifier si ce problème vous concerne, consultez les règles de transfert iptables sur les nœuds sur lesquels le pod de backend du service concerné est en cours d'exécution:

sudo iptables -L FORWARD

Si la règle KUBE-FORWARD s'affiche avant la règle CILIUM_FORWARD dans iptables, vous pouvez être concerné par ce problème. L'exemple de résultat suivant affiche un nœud dans lequel le problème existe:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Solution :

Redémarrez le pod anetd sur le nœud mal configuré. Après avoir redémarré le pod anetd, la règle de transfert dans iptables doit être configurée correctement.

L'exemple de résultat suivant montre que la règle CILIUM_FORWARD est maintenant correctement configurée avant la règle KUBE-FORWARD:


Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */

Mises à niveau et mises à jour

1,9 et 1,10

La fonctionnalité en preview ne conserve pas les informations d'origine concernant l'autorisation et le propriétaire

La fonctionnalité d'aperçu du cluster 1.9.x utilisant bmctl 1.9.x ne conserve pas les informations initiales sur l'autorisation et le propriétaire. Pour vérifier si vous êtes concerné par cette fonctionnalité, extrayez le fichier sauvegardé à l'aide de la commande suivante:

tar -xzvf BACKUP_FILE

Solution

Vérifiez que metadata.json est présent et que bmctlVersion est 1.9.x. Si metadata.json n'est pas présent, effectuez une mise à niveau vers le cluster 1.10.x et utilisez bmctl 1.10.x pour effectuer une sauvegarde/restauration.

Migrations et créations

1.14.2

`clientconfig-operator` reste en attente avec `CreateContainerConfigError`

Si vous avez mis à niveau ou créé un cluster de version 1.14.2 avec une configuration OIDC/LDAP, le pod clientconfig-operator peut rester bloqué. Avec ce problème, deux pods clientconfig-operator sont en cours d'exécution, l'un en attente.

Ce problème s'applique uniquement aux clusters Anthos sur bare metal version 1.14.2. Les versions antérieures, telles que 1.14.0 et 1.14.1, ne sont pas concernées. Ce problème est résolu dans la version 1.14.3 et toutes les versions ultérieures, y compris la version 1.15.0 et ultérieures.

Solution :

Pour contourner ce problème, vous pouvez appliquer un correctif au déploiement clientconfig-operator afin d'ajouter un contexte de sécurité supplémentaire et vous assurer que le déploiement est prêt.

Utilisez la commande suivante pour appliquer un correctif à clientconfig-operator dans le cluster cible:

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Remplacez les éléments suivants :

CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster cible.

Opération

1.11, 1.12, 1.13, 1.14 et 1.15

Échec de la rotation de l'autorité de certification pour les clusters sans équilibrage de charge groupé

Pour les clusters sans équilibrage de charge groupé (spec.loadBalancer.mode défini sur manual), la commande bmctl update credentials certificate-authorities rotate peut ne plus répondre et échouer avec l'erreur suivante: x509: certificate signed by unknown authority.

Si vous êtes affecté par ce problème, la commande bmctl peut générer le message suivant avant de ne plus répondre:

Signing CA completed in 3/0 control-plane nodes

Dans ce cas, la commande échoue. Le journal de rotation des autorités de certification pour un cluster avec trois plans de contrôle peut inclure des entrées telles que:

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Solution

Si vous avez besoin d'aide, contactez l'assistance Google.

Installation, mise en réseau

1.11, 1.12, 1.13, 1.14.0 à 1.14.1

`ipam-controller-manager` parcours dans les clusters à double pile

Lorsque vous déployez un cluster double pile (cluster avec des adresses IPv4 et IPv6), le ou les pods ipam-controller-manager peuvent planter. Ce comportement entraîne le basculement des nœuds entre les états Ready et NotReady, et peut entraîner l'échec de l'installation du cluster. Ce problème peut se produire lorsque le serveur d'API est soumis à une charge élevée.

Pour voir si ce problème vous concerne, vérifiez si le ou les pods ipam-controller-manager présentent des erreurs CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

L'exemple de résultat suivant affiche les pods à l'état CrashLoopBackOff:


ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Obtenez les détails du nœud à l'état NotReady:

kubectl describe node <node-name> | grep PodCIDRs

Dans un cluster présentant ce problème, aucun pod n'est attribué à un nœud, comme illustré dans l'exemple de résultat suivant:


PodCIDRs:

Dans un cluster opérationnel, tous les nœuds doivent disposer de pods à double pile, comme illustré dans l'exemple de résultat suivant:


PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Solution :

Redémarrez le ou les pods ipam-controller-manager :

kubectl -n kube-system rollout restart ds ipam-controller-manager

Opération

1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 et 1.14

etcd

Les clusters exécutant la version 3.4.13 ou antérieure d' etcd peuvent rencontrer des problèmes de surveillance des ressources et de surveillance des ressources non opérationnelles, ce qui peut entraîner les problèmes suivants:

La planification des pods est interrompue
Impossible d'enregistrer les nœuds
Kubelet n'observe pas les modifications du pod

Ces problèmes peuvent rendre le cluster non fonctionnel.

Ce problème a été résolu dans les versions 1.12.9, 1.13.6 et 1.14.3 des clusters Anthos sur bare metal et dans les versions ultérieures. Ces versions plus récentes utilisent la version 3.4.21 d'Etd. Toutes les versions précédentes des clusters Anthos sur bare metal sont affectées par ce problème.

Solution

Si vous ne pouvez pas procéder à une mise à niveau immédiate, vous pouvez réduire le risque de défaillance du cluster en réduisant le nombre de nœuds qu'il contient. Supprimez les nœuds jusqu'à ce que la métrique etcd_network_client_grpc_sent_bytes_total soit inférieure à 300 Mbit/s.

Pour afficher cette métrique dans l'Explorateur de métriques:

Accédez à l'Explorateur de métriques dans la console Google Cloud:
Accéder à l'explorateur de métriques
Accédez à l'onglet Configuration.
Développez Sélectionner une métrique, saisissez Kubernetes Container dans la barre de filtre, puis utilisez les sous-menus pour sélectionner la métrique :
1. Dans le menu Ressources actives, sélectionnez Conteneur Kubernetes.
2. Dans le menu Catégories de métriques actives, sélectionnez Anthos.
3. Dans le menu Métriques actives, sélectionnez etcd_network_client_grpc_sent_bytes_total.
4. Cliquez sur Appliquer.

Mise en réseau

1.11.6 et 1.12.3

État "Échec " de l'opérateur `vfio-pci` du mode SR-IOV

Le syncStatus de l'objet SriovNetworkNodeState peut signaler la valeur "Failed" pour un nœud configuré. Pour afficher l'état d'un nœud et déterminer si le problème vous concerne, exécutez la commande suivante:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Remplacez NODE_NAME par le nom du nœud à vérifier.

Solution :

Si l'état de l'objet SriovNetworkNodeState est "Failed", passez aux clusters Anthos sur bare metal version 1.11.7 ou ultérieure ou 1.12.4 ou ultérieure.

Mises à niveau et mises à jour

1.10, 1.11, 1.12, 1.13, 1.14.0 et 1.14.1

Certains nœuds de calcul ne sont pas prêts pour la mise à niveau

Une fois la mise à niveau terminée, la condition Prêt de certains nœuds de calcul peut être définie sur false. Sur la ressource du nœud, une erreur s'affiche à côté de la condition Prêt, comme dans l'exemple suivant:


container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Lorsque vous vous connectez à une machine à l'arrêt, la configuration CNI de la machine est vide:

sudo ls /etc/cni/net.d/

Solution

Redémarrez le pod anetd du nœud en le supprimant.

Mises à niveau et mises à jour, sécurité

1.10

La rotation de plusieurs certificats à partir de cert-manager entraîne des incohérences

Après plusieurs rotations de certificats manuelles ou automatiques, le pod de webhook, tel que anthos-cluster-operator, n'est pas mis à jour avec les nouveaux certificats émis par cert-manager. Toute mise à jour de la ressource personnalisée du cluster échoue et génère une erreur semblable à celle-ci:


Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Ce problème peut se produire dans les cas suivants:

Vous avez effectué deux rotations de certificats manuelles effectuées par cert-manager sur un cluster de plus de 180 jours et n'avez jamais redémarré l'opérateur anthos-cluster-operator.
Si vous avez effectué une rotation manuelle des certificats cert-manager sur un cluster datant de plus de 90 jours ou plus et que vous n'avez jamais redémarré l'opérateur anthos-cluster-operator.

Solution

Redémarrez le pod en arrêtant anthos-cluster-operator.

Mises à niveau et mises à jour

1.14.0

Pods obsolètes de déployeurs de contrôleurs de cycle de vie créés lors de la mise à niveau du cluster d'utilisateur

Dans les clusters d'administrateur version 1.14.0, un ou plusieurs pods de déployeurs de contrôleurs de cycle de vie obsolètes peuvent être créés lors des mises à niveau des clusters d'utilisateur. Ce problème s'applique aux clusters d'utilisateur initialement créés dans des versions antérieures à la version 1.12. Les pods créés par inadvertance n'empêchent pas les opérations de mise à niveau, mais ils peuvent se trouver dans un état anormal. Nous vous recommandons de supprimer les pods obsolètes.

Ce problème a été résolu dans la version 1.14.1.

Solution :

Pour supprimer les pods déployeurs de contrôleurs de cycle de vie obsolètes:

Répertoriez les ressources de vérification préliminaire:

kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A

Le résultat ressemble à ceci :

NAMESPACE                    NAME                      PASS   AGE
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d

où ci-87a021b9dcbb31c est le nom du cluster.

Supprimez les ressources dont la valeur dans la colonne PASS est true ou false.

Par exemple, pour supprimer les ressources de l'exemple de résultat précédent, utilisez les commandes suivantes:

kubectl delete preflightchecks ci-87a021b9dcbb31c \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG 
kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
    -n cluster-ci-87a021b9dcbb31c \
    --kubeconfig ADMIN_KUBECONFIG

Mise en réseau

1.9, 1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

L'état de `BGPSession` change constamment en raison d'un grand nombre de routes entrantes

La mise en réseau avancée des clusters Anthos sur bare metal ne parvient pas à gérer correctement les sessions BGP lorsque des pairs externes annoncent un grand nombre de routes (environ 100 ou plus). Avec un grand nombre de routes entrantes, le contrôleur BGP local des nœuds prend trop de temps pour rapprocher les sessions BGP et ne parvient pas à mettre à jour l'état. En l'absence de mises à jour d'état ou de vérification de l'état, la session est supprimée pour cause d'obsolescence.

Voici quelques exemples de comportements indésirables sur les sessions BGP que vous pourriez remarquer et indiquer:

Suppression et recréation d'bgpsession en continu.
bgpsession.status.state ne devient jamais Established.
Routes ne diffusant pas d'annonces, ou dont la publicité et le retrait sont répétés.

Les problèmes d'équilibrage de charge BGP peuvent survenir en raison de problèmes de connectivité aux services LoadBalancer.

Le problème BGP de FlatIP peut être perceptible avec des problèmes de connectivité aux pods.

Pour déterminer si les problèmes BGP sont causés par les pairs distants qui annoncent trop de routes, utilisez les commandes suivantes pour examiner les états et le résultat associés:

Utilisez kubectl get bgpsessions sur le cluster concerné. La sortie affiche bgpsessions avec l'état "Non établi" et la dernière heure du rapport compte jusqu'à environ 10 à 12 secondes avant qu'il ne soit remis à zéro.

La sortie de kubectl get bgpsessions indique que les sessions concernées sont recréées à plusieurs reprises:

kubectl get bgpsessions \
    -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"

Les messages de journal indiquent que des sessions BGP obsolètes sont en cours de suppression:
```
kubectl logs ang-controller-manager-POD_NUMBER
```
Remplacez POD_NUMBER par le pod leader de votre cluster.

Solution :

Réduisez ou supprimez le nombre de routes annoncées par le pair distant vers le cluster avec une règle d'exportation.

Dans les clusters Anthos sur bare metal version 1.14.2 ou ultérieure, vous pouvez également désactiver la fonctionnalité qui traite les routes reçues à l'aide d'un AddOnConfiguration. Ajoutez l'argument --disable-received-routes au conteneur bgpd du daemonset ang-daemon.

Mise en réseau

1,14 et 1,15

Délais d'expiration de l'application causés par les échecs d'insertion de la table conntrack

Les clusters exécutés sur un système d'exploitation Ubuntu exécutant le noyau 5.15 ou une version ultérieure sont susceptibles d'échouer lors de l'insertion d'une table netfilter. Des échecs d'insertion peuvent se produire même lorsque la table "conntrack" peut accueillir de nouvelles entrées. Les échecs sont dus à des modifications apportées à partir de la version 5.15 du noyau, qui restreignent l'insertion de la table en fonction de la longueur de la chaîne.

Pour savoir si vous êtes concerné par ce problème, vous pouvez consulter les statistiques système du système de suivi des connexions du noyau à l'aide de la commande suivante:

sudo conntrack -S

La réponse est semblable à ce qui suit :

cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

Si une valeur chaintoolong dans la réponse est un nombre différent de zéro, vous êtes concerné par ce problème.

Solution

L'atténuation à court terme consiste à augmenter la taille de la table de hachage netfiler (nf_conntrack_buckets) et de la table de suivi de connexion netfilter (nf_conntrack_max). Utilisez les commandes suivantes sur chaque nœud du cluster pour augmenter la taille des tables:

sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE

sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

Remplacez TABLE_SIZE par une nouvelle taille en octets. La valeur de la taille de la table par défaut est 262144. Nous vous suggérons de définir une valeur égale à 65 536 fois le nombre de cœurs sur le nœud. Par exemple, si votre nœud comporte huit cœurs, définissez la taille de la table sur 524288.

Mises à niveau et mises à jour

1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.11.7

Impossible de restaurer les sauvegardes du cluster avec `bmctl` pour certaines versions

Nous vous recommandons de sauvegarder vos clusters avant la mise à niveau afin de pouvoir restaurer la version précédente en cas d'échec. Un problème avec la commande bmctl restore cluster entraîne l'échec de la restauration des sauvegardes de clusters avec les versions identifiées. Ce problème est spécifique aux mises à niveau, où vous restaurez une sauvegarde d'une version antérieure.

Si votre cluster est affecté, le journal bmctl restore cluster contient l'erreur suivante:


Error: failed to extract image paths from profile: anthos version VERSION not supported

Solution :

En attendant que ce problème soit résolu, nous vous recommandons de suivre les instructions de la section Sauvegarder et restaurer des clusters pour sauvegarder vos clusters manuellement et les restaurer si nécessaire.

Mise en réseau

1.10, 1.11, 1.12, 1.13 et 1.14.0-1.14.2

`NetworkGatewayGroup` plante si aucune adresse IP ne s'affiche sur l'interface

NetworkGatewayGroup ne crée pas de daemons pour les nœuds qui ne comportent pas à la fois des interfaces IPv4 et IPv6. Cela entraîne l'échec de fonctionnalités telles que BGP LB et EgressNAT. Si vous vérifiez les journaux du pod ang-node défaillant dans l'espace de noms kube-system, des erreurs semblables à l'exemple suivant s'affichent lorsqu'il manque une adresse IPv6:


ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

Dans l'exemple précédent, il n'existe pas d'adresse IPv6 sur l'interface ens192. Des erreurs ARP similaires s'affichent si aucune adresse IPv4 n'est associée au nœud.

NetworkGatewayGroup tente d'établir une connexion ARP et une connexion NDP à l'adresse IP locale de la liaison. Si l'adresse IP n'existe pas (IPv4 pour ARP, IPv6 pour NDP), la connexion échoue et le daemon ne se poursuit pas.

Ce problème a été résolu dans la version 1.14.3.

Solution :

Connectez-vous au nœud à l'aide de SSH et ajoutez une adresse IPv4 ou IPv6 au lien contenant l'adresse IP du nœud. Dans l'exemple d'entrée de journal précédent, cette interface était ens192:

ip address add dev INTERFACE scope link ADDRESS

Remplacez les éléments suivants :

INTERFACE: interface de votre nœud, par exemple ens192.
ADDRESS: adresse IP et masque de sous-réseau à appliquer à l'interface.

Réinitialisation/Suppression

1.10, 1.11, 1.12, 1.13.0 à 1.13.2

`anthos-cluster-operator` boucle de plantage lors de la suppression d'un nœud de plan de contrôle

Lorsque vous essayez de supprimer un nœud de plan de contrôle en supprimant l'adresse IP de Cluster.Spec, anthos-cluster-operator entre dans une boucle de plantage qui bloque toutes les autres opérations.

Solution :

Problème résolu dans les versions 1.13.3 et 1.14.0 et ultérieures. Toutes les autres versions sont affectées. Mettre à niveau vers l'une des versions corrigées

Pour contourner ce problème, exécutez la commande suivante:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Remplacez les éléments suivants :

IP_ADDRESS: adresse IP du nœud dans une boucle de plantage.
CLUSTER_NAMESPACE: espace de noms du cluster.

Installation

1.13.1, 1.13.2 et 1.13.3

`kubeadm join` échoue dans les clusters volumineux en raison d'une non-concordance des jetons

Lorsque vous installez des clusters Anthos sur bare metal avec un grand nombre de nœuds, un message d'erreur kubeadmin join peut s'afficher:


TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Solution :

Ce problème est résolu dans les clusters Anthos sur bare metal version 1.13.4 et ultérieure.

Si vous devez utiliser une version affectée, commencez par créer un cluster avec moins de 20 nœuds, puis redimensionnez le cluster pour ajouter des nœuds supplémentaires après l'installation.

Journalisation et surveillance

1.10, 1.11, 1.12 et 1.13.0

Limite de processeur faible pour `metrics-server` dans les clusters périphériques

Dans les clusters Anthos sur des clusters Edge Bare Metal, des limites de processeur faibles pour metrics-server peuvent entraîner des redémarrages fréquents de metrics-server. L'autoscaling horizontal des pods ne fonctionne pas, car metrics-server est non opérationnel.

Si la limite de processeur metrics-server est inférieure à 40m, vos clusters peuvent être affectés. Pour vérifier les limites de processeur metrics-server, examinez l'un des fichiers suivants:

Clusters Anthos sur bare metal version 1.x-1.12:

kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml

Clusters Anthos sur bare metal version 1.13 ou ultérieure:

kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Solution :

Ce problème est résolu dans les clusters Anthos sur bare metal version 1.13.1 ou ultérieure. Pour résoudre ce problème, mettez à niveau vos clusters.

Une solution de contournement à court terme jusqu'à ce que vous puissiez mettre à niveau les clusters consiste à augmenter manuellement les limites de processeur pour metrics-server:

Réduisez la capacité de metrics-server-operator :

kubectl scale deploy metrics-server-operator --replicas=0

Mettez à jour la configuration et augmentez les limites de processeur :

Clusters Anthos sur bare metal version 1.x-1.12:

kubectl -n kube-system edit deployment metrics-server

Clusters Anthos sur bare metal version 1.13:

kubectl -n gke-managed-metrics-server edit deployment metrics-server

Supprimez la ligne --config-dir=/etc/config et augmentez les limites de processeur, comme indiqué dans l'exemple suivant:


[...]
- command:
  - /pod_nanny
  # - --config-dir=/etc/config # <--- # Remove this line - --container=metrics-server - --cpu=50m><--- CPU,
[...] Increase such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true>

Enregistrez et fermez metrics-server pour appliquer les modifications.

Mise en réseau

1,14 et 1,15

La connexion directe NodePort au pod hostNetwork ne fonctionne pas

La connexion à un pod activé avec hostNetwork via le service NodePort échoue lorsque le pod de backend se trouve sur le même nœud que le NodePort ciblé. Ce problème affecte les services LoadBalancer lorsqu'il est utilisé avec des pods hostNetwork-ed. Avec plusieurs backends, il peut y avoir une défaillance sporadique de la connexion.

Ce problème est dû à un bug du programme eBPF.

Solution :

Lorsque vous utilisez un service Nodeport, ne ciblez pas le nœud sur lequel le pod de backend s'exécute. Lorsque vous utilisez le service LoadBalancer, assurez-vous que les pods hébergés par hostNetwork ne s'exécutent pas sur les nœuds LoadBalancer.

Mises à niveau et mises à jour

1.12.3 et 1.13.0

Les clusters d'administrateur 1.13.0 ne peuvent pas gérer 1.12.3 cluster(s) d'utilisateur

Les clusters d'administrateur exécutant la version 1.13.0 ne peuvent pas gérer les clusters d'utilisateur exécutant la version 1.12.3. Les opérations sur un cluster d'utilisateur version 1.12.3 échouent.

Solution :

Mettez à niveau votre cluster d'administrateur vers la version 1.13.1 ou mettez à niveau le cluster d'utilisateur vers la même version que le cluster d'administrateur.

Mises à niveau et mises à jour

1.12

La mise à niveau vers la version 1.13.x est bloquée pour les clusters d'administrateur comportant des pools de nœuds de calcul

Les clusters d'administrateur version 1.13.0 et supérieures ne peuvent pas contenir de pools de nœuds de calcul. Les mises à niveau vers la version 1.13.0 ou une version ultérieure pour les clusters d'administrateur comportant des pools de nœuds de calcul sont bloquées. Si la mise à niveau du cluster d'administrateur est bloquée, vous pouvez vérifier si les pools de nœuds de calcul en sont la cause en vérifiant l'erreur suivante dans le fichier upgrade-cluster.log du dossier bmctl-workspace:


Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Solution :

Avant de procéder à la mise à niveau, déplacez tous les pools de nœuds de calcul vers des clusters d'utilisateur. Pour savoir comment ajouter et supprimer des pools de nœuds, consultez Gérer les pools de nœuds dans un cluster.

Mises à niveau et mises à jour

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Erreurs lors de la mise à jour des ressources avec `kubectl apply`

Si vous mettez à jour des ressources existantes telles que les ressources personnalisées ClientConfig ou Stackdriver à l'aide de kubectl apply, le contrôleur peut renvoyer une erreur ou annuler votre entrée et les modifications souhaitées.

Par exemple, vous pouvez essayer de modifier la ressource personnalisée Stackdriver comme suit : commencez par l'obtenir, puis appliquez une version mise à jour :

Obtenez la définition YAML existante:

kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml

Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML.
Appliquez à nouveau le fichier YAML mis à jour:
```
kubectl apply -f stackdriver.yaml
```

La dernière étape pour kubectl apply est l'étape à laquelle vous pouvez rencontrer des problèmes.

Solution :

N'utilisez pas kubectl apply pour modifier les ressources existantes. Utilisez plutôt kubectl edit ou kubectl patch, comme illustré dans les exemples suivants:

Modifiez la ressource personnalisée Stackdriver :

kubectl edit stackdriver -n kube-system stackdriver

Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML.
Enregistrer et quitter l'éditeur

Approche alternative avec kubectl patch:

Obtenez la définition YAML existante:

kubectl get stackdriver -n kube-system stackdriver \
    -o yaml > stackdriver.yaml

Activez des fonctionnalités ou mettez à jour la configuration dans le fichier YAML.

Appliquez à nouveau le fichier YAML mis à jour:

kubectl patch stackdriver stackdriver --type merge \
    -n kube-system --patch-file stackdriver.yaml

Journalisation et surveillance

1.12, 1.13, 1.14, 1.15

Des fragments de tâches en attente corrompus génèrent `stackdriver-log-forwarder` boucle de plantage

Le plantage de stackdriver-log-forwarder se produit s'il tente de traiter un fragment de tâches en attente corrompu. Les exemples d'erreurs suivants sont affichés dans les journaux du conteneur:


[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Lorsque cette boucle de plantage se produit, les journaux ne s'affichent pas dans Cloud Logging.

Solution :

Pour résoudre ces erreurs, procédez comme suit:

Identifiez les fragments de tâches en attente corrompus. Consultez les exemples de messages d'erreur suivants:
```
[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
```
Dans cet exemple, le fichier tail.1/1-1659339894.252926599.flb stocké dans var/log/fluent-bit-buffers/tail.1/ est responsable. Chaque fichier *.flb dont la vérification du format a échoué doit être supprimé.
Mettez fin aux pods en cours d'exécution pour stackdriver-log-forwarder:
```
kubectl --kubeconfig KUBECONFIG -n kube-system \
    patch daemonset stackdriver-log-forwarder \
    -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
```
Remplacez KUBECONFIG par le chemin d'accès à votre fichier kubeconfig du cluster d'utilisateur.

Vérifiez que les pods stackdriver-log-forwarder sont supprimés avant de passer à l'étape suivante.
Connectez-vous au nœud à l'aide de SSH, où stackdriver-log-forwarder est en cours d'exécution.

Sur le nœud, supprimez tous les fichiers *.flb corrompus dans var/log/fluent-bit-buffers/tail.1/.

Si le nombre de fichiers corrompus est trop élevé et que vous souhaitez appliquer un script pour nettoyer tous les segments en attente, utilisez les scripts suivants :

Déployez un DaemonSet pour nettoyer toutes les données modifiées dans des tampons dans 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 deux commandes suivantes doit être égal au nombre de nœuds du 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

Redémarrez les pods stackdriver-log-forwarder:

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

Mise en réseau, environnement d'exécution des VM Anthos

1.14.0

Si vous redémarrez Dataplane V2 (`anetd`) sur des clusters, les VM existantes ne pourront pas être associées à des réseaux autres que des pods

Sur les clusters dotés de plusieurs cartes réseau, le redémarrage de Dataplane V2 (anetd) peut empêcher les machines virtuelles de s'associer aux réseaux. Une erreur semblable à la suivante peut être observée dans les journaux du pod anetd:


could not find an allocator to allocate the IP of the multi-nic endpoint

Solution :

Pour résoudre ce problème, vous pouvez redémarrer la VM. Pour éviter que le problème survienne à nouveau, passez aux clusters Anthos sur bare metal 1.14.1 ou version ultérieure.

Opération

1.13, 1.14.0 et 1.14.1

`gke-metrics-agent` n'a pas de limite de mémoire sur les clusters de profils périphériques

Selon la charge de travail du cluster, gke-metrics-agent peut utiliser plus de 4 608 Mio de mémoire. Ce problème ne concerne que les clusters Anthos sur des clusters de profil Edge Bare Metal. Les clusters de profils par défaut ne sont pas affectés.

Solution :

Mettez à niveau votre cluster vers la version 1.14.2 ou une version ultérieure.

Installation

1,12 et 1,13

La création du cluster peut échouer en raison des conditions de concurrence

Lorsque vous créez des clusters à l'aide de kubectl, il est possible que les vérifications préliminaires ne soient jamais terminées en raison des conditions de concurrence. Par conséquent, la création de cluster peut échouer dans certains cas.

Le rapprochement de la vérification préliminaire crée un SecretForwarder pour copier le secret ssh-key par défaut dans l'espace de noms cible. En règle générale, la vérification préliminaire s'appuie sur les références propriétaire et les rapprochements une fois la SecretForwarder terminée. Toutefois, dans de rares cas, les références du propriétaire de SecretForwarder peuvent perdre la référence à la vérification préliminaire, ce qui la bloque. Par conséquent, la création du cluster échoue. Pour continuer le rapprochement de la vérification préliminaire préliminaire basée sur le contrôleur, supprimez le pod de l'opérateur de cluster ou la ressource de vérification préalable. Lorsque vous supprimez la ressource de vérification préliminaire, elle en crée une autre et poursuit le rapprochement. Vous pouvez également mettre à niveau vos clusters existants (créés avec une version antérieure) vers une version corrigée.

Mise en réseau

1.9, 1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Les adresses IP réservées ne sont pas libérées lors de l'utilisation du plug-in WHEREwhere avec la fonctionnalité avec plusieurs cartes d'interface réseau

Dans la fonctionnalité multi-nic, si vous utilisez le plug-in de destination CNI et que vous utilisez l'opération CNI DEL pour supprimer une interface réseau pour un pod, certaines adresses IP réservées risquent de ne pas être libérées correctement. Cela se produit lorsque l'opération CNI DEL est interrompue.

Vous pouvez vérifier les réservations d'adresses IP inutilisées des pods en exécutant la commande suivante:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Solution :

Supprimez manuellement les adresses IP (ippools) qui ne sont pas utilisées.

Installation

1.10, 1.11.0, 1.11.1 et 1.11.2

Échec du détecteur de problèmes de nœuds dans le cluster d'utilisateur 1.10.4

Le détecteur de problèmes de nœuds peut échouer dans les clusters d'utilisateur Anthos Bare Metal 1.10.x, lorsque les clusters d'administrateur Anthos Bare Metal 1.11.0, 1.11.1 ou 1.11.2 gèrent des clusters d'utilisateur 1.10.x. En cas de défaillance du détecteur de problèmes de nœuds, le journal est mis à jour avec le message d'erreur suivant:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Solution

Mettez à niveau le cluster d'administrateur vers la version 1.11.3 pour résoudre le problème.

Opération

1.14

1.14 Les nœuds de cluster IPv4 en mode île ont un masque CIDR de pod de 24

Dans la version 1.14, le paramètre maxPodsPerNode n'est pas pris en compte pour les clusters en mode insulaire. Par conséquent, les nœuds se voient attribuer une taille de masque CIDR de 24 (256 adresses IP). Le cluster risque alors de manquer d'adresses IP de pod plus que prévu. Par exemple, si le cluster a une taille de masque CIDR de 22 pods, un masque CIDR de pod de 24 sera attribué à chaque nœud, et le cluster ne pourra gérer que 4 nœuds au maximum. Votre cluster peut également subir une instabilité du réseau pendant une période de perte de pods élevée lorsque maxPodsPerNode est défini sur 129 ou plus et lorsque la surcharge du CIDR des pods est insuffisante pour chaque nœud.

Ce problème n'affecte que les clusters IPv4 en mode île qui utilisent maxPodsPerNode en dehors de la plage de 65 à 128.

Si votre cluster est affecté, le pod anetd signale l'erreur suivante lorsque vous ajoutez un nœud au cluster et qu'aucun podCIDR n'est disponible:

error="required IPv4 PodCIDR not available"

Solution

Pour résoudre le problème, procédez comme suit:

Passez à la version 1.14.1 ou à une version ultérieure.
Supprimez les nœuds de calcul et ajoutez-les à nouveau.
Supprimez les nœuds du plan de contrôle, puis ajoutez-les de préférence, un par un, afin d'éviter les temps d'arrêt du cluster.

Mises à niveau et mises à jour

1.14.0 et 1.14.1

Échec du rollback de la mise à niveau du cluster

Un rollback de mise à niveau peut échouer pour les clusters Anthos sur bare metal 1.14.0 vers la version 1.14.1. Si vous mettez à niveau un cluster de la version 1.14.0 vers la version 1.14.1, puis essayez de effectuer un rollback vers la version 1.14.0 à l'aide de la commande bmctl restore cluster, une erreur semblable à l'exemple suivant peut s'afficher:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Solution :

Supprimez toutes les ressources healthchecks.baremetal.cluster.gke.io sous l'espace de noms du cluster, puis réexécutez la commande bmctl restore cluster:

Répertoriez toutes les ressources healthchecks.baremetal.cluster.gke.io:
```
kubectl get healthchecks.baremetal.cluster.gke.io \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAMESPACE: espace de noms du cluster.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Supprimez toutes les ressources healthchecks.baremetal.cluster.gke.io répertoriées à l'étape précédente:
```
kubectl delete healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_RESOURCE_NAME \
    --namespace=CLUSTER_NAMESPACE \
    --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez HEALTHCHECK_RESOURCE_NAME par le nom des ressources de vérification d'état.
Exécutez à nouveau la commande bmctl restore cluster.

Mise en réseau

1.12.0

L'adresse IP externe du service ne fonctionne pas en mode plat

Dans un cluster pour lequel flatIPv4 est défini sur true, les services de type LoadBalancer ne sont pas accessibles par leurs adresses IP externes.

Ce problème a été résolu dans la version 1.12.1.

Solution :

Dans le ConfigMap cilium-config, définissez enable-415 sur "true", puis redémarrez les pods anetd.

Mises à niveau et mises à jour

1.13.0 et 1.14

Les mises à niveau sur place de la version 1.13.0 vers la version 1.14.x ne s'arrêtent jamais

Lorsque vous essayez d'effectuer une mise à niveau sur place de la version 1.13.0 vers la version 1.14.x à l'aide de bmctl 1.14.0 et de l'indicateur --use-bootstrap=false, la mise à niveau ne se termine jamais.

Une erreur liée à l'opérateur preflight-check empêche le cluster de planifier les vérifications requises, ce qui signifie que la vérification préliminaire ne se termine jamais.

Solution :

Effectuez la mise à niveau vers la version 1.13.1 avant de passer à la version 1.14.x. Une mise à niveau sur place de la version 1.13.0 vers la version 1.13.1 devrait fonctionner. Vous pouvez également passer de la version 1.13.0 à la version 1.14.x sans l'indicateur --use-bootstrap=false.

Mises à niveau et mises à jour, sécurité

1,13 et 1,14

Les clusters mis à niveau vers la version 1.14.0 perdent des rejets maîtres.

Les nœuds du plan de contrôle nécessitent l'un des deux rejets spécifiques pour empêcher la planification des pods de charge de travail sur ces nœuds. Lorsque vous mettez à niveau des clusters Anthos version 1.13 vers la version 1.14.0, les nœuds de plan de contrôle perdent les rejets requis suivants:

node-role.kubernetes.io/master:NoSchedule
node-role.kubernetes.io/master:PreferNoSchedule

Remarque:Les clusters autogérés, tels qu'un cluster de type autonome, utilisent le rejet PreferNoSchedule par défaut.

Ce problème n'entraîne pas d'échec de la mise à niveau, mais les pods qui ne sont pas censés s'exécuter sur les nœuds du plan de contrôle peuvent commencer à le faire. Ces pods de charge de travail peuvent surcharger les nœuds du plan de contrôle et entraîner une instabilité de cluster.

Déterminer si vous êtes concerné

Recherchez les nœuds du plan de contrôle à l'aide de la commande suivante:

kubectl get node -l 'node-role.kubernetes.io/control-plane' \
    -o name --kubeconfig KUBECONFIG_PATH

Pour vérifier la liste des rejets sur un nœud, utilisez la commande suivante:
```
kubectl describe node NODE_NAME \
    --kubeconfig KUBECONFIG_PATH
```
Si aucun des rejets requis ne s'affiche, cela signifie que vous êtes concerné.

Solution

Procédez comme suit pour chaque nœud de plan de contrôle du cluster de version 1.14.0 concerné afin de restaurer la fonction appropriée. Ces étapes concernent le rejet node-role.kubernetes.io/master:NoSchedule et les pods associés. Si vous souhaitez que les nœuds du plan de contrôle utilisent le rejet PreferNoSchedule, ajustez les étapes en conséquence.

Afficher la procédure de contournement

Appliquez le rejet manquant:

kubectl taint nodes NODE_NAME \
    node-role.kubernetes.io/master:NoSchedule \
    -–kubeconfig KUBECONFIG_PATH

Recherchez les pods sans tolérance node-role.kubernetes.io/master:NoSchedule:

kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \
    -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \
    --kubeconfig KUBECONFIG_PATH | \
    grep -v  "node-role.kubernetes.io/master" | uniq

Supprimez les pods qui n'ont pas la tolérance node-role.kubernetes.io/master:NoSchedule:
```
kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
```

Opération, environnement d'exécution des VM Anthos

1.11, 1.12, 1.13, 1.14 et 1.15

Échec de la création intermittente de la VM avec des erreurs d'importation

La création d'une machine virtuelle (VM) avec la commande kubectl virt create vm échoue rarement lors de l'importation de l'image. Ce problème s'applique à la fois aux VM Linux et Windows. L'erreur se présente comme suit:

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Solution

Réessayez la commande kubectl virt create vm pour créer votre VM.

Mises à niveau et mises à jour, journalisation et surveillance

1.11

Les composants de collections gérées dans les clusters 1.11 ne sont pas conservés dans les mises à niveau vers la version 1.12.

Les composants de collection gérée font partie de Managed Service pour Prometheus. Si vous avez déployé manuellement des composants de collection gérée dans l'espace de noms gmp-system de vos clusters Anthos 1.11, les ressources associées ne sont pas conservées lorsque vous passez à la version 1.12.

À partir de la version 1.12.0 des clusters Anthos sur bare metal, les composants de service géré pour Prometheus dans l'espace de noms gmp-system et les définitions de ressources personnalisées associées sont gérés par stackdriver-operator avec le champ enableGMPForApplications. Le champ enableGMPForApplications est défini par défaut sur true. Par conséquent, si vous déployez manuellement les composants Managed Service pour Prometheus dans l'espace de noms avant la mise à niveau vers la version 1.12, les ressources sont supprimées par stackdriver-operator.

Solution

Pour conserver des ressources de collection gérées manuellement:

Sauvegardez toutes les ressources personnalisées de PodMonitoring.
Mettez à niveau le cluster vers la version 1.12 et activez Managed Service pour Prometheus.
Redéployez les ressources personnalisées de PodMonitoring sur votre cluster mis à niveau.

Mises à niveau et mises à jour

1.13

Certains clusters version 1.12 avec l'environnement d'exécution de conteneurs Docker ne peuvent pas être mis à niveau vers la version 1.13

Si un cluster version 1.12 qui utilise l'environnement d'exécution de conteneurs Docker ne comporte pas l'annotation suivante, il ne peut pas être mis à niveau vers la version 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Si vous êtes affecté par ce problème, bmctl écrit l'erreur suivante dans le fichier upgrade-cluster.log du dossier bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

Cela peut se produire avec les clusters Docker version 1.12 qui ont été mis à niveau à partir de la version 1.11, car cette mise à niveau ne nécessite pas l'annotation pour maintenir l'environnement d'exécution du conteneur Docker. Dans ce cas, les clusters ne comportent pas l'annotation lorsqu'ils passent à la version 1.13. Notez qu'à partir de la version 1.13, containerd est le seul environnement d'exécution de conteneur autorisé.

Solution :

Si vous êtes affecté par ce problème, mettez à jour la ressource du cluster avec l'annotation manquante. Vous pouvez ajouter l'annotation pendant la mise à niveau ou après l'annulation et avant de la relancer.

Installation

1.11

`bmctl` se ferme avant la fin de la création du cluster

La création de clusters peut échouer pour les clusters Anthos sur bare metal version 1.11.0 (ce problème est résolu dans la version 1.11.1 des clusters Anthos sur bare metal). Dans certains cas, la commande bmctl create cluster se ferme de façon anticipée et écrit des erreurs comme celles-ci dans les journaux:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Solution

L'opération ayant échoué génère des artefacts, mais le cluster n'est pas opérationnel. Si ce problème vous concerne, procédez comme suit pour nettoyer les artefacts et créer un cluster:

Afficher la procédure de contournement

Pour supprimer les artefacts du cluster et réinitialiser la machine de nœud, exécutez la commande suivante:
```
bmctl reset -c USER_CLUSTER_NAME
```
Pour lancer l'opération de création de cluster, exécutez la commande suivante :
```
bmctl create cluster -c USER_CLUSTER_NAME \
    --keep-bootstrap-cluster
```
L'option --keep-bootstrap-cluster est importante si cette commande échoue. Si la commande de création de cluster aboutit, vous pouvez ignorer les étapes restantes. Sinon, continuez.

Exécutez la commande suivante pour obtenir la version du cluster d'amorçage :

kubectl get cluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAMESPACE \
    --kubeconfig bmctl-workspace/.kindkubeconfig \
    -o=jsonpath='{.status.anthosBareMetalVersion}

Le résultat 1.11.0 doit s'afficher. Si le résultat n'est pas 1.11.0, attendez une ou deux minutes, puis réessayez.

Pour déplacer manuellement des ressources du cluster d'amorçage vers le cluster cible, exécutez la commande suivante:

bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \
    --to-kubeconfig \
    bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \
    -n USER_CLUSTER_NAMESPACE

Pour supprimer le cluster d'amorçage, exécutez la commande suivante :
```
bmctl reset bootstrap
```

Installation, environnement d'exécution des VM Anthos

1,11 et 1,12

Signalement de l'erreur de rapprochement de l'environnement d'exécution des VM

L'opération de création du cluster peut signaler une erreur semblable à celle-ci:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Solution

Cette erreur est bénigne et vous pouvez l'ignorer en toute sécurité.

Installation

1.10, 1.11, 1.12

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

La création du cluster échoue lorsque vous combinez les conditions suivantes:

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 de cluster, la version par défaut pour les clusters Anthos sur bare metal version 1.10).

Le cluster est configuré pour fournir plusieurs interfaces réseau, à 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 tentez de créer un cluster. Ce paramètre proxy peut s'afficher en tant que variable d'environnement HTTPS_PROXY ou dans votre configuration containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Solution

Ajoutez les CIDR des services (clusterNetwork.services.cidrBlocks) à la variable d'environnement NO_PROXY sur toutes les machines de nœud.

Installation

1.10, 1.11, 1.12

Échec sur les systèmes avec le paramètre `umask` restrictif

La version 1.10.0 des clusters Anthos sur bare metal a introduit une fonctionnalité de plan de contrôle sans racine qui exécute tous les composants du plan de contrôle en tant qu'utilisateur non racine. L'exécution de tous les composants en tant qu'utilisateur non racine peut entraîner des échecs d'installation ou de mise à niveau sur les systèmes avec un paramètre umask plus restrictif de 0077.

Solution

Réinitialisez les nœuds du plan de contrôle et définissez le paramètre umask sur 0022 sur toutes les machines du plan de contrôle. Relancez l'installation après la mise à jour des machines.

Vous pouvez également modifier les autorisations de répertoire et de fichier de /etc/kubernetes sur les machines de plan de contrôle pour l'installation ou la mise à niveau pour continuer.

/etc/kubernetes et tous ses sous-répertoires lisibles: chmod o+rx
Rendez tous les fichiers appartenant à l'utilisateur root dans le répertoire (de manière récursive) /etc/kubernetes lisibles dans le monde entier (chmod o+r). Excluez les fichiers de clé privée (.key) de ces modifications, car ils sont déjà créés avec les bonnes propriétés et autorisations.
Rendez /usr/local/etc/haproxy/haproxy.cfg utilisable dans le monde entier.
Rendez /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml utilisable dans le monde entier.

Installation

1.10, 1.11, 1.12 et 1.13

Incompatibilité du groupe de contrôle v2

Le groupe de contrôle v2 (cgroup v2) n'est pas compatible avec les clusters Anthos sur bare metal versions 1.13 et antérieures. Cependant, la version 1.14 est compatible avec cgroup v2 en tant que fonctionnalité Preview . La présence de /sys/fs/cgroup/cgroup.controllers indique que votre système utilise cgroup v2.

Solution

Si votre système utilise cgroup v2, passez à la version 1.14 des clusters Anthos sur bare metal.

Installation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

Pour les installations déclenchées par des clusters d'administrateur ou hybrides (en d'autres termes, des clusters non créés avec bmctl, comme des clusters d'utilisateur), la vérification préliminaire ne vérifie pas les identifiants du compte de service Google Cloud ni leurs autorisations associées.

Installation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

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

Solution

Pour que l'ADC fonctionne, vous devez soit diriger la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS vers un fichier d'identifiants de compte de service, soit exécuter gcloud auth application-default login.

Installation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Service Docker

Sur les machines de 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 échouera et indiquera Docker service is not active.

Solution

Supprimez Docker ou activez le service Docker.

Installation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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 indicateurs sont liés au déchargement de segmentation matérielle effectué par le pilote vSphere VMXNET3 et ne fonctionnent pas avec le tunnel GENEVE de clusters Anthos sur bare metal.

Solution

Exécutez la commande suivante sur chaque nœud pour vérifier les valeurs actuelles de ces indicateurs:

ethtool -k NET_INTFC | grep segm

Remplacez NET_INTFC par l'interface réseau associée à l'adresse IP du nœud.

La réponse doit comporter les entrées suivantes:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...

Dans RHEL 8.4, ethtool indique parfois que ces indicateurs sont désactivés. Pour les désactiver, 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 ces indicateurs de manière explicite au démarrage du système.

Mises à niveau et mises à jour

1.10

`bmctl` ne peut pas créer, mettre à jour ni réinitialiser des clusters d'utilisateur de version anté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 de 1.N.X pour réinitialiser un cluster d'utilisateur de la version 1.N-1.Y, même si le cluster d'administrateur se trouve également dans la version 1.N.X.

Si vous êtes affecté par ce problème, vous devriez voir des journaux semblables à ceux ci-dessous 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

Solution :

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.

Mises à niveau et mises à jour

1.12

La mise à niveau des clusters vers la version 1.12.1 peut être bloquée

La mise à niveau des clusters vers la version 1.12.1 s'interrompt parfois, car le serveur d'API devient indisponible. Ce problème affecte tous les types de clusters et tous les systèmes d'exploitation compatibles. Lorsque ce problème se produit, la commande bmctl upgrade cluster peut échouer à plusieurs moments, y compris au cours de la deuxième phase des vérifications préliminaires.

Solution

Vous pouvez consulter vos journaux de mise à niveau pour déterminer si vous êtes concerné par ce problème. Les journaux de mise à niveau sont situés dans /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP par défaut.

upgrade-cluster.log peut contenir des erreurs semblables à celles-ci:

Failed to upgrade cluster: preflight checks failed: preflight check failed

Le journal de la machine peut contenir les erreurs suivantes (les échecs répétés indiquent que vous êtes affecté par ce problème):

FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

GCS et Keepalife doivent être exécutés sur chaque nœud de plan de contrôle avant de réessayer de mettre à niveau votre cluster vers la version 1.12.1. Utilisez l' interface de ligne de commande crictl sur chaque nœud pour vérifier si les conteneurs haproxy et keepalived sont en cours d'exécution:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Si GAIA ou Keepalife ne s'exécute pas sur un nœud, redémarrez kubelet sur le nœud:

systemctl restart kubelet

Mises à niveau et mises à jour, environnement d'exécution des VM Anthos

1,11 et 1,12

La mise à niveau des clusters vers la version 1.12.0 ou une version ultérieure échoue lorsque l'environnement d'exécution des VM Anthos est activé

Dans la version 1.12.0 des clusters Anthos sur bare metal, toutes les ressources liées à l'environnement d'exécution des VM Anthos sont migrées vers l'espace de noms vm-system pour une meilleure compatibilité avec la version en disponibilité générale des VM d'Anthos. Si l'environnement d'exécution des VM Anthos est activé dans un cluster version 1.11.x ou antérieure, la mise à niveau vers la version 1.12.0 ou ultérieure échoue, sauf si vous désactivez d'abord l'environnement d'exécution des VM Anthos. Lorsque vous êtes concerné par ce problème, l'opération de mise à niveau signale l'erreur suivante:


Failed to upgrade cluster: cluster is not upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Solution

Pour désactiver l'environnement d'exécution de VM Anthos, procédez comme suit:

Modifiez la ressource personnalisée VMRuntime :
```
kubectl edit vmruntime
```

Définissez enabled sur false dans la spécification:

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: false
  ...

Enregistrez la ressource personnalisée dans votre éditeur.
Une fois la mise à niveau du cluster terminée, réactivez l'environnement d'exécution des VM Anthos.

Pour en savoir plus, consultez Utiliser des charges de travail basées sur des VM.

Mises à niveau et mises à jour

1.10, 1.11, 1.12

Migration bloquée à `error during manifests operations`

Dans certaines situations, les mises à niveau des clusters échouent et la CLI bmctl ne répond plus. Ce problème peut être dû à une ressource mal mise à jour. Pour déterminer si vous êtes concerné par ce problème et le corriger, consultez les journaux anthos-cluster-operator et recherchez les 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 le symptôme d'une ressource mal mise à jour, où {RESOURCE_NAME} est le nom de la ressource problématique.

Solution

Si vous constatez ces erreurs dans vos journaux, procédez comme suit:

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.

Mises à niveau et mises à jour

1.10, 1.11, 1.12

Les mises à niveau sont bloquées pour les clusters dotés de fonctionnalités qui utilisent la passerelle réseau Anthos

Les mises à niveau de la version 1.10.x vers la version 1.11.x échouent pour les clusters qui utilisent une passerelle NAT de sortie ou un équilibrage de charge groupé avec BGP. Ces fonctionnalités utilisent Anthos Network Gateway. Les mises à niveau des clusters sont bloquées au niveau du message de ligne de commande Waiting for upgrade to complete... et le anthos-cluster-operator consigne les erreurs suivantes:


apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Solution

Attention:La solution de contournement suivante supprime les fichiers manifestes et provoque un bref temps d'arrêt de 30 à 60 secondes pour l'équilibrage de charge groupé avec BGP. Les sessions BGP sont supprimées et rétablies, et les services LoadBalancer ne sont pas disponibles pendant cette période. La fonction est restaurée lorsque anthos-cluster-operator réinstalle les fichiers manifestes.

Pour débloquer la mise à niveau, exécutez les commandes suivantes sur le cluster que vous mettez à niveau:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node

Mises à niveau et mises à jour

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

`bmctl update` ne supprime pas les blocs de maintenance

La commande bmctl update ne peut pas supprimer ni modifier la section maintenanceBlocks de la configuration de la ressource de cluster.

Solution

Pour en savoir plus, y compris sur les instructions de suppression de nœuds du mode de maintenance, consultez la section Mettre des nœuds en mode de maintenance.

Mises à niveau et mises à jour

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Le drainage du 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 s'ils sont 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. Cela se produit rarement.

Solution

Pour minimiser la probabilité que vous rencontriez ce problème, assurez-vous que vos nœuds fonctionnent correctement avant de lancer une mise à niveau.

Mises à niveau et mises à jour

1.12

`containerd` 1.5.13 nécessite `libseccomp` 2.5 ou une version ultérieure

Les clusters Anthos sur bare metal version 1.12.1 sont fournis avec containerd version 1.5.13, et cette version de containerd nécessite libseccomp version 2.5 ou ultérieure.

Si la version 2.5 ou ultérieure de libseccomp n'est pas installée sur votre système, mettez-la à jour avant de mettre à niveau les clusters existants vers la version 1.12.1. Dans le cas contraire, vous pouvez voir des erreurs dans les pods cplb-update pour les nœuds d'équilibrage de charge, par exemple:


runc did not terminate successfully: runc: symbol lookup error: runc: undefined
symbol: seccomp_notify_respond

Solution

Pour installer la dernière version de libseccomp dans Ubuntu, exécutez la commande suivante:

sudo apt-get install  libseccomp-dev

Pour installer la dernière version de libseccomp dans CentOS ou RHEL, exécutez la commande suivante:

sudo dnf -y install libseccomp-devel

Opération

1.10, 1.11, 1.12

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

Si vous exécutez des clusters Anthos sur bare metal version 1.12.0 (anthosBareMetalVersion: 1.12.0) ou antérieure et utilisez manuellement kubectl cordon sur un nœud, les clusters Anthos sur bare metal peuvent annuler le marquage du nœud avant que vous ne soyez prêt à rapprocher l'état attendu.

Solution

Pour les clusters Anthos sur bare metal version 1.12.0 ou antérieure, utilisez le mode de maintenance pour marquer et décharger les nœuds en toute sécurité.

À partir de la version 1.12.1 (anthosBareMetalVersion: 1.12.1) ou d'une version ultérieure, les clusters Anthos sur bare metal n'annulent pas le marquage inattendu de vos nœuds lorsque vous utilisez kubectl cordon.

Opération

1.11

Les clusters d'administrateur version 11 utilisant un miroir de registre ne peuvent pas gérer les clusters de version 1.10

Si votre cluster d'administrateur est en version 1.11 et utilise un miroir de registre, il ne peut pas gérer les clusters d'utilisateur qui utilisent une version mineure. Ce problème affecte les opérations de réinitialisation, de mise à jour et de mise à niveau du cluster d'utilisateur.

Pour déterminer si ce problème vous concerne, consultez les journaux des opérations de cluster, telles que la création, la mise à niveau ou la réinitialisation. Ces journaux se trouvent par défaut dans le dossier bmctl-workspace/CLUSTER_NAME/. Si vous êtes affecté par le problème, vos journaux contiennent le message d'erreur suivant:


flag provided but not defined: -registry-mirror-host-to-endpoints

Opération

1,10 et 1,11

Secret kubeconfig écrasé

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 le fichier kubeconfig du cluster d'administrateur. Le remplacement du fichier entraîne l'échec des opérations standards du cluster, telles que la mise à jour et la mise à niveau, pour les clusters d'utilisateur concernés. Ce problème s'applique aux clusters Anthos sur bare metal 1.11.1 et versions antérieures.

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

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    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_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-. Par exemple, si vous nommez votre cluster test, l'espace de noms par défaut est cluster-test.
USER_CLUSTER_NAME: nom du cluster d'utilisateur à vérifier.

Si le nom du cluster dans la sortie (voir contexts.context.cluster dans l'exemple de résultat suivant) est le nom du cluster d'administrateur, le cluster d'utilisateur spécifié est affecté.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Solution

Pour restaurer la fonction dans un cluster d'utilisateur concerné (USER_CLUSTER_NAME), procédez comme suit :

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 des machines sont corrects pour votre cluster.
Exécutez la commande suivante pour supprimer le fichier kubeconfig corrompu du 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

Opération

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Si vous utilisez containerd comme environnement d'exécution de 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 de l'utilisateur. Sinon, il échouera 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 d'instantané. Le chemin d'accès sudo peut être différent du profil racine et peut ne pas contenir /usr/local/bin.

Solution

Mettez à jour secure_path dans /etc/sudoers pour inclure /usr/local/bin. Vous pouvez également créer un lien symbolique pour crictl dans un autre répertoire /bin.

Opération, environnement d'exécution des VM Anthos

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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 de leur adresse IP.

Si l'adresse IP d'une VM change, cela n'a aucune incidence sur la joignabilité des applications de VM exposées en tant que service Kubernetes.

Solution

Si l'adresse IP est perdue, vous devez exécuter dhclient à partir de la VM pour en obtenir une.

Journalisation et surveillance

1.10

`stackdriver-log-forwarder` comporte `[parser:cri] invalid time format` journaux d'avertissement

Si l'analyseur d'interface de conteneur (CRI) utilise une expression régulière incorrecte pour l'analyse, les journaux du pod stackdriver-log-forwarder contiennent des erreurs et des avertissements semblables à ceux-ci:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Solution :

Afficher la procédure de contournement

Mettez à niveau les clusters Anthos sur bare metal vers la version 1.11.0 ou une version ultérieure.

Si vous ne parvenez pas à mettre à niveau vos clusters immédiatement, procédez comme suit pour mettre à jour l'expression régulière d'analyse CRI:

Pour éviter que vos modifications suivantes ne soient annulées, réduisez la taille de stackdriver-operator:

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

Modifiez l'entrée Regex dans le ConfigMap stackdriver-log-forwarder-config:

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

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

[PARSER]
    # https://rubular.com/r/Vn30bO78GlkvyB
    Name cri
    Format regex
    # The timestamp is described in
    https://www.rfc-editor.org/rfc/rfc3339#section-5.6
    Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9]
    {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9]
    {2}:[0-9]{2})) (?<stream>stdout|stderr)
    (?<logtag>[^ ]*) (?<log>.*)$
    Time_Key    time
    Time_Format %Y-%m-%dT%H:%M:%S.%L%z
    Time_Keep   off

Redémarrez les pods du transfert de journaux :

kubectl --kubeconfig KUBECONFIG \
    -n kube-system rollout restart daemonset \
    stackdriver-log-forwarder

Journalisation et surveillance

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Surveillance inattendue de la facturation

Pour les clusters Anthos sur bare metal versions 1.10 ou supérieures, certains clients ont constaté une facturation élevée inattendue pour Metrics volume sur la page Facturation. Ce problème ne vous concerne que lorsque toutes les circonstances suivantes s'appliquent:

La surveillance des applications est activée (enableStackdriverForApplications=true)
Managed Service pour Prometheus n'est pas activé (enableGMPForApplications)
Les pods d'application comportent l'annotation prometheus.io/scrap=true

Pour savoir si vous êtes concerné par ce problème, répertoriez-les. Si la facturation de métriques indésirables s'affiche, ce problème vous concerne.

Solution

Si vous êtes concerné par ce problème, nous vous recommandons de mettre à niveau vos clusters vers la version 1.12 et de passer à la nouvelle solution de surveillance des applications managed-service-for-prometheus.

Indicateurs distincts pour contrôler la collecte des journaux d'application par rapport aux métriques d'application

Service Google Cloud Managed Service pour Prometheus inclus

Si vous ne pouvez pas passer à la version 1.12, procédez comme suit:

Recherchez les pods et services sources qui présentent une facturation indésirable :

kubectl --kubeconfig KUBECONFIG \
    get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
    services -A -o yaml | grep 'prometheus.io/scrape: "true"'

Supprimez l'annotation prometheus.io/scrap=true du pod ou du service.

Journalisation et surveillance

1.11, 1.12, 1.13, 1.14 et 1.15

Les modifications apportées à `metrics-server-config` ne sont pas conservées.

Une densité de pods élevée peut, dans des cas extrêmes, créer une surcharge de journalisation et de surveillance excessive, ce qui peut entraîner l'arrêt et le redémarrage du serveur de métriques. Vous pouvez modifier le ConfigMap metrics-server-config pour allouer davantage de ressources afin de maintenir le serveur de métriques en cours d'exécution. Toutefois, en raison du rapprochement, les valeurs par défaut peuvent être rétablies pour les modifications apportées à metrics-server-config lors d'une mise à jour ou d'une mise à niveau du cluster. Le serveur de métriques n'est pas affecté immédiatement, mais au prochain redémarrage, il récupère le ConfigMap rétabli et est à nouveau vulnérable à une surcharge excessive.

Solution

Pour la version 1.11.x, vous pouvez rédiger le script de la modification du ConfigMap et l'exécuter avec des mises à jour ou des mises à niveau du cluster. Pour les versions 1.12 et ultérieures, veuillez contacter l'assistance.

Journalisation et surveillance

1,11 et 1,12

Les métriques obsolètes ont une incidence sur le tableau de bord Cloud Monitoring

Plusieurs métriques Anthos sont obsolètes. À partir de la version 1.11 des clusters Anthos sur bare metal, les données ne sont plus collectées. Si vous utilisez ces métriques dans l'une de vos règles d'alerte, aucune donnée ne déclenchera la condition d'alerte.

Le tableau suivant répertorie les métriques individuelles obsolètes et la métrique qui les remplace.

Métriques obsolètes	Métrique de remplacement
`kube_daemonset_updated_number_scheduled`	`kube_daemonset_status_updated_number_scheduled`
`kube_node_status_allocatable_cpu_cores` `kube_node_status_allocatable_memory_bytes` `kube_node_status_allocatable_pods`	`kube_node_status_allocatable`
`kube_node_status_capacity_cpu_cores` `kube_node_status_capacity_memory_bytes` `kube_node_status_capacity_pods`	`kube_node_status_capacity`

Dans les versions d'clusters Anthos sur bare metal antérieures à la version 1.11, le fichier de définition de stratégie pour l'alerte Anthos on baremetal node cpu usage exceeds 80 percent (critical) recommandée utilise les métriques obsolètes. Le fichier de définition JSON node-cpu-usage-high.json est mis à jour pour les versions 1.11.0 et ultérieures.

Solution

Pour migrer vers les métriques de remplacement, procédez comme suit :

Dans la console Google Cloud, sélectionnez Monitoring ou cliquez sur le bouton suivant:
Accéder à Monitoring
Dans le volet de navigation, sélectionnez Tableaux de bord, puis supprimez le tableau de bord État des nœuds du cluster Anthos.
Cliquez sur l'onglet Bibliothèque d'échantillons, puis réinstallez le tableau de bord État des nœuds du cluster Anthos.
Suivez les instructions de la section Créer des règles d'alerte pour créer une règle à l'aide du fichier de définition de règle node-cpu-usage-high.json mis à jour.

Journalisation et surveillance

1,10 et 1,11

"`stackdriver-log-forwarder`" comporte des erreurs `CrashloopBackOff`

Dans certains cas, l'agent Logging fluent-bit peut se retrouver bloqué lors du traitement de fragments corrompus. Lorsque l'agent Logging ne parvient pas à contourner les fragments corrompus, vous pouvez constater que stackdriver-log-forwarder continue de planter avec une erreur CrashloopBackOff. Si vous rencontrez ce problème, vos journaux comportent des entrées semblables aux suivantes :


[2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
#1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
#2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
#3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
#4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0

Solution :

Nettoyez les fragments de la mémoire tampon pour le redirecteur Stackdriver Log.

Remarque: Dans les commandes suivantes, remplacez KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Arrêtez tous les pods stackdriver-log-forwarder :

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

Vérifiez que les pods stackdriver-log-forwarder sont bien 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

Exécutez les commandes suivantes pour vérifier que le DaemonSet a nettoyé tous les nœuds:

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

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

Supprimez le DaemonSet de nettoyage :

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

Redémarrez les pods du transfert de journaux :

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

Journalisation et surveillance

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Données de métriques inconnues dans Cloud Monitoring

Les données dans les clusters Cloud Monitoring pour les versions 1.10.x peuvent contenir des entrées de métriques récapitulatives non pertinentes, telles que:

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

Les autres types de métriques pouvant présenter des métriques récapitulatives non pertinentes sont les suivants :

apiserver_admission_step_admission_duration_seconds_summary
go_gc_duration_seconds
scheduler_scheduling_duration_seconds
gkeconnect_http_request_duration_seconds_summary
alertmanager_nflog_snapshot_duration_seconds_summary

Bien que ces métriques de type récapitulatif figurent dans la liste des métriques, elles ne sont pas compatibles avec gke-metrics-agent pour le moment.

Journalisation et surveillance

1,10 et 1,11

Interruptions intermittentes de l'exportation de métriques

Les clusters Anthos sur bare metal peuvent rencontrer des interruptions lors de l'exportation continue et standard des métriques, ou des métriques manquantes sur certains nœuds. Si ce problème affecte vos clusters, vous risquez de constater 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

Solution

Mettez à niveau vos clusters vers la version 1.11.1 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 de 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 trouve cpu: 50m si vos modifications ont été appliquées.

Mise en réseau

1.10

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 interruption de la connectivité depuis un pod vers 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é.

Mise en réseau

1.12

Les modifications de ressources personnalisées de mise en réseau sur des clusters d'utilisateur sont écrasées

La version 1.12.x des clusters Anthos sur bare metal ne vous empêche pas de modifier manuellement les ressources personnalisées de mise en réseau de votre cluster d'utilisateur. Les clusters Anthos sur bare metal fusionnent les ressources personnalisées des clusters d'utilisateur avec les ressources personnalisées de votre cluster d'administrateur lors des mises à niveau des clusters. Ce rapprochement écrase toutes les modifications apportées directement aux ressources personnalisées de mise en réseau du cluster d'utilisateur. Les ressources personnalisées de mise en réseau doivent être modifiées uniquement dans le cluster d'administrateur, mais les clusters Anthos sur bare metal version 1.12.x n'imposent pas cette exigence.

Les fonctionnalités de mise en réseau avancées, telles que l'équilibrage de charge groupé avec BGP, la passerelle NAT de sortie, la mise en réseau SR-IOV, le mode plat avec BGP et plusieurs cartes d'interface réseau pour les pods, utilisent les ressources personnalisées suivantes:

BGPLoadBalancer
BGPPeer
NetworkGatewayGroup
NetworkAttachmentDefinition
ClusterCIDRConfig
FlatIPMode

Vous modifiez ces ressources personnalisées dans votre cluster d'administrateur. L'étape de rapprochement applique les modifications à vos clusters d'utilisateur.

Solution

Si vous avez modifié l'une des ressources personnalisées mentionnées précédemment sur un cluster d'utilisateur, modifiez les ressources personnalisées correspondantes de votre cluster d'administrateur afin qu'elles correspondent avant la mise à niveau. Cette étape garantit que les modifications apportées à votre configuration sont conservées. Les clusters Anthos sur bare metal version 1.13.0 ou ultérieure vous empêchent de modifier directement les ressources personnalisées de mise en réseau de vos clusters d'utilisateur.

Mise en réseau

1.11, 1.12, 1.13, 1.14 et 1.15

Échec de la NAT avec trop de connexions parallèles

Pour un nœud donné de votre cluster, l'adresse IP du nœud fournit une traduction d'adresses réseau (NAT) pour les paquets acheminés vers une adresse en dehors du cluster. De même, lorsque des paquets entrants entrent dans un nœud d'équilibrage de charge configuré pour utiliser l'équilibrage de charge groupé (spec.loadBalancer.mode: bundled), la traduction d'adresse réseau source (SNAT) achemine les paquets vers l'adresse IP du nœud avant leur transfert vers un pod de backend.

La plage de ports pour le NAT utilisée par les clusters Anthos sur bare metal est de 32768 à 65535. Cette plage limite le nombre de connexions parallèles à 32 767 par protocole sur ce nœud. Chaque connexion nécessite une entrée dans la table "conntrack". Si vous avez trop de connexions de courte durée, la table conntrack s'épuise des ports pour la NAT. Un récupérateur de mémoire nettoie les entrées obsolètes, mais le nettoyage n'est pas immédiat.

Lorsque le nombre de connexions sur votre nœud atteint 32 767, vous pouvez observer des pertes de paquets pour les connexions nécessitant une fonctionnalité NAT.

Pour identifier ce problème, exécutez la commande suivante sur le pod anetd du nœud problématique:

kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

Les erreurs doivent s'afficher sous la forme suivante :


No mapping for NAT masquerade DROPPED

Solution

Répartissez votre trafic vers d'autres nœuds.

Mise en réseau

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

Si vous définissez la règle de trafic externe sur Local, des erreurs de routage peuvent se produire, 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 toutefois que le trafic local des nœuds.

Solution

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

Mise en réseau

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

La modification de `firewalld` effacera les chaînes de règles Cilium iptable

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

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

Le redémarrage de firewalld avec systemctl
Actualiser firewalld avec le client de ligne de commande (firewall-cmd --reload)

Solution

Redémarrez anetd sur le nœud. Recherchez 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.

Mise en réseau

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Dupliquer les adresses `egressSourceIP`

Lorsque vous utilisez la fonctionnalité de passerelle NAT de sortie, il est possible de définir des règles de sélection du trafic qui spécifient une adresse egressSourceIP déjà utilisée pour un autre objet EgressNATPolicy. Cela peut entraîner des conflits de routage du trafic de sortie.

Solution

Contactez votre équipe de développement pour déterminer les adresses IP flottantes disponibles avant de spécifier l'adresse egressSourceIP dans votre ressource personnalisée EgressNATPolicy.

Mise en réseau

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

Les clusters Anthos sur bare metal configure le filtrage au chemin inverse sur les nœuds pour désactiver la validation de la source (net.ipv4.conf.all.rp_filter=0). Si vous définissez le paramètre rp_filter sur 1 ou 2, les pods échoueront en raison de délais de communication hors nœud.

Le filtrage du chemin inverse est défini avec 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 inverse dans un fichier de configuration de la sécurité réseau, tel que /etc/sysctl.d/60-gce-network-security.conf.

Solution

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

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

Remplacez ANETD_XYZ par le nom du pod anetd.

Mise en réseau

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Amorçage des adresses IP du cluster et des adresses IP des nœuds de cluster qui se chevauchent

192.168.122.0/24 et 10.96.0.0/27 sont les CIDR des pods et des services par défaut utilisés par le cluster d'amorçage (kind). Les vérifications préliminaires échouent si elles se chevauchent avec les adresses IP de la machine du nœud du cluster.

Solution

Pour éviter le conflit, vous pouvez transmettre les options --bootstrap-cluster-pod-cidr et --bootstrap-cluster-service-cidr à bmctl afin de spécifier des valeurs différentes.

Système d'exploitation

1.11

Incompatibilité avec Ubuntu 18.04.6 sur le noyau GA

Les clusters Anthos sur bare metal versions 1.11.0 et 1.11.1 ne sont pas compatibles avec Ubuntu 18.04.6 sur le noyau GA (de 4.15.0-144-generic à 4.15.0-176-generic). L'incompatibilité provoque la configuration de l'agent réseau par le message d'erreur "Le programme BGP est trop volumineux" dans les journaux anetd. Il est possible que des pods restent bloqués à l'état ContainerCreating avec l'erreur networkPlugin cni failed to set up pod dans le journal des événements des pods. Ce problème ne s'applique pas aux noyaux HWE (Ubuntu Hardware Enablement).

Solution

Nous vous recommandons de télécharger le noyau HWE et de le mettre à niveau vers la dernière version compatible avec Ubuntu 18.04.

Système d'exploitation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

É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é le abandon de CentOS. Le 31 janvier 2022, CentOS 8 est arrivé en fin de vie. Suite à la fin de vie, les dépôts yum ne fonctionnent plus 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 s'applique à toutes les versions des clusters Anthos sur bare metal.

Solution

Afficher la procédure de contournement

Pour contourner ce problème, exécutez les commandes suivantes afin que 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.

Système d'exploitation

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

Sur RHEL et CentOS, la limite au niveau du cluster est de 100 000 points de terminaison. Service Kubernetes. Si deux services font référence au même ensemble de pods, cela compte pour deux ensembles de points de terminaison distincts. L'implémentation nftable sous-jacente sur RHEL et CentOS est à l'origine de cette limitation. Il ne s'agit pas d'une limitation intrinsèque des clusters Anthos sur bare metal.

Sécurité

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

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

Si vous utilisez containerd comme environnement d'exécution de conteneur et que SELinux est activé sur votre système d'exploitation, le VOLUME défini dans le Dockerfile de l'application risque de ne pas être accessible en écriture. Par exemple, les conteneurs créés avec le 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 affecté par ce problème, vous verrez un message d'erreur denied semblable à celui-ci:

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="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" 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

Solution

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

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

Sécurité

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Erreurs SELinux lors de la création du pod

La création de pods échoue parfois lorsque SELinux empêche l'exécution du conteneur de définir des libellés sur les installations tmpfs. Cet échec 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 des pods, utilisez la commande suivante pour rechercher les erreurs dans les journaux kubelet:

journalctl -u kubelet

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


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

ausearch -m avc

Cette commande recherche dans les journaux d'audit des erreurs d'autorisation du cache du vecteur d'accès (AVC). Le avc: denied dans l'exemple de réponse suivant confirme que les échecs de création de pod sont liés à l'application 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

Ce problème de création de pod avec SELinux est à l'origine d'un bug du noyau détecté 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

Solution

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

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

Réinitialisation/Suppression

1.10, 1.11, 1.12

Suppression d'un espace de noms

La suppression d'un espace de noms empêche la création de ressources dans cet espace de noms, y compris les tâches de réinitialisation des machines.

Solution

Lorsque vous supprimez un cluster d'utilisateur, vous devez d'abord supprimer l'objet de cluster avant de supprimer son espace de noms. Sinon, 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.

Réinitialisation/Suppression

1.10, 1.11, 1.12, 1.13, 1.14 et 1.15

Service containerd

La commande bmctl reset ne supprime aucun fichier de configuration ni aucun fichier binaire containerd. Le service containerd systemd est opérationnel. La commande supprime les conteneurs exécutant les pods planifiés sur le nœud.

Mises à niveau et mises à jour

1.10, 1.11, 1.12

Le détecteur de problèmes de nœuds n'est pas activé par défaut après la mise à niveau du cluster

Lorsque vous mettez à niveau des clusters Anthos sur bare metal, le détecteur de problèmes de nœuds n'est pas activé par défaut. Ce problème s'applique aux mises à niveau de la version 1.10 à la version 1.12.1 et a été corrigé dans la version 1.12.2.

Solution :

Pour activer l'outil de détection des problèmes de nœuds:

Vérifiez si le service node-problem-detector systemd est en cours d'exécution sur le nœud.
1. Utilisez la commande SSH et connectez-vous au nœud.
2. Vérifiez si le service node-problem-detector systemd est en cours d'exécution sur le nœud:
```
systemctl is-active node-problem-detector
```
  Si le résultat de la commande affiche inactive, cela signifie que le détecteur de problème de nœud n'est pas en cours d'exécution sur le nœud.
Pour activer l'outil de détection des problèmes de nœuds, utilisez la commande kubectl edit et modifiez le ConfigMap node-problem-detector-config. Pour en savoir plus, consultez la section Détecteur de problèmes de nœuds.

Opération

1,9 et 1,10

La commande bmctl backup cluster échoue si nodeAccess.loginUser est défini sur un nom d'utilisateur non racine.]

Solution :

Ce problème s'applique aux clusters Anthos sur bare metal 1.9.x, 1.10.0 et 1.10.1 et est résolu dans les versions 1.10.2 et ultérieures.

Mise en réseau

1.10, 1.11, 1.12

Les services d'équilibreur de charge ne fonctionnent pas avec les conteneurs sur le réseau hôte du plan de contrôle

Dans anetd, un paquet est supprimé pour les services LoadBalancer si les pods de backend s'exécutent tous deux sur le nœud du plan de contrôle et utilisent le champ hostNetwork: true dans la spécification du conteneur.

Le bug n'est pas présent dans la version 1.13 ou ultérieure.

Solution :

Les solutions suivantes peuvent vous aider si vous utilisez un service LoadBalancer reposant sur des pods hostNetwork:

Exécutez-les sur des nœuds de calcul (pas sur les nœuds du plan de contrôle).
Utilisez externalTrafficPolicy: local dans la spécification de service et assurez-vous que vos charges de travail s'exécutent sur des nœuds d'équilibreur de charge.

Mises à niveau et mises à jour

1,12 et 1,13

Le pod anthos-version-$version$ orphelin ne parvient pas à extraire l'image.

La mise à niveau du cluster de la version 1.12.x vers la version 1.13.x peut entraîner l'échec d'un pod anthos-version-$version$ avec une erreur ImagePullBackOff. Cela est dû au fait que la condition de concurrence de anthos-cluster-operator est mise à niveau et ne devrait affecter aucune fonctionnalité de cluster standard.

Le bug n'est plus présent après 1.13 ou une version ultérieure.

Solution :

Supprimez la tâche de Dynamic-version-installer d'ici le kubectl delete job anthos-version-$version$ -n kube-system

Mises à niveau et mises à jour

1.13

1.12 clusters mis à niveau depuis la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0

Les clusters version 1.12 mis à niveau depuis la version 1.11 ne peuvent pas être mis à niveau vers la version 1.13.0. Ce problème de mise à niveau ne s'applique pas aux clusters créés dans la version 1.12.

Pour déterminer si vous êtes concerné, consultez les journaux de la tâche de mise à niveau contenant la chaîne upgrade-first-no* dans le cluster d'administrateur. Si le message d'erreur suivant s'affiche, cela signifie que vous êtes concerné.

TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
...
[upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack is not a valid feature name.
...

Solution :

Pour résoudre ce problème, procédez comme suit :

Exécutez les commandes suivantes sur votre poste de travail administrateur:

echo '[{ "op": "remove", "path": \
    "/spec/clusterConfiguration/featureGates" }]' \
    > remove-feature-gates.patch
export KUBECONFIG=$ADMIN_KUBECONFIG
kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
    'kubectl patch kubeadmconfig $1 -n $0 --type json \
    --patch-file remove-feature-gates.patch'

Retentez une mise à niveau du cluster.

Si vous avez besoin d'aide, contactez l'assistance Google.

Problèmes connus des clusters Anthos sur Bare Metal

orderPolicy (DNS) non reconnu

Composants de la passerelle réseau Anthos évincés ou en attente, car la classe de priorité est manquante

La création et la mise à niveau des clusters échouent en raison de leur longueur

Les clusters version 1.14.0 et 1.14.1 avec fonctionnalités d'aperçu ne peuvent pas être mis à niveau vers la version 1.15.x

Les clusters version 1.15 n'acceptent pas les adresses IP flottantes en double

Les VM peuvent ne pas démarrer sur des clusters 1.13.7 qui utilisent un registre privé

Lors de la création du cluster dans le cluster de genre, le pod gke-metric-agent ne démarre pas

L'accès à un point de terminaison de service IPv6 entraîne le plantage du nœud LoadBalancer sur CentOS ou RHEL

Problèmes de connectivité intermittents après le redémarrage du nœud

La fonctionnalité en preview ne conserve pas les informations d'origine concernant l'autorisation et le propriétaire

clientconfig-operator reste en attente avec CreateContainerConfigError

Échec de la rotation de l'autorité de certification pour les clusters sans équilibrage de charge groupé

ipam-controller-manager parcours dans les clusters à double pile

etcd

État "Échec " de l'opérateur vfio-pci du mode SR-IOV

Certains nœuds de calcul ne sont pas prêts pour la mise à niveau

La rotation de plusieurs certificats à partir de cert-manager entraîne des incohérences

Pods obsolètes de déployeurs de contrôleurs de cycle de vie créés lors de la mise à niveau du cluster d'utilisateur

L'état de BGPSession change constamment en raison d'un grand nombre de routes entrantes

Délais d'expiration de l'application causés par les échecs d'insertion de la table conntrack

Impossible de restaurer les sauvegardes du cluster avec bmctl pour certaines versions

NetworkGatewayGroup plante si aucune adresse IP ne s'affiche sur l'interface

anthos-cluster-operator boucle de plantage lors de la suppression d'un nœud de plan de contrôle

kubeadm join échoue dans les clusters volumineux en raison d'une non-concordance des jetons

Limite de processeur faible pour metrics-server dans les clusters périphériques

La connexion directe NodePort au pod hostNetwork ne fonctionne pas

Les clusters d'administrateur 1.13.0 ne peuvent pas gérer 1.12.3 cluster(s) d'utilisateur

La mise à niveau vers la version 1.13.x est bloquée pour les clusters d'administrateur comportant des pools de nœuds de calcul

Erreurs lors de la mise à jour des ressources avec kubectl apply

Des fragments de tâches en attente corrompus génèrent stackdriver-log-forwarder boucle de plantage

Si vous redémarrez Dataplane V2 (anetd) sur des clusters, les VM existantes ne pourront pas être associées à des réseaux autres que des pods

gke-metrics-agent n'a pas de limite de mémoire sur les clusters de profils périphériques

La création du cluster peut échouer en raison des conditions de concurrence

Les adresses IP réservées ne sont pas libérées lors de l'utilisation du plug-in WHEREwhere avec la fonctionnalité avec plusieurs cartes d'interface réseau

Échec du détecteur de problèmes de nœuds dans le cluster d'utilisateur 1.10.4

1.14 Les nœuds de cluster IPv4 en mode île ont un masque CIDR de pod de 24

Échec du rollback de la mise à niveau du cluster

L'adresse IP externe du service ne fonctionne pas en mode plat

Les mises à niveau sur place de la version 1.13.0 vers la version 1.14.x ne s'arrêtent jamais

Les clusters mis à niveau vers la version 1.14.0 perdent des rejets maîtres.

Afficher la procédure de contournement

Échec de la création intermittente de la VM avec des erreurs d'importation

Les composants de collections gérées dans les clusters 1.11 ne sont pas conservés dans les mises à niveau vers la version 1.12.

Certains clusters version 1.12 avec l'environnement d'exécution de conteneurs Docker ne peuvent pas être mis à niveau vers la version 1.13

bmctl se ferme avant la fin de la création du cluster

Afficher la procédure de contournement

Signalement de l'erreur de rapprochement de l'environnement d'exécution des VM

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

Échec sur les systèmes avec le paramètre umask restrictif

Incompatibilité du groupe de contrôle v2

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

Identifiants par défaut de l'application et bmctl

Service Docker

Installer sur vSphere

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

La mise à niveau des clusters vers la version 1.12.1 peut être bloquée

La mise à niveau des clusters vers la version 1.12.0 ou une version ultérieure échoue lorsque l'environnement d'exécution des VM Anthos est activé

Migration bloquée à error during manifests operations

Les mises à niveau sont bloquées pour les clusters dotés de fonctionnalités qui utilisent la passerelle réseau Anthos

bmctl update ne supprime pas les blocs de maintenance

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

containerd 1.5.13 nécessite libseccomp 2.5 ou une version ultérieure

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

Les clusters d'administrateur version 11 utilisant un miroir de registre ne peuvent pas gérer les clusters de version 1.10

Secret kubeconfig écrasé

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

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 de leur adresse IP.

stackdriver-log-forwarder comporte [parser:cri] invalid time format journaux d'avertissement

Afficher la procédure de contournement

Surveillance inattendue de la facturation

Les modifications apportées à metrics-server-config ne sont pas conservées.

Les métriques obsolètes ont une incidence sur le tableau de bord Cloud Monitoring

"stackdriver-log-forwarder" comporte des erreurs CrashloopBackOff

Données de métriques inconnues dans Cloud Monitoring

Interruptions intermittentes de l'exportation de métriques

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

Les modifications de ressources personnalisées de mise en réseau sur des clusters d'utilisateur sont écrasées

Échec de la NAT avec trop de connexions parallèles

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

`orderPolicy` (DNS) non reconnu

`clientconfig-operator` reste en attente avec `CreateContainerConfigError`

`ipam-controller-manager` parcours dans les clusters à double pile

État "Échec " de l'opérateur `vfio-pci` du mode SR-IOV

L'état de `BGPSession` change constamment en raison d'un grand nombre de routes entrantes

Impossible de restaurer les sauvegardes du cluster avec `bmctl` pour certaines versions

`NetworkGatewayGroup` plante si aucune adresse IP ne s'affiche sur l'interface

`anthos-cluster-operator` boucle de plantage lors de la suppression d'un nœud de plan de contrôle

`kubeadm join` échoue dans les clusters volumineux en raison d'une non-concordance des jetons

Limite de processeur faible pour `metrics-server` dans les clusters périphériques

Erreurs lors de la mise à jour des ressources avec `kubectl apply`

Des fragments de tâches en attente corrompus génèrent `stackdriver-log-forwarder` boucle de plantage

Si vous redémarrez Dataplane V2 (`anetd`) sur des clusters, les VM existantes ne pourront pas être associées à des réseaux autres que des pods

`gke-metrics-agent` n'a pas de limite de mémoire sur les clusters de profils périphériques

`bmctl` se ferme avant la fin de la création du cluster

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

Échec sur les systèmes avec le paramètre `umask` restrictif

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

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

Migration bloquée à `error during manifests operations`

`bmctl update` ne supprime pas les blocs de maintenance

`containerd` 1.5.13 nécessite `libseccomp` 2.5 ou une version ultérieure

`stackdriver-log-forwarder` comporte `[parser:cri] invalid time format` journaux d'avertissement

Les modifications apportées à `metrics-server-config` ne sont pas conservées.

"`stackdriver-log-forwarder`" comporte des erreurs `CrashloopBackOff`

La modification de `firewalld` effacera les chaînes de règles Cilium iptable

Dupliquer les adresses `egressSourceIP`

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