Problèmes connus

Ce document décrit les problèmes connus pour la version 1.7 d'Anthos Clusters on VMware (GKE On-Prem).

La mise à niveau du cluster d'utilisateur échoue en raison de l'échec de l'enregistrement sur GCP

Catégorie

Édition supérieure

Versions identifiées

1.7.0+, 1.8.0+

Symptômes

Lorsque vous mettez à niveau les clusters d'utilisateur vers les versions 1.7, la commande gkectl upgrade cluster échoue et un message d'erreur semblable à celui-ci s'affiche :

$ gkectl upgrade cluster --kubeconfig kubeconfig --config user-cluster.yaml
…
Upgrading to bundle version: "1.7.1-gke.4"
…
Exit with error:

failed to register to GCP, gcloud output: , error: error running command 'gcloud alpha container hub memberships register foo-cluster --kubeconfig kubeconfig --context cluster --version 20210129-01-00  --enable-workload-identity --has-private-issuer --verbosity=error --quiet': error: exit status 1, stderr: 'Waiting for membership to be created...

Les erreurs indiquent que la mise à niveau du cluster d'utilisateur est presque terminée, sauf que l'agent Connect n'a pas été mis à niveau. Toutefois, la fonctionnalité de GKE Connect ne devrait pas être affectée.

Cause

La version 20210129-01-00 de Connect Agent utilisée dans les versions 1.7 n'est plus compatible.

Solution

Veuillez contacter l'assistance Google pour résoudre le problème.

systemd-timesyncd ne s'exécute pas après le redémarrage sur le nœud Ubuntu

Catégorie

OS

Versions identifiées

1.7.1-1.7.5, 1.8.0-1.8.4, 1.9.0+

Symptômes

systemctl status systemd-timesyncd doit indiquer que le service est inactif :

● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: inactive (dead)

Cela peut entraîner des problèmes de synchronisation.

Cause

chrony a été mal installé sur l'image de l'OS Ubuntu, et il existe un conflit entre chrony et systemd-timesyncd, où systemd-timesyncd devient inactif et chrony devient actif à chaque fois que la VM Ubuntu redémarre. Toutefois, systemd-timesyncd doit être le client NTp par défaut pour la VM.

Solution

Option 1 : Exécutez manuellement restart systemd-timesyncd à chaque fois que la VM est redémarrée.

Option 2 : Déployez le Daemonset suivant afin que systemd-timesyncd soit toujours redémarré s'il est inactif.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ensure-systemd-timesyncd
spec:
  selector:
    matchLabels:
      name: ensure-systemd-timesyncd
  template:
    metadata:
      labels:
        name: ensure-systemd-timesyncd
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: ensure-systemd-timesyncd
        # Use your preferred image.
        image: ubuntu
        command:
        - /bin/bash
        - -c
        - |
          while true; do
            echo $(date -u)
            echo "Checking systemd-timesyncd status..."
            chroot /host systemctl status systemd-timesyncd
            if (( $? != 0 )) ; then
              echo "Restarting systemd-timesyncd..."
              chroot /host systemctl start systemd-timesyncd
            else
              echo "systemd-timesyncd is running."
            fi;
            sleep 60
          done
        volumeMounts:
        - name: host
          mountPath: /host
        resources:
          requests:
            memory: "10Mi"
            cpu: "10m"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /
````

## ClientConfig custom resource

`gkectl update` reverts any manual changes that you have made to the ClientConfig
custom resource. We strongly recommend that you back up the ClientConfig
resource after every manual change.

## `kubectl describe CSINode` and `gkectl diagnose snapshot`

`kubectl describe CSINode` and `gkectl diagnose snapshot` sometimes fail due to
the
[OSS Kubernetes issue](https://github.com/kubernetes/kubectl/issues/848){:.external}
on dereferencing nil pointer fields.

## OIDC and the CA certificate

The OIDC provider doesn't use the common CA by default. You must explicitly
supply the CA certificate.

Upgrading the admin cluster from 1.5 to 1.6.0 breaks 1.5 user clusters that use
an OIDC provider and have no value for `authentication.oidc.capath` in the
[user cluster configuration file](/anthos/clusters/docs/on-prem/1.7/how-to/user-cluster-configuration-file).

To work around this issue, run the following script:

<section><pre class="devsite-click-to-copy">
USER_CLUSTER_KUBECONFIG=<var class="edit">YOUR_USER_CLUSTER_KUBECONFIG</var>

IDENTITY_PROVIDER=<var class="edit">YOUR_OIDC_PROVIDER_ADDRESS</var>

openssl s_client -showcerts -verify 5 -connect $IDENTITY_PROVIDER:443 < /dev/null | awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/{ if(/BEGIN CERTIFICATE/){i++}; out="tmpcert"i".pem"; print >out}'

ROOT_CA_ISSUED_CERT=$(ls tmpcert*.pem | tail -1)

ROOT_CA_CERT="/etc/ssl/certs/$(openssl x509 -in $ROOT_CA_ISSUED_CERT -noout -issuer_hash).0"

cat tmpcert*.pem $ROOT_CA_CERT > certchain.pem CERT=$(echo $(base64 certchain.pem) | sed 's\ \\g') rm tmpcert1.pem tmpcert2.pem

kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG patch clientconfig default -n kube-public --type json -p "[{ \"op\": \"replace\", \"path\": \"/spec/authentication/0/oidc/certificateAuthorityData\", \"value\":\"${CERT}\"}]"
</pre></section>

Replace the following:

* <var>YOUR_OIDC_IDENTITY_PROVICER</var>: The address of your OIDC provider:

* <var>YOUR_YOUR_USER_CLUSTER_KUBECONFIG</var>: The path of your user cluster
  kubeconfig file.

## gkectl check-config</code> validation fails: can't find F5 BIG-IP partitions

<dl>
<dt>Symptoms</dt>
<dd><p>Validation fails because F5 BIG-IP partitions can't be found, even though they exist.</p></dd>
<dt>Potential causes</dt>
<dd><p>An issue with the F5 BIG-IP API can cause validation to fail.</p></dd>
<dt>Resolution</dt>
<dd><p>Try running <code>gkectl check-config</code> again.</p></dd>
</dl>

## Disruption for workloads with PodDisruptionBudgets {:#workloads_pdbs_disruption}

Upgrading clusters can cause disruption or downtime for workloads that use
[PodDisruptionBudgets](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/){:.external}
(PDBs).

## Nodes fail to complete their upgrade process

If you have `PodDisruptionBudget` objects configured that are unable to
allow any additional disruptions, node upgrades might fail to upgrade to the
control plane version after repeated attempts. To prevent this failure, we
recommend that you scale up the `Deployment` or `HorizontalPodAutoscaler` to
allow the node to drain while still respecting the `PodDisruptionBudget`
configuration.

To see all `PodDisruptionBudget` objects that do not allow any disruptions:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}' ```

Le service de transfert de journaux effectue un nombre excessif de requêtes OAuth 2.0

Remarque : Ce problème a été résolu dans les Anthos Clusters on VMware version 1.7.2.

Avec Anthos Clusters on VMware version 1.7.1, vous pouvez rencontrer des problèmes de consommation de mémoire du service de transfert de journaux si celui-ci effectue un nombre excessif de requêtes OAuth 2.0. Pour contourner le problème, vous pouvez revenir à la version antérieure de stackdriver-operator, nettoyer le disque et redémarrer le service de transfert de journaux.

Étape 0 : Télécharger les images dans votre registre privé si nécessaire

Si vous utilisez un registre privé, procédez comme suit pour télécharger ces images dans ce registre avant de continuer. Passez cette étape si vous n'utilisez pas de registre privé.

Remplacez PRIVATE_REGISTRY_HOST par le nom d'hôte ou l'adresse IP de votre registre Docker privé.

stackdriver-operator

docker pull gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440

docker tag gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440 \
    PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

docker push PRIVATE_REGISTRY_HOST/stackdriver-operator:v0.0.440

fluent-bit

docker pull gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3

docker tag gcr.io/gke-on-prem-release/fluent-bit:v1.6.10-gke.3 \
    PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

docker push PRIVATE_REGISTRY_HOST/fluent-bit:v1.6.10-gke.3

prometheus

docker pull gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0

docker tag gcr.io/gke-on-prem-release/prometheus:2.18.1-gke.0 \
    PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

docker push PRIVATE_REGISTRY_HOST/prometheus:2.18.1-gke.0

Étape 1 : Revenir à une version antérieure de stackdriver-operator

• Exécutez la commande suivante pour revenir à une version antérieure de stackdriver-operator.

kubectl  --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system patch deployment stackdriver-operator -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"stackdriver-operator","image":"gcr.io/gke-on-prem-release/stackdriver-operator:v0.0.440"}]}}}}'

Étape 2 : Nettoyer le tampon de disque du service de transfert de journaux

• Déployez le DaemonSet dans le cluster pour nettoyer le tampon.

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

• Vérifiez que le tampon de disque est nettoyé.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

Le résultat indique le nombre de nœuds du cluster.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l

Le résultat indique le nombre de nœuds du cluster.

• Supprimez le DaemonSet de nettoyage.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

Étape 3 : Redémarrer le service de transfert de journaux

kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system rollout restart ds/stackdriver-log-forwarder

Les journaux et les métriques ne sont pas envoyés au projet spécifié par stackdriver.projectID

Dans Anthos Clusters on VMware 1.7, les journaux sont envoyés au projet parent du compte de service spécifié dans le champ stackdriver.serviceAccountKeyPath de votre fichier de configuration de cluster. La valeur de stackdriver.projectID est ignorée. Ce problème sera résolu dans une prochaine version.

Pour contourner ce problème, affichez les journaux dans le projet parent de votre compte de service logging-monitoring.

Le renouvellement des certificats peut être obligatoire avant la mise à niveau du cluster d'administrateur.

Avant de commencer le processus de mise à niveau du cluster d'administrateur, vous devez vous assurer que les certificats de votre cluster d'administrateur sont actuellement valides et les renouveler si ce n'est pas le cas.

Remarque : Si vous avez commencé le processus de mise à niveau et que vous avez découvert une erreur d'expiration du certificat, contactez l'assistance Google pour obtenir de l'aide.

Remarque : Ces conseils s'appliquent exclusivement au renouvellement des certificats de cluster d'administrateur.

Processus de renouvellement du certificat du cluster d'administrateur

1. Assurez-vous qu'OpenSSL est installé sur le poste de travail administrateur avant de commencer.

2. Obtenez l'adresse IP et les clés SSH du nœud maître administrateur :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get secrets -n kube-system sshkeys \
   -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
   ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
   
   export MASTER_NODE_IP=$(kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes -o \
   jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
   --selector='node-role.kubernetes.io/master')
   

3. Vérifiez si les certificats ont expiré :

   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
   "sudo kubeadm alpha certs check-expiration"
   

   Si les certificats ont expiré, vous devez les renouveler avant de mettre à niveau le cluster d'administrateur.

4. Étant donné que le fichier kubeconfig du cluster d'administrateur expire également si les certificats d'administrateur expirent, vous devez sauvegarder ce fichier avant l'expiration.

   • Sauvegardez le fichier kubeconfig du cluster d'administrateur :

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
     vi [ADMIN_CLUSTER_KUBECONFIG]
     

   • Remplacez client-certificate-data et client-key-data dans kubeconfig par client-certificate-data et client-key-data dans le fichier new_admin.conf que vous avez créé.

5. Sauvegardez les anciens certificats :

   Il s'agit d'une étape facultative, mais recommandée.

   # ssh into admin master if you didn't in the previous step
   ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
   
   # on admin master
   sudo tar -czvf backup.tar.gz /etc/kubernetes
   logout
   
   # on worker node
   sudo scp -i ~/.ssh/admin-cluster.key \
   ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
   

6. Renouvelez les certificats avec kubeadm :

    # ssh into admin master
    ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
    # on admin master
    sudo kubeadm alpha certs renew all
    

7. Redémarrez les pods statiques exécutés sur le nœud maître administrateur:

     # on admin master
     cd /etc/kubernetes
     sudo mkdir tempdir
     sudo mv manifests/*.yaml tempdir/
     sleep 5
     echo "remove pods"
     # ensure kubelet detect those change remove those pods
     # wait until the result of this command is empty
     sudo docker ps | grep kube-apiserver
   
     # ensure kubelet start those pods again
     echo "start pods again"
     sudo mv tempdir/*.yaml manifests/
     sleep 30
     # ensure kubelet start those pods again
     # should show some results
     sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd
   
     # clean up
     sudo rm -rf tempdir
   
     logout
    

8. Renouveler les certificats des nœuds de calcul du cluster d'administrateur

   Vérifier la date d'expiration des certificats de nœud

       kubectl get nodes -o wide
       # find the oldest node, fill NODE_IP with the internal ip of that node
       ssh -i ~/.ssh/admin-cluster.key ubuntu@"${NODE_IP}"
       openssl x509 -enddate -noout -in /var/lib/kubelet/pki/kubelet-client-current.pem
       logout
      

   Si le certificat est sur le point d'expirer, renouvelez les certificats de nœud en suivant la réparation manuelle des nœuds.

9. Vous devez valider les certificats renouvelés et le certificat de kube-apiserver.

   • Vérifiez la date d'expiration des certificats :

     ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" 
     
     "sudo kubeadm alpha certs check-expiration"
     

   • Vérifiez le certificat de kube-apiserver :

     # Get the IP address of kube-apiserver
     cat [ADMIN_CLUSTER_KUBECONFIG] | grep server
     # Get the current kube-apiserver certificate
     openssl s_client -showcerts -connect : 
     
     | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'  
     
     > current-kube-apiserver.crt
     # check expiration date of this cert
     openssl x509 -in current-kube-apiserver.crt -noout -enddate
     

Le script /etc/cron.daily/aide utilise tout l'espace de /run, entraînant une boucle de plantage dans les pods

À partir de la version 1.7.2 d'Anthos Clusters on VMware, les images d'OS Ubuntu sont renforcées à l'aide du benchmark CIS L1 Server. Le script Cron /etc/cron.daily/aide a donc été installé. Il permet de programmer une vérification pour garantir que la règle CIS L1 Server "1.4.2 Ensure filesystem integrity is regularly checked" (S'assurer que l'intégrité du système de fichiers est régulièrement contrôlée) est appliquée.

Le script utilise /run/aide comme répertoire temporaire pour enregistrer ses journaux Cron. Il peut, au fil du temps, utiliser tout l'espace de /run. Consultez la page Le script /etc/cron.daily/aide utilise tout l'espace de /run pour résoudre le problème.

Si un ou plusieurs pods plantent sur un nœud, exécutez la commande df -h /run sur le nœud. Si le résultat de la commande indique une utilisation de 100 % de l'espace, vous rencontrez probablement ce problème.

Nous prévoyons d'ajouter un correctif dans une prochaine version. En attendant, vous pouvez résoudre ce problème de l'une des deux façons suivantes :

1. Supprimez régulièrement les fichiers journaux à l'emplacement /run/aide/cron.daily.old* (recommandé).
2. Suivez la procédure décrite dans le lien externe ci-dessus. (Remarque : Cette solution de contournement peut avoir un impact sur l'état de conformité des nœuds.)

Utiliser Anthos Clusters on VMware avec Anthos Service Mesh version 1.7 ou ultérieure

Si vous utilisez Anthos Clusters on VMware avec la version 1.7 ou ultérieure d'Anthos Service Mesh et que vous souhaitez passer à Anthos Clusters on VMware version 1.6.0-1.6.3 ou Anthos Clusters on VMware version 1.7.0-1.7.2, vous devez supprimer les libellés bundle.gke.io/component-name et bundle.gke.io/component-version des définitions de ressources personnalisées (CRDm Custom Resource Definition) suivantes :

• destinationrules.networking.istio.io
• envoyfilters.networking.istio.io
• serviceentries.networking.istio.io
• virtualservices.networking.istio.io

1. Exécutez la commande suivante pour mettre à jour l'objet CRD destinationrules.networking.istio.io dans votre cluster d'utilisateur :

   kubectl edit crd destinationrules.networking.istio.io --kubeconfig USER_CLUSTER_KUBECONFIG

2. Supprimez les libellés bundle.gke.io/component-version et bundle.gke.io/component-name de l'objet CRD.

Vous pouvez également attendre la version 1.6.4 et 1.7.3, puis effectuer la mise à niveau vers 1.6.4 ou 1.7.3 directement.

Impossible de se connecter au poste de travail administrateur en raison d'un problème d'expiration du mot de passe

Vous pouvez rencontrer ce problème si vous utilisez l'une des versions suivantes d'Anthos clusters on VMware.

• 1.7.2-gke.2
• 1.7.3-gke.2
• 1.8.0-gke.21
• 1.8.0-gke.24
• 1.8.0-gke.25
• 1.8.1-gke.7
• 1.8.2-gke.8

L'erreur suivante peut se produire lorsque vous tentez de vous connecter en SSH à vos VM Anthos, y compris le poste de travail d'administrateur, les nœuds de cluster et les nœuds Seesaw :

WARNING: Your password has expired.

Cette erreur se produit parce que le mot de passe utilisateur ubuntu sur les VM a expiré. Vous devez réinitialiser manuellement le délai d'expiration du mot de passe de l'utilisateur à une valeur élevée avant de vous connecter aux VM.

Remarque : La protection et l'atténuation recommandées ici ne respectent pas la règle 5.4.1.1 Benchmark CIS, "Garantir l'expiration du mot de passe à 365 jours maximum" sur le nœud.

Prévention de l'erreur d'expiration du mot de passe

Si vous exécutez les versions concernées répertoriées ci-dessus et que le mot de passe utilisateur n'a pas encore expiré, vous devez prolonger le délai d'expiration avant de voir apparaître l'erreur SSH.

Exécutez la commande suivante sur chaque VM Anthos :

sudo chage -M 99999 ubuntu

Atténuation des erreurs d'expiration de mot de passe

Si le mot de passe de l'utilisateur a déjà expiré et que vous ne pouvez pas vous connecter aux VM pour prolonger le délai d'expiration, procédez comme suit pour limiter les risques liés à chaque composant.

Poste de travail administrateur

Utilisez une VM temporaire pour effectuer les étapes suivantes. Vous pouvez créer un poste de travail administrateur en utilisant la version 1.7.1-gke.4 comme VM temporaire.

1. Assurez-vous que la VM temporaire et le poste de travail administrateur sont hors tension.

2. Associez le disque de démarrage du poste de travail administrateur à la VM temporaire. Le disque de démarrage est celui portant le libellé "Disque dur 1".

3. Installez le disque de démarrage dans la VM en exécutant ces commandes. Remplacez dev/sdc1 par votre propre identifiant de disque de démarrage.

   sudo mkdir -p /mnt/boot-disk
   sudo mount /dev/sdc1 /mnt/boot-disk
   

4. Définissez une date d'expiration pour l'utilisateur ubuntu sur une valeur élevée, par exemple 99999 jours.

   sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
   

5. Arrêtez la VM temporaire.

6. Mettez le poste de travail d'administrateur sous tension. Vous devriez maintenant pouvoir vous connecter en SSH comme d'habitude.

7. Pour le nettoyage, supprimez la VM temporaire.

VM du plan de contrôle pour le cluster d'administrateur

Suivez les instructions pour recréer la VM du plan de contrôle du cluster d'administrateur.

VM de modules complémentaires du cluster d'administrateur

Exécutez la commande suivante à partir du poste de travail administrateur pour recréer la VM :

  kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
  

Après avoir exécuté cette commande, attendez que les VM des modules complémentaires du cluster d'administrateur terminent la recréation et soient prêtes avant de passer aux étapes suivantes.

VM du plan de contrôle du cluster d'utilisateur

Exécutez la commande suivante à partir du poste de travail administrateur pour recréer les VM :

usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"

Après avoir exécuté cette commande, attendez que les VM du plan de contrôle du cluster d'utilisateur terminent la recréation et soient prêtes avant de passer aux étapes suivantes.

VM de nœud de calcul de cluster d'utilisateur

Exécutez la commande suivante à partir du poste de travail administrateur pour recréer les VM.

for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done

VM Seesaw

Exécutez les commandes suivantes à partir du poste de travail administrateur pour recréer les VM Seesaw. Il y aura un temps d'arrêt. Si le mode haute disponibilité est activé pour l'équilibreur de charge, le temps d'arrêt maximal est de deux secondes.

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff

Redémarrer ou mettre à niveau vCenter pour les versions antérieures à la version 7.0U2

Si vCenter, pour les versions antérieures à 7.0U2, est redémarré, après une mise à niveau ou autre, le nom de réseau dans les informations de VM de vCenter est incorrect et la machine présente un état Unavailable. Cela entraîne la réparation automatique des nœuds pour en créer de nouveaux.

Bug govmomi associé : https://github.com/vmware/govmomi/issues/2552

Cette solution est fournie par l'assistance VMware :

1. The issue is fixed in vCenter versions 7.0U2 and above.

2. For lower versions:
Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the
VM's portgroup.

Connexion SSH fermée par l'hôte distant

Pour Anthos Clusters on VMware version 1.7.2 et ultérieure, les images de l'OS Ubuntu sont renforcées avec le benchmark CIS L1 Server. Pour respecter la règle CIS "5.2.16 Vérifier que le délai d'inactivité de la connexion SSH est configuré", /etc/ssh/sshd_config a les paramètres suivants :

ClientAliveInterval 300
ClientAliveCountMax 0

Le but de ces paramètres est de mettre fin à une session client après cinq minutes d'inactivité. Cependant, la valeur ClientAliveCountMax 0 entraîne un comportement inattendu. Lorsque vous utilisez la session SSH sur le poste de travail administrateur, ou un nœud de clusters, la connexion SSH peut être déconnectée même si votre client SSH n'est pas inactif, par exemple lors de l'exécution d'une commande chronophage, et votre commande peut être interrompue avec le message suivant :

Connection to [IP] closed by remote host.
Connection to [IP] closed.

Pour contourner ce problème, vous pouvez utiliser l'une des méthodes suivantes :

• Utilisez nohup pour éviter que votre commande soit interrompue lors d'une déconnexion SSH.

  nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
  

• Mettez à jour sshd_config pour utiliser une valeur ClientAliveCountMax différente de zéro. La règle CIS recommande d'utiliser une valeur inférieure à 3.

  sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config
  sudo systemctl restart sshd
  

  Veillez à reconnecter votre session SSH.

Faux positifs lors de l'analyse des failles docker, containerd et runc

Les conteneurs Docker, containerd et runc des images d'OS Ubuntu fournies avec Anthos clusters on VMware sont rattachés aux versions spéciales à l'aide de Ubuntu PPA. Cela garantit que tout changement d'environnement d'exécution des conteneurs sera qualifié par Anthos clusters on VMware avant chaque publication de version.

Cependant, les versions spéciales ne sont pas connues de l'outil de suivi CVE d'Ubuntu, qui est utilisé comme flux concernant les failles par divers outils d'analyse CVE. Par conséquent, vous observerez des faux positifs dans les résultats d'analyse des failles docker, containerd et runc.

Par exemple, il est possible que les faux positifs ci-dessous apparaissent dans les résultats de l'analyse CVE. Ces failles CVE sont déjà corrigées dans les dernières versions corrigées d'Anthos clusters on VMware.

• CVE-2019-16884
• CVE-2019-19921
• CVE-2020-15157
• CVE-2020-15257

Reportez-vous aux notes de version pour obtenir les correctifs CVE.

Canonical est informé de ce problème et le correctif est disponible à l'adresse https://github.com/canonical/sec-cvescan/issues/73.

/etc/cron.daily/aide Problème de pic de mémoire et de processeur

À partir de la version 1.7.2 d'Anthos Clusters on VMware, les images d'OS Ubuntu sont renforcées à l'aide du benchmark CIS L1 Server.

Le script Cron /etc/cron.daily/aide a donc été installé. Il permet de programmer une vérification aide pour garantir que la règle CIS L1 Server "1.4.2 Ensure filesystem integrity is regularly checked" (S'assurer que l'intégrité du système de fichiers est régulièrement contrôlée) est appliquée.

La tâche Cron s'exécute tous les jours à 6h25 UTC. Selon le nombre de fichiers sur le système de fichiers, vous pouvez rencontrer des pics d'utilisation du processeur et de la mémoire autour de cette période, en raison du processus aide.

Si les pics affectent votre charge de travail, vous pouvez désactiver la tâche Cron quotidienne :

`sudo chmod -x /etc/cron.daily/aide`.