Bekannte Probleme

In diesem Dokument werden bekannte Probleme für Version 1.9 von Anthos-Cluster 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.

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: /

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.

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

Die Installation des Nutzerclusters ist aufgrund eines Problems mit der Wahl des Cert-Manager/ca-injector in Anthos 1.9.0 fehlgeschlagen.

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 Version 1.9.1 oder höher sind diese Schritte nicht mehr erforderlich, da Anthos die Leader-Auswahl für Kainjector deaktiviert.

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

Prüfen Sie zuerst, ob OpenSSL auf der Administrator-Workstation installiert ist, bevor Sie beginnen.
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.

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')

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

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 .

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

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

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

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 die Maschine im Zustand 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.

Konflikt mit `cert-manager` beim Upgrade auf Version 1.9.0 oder 1.9.1

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.9.0 oder 1.9.1 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.9.0 oder 1.9.1 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.9.0 oder 1.9.1 auszuführen:

Konflikte während des Upgrades vermeiden

Deinstallieren Sie Ihre Version von cert-manager. Wenn Sie Ihre eigenen Ressourcen definiert haben, können Sie diese sichern.
Führen Sie das Upgrade aus.
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.

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

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

In Versionen 1.9.2 oder höher installiert monitoring-operator cert-manager im Namespace cert-manager. Wenn Sie aus bestimmten Gründen Ihren eigenen Cert-Manager installieren müssen, folgen Sie der folgenden Anleitung, um Konflikte zu vermeiden:

Konflikte während des Upgrades vermeiden

Deinstallieren Sie Ihre Version von cert-manager. Wenn Sie Ihre eigenen Ressourcen definiert haben, können Sie diese sichern.
Führen Sie das Upgrade aus.
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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

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

Sie können diesen Schritt überspringen, wenn Sie die vorgelagerte Standardinstallation von cert-manager verwenden oder sicher sind, dass Ihr cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das cert-manager.io/v1-Zertifikat metrics-ca und die Ausstellerressourcen metrics-pki.cluster.local von cert-manager in den Clusterressourcen-Namespace des installierten cert-managers.

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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get certificate -n cert-manager 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

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 cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-cainjector --replicas=0
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n cert-manager scale deployment cert-manager-webhook --replicas=0

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

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 cert-manager metrics-pki.cluster.local -o json | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get certificate -n cert-manager 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.

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.

Fehlerhafte Konnektivitätsserver-Pods bei Verwendung von Seesaw- oder manuellem Load-Balancer

Wenn Sie Seesaw oder den Load-Balancer im manuellen Modus verwenden, stellen Sie möglicherweise fest, dass die Pods des Konnektivitätsservers fehlerhaft sind. Dies liegt daran, dass Seesaw die Wiederverwendung einer IP-Adresse in einem Dienst nicht unterstützt. Im manuellen Modus wird der Dienst nicht automatisch auf Ihrem Load-Balancer bereitgestellt.

Das SSH-Tunneling ist in Clustern der Version 1.9 aktiviert. Selbst wenn der Konnektivitätsserver nicht fehlerfrei ist, können Sie den SSH-Tunnel weiterhin verwenden. So sollte die Verbindung zu und innerhalb des Clusters nicht beeinträchtigt werden. Daher müssen Sie sich keine Gedanken über diese fehlerhaften Pods machen.

Wenn Sie ein Upgrade von Version 1.9.0 auf 1.9.x durchführen möchten, wird empfohlen, die fehlerhaften Serverbereitstellungen vor dem Upgrade zu löschen. Führen Sie den folgenden Befehl aus:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME delete Deployment konnectivity-server

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

Load-Balancer und zustandsorientierte verteilte NSX-T-Firewallregeln interagieren unvorhersehbar

Wenn bei der Bereitstellung von Anthos-Clustern auf VMware-Version 1.9 oder höher der gebündelte Seesaw-Load-Balancer der Bereitstellung in einer Umgebung mit zustandsorientierten verteilten NSX-T-Firewallregeln vorhanden ist, erstellt stackdriver-operator möglicherweise keine gke-metrics-agent-conf-ConfigMap und verursacht, dass gke-connect-agent Pods in einer Absturzschleife.

Das zugrunde liegende Problem besteht darin, dass die zustandsorientierten verteilten NSX-T-Firewallregeln die Verbindung von einem Client zum Nutzercluster-API-Server über den Seesaw-Load-Balancer beenden, da Seesaw asymmetrische Verbindungsflüsse verwendet. Die Integrationsprobleme mit NSX-T-verteilten Firewallregeln wirken sich auf alle Anthos-Cluster auf VMware-Releases aus, die Seesaw verwenden. Möglicherweise treten bei Ihren eigenen Anwendungen ähnliche Verbindungsprobleme auf, wenn sie große Kubernetes-Objekte erstellen, deren Größe größer als 32 KB ist. Folgen Sie dieser Anleitung, um verteilte NSX-T-Firewallregeln zu deaktivieren oder zustandslose verteilte Firewallregeln für Seesaw-VMs zu verwenden.

Wenn Ihre Cluster einen manuellen Load-Balancer verwenden, folgen Sie dieser Anleitung, um Ihren Load-Balancer so zu konfigurieren, dass Clientverbindungen zurückgesetzt werden, wenn ein Back-End-Knotenfehler auftritt. Ohne diese Konfiguration reagieren Clients des Kubernetes API-Servers möglicherweise mehrere Minuten lang nicht, wenn eine Serverinstanz ausfällt.

Fehler beim Registrieren des Administratorclusters während der Erstellung

Wenn Sie einen Administratorcluster für Version 1.9.x oder 1.10.0 erstellen und der Administratorcluster sich während der Erstellung nicht mit der bereitgestellten gkeConnect-Spezifikation registrieren kann, wird der folgende Fehler angezeigt.

  Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

Sie können diesen Administratorcluster weiterhin verwenden, erhalten jedoch die folgende Fehlermeldung, wenn Sie später versuchen, den Administratorcluster auf Version 1.10.y zu aktualisieren.

  failed to migrate to first admin trust chain: failed to parse current version "":
  invalid version: "" failed to migrate to first admin trust chain: failed to parse
  current version "": invalid version: ""

Wenn dieser Fehler auftritt, gehen Sie folgendermaßen vor, um das Problem mit der Clusterregistrierung zu beheben. Nachdem Sie dieses Problem behoben haben, können Sie ein Upgrade des Administratorclusters ausführen.

Geben Sie govc an, die Befehlszeilenschnittstelle zu vSphere, einige Variablen, die Elemente Ihrer vCenter Server- und vSphere-Umgebung deklarieren.

Hinweis: Viele dieser Werte finden Sie in der Konfigurationsdatei für den Administratorcluster oder durch Anmeldung beim vCenter Server.
```
export GOVC_URL=https://VCENTER_SERVER_ADDRESS
export GOVC_USERNAME=VCENTER_SERVER_USERNAME
export GOVC_PASSWORD=VCENTER_SERVER_PASSWORD
export GOVC_DATASTORE=VSPHERE_DATASTORE
export GOVC_DATACENTER=VSPHERE_DATACENTER
export GOVC_INSECURE=true
# DATA_DISK_NAME should not include the suffix ".vmdk"
export DATA_DISK_NAME=DATA_DISK_NAME
```
Dabei gilt:
- VCENTER_SERVER_ADDRESS ist die IP-Adresse oder der Hostname Ihres vCenter Servers.
- VCENTER_SERVER_USERNAME ist der Nutzername eines Kontos, das die Administratorrolle oder gleichwertige Berechtigungen in vCenter Server hat.
- VCENTER_SERVER_PASSWORD ist das Passwort des vCenter Server-Kontos.
- VSPHERE_DATASTORE ist der Name des Datenspeichers, den Sie in Ihrer vSphere-Umgebung konfiguriert haben.
- VSPHERE_DATACENTER ist der Name des Rechenzentrums, das Sie in Ihrer vSphere-Umgebung konfiguriert haben.
- DATA_DISK_NAME ist der Name des Datenlaufwerks.

Laden Sie die DATA_DISK_NAME‑checkpoint.yaml Datei herunter.

govc datastore.download ${DATA_DISK_NAME}-checkpoint.yaml temp-checkpoint.yaml

Bearbeiten Sie die Prüfpunktfelder.

# Find out the gkeOnPremVersion
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system --no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster -n kube-system $ADMIN_CLUSTER_NAME -o=jsonpath='{.spec.gkeOnPremVersion}')

# Replace the gkeOnPremVersion in temp-checkpoint.yaml
sed -i "s/gkeonpremversion: \"\"/gkeonpremversion: \"$GKE_ON_PREM_VERSION\"/" temp-checkpoint.yaml

#The steps below are only needed for upgrading from 1.9x to 1.10x clusters.

# Find out the provider ID of the admin control-plane VM
ADMIN_CONTROL_PLANE_MACHINE_NAME=$(kubectl get machines --no-headers | grep master)
ADMIN_CONTROL_PLANE_PROVIDER_ID=$(kubectl get machines $ADMIN_CONTROL_PLANE_MACHINE_NAME -o=jsonpath='{.spec.providerID}' | sed 's/\//\\\//g')

# Fill in the providerID field in temp-checkpoint.yaml
sed -i "s/providerid: null/providerid: \"$ADMIN_CONTROL_PLANE_PROVIDER_ID\"/" temp-checkpoint.yaml

Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.

Generieren Sie eine neue Prüfsumme.
- Ändern Sie die letzte Zeile der Prüfpunktdatei in
```
checksum:$NEW_CHECKSUM
```
  Ersetzen Sie NEW_CHECKSUM durch die Ausgabe des folgenden Befehls:
```
sha256sum temp-checkpoint.yaml
```

Laden Sie die neue Prüfpunktdatei hoch.

govc datastore.upload temp-checkpoint.yaml ${DATA_DISK_NAME}-checkpoint.yaml

Die Verwendung des Anthos Identity Service kann dazu führen, dass der Connect Agent unvorhersehbar neu gestartet wird

Wenn Sie mithilfe der Anthos Identity Service-Funktion Anthos Identity Service ClientConfig verwalten, wird der Connect Agent möglicherweise unerwartet neu gestartet.

Wenn dieses Problem bei einem vorhandenen Cluster aufgetreten ist, können Sie einen der folgenden Schritte ausführen:

Deaktivieren Sie Anthos Identity Service (AIS). Wenn Sie AIS deaktivieren, wird die bereitgestellte AIS-Binärdatei nicht entfernt oder die AIS-ClientConfig entfernt. Führen Sie den folgenden Befehl aus, um AIS zu deaktivieren:
```
gcloud beta container hub identity-service disable --project PROJECT_NAME
```
Ersetzen Sie PROJECT_NAME durch den Namen des Flotten-Hostprojekts des Clusters.
Aktualisieren Sie den Cluster auf Version 1.9.3, 1.10.1 oder höher, um die Connect Agent-Version zu aktualisieren.

Hoher Netzwerkverkehr zu monitoring.googleapis.com

Möglicherweise sehen Sie auch in einem neuen Cluster ohne Nutzerarbeitslasten einen hohen Netzwerktraffic zu monitoring.googleapis.com.

Dieses Problem betrifft die Versionen 1.10.0-1.10.1 und 1.9.0-1.9.4. Dieses Problem wurde in den Versionen 1.10.2 und 1.9.5 behoben.

Führen Sie zur Problembehebung ein Upgrade auf Version 1.10.2/1.9.5 oder höher durch.

So beheben Sie das Problem bei einer früheren Version:

Skalieren Sie stackdriver-operator herunter:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   scale deployment stackdriver-operator --replicas=0
```
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Öffnen Sie die ConfigMap gke-metrics-agent-conf zum Bearbeiten:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit configmap gke-metrics-agent-conf

Erhöhen Sie das Prüfungsintervall von 0,1 Sekunden auf 13 Sekunden:

processors:
  disk_buffer/metrics:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-metrics
    probe_interval: 13s
    retention_size_mib: 6144
 disk_buffer/self:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-self
    probe_interval: 13s
    retention_size_mib: 200
  disk_buffer/uptime:
    backend_endpoint: https://monitoring.googleapis.com:443
    buffer_dir: /metrics-data/nsq-metrics-uptime
    probe_interval: 13s
    retention_size_mib: 200

Schließen Sie die Bearbeitungssitzung.

Ändern Sie die DaemonSet-Version von gke-metrics-agent in 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

Fehlende Messwerte auf einigen Knoten

Möglicherweise stellen Sie fest, dass die folgenden Messwerte auf einigen, aber nicht auf allen Knoten fehlen:

kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total

So beheben Sie das Problem:

[Version 1.9.5 und höher]: Erhöhen Sie die CPU für gke-metrics-agent durch die Schritte 1 bis 4.
[Version 1.9.0-1.9.4]: Folgen Sie den Schritten 1 bis 9

Öffnen Sie die Ressource stackdriver zum Bearbeiten:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver

Fügen Sie dem stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu, um die CPU-Anfrage für gke-metrics-agent von 10m auf 50m zu erhöhen:

spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Ihre bearbeitete Ressource sollte in etwa so aussehen:

spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

Speichern Sie die Änderungen und schließen Sie den Texteditor.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
```
Der Befehl sucht cpu: 50m, wenn Ihre Änderungen wirksam wurden.
Wenn Sie verhindern möchten, dass folgende Änderungen rückgängig gemacht werden, skalieren Sie stackdriver-operator herunter:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system scale deploy stackdriver-operator --replicas=0
```

Öffnen Sie gke-metrics-agent-conf zum Bearbeiten:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system edit configmap gke-metrics-agent-conf

Bearbeiten Sie die Konfiguration, um alle Instanzen von probe_interval: 0.1s in probe_interval: 13s zu ändern:

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Speichern Sie die Änderungen und schließen Sie den Texteditor.

Ändern Sie die DaemonSet-Version von gke-metrics-agent in 1.1.0-anthos.8:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \
   edit daemonset gke-metrics-agent

image: gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8 # use 1.1.0-anthos.8
imagePullPolicy: IfNotPresent
name: gke-metrics-agent

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.

„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

Bekannte Probleme

/var/log/audit/ Speicherplatz belegen

Kategorie

Erkannte Versionen

Symptome

Ursache

Problemumgehung

Administratorworkstation

Clusterknoten

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

Kategorie

Erkannte Versionen

Symptome

Ursache

Problemumgehung

Benutzerdefinierte ClientConfig-Ressource

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

Unterbrechung für Arbeitslasten mit PodDisauseBudgets

Knoten schließen ihren Upgradeprozess nicht ab

Die Installation des Nutzerclusters ist aufgrund eines Problems mit der Wahl des Cert-Manager/ca-injector in Anthos 1.9.0 fehlgeschlagen.

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

Verlängerungsprozess des Administratorclusterzertifikats

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

SSH-Verbindung durch Remote-Host geschlossen

Konflikt mit cert-manager beim Upgrade auf Version 1.9.0 oder 1.9.1

Konflikte während des Upgrades vermeiden

Eigenen Cert-Manager in Nutzerclustern wiederherstellen

Eigenen Cert-Manager in Administratorclustern wiederherstellen

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

Konflikte während des Upgrades vermeiden

Eigenen Cert-Manager in Nutzerclustern wiederherstellen

Eigenen Cert-Manager in Administratorclustern wiederherstellen

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

Fehlerhafte Konnektivitätsserver-Pods bei Verwendung von Seesaw- oder manuellem Load-Balancer

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

Load-Balancer und zustandsorientierte verteilte NSX-T-Firewallregeln interagieren unvorhersehbar

Fehler beim Registrieren des Administratorclusters während der Erstellung

Die Verwendung des Anthos Identity Service kann dazu führen, dass der Connect Agent unvorhersehbar neu gestartet wird

Hoher Netzwerkverkehr zu monitoring.googleapis.com

Fehlende Messwerte auf einigen Knoten

Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

„Gkectl diagnose“-Prüfung von Zertifikatfehlern

Konflikt mit `cert-manager` beim Upgrade auf Version 1.9.0 oder 1.9.1

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

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