Bekannte Probleme von Anthos-Cluster auf VMware

Auf dieser Seite werden alle bekannten Probleme für Anthos-Cluster auf VMware aufgeführt. Wählen Sie zum Filtern der bekannten Probleme nach einer Produktversion oder Kategorie die gewünschten Filter aus den folgenden Drop-down-Menüs aus.

Wählen Sie Ihre Version von Anthos-Cluster auf VMware aus:

Wählen Sie eine Problemkategorie aus:

Oder suchen Sie nach Ihrem Problem:

Kategorie Ermittelte Version(en) Problem und Problemumgehung
Netzwerk 1.10.0+, 1.11.0+, 1.12.0+, 1.13.0+, 1.14.0+, 1.15.0+

Seesaw-VM aufgrund von wenig Speicherplatz defekt

Wenn Sie Seesaw als Load-Balancer-Typ für Ihren Cluster verwenden und sehen, dass eine Seesaw-VM ausgefallen ist oder nicht startet, sehen Sie möglicherweise die folgende Fehlermeldung in der vSphere-Konsole:


    GRUB_FORCE_PARTUUID set, initrdless boot failed. Attempting with initrd

Dieser Fehler weist darauf hin, dass auf der VM nur wenig Speicherplatz verfügbar ist, weil der auf der Seesaw-VM ausgeführte Fluid-Bit nicht mit der richtigen Logrotation konfiguriert wurde.


Workaround:

Suchen Sie mit du -sh -- /var/lib/docker/containers/* | sort -rh die Protokolldateien, die den meisten Speicherplatz belegen. Bereinigen Sie die Logdatei mit der größten Größe und starten Sie die VM neu.

Hinweis:Wenn die VM nicht zugänglich ist, hängen Sie das Laufwerk an eine funktionierende VM an, z.B. die Administrator-Workstation, entfernen Sie die Datei von dem angehängten Laufwerk und fügen Sie es dann wieder der ursprünglichen Seesaw-VM hinzu.
Vorgang 1.13, 1.14.0–1.14.6, 1.15

Fehler beim öffentlichen SSH-Schlüssel nach Upgrade oder Aktualisierung des Administratorclusters

Wenn Sie ein Upgrade (gkectl upgrade admin) oder ein Update (gkectl update admin) eines Administratorclusters ohne Hochverfügbarkeit mit aktiviertem Prüfpunkt ausführen, können das Upgrade oder Update folgende Fehler verursachen: 


Checking admin cluster certificates...FAILURE
    Reason: 20 admin cluster certificates error(s).
Unhealthy Resources:
    AdminMaster clusterCA bundle: failed to get clusterCA bundle on admin master, command [ssh -o IdentitiesOnly=yes -i admin-ssh-key -o StrictHostKeyChecking=no -o ConnectTimeout=30 ubuntu@AdminMasterIP -- sudo cat /etc/kubernetes/pki/ca-bundle.crt] failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey).


failed to ssh AdminMasterIP, failed with error: exit status 255, stderr: Authorized uses only. All activity may be monitored and reported.
    ubuntu@AdminMasterIP: Permission denied (publickey)


error dialing ubuntu@AdminMasterIP: failed to establish an authenticated SSH connection: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey]...


Workaround:

Wenn kein Upgrade auf eine Patchversion von Anthos-Cluster auf VMware durchgeführt werden kann, wenden Sie sich an den Google-Support.
Upgrades 1.13.0–1.13.9, 1.14.0–1.14.6, 1.15.1–1.15.2

Das Upgrade eines Administratorclusters, der für die Anthos On-Prem API registriert ist, kann fehlschlagen

Wenn ein Administratorcluster in der Anthos On-Prem API registriert ist, kann ein Upgrade des Administratorclusters auf die betroffenen Versionen fehlschlagen, da die Flottenmitgliedschaft nicht aktualisiert werden konnte. Wenn dieser Fehler auftritt, wird beim Upgrade des Clusters der folgende Fehler angezeigt:


    failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.on_prem_cluster.resource_link: field cannot be updated

Ein Administratorcluster wird in der API registriert, wenn Sie den Cluster explizit registrieren oder wenn Sie einen Nutzercluster mit einem Anthos On-Prem API-Client upgraden.


Workaround:

Melden Sie den Administratorcluster ab: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und führen Sie das Upgrade des Administratorclusters aus. Es kann sein, dass der veraltete Fehler „Cluster konnte nicht registriert werden“ vorübergehend angezeigt wird. Nach einiger Zeit sollte er automatisch aktualisiert werden.
Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.4, 1.15.0

Wenn ein Administratorcluster in der Anthos On-Prem API registriert ist, wird die Annotation zu den Ressourcenlinks auf die benutzerdefinierte Ressource OnPremAdminCluster angewendet, die bei späteren Updates des Administratorclusters nicht verwendet wird, da der falsche Annotationsschlüssel verwendet wird. Dies kann dazu führen, dass der Administratorcluster versehentlich wieder bei der Anthos On-Prem API registriert wird.

Ein Administratorcluster wird in der API registriert, wenn Sie den Cluster explizit registrieren oder wenn Sie einen Nutzercluster mit einem Anthos On-Prem API-Client upgraden.


Workaround:

Melden Sie den Administratorcluster ab: 

    gcloud alpha container vmware admin-clusters unenroll ADMIN_CLUSTER_NAME --project CLUSTER_PROJECT --location=CLUSTER_LOCATION --allow-missing
und registrieren Sie den Administratorcluster noch einmal.
Netzwerk 1.15.0–1.15.2

CoreDNS orderPolicy wurde nicht erkannt

OrderPolicy wird nicht als Parameter erkannt und nicht verwendet. Anthos-Cluster auf VMware verwenden stattdessen immer Random.

Dieses Problem tritt auf, weil die CoreDNS-Vorlage nicht aktualisiert wurde und orderPolicy deshalb ignoriert wird.


Workaround:

Aktualisieren Sie die CoreDNS-Vorlage und wenden Sie den Fehler an. Dieses Problem wird bis zum Upgrade behoben.

  1. Bearbeiten Sie die Vorlage: 
    
kubectl edit cm -n kube-system coredns-template
    Ersetzen Sie den Inhalt der Vorlage durch Folgendes: 
    
coredns-template: |-
  .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
{{- if .PrivateGoogleAccess }}
    import zones/private.Corefile
{{- end }}
{{- if .RestrictedGoogleAccess }}
    import zones/restricted.Corefile
{{- end }}
    prometheus :9153
    forward . {{ .UpstreamNameservers }} {
      max_concurrent 1000
      {{- if ne .OrderPolicy "" }}
      policy {{ .OrderPolicy }}
      {{- end }}
    }
    cache 30
{{- if .DefaultDomainQueryLogging }}
    log
{{- end }}
    loop
    reload
    loadbalance
}{{ range $i, $stubdomain := .StubDomains }}
{{ $stubdomain.Domain }}:53 {
  errors
{{- if $stubdomain.QueryLogging }}
  log
{{- end }}
  cache 30
  forward . {{ $stubdomain.Nameservers }} {
    max_concurrent 1000
    {{- if ne $.OrderPolicy "" }}
    policy {{ $.OrderPolicy }}
    {{- end }}
  }
}
{{- end }}
Upgrades und Updates 1.10, 1.11, 1.12, 1.13.0–1.13.7, 1.14.0–1.14.3

OnPremAdminCluster-Status zwischen Prüfpunkt und tatsächlicher Antwort nicht einheitlich

Bestimmte Race-Bedingungen können dazu führen, dass der OnPremAdminCluster-Status zwischen dem Checkpoint und der tatsächlichen CR inkonsistent ist. Beim Aktualisieren des Administratorclusters kann nach dem Upgrade der folgende Fehler auftreten:


Exit with error:
E0321 10:20:53.515562  961695 console.go:93] Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Failed to update the admin cluster: OnPremAdminCluster "gke-admin-rj8jr" is in the middle of a create/upgrade ("" -> "1.15.0-gke.123"), which must be completed before it can be updated
Um das Problem zu umgehen, müssen Sie entweder den Checkpoint bearbeiten oder den Checkpoint für das Upgrade/Update deaktivieren. Wenden Sie sich an unser Supportteam, um mit der Problemumgehung fortzufahren.
Vorgang 1,13, 1,14, 1,15

Durch den Abgleich werden Administratorzertifikate auf Administratorclustern geändert

Anthos-Cluster auf VMware ändern die Administratorzertifikate auf den Steuerungsebenen der Administratorcluster bei jedem Abgleichsprozess, z. B. während eines Clusterupgrades. Dadurch erhöht sich die Wahrscheinlichkeit, dass ungültige Zertifikate für Ihren Administratorcluster abgerufen werden, insbesondere für Cluster der Version 1.15.

Wenn Sie von diesem Problem betroffen sind, können Probleme wie die folgenden auftreten:

  • Ungültige Zertifikate können zu folgenden Zeitüberschreitungen führen und Fehler zurückgeben:
    • gkectl create admin
    • gkectl upgrade amdin
    • gkectl update admin

    Diese Befehle können Autorisierungsfehler wie die folgenden zurückgeben:

    
Failed to reconcile admin cluster: unable to populate admin clients: failed to get admin controller runtime client: Unauthorized
  • Die kube-apiserver-Logs für Ihren Administratorcluster können folgende Fehler enthalten: 
    
Unable to authenticate the request" err="[x509: certificate has expired or is not yet valid...

Workaround:

Führen Sie ein Upgrade auf eine Version von Anthos-Cluster auf VMware aus. Falls ein Upgrade für Sie nicht möglich ist, wenden Sie sich an Cloud Customer Care, um das Problem zu beheben.
Netzwerk, Betrieb 1.10, 1.11, 1.12, 1.13, 1.14

Anthos Network Gateway-Komponenten, die entfernt wurden oder ausstehend sind, weil die Prioritätsklasse fehlt

Netzwerk-Gateway-Pods in kube-system können den Status Pending oder Evicted haben, wie in der folgenden verkürzten Beispielausgabe gezeigt:


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Diese Fehler weisen auf Bereinigungsereignisse oder auf die Unmöglichkeit hin, Pods aufgrund von Knotenressourcen zu planen. Da Anthos Network Gateway-Pods keine PriorityClass haben, haben sie dieselbe Standardpriorität wie andere Arbeitslasten. Wenn Knoten durch Ressourcen beschränkt sind, werden die Netzwerk-Gateway-Pods möglicherweise entfernt. Dieses Verhalten ist insbesondere für das ang-node-DaemonSet schlecht, da diese Pods auf einem bestimmten Knoten geplant werden können und nicht migriert werden können.


Workaround:

Führen Sie ein Upgrade auf Version 1.15 oder höher aus.

Als kurzfristige Lösung können Sie den Anthos Network Gateway-Komponenten manuell eine PriorityClass zuweisen. Der Controller für Anthos-Cluster auf VMware überschreibt diese manuellen Änderungen während eines Abgleichsprozesses, z. B. während eines Clusterupgrades.

  • Weisen Sie den Deployment-Controllern Cluster ang-controller-manager und autoscaler die Priorität system-cluster-critical zu.
  • Weisen Sie dem ang-daemon-Knoten-DaemonSet die Prioritätsklasse system-node-critical zu.
Upgrades und Updates 1.12, 1.13, 1.14, 1.15.0 bis 1.15.2

Das Upgrade des Administratorclusters schlägt nach der Registrierung des Clusters bei gcloud fehl

Nachdem Sie mit gcloud einen Administratorcluster mit nicht leeren gkeConnect-Bereich registriert haben, wird beim Upgrade des Clusters möglicherweise der folgende Fehler angezeigt:


failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Löschen Sie den Namespace gke-connect: 


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
Rufen Sie den Namen des Administratorclusters ab: 

kubectl get onpremadmincluster -n kube-system --kubeconfig=ADMIN_KUBECONFIG
Löschen Sie die Flottenmitgliedschaft: 

gcloud container fleet memberships delete ADMIN_CLUSTER_NAME
und führen Sie das Upgrade des Administratorclusters aus.
Vorgang 1.13.0–1.13.8, 1.14.0–1.14.5, 1.15.0–1.15.1

gkectl diagnose snapshot --log-since begrenzt das Zeitfenster für journalctl-Befehle, die auf den Clusterknoten ausgeführt werden, nicht

Dies wirkt sich nicht auf die Funktion des Erstellens eines Snapshots des Clusters aus, da der Snapshot weiterhin alle Logs enthält, die standardmäßig durch Ausführen von journalctl auf den Clusterknoten erfasst werden. Daher werden keine Debugging-Informationen verpasst.
Installation, Upgrades und Updates 1,9+, 1,10+, 1,11+, 1,12+

gkectl prepare windows Fehler

gkectl prepare windows kann Docker on Anthos-Cluster auf VMware-Versionen vor 1.13 nicht installieren, da MicrosoftDockerProvider verworfen wurde.


Workaround:

Die allgemeine Idee, dieses Problem zu umgehen, besteht darin, ein Upgrade auf Anthos-Cluster auf VMware 1.13 durchzuführen und den gkectl 1.13 zu verwenden, um eine Windows-VM-Vorlage und dann Windows-Knotenpools zu erstellen. Es gibt zwei Möglichkeiten, von Ihrer aktuellen Version zu Anthos-Cluster auf VMware 1.13 zu gelangen, wie unten dargestellt.

Hinweis: Wir können das Problem in Ihrer aktuellen Version beheben, ohne bis zur Version 1.13 ein Upgrade ausführen zu müssen. Allerdings sind weitere manuelle Schritte erforderlich. Wenden Sie sich an unser Supportteam, wenn Sie diese Option in Betracht ziehen.


Option 1:Blau/Grün-Upgrade

Sie können einen neuen Cluster mit Anthos-Cluster auf VMware 1.13 oder höher mit Windows-Knotenpools erstellen, Ihre Arbeitslasten zum neuen Cluster migrieren und dann den aktuellen Cluster entfernen. Es wird empfohlen, die neueste Nebenversion von Anthos zu verwenden.

Hinweis: Dies erfordert zusätzliche Ressourcen zum Bereitstellen des neuen Clusters, aber weniger Ausfallzeiten und Unterbrechungen für vorhandene Arbeitslasten.


Option 2: Löschen Sie Windows-Knotenpools und fügen Sie sie wieder hinzu, wenn Sie auf Anthos-Cluster auf VMware 1.13 upgraden.

Hinweis: Bei dieser Option können die Windows-Arbeitslasten erst ausgeführt werden, wenn der Cluster auf 1.13 aktualisiert wurde und die Windows-Knotenpools wieder hinzugefügt wurden.

  1. Löschen Sie vorhandene Windows-Knotenpools, indem Sie die Windows-Knotenpoolkonfiguration aus der Datei „user-cluster.yaml“ entfernen, und führen Sie dann den folgenden Befehl aus: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Führen Sie ein Upgrade des Upgrades für Linux-Administratoren und -Nutzer auf Version 1.12 aus. Entsprechende Informationen finden Sie im Leitfaden zum Upgrade für die entsprechende Nebenversion.
  3. Führen Sie diesen Schritt aus, bevor Sie ein Upgrade auf 1.13 ausführen. Achten Sie darauf, dass enableWindowsDataplaneV2: true in der Antwortvorlage OnPremUserCluster konfiguriert ist. Andernfalls verwendet der Cluster weiterhin Docker für Windows-Knotenpools, die nicht mit der neu erstellten Windows-VM-Vorlage mit 1.13 Plug-ins kompatibel sind, bei denen Docker nicht installiert ist. Wenn nicht konfiguriert oder auf „false“ festgelegt, aktualisieren Sie den Cluster so, dass er in der Datei „user-cluster.yaml“ auf „true“ gesetzt ist. Führen Sie dann den folgenden Befehl aus: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Führen Sie gemäß der Anleitung zum Upgrade für Linux-nur Administrator- und Nutzercluster ein Upgrade auf 1.13 aus.
  5. Bereiten Sie eine Windows-VM-Vorlage mit gkectl (1.13) vor: 
    
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Fügen Sie die Windows-Knotenpoolkonfiguration wieder zu „user-cluster.yaml“ hinzu, wobei das Feld OSImage auf die neu erstellte Windows-VM-Vorlage gesetzt wird.
  7. Cluster aktualisieren, um Windows-Knotenpools hinzuzufügen 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installation, Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

RootDistanceMaxSec-Konfiguration wird für ubuntu Knoten nicht wirksam

Anstelle der verbleibenden 20 Sekunden wird auf den Knoten der Standardwert von 5 Sekunden für RootDistanceMaxSec verwendet. Wenn Sie das Knoten-Startlog durch SSH in die VM prüfen, die sich unter „/var/log/Startup.log“ befindet, wird dort der folgende Fehler angezeigt:


+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

Bei Verwendung von RootDistanceMaxSec in 5 Sekunden kann die Systemuhr von dem NTP-Server abweichen, wenn der Drift der Uhr größer als 5 Sekunden ist.


Workaround:

Stellen Sie eine SSH-Verbindung zu den Knoten her und konfigurieren Sie RootDistanceMaxSec:


mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
Upgrades und Updates 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

gkectl update admin schlägt aufgrund eines leeren Felds osImageType fehl

Wenn Sie Version 1.13 von gkectl zum Aktualisieren eines Administratorclusters von Version 1.12 verwenden, wird möglicherweise der folgende Fehler angezeigt:


Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Wenn Sie gkectl update admin für Cluster der Version 1.13 oder 1.14 verwenden, wird in der Antwort möglicherweise die folgende Meldung angezeigt:


Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Wenn Sie sich das Log gkectl ansehen, stellen Sie möglicherweise fest, dass bei den vielen Änderungen osImageType auf einen leeren String in ubuntu_containerd festgelegt wird.

Diese Updatefehler sind auf einen fehlerhaften Backfill des Felds osImageType in der Konfiguration des Administratorclusters zurückzuführen, da es in Version 1.9 eingeführt wurde.


Workaround:

Führen Sie ein Upgrade auf eine Version von Anthos-Cluster auf VMware aus. Wenn ein Upgrade für Sie nicht möglich ist, wenden Sie sich an Cloud Customer Care, um dieses Problem zu beheben.
Installation, Sicherheit 1,13, 1,14, 1,15

SNI funktioniert nicht auf Nutzerclustern mit Steuerungsebene V2

Die Möglichkeit, ein zusätzliches Bereitstellungszertifikat für den Kubernetes API-Server eines Nutzerclusters mit authentication.sni bereitzustellen, funktioniert nicht, wenn die Steuerungsebene V2 aktiviert ist ( enableControlplaneV2: true).


Workaround:

Bis ein Anthos-Cluster auf VMware-Patch mit der Korrektur verfügbar ist, wenn Sie SNI verwenden müssen, deaktivieren Sie Steuerungsebene V2 (enableControlplaneV2: false).
Installation 1.0–1.11, 1.12, 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

$ im Nutzernamen der privaten Registry führt zum Fehler beim Start der Maschine für die Steuerungsebene des Administrators

Die Maschine der Administrator-Steuerungsebene kann nicht gestartet werden, wenn der Nutzername der privaten Registry $ enthält. Wenn Sie /var/log/startup.log auf dem Computer der Steuerungsebene prüfen, wird der folgende Fehler angezeigt: 


++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Workaround:

Verwenden Sie einen privaten Registry-Nutzernamen ohne $ oder eine Version von Anthos-Cluster auf VMware mit der Korrektur.
Upgrades und Updates 1.12.0–1.12.4

Falsch positive Warnungen zu nicht unterstützten Änderungen während der Aktualisierung des Administratorclusters

Wenn Sie Administratorcluster aktualisieren, werden die folgenden falsch positiven Warnungen im Log angezeigt und Sie können sie ignorieren. 


    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
Upgrades und Updates 1.13.0–1.13.9, 1.14.0–1.14.5, 1.15.0–1.15.1

Nutzercluster konnte nach der Rotation des KSA-Signaturschlüssels nicht aktualisiert werden

Nachdem Sie KSA-Signaturschlüssel rotiert haben und anschließend einen Nutzercluster aktualisieren, kann gkectl update die folgende Fehlermeldung zurückgeben: 


Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


Workaround:

Ändern Sie die Version Ihrer KSA-Signaturschlüssel wieder auf 1, behalten Sie jedoch die neuesten Schlüsselversionen bei:
  1. Prüfen Sie das Secret im Administratorcluster unter dem Namespace USER_CLUSTER_NAME und rufen Sie den Namen des Secrets „ksa-signing-key“ ab: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Kopieren Sie das Secret „ksa-signing-key“ und benennen Sie das kopierte Secret als „dienstkonto“: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Löschen Sie das vorherige Secret für ksa-signing-key: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Aktualisieren Sie das Feld data.data in der Configs für ksa-signing-key-rotation-stage auf '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Deaktivieren Sie den Validierungs-Webhook, um die Versionsinformationen in der benutzerdefinierten OnPremUserCluster-Ressource zu bearbeiten: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Aktualisieren Sie das Feld spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation in Ihrer benutzerdefinierten OnPremUserCluster-Ressource auf 1: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Warten Sie, bis der Zielnutzercluster bereit ist. Sie können den Status so prüfen: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Stellen Sie den Validierungs-Webhook für den Nutzercluster wieder her: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Vermeiden Sie eine weitere Rotation des KSA-Signaturschlüssels, bis der Cluster mit der Fehlerkorrektur auf die Version aktualisiert wird.
Vorgang 1.13.1+, 1.14, 1.15

Virtuelle F5 BIG-IP-Server werden nicht bereinigt, wenn Terraform Nutzercluster löscht.

Wenn Sie Terraform verwenden, um einen Nutzercluster mit einem F5 BIG-IP-Load-Balancer zu löschen, werden die virtuellen F5 BIG-IP-Server nach dem Cluster nicht entfernt.


Workaround:

Wenn Sie die F5-Ressourcen entfernen möchten, folgen Sie der Anleitung zum Bereinigen einer F5-Partition eines Nutzerclusters.
Installation, Upgrades und Updates 1.13.8, 1.14.4

Clustertyp ruft Container-Images aus docker.io ab

Wenn Sie einen Administratorcluster der Version 1.13.8 oder 1.14.4 erstellen oder einen Administratorcluster auf Version 1.13.8 oder 1.14.4 upgraden, ruft der Artcluster die folgenden Container-Images aus docker.io ab:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Wenn von Ihrer Administratorworkstation aus nicht auf docker.io zugegriffen werden kann, wird beim Erstellen oder Upgrade des Administratorclusters der Artcluster nicht angezeigt. Wenn Sie den folgenden Befehl auf der Administratorworkstation ausführen, werden die entsprechenden Container mit ErrImagePull angezeigt:

    
docker exec gkectl-control-plane kubectl get pods -A

    Die Antwort enthält Einträge wie den folgenden:

    
...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Diese Container-Images sollten im Art-Container-Image vorab geladen werden. In Typ 0.18.0 gibt es jedoch ein Problem mit den vorab geladenen Container-Images. Dies führt dazu, dass sie versehentlich aus dem Internet abgerufen werden.


    Workaround:

    Führen Sie auf der Administratorworkstation die folgenden Befehle aus, während der Administratorcluster noch nicht erstellt oder aktualisiert wurde:

    
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Vorgang 1.13.0–1.13.7, 1.14.0–1.14.4, 1.15.0

    Failover des Hochverfügbarkeits-Nutzerclusters und Administratorcluster der HA-Steuerungsebene, wenn das Netzwerk doppelte GARP-Anfragen herausfiltert

    Wenn Ihre Cluster-VMs mit einem Switch verbunden sind, der doppelte GARP-Anfragen (Griduitous ARP) filtert, kann die Keepalive-Leader-Wahl auf eine Race-Bedingung stoßen, wodurch einige Knoten falsche ARP-Tabelleneinträge haben.

    Die betroffenen Knoten können die virtuelle IP-Adresse der Steuerungsebene ping, aber eine TCP-Verbindung zur virtuellen IP-Adresse der Steuerungsebene kann zu einer Zeitüberschreitung führen.


    Workaround:

    Führen Sie den folgenden Befehl auf jedem Knoten der Steuerungsebene des betroffenen Clusters aus: 
    
    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrades und Updates 1.13.0–1.13.7, 1.14.0–1.14.4, 1.15.0

    vsphere-csi-controller muss nach der Rotation des vCenter-Zertifikats neu gestartet werden

    vsphere-csi-controller sollte sein vCenter-Secret nach der Rotation des vCenter-Zertifikats aktualisieren. Die Pods von vsphere-csi-controller werden vom aktuellen System jedoch nicht neu gestartet, sodass vsphere-csi-controller nach der Rotation abstürzt.

    Workaround:

    Folgen Sie der Anleitung für Cluster, die mit Version 1.13 oder höher erstellt wurden, neu, um vsphere-csi-controller neu zu starten 

    
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Installation 1.10.3–1.10.7, 1.11, 1.12, 1.13.0–1.13.1

    Das Erstellen des Administratorclusters schlägt fehl, wenn Clusterregistrierung Fehler auftreten

    Selbst wenn die Clusterregistrierung während der Erstellung des Administratorclusters fehlschlägt, schlägt der Befehl gkectl create admin nicht bei dem Fehler fehl und wird möglicherweise erfolgreich sein. Mit anderen Worten: Die Erstellung des Administratorclusters war erfolgreich, ohne bei einer Flotte registriert zu sein.

    Zur Erkennung des Symptoms suchen Sie im Log von „gkectl create admin“ nach den folgenden Fehlermeldungen: 
    
Failed to register admin cluster

    Sie können auch prüfen, ob der Cluster in der Cloud Console unter registrierten Clustern zu finden ist.

    Workaround:

    Wenn ein Cluster nach Version 1.12 erstellt wurde, folgen Sie der Anleitung zum Versuchen der Administratorcluster-Registrierung nach dem Erstellen des Clusters. Für Cluster, die in früheren Versionen erstellt wurden,

    1. Hängen Sie ein Schlüssel/Wert-Paar wie „foo: bar“ an Ihre SA-Schlüsseldatei an.
    2. Führen Sie gkectl update admin aus, um den Administratorcluster noch einmal zu registrieren.

    Upgrades und Updates 1.10, 1.11, 1.12, 1.13.0–1.13.1

    Die erneute Registrierung des Administratorclusters kann beim Upgrade des Administratorclusters übersprungen werden

    Wenn das Upgrade des Administratorcluster-Clusters aufgrund einer Zeitüberschreitung abläuft, wird der Administratorcluster nicht noch einmal mit der aktualisierten Connect Agent-Version registriert.


    Workaround:

    Prüfen Sie, ob der Cluster unter registrierten Clustern angezeigt wird. Optional: Melden Sie sich im Cluster an, nachdem Sie die Authentifizierung eingerichtet haben. Wenn der Cluster noch registriert ist, können Sie die folgende Anleitung überspringen, um die Registrierung zu wiederholen. Wenn ein Cluster auf Version 1.12 oder höher aktualisiert wurde, folgen Sie nach der Erstellung des Clusters der Anleitung zum Versuchen der Administratorcluster-Registrierung. Bei Clustern, die auf ältere Versionen aktualisiert wurden, gilt:
    1. Hängen Sie ein Schlüssel/Wert-Paar wie „foo: bar“ an Ihre SA-Schlüsseldatei an.
    2. Führen Sie gkectl update admin aus, um den Administratorcluster noch einmal zu registrieren.

    Konfiguration 1.15.0

    Falsche Fehlermeldung zu vCenter.dataDisk

    Bei einem Hochverfügbarkeits-Administratorcluster zeigt gkectl prepare diese falsche Fehlermeldung an:

    
vCenter.dataDisk must be present in the AdminCluster spec

    Workaround:

    In diesem Fall können Sie diese Fehlermeldung ignorieren.
    VMware 1.15.0

    Knotenpool kann aufgrund redundanter Regeln für VM-Host-Affinitäten nicht erstellt werden

    Beim Erstellen eines Knotenpools, der eine VM-Host-Affinität verwendet, kann eine Race-Bedingung dazu führen, dass mehrere VM-Host-Affinitätsregeln mit demselben Namen erstellt werden. Dies kann dazu führen, dass der Knotenpool nicht erstellt werden kann.


    Workaround:

    Entfernen Sie die alten redundanten Regeln, damit der Knotenpool erstellt werden kann. Diese Regeln haben den Namen [USER_CLUSTER_NAME]–[HASH].
    Vorgang 1.15.0

    gkectl repair admin-master kann aufgrund von failed to delete the admin master node object and reboot the admin master VM fehlschlagen

    Der Befehl gkectl repair admin-master kann aufgrund einer Race-Bedingung mit dem folgenden Fehler fehlschlagen. 

    
Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Workaround:

    Dieser Befehl ist idempotent. Er kann bis zum erfolgreichen Ausführen des Befehls sicher noch einmal ausgeführt werden.
    Upgrades und Updates 1.15.0

    Pods bleiben im Status „Nicht bestanden“ nach einer Neuerstellung oder Aktualisierung eines Knotens der Steuerungsebene

    Nachdem Sie den Knoten einer Steuerungsebene neu erstellt oder aktualisiert haben, können aufgrund des Ausfalls des NodeAffinitätsprädikats bestimmte Pods im Status Failed verbleiben. Diese fehlgeschlagenen Pods haben keine Auswirkungen auf den normalen Clusterbetrieb oder den Systemzustand.


    Workaround:

    Sie können die fehlgeschlagenen Pods ignorieren oder manuell löschen.
    Sicherheit, Konfiguration 1.15

    OnPremUserCluster nicht bereit aufgrund von Anmeldedaten der privaten Registry

    Wenn Sie vorbereitete Anmeldedaten und eine private Registry verwenden, aber keine vorbereiteten Anmeldedaten für Ihre private Registry konfiguriert haben, ist der OnPremUserCluster möglicherweise nicht bereit und es wird möglicherweise die folgende Fehlermeldung angezeigt: 

    
failed to check secret reference for private registry …


    Workaround:

    Bereiten Sie die Anmeldedaten der privaten Registry für den Nutzercluster gemäß der Anleitung unter Vorbereitete Anmeldedaten konfigurieren vor.

    Upgrades und Updates 1.15.0

    gkectl upgrade admin schlägt mit StorageClass standard sets the parameter diskformat which is invalid for CSI Migration fehl

    Bei gkectl upgrade admin prüft die Preflight-Speicherprüfung für CSI-Migration, ob die StorageClasses keine Parameter haben, die nach der CSI-Migration ignoriert werden. Wenn z. B. eine BidRequest mit dem Parameter diskformat vorhanden ist, meldet gkectl upgrade admin die kubeconfig und meldet einen Fehler in der Preflight-Validierung. In Anthos 1.10 und früheren Versionen erstellte Administratorcluster haben eine Namespace mit diskformat: thin. Diese bestehen diese Validierung nicht, sie funktioniert jedoch nach der CSI-Migration noch gut. Diese Fehler sollten stattdessen als Warnungen interpretiert werden.

    Weitere Informationen finden Sie im Abschnitt zu dem BidRequest-Parameter unter In-Tree vSphere-Volumes zum vSphere-Container Storage-Plug-in migrieren.


    Workaround:

    Nachdem Sie bestätigt haben, dass der Cluster eine kubeconfig mit Parametern ignoriert, nachdem die CSI-Migration gkectl upgrade admin mit dem Flag --skip-validation-cluster-health ausgeführt wurde
    Speicher 1.15

    Migrierte integrierte vSphere-Volumes mithilfe des Windows-Dateisystems können nicht mit vSphere CSI-Treiber verwendet werden

    Unter bestimmten Bedingungen können Laufwerke als schreibgeschützt an Windows-Knoten angehängt werden. Das entsprechende Volume ist innerhalb eines Pods schreibgeschützt. Dieses Problem tritt eher auf, wenn ein neuer Satz von Knoten einen alten Satz von Knoten ersetzt (z. B. Cluster-Upgrade oder Knotenpoolaktualisierung). Zustandsorientierte Arbeitslasten, die zuvor gut funktioniert haben, können möglicherweise nicht auf ihre neuen Volumes auf den neuen Knoten schreiben.


    Workaround:

    1. Rufen Sie die UID des Pods ab, die nicht in sein Volume schreiben kann: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Verwenden Sie den PersistentVolumeClaim, um den Namen des PersistentVolume zu erhalten: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Bestimmen Sie den Namen des Knotens, auf dem der Pod ausgeführt wird: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Rufen Sie PowerShell-Zugriff auf den Knoten ab, entweder über SSH oder die vSphere-Weboberfläche.
    5. Legen Sie Umgebungsvariablen fest: 
      
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Ermitteln Sie die Laufwerksnummer für das Laufwerk, das mit dem PersistentVolume verknüpft ist: 
      
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Prüfen Sie, ob das Laufwerk readonly ist: 
      
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Das Ergebnis sollte True sein.
    8. Setzen Sie readonly auf false. 
      
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Löschen Sie den Pod, damit er neu gestartet wird: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Der Pod sollte auf demselben Knoten geplant werden. Wenn der Pod jedoch auf einem neuen Knoten geplant wird, müssen Sie möglicherweise die vorherigen Schritte auf dem neuen Knoten wiederholen.

    Upgrades und Updates 1.12, 1.13.0–1.13.7, 1.14.0–1.14.4

    vsphere-csi-secret wird nach dem gkectl update credentials vsphere --admin-cluster nicht aktualisiert

    Wenn Sie die vSphere-Anmeldedaten für einen Administratorcluster nach dem Aktualisieren von Clusteranmeldedaten aktualisieren, wird für vsphere-csi-secret im Namespace kube-system möglicherweise die alten Anmeldedaten verwendet.


    Workaround:

    1. Rufen Sie den Secret-Namen vsphere-csi-secret ab: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aktualisieren Sie die Daten des vsphere-csi-secret-Secrets, das Sie im obigen Schritt erhalten haben: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. Starten Sie vsphere-csi-controller neu: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Sie können den Roll-out-Status mit Folgendem verfolgen: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Nachdem das Deployment erfolgreich eingeführt wurde, sollte der Controller vsphere-csi-secret verwenden.
    Upgrades und Updates 1.10, 1.11, 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

    audit-proxy-Absturzschleife beim Aktivieren von Cloud-Audit-Logs mit gkectl update cluster

    audit-proxy kann aufgrund leeren --cluster-name zu Abstürzen führen. Dieses Verhalten wird durch einen Fehler in der Aktualisierungslogik verursacht, bei dem der Clustername nicht an den Audit-Proxy-Pod / das Containermanifest weitergegeben wird.


    Workaround:

    Stellen Sie bei einem Nutzercluster der Steuerungsebene mit enableControlplaneV2: true eine Verbindung zur Maschine der Nutzersteuerungsebene über SSH her und aktualisieren Sie /etc/kubernetes/manifests/audit-proxy.yaml mit --cluster_name=USER_CLUSTER_NAME.

    Bearbeiten Sie für einen Nutzercluster der Steuerungsebene v1 den audit-proxy-Container im kube-apiserver-Zusatzsatz, um --cluster_name=USER_CLUSTER_NAME hinzuzufügen:

    
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrades und Updates 1.11, 1.12, 1.13.0–1.13.5, 1.14.0–1.14.1

    Zusätzliche Bereitstellung einer zusätzlichen Steuerungsebene direkt nach gkectl upgrade cluster

    Direkt nach gkectl upgrade cluster werden die Pods der Steuerungsebene möglicherweise noch einmal bereitgestellt. Der Clusterstatus von gkectl list clusters ändert sich von RUNNING zu RECONCILING. Bei Anfragen an den Nutzercluster kann es zu einer Zeitüberschreitung kommen.

    Dieses Verhalten ist darauf zurückzuführen, dass das Zertifikat der Steuerungsebene automatisch nach gkectl upgrade cluster rotiert wird.

    Dieses Problem tritt nur bei Nutzerclustern auf, die KEINE Steuerungsebene v2 verwenden.


    Workaround:

    Warten Sie, bis sich der Clusterstatus in gkectl list clusters wieder zu RUNNING geändert hat, oder führen Sie ein Upgrade auf Versionen mit der folgenden Fehlerbehebung durch: 1.13.6+, 1.14.2+ oder 1.15+.
    Upgrades und Updates 1.12.7

    Fehlerhafte Release 1.12.7-gke.19 wurde entfernt

    Anthos-Cluster auf VMware 1.12.7-gke.19 ist ein fehlerhafter Release und Sie sollten ihn nicht verwenden. Die Artefakte wurden aus dem Cloud Storage-Bucket entfernt.

    Workaround:

    Verwenden Sie stattdessen den Release 1.12.7-gke.20.
    Upgrades und Updates 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    gke-connect-agent verwendet weiterhin das ältere Image, nachdem die Registrierungsanmeldedaten aktualisiert wurden

    Sie können die Registrierungsanmeldedaten mit einer der folgenden Methoden aktualisieren:

    • gkectl update credentials componentaccess, wenn keine private Registry verwendet wird
    • gkectl update credentials privateregistry, wenn die private Registry verwendet wird

    Es kann vorkommen, dass gke-connect-agent weiterhin das ältere Image verwendet oder die gke-connect-agent-Pods aufgrund ImagePullBackOff nicht abgerufen werden können.

    Dieses Problem wird in Anthos-Cluster auf VMware-Releases 1.13.8, 1.14.4 und nachfolgenden Releases behoben.


    Workaround:

    Option 1: gke-connect-agent manuell noch einmal bereitstellen:

    1. Löschen Sie den Namespace gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Stellen Sie gke-connect-agent noch einmal mit dem ursprünglichen Dienstkontoschlüssel für die Registrierung bereit. Sie müssen den Schlüssel nicht aktualisieren:

      Für Administratorcluster: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Für Nutzercluster: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Option 2: Sie können die Daten des Image-Pull-Secrets regcred, das von der gke-connect-agent-Bereitstellung verwendet wird, manuell ändern:

    
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Option 3: Sie können das Standard-Image-Abruf-Secret für Ihren Cluster im gke-connect-agent-Deployment so hinzufügen:

    1. Kopieren Sie das Standard-Secret in den Namespace gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Rufen Sie den Bereitstellungsnamen gke-connect-agent ab: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Fügen Sie das Standard-Secret zur gke-connect-agent-Bereitstellung hinzu: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Installation 1,13, 1,14

    Manuelle Konfiguration der LB-Konfiguration fehlgeschlagen

    Wenn Sie die Konfiguration überprüfen, bevor Sie einen Cluster mit manuellem Load-Balancer erstellen, indem Sie gkectl check-config ausführen, schlägt der Befehl mit den folgenden Fehlermeldungen fehl.

    
 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

    Workaround:

    Option 1: Sie können die Patchversion 1.13.7 und 1.14.4 verwenden, die die Fehlerkorrektur enthält.

    Option 2: Sie können auch denselben Befehl ausführen, um die Konfiguration zu validieren, aber die Load-Balancer-Validierung überspringen.

    
gkectl check-config --skip-validation-load-balancer
    Vorgang 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 und 1.14

    etcd Watch Hunger

    Bei Clustern mit der etcd-Version 3.4.13 oder niedriger können Watch-Wartungsaufgaben und nicht betriebsbereite Ressourcen-Smartwatches ausgesetzt sein, was zu folgenden Problemen führen kann:

    • Pod-Planung ist unterbrochen
    • Knoten können nicht registriert werden
    • Kubelet berücksichtigt keine Pod-Änderungen

    Diese Probleme können dazu führen, dass der Cluster nicht mehr funktioniert.

    Dieses Problem wurde in Anthos-Cluster auf VMware behoben, die in den Versionen 1.12.7, 1.13.6, 1.14.3 und den nachfolgenden Releases enthalten sind. Diese neueren Versionen verwenden die etcd-Version 3.4.21. Alle vorherigen Versionen von Anthos-Cluster auf VMware sind von diesem Problem betroffen.

    Problemumgehung

    Wenn Sie das Upgrade nicht sofort ausführen können, verringern Sie das Risiko eines Clusterfehlers, indem Sie die Anzahl der Knoten im Cluster reduzieren. Entfernen Sie Knoten, bis der Messwert etcd_network_client_grpc_sent_bytes_total unter 300 Mbit/s liegt.

    So rufen Sie diesen Messwert im Metrics Explorer auf:

    1. Rufen Sie in der Google Cloud Console den Metrics Explorer auf:

      Zum Metrics Explorer

    2. Wählen Sie den Tab Konfiguration aus.
    3. Maximieren Sie Messwert auswählen, geben Sie Kubernetes Container in die Filterleiste ein und wählen Sie den Messwert dann in den Untermenüs aus:
      1. Wählen Sie im Menü Aktive Ressourcen die Option Kubernetes-Container aus.
      2. Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
      3. Wählen Sie im Menü Aktive Messwerte die Option etcd_network_client_grpc_sent_bytes_total aus.
      4. Klicken Sie auf „Übernehmen“.
    Upgrades und Updates 1.10, 1.11, 1.12, 1.13 und 1.14

    Anthos Identity Service kann Latenzen auf Steuerungsebene verursachen

    Bei Neustarts oder Upgrades von Clustern kann der Anthos Identity-Dienst mit Traffic überlastet werden, der aus abgelaufenen JWT-Tokens besteht, die von kube-apiserver über den Authentifizierungs-Webhook an Anthos Identity Service weitergeleitet werden. Auch wenn Anthos Identity Service nicht in eine Absturzschleife wechselt, reagiert er nicht mehr und stellt keine weiteren Anfragen mehr bereit. Dieses Problem kann schließlich zu höheren Latenzen auf der Steuerungsebene führen.

    Dieses Problem ist in den folgenden Anthos-Cluster auf VMware-Releases behoben:

    • 1.12.6 oder höher
    • 1.13.6+
    • 1.14.2 oder höher

    Führen Sie die folgenden Schritte aus, um zu ermitteln, ob Sie von diesem Problem betroffen sind:

    1. Prüfen Sie, ob der Endpunkt des Anthos Identity-Dienstes extern erreichbar ist: 
      
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Ersetzen Sie CLUSTER_ENDPOINT durch die virtuelle IP-Adresse der Steuerungsebene und den Load-Balancer-Port der Steuerungsebene für Ihren Cluster (z. B. 172.16.20.50:443).

      Wenn Sie von diesem Problem betroffen sind, gibt der Befehl den Statuscode 400 zurück. Wenn das Zeitlimit für die Anfrage überschritten wird, starten Sie den Pod ais neu und führen Sie den Befehl curl noch einmal aus, um das Problem zu beheben. Wenn Sie den Statuscode 000 erhalten, wurde das Problem behoben und der Vorgang ist abgeschlossen. Wenn Sie weiterhin den Statuscode 400 erhalten, wird der HTTP-Server des Anthos Identity-Dienstes nicht gestartet. Fahren Sie in diesem Fall fort.

    2. Prüfen Sie die Logs von Anthos Identity und kube-apiserver:
      1. Prüfen Sie das Anthos Identity Service-Log: 
        
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Wenn das Protokoll einen Eintrag wie den folgenden enthält, sind Sie von diesem Problem betroffen:

        
I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Prüfen Sie die kube-apiserver-Logs für Ihre Cluster:

        In den folgenden Befehlen ist KUBE_APISERVER_POD der Name des kube-apiserver-Pods im angegebenen Cluster.

        Administratorcluster:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Nutzercluster:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Wenn die Logs von kube-apiserver Einträge wie den folgenden enthalten, sind Sie von diesem Problem betroffen:

        
E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Problemumgehung

    Wenn Sie Ihre Cluster nicht sofort upgraden können, um das Problem zu beheben, können Sie die betroffenen Pods als Problemumgehung identifizieren und neu starten:

    1. Erhöhen Sie die Ausführlichkeitsstufe des Anthos Identity-Dienstes auf 9: 
      
kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Prüfen Sie das Anthos Identity Service-Log auf den ungültigen Token-Kontext: 
      
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Damit Sie die Tokennutzlast, die mit jedem ungültigen Tokenkontext verknüpft ist, abrufen können, parsen Sie jedes zugehörige Dienstkonto-Secret mit dem folgenden Befehl: 
      
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Kopieren Sie das Token in den Debugger unter jwt.io, um das Token zu decodieren und den Namen und den Namespace des Quell-Pods aufzurufen.
    5. Starten Sie die Pods, die anhand der Tokens identifiziert wurden, neu.
    Vorgang 1,8, 1,9, 1,10

    Problem mit dem Speicherbedarf der etcd-Wartungs-Pods

    Die etcd-Wartungs-Pods, die das Image etcddefrag:gke_master_etcddefrag_20210211.00_p0 verwenden, sind betroffen. Der Container „etcddefrag“ öffnet während jedes Defragzyklus eine neue Verbindung zum etcd-Server und die alten Verbindungen werden nicht bereinigt.


    Workaround:

    Option 1: Führen Sie ein Upgrade auf die neueste Patchversion von 1.8 auf 1.11 aus, die den Fehler enthält.

    Option 2: Wenn Sie eine Patchversion vor 1.9.6 und 1.10.3 verwenden, müssen Sie den etcd-Wartungs-Pod für den Administrator- und Nutzercluster herunterskalieren:

    
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Vorgang 1,9, 1,10, 1,11, 1,12, 1,13

    Fehlende Systemdiagnosen von Pods der Steuerungsebene des Nutzerclusters

    Sowohl der Cluster-Systemdiagnose-Controller als auch der gkectl diagnose cluster-Befehl führen eine Reihe von Systemdiagnosen durch, einschließlich der Pod-Systemdiagnosen für Namespaces. Sie überspringen jedoch versehentlich die Pods der Steuerungsebene des Nutzers. Wenn Sie den Modus „v2“ der Steuerungsebene verwenden, hat dies keine Auswirkungen auf Ihren Cluster.


    Workaround:

    Dies hat keine Auswirkungen auf die Arbeitslast- oder Clusterverwaltung. Wenn Sie den Zustand Ihrer Pods der Steuerungsebene prüfen möchten, können Sie die folgenden Befehle ausführen:

    
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Upgrades und Updates 1,6+, 1,7+

    1.6- und 1.7-Administratorclusterupgrades können von der Weiterleitung k8s.gcr.io -> registry.k8s.io betroffen sein

    Kubernetes hat den Traffic vom 20.03.2023 von k8s.gcr.io zu registry.k8s.io weitergeleitet. In Anthos-Cluster auf VMware 1.6.x und 1.7.x verwenden die Administratorcluster-Upgrades das Container-Image k8s.gcr.io/pause:3.2. Wenn Sie einen Proxy für Ihre Administratorworkstation verwenden und der Proxy registry.k8s.io nicht zulässt und das Container-Image k8s.gcr.io/pause:3.2 nicht lokal im Cache gespeichert wird, schlagen die Upgrades des Administratorclusters fehl, wenn das Container-Image abgerufen wird.


    Workaround:

    Fügen Sie registry.k8s.io zur Zulassungsliste des Proxys für Ihre Administratorworkstation hinzu.
    Netzwerk 1.10, 1.11, 1.12.0–1.12.6, 1.13.0–1.13.6, 1.14.0–1.14.2

    Seesaw-Validierung beim Erstellen des Load-Balancers

    gkectl create loadbalancer schlägt mit der folgenden Fehlermeldung fehl:

    
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Dies liegt daran, dass die Seesaw-Gruppendatei bereits vorhanden ist. Mit der Preflight-Prüfung wird versucht, einen nicht vorhandenen Seesaw-Load-Balancer zu validieren.

    Workaround:

    Entfernen Sie die vorhandene Seesaw-Gruppendatei für diesen Cluster. Der Dateiname ist seesaw-for-gke-admin.yaml für den Administratorcluster und seesaw-for-{CLUSTER_NAME}.yaml für einen Nutzercluster.
    Netzwerk 1.14

    Zeitüberschreitungen in der Anwendung bei Fehlern beim Zusammenführen der Tabellen

    Anthos-Cluster auf VMware-Version 1.14 ist bei Fehlgeschlagenen der Tabelleneinfügung (Conntrack) der Tabelleneinfügung anfällig, wenn Sie Ubuntu- oder COS-Betriebssystem-Images verwenden. Fehlgeschlagene Bereitstellung führt zu zufälligen Anwendungszeitüberschreitungen und kann selbst auftreten, wenn die Conntrack-Tabelle Platz für neue Einträge bietet. Die Fehler werden durch Änderungen im Kernel 5.15 und höher verursacht, durch die Tabellenbereitstellungen basierend auf der Kettenlänge eingeschränkt werden.

    Wenn Sie wissen möchten, ob Sie von diesem Problem betroffen sind, können Sie mit dem folgenden Befehl die Systemstatistiken für das Verbindungs-Tracking in jedem Knoten prüfen:

    
sudo conntrack -S

    Die Antwort sieht so aus:

    
cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

    Wenn ein chaintoolong-Wert in der Antwort eine Zahl ungleich null ist, sind Sie von diesem Problem betroffen.

    Problemumgehung

    Die vorläufige Risikominderung besteht darin, die Größe der Netfiler-Hash-Tabelle (nf_conntrack_buckets) und der Netfilter-Verbindungs-Tracking-Tabelle (nf_conntrack_max) zu erhöhen. Verwenden Sie die folgenden Befehle auf jedem Clusterknoten, um die Größe der Tabellen zu erhöhen:

    
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    Ersetzen Sie TABLE_SIZE durch eine neue Größe in Byte. Der Standardwert für die Tabellengröße ist 262144. Wir empfehlen, einen Wert festzulegen, der der 65.536-fachen Anzahl der Kerne auf dem Knoten entspricht. Wenn Ihr Knoten beispielsweise acht Kerne hat, legen Sie die Tabellengröße auf 524288 fest.
    Netzwerk 1.13.0–1.13.2

    Calic-Typha oder anetd-Operator Absturzschleife auf Windows-Knoten mit Steuerungsebene 2

    Mit Steuerungsebene v2 oder einem neuen Installationsmodell können calico-typha oder anetd-operator auf Windows-Knoten geplant werden und in eine Absturzschleife gelangen.

    Der Grund dafür ist, dass die beiden Bereitstellungen alle Markierungen tolerieren, einschließlich der Windows-Knotenmarkierung.


    Workaround:

    Führen Sie entweder ein Upgrade auf 1.13.3+ aus oder führen Sie die folgenden Befehle aus, um das Deployment „calico-typha“ oder „anetd-operator“ zu bearbeiten:

    
    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Entferne das folgende spec.template.spec.tolerations:

    
    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    Fügen Sie außerdem die folgende Toleranz hinzu:

    
    - key: node-role.kubernetes.io/master
      operator: Exists
    Konfiguration 1.14.0–1.14.2

    Die Datei mit den Anmeldedaten des privaten Nutzerclusters kann nicht geladen werden

    Sie können möglicherweise keinen Nutzercluster erstellen, wenn Sie den Abschnitt privateRegistry mit den Anmeldedaten fileRef angeben. Preflight kann mit der folgenden Meldung fehlschlagen: 

    
[FAILURE] Docker registry access: Failed to login.


    Workaround:

    • Wenn Sie das Feld nicht angeben möchten oder dieselben Anmeldedaten für die private Registry wie den Administratorcluster verwenden möchten, können Sie den Abschnitt privateRegistry in der Konfigurationsdatei des Nutzerclusters einfach entfernen oder kommentieren.
    • Wenn Sie für Ihren Nutzercluster bestimmte Anmeldedaten für eine private Registry verwenden möchten, können Sie den Abschnitt privateRegistry vorübergehend so angeben: 
      
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      (HINWEIS: Dies ist nur eine vorübergehende Lösung. Diese Felder wurden bereits eingestellt. Daher sollten Sie die Datei mit den Anmeldedaten beim Upgrade auf Version 1.14.3 oder höher verwenden.)

    Operations 1.10+

    Anthos Service Mesh und andere Service Meshes sind nicht mit Dataplane v2 kompatibel

    Dataplane V2 übernimmt das Load-Balancing und erstellt einen Kernel-Socket anstelle eines paketbasierten DNAT. Dies bedeutet, dass Anthos Service Mesh keine Paketprüfung durchführen kann, da der Pod umgangen wird und niemals IPTables verwendet.

    Dies wird im kube-proxy-freien Modus durch Verbindungsunterbrechung oder falsches Traffic-Routing für Dienste mit Anthos Service Mesh verursacht, da die Sidecar-Datei keine Paketprüfung durchführen kann.

    Dieses Problem tritt in allen Versionen von Anthos-Clustern auf Bare Metal 1.10 auf. Einige neuere Versionen von 1.10 (1.10.2+) haben jedoch eine Problemumgehung.


    Workaround:

    Führen Sie entweder ein Upgrade auf 1.11 aus, um vollständige Kompatibilität zu gewährleisten, oder, wenn Sie 1.10.2 oder höher verwenden, folgenden Befehl:

    
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Fügen Sie bpf-lb-sock-hostns-only: true der „configmap“ hinzu und starten Sie dann den netnet-Daemon neu:

    
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Speicher 1.12 oder höher, 1.13.3

    kube-controller-manager kann nichtflüchtige Volumes nach 6 Minuten stark trennen.

    kube-controller-manager kann zu einer Zeitüberschreitung führen, wenn PV/PVCs nach 6 Minuten getrennt werden, und diese manuell erzwingen. Detaillierte Logs aus kube-controller-manager zeigen Ereignisse ähnlich dem folgenden an:

    
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Melden Sie sich zum Prüfen des Problems im Knoten an und führen Sie die folgenden Befehle aus:

    
# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Im kubelet-Log werden Fehler wie die folgenden angezeigt:

    
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Workaround:

    Stellen Sie eine SSH-Verbindung zum betroffenen Knoten her und starten Sie den Knoten neu.
    Upgrades und Updates 1,12+, 1,13+, 1,14+

    Clusterupgrade bleibt hängen, wenn ein CSI-Treiber von einem Drittanbieter verwendet wird

    Wenn Sie einen CSI-Treiber eines Drittanbieters verwenden, können Sie einen Cluster möglicherweise nicht upgraden. Der Befehl gkectl cluster diagnose gibt möglicherweise den folgenden Fehler zurück: 

    
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Workaround:

    Führen Sie das Upgrade mit der Option --skip-validation-all durch.
    Vorgang 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master erstellt die Administrator-Master-VM, ohne die VM-Hardwareversion zu aktualisieren

    Der über gkectl repair admin-master erstellte Administrator-Masterknoten verwendet möglicherweise eine niedrigere VM-Hardwareversion als erwartet. Wenn das Problem auftritt, wird der Fehler im Bericht gkectl diagnose cluster angezeigt. 

    
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Workaround:

    Fahren Sie den Administrator-Masterknoten herunter. Führen Sie dann https://kb.vmware.com/s/article/1003746 aus, um den Knoten auf die erwartete Version zu aktualisieren, die in der Fehlermeldung beschrieben wird, und starten Sie dann den Knoten.
    Betriebssystem 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+

    VM gibt die DHCP-Freigabe beim Herunterfahren/Neustart unerwartet frei, was zu IP-Änderungen führen kann

    In systemd v244 hat systemd-networkd eine Standardverhaltensänderung in der Konfiguration von KeepConfiguration. Vor dieser Änderung haben VMs beim Herunterfahren oder Neustarten keine DHCP-Freigabenachricht an den DHCP-Server gesendet. Nach dieser Änderung senden VMs eine solche Nachricht und geben die IP-Adressen an den DHCP-Server zurück. Infolgedessen kann die freigegebene IP-Adresse einer anderen VM zugewiesen und/oder der VM eine andere IP-Adresse zugewiesen werden. Dies führt zu einem IP-Konflikt (auf Kubernetes-Ebene, nicht auf vSphere-Ebene) und/oder IP-Änderung auf den VMs, was die Cluster auf unterschiedliche Weise beeinträchtigen kann.

    Beispielsweise können die folgenden Symptome auftreten.

    • Die vCenter-Benutzeroberfläche zeigt, dass keine VMs dieselbe IP-Adresse verwenden, kubectl get nodes -o wide gibt jedoch Knoten mit doppelten IP-Adressen zurück. 
      
NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • Neue Knoten können aufgrund des Fehlers calico-node nicht gestartet werden 
      
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Workaround:

    Stellen Sie das folgende DaemonSet im Cluster bereit, um die Standardänderung von systemd-networkd rückgängig zu machen. Die VMs, auf denen dieses DaemonSet ausgeführt wird, geben die IP-Adressen beim Herunterfahren/Neustart nicht an den DHCP-Server weiter. Die IP-Adressen werden vom DHCP-Server automatisch freigegeben, wenn die Freigabe abläuft. 

    
      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Betrieb, Upgrades und Updates 1.12.0–1.12.5, 1.13.0–1.13.5, 1.14.0–1.14.1

    Dienstkontoschlüssel für Zugriff auf Komponenten gelöscht, nachdem der Administratorcluster von 1.11.x aktualisiert wurde

    Dieses Problem betrifft nur Administratorcluster, die von 1.11.x aktualisiert wurden, und nicht von Administratorclustern, die nach 1.12 neu erstellt werden.

    Nach dem Upgrade eines Clusters von 1.11.x auf 1.12.x wird das Feld component-access-sa-key im Secret admin-cluster-creds gelöscht. Sie können das prüfen, indem Sie den folgenden Befehl ausführen: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Wenn Sie feststellen, dass die Ausgabe leer ist, wird der Schlüssel gelöscht.

    Nachdem der Dienstkontoschlüssel für den Komponentenzugriff gelöscht wurde, schlägt die Installation neuer Nutzercluster oder das Upgrade vorhandener Nutzercluster fehl. Im Folgenden werden einige Fehlermeldungen aufgeführt:

    • Langsamer Validierungs-Preflight-Fehler mit Fehlermeldung: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Die Vorbereitung durch gkectl prepare ist mit der folgenden Fehlermeldung fehlgeschlagen: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Wenn Sie einen Nutzercluster der Version 1.13 mit der Google Cloud Console oder der gcloud CLI upgraden, schlägt der Befehl zum Bereitstellen des Controllers für die Upgrade-Plattform mit der Meldung "failed to download bundle to disk: dialing: unexpected end of JSON input" fehl. Diese Meldung wird im Feld status in der Ausgabe von kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml angezeigt.gkectl update admin --enable-preview-user-cluster-central-upgrade


    Problemlösung:

    Fügen Sie den Dienstkontoschlüssel für den Komponentenzugriff manuell mit dem folgenden Befehl wieder in das Secret ein: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
    Vorgang 1.13.0+, 1.14.0+

    Cluster Autoscaler funktioniert nicht, wenn die Steuerungsebene V2 aktiviert ist

    Für Nutzercluster, die mit Controlplane V2 oder einem neuen Installationsmodell erstellt wurden, verwenden Knotenpools mit Autoscaling immer ihre Autoscaling.minReplicas in der user-cluster.yaml. Das Log des Cluster Autoscaler-Pods zeigt auch an, dass sie fehlerhaft sind. 

    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Der Cluster Autoscaler-Pod lässt sich mit den folgenden Befehlen finden. 
    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Problemlösung:

    Autoscaling in allen Knotenpools mit „gkectl update cluster“ deaktivieren, bis Sie auf eine Version mit Korrektur upgraden
    Installation 1.12.0–1.12.4, 1.13.0–1.13.3, 1.14.0

    CIDR ist in der IP-Blockdatei nicht zulässig

    Wenn Nutzer CIDR in der IP-Blockdatei verwenden, schlägt die Konfigurationsprüfung mit dem folgenden Fehler fehl: 

    
- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Problemlösung:

    Fügen Sie der IP-Blockdatei einzelne IP-Adressen hinzu, bis Sie ein Upgrade auf eine Version mit 1.12.5, 1.13.4, 1.14.1 oder höher ausführen.
    Upgrades und Updates 1.14.0–1.14.1

    Das Update des Betriebssystem-Image-Typs in der Datei „admin-cluster.yaml“ wartet nicht darauf, dass Maschinen der Nutzersteuerungsebene neu erstellt werden

    Wenn der Betriebssystem-Image-Typ der Steuerungsebene in der Datei „admin-cluster.yaml“ aktualisiert wird und der entsprechende Nutzercluster über Controlplane V2 erstellt wurde, wird die Neuerstellung unter Umständen erst nach Abschluss des gkectl-Befehls ausgeführt.


    Problemlösung:

    Warten Sie, bis das Update abgeschlossen ist, und warten Sie, bis die Geräte der Nutzersteuerungsebene neu erstellt wurden. Prüfen Sie dazu mit kubectl --kubeconfig USER_KUBECONFIG get nodes -owide die Arten des Knotenbetriebs. Beispiel: Wenn Sie ein Update von Ubuntu auf COS durchführen, sollten wir warten, bis alle Maschinen der Steuerungsebene vollständig von Ubuntu zu COS gewechselt sind, auch wenn der Befehl zum Aktualisieren abgeschlossen ist.

    Vorgang 1.14.0

    Pod-Fehler beim Erstellen oder Löschen aufgrund des Authentifizierungstokens des CNI-Dienstkontos

    Ein Problem mit Calico in Anthos-Cluster auf VMware 1.14.0 führt zum Erstellen und Löschen von Pods mit der folgenden Fehlermeldung in der Ausgabe von kubectl describe pods:

    
  error getting ClusterInformation: connection is unauthorized: Unauthorized

    Dieses Problem wird erst 24 Stunden nach der Erstellung des Upgrades oder der Aktualisierung auf 1.14 mit Calico festgestellt.

    Administratorcluster verwenden Calico immer. Für den Nutzercluster gibt es das Konfigurationsfeld „enableDataPlaneV2“ in der Datei „user-cluster.yaml“, wenn dieses Feld auf „false“ gesetzt oder nicht angegeben ist, was bedeutet, dass Sie Calico im Nutzercluster verwenden.

    Der Container install-cni der Knoten erstellt eine kubeconfig-Datei mit einem Token, das 24 Stunden lang gültig ist. Dieses Token muss regelmäßig vom calico-node-Pod verlängert werden. Der Pod calico-node kann das Token nicht verlängern, da er keinen Zugriff auf das Verzeichnis hat, das die kubeconfig-Datei auf dem Knoten enthält.


    Workaround:

    Um das Problem zu beheben, wenden Sie den folgenden Patch auf das calico-node-DaemonSet in Ihrem Administrator- und Nutzercluster an:

    
  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Ersetzen Sie Folgendes:
    • ADMIN_CLUSTER_KUBECONFIG: Der Pfad der kubeconfig-Datei des Administratorclusters.
    • USER_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Nutzerclusters.
    Installation 1.12.0–1.12.4, 1.13.0–1.13.3, 1.14.0

    Die Validierung von IP-Blöcken schlägt fehl bei Verwendung von CIDR

    Die Clustererstellung schlägt fehl, obwohl der Nutzer die richtige Konfiguration hat. Der Nutzer sieht, dass die Erstellung fehlschlägt, weil der Cluster nicht genügend IP-Adressen hat.


    Problemlösung:

    Teilen Sie CIDRs in mehrere kleinere CIDR-Blöcke wie 10.0.0.0/30 auf, sodass 10.0.0.0/31, 10.0.0.2/31 wird. Solange es N+1-CIDRs gibt, wobei N die Anzahl der Knoten im Cluster ist, sollte dies ausreichen.

    Betrieb, Upgrades und Updates 1.11.0–1.11.1, 1.10.0–1.10.4, 1.9.0–1.9.6

    In der Sicherung des Administratorclusters sind die Verschlüsselungsschlüssel und die Konfiguration für immer aktive Secrets nicht enthalten

    Wenn die Funktion „Verschlüsselung immer aktivierte Secrets“ zusammen mit der Clustersicherung aktiviert ist, enthält die Sicherung des Administratorclusters nicht die Verschlüsselungsschlüssel und die Konfiguration, die für die Verschlüsselungsfunktion „Immer aktivierte Secrets“ erforderlich sind. Daher führt die Reparatur des Admin-Masters mit dieser Sicherung mit gkectl repair admin-master --restore-from-backup zu folgendem Fehler: 

    
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Betrieb, Upgrades und Updates 1.10+

    Die Administrator-Master-VM mit einem neuen Bootlaufwerk neu erstellen (z.B. gkectl repair admin-master) schlägt fehl, wenn die Funktion zur Verschlüsselung von immer aktiven Secrets mit dem Befehl „gkectl update“ aktiviert wird.

    Wenn die Verschlüsselungsfunktion „Always-on-Secrets“ bei der Clustererstellung nicht aktiviert ist, später aber mit dem gkectl update-Vorgang aktiviert wird, kann gkectl repair admin-master den Knoten der Steuerungsebene des Administratorclusters nicht reparieren. Es wird empfohlen, beim Erstellen des Clusters die Funktion „Always-on-Secrets-Verschlüsselung“ zu aktivieren. Es gibt derzeit keine Entschärfung.

    Upgrades und Updates 1.10

    Durch das Upgrade des ersten Nutzerclusters von 1.9 auf 1.10 werden Knoten in anderen Nutzerclustern neu erstellt

    Ein Upgrade des ersten Nutzerclusters von 1.9 auf 1.10 kann Knoten in anderen Nutzerclustern unter demselben Administratorcluster neu erstellen. Die Wiederherstellung erfolgt fortlaufend.

    Die disk_label wurde aus MachineTemplate.spec.template.spec.providerSpec.machineVariables entfernt, wodurch eine Aktualisierung an allen MachineDeployments unerwartet ausgelöst wurde.


    Workaround:
    Upgrades und Updates 1.10.0

    Docker wird nach dem Clusterupgrade häufig neu gestartet

    Führen Sie ein Upgrade des Nutzerclusters auf 1.10.0 aus, was zu einem häufigen Neustart des Docker führen kann.

    Dieses Problem können Sie mit kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG ermitteln.

    Eine Knotenbedingung zeigt an, ob das Docker häufig neu gestartet wird. Hier ein Beispiel für eine Ausgabe:

    
Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Um die Ursache zu ermitteln, müssen Sie eine SSH-Verbindung zum Knoten mit dem Symptom herstellen und Befehle wie sudo journalctl --utc -u docker oder sudo journalctl -x ausführen.


    Workaround:
    Upgrades und Updates 1,11, 1,12

    Selbst bereitgestellte GMP-Komponenten, die nach dem Upgrade auf Version 1.12 nicht beibehalten wurden

    Wenn Sie eine Anthos-Cluster auf VMware-Version unter 1.12 verwenden und von Google verwaltete Prometheus-Komponenten (GMP) im Namespace gmp-system für Ihren Cluster manuell eingerichtet haben, bleiben die Komponenten beim Upgrade auf Version 1.12.x erhalten.

    Ab Version 1.12 werden GMP-Komponenten im gmp-system-Namespace und in CRDs mit dem Objekt stackdriver verwaltet, wobei das Flag enableGMPForApplications standardmäßig auf false gesetzt ist. Wenn Sie GMP-Komponenten vor dem Upgrade auf Version 1.12 manuell im Namespace bereitstellen, werden die Ressourcen von stackdriver gelöscht.


    Workaround:
    Vorgang 1.11, 1.12, 1.13.0–1.13.1

    Fehlende ClusterAPI-Objekte im Cluster-Snapshot system

    Im system-Szenario enthält der Cluster-Snapshot keine Ressourcen unter dem Namespace default.

    Einige Kubernetes-Ressourcen wie Cluster API-Objekte in diesem Namespace enthalten jedoch nützliche Informationen zur Fehlerbehebung. Der Cluster-Snapshot sollte sie enthalten.


    Workaround:

    Sie können die folgenden Befehle manuell ausführen, um die Debugging-Informationen zu erfassen.

    
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    wobei

    USER_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Nutzerclusters.
    Upgrades und Updates 1.11.0–1.11.4, 1.12.0–1.12.3, 1.13.0–1.13.1

    Löschen des Nutzerclusters beim Beenden des Knotens zur vSAN-Einrichtung hängt fest

    Wenn Sie einen Nutzercluster löschen, aktualisieren oder upgraden, bleibt der Knoten in den folgenden Szenarien möglicherweise hängen:

    • Der Administratorcluster verwendet seit Version 1.12.x den vSphere-CSI-Treiber für vSAN und
    • Es gibt keine PVC/PV-Objekte, die von integrierten vSphere-Plug-ins im Administrator- und Nutzercluster erstellt wurden.

    Führen Sie den folgenden Befehl aus, um das Symptom zu identifizieren:

    
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Hier sehen Sie ein Beispiel für eine Fehlermeldung vom obigen Befehl:

    
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols ist das Standardverzeichnis für den integrierten vSphere-Treiber. Wenn keine PVC-/PV-Objekte erstellt werden, tritt möglicherweise ein Fehler auf, bei dem der Knotenablauf bei der Suche nach kubevols hängen bleibt, da bei der aktuellen Implementierung davon ausgegangen wird, dass kubevols immer vorhanden ist.


    Workaround:

    Erstellen Sie das Verzeichnis kubevols im Datenspeicher, in dem der Knoten erstellt wird. Dies wird in den Dateien user-cluster.yaml und admin-cluster.yaml im Feld vCenter.datastore definiert.
    Konfiguration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14

    Cluster Autoscaler Clusterrolebinding und Clusterrole werden nach dem Löschen eines Nutzerclusters gelöscht.

    Beim Löschen des Nutzerclusters werden auch die entsprechenden clusterrole und clusterrolebinding für Cluster Autoscaler gelöscht. Dies wirkt sich auf alle anderen Nutzercluster im selben Administratorcluster aus, für den Cluster Autoscaler aktiviert ist. Dies liegt daran, dass dieselbe Clusterrole und Clusterrolebinding für alle Cluster Autoscaler-Pods im selben Administratorcluster verwendet werden.

    Die Symptome sind:

    • cluster-autoscaler-Logs
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Hier ein Beispiel für Fehlermeldungen: 
      
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Workaround:

    Konfiguration 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    Administratorcluster cluster-health-controller und vsphere-metrics-exporter funktionieren nach dem Löschen des Nutzerclusters nicht

    Beim Löschen von Nutzerclustern wird auch die entsprechende clusterrole gelöscht, was dazu führt, dass der Export von automatischen Reparaturen und vSphere-Messwerten nicht mehr funktioniert

    Die Symptome sind:

    • cluster-health-controller-Logs
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Hier ein Beispiel für Fehlermeldungen: 
      
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • vsphere-metrics-exporter-Logs
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      Dabei ist ADMIN_CLUSTER_KUBECONFIG die kubeconfig-Datei des Administratorclusters. Hier ein Beispiel für Fehlermeldungen: 
      
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Workaround:

    Konfiguration 1.12.1–1.12.3, 1.13.0–1.13.2

    gkectl check-config schlägt bei der Validierung des Betriebssystem-Images fehl

    Ein bekanntes Problem, das den gkectl check-config-Fehler verursachen kann, ohne gkectl prepare auszuführen. Das ist verwirrend, weil wir empfehlen, den Befehl vor der Ausführung von gkectl prepare auszuführen.

    Das Symptom ist, dass der Befehl gkectl check-config fehlschlägt und die folgende Fehlermeldung angezeigt wird:

    
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Workaround:

    Option 1: Führen Sie gkectl prepare aus, um die fehlenden Betriebssystem-Images hochzuladen.

    Option 2: Überspringen Sie mit gkectl check-config --skip-validation-os-images die Validierung des Betriebssystem-Images.
    Upgrades und Updates 1,11, 1,12, 1,13

    gkectl update admin/cluster kann Anti-Affinitätsgruppen nicht aktualisieren

    Ein bekanntes Problem, das beim Aktualisieren von anti affinity groups möglicherweise den Fehler gkectl update admin/cluster verursacht.

    Das Symptom ist, dass der Befehl gkectl update fehlschlägt und die folgende Fehlermeldung angezeigt wird:

    
Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Workaround:
    Installation, Upgrades und Updates 1.13.0–1.13.8, 1.14.0–1.14.4, 1.15.0

    Knoten können nicht registriert werden, wenn der konfigurierte Hostname einen Punkt enthält

    Die Knotenregistrierung schlägt während der Clustererstellung, des Upgrades, der Aktualisierung und der automatischen Knotenreparatur fehl, wenn ipMode.type static ist und der konfigurierte Hostname in der IP-Blockdatei einen oder mehrere Punkte enthält. In diesem Fall werden Zertifikatsignaturanfragen (Certificate Signing Request, CSR) für einen Knoten nicht automatisch genehmigt.

    Führen Sie den folgenden Befehl aus, um ausstehende CSRs für einen Knoten aufzurufen:

    
kubectl get csr -A -o wide

    Prüfen Sie die folgenden Logs auf Fehlermeldungen:

    • Sehen Sie sich die Logs im Administratorcluster für den Container clusterapi-controller-manager im clusterapi-controllers-Pod an: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Führen Sie den folgenden Befehl aus, um dieselben Logs im Nutzercluster anzusehen: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      Dabei gilt:
      • ADMIN_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Administratorclusters.
      • USER_CLUSTER_NAME ist der Name des Nutzerclusters.
      Beispiel für Fehlermeldungen: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Sehen Sie sich die kubelet-Logs auf dem problematischen Knoten an: 
      
journalctl --u kubelet
      Hier ein Beispiel für Fehlermeldungen: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Wenn Sie im Feld „Hostname“ einer IP-Blockdatei einen Domainnamen angeben, werden alle Zeichen, die auf den ersten Punkt folgen, ignoriert. Wenn Sie beispielsweise den Hostnamen als bob-vm-1.bank.plc angeben, werden der VM-Hostname und der Knotenname auf bob-vm-1 festgelegt.

    Wenn die Knoten-ID-Überprüfung aktiviert ist, vergleicht der CSR-Genehmiger den Knotennamen mit dem Hostnamen in der Maschinenspezifikation, kann den Namen aber nicht abgleichen. Der Genehmiger lehnt die CSR ab und der Knoten startet nicht.


    Workaround:

    Nutzercluster

    So deaktivieren Sie die Knoten-ID-Bestätigung:

    1. Fügen Sie der Konfigurationsdatei des Nutzerclusters die folgenden Felder hinzu: 
      
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Speichern Sie die Datei und aktualisieren Sie den Nutzercluster mit dem folgenden Befehl: 
      
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Ersetzen Sie Folgendes:
      • ADMIN_CLUSTER_KUBECONFIG: Der Pfad der kubeconfig-Datei des Administratorclusters.
      • USER_CLUSTER_CONFIG_FILE: der Pfad zur Konfigurationsdatei des Nutzerclusters.

    Administratorcluster

    1. Öffnen Sie die benutzerdefinierte Ressource OnPremAdminCluster zum Bearbeiten: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Fügen Sie der benutzerdefinierten Ressource die folgende Annotation hinzu: 
      
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Bearbeiten Sie das Manifest kube-controller-manager in der Steuerungsebene des Administratorclusters:
      1. Stellen Sie eine SSH-Verbindung zum Knoten der Steuerungsebene des Administratorclusters her.
      2. Öffnen Sie das Manifest kube-controller-manager zum Bearbeiten: 
        
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Suchen Sie die Liste der controllers: 
        
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Aktualisieren Sie diesen Abschnitt wie unten dargestellt: 
        
--controllers=*,bootstrapsigner,tokencleaner
    4. Öffnen Sie den Deployment Cluster API-Controller zum Bearbeiten: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Ändern Sie die Werte von node-id-verification-enabled und node-id-verification-csr-signing-enabled in false: 
      
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installation, Upgrades und Updates 1.11.0–1.11.4

    Startvorgang der Maschine für die Steuerungsebene des Administrators verursacht durch ein privates Registry-Zertifikatspaket

    Das Erstellen/Upgrade des Administratorclusters bleibt dauerhaft beim folgenden Log hängen und führt irgendwann zu einer Zeitüberschreitung:

    
Waiting for Machine gke-admin-master-xxxx to become ready...

    Das Cluster API-Controller-Log im externen Cluster-Snapshot enthält das folgende Log:

    
Invalid value 'XXXX' specified for property startup-data

    Hier ein Beispiel für einen Dateipfad für das Cluster API-Controller-Log:

    
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Netzwerk 1.10, 1.11.0–1.11.3, 1.12.0–1.12.2, 1.13.0

    NetworkGatewayNodes wurde aufgrund eines Konflikts bei einer gleichzeitigen Statusaktualisierung als fehlerhaft gekennzeichnet

    In networkgatewaygroups.status.nodes wechseln einige Knoten zwischen NotHealthy und Up.

    Logs für den Pod ang-daemon, der auf diesem Knoten ausgeführt wird, zeigen wiederholte Fehler auf: 

    
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    Der Status NotHealthy verhindert, dass der Controller zusätzliche Knoten-IP-Adressen erhält. Dies kann zu einer höheren Belastung anderer Knoten oder einer Redundanz bei Hochverfügbarkeit führen.

    Die Aktivität der Datenebene ist ansonsten nicht betroffen.

    Konflikte beim networkgatewaygroup-Objekt führen dazu, dass einige Statusaktualisierungen aufgrund eines Fehlers bei der Wiederholungsbehandlung fehlschlagen. Wenn zu viele Statusaktualisierungen fehlschlagen, sieht ang-controller-manager, dass der Knoten über das Heartbeat-Zeitlimit hinausgeht und den Knoten NotHealthy markiert.

    Der Fehler bei der Wiederholungsbehandlung wurde in späteren Versionen behoben.


    Workaround:

    Führen Sie ein Upgrade auf eine korrigierte Version durch, falls verfügbar.
    Upgrades und Updates 1.12.0–1.12.2, 1.13.0

    Race-Bedingung verhindert das Löschen von Maschinenobjekten während des Updates und der Aktualisierung oder des Upgrades

    Ein bekanntes Problem, das dazu führen kann, dass das Clusterupgrade oder -update auf das Löschen des alten Maschinenobjekts hängt. Dies liegt daran, dass der Finaler nicht aus dem Maschinenobjekt entfernt werden kann. Dies wirkt sich auf alle Rolling Update-Vorgänge für Knotenpools aus.

    Das Symptom ist, dass der Befehl gkectl mit der folgenden Fehlermeldung abläuft:

    
E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    In clusterapi-controller-Pod-Logs sehen die folgenden Fehler aus:

    
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    Der Fehler wird für dieselbe Maschine mehrere Minuten lang für erfolgreiche Ausführungen wiederholt, auch ohne diesen Fehler. Meistens kann er schnell passieren, aber in seltenen Fällen kann er bei dieser Race-Bedingung mehrere Stunden hängen bleiben.

    Das Problem besteht darin, dass die zugrunde liegende VM bereits in vCenter gelöscht wurde, das entsprechende Maschinenobjekt aber nicht entfernt werden kann. Es bleibt aufgrund sehr häufiger Aktualisierungen von anderen Controllern beim Entfernen des endgültigen Endpunkts. Dies kann dazu führen, dass der Befehl gkectl zu einer Zeitüberschreitung führt. Der Controller vergleicht den Cluster aber weiter, damit der Upgrade- oder Aktualisierungsprozess abgeschlossen ist.


    Workaround:

    Wir haben verschiedene Lösungsmöglichkeiten für dieses Problem vorbereitet, die von Ihrer Umgebung und Ihren Anforderungen abhängen.

    • Option 1: Warten Sie, bis das Upgrade abgeschlossen ist.

      Basierend auf der Analyse und Reproduktion Ihrer Umgebung kann das Upgrade schließlich ohne manuelle Eingriffe selbst durchgeführt werden. Bei dieser Option ist allerdings ungewiss, wie lange es dauert, bis das jeweilige Endgerät durch das Entfernen des endgültigen Objekts entfernt wird. Wenn das Glück ausreicht, kann der Vorgang sofort abgeschlossen werden. Er kann auch mehrere Stunden dauern, wenn der Machineset-Controller-Abgleich zu schnell ist und der Computer-Controller nie die Möglichkeit hat, den Finalierer zwischen den Abgleichen zu entfernen.

      Die Option muss nichts weiter tun. Die Arbeitslasten werden nicht unterbrochen. Es dauert einfach länger, bis das Upgrade abgeschlossen ist.
    • Option 2: Annotationen zur automatischen Reparatur auf alle alten Maschinenobjekte anwenden.

      Der Computersatz-Controller filtert die Maschinen heraus, bei denen der Hinweis auf automatische Reparatur und der Löschzeitstempel ungleich null sind. Außerdem werden auf diesen Computern keine Löschaufrufe ausgeführt, wodurch die Race-Bedingung vermieden werden kann.

      Der Nachteil ist, dass die Pods auf den Maschinen direkt gelöscht und nicht entfernt werden, d. h. die PDB-Konfiguration wird nicht berücksichtigt. Dies kann zu Ausfallzeiten Ihrer Arbeitslasten führen.

      Der Befehl zum Abrufen aller Maschinennamen: 
      
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Der Befehl zum Anwenden der Anmerkung zur automatischen Reparatur für jede Maschine: 
      
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Wenn dieses Problem auftritt und das Upgrade oder Update nach einiger Zeit immer noch nicht abgeschlossen ist, wenden Sie sich an unser Supportteam, um entsprechende Maßnahmen zu ergreifen.
    Installation, Upgrades und Updates 1.10.2, 1.11, 1.12, 1.13

    gkectl bereitet den Preflight-Fehler bei der Validierung von Betriebssystem-Images vor

    gkectl prepare-Befehl fehlgeschlagen:

    
- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    Die Preflight-Prüfungen von gkectl prepare enthielten eine falsche Validierung.


    Workaround:

    Führen Sie denselben Befehl mit dem zusätzlichen Flag --skip-validation-os-images aus.
    Installation 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    Die vCenter-URL mit dem Präfix https:// oder http:// kann zu einem Fehler beim Start des Clusters führen

    Erstellen des Administratorclusters fehlgeschlagen mit:

    
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    Die URL wird als Teil eines Secret-Schlüssels verwendet, der "/" oder ":" nicht unterstützt.


    Workaround:

    Entfernen Sie das Präfix https:// oder http:// aus dem Feld vCenter.Address in der YAML-Datei für den Administratorcluster oder den Nutzercluster.
    Installation, Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    gkectl prepare Panik auf util.CheckFileExists

    gkectl prepare kann mit dem folgenden Stacktrace Panik betreiben:

    
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Das Problem besteht darin, dass gkectl prepare das Verzeichnis der privaten Registry-Zertifikate mit der falschen Berechtigung erstellt hat.


    Workaround:

    Führen Sie auf der Administratorworkstation die folgenden Befehle aus, um dieses Problem zu beheben:

    
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    gkectl repair admin-master und fortsetzbares Administrator-Upgrade funktionieren nicht zusammen

    Führen Sie nach einem fehlgeschlagenen Upgrade des Administratorclusters nicht gkectl repair admin-master aus. Das kann dazu führen, dass nachfolgende Administrator-Upgrade-Fehler fehlschlagen, z. B. aufgrund von Ausfällen des Administrator-Masters oder wenn die VM nicht zugänglich ist.


    Workaround:

    Wenn dieses Fehlerszenario bereits aufgetreten ist, wenden Sie sich an den Support.
    Upgrades und Updates 1,10, 1,11

    Ein fortgesetztes Upgrade des Administratorclusters kann zu einer fehlenden VM-Vorlage der Admin-Steuerungsebene führen

    Wenn die Maschine der Administrator-Steuerungsebene nach einem fortgesetzten Upgradeversuch des Administratorclusters nicht neu erstellt wird, wird die VM-Vorlage der Administrator-Steuerungsebene gelöscht. Die VM-Vorlage der Administrator-Steuerungsebene ist die Vorlage des Administrator-Masters, der zum Wiederherstellen der Maschine der Steuerungsebene mit gkectl repair admin-master verwendet wird.


    Workaround:

    Die VM-Vorlage der Administrator-Steuerungsebene wird beim nächsten Upgrade des Administratorclusters neu generiert.
    Betriebssystem 1,12, 1,13

    cgroup v2 kann sich auf Arbeitslasten auswirken

    In Version 1.12.0 ist cgroup v2 (einheitlich) für Container-Optimized OS-Knoten (COS) standardmäßig aktiviert. Dies kann zu einer Instabilität Ihrer Arbeitslasten in einem COS-Cluster führen.


    Workaround:

    In Version 1.12.1 haben wir wieder auf cgroup v1 (hybrid) umgestellt. Wenn Sie COS-Knoten verwenden, empfehlen wir, ein Upgrade auf Version 1.12.1 vorzunehmen, sobald es veröffentlicht wird.
    Identität 1.10, 1.11, 1.12, 1.13

    Benutzerdefinierte ClientConfig-Ressource

    gkectl update setzt alle manuellen Änderungen zurück, die Sie an der benutzerdefinierten ClientConfig-Ressource vorgenommen haben.


    Workaround:

    Wir empfehlen Ihnen dringend, die ClientConfig-Ressource nach jeder manuellen Änderung zu sichern.
    Installation 1.10, 1.11, 1.12, 1.13

    gkectl check-config-Validierung fehlgeschlagen: F5 BIG-IP-Partitionen können nicht gefunden werden

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

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


    Workaround:

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

    Die Installation des Nutzerclusters ist aufgrund eines Problems mit der Leader-Auswahl für cert-manager/ca-injector fehlgeschlagen

    Es kann zu einem Installationsfehler aufgrund von cert-manager-cainjector in der Absturzschleife kommen, wenn apiserver/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"

    Workaround:
    Sicherheit, Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    Die Verlängerung von Zertifikaten ist möglicherweise vor dem Upgrade eines Administratorclusters erforderlich

    Prüfen Sie vor dem Upgrade des Administratorclusters, ob Ihre Administratorclusterzertifikate derzeit gültig sind, und verlängern Sie diese, wenn dies nicht der Fall ist.

    Wenn Sie das Upgrade gestartet und einen Fehler mit dem Ablaufdatum des Zertifikats gefunden haben, wenden Sie sich an den Google-Support.

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

    Workaround:
    VMware 1.10, 1.11, 1.12, 1.13

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

    Wenn vCenter nach einem Upgrade oder anderen Ausführungen bei Versionen unter 7.0U2 neu gestartet wird, ist der Netzwerkname in den VM-Informationen von vCenter falsch und führt dazu, dass sich der Computer im Status Unavailable befindet. Dies führt schließlich dazu, dass die Knoten automatisch repariert werden, um neue zu erstellen.

    Zugehöriger govmomi-Fehler


    Workaround:

    Diese Problemumgehung wird vom VMware-Support bereitgestellt:

    1. Das Problem wird in vCenter Version 7.0U2 und höher behoben.
    2. Bei niedrigeren Versionen klicken Sie mit der rechten Maustaste auf den Host und wählen Sie dann Verbindung > Verbindung trennen aus. Als Nächstes stellen Sie die Verbindung wieder her. Dadurch wird eine Aktualisierung der Portgruppe der VM erzwungen.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

    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.

    /etc/ssh/sshd_config hat die folgenden Einstellungen, um die CIS-Regel „5.2.16 Achten Sie darauf, dass das Zeitlimit-Intervall für SSH-Leerheiten konfiguriert ist“ zu erfüllen:

    
ClientAliveInterval 300
ClientAliveCountMax 0

    Mit diesen Einstellungen wird eine Clientsitzung nach 5 Minuten Inaktivität beendet. Der Wert ClientAliveCountMax 0 verursacht jedoch ein unerwartetes Verhalten. Wenn Sie die SSH-Sitzung auf der Administratorworkstation oder einem Clusterknoten verwenden, wird die SSH-Verbindung möglicherweise getrennt, auch wenn Ihr SSH-Client nicht inaktiv ist, z. B. beim Ausführen eines zeitaufwändigen Befehls, und Ihr Befehl kann mit der folgenden Nachricht beendet werden:

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

    Workaround:

    Sie haben folgende Möglichkeiten:

    • Verwenden Sie nohup, um zu verhindern, dass Ihr Befehl bei der SSH-Verbindung beendet wird. 
      
nohup gkectl upgrade admin --config admin-cluster.yaml \
    --kubeconfig kubeconfig
    • Aktualisieren Sie sshd_config, um einen ClientAliveCountMax-Wert ungleich null zu verwenden. Die CIS-Regel empfiehlt, einen Wert unter 3 zu verwenden: 
      
sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' \
    /etc/ssh/sshd_config
sudo systemctl restart sshd

    Achten Sie darauf, dass Sie die SSH-Sitzung neu verbinden.
    Installation 1.10, 1.11, 1.12, 1.13

    In Konflikt stehende cert-manager-Installation

    In 1.13-Releases installiert monitoring-operator cert-manager im Namespace cert-manager. Falls Sie aus bestimmten Gründen Ihren eigenen cert-manager installieren müssen, folgen Sie der folgenden Anleitung, um Konflikte zu vermeiden:

    Sie müssen diese Arbeit nur einmal auf jeden Cluster anwenden. Die Änderungen werden nach dem Clusterupgrade beibehalten.

    Hinweis: Ein häufiges Symptom der Installation eines eigenen cert-managers ist, dass die cert-manager Version oder das Image (z. B. v1.7.2) auf eine ältere Version zurückgesetzt werden kann. Der Grund dafür ist, dass monitoring-operator versucht, den cert-manager abzugleichen und die Version dabei zurückzusetzen.

    Workaround:

    Konflikte während des Upgrades vermeiden

    1. Deinstallieren Sie Ihre Version von cert-manager. Wenn Sie eigene Ressourcen definiert haben, können Sie diese sichern .
    2. Führen Sie das Upgrade aus.
    3. Folgen Sie der Anleitung, um Ihre eigene cert-manager wiederherzustellen.

    Eigenen cert-manager in Nutzerclustern wiederherstellen

    • Skalieren Sie das Deployment von monitoring-operator auf 0: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n USER_CLUSTER_NAME \
    scale deployment monitoring-operator --replicas=0
    • Skalieren Sie die von monitoring-operator verwalteten Bereitstellungen auf cert-manager 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
    • Installiere deine Version von cert-manager neu. Wiederherstellen Ihrer benutzerdefinierten Ressourcen, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die Standardinstallation von cert-manager verwenden oder sicher sind, dass cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das Zertifikat metrics-ca cert-manager.io/v1 und die Ausstellerressourcen metrics-pki.cluster.local von cert-manager in den Namespace der Clusterressource 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

    Im Allgemeinen müssen Sie cert-manager in Administratorclustern nicht neu installieren, da Administratorcluster nur Arbeitslasten von Anthos-Cluster auf VMware 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. Hinweis: Wenn Sie Apigee-Kunde sind und nur den Zertifikatmanager 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 Bereitstellungen von cert-manager 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
    • Installiere deine Version von cert-manager neu. Wiederherstellen Ihrer benutzerdefinierten Ressourcen, falls vorhanden.
    • Sie können diesen Schritt überspringen, wenn Sie die Standardinstallation von cert-manager verwenden oder sicher sind, dass cert-manager im Namespace cert-manager installiert ist. Kopieren Sie andernfalls das Zertifikat metrics-ca cert-manager.io/v1 und die Ausstellerressourcen metrics-pki.cluster.local von cert-manager in den Namespace der Clusterressource des installierten cert-managers. 
      
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 \n
    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
    Betriebssystem 1.10, 1.11, 1.12, 1.13

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

    Docker, containerd und runc in den Ubuntu-Betriebssystem-Images, die mit Anthos-Cluster auf VMware ausgeliefert wurden, sind mit Ubuntu PPA an spezielle Versionen angepinnt. So werden alle Änderungen der Containerlaufzeit vor jedem Release von Anthos-Cluster auf VMware qualifiziert.

    Die Sonderversionen sind jedoch der Ubuntu CVE-Tracker nicht bekannt, der von verschiedenen CVE-Scantools als Sicherheitslückenfeeds verwendet wird. Daher werden in Docker, containerd und runc Sicherheitslücken-Scans falsch positive Ergebnisse angezeigt.

    Unter Umständen sehen Sie in den Ergebnissen des CVE-Scans die folgenden falsch positiven Ergebnisse: Diese CVEs sind in den neuesten Patchversionen von Anthos-Cluster auf VMware bereits behoben.

    CVE-Korrekturen finden Sie in den Versionshinweisen.


    Workaround:

    Kanonisch ist sich dieses Problems bewusst. Die Fehlerbehebung wird unter https://github.com/canonical/sec-cvescan/issues/73 erfasst.
    Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    Die Netzwerkverbindung zwischen dem Administrator- und dem Nutzercluster ist möglicherweise während eines Nicht-HA-Clusterupgrades für kurze Zeit nicht verfügbar

    Wenn Sie ein Upgrade für Hochverfügbarkeitscluster von 1.9 auf 1.10 durchführen, stellen Sie möglicherweise fest, dass kubectl exec, kubectl log und Webhook mit Nutzerclustern für kurze Zeit nicht verfügbar sind. Diese Ausfallzeit kann bis zu einer Minute dauern. Dies geschieht, da die eingehende Anfrage (kubectl exec, kubectl log und webhook) von kube-apiserver für den Nutzercluster verarbeitet wird. Der Nutzer kube-apiserver ist ein Statefulset. In einem Nicht-HA-Cluster gibt es nur ein Replikat für das Statefulset. Während des Upgrades ist es also möglich, dass die alte kube-apiserver nicht verfügbar ist, während die neue kube-apiserver noch nicht bereit ist.


    Workaround:

    Diese Ausfallzeit findet nur während des Upgrades statt. Wenn Sie während des Upgrades die Ausfallzeiten verkürzen möchten, empfehlen wir, zu HA-Clustern zu wechseln.
    Installation, Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    Konnektivitätsbereitschaftsprüfung in der HA-Clusterdiagnose nach Clustererstellung oder -upgrade fehlgeschlagen

    Wenn Sie einen Hochverfügbarkeitscluster erstellen oder upgraden und dabei feststellen, dass die Prüfung der Konnektivität in der Clusterdiagnose fehlgeschlagen ist, hat dies in den meisten Fällen keine Auswirkungen auf die Funktionalität von Anthos-Cluster auf VMware (kubectl exec, kubectl log und Webhook). Dies liegt daran, dass aufgrund von instabilen Netzwerken oder anderen Problemen manchmal ein oder zwei Konnectivity-Replikate für einen bestimmten Zeitraum nicht gelesen werden können.


    Workaround:

    Die Konnektivität wird alleine wiederhergestellt. Warten Sie 30 Minuten bis 1 Stunde und führen Sie die Clusterdiagnose noch einmal aus.
    Betriebssystem 1,7, 1,8, 1,9, 1,10, 1,11

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

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

    Aus diesem Grund wurde das Cron-Skript /etc/cron.daily/aide installiert, um eine aide-Prüfung zu planen. Damit soll sichergestellt werden, dass die CIS-L1-Serverregel „1.4.2: Sicherstellen, dass die Dateisystemintegrität regelmäßig geprüft wird“ eingehalten wird.

    Der Cronjob wird täglich um 06:25 Uhr UTC ausgeführt. Abhängig von der Anzahl der Dateien im Dateisystem kann es in diesem Zeitraum zu einem Anstieg der CPU- und Arbeitsspeichernutzung kommen, der durch diesen aide-Prozess verursacht wird.


    Workaround:

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

    
sudo chmod -x /etc/cron.daily/aide
    Netzwerk 1.10, 1.11, 1.12, 1.13

    Load-Balancer und zustandsorientierte NSX-T-Zulassungsregeln funktionieren unvorhersehbar

    Wenn Anthos Anthos-Cluster auf VMware Version 1.9 oder höher bereitgestellt werden und das Seesaw-Bundle-Load-Balancer in einer Umgebung verwendet wird, die vertrauenswürdige NSX-T-Firewallregeln verwendet, kann stackdriver-operator gke-metrics-agent-conf ConfigMap erstellen und gke-connect-agent Pods in einer Absturzschleife befinden.

    Das zugrunde liegende Problem besteht darin, dass die zustandsorientierte verteilte NSX-T-Firewallregeln die Verbindung von einem Client zum Nutzercluster-API-Server über den Seesaw-Load-Balancer beendet, da Seesaw asymmetrische Verbindungsabläufe verwendet. Die Integrationsprobleme mit verteilten Firewallregeln von NSX-T wirken sich auf alle Anthos-Cluster auf VMware-Releases aus, die Seesaw verwenden. Es kann zu ähnlichen Verbindungsproblemen bei Ihren eigenen Anwendungen kommen, wenn sie große Kubernetes-Objekte erstellen, die größer als 32 K sind.


    Workaround:

    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 er einen Back-End-Knotenfehler erkennt. Ohne diese Konfiguration reagieren Clients des Kubernetes API-Servers bei Ausfall einer Serverinstanz möglicherweise mehrere Minuten lang nicht mehr.
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    Unerwartete Monitoring-Abrechnung

    Bei Anthos-Cluster auf VMware-Versionen ab 1.10 haben einige Kunden auf der Seite Abrechnung einen unerwartet hohen Preis für Metrics volume festgestellt. Dieses Problem betrifft Sie nur, wenn folgende Bedingungen erfüllt sind:

    • Anwendungsmonitoring ist aktiviert (enableStackdriverForApplications=true)
    • Managed Service for Prometheus ist nicht aktiviert (enableGMPForApplications)
    • Anwendungs-Pods haben die Annotation prometheus.io/scrap=true. Wenn Sie Anthos Service Mesh installieren, kann diese Annotation ebenfalls hinzugefügt werden.

    Erstelle eine Liste deiner benutzerdefinierten Messwerte, um zu sehen, ob du von diesem Problem betroffen bist. Wenn Sie Abrechnungen für unerwünschte Messwerte sehen, ist dieses Problem für Sie relevant.


    Problemumgehung

    Wenn Sie von diesem Problem betroffen sind, empfehlen wir Ihnen, Ihre Cluster auf Version 1.12 zu aktualisieren und zu einer neuen Lösung für das Anwendungsmonitoring managed-service-for-prometheus zu wechseln, die dieses Problem löst:

  • Separate Flags zur Steuerung der Erfassung von Anwendungslogs und Anwendungsmesswerten
  • Gebündelter Google Cloud Managed Service for Prometheus

    • Wenn Sie kein Upgrade auf Version 1.12 ausführen können, gehen Sie so vor:

    1. Suchen Sie die Quell-Pods und -Dienste, die die nicht berechnete haben 
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Entfernen Sie die Annotation prometheus.io/scrap=true aus dem Pod oder Dienst. Wenn die Annotation von Anthos Service Mesh hinzugefügt wird, können Sie Anthos Service Mesh ohne die Prometheus-Option konfigurieren oder das Mesh-Feature für Istio-Messwerte deaktivieren.
    Installation 1,11, 1,12, 1,13

    Das Installationsprogramm schlägt beim Erstellen des vSphere-Datenlaufwerks fehl.

    Das Anthos-Cluster auf VMware-Installationsprogramm kann fehlschlagen, wenn benutzerdefinierte Rollen auf der falschen Berechtigungsebene gebunden sind.

    Wenn die Rollenbindung falsch ist, wird beim Erstellen eines vSphere-Datenlaufwerks mit govc der Vorgang angehalten. Das Laufwerk wird mit einer Größe von 0 erstellt. Zur Behebung des Problems sollten Sie die benutzerdefinierte Rolle an die vSphere-vCPU-Ebene binden (Stamm).


    Workaround:

    Wenn Sie die benutzerdefinierte Rolle auf DC-Ebene oder niedriger an die Root-Ebene binden möchten, müssen Sie auch die schreibgeschützte Rolle an den Nutzer auf der Stamm- vCenter-Ebene binden.

    Weitere Informationen zum Erstellen von Rollen finden Sie unter Berechtigungen für vCenter-Nutzerkonten.
    Logging und Monitoring 1.9.0–1.9.4, 1.10.0–1.10.1

    Hoher Netzwerk-Traffic zu Monitoring.googleapis.com

    Es kann sein, dass selbst bei einem neuen Cluster ohne Nutzerarbeitslasten hoher Traffic zu monitoring.googleapis.com auftritt.

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


    Workaround:
    Logging und Monitoring 1,10, 1,11

    gke-metrics-agent hat häufige CrashLoopBackOff-Fehler

    Bei Anthos-Cluster auf VMware-Version 1.10 und höher weist „DaemonSet-metrics-agent“ das DaemonSet häufig „CrashLoopBackOff“-Fehler auf, wenn „enableApigeeForApplications“ im Objekt „ Stackdriver“ auf „true“ gesetzt ist.


    Workaround:

    Um dieses Problem zu minimieren, deaktivieren Sie die Erfassung von Anwendungsmesswerten mit den folgenden Befehlen. Diese Befehle deaktivieren die Erfassung von Anwendungslogs nicht.

    1. So verhindern Sie, dass die folgenden Änderungen rückgängig gemacht werden: stackdriver-operator 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
    2. Öffnen Sie die ConfigMap gke-metrics-agent-conf zum Bearbeiten: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Kommentieren Sie unter services.pipelines den gesamten Abschnitt metrics/app-metrics aus: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Schließen Sie die Bearbeitungssitzung.
    5. Starten Sie das DaemonSet gke-metrics-agent neu: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging und Monitoring 1,11, 1,12, 1,13

    Verworfene Messwerte im Dashboard ersetzen

    Wenn in Ihren OOTB-Dashboards verworfene Messwerte verwendet werden, sehen Sie einige leere Diagramme. Führen Sie die folgenden Befehle aus, um verworfene Messwerte in den Monitoring-Dashboards zu finden:

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    Die folgenden verworfenen Messwerte sollten zu ihren Ersatzen migriert werden.

    Eingestellte FunktionenErsetzen
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Workaround:

    Um die eingestellten Messwerte zu ersetzen

    1. Löschen Sie den GKE On-Prem-Knotenstatus im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem Node Status“ gemäß dieser Anleitung neu.
    2. Löschen Sie „GKE On-Prem-Knotenauslastung“ im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem-Knotenauslastung“ neu. Folgen Sie dazu dieser Anleitung.
    3. Löschen Sie den Status „GKE On-Prem vSphere-VM“ im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem vSphere-VM-Status“ neu. Folgen Sie dazu dieser Anleitung.

      4. Diese Einstellung ist auf das Upgrade des kube-state-metrics-Agents von v1.9 auf v2.4 zurückzuführen, der für Kubernetes 1.22 erforderlich ist. Sie können alle eingestellten kube-state-metrics-Messwerte mit dem Präfix kube_ in Ihren benutzerdefinierten Dashboards oder Benachrichtigungsrichtlinien ersetzen.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13

    Unbekannte Messwertdaten in Cloud Monitoring

    Bei Anthos-Cluster auf VMware Version 1.10 und höher können die Daten für Cluster in Cloud Monitoring irrelevante Einträge mit zusammenfassenden Messwerten wie die folgenden enthalten:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Andere Messwerte, die irrelevante zusammenfassende Messwerte enthalten können, sind unter anderem:

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Diese Messwerte vom Typ „Zusammenfassung“ sind zwar in der Messwertliste enthalten, werden aber derzeit von gke-metrics-agent nicht unterstützt.
    Logging und Monitoring 1.10, 1.11, 1.12, 1.13

    Bei einigen Knoten fehlen Messwerte

    Die folgenden Messwerte fehlen möglicherweise bei einigen, aber nicht bei allen Knoten:

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

    Workaround:

    Um das Problem zu beheben, führen Sie die folgenden Schritte aus: Für [Version 1.9.5+, 1.10.2+, 1.11.0] müssen Sie die CPU-Anzahl für gke-metrics-agent erhöhen. Folgen Sie dazu den Schritten 1–4.

    1. Öffnen Sie die Ressource stackdriver zum Bearbeiten: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Wenn Sie die CPU-Anfrage für gke-metrics-agent von 10m auf 50m erhöhen möchten, fügen Sie dem stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu, um das CPU-Limit von 100m auf 200m zu erhöhen : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        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: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. 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.
    Logging und Monitoring 1.11.0–1.11.2, 1.12.0

    Im Administratorcluster fehlen Messwerte für Planer und Controller-Manager

    Wenn Ihr Administratorcluster von diesem Problem betroffen ist, fehlen Messwerte des Planers und des Controller-Managers. Diese beiden Messwerte fehlen beispielsweise:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Workaround:

    Führen Sie ein Upgrade auf v1.11.3+, v1.12.1+ oder v1.13+ aus.
    1.11.0–1.11.2, 1.12.0

    Im Nutzercluster fehlen Messwerte für Planer und Controller-Manager

    Wenn Ihr Nutzercluster von diesem Problem betroffen ist, fehlen Messwerte des Planers und des Controller-Managers. Diese beiden Messwerte fehlen beispielsweise:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Workaround:

    Dieses Problem wurde in Anthos-Cluster auf VMware-Version 1.13.0 und höher behoben. Führen Sie ein Upgrade Ihres Clusters auf eine Version mit der Fehlerkorrektur durch.
    Installation, Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    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 sich der Administratorcluster nicht während der Erstellung mit der angegebenen 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:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Sie können diesen Administratorcluster weiterhin verwenden. Wenn Sie später jedoch versuchen, ein Upgrade des Administratorclusters auf Version 1.10.y durchzuführen, wird der folgende Fehler angezeigt.

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

    Workaround:
    Identität 1.10, 1.11, 1.12, 1.13

    Die Verwendung des Anthos Identity-Dienstes kann dazu führen, dass der Connect-Agent unvorhersehbar neu startet

    Wenn Sie das Feature Anthos Identity Service zum Verwalten von Anthos Identity Service ClientConfig verwenden, wird der Connect Agent möglicherweise unerwartet neu gestartet.


    Workaround:

    Wenn dieses Problem bei einem vorhandenen Cluster aufgetreten ist, haben Sie folgende Möglichkeiten:

    • Deaktivieren Sie Anthos Identity Service (AIS). Wenn Sie AIS deaktivieren, wird das bereitgestellte AIS-Binärprogramm und der AIS-ClientConfig nicht 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 oder höher oder 1.10.1 oder höher, um das Connect-Agent-Upgrade zu aktualisieren.
    Netzwerk 1.10, 1.11, 1.12, 1.13

    Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

    Seesaw wird im DSR-Modus ausgeführt und funktioniert in Cisco ACI aufgrund des IP-Lernens der Datenebene standardmäßig nicht.


    Workaround:

    Sie können das IP-Lernen deaktivieren, indem Sie die Seesaw-IP-Adresse als virtuelle L4-L7-IP-Adresse in den Cisco Application Policy Infrastructure Controller (APIC) hinzufügen.

    Sie können die virtuelle IP-Adresse L4-L7 unter Tenant > Anwendungsprofile > Anwendungs-EPGs oder uSeg-EPGs konfigurieren. Wenn Sie das IP-Lernen nicht deaktivieren, flackert der IP-Endpunkt zwischen verschiedenen Orten in der Cisco API-Struktur.
    VMware 1.10, 1.11, 1.12, 1.13

    Probleme mit dem vSphere 7.0 Update 3

    VMWare hat vor Kurzem kritische Probleme in den folgenden vSphere 7.0 Update 3-Releases erkannt:

    • vSphere ESXi 7.0 Update 3 (Build 18644231)
    • vSphere ESXi 7.0 Update 3a (Build 18825058)
    • vSphere ESXi 7.0 Update 3b (Build 18905247)
    • vSphere vCenter 7.0 Update 3b (Build 18901211)

    Workaround:

    VMWare hat diese Releases seitdem entfernt. Sie sollten ein Upgrade für die ESXi- und vCenter-Server auf eine neuere Version durchführen.
    Betriebssystem 1.10, 1.11, 1.12, 1.13

    Das Feld „blankDir“ kann nicht als exec im Pod bereitgestellt werden, der auf COS-Knoten ausgeführt wird

    Für Pods, die auf Knoten ausgeführt werden, die Container-Optimized OS-(COS)-Images verwenden, können Sie ein leeres Dir-Volume nicht als exec bereitstellen. Die Bereitstellung erfolgt als noexec und Sie erhalten den folgenden Fehler: exec user process caused: permission denied. Diese Fehlermeldung wird beispielsweise angezeigt, wenn Sie den folgenden Test-Pod bereitstellen:

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Wenn Sie im Test-Pod mount | grep test-volume ausführen, wird die Option „Noexec“ angezeigt:

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Workaround:
    Upgrades und Updates 1.10, 1.11, 1.12, 1.13

    Das Aktualisieren des Clusterknoten-Replikats funktioniert nicht, nachdem Autoscaling auf dem Knotenpool deaktiviert wurde

    Knotenpoolpools werden nicht aktualisiert, nachdem Autoscaling in einem Knotenpool aktiviert und deaktiviert wurde.


    Workaround:

    Die Annotationen cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size und cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size aus der Maschinenbereitstellung des entsprechenden Knotenpools entfernen.
    Logging und Monitoring 1,11, 1,12, 1,13

    Windows-Monitoring-Dashboards zeigen Daten aus Linux-Clustern an

    Ab Version 1.11 werden auf den vorkonfigurierten Monitoring-Dashboards sowohl im Windows Pod-Status-Dashboard als auch im Windows-Knotenstatus-Dashboard Daten aus Linux-Clustern angezeigt. Dies liegt daran, dass die Windows-Knoten- und Pod-Messwerte auch in Linux-Clustern verfügbar sind.
    Logging und Monitoring 1.10, 1.11, 1.12

    stackdriver-log-forwarder bei konstantem CrashLoopBackOff

    Bei Anthos-Cluster auf VMware-Version 1.10, 1.11 und 1.12 weist stackdriver-log-forwarder DaemonSet möglicherweise CrashLoopBackOff-Fehler auf, wenn fehlerhafte zwischengespeicherte Logs auf dem Laufwerk vorhanden sind.


    Workaround:

    Zur Behebung dieses Problems müssen wir die zwischengespeicherten Logs auf dem Knoten bereinigen.

    1. Zur Vermeidung des unerwarteten Verhaltens skalieren Sie stackdriver-log-forwarder herunter: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
    2. Stellen Sie das Bereinigungs-DaemonSet bereit, um fehlerhafte Segmente zu bereinigen: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
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
EOF
    3. Führen Sie die folgenden Befehle aus, um zu prüfen, ob das Debugging alle Fragmente bereinigt hat. Die Ausgabe der beiden Befehle sollte mit der Knotennummer im Cluster übereinstimmen: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Löschen Sie das Bereinigungs-DaemonSet: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. stackdriver-log-forwarder fortsetzen: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging und Monitoring 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    stackdriver-log-forwarder sendet keine Logs an Cloud Logging

    Wenn Sie in Cloud Logging keine Logs Ihrer Cluster sehen und in den Logs der folgende Fehler auftritt: 

    
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    Wahrscheinlich überschreitet die Logeingaberate das Limit des Logging-Agents, wodurch stackdriver-log-forwarder keine Logs sendet. Dieses Problem tritt in allen Anthos-Cluster auf VMware-Versionen auf.

    Behelfslösung:

    Sie müssen das Ressourcenlimit für den Logging-Agent erhöhen, um dieses Problem zu minimieren.

    1. Öffnen Sie die Ressource stackdriver zum Bearbeiten: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Fügen Sie dem stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu, um die CPU-Anfrage für stackdriver-log-forwarder zu erhöhen : 
      
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      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:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Speichern Sie die Änderungen und schließen Sie den Texteditor.
    4. 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 stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Der Befehl sucht cpu: 1200m, wenn Ihre Änderungen wirksam wurden.
    Sicherheit 1.13

    Der Kubelet-Dienst ist nach NodeReady vorübergehend nicht verfügbar

    Für einen kurzen Zeitraum ist der Knoten bereit, das Kubelet-Serverzertifikat jedoch nicht. kubectl exec und kubectl logs sind in dieser Dauer von zehn Sekunden nicht verfügbar. Dies liegt daran, dass es einige Zeit dauert, bis der neue Genehmiger für Serverzertifikate die aktualisierten gültigen IP-Adressen des Knotens sieht.

    Dieses Problem betrifft nur das kubelet-Serverzertifikat, nicht die Pod-Planung.
    Upgrades und Updates 1.12

    Teilweises Upgrade des Administratorclusters wird das spätere Nutzerclusterupgrade nicht blockieren

    Upgrade des Nutzerclusters ist fehlgeschlagen mit:

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Der Administratorcluster wurde nicht vollständig aktualisiert und die Statusversion ist noch 1.10. Das Nutzercluster-Upgrade auf 1.12 wird durch keine Preflight-Prüfung blockiert und schlägt mit einem Problem mit Versionsverzerrungen fehl.


    Workaround:

    Führen Sie zuerst ein Upgrade des Administratorclusters auf 1.11 und dann den Upgrade des Nutzerclusters auf 1.12 aus.
    Speicher 1.10.0–1.10.5, 1.11.0–1.11.2, 1.12.0

    Datastore meldet fälschlicherweise nicht genügend freien Speicherplatz

    gkectl diagnose cluster-Befehl fehlgeschlagen: 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    Die Validierung des freien Speicherplatzes sollte nicht für vorhandene Clusterknotenpools verwendet werden. Sie wurde versehentlich in gkectl diagnose cluster hinzugefügt.


    Workaround:

    Sie können die Fehlermeldung ignorieren oder die Validierung mit --skip-validation-infra überspringen.
    Betrieb, Netzwerk 1.11, 1.12.0–1.12.1

    Neuen Nutzercluster kann nicht hinzugefügt werden, wenn der Administratorcluster den MetalLB-Load-Balancer verwendet

    Sie können möglicherweise keinen neuen Nutzercluster hinzufügen, wenn Ihr Administratorcluster mit einer MetalLB-Load-Balancer-Konfiguration eingerichtet ist.

    Der Vorgang zum Löschen des Nutzerclusters kann aus irgendeinem Grund hängen bleiben, was zu einer Entwertung der MatalLB-ConfigMap führt. In diesem Zustand kann kein neuer Nutzercluster hinzugefügt werden.


    Workaround:

    Sie können das Löschen des Nutzerclusters erzwingen.
    Installation, Betriebssystem 1.10, 1.11, 1.12, 1.13

    Fehler bei der Verwendung von Container-Optimized OS (COS) für Nutzercluster

    Wenn osImageType für den Administratorcluster cos verwendet und gkectl check-config nach der Erstellung des Administratorclusters und vor der Nutzerclustererstellung ausgeführt wird, würde der Vorgang am folgenden Datum fehlschlagen: 

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    Die für den Nutzercluster check-config erstellte Test-VM verwendet standardmäßig den gleichen osImageType aus dem Administratorcluster. Derzeit ist die Test-VM noch nicht mit COS kompatibel.


    Workaround:

    Verwenden Sie gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast, um die langsame Preflight-Prüfung zu vermeiden, mit der die Test-VM erstellt wird.
    Logging und Monitoring 1.12.0–1.12.1

    Grafana im Administratorcluster kann keine Nutzercluster erreichen

    Dieses Problem betrifft Kunden, die Grafana im Administratorcluster verwenden, um Nutzercluster in Anthos-Cluster auf VMware-Versionen 1.12.0 und 1.12.1 zu überwachen. Es stammt aus einer Abweichung zwischen Pushprox-Client-Zertifikaten in Nutzerclustern und der Zulassungsliste im Pushprox-Server im Administratorcluster. Das Symptom ist „pushprox-client“ in den Nutzerclustern, die Fehlerlogs wie die folgenden ausgeben:

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Workaround:
    Sonstiges 1.11.3

    gkectl repair admin-master stellt nicht die VM-Vorlage bereit, die für die Wiederherstellung verwendet werden soll

    gkectl repair admin-master-Befehl fehlgeschlagen: 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master kann die VM-Vorlage, die zur Reparatur der VM der Administrator-Steuerungsebene verwendet werden soll, nicht abrufen, wenn der Name der VM auf der Administrator-Steuerungsebene mit den Zeichen t, m, p oder l endet.


    Workaround:

    Führen Sie den Befehl mit --skip-validation noch einmal aus.
    Logging und Monitoring 1,11, 1,12, 1,13, 1,14, 1,15

    Cloud-Audit-Logging-Fehler aufgrund einer verweigerten Berechtigung

    Anthos Cloud-Audit-Logging erfordert eine spezielle Berechtigungseinrichtung, die derzeit nur für Nutzercluster automatisch über GKE Hub ausgeführt wird. Es wird empfohlen, mindestens einen Nutzercluster zu haben, der dieselbe Projekt-ID und dasselbe Dienstkonto wie der Administratorcluster für das Cloud-Audit-Logging verwendet. So hat der Administratorcluster die erforderliche Berechtigung für das Cloud-Audit-Logging.

    Wenn der Administratorcluster jedoch mit einem beliebigen Nutzercluster eine andere Projekt-ID oder ein anderes Dienstkonto verwendet, können Audit-Logs aus dem Administratorcluster nicht in die Cloud eingeschleust werden. Das Symptom ist eine Reihe von Permission Denied-Fehlern im Pod audit-proxy im Administratorcluster.


    Workaround:
    Betrieb, Sicherheit 1.11

    gkectl diagnose konnte keine Zertifikate prüfen

    Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten des Nutzerclusters hat, werden bei der Ausführung von gkectl diagnose die folgenden Fehler ausgegeben:

    
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

    Wenn Ihre Workstation keinen Zugriff auf Worker-Knoten des Administratorclusters oder Worker-Cluster-Worker-Knoten hat, werden bei der Ausführung von gkectl diagnose die folgenden Fehler ausgegeben:

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin 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

    Workaround:

    Wenn Sie diese Nachrichten ignorieren können.
    Betriebssystem 1,8, 1,9, 1,10, 1,11, 1,12, 1,13

    /var/log/audit/ belegt Speicherplatz auf VMs

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

    Bestimmte gkectl-Befehle auf der Administratorworkstation, z. B. gkectl diagnose snapshot, tragen zur Speicherplatznutzung bei.

    Ab Anthos v1.8 wird das Ubuntu-Image mit der CIS-Level-2-Benchmark gehärtet. Mit einer der Complianceregeln „4.1.2.2 Achten Sie darauf, dass Audit-Logs nicht automatisch gelöscht werden“ wird die geprüfte Einstellung max_log_file_action = keep_logs sichergestellt. Das führt dazu, dass alle Audit-Regeln auf dem Laufwerk erhalten bleiben.


    Workaround:
    Netzwerk 1.10, 1.11.0–1.11.3, 1.12.0–1.12.2, 1.13.0

    NetworkGatewayGroup Schwebende IP-Adresse steht in Konflikt mit der Knotenadresse

    Nutzer können aufgrund des folgenden Webhook-Fehlers keine NetworkGatewayGroup-Objekte erstellen oder aktualisieren:

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    In betroffenen Versionen kann das Kubelet fälschlicherweise an eine Floating-IP-Adresse binden, die dem Knoten zugewiesen ist, und diese als Knotenadresse in node.status.addresses melden. Der validierende Webhook prüft NetworkGatewayGroup-Floating-IP-Adressen mit allen node.status.addresses-Werten im Cluster und sieht dies als Konflikt.


    Workaround:

    Deaktivieren Sie in demselben Cluster, in dem NetworkGatewayGroup-Objekte erstellt oder aktualisiert werden, den ANG-Validierungs-Webhook vorübergehend und reichen Sie Ihre Änderung ein:

    1. Speichern Sie die Webhook-Konfiguration, damit sie am Ende wiederhergestellt werden kann: 
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Bearbeiten Sie die Webhook-Konfiguration: 
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Entfernen Sie das vnetworkgatewaygroup.kb.io-Element aus der Webhook-Konfigurationsliste und schließen Sie die Änderungen, um sie anzuwenden.
    4. Erstellen oder bearbeiten Sie das NetworkGatewayGroup-Objekt.
    5. Wenden Sie die ursprüngliche Webhook-Konfiguration noch einmal an: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Installation, Upgrades und Updates 1.10.0–1.10.2

    Zeitlimit für Administratorcluster erstellen oder upgraden

    Während des Upgrades kann der Administrator der Steuerungsebene des Administratorclusters während der Erstellung nicht weiterkommen. Die VM der Administrator-Steuerungsebene wird beim Start in eine Endlosschleife versetzt und in der Datei /var/log/cloud-init-output.log wird der folgende Endlosschleife-Fehler angezeigt:

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Dies liegt daran, dass Anthos-Cluster auf VMware versucht, die IP-Adresse des Knotens im Startskript abzurufen. Dabei wird mit grep -v ADMIN_CONTROL_PLANE_VIP die virtuelle IP-Adresse des Administratorclusters übersprungen, die auch der NIC zugewiesen werden kann. Der Befehl überspringt jedoch auch alle IP-Adressen mit einem Präfix der virtuellen IP-Adresse der Steuerungsebene. Dies hat zur Folge, dass sich das Startskript aufhängt.

    Beispiel: Die virtuelle IP-Adresse des Administratorclusters 192.168.1.25. Wenn die IP-Adresse der VM des Steuerungsebene-Clusters dasselbe Präfix hat, z. B. 192.168.1.254, bleibt die VM der Steuerungsebene während der Erstellung hängen. Dieses Problem kann auch ausgelöst werden, wenn die Übertragungsadresse das gleiche Präfix wie die virtuelle IP-Adresse der Steuerungsebene hat, z. B. 192.168.1.255.


    Workaround:

    • Wenn das Zeitlimit für die Erstellung des Administratorclusters auf die Übertragungs-IP-Adresse zurückzuführen ist, führen Sie den folgenden Befehl auf der VM des Steuerungsebenenclusters aus: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      Dadurch wird eine Zeile ohne Übertragungsadresse erstellt und der Bootvorgang wird aufgehoben. Entfernen Sie nach dem Aufheben der Blockierung des Startskripts die hinzugefügte Zeile, indem Sie den folgenden Befehl ausführen: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Wenn der Grund für das Zeitlimit beim Erstellen des Administratorclusters auf die IP-Adresse der VM der Steuerungsebene zurückzuführen ist, können Sie das Startskript nicht entsperren. Wechseln Sie zu einer anderen IP-Adresse und erstellen Sie ein Upgrade auf Version 1.10.3 oder höher.
    Betriebssystem, Upgrades und Updates 1.10.0–1.10.2

    Der Status des Administratorclusters, der das COS-Image verwendet, geht bei einem Upgrade des Administratorclusters oder einer Mastermasterreparatur verloren

    DataDisk kann auf dem Masterknoten des Administratorclusters nicht korrekt bereitgestellt werden, wenn das COS-Image verwendet wird. Der Status des Administratorclusters, der das COS-Image verwendet, geht nach dem Upgrade des Administratorclusters oder der Mastermasterverwaltung verloren. (Administratorcluster mit COS-Image ist ein Vorschaumerkmal)


    Workaround:

    Administratorcluster mit osImageType auf ubuntu_containerd neu erstellen

    Nachdem Sie den Administratorcluster erstellt haben, bei dem osImageType auf Cos festgelegt wurde, rufen Sie den SSH-Schlüssel des Administratorclusters und SSH in den Administrator-Masterknoten ab. Das Ergebnis df -h enthält /dev/sdb1 98G 209M 93G 1% /opt/data. Und das lsblk-Ergebnis enthält -sdb1 8:17 0 100G 0 part /opt/data
    Betriebssystem 1.10

    systemd-resolved schlug beim DNS-Lookup auf .local-Domains fehl

    In Anthos-Cluster auf VMware-Version 1.10.0 werden Namensauflösungen auf Ubuntu standardmäßig an 127.0.0.53 aufgelöst, die in systemd-resolved geprüft werden. Der Grund dafür ist, dass /etc/resolv.conf unter Ubuntu 20.04 in Version 1.10.0 mit /run/systemd/resolve/stub-resolv.conf verknüpft ist, das auf den localhost-DNS-Stub 127.0.0.53 verweist.

    Daher weigert die localhost-DNS-Namensauflösung, die vorgelagerten DNS-Server (in /run/systemd/resolve/resolv.conf angegeben) auf Namen mit einem .local-Suffix zu prüfen, sofern nicht die Namen als Suchdomains angegeben sind.

    Dies führt dazu, dass alle Lookups nach .local-Namen fehlschlagen. Während des Knotenstarts schlägt kubelet beispielsweise keine Images aus der privaten Registry mit dem Suffix .local ab. Die Angabe einer vCenter-Adresse mit dem Suffix .local funktioniert nicht auf einer Administratorworkstation.


    Workaround:

    Sie können dieses Problem für Clusterknoten vermeiden, wenn Sie das Feld searchDomainsForDNS in Ihrer Konfigurationsdatei für den Administratorcluster und die Konfigurationsdatei für den Nutzercluster angeben, um die Domains aufzunehmen.

    Derzeit unterstützt gkectl update das Aktualisieren des Felds searchDomainsForDNS noch nicht.

    Wenn du dieses Feld nicht vor der Clustererstellung eingerichtet hast, musst du SSH in die Knoten einfügen und den lokalen, systemd-auflösungen Stub umgehen. Dazu ändere den symlink von /etc/resolv.conf von /run/systemd/resolve/stub-resolv.conf (das den lokalen 127.0.0.53 von 127.0.0.53 enthält) zu /run/systemd/resolve/resolv.conf (das auf das vorgelagerte DNS verweist): 

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Was die Administrator-Workstation betrifft, unterstützt gkeadm die Angabe von Suchdomains nicht. Sie müssen das Problem daher mit diesem manuellen Schritt umgehen.

    Diese Lösung für nicht beibehaltene Neuerstellungen von VMs Sie müssen diese Problemumgehung immer dann anwenden, wenn VMs neu erstellt werden.
    Installation, Betriebssystem 1.10

    IP-Adresse der Docker-Brücke verwendet 172.17.0.1/16 anstelle von 169.254.123.1/24

    Anthos-Cluster auf VMware geben ein dediziertes Subnetz für die Docker-Brücken-IP-Adresse an, die --bip=169.254.123.1/24 verwendet, sodass das standardmäßige 172.17.0.1/16-Subnetz nicht reserviert wird. In Version 1.10.0 liegt jedoch ein Fehler im Ubuntu-Betriebssystem-Image vor, aufgrund dessen die benutzerdefinierte Docker-Konfiguration ignoriert wurde.

    Daraufhin wählt Docker das Standard-172.17.0.1/16 als Subnetz der Bridge-IP-Adresse aus. Dies kann zu einem IP-Adresskonflikt führen, wenn in diesem IP-Adressbereich bereits Arbeitslasten ausgeführt werden.


    Workaround:

    Um dieses Problem zu umgehen, müssen Sie die folgende systemd-Konfigurationsdatei für „dockerd“ umbenennen und dann den Dienst neu starten:

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Prüfen Sie, ob Docker die richtige Brücken-IP-Adresse nutzt:

    
ip a | grep docker0

    Diese Lösung bleibt nicht bei VM-Neuerstellungen bestehen. Sie müssen diese Problemumgehung immer dann anwenden, wenn VMs neu erstellt werden.
    Upgrades und Updates 1.11

    Upgrade auf 1.11 aufgrund von Stackdriver-Bereitschaft blockiert

    In Anthos-Cluster auf VMware Version 1.11.0 gibt es Änderungen an der Definition benutzerdefinierter Ressourcen im Zusammenhang mit Logging und Monitoring:

    • Gruppenname der benutzerdefinierten Ressource stackdriver von addons.sigs.k8s.io in addons.gke.io geändert.
    • Der Gruppenname der benutzerdefinierten Ressourcen monitoring und metricsserver wurde von addons.k8s.io zu addons.gke.io geändert.
    • Die Spezifikationen der oben genannten Ressourcen werden jetzt anhand ihres Schemas geprüft. Insbesondere müssen die Spezifikation „resourceAttrOverride“ und „storageSizeOverride“ in der benutzerdefinierten Ressource stackdriver den Stringtyp in den Werten der CPU-, Arbeitsspeicher- und Speichergrößenanforderungen und -limits haben.

    Die Änderungen des Gruppennamens werden vorgenommen, um den CustomResourceDefinition-Updates in Kubernetes 1.22 zu entsprechen.

    Wenn Sie keine zusätzliche Logik für die betroffenen benutzerdefinierten Ressourcen haben, müssen Sie nichts unternehmen. Das Upgrade von Anthos-Cluster auf VMware nimmt die Migration der betroffenen Ressourcen auf und behält ihre vorhandenen Spezifikationen nach der Änderung des Gruppennamens bei.

    Wenn Sie jedoch eine Logik ausführen, die die betroffenen Ressourcen anwendet oder bearbeitet, ist besondere Aufmerksamkeit erforderlich. Verweise zuerst auf den neuen Gruppennamen in der Manifestdatei. Beispiel:

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    Zweitens, ob die Spezifikationswerte resourceAttrOverride und storageSizeOverride vom Typ „String“ sind. Beispiel:

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    Andernfalls werden die Änderungen angewendet und können zu einem unerwarteten Status bei der Protokollierung und Überwachung von Komponenten führen. Beispiele für mögliche Symptome:

    • Logs zu Abgleichsfehlern in onprem-user-cluster-controller. Beispiel: 
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Fehler in kubectl edit stackdriver stackdriver, z. B.: 
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Wenn die oben genannten Fehler auftreten, bedeutet das, dass vor der Aktualisierung bereits ein nicht unterstützter Typ gemäß der Stackdriver-CR-Spezifikation vorhanden war. Zur Umgehung des Problems können Sie die Stackdriver-CR unter dem alten Gruppennamen kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver manuell bearbeiten und Folgendes tun:

    1. Ändern Sie die Ressourcenanfragen und -limits in den Stringtyp.
    2. Entfernen Sie alle addons.gke.io/migrated-and-deprecated: true-Annotationen, falls vorhanden.
    Fahren Sie dann mit dem Upgrade fort oder starten Sie ihn neu.

    Betriebssystem 1,7, 1,8, 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15

    COS-VMs zeigen keine IP-Adressen an, wenn VMs durch nicht ordnungsgemäßes Herunterfahren des Hosts verschoben werden

    Wenn ein Fehler auf einem ESXi-Server vorliegt und die vCenter-HA-Funktion für den Server aktiviert wurde, lösen alle VMs auf dem fehlerhaften ESXi-Server den vMotion-Mechanismus aus und werden auf einen anderen normalen ESXi-Server verschoben. Migrierte COS-VMs verlieren ihre IP-Adressen.

    Workaround:

    VM neu starten
    Netzwerk alle Versionen vor 1.14.7, 1.15.0–1.15.3, 1.16.0

    Von Seesaw gesendete GARP-Antwort legt keine Ziel-IP fest

    Für den regelmäßigen, von Seesaw alle 20 Sekunden gesendeten GARP (Gratuitous ARP) wird die Ziel-IP-Adresse im ARP-Header nicht festgelegt. In einigen Netzwerken werden solche Pakete möglicherweise nicht akzeptiert (z. B. Cisco ACI). Nach der Wiederherstellung eines geteilten Gehirns kann es aufgrund der VR-Paketabfälle länger dauern.

    Workaround:

    Lösen Sie sudo seesaw -c failover auf einer der Seesaw-VMs aus, um einen Seeaw-Failover auszulösen. Dadurch sollte der Traffic wiederhergestellt werden.
    Wenn Sie weitere Hilfe benötigen, wenden Sie sich an den Google-Support.