Bekannte Probleme

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

/var/log/audit/ Speicherplatz belegen

Kategorie

Betriebssystem

Erkannte Versionen

1.8.0+, 1.9.0+, 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+

Symptome

/var/log/audit/ ist mit Audit-Logs gefüllt. Sie können die Laufwerksnutzung mit sudo du -h -d 1 /var/log/audit prüfen.

Ursache

Seit Anthos Version 1.8 wird das Ubuntu-Image mit CIS Level2 Benchmark gehärtet. Eine der Complianceregeln 4.1.2.2 Ensure audit logs are not automatically deleted sorgt für die geprüfte Einstellung max_log_file_action = keep_logs. Dadurch werden alle Audit-Regeln auf dem Laufwerk gespeichert.

Problemumgehung

Administratorworkstation

Für die Administrator-Workstation können Sie die geprüften Einstellungen manuell so ändern, dass die Logs automatisch rotiert werden. Anschließend können Sie den geprüften Dienst neu starten:

sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd

Die obige Einstellung würde veranlassen, dass geprüfte Logs automatisch rotieren, sobald mehr als 250 Dateien mit jeweils 8 Mio. Größe generiert wurden.

Clusterknoten

Wenden Sie für Clusterknoten das folgende DaemonSet auf Ihren Cluster an, um potenzielle Probleme zu vermeiden:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: change-auditd-log-action
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: change-auditd-log-action
  template:
    metadata:
      labels:
        app: change-auditd-log-action
    spec:
      hostIPC: true
      hostPID: true
      containers:
      - name: update-audit-rule
        image: ubuntu
        command: ["chroot", "/host", "bash", "-c"]
        args:
        - |
          while true; do
            if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
              echo "updating auditd max_log_file_action to rotate with a max of 250 files"
              sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
              sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
              echo "restarting auditd"
              systemctl restart auditd
            else
              echo "auditd setting is expected, skip update"
            fi
            sleep 600
          done
        volumeMounts:
        - name: host
          mountPath: /host
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: /

Diese Änderung der geprüften Konfiguration würde gegen die CIS-Level-2-Regel 4.1.2.2 Ensure audit logs are not automatically deleted verstoßen.

Upgrade/Aktualisierung des Nutzerclusters schlägt aufgrund von „Fehler beim Registrieren des Nutzerclusters“ fehl

Kategorie

Upgrade, Aktualisierung

Erkannte Versionen

1.7.0+, 1.8.0+

Symptome

Führen Sie gkectl diagnose cluster aus, wenn bei einem vorherigen gkectl-Befehl in den folgenden Fällen eine Zeitüberschreitung aufgetreten ist.

1. Upgrade von Nutzerclustern mit GKE Connect auf aktivierte 1.8-Versionen.
2. gkectl update cluster wird auf 1.8-Nutzerclustern mit aktivierter GKE-Verbindung ausgeführt.
3. gkectl update cluster ausführen, um GKE Connect auf Nutzerclustern der Version 1.8 zu aktivieren.

$ gkectl diagnose cluster --kubeconfig kubeconfig --cluster-name foo-cluster
…
    Unhealthy Resources:
      OnPremUserCluster foo-cluster: not ready: ready condition is not true: ClusterCreateOrUpdate: failed to register user cluster "foo-cluster": failed to register cluster: ...
...

Beachten Sie, dass die Funktionalität von GKE Connect nicht beeinträchtigt werden sollte. Mit anderen Worten: Wenn GKE Connect vor dem Befehl funktioniert hat, sollte es weiterhin funktionieren.

Ursache

Die in 1.8-Versionen verwendete Connect-Agent-Version 20210514-00-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.

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

Die Installation von Nutzerclustern ist fehlgeschlagen, weil in cert-manager/ca-injector ein Problem mit der Leader-Auswahl in Anthos 1.8.2 und 1.8.3 aufgetreten ist

Möglicherweise wird ein Installationsfehler aufgrund von cert-manager-cainjector in der Absturzschleife angezeigt, wenn der API-Server/etcd langsam ist. Mit dem folgenden Befehl

  kubectl logs --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployments/cert-manager-cainjector

ergibt die Logs beispielsweise Folgendes:

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 herunter, damit die Änderungen am cert-manager-cainjector-Deployment nicht rückgängig gemacht werden.

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

Patchen Sie dann das cert-manager-cainjector-Deployment, um die Leader-Auswahl zu deaktivieren. Das ist sicher, weil nur ein Replikat ausgeführt wird. Er ist für ein einzelnes Replikat nicht erforderlich.

# Ensure that we run only 1 cainjector replica, even during rolling updates.
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=strategic --patch '
spec:
  strategy:
    rollingUpdate:
      maxSurge: 0
'
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl patch --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system deployment cert-manager-cainjector --type=json --patch '[
    {
        "op": "add",
        "path": "/spec/template/spec/containers/0/args/-",
        "value": "--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 ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=1

Nach dem Upgrade auf 1.8.4 und höher (oder 1.9.1 und höher, wenn ein Upgrade auf 1.9 erfolgt), sind diese Schritte nicht mehr erforderlich, da Anthos die Leader-Auswahl für Kainjector deaktiviert. Wenn dieses Problem bei jedem Upgrade auftritt, müssen Sie dieselben Schritte zur Risikominderung noch einmal ausführen.

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.

Hinweis: Wenn Sie den Upgradeprozess gestartet und einen Fehler beim Ablauf des Zertifikats festgestellt haben, wenden Sie sich an den Google-Support.

Hinweis: Diese Anleitung gilt ausschließlich für die Verlängerung von Zertifikaten für Administratorcluster.

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

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

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

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

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

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

Hinweis: Die hier empfohlene Prävention und Schadensminderung verstoßen auf dem Knoten gegen die CIS-Benchmark-Regel 5.4.1.1, "Der Ablauf des Passworts darf höchstens 365 Tage dauern".

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:

Hinweis: Sie müssen diese Aufgabe nur einmal für jeden Cluster anwenden und die Änderungen bleiben beim Clusterupgrade erhalten.

Konflikte während des Upgrades vermeiden

1. Deinstallieren Sie Ihre Version von cert-manager. Wenn Sie Ihre eigenen Ressourcen definiert haben, können Sie diese sichern.

2. Führen Sie das Upgrade aus.

3. Folgen Sie der Anleitung, um Ihren eigenen cert-manager wiederherzustellen.

Eigenen Cert-Manager in Nutzerclustern wiederherstellen

• Skalieren Sie das monitoring-operator-Deployment auf 0.

  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.

  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. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, sofern vorhanden.

• 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. Ihr installierter cert-manager-Namespace ist cert-manager, wenn Sie die vorgelagerte Standard-cert-manager-Installation verwenden. Dies hängt aber von Ihrer Installation ab.

  relevant_fields='
  {
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
  name: .metadata.name,
  namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
  }
  '
  f1=$(mktemp)
  f2=$(mktemp)
  kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
  kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f2
  kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
  kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2
   

Eigenen Cert-Manager in Administratorclustern wiederherstellen

Im Allgemeinen müssen Sie cert-manager in Administratorclustern nicht neu installieren, da Administratorcluster nur Anthos-Cluster auf VMware-Steuerungsebenen-Arbeitslasten ausführen. In den seltenen Fällen, in denen Sie auch Ihren eigenen cert-manager in Administratorclustern installieren müssen, folgen Sie der folgenden Anleitung, um Konflikte zu vermeiden. Wenn Sie Apigee-Kunde sind und Cert-Manager nur für Apigee benötigen, müssen Sie die Befehle des Administratorclusters nicht ausführen.

• Skalieren Sie das monitoring-operator-Deployment auf 0.

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

• Skalieren Sie die von monitoring-operator verwalteten cert-manager-Bereitstellungen auf 0.

  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
    

• Installieren Sie cert-manager noch einmal. Stellen Sie Ihre benutzerdefinierten Ressourcen wieder her, sofern vorhanden.

• 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. Ihr installierter cert-manager-Namespace ist cert-manager, wenn Sie die vorgelagerte Standard-cert-manager-Installation verwenden. Dies hängt aber von Ihrer Installation ab.

  relevant_fields='
  {
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
  name: .metadata.name,
  namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
  }
  '
  f3=$(mktemp)
  f4=$(mktemp)
  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get issuer -n kube-system metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
  kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n kube-system metrics-ca -o json | jq "${relevant_fields}" > $f4
  kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
  kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
   

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.

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

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

Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

Seesaw wird im DSR-Modus ausgeführt und funktioniert aufgrund des IP-Lernens auf Datenebene standardmäßig nicht in Cisco ACI. Eine mögliche Problemumgehung besteht in der Deaktivierung des IP-Lernens. Fügen Sie dazu die Seesaw-IP-Adresse als virtuelle L4-L7-IP-Adresse zum Cisco Application Policy Infrastructure Controller (APIC) hinzu.

Sie können die virtuelle IP-Adresse für L4-L7 unter Mandant > Anwendungsprofile > Anwendungs-EPGs oder uSeg-EPGs konfigurieren. Wird das IP-Lernen nicht deaktiviert, führt dies zu Flapping von IP-Endpunkten zwischen verschiedenen Standorten in der Cisco API-Fabric.

Ein zu langes Dienstkontoinhabertoken kann die Logs von Seesaw-Load-Balancer beeinträchtigen.

Wenn das Inhabertoken des Logging-Monitoring-Dienstkontos größer als 512 KB ist, können die Seesaw-Load-Balancer-Logs beeinträchtigt werden. Führen Sie zur Problembehebung ein Upgrade auf Version 1.9 oder höher durch.

Verbindungsprobleme zwischen Pods aufgrund von anetd-Daemons im Software-Deadlock

Bei Clustern, für die enableDataplaneV2 auf true festgelegt ist, können Verbindungsprobleme zwischen Pods auftreten, da anetd-Daemons (die als Daemonset ausgeführt werden) eine Software-Deadlock eingeben. In diesem Zustand sehen anetd-Daemons veraltete Knoten (zuvor gelöschte Knoten) als Peers und verpassen neu hinzugefügte Knoten als neue Peers.

Wenn dieses Problem aufgetreten ist, führen Sie die folgenden Schritte aus, um die anetd-Daemons neu zu starten und die Peer-Knoten zu aktualisieren. Die Verbindung sollte dann wiederhergestellt werden.

1. Alle anetd-Daemons im Cluster suchen:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
   

2. Prüfen Sie, ob die anetd-Daemons derzeit veraltete Peers sehen:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
   

   Ersetzen Sie ANETD_XYZ durch den Namen eines anetd-Pods.

3. Starten Sie alle betroffenen Pods neu:

   kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ
   

„Gkectl diagnose“-Prüfung von Zertifikatfehlern

Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten von Nutzerclustern hat, wird beim Ausführen von gkectl diagnose die folgende Fehlermeldung angezeigt, die Sie ignorieren können.

Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out