Version 1.8. Diese Version wird unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Darin sind die neuesten Patches und Updates zu Sicherheitslücken, Kontakten und Problemen mit Anthos-Clustern auf VMware (GKE On-Prem) aufgeführt. Weitere Informationen finden Sie in den Versionshinweisen. Dies ist nicht die neueste Version.

Bekannte Probleme

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

Benutzerdefinierte ClientConfig-Ressource

gkectl update setzt alle manuellen Änderungen, die Sie an der benutzerdefinierten ClientConfig-Ressource vorgenommen haben, wieder zurück. Es wird dringend empfohlen, die ClientConfig-Ressource nach jeder manuellen Änderung zu sichern.

kubectl describe CSINode und gkectl diagnose snapshot

kubectl describe CSINode und gkectl diagnose snapshot schlagen manchmal aufgrund des OSS-Kubernetes-Problems beim Entfernen des Verweises für Null-Zeigerfelder fehl.

OIDC und das CA-Zertifikat

Der OIDC-Anbieter verwendet nicht standardmäßig die gemeinsame Zertifizierungsstelle. Sie müssen das CA-Zertifikat explizit bereitstellen.

Durch das Upgrade des Administratorclusters von 1.5 auf 1.6.0 werden 1.5-Nutzercluster gebrochen, die einen OIDC-Anbieter verwenden und in der Konfigurationsdatei des Nutzerclusters keinen Wert für authentication.oidc.capath haben.

Führen Sie das folgende Skript aus, um dieses Problem zu umgehen:

USER_CLUSTER_KUBECONFIG=YOUR_USER_CLUSTER_KUBECONFIG

IDENTITY_PROVIDER=YOUR_OIDC_PROVIDER_ADDRESS

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

Dabei gilt:

  • YOUR_OIDC_IDENTITY_PROVICER: Die Adresse Ihres OIDC-Anbieters:

  • YOUR_YOUR_USER_CLUSTER_KUBECONFIG: Der Pfad der Kubeconfig-Datei des Nutzerclusters.

gkectl check-config-Validierung schlägt fehl: F5 BIG-IP-Partitionen können nicht gefunden werden

Symptome

Die Validierung schlägt fehl, weil F5 BIG-IP-Partitionen nicht gefunden werden können, obwohl sie vorhanden sind.

Mögliche Ursachen

Ein Problem mit der F5 BIG-IP API kann dazu führen, dass die Validierung fehlschlägt.

Lösung

Versuchen Sie, gkectl check-config noch einmal auszuführen.

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

Derzeit kann das Upgrade von Clustern zu Unterbrechungen oder Ausfallzeiten bei Arbeitslasten führen, die PodDisruptionBudgets (PDBs) verwenden.

Knoten schließen ihren Upgradeprozess nicht ab

Wenn Sie PodDisruptionBudget-Objekte konfiguriert haben, die keine zusätzlichen Unterbrechungen zulassen, werden Knotenupgrades nach wiederholten Versuchen möglicherweise nicht auf die Version der Steuerungsebene aktualisiert. Zur Vermeidung dieses Fehlers empfehlen wir eine vertikale Skalierung von Deployment oder HorizontalPodAutoscaler, damit der Knoten unter Berücksichtigung der PodDisruptionBudget-Konfiguration entleert wird.

So rufen Sie alle PodDisruptionBudget-Objekte auf, die keine Störungen zulassen:

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  -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  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  -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  -n kube-system delete ds fluent-bit-cleanup

Schritt 3: Log Forwarder neu starten

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

Nutzerclusterinstallation wegen Problem bei Leader-Auswahl durch Cert Manager/CA Injektor fehlgeschlagen

Möglicherweise tritt ein Installationsfehler aufgrund von cert-manager-cainjector in Absturzschleife auf, wenn der API-Server/etcd langsam ist:

# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system cert-manager-cainjector-xxx`

I0923 16:19:27.911174       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110       1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593       1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629       1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"

Führen Sie die folgenden Befehle aus, um das Problem zu beheben.

Skalieren Sie zuerst monitoring-operator, damit die Änderungen am cert-manager-Deployment nicht rückgängig gemacht werden.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

Bearbeiten Sie als Nächstes das cert-manager-cainjector-Deployment, um die Leader-Auswahl zu deaktivieren, da nur ein Replikat ausgeführt wird. Er ist für ein einzelnes Replikat nicht erforderlich.

# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit -n kube-system deployment cert-manager-cainjector

Das relevante YAML-Snippet für das Deployment cert-manager-cainjector sollte in etwa so aussehen: ... apiVersion: apps/v1 kind: Deployment metadata: name: cert-manager-cainjector namespace: kube-system ... spec: ... template: ... spec: ... containers: - name: cert-manager image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0" args: ... - --leader-elect=false ...

Behalten Sie monitoring-operator-Replikate bei 0 als Minderung bei, bis die Installation abgeschlossen ist. Andernfalls wird die Änderung rückgängig gemacht.

Nachdem die Installation abgeschlossen ist und der Cluster ausgeführt wird, aktivieren Sie monitoring-operator für Tag-2-Vorgänge:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=1

Nach jedem Upgrade werden die Änderungen rückgängig gemacht. Wiederholen Sie diese Schritte, um das Problem zu minimieren, bis es in einer zukünftigen Version behoben wird.

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. Legen Sie die Variable KUBECONFIG fest.

    KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
    

    Ersetzen Sie ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG durch den absoluten Pfad zur kubeconfig-Datei des Administratorclusters.

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

    kubectl --kubeconfig "${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 "${KUBECONFIG}" get nodes -o \
    jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
    --selector='node-role.kubernetes.io/master')
    
  4. 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.

  5. Sichern Sie alte Zertifikate:

    Dieser Schritt ist optional, wird jedoch empfohlen.

    # ssh into admin master
    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 den Administrator-Masterknoten 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. 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 "${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.

  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 $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 wurde in Version 1.8.1 behoben. Bei den Versionen 1.7.2 und 1.8.0 können Sie dieses Problem mit einer der beiden folgenden Problemumgehungen manuell beheben:

  1. Entfernen Sie die Logdateien regelmäßig unter /run/aide/cron.daily.old* (empfohlen).
  2. Folgen Sie den Schritten im Skript /etc/cron.Daily/aide, um den gesamten Speicherplatz in /run zu verwenden. (Hinweis: Diese Problemumgehung kann sich möglicherweise auf den Compliancestatus des Knotens auswirken).

Seesaw-Load-Balancer mit Version 1.8.0 aktualisieren

Wenn Sie mit gkectl upgrade loadbalancer versuchen, einige Parameter des Seesaw-Load-Balancers in Version 1.8.0 zu aktualisieren, funktioniert dies weder im DHCP- noch im IPAM-Modus. Wenn Ihre Einrichtung diese Konfiguration enthält, führen Sie kein Upgrade auf Version 1.8.0 durch, sondern auf Version 1.8.1 oder höher.

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.

Panik gkectl create-config admin und gkectl create-config cluster

In Version 1.8.0-1.8.3 wird der Befehl gkectl create-config admin/cluster in die Meldung panic: invalid version: "latest" umgewandelt.

Verwenden Sie als Behelfslösung gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION. Ersetzen Sie DESIRED_CLUSTER_VERSION durch die gewünschte Version. Beispiel: 1.8.2-gke.8.

Zeitüberschreitung bei Administratorclustern erstellen/aktualisieren

Dieses Problem betrifft 1.8.0-1.8.3.

Die Erstellung eines Administratorclusters oder das Upgrade eines Administratorclusters wird möglicherweise mit dem folgenden Fehler abgebrochen:

Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory

Darüber hinaus endet das Protokoll unter nodes/ADMIN_MASTER_NODE/files/var/log/startup.log im externen Cluster-Snapshot mit dieser Meldung:

[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'

Dieser Fehler tritt auf, wenn das Netzwerk zwischen der VM der Administratorsteuerungsebene und der Container Registry langsam ist. Prüfen Sie Ihre Netzwerk- oder Proxyeinrichtung, um die Latenz zu verringern und die Bandbreite zu erhöhen.

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.

Konflikt mit cert-manager beim Ausführen von Upgrades auf Version 1.8.2 oder höher

Wenn Sie eine eigene cert-manager-Installation mit Anthos-Clustern auf VMware haben, kann ein Fehler auftreten, wenn Sie versuchen, ein Upgrade auf Version 1.8.2 oder höher durchzuführen. Dies ist auf einen Konflikt zwischen Ihrer Version von cert-manager, die wahrscheinlich im Namespace cert-manager installiert ist, und der Version monitoring-operator zurückzuführen.

Wenn Sie versuchen, eine weitere Kopie von cert-manager zu installieren, nachdem Sie ein Upgrade auf Anthos-Cluster auf VMware Version 1.8.2 oder höher ausgeführt haben, kann die Installation aufgrund eines Konflikts mit dem vorhandenen Cluster, der von monitoring-operator verwaltet wird, fehlschlagen.

Der Clusteraussteller metrics-ca, von dem Komponenten der Steuerungsebene und Beobachtbarkeitskomponenten zum Erstellen und Rotieren von Zertifikat-Secrets abhängen, erfordert ein metrics-ca-Zertifikat-Secret im Namespace der Clusterressource. Dieser Namespace ist kube-system für die Installation des Monitoring-Operators und wahrscheinlich cert-manager für Ihre Installation.

Wenn ein Installationsfehler aufgetreten ist, führen Sie die folgenden Schritte aus, um ein Upgrade auf Version 1.8.2 oder höher auszuführen:

  1. Deinstallieren Sie Ihre Version von cert-manager.

  2. Führen Sie das Upgrade aus.

  3. Wenn Sie Ihre eigene Installation von cert-manager wiederherstellen möchten, gehen Sie so vor:

    • Skalieren Sie das monitoring-operator-Deployment auf 0. Führen Sie für den Administratorcluster diesen Befehl aus:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0

      Führen Sie für einen Nutzercluster diesen Befehl aus:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0

    • Skalieren Sie die von monitoring-operator verwalteten cert-manager-Bereitstellungen auf 0. Führen Sie für den Administratorcluster diesen Befehl aus:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
      

      Führen Sie für einen Nutzercluster diesen Befehl aus:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0
      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
      
    • Installieren Sie cert-manager noch einmal.

    • Kopieren Sie das cert-manager.io/v1-Zertifikat metrics-ca und die Ausstellerressourcen metrics-pki.cluster.local von kube-system in den Clusterressourcen-Namespace des installierten cert-managers. Dieser Namespace kann cert-manager sein, wenn Sie den vorgelagerten cert-manager-Release (z. B. v1.0.3) verwenden. Dies hängt jedoch von Ihrer Installation ab.

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