| 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 |
Die Annotation der Ressourcenlinks des registrierten Administratorclusters wird nicht beibehalten
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.
- 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:
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.
- 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
- 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.
- 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
- Führen Sie gemäß der
Anleitung zum Upgrade für Linux-nur Administrator- und Nutzercluster ein Upgrade auf 1.13 aus.
- 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
- 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.
- 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:
- 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
- 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 -
- 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
- 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
- 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
'
- 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
- 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
- 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
'
- 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 |
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,
-
Hängen Sie ein Schlüssel/Wert-Paar wie „foo: bar“ an Ihre SA-Schlüsseldatei an.
-
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:
-
Hängen Sie ein Schlüssel/Wert-Paar wie „foo: bar“ an Ihre SA-Schlüsseldatei an.
-
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 |
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:
-
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"}'
-
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"}'
-
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"}'
-
Rufen Sie PowerShell-Zugriff auf den Knoten ab, entweder über SSH oder die vSphere-Weboberfläche.
-
Legen Sie Umgebungsvariablen fest:
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
- 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
-
Prüfen Sie, ob das Laufwerk
readonly ist:
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
Das Ergebnis sollte True sein.
- Setzen Sie
readonly auf false.
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
-
Löschen Sie den Pod, damit er neu gestartet wird:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
--namespace POD_NAMESPACE
-
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:
- Rufen Sie den Secret-Namen
vsphere-csi-secret ab:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
- 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 \
)\"}}"
- Starten Sie
vsphere-csi-controller neu:
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
- 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 wirdgkectl 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:
- Löschen Sie den Namespace
gke-connect:
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
- 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:
- 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 -
- Rufen Sie den Bereitstellungsnamen
gke-connect-agent ab:
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
- 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:
- Rufen Sie in der Google Cloud Console den Metrics Explorer auf:
Zum Metrics Explorer
- Wählen Sie den Tab Konfiguration aus.
- 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:
- Wählen Sie im Menü Aktive Ressourcen die Option Kubernetes-Container aus.
- Wählen Sie im Menü Aktive Messwertkategorien die Option Anthos aus.
- Wählen Sie im Menü Aktive Messwerte die Option
etcd_network_client_grpc_sent_bytes_total aus.
- 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:
- 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.
- Prüfen Sie die Logs von Anthos Identity und kube-apiserver:
- 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:
- 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:
- 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
- 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
- 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
- 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.
- 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
Behelfslösung:
- Verwenden Sie das gkectl-Binärprogramm der neuesten verfügbaren Patchversion für die entsprechende Nebenversion, um nach kritischen Clustervorgängen die Sicherung des Administratorclusters auszuführen. Wenn der Cluster beispielsweise eine 1.10.2-Version ausführt, verwenden Sie das Binärprogramm 1.10.5 gkectl, um eine manuelle Sicherung des Administratorclusters auszuführen, wie unter Administratorcluster mit gkectl sichern und wiederherstellen beschrieben.
|
| 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:
Problemumgehungen ansehen
|
| 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-Logskubectl 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:
Problemumgehungen ansehen
Prüfen Sie, ob die Clusterrolle und die Clusterrollenbindung im Administratorcluster fehlen
-
kubectl get clusterrolebindings --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
-
kubectl get clusterrole --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system | grep cluster-autoscaler
Wenden Sie die folgenden Clusterrollen- und Clusterrollenbindungen auf den Administratorcluster an, wenn sie fehlen. Fügen Sie die Dienstkonto-Subjekte der Clusterrollenbindung für jeden Nutzercluster hinzu.
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-autoscaler
rules:
- apiGroups: ["cluster.k8s.io"]
resources: ["clusters"]
verbs: ["get", "list", "watch"]
- apiGroups: ["cluster.k8s.io"]
resources: ["machinesets","machinedeployments", "machinedeployments/scale","machines"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["onprem.cluster.gke.io"]
resources: ["onpremuserclusters"]
verbs: ["get", "list", "watch"]
- apiGroups:
- coordination.k8s.io
resources:
- leases
resourceNames: ["cluster-autoscaler"]
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- nodes
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups:
- ""
resources:
- pods
verbs: ["get", "list", "watch"]
- apiGroups:
- ""
resources:
- pods/eviction
verbs: ["create"]
# read-only access to cluster state
- apiGroups: [""]
resources: ["services", "replicationcontrollers", "persistentvolumes", "persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["daemonsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
resources: ["poddisruptionbudgets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
# misc access
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["cluster-autoscaler-status"]
verbs: ["get", "update", "patch", "delete"]
-
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: cluster-autoscaler
name: cluster-autoscaler
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-autoscaler
subjects:
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_1
- kind: ServiceAccount
name: cluster-autoscaler
namespace: NAMESPACE_OF_USER_CLUSTER_2
...
|
| 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-Logskubectl 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-Logskubectl 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:
Problemumgehungen ansehen
Wenden Sie die folgende YAML-Datei auf den Administratorcluster an.
- Für vsphere-metrics-exporter
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: vsphere-metrics-exporter
rules:
- apiGroups:
- cluster.k8s.io
resources:
- clusters
verbs: [get, list, watch]
- apiGroups:
- ""
resources:
- nodes
verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: vsphere-metrics-exporter
name: vsphere-metrics-exporter
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: vsphere-metrics-exporter
subjects:
- kind: ServiceAccount
name: vsphere-metrics-exporter
namespace: kube-system
- Für Cluster-Health-Controller
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-health-controller-role
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
|
| 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:
Problemumgehungen ansehen
Damit das Update wirksam wird, müssen die Maschinen afterdas fehlgeschlagene Update neu erstellen.
Für eine Aktualisierung des Administratorclusters müssen die Nutzermaster- und Administrator-Add-on-Knoten neu erstellt werden
Für die Aktualisierung von Nutzerclustern müssen Nutzer-Worker-Knoten neu erstellt werden
So erstellen Sie Nutzer-Worker-Knoten neu
Option 1
Aktualisieren Sie einen Knotenpool und ändern Sie die CPU oder den Arbeitsspeicher, um eine rollierende Neuerstellung der Knoten auszulösen.
Option 2
Verwenden Sie kubectl, um die Maschinen nacheinander neu zu erstellen.
kubectl delete machines MACHINE_NAME --kubeconfig USER_KUBECONFIG
So erstellen Sie Nutzermasterknoten neu
Option 1
Ändern Sie die Größe der Steuerungsebene und ändern Sie die CPU oder den Arbeitsspeicher, um eine rollierende Neuerstellung der Knoten auszulösen.
Option 2
Verwenden Sie kubectl, um die Maschinen nacheinander neu zu erstellen.
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
So erstellen Sie Administrator-Add-on-Knoten
Mit kubectl delete die Maschinen nacheinander neu erstellen
kubectl delete machines MACHINE_NAME --kubeconfig ADMIN_KUBECONFIG
|
| Installation, Upgrades und Updates |
1.13.0–1.13.8, 1.14.0–1.14.4, 1.15.0 |
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:
- Fügen Sie der Konfigurationsdatei des Nutzerclusters die folgenden Felder hinzu:
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
- 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
- Öffnen Sie die benutzerdefinierte Ressource
OnPremAdminCluster zum Bearbeiten:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit onpremadmincluster -n kube-system
- Fügen Sie der benutzerdefinierten Ressource die folgende Annotation hinzu:
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
- Bearbeiten Sie das Manifest
kube-controller-manager in der Steuerungsebene des Administratorclusters:
- Stellen Sie eine SSH-Verbindung zum Knoten der Steuerungsebene des Administratorclusters her.
- Öffnen Sie das Manifest
kube-controller-manager zum Bearbeiten:
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
- Suchen Sie die Liste der
controllers:
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
- Aktualisieren Sie diesen Abschnitt wie unten dargestellt:
--controllers=*,bootstrapsigner,tokencleaner
- Öffnen Sie den Deployment Cluster API-Controller zum Bearbeiten:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
edit deployment clusterapi-controllers -n kube-system
- Ä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:
Problemumgehungen ansehen
Führen Sie die folgenden Befehle aus, um das Problem zu beheben.
Skalieren Sie zuerst den monitoring-operator herunter, damit die Änderungen am cert-manager-Deployment nicht rückgängig gemacht werden:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=0
Bearbeiten Sie die Bereitstellung cert-manager-cainjector, um die Leader-Auswahl zu deaktivieren, da nur ein Replikat ausgeführt wird. Für ein einzelnes Replikat ist es nicht erforderlich:
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit \
-n kube-system deployment cert-manager-cainjector
Das relevante YAML-Snippet für die Bereitstellung cert-manager-cainjector sollte so aussehen:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Lassen Sie monitoring-operator Replikate zur Risikominimierung bei 0, bis die Installation abgeschlossen ist. Andernfalls wird die Änderung rückgängig gemacht.
Wenn die Installation abgeschlossen ist und der Cluster ausgeführt wird, aktivieren Sie monitoring-operator für Vorgänge nach Tag 2:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system \
scale deployment monitoring-operator --replicas=1
Nach jedem Upgrade werden die Änderungen rückgängig gemacht. Führen Sie dieselben Schritte noch einmal aus, um das Problem so lange zu beheben, bis es in einer zukünftigen Version behoben wird.
|
| 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:
Problemumgehungen ansehen
Achten Sie darauf, dass OpenSSL auf der Administrator-Workstation installiert ist, bevor Sie beginnen.
- Legen Sie die Variable
KUBECONFIG fest:
KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG durch den absoluten Pfad zur kubeconfig-Datei des Administratorclusters.
- Rufen Sie die IP-Adresse und die SSH-Schlüssel für den Administrator-Masterknoten ab:
kubectl --kubeconfig "${KUBECONFIG}" get secrets \
-n kube-system sshkeys \
-o jsonpath='{.data.vsphere_tmp}' | base64 -d > \
~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key
export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" \
get nodes -o \
jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
--selector='node-role.kubernetes.io/master')
- Prüfen Sie, ob die Zertifikate abgelaufen sind:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
Wenn die Zertifikate abgelaufen sind, müssen Sie sie vor dem Upgrade des Administratorclusters verlängern.
- Da der Administratorcluster kubeconfig auch bei Ablauf der Administratorzertifikate abläuft, sollten Sie diese Datei vor dem Ablauf sichern.
- Sichern Sie die kubeconfig-Datei des Administratorclusters:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf
vi "${KUBECONFIG}"
- Ersetzen Sie
client-certificate-data und client-key-data in kubeconfig durch client-certificate-data und client-key-data in der von Ihnen erstellten Datei new_admin.conf.
- Alte Zertifikate sichern Dieser Schritt ist optional, wird aber empfohlen:
# ssh into admin master if you didn't in the previous step
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo tar -czvf backup.tar.gz /etc/kubernetes
logout
# on worker node
sudo scp -i ~/.ssh/admin-cluster.key \
ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
- Verlängern Sie die Zertifikate mit kubeadm:
# ssh into admin master
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
# on admin master
sudo kubeadm alpha certs renew all
- Starten Sie statische Pods neu, die auf dem Administrator-Masterknoten ausgeführt werden:
# on admin master
cd /etc/kubernetes
sudo mkdir tempdir
sudo mv manifests/*.yaml tempdir/
sleep 5
echo "remove pods"
# ensure kubelet detect those change remove those pods
# wait until the result of this command is empty
sudo docker ps | grep kube-apiserver
# ensure kubelet start those pods again
echo "start pods again"
sudo mv tempdir/*.yaml manifests/
sleep 30
# ensure kubelet start those pods again
# should show some results
sudo docker ps | grep -e kube-apiserver -e kube-controller-manager \
-e kube-scheduler -e etcd
# clean up
sudo rm -rf tempdir
logout
- Sie müssen die verlängerten Zertifikate und das Zertifikat von kube-apiserver validieren. Prüfen Sie den Ablauf der Zertifikate:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \
"sudo kubeadm alpha certs check-expiration"
- Prüfen Sie das Zertifikat von kube-apiserver:
# Get the IP address of kube-apiserver
cat $KUBECONFIG | grep server
# Get the current kube-apiserver certificate
openssl s_client -showcerts -connect : \
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
> current-kube-apiserver.crt
# check expiration date of this cert
openssl x509 -in current-kube-apiserver.crt -noout -enddate
|
| 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:
- Das Problem wird in vCenter Version 7.0U2 und höher behoben.
- 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
- Deinstallieren Sie Ihre Version von
cert-manager. Wenn Sie eigene Ressourcen definiert haben, können Sie diese sichern
.
- Führen Sie das Upgrade aus.
- 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:
- 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"'
- 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:
Problemumgehungen ansehen
Führen Sie ein Upgrade auf Version 1.10.2/1.9.5 oder höher aus.
So beheben Sie das Problem bei einer früheren Version:
- Skalieren Sie „ Stackdriver-Operator“ herunter:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
scale deployment stackdriver-operator --replicas=0
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
- Öffnen Sie die ConfigMap
gke-metrics-agent-conf zum Bearbeiten:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system \
edit configmap gke-metrics-agent-conf
- Erhöhen Sie das Prüfungsintervall von 0,1 Sekunden auf 13 Sekunden:
processors:
disk_buffer/metrics:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-metrics
probe_interval: 13s
retention_size_mib: 6144
disk_buffer/self:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-self
probe_interval: 13s
retention_size_mib: 200
disk_buffer/uptime:
backend_endpoint: https://monitoring.googleapis.com:443
buffer_dir: /metrics-data/nsq-metrics-uptime
probe_interval: 13s
retention_size_mib: 200
- Schließen Sie die Bearbeitungssitzung.
- Ändern Sie die
gke-metrics-agent DaemonSet-Version in 1.1.0-anthos.8:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system set image daemonset/gke-metrics-agent \
gke-metrics-agent=gcr.io/gke-on-prem-release/gke-metrics-agent:1.1.0-anthos.8
|
| 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.
- 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.
- Öffnen Sie die ConfigMap
gke-metrics-agent-conf zum Bearbeiten:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit configmap gke-metrics-agent-conf
- 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
- Schließen Sie die Bearbeitungssitzung.
- 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 Funktionen | Ersetzen |
|---|
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
- Löschen Sie den GKE On-Prem-Knotenstatus im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem Node Status“ gemäß
dieser Anleitung neu.
- Löschen Sie „GKE On-Prem-Knotenauslastung“ im Google Cloud Monitoring-Dashboard. Installieren Sie „GKE On-Prem-Knotenauslastung“ neu. Folgen Sie dazu
dieser Anleitung.
- 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.
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_summarygo_gc_duration_secondsscheduler_scheduling_duration_secondsgkeconnect_http_request_duration_seconds_summaryalertmanager_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_byteskubernetes.io/anthos/container_cpu_usage_seconds_totalkubernetes.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.
- Öffnen Sie die Ressource
stackdriver zum Bearbeiten:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- 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
- Speichern Sie die Änderungen und schließen Sie den Texteditor.
- Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset gke-metrics-agent -o yaml \
| grep "cpu: 50m"
Der Befehl sucht cpu: 50m, wenn Ihre Änderungen wirksam wurden.
|
| 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:
Problemumgehungen ansehen
Wenn dieser Fehler auftritt, führen Sie die folgenden Schritte aus, um das Problem bei der Clusterregistrierung zu beheben. Anschließend können Sie den Administratorcluster upgraden.
- Führen Sie
gkectl update admin aus, um den Administratorcluster mit dem richtigen Dienstkontoschlüssel zu registrieren.
- Erstellen Sie ein dediziertes Dienstkonto zum Patchen der benutzerdefinierten Ressource
OnPremAdminCluster.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
# Create Service Account modify-admin
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: modify-admin
namespace: kube-system
EOF
# Create ClusterRole
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: null
name: modify-admin-role
rules:
- apiGroups:
- "onprem.cluster.gke.io"
resources:
- "onpremadminclusters/status"
verbs:
- "patch"
EOF
# Create ClusterRoleBinding for binding the permissions to the modify-admin SA
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
creationTimestamp: null
name: modify-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: modify-admin-role
subjects:
- kind: ServiceAccount
name: modify-admin
namespace: kube-system
EOF
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad Ihrer kubeconfig-Datei des Administratorclusters.
- Führen Sie diese Befehle aus, um die benutzerdefinierte Ressource
OnPremAdminCluster zu aktualisieren.
export KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
SERVICE_ACCOUNT=modify-admin
SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} \
-n kube-system -o json \
| jq -Mr '.secrets[].name | select(contains("token"))')
TOKEN=$(kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data.token' | base64 -d)
kubectl get secret ${SECRET} -n kube-system -o json \
| jq -Mr '.data["ca.crt"]' \
| base64 -d > /tmp/ca.crt
APISERVER=https://$(kubectl -n default get endpoints kubernetes \
--no-headers | awk '{ print $2 }')
# Find out the admin cluster name and gkeOnPremVersion from the OnPremAdminCluster CR
ADMIN_CLUSTER_NAME=$(kubectl get onpremadmincluster -n kube-system \
--no-headers | awk '{ print $1 }')
GKE_ON_PREM_VERSION=$(kubectl get onpremadmincluster \
-n kube-system $ADMIN_CLUSTER_NAME \
-o=jsonpath='{.spec.gkeOnPremVersion}')
# Create the Status field and set the gkeOnPremVersion in OnPremAdminCluster CR
curl -H "Accept: application/json" \
--header "Authorization: Bearer $TOKEN" -XPATCH \
-H "Content-Type: application/merge-patch+json" \
--cacert /tmp/ca.crt \
--data '{"status": {"gkeOnPremVersion": "'$GKE_ON_PREM_VERSION'"}}' \
$APISERVER/apis/onprem.cluster.gke.io/v1alpha1/namespaces/kube-system/onpremadminclusters/$ADMIN_CLUSTER_NAME/status
- Versuchen Sie noch einmal, den Administratorcluster mit dem Flag
--disable-upgrade-from-checkpoint zu aktualisieren.
gkectl upgrade admin --config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--disable-upgrade-from-checkpoint
Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad der Konfigurationsdatei Ihres Administratorclusters.
|
| 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:
Problemumgehungen ansehen
Wenden Sie eine DaemonSet-Ressource an. Beispiel:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fix-cos-noexec
namespace: kube-system
spec:
selector:
matchLabels:
app: fix-cos-noexec
template:
metadata:
labels:
app: fix-cos-noexec
spec:
hostIPC: true
hostPID: true
containers:
- name: fix-cos-noexec
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
set -ex
while true; do
if ! $(nsenter -a -t 1 findmnt -l | grep -qe "^/var/lib/kubelet\s"); then
echo "remounting /var/lib/kubelet with exec"
nsenter -a -t 1 mount --bind /var/lib/kubelet /var/lib/kubelet
nsenter -a -t 1 mount -o remount,exec /var/lib/kubelet
fi
sleep 3600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
|
| 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.
- 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.
- 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
- 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
- Löschen Sie das Bereinigungs-DaemonSet:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system delete ds fluent-bit-cleanup
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.
- Öffnen Sie die Ressource
stackdriver zum Bearbeiten:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system edit stackdriver stackdriver
- Fügen Sie dem
stackdriver-Manifest den folgenden resourceAttrOverride-Abschnitt hinzu, um die CPU-Anfrage für 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
- Speichern Sie die Änderungen und schließen Sie den Texteditor.
- Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
--namespace kube-system get daemonset 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 |
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:
Problemumgehungen ansehen
führen Sie die folgenden Schritte aus:
- Monitoring-Operator-Deployment im Kube-System-Namespace des Administratorclusters herunterskalieren
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system scale deploy monitoring-operator \
--replicas=0
- Bearbeiten Sie die ConfigMap
pushprox-server-rbac-proxy-config im Administratorcluster-Namespace.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--namespace kube-system edit cm pushprox-server-rbac-proxy-config
Suchen Sie die Zeile principals für den Listener external-pushprox-server-auth-proxy und korrigieren Sie die principal_name für alle Nutzercluster. Entfernen Sie dazu den Teilstring kube-system aus pushprox-client.metrics-consumers.kube-system.cluster.. Die neue Konfiguration sollte so aussehen:
permissions:
- or_rules:
rules:
- header: { name: ":path", exact_match: "/poll" }
- header: { name: ":path", exact_match: "/push" }
principals: [{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster.local"}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.kube-system.cluster."}}},{"authenticated":{"principal_name":{"exact":"pushprox-client.metrics-consumers.cluster."}}}]
- Starten Sie die Bereitstellung
pushprox-server im Administratorcluster und die Bereitstellung pushprox-client in den betroffenen Nutzerclustern neu:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-server
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system rollout restart deploy pushprox-client
- Das Problem sollte mit den vorherigen Schritten behoben werden. Sobald der Cluster auf Version 1.12.2 aktualisiert wurde und das Problem behoben ist, wird der Administratorcluster kube-systemmonitoring-operator vertikal skaliert, sodass er die Pipeline wieder verwalten kann.
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system scale deploy monitoring-operator --replicas=1
|
| 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:
Problemumgehungen ansehen
Zur Behebung dieses Problems kann die Berechtigung durch Interaktion mit dem cloudauditlogging-Hub-Feature eingerichtet werden:
- Prüfen Sie zuerst die vorhandenen Dienstkonten, die für Anthos Cloud-Audit-Logging für Ihr Projekt auf der Zulassungsliste stehen:
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
- Führen Sie je nach Antwort einen der folgenden Schritte aus:
- Wenn der Fehler
404 Not_found angezeigt wird, ist für diese Projekt-ID kein Dienstkonto auf der Zulassungsliste vorhanden. Sie können ein Dienstkonto auf die Zulassungsliste setzen, indem Sie die Funktion cloudauditlogging Hub aktivieren:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Wenn Sie eine Feature-Spezifikation erhalten, die
"lifecycleState": "ENABLED" mit "code":
"OK" und eine Liste der Dienstkonten in allowlistedServiceAccounts enthält, bedeutet dies, dass für dieses Projekt bereits Dienstkonten vorhanden sind. Sie können entweder ein Dienstkonto aus dieser Liste in Ihrem Cluster verwenden oder ein neues Dienstkonto auf die Zulassungsliste setzen:
curl -X PATCH -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging?update_mask=spec.cloudauditlogging.allowlistedServiceAccounts -d \
'{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}'
- Wenn Sie eine Featurespezifikation erhalten, die
"lifecycleState": "ENABLED" mit "code":
"FAILED" enthält, war die Einrichtung der Berechtigung nicht erfolgreich.
Versuchen Sie, die Probleme im Feld description der Antwort zu beheben, oder sichern Sie die aktuelle Zulassungsliste, löschen Sie die Funktion „cloudauditlogging-hub“ und aktivieren Sie sie wieder gemäß Schritt 1 in diesem Abschnitt. Sie können das cloudauditlogging-Hub-Feature folgendermaßen löschen:
curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging
Für obige Befehle gilt:
|
| 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:
Problemumgehungen ansehen
Administratorworkstation
Für die Administratorworkstation können Sie die geprüften Einstellungen so ändern, dass die Logs automatisch rotiert werden und der geprüfte Dienst dann neu gestartet wird:
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
systemctl restart auditd
Mit der obigen Einstellung werden geprüfte Logs automatisch rotiert, sobald mehr als 250 Dateien mit einer Größe von 8 Millionen generiert wurden.
Clusterknoten
Führen Sie für Clusterknoten ein Upgrade auf 1.11.5+, 1.12.4+, 1.13.2+ oder 1.14+ aus. Wenn Sie noch kein Upgrade auf diese Versionen ausführen können, wenden Sie das folgende DaemonSet auf Ihren Cluster an:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: change-auditd-log-action
namespace: kube-system
spec:
selector:
matchLabels:
app: change-auditd-log-action
template:
metadata:
labels:
app: change-auditd-log-action
spec:
hostIPC: true
hostPID: true
containers:
- name: update-audit-rule
image: ubuntu
command: ["chroot", "/host", "bash", "-c"]
args:
- |
while true; do
if $(grep -q "max_log_file_action = keep_logs" /etc/audit/auditd.conf); then
echo "updating auditd max_log_file_action to rotate with a max of 250 files"
sed -i 's/max_log_file_action = keep_logs/max_log_file_action = rotate/g' /etc/audit/auditd.conf
sed -i 's/num_logs = .*/num_logs = 250/g' /etc/audit/auditd.conf
echo "restarting auditd"
systemctl restart auditd
else
echo "auditd setting is expected, skip update"
fi
sleep 600
done
volumeMounts:
- name: host
mountPath: /host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
Hinweis: Diese Änderung der geprüften Konfiguration würde gegen die CIS-Regel 2 der Regel „4.1.2.2 – Sicherstellen, dass Audit-Logs nicht automatisch gelöscht werden“ verstoßen.
|
| 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:
- 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
- Bearbeiten Sie die Webhook-Konfiguration:
kubectl -n kube-system edit validatingwebhookconfiguration \
ang-validating-webhook-configuration
- Entfernen Sie das
vnetworkgatewaygroup.kb.io-Element aus der Webhook-Konfigurationsliste und schließen Sie die Änderungen, um sie anzuwenden.
- Erstellen oder bearbeiten Sie das
NetworkGatewayGroup-Objekt.
- 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:
- Ändern Sie die Ressourcenanfragen und -limits in den Stringtyp.
- 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.
|
