Bekannte Probleme

In diesem Dokument werden bekannte Probleme für Version 1.7 von Anthos-Clustern auf VMware (GKE On-Prem) beschrieben.

Das Upgrade des Nutzerclusters schlägt fehl, weil die Registrierung bei der GCP fehlgeschlagen ist

Kategorie

Upgrade

Erkannte Versionen

1.7.0+, 1.8.0+

Symptome

Beim Upgrade von Nutzerclustern auf Version 1.7 schlägt der Befehl gkectl upgrade cluster mit Fehlermeldungen wie dieser fehl

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

Die Fehler weisen darauf hin, dass das Upgrade des Nutzerclusters größtenteils abgeschlossen ist, außer dass der Connect-Agent nicht aktualisiert wurde. Die Funktionalität von GKE Connect sollte jedoch nicht beeinträchtigt werden.

Ursache

Die in 1.7-Versionen verwendete Connect-Agent-Version 20210129-01-00 wird nicht mehr unterstützt.

Problemumgehung

Bitte wenden Sie sich an den Google-Support, um das Problem zu beheben.

systemd-timesyncd wird nach Neustart auf Ubuntu-Knoten nicht ausgeführt

Kategorie

Betriebssystem

Erkannte Versionen

1.7.1–1.7.5, 1.8.0–1.8.4, 1.9.0+

Symptome

systemctl status systemd-timesyncd sollte anzeigen, dass der Dienst inaktiv ist:

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

Das kann zu Zeitüberschreitungen führen.

Ursache

chrony wurde fälschlicherweise auf dem Ubuntu-Betriebssystem-Image installiert. Es gibt einen Konflikt zwischen chrony und systemd-timesyncd, wobei systemd-timesyncd inaktiv wird und chrony bei jedem Neustart der Ubuntu-VM aktiv wird. systemd-timesyncd sollte jedoch der Standard-NTP-Client für die VM sein.

Problemumgehung

Option 1: restart systemd-timesyncd jedes Mal manuell neu starten, wenn die VM neu gestartet wurde.

Option 2: Stellen Sie das folgende Daemonset bereit, damit systemd-timesyncd immer neu gestartet wird, wenn es inaktiv ist.

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}' ```

Der Log Forwarder stellt eine übermäßige Anzahl von OAuth 2.0-Anfragen.

Mit Anthos-Clustern in VMware, Version 1.7.1, können Probleme mit dem Log Forwarder auftreten, dass er Arbeitsspeicher verbraucht, indem übermäßig viele OAuth 2.0-Anfragen stellt. Mit dieser Problemumgehung können Sie die stackdriver-operator-Version downgraden, das Laufwerk bereinigen und Log Forwarder neu starten.

Schritt 0: Images in Ihre private Registry herunterladen (falls zutreffend)

Wenn Sie eine private Registry verwenden, führen Sie die folgenden Schritte aus, um diese Images in Ihre private Registry herunterzuladen, bevor Sie fortfahren. Wenn Sie keine private Registry verwenden, können Sie diesen Schritt überspringen.

Ersetzen Sie PRIVATE_REGISTRY_HOST durch den Hostnamen oder die IP-Adresse Ihrer privaten Docker-Registry.

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

Schritt 1: Downgrade für Version des Stackdriver-Operators ausführen

  • Führen Sie mit dem folgenden Befehl ein Downgrade Ihrer Version von stackdriver-operator aus.
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"}]}}}}'

Schritt 2: Zwischenspeicher des Laufwerks für Log Forwarder bereinigen

  • DaemonSet im Cluster bereitstellen, um den Zwischenspeicher zu bereinigen
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
  • Überprüfen Sie, ob der Zwischenspeicher des Laufwerks bereinigt wurde.
kubectl --kubeconfig [CLUSTER_KUBECONFIG] logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

Die Ausgabe zeigt die Anzahl der Knoten im Cluster.

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

Die Ausgabe zeigt die Anzahl der Knoten im Cluster.

  • Löschen Sie das Bereinigungs-Daemonset:
kubectl --kubeconfig [CLUSTER_KUBECONFIG] -n kube-system delete ds fluent-bit-cleanup

Schritt 3: Log Forwarder neu starten

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

Logs und Messwerte werden nicht an das von stackdriver.projectID angegebene Projekt gesendet

In Anthos-Cluster auf VMware 1.7 werden Logs an das übergeordnete Projekt des Dienstkontos gesendet, das im Feld stackdriver.serviceAccountKeyPath Ihrer Cluster-Konfigurationsdatei angegeben ist. Der Wert von stackdriver.projectID wird ignoriert. Dieses Problem wird in einer zukünftigen Version behoben.

Als Behelfslösung können Sie Logs im übergeordneten Projekt Ihres Logging-Monitoring-Dienstkontos aufrufen.

Möglicherweise müssen die Zertifikate vor einem Upgrade des Administratorclusters verlängert werden

Bevor Sie mit dem Upgrade des Administratorclusters beginnen, sollten Sie prüfen, ob die Zertifikate des Administratorclusters derzeit gültig sind, und sie verlängern, falls nicht.

Verlängerungsprozess des Administratorclusterzertifikats

  1. Prüfen Sie zuerst, ob OpenSSL auf der Administrator-Workstation installiert ist, bevor Sie beginnen.

  2. Rufen Sie die IP-Adresse und die SSH-Schlüssel für den Administrator-Masterknoten ab:

    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. Prüfen Sie, ob die Zertifikate abgelaufen sind:

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

    Wenn die Zertifikate abgelaufen sind, müssen Sie sie vor dem Upgrade des Administratorclusters verlängern.

  4. Da die kubeconfig-Datei des Administratorclusters auch abläuft, wenn die Administratorzertifikate ablaufen, sollten Sie diese Datei vor Ablauf sichern.

    • Sichern Sie die kubeconfig-Datei des Administratorclusters: 

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

    • Ersetzen Sie client-certificate-data und client-key-data in kubeconfig durch client-certificate-data und client-key-data in der von Ihnen erstellten Datei new_admin.conf.

  5. Sichern Sie alte Zertifikate:

    Dieser Schritt ist optional, wird jedoch empfohlen.

    # 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. Verlängern Sie die Zertifikate mit 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. Starten Sie statische Pods, die auf dem Administratormasterknoten ausgeführt werden, neu:

      # 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. Zertifikate von Administratorcluster-Worker-Knoten verlängern

    Ablaufdatum des Knotenzertifikats prüfen 

        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

    Erneuern Sie die Knotenzertifikate durch manuelle Knotenreparatur, wenn das Zertifikat bald abläuft.

  9. Sie müssen die erneuerten Zertifikate und das Zertifikat von kube-apiserver validieren.

    • Prüfen Sie den Ablauf der Zertifikate: 

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

    • Prüfen Sie das Zertifikat von 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

Das Skript /etc/cron.Daily/aide belegt den gesamten Speicherplatz in /run, was zu einer Absturzschleife in Pods führt

Ab Anthos-Clustern auf VMware 1.7.2 werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet. Daher wurde das Cron-Skript /etc/cron.daily/aide installiert, damit eine Unterstützungsprüfung geplant wird, um sicherzustellen, dass die CIS L1 Server-Regel „1.4.2 Dateiintegrität regelmäßig überprüft wird“.

Das Skript verwendet /run/aide als temporäres Verzeichnis, um seine Cron-Logs zu speichern. Im Laufe der Zeit könnte es den gesamten Speicherplatz in /run belegen. Informationen für eine Problemumgehung finden Sie unter Das Skript /etc/cron.daily/aide verbraucht den gesamten Speicherplatz in /run.

Wenn ein oder mehrere Pods auf einem Knoten abstürzen, führen Sie auf diesem Knoten df -h /run aus. Dieses Problem tritt wahrscheinlich auf, wenn die Befehlsausgabe 100 % Speicherplatznutzung anzeigt.

Dieses Problem wird in einer zukünftigen Version behoben. In der Zwischenzeit können Sie das Problem mit einer der folgenden beiden Problemumgehungen beheben:

  1. Entfernen Sie die Logdateien regelmäßig unter /run/aide/cron.daily.old* (empfohlen).
  2. Folgen Sie den Schritten unter dem obigen externen Link. (Hinweis: Diese Problemumgehung kann sich möglicherweise auf den Compliancestatus des Knotens auswirken).

Anthos-Cluster auf VMware mit Anthos Service Mesh ab Version 1.7 verwenden

Wenn Sie Anthos-Cluster auf VMware mit Anthos Service Mesh ab Version 1.7 verwenden und ein Upgrade auf Anthos-Cluster auf VMware-Version 1.6.0–1.6.3 oder Anthos-Cluster auf VMware-Version 1.7.0–1.7.2 durchführen möchten, müssen Sie die Labels bundle.gke.io/component-name und bundle.gke.io/component-version aus den folgenden benutzerdefinierten Ressourcendefinitionen entfernen:

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

  1. Führen Sie diesen Befehl aus, um die CRD destinationrules.networking.istio.io in Ihrem Nutzercluster zu aktualisieren:

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

  2. Entfernen Sie die Labels bundle.gke.io/component-version und bundle.gke.io/component-name aus der CRD.

Alternativ können Sie auf die Releases 1.6.4 und 1.7.3 warten und dann direkt ein Upgrade auf 1.6.4 oder 1.7.3 durchführen.

Anmeldung aufgrund der Ablaufzeit des Passworts nicht in der Administrator-Workstation möglich

Dieses Problem kann auftreten, wenn Sie eine der folgenden Versionen von Anthos-Clustern in VMware verwenden.

  • 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

Wenn Sie eine SSH-Verbindung zu Ihren Anthos-VMs herstellen, einschließlich der Administrator-Workstation, der Clusterknoten und der Seesaw-Knoten, erhalten Sie möglicherweise den folgenden Fehler:

WARNING: Your password has expired.

Dieser Fehler tritt auf, weil das Nutzerpasswort für ubuntu auf den VMs abgelaufen ist. Sie müssen die Ablaufzeit des Nutzerpassworts manuell auf einen hohen Wert zurücksetzen, bevor Sie sich bei den VMs anmelden.

Fehler bei der Ablaufzeit verhindern

Wenn Sie die oben aufgeführten betroffenen Versionen ausführen und das Nutzerpasswort noch nicht abgelaufen ist, sollten Sie die Ablaufzeit verlängern, bevor der SSH-Fehler angezeigt wird.

Führen Sie auf jeder Anthos-VM den folgenden Befehl aus:

sudo chage -M 99999 ubuntu

Minderung des Ablaufs für Passwörter

Wenn das Nutzerpasswort bereits abgelaufen ist und Sie sich nicht bei den VMs anmelden können, um die Ablaufzeit zu verlängern, führen Sie für jede Komponente die folgenden Schritte zur Risikominderung aus.

Administratorworkstation

Führen Sie die folgenden Schritte mit einer temporären VM aus. Sie können eine Administrator-Workstation mit der Version 1.7.1-gke.4 erstellen, die als temporäre VM verwendet werden soll.

  1. Prüfen Sie, ob die temporäre VM und die Administrator-Workstation deaktiviert sind.

  2. Hängen Sie das Bootlaufwerk der Administrator-Workstation an die temporäre VM an. Das Bootlaufwerk ist das Label "Festplatte 1".

  3. Stellen Sie das Bootlaufwerk innerhalb der VM bereit, indem Sie diese Befehle ausführen. Ersetzen Sie dev/sdc1 durch Ihre eigene Bootlaufwerk-ID.

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

  4. Legen Sie das Ablaufdatum des ubuntu-Nutzers auf einen großen Wert fest, z. B. 99999 Tage.

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

  5. Fahren Sie die temporäre VM herunter.

  6. Schalten Sie die Administrator-Workstation ein. Sie sollten nun wie gewohnt eine SSH-Verbindung herstellen können.

  7. Löschen Sie zur Bereinigung die temporäre VM.

VM der Administratorcluster-Steuerungsebene

Folgen Sie der Anleitung, um die VM des Administratorcluster-Steuerungsebenen neu zu erstellen.

Administratorcluster-Add-on-VMs

Führen Sie den folgenden Befehl auf der Administrator-Workstation aus, um die VM neu zu erstellen:

  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"}}]"

Nachdem Sie diesen Befehl ausgeführt haben, warten Sie, bis die Neuerstellung der Administratorcluster-Add-on-VMs abgeschlossen und bereit ist, bevor Sie mit den nächsten Schritten fortfahren.

Nutzercluster-VMs auf Steuerungsebene

Führen Sie den folgenden Befehl über die Administrator-Workstation aus, um die VMs neu zu erstellen:

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"}}]"

Warten Sie nach dem Ausführen dieses Befehls, bis die VMs der Nutzercluster-Steuerungsebene ihre Neuerstellung abgeschlossen haben und bereit sind, bevor Sie mit den nächsten Schritten fortfahren.

Nutzercluster-Worker-VMs

Führen Sie den folgenden Befehl auf der Administrator-Workstation aus, um die VMs neu zu erstellen.

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

Seesaw-VMs

Führen Sie die folgenden Befehle über die Administrator-Workstation aus, um die Seesaw-VMs neu zu erstellen. Es kommt zu einer Ausfallzeit. Wenn für den Load-Balancer Hochverfügbarkeit aktiviert ist, beträgt die maximale Ausfallzeit zwei Sekunden.

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

vCenter für Versionen unter 7.0U2 neu starten oder aktualisieren

Wenn das vCenter für Versionen unter 7.0U2 nach einem Upgrade oder anderweitig neu gestartet wird, ist der Netzwerkname in vm-Informationen von vCenter falsch und führt dazu, dass sich der Computer im Status Unavailable befindet. Dies führt dazu, dass die Knoten automatisch repariert werden, um neue Knoten zu erstellen.

Zugehöriger govmomi-Fehler: https://github.com/vmware/govmomi/issues/2552

Diese Problemumgehung wird vom VMware-Support bereitgestellt:

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.

SSH-Verbindung durch Remote-Host geschlossen

Bei Anthos-Cluster auf VMware-Version 1.7.2 und höher werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet. Um die CIS-Regel "5.2.16 Sicherstellen, dass das SSH-Zeitlimit für Inaktivität konfiguriert ist" zu erfüllen, hat /etc/ssh/sshd_config die folgenden Einstellungen:

ClientAliveInterval 300
ClientAliveCountMax 0

Bei diesen Einstellungen wird eine Clientsitzung nach 5 Minuten Inaktivität beendet. Der Wert ClientAliveCountMax 0 führt jedoch zu unerwartetem Verhalten. Wenn Sie die SSH-Sitzung auf der Administrator-Workstation oder einem Clusterknoten verwenden, wird die SSH-Verbindung möglicherweise getrennt, auch wenn Ihr SSH-Client nicht inaktiv ist, z. B. wenn ein zeitaufwendiger Befehl ausgeführt wird. Ihr Befehl wird dann möglicherweise mit der folgenden Nachricht beendet:

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

Zur Umgehung dieses Problems führen Sie eine der folgenden Aktionen aus:

  • Verwenden Sie nohup, um zu verhindern, dass Ihr Befehl beim Trennen einer SSH-Verbindung beendet wird.

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

  • Aktualisieren Sie sshd_config so, dass ein ClientAliveCountMax-Wert ungleich null verwendet wird. Die CIS-Regel empfiehlt die Verwendung eines Werts unter 3.

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

    Stellen Sie sicher, dass Sie Ihre SSH-Sitzung neu verbinden.

Falsch positive Ergebnisse beim Scannen auf Sicherheitslücken in Docker, Containerd und Runc

Die Docker-, Containerd- und Runc-Objekte in den Ubuntu-Betriebssystem-Images, die mit Anthos-Clustern in VMware geliefert werden, werden mithilfe von Ubuntu PPA an spezielle Versionen angepinnt. Dadurch wird gewährleistet, dass Änderungen der Containerlaufzeit von Anthos-Clustern auf VMware vor jedem Release qualifiziert werden.

Die speziellen Versionen sind jedoch im Ubuntu CVE-Tracker unbekannt. Er wird von den CVE-Scantools als Feeds für Sicherheitslücken verwendet. Daher werden falsch positive Ergebnisse beim Scannen auf Sicherheitslücken in Docker, Containerd und Runc angezeigt.

Zum Beispiel können die folgenden falsch positiven Ergebnisse aus den CVE-Scanergebnissen angezeigt werden. Diese CVEs wurden bereits in den neuesten Patchversionen von Anthos-Clustern auf VMware behoben.

Informationen zu CVE-Korrekturen finden Sie in den Versionshinweisen.

Das Problem ist Canonical bekannt und der Fehler wird unter https://github.com/canonical/sec-cvescan/issues/73 verfolgt.

/etc/cron.daily/aide-CPU- und Speicherspitzenproblem

Ab Anthos-Clustern auf VMware 1.7.2 werden die Ubuntu-Betriebssystem-Images mit CIS L1 Server Benchmark gehärtet.

Daher wurde das Cron-Skript /etc/cron.daily/aide installiert, damit eine aide-Prüfung geplant wird. Auf diese Weise wird die Einhaltung der CIS-L1-Serverregel „1.4.2 Dateisystemintegrität muss regelmäßig geprüft werden” sichergestellt.

Der Cronjob wird täglich um 6:25 Uhr (UTC) ausgeführt. Abhängig von der Anzahl der Dateien im Dateisystem kann es zu dieser Zeit zu CPU- und Speicherauslastungsspitzen kommen, die durch den aide-Prozess verursacht werden.

Wenn die Spitzen Ihre Arbeitslast beeinträchtigen, können Sie den täglichen Cronjob deaktivieren:

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