Bekannte Probleme mit Google Distributed Cloud mit Air Gap 1.12.x
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Der Speichercluster für die Volumesicherung verwendet den externen DNS-Server anstelle des Forwarders. Dadurch kann die Volumesicherung keine Object Storage-Endpunkte auf Organisationsebene auflösen. In Version 1.12 erfordert Backup-Traffic neue Routen zu jeder Organisation.
Workaround:
IOs müssen den Speichercluster aktualisieren, um die DNS-Auflösung auf Organisationsebene zu aktivieren und eine Route von den logischen Replikationsschnittstellen (LIFs) zu den Objektspeicher-Endpunkten in jeder Organisation zu erstellen. Kopieren Sie die folgenden Befehle aus dem Bootstrapper und fügen Sie sie ein.
Das Abrufen des Ingress-Gateways des Organisationsadministrators von ONTAP-Knoten schlägt fehl, da keine Route vom Sicherungssubnetz zu den Steuerungsebenen der Organisation vorhanden ist.
Workaround:
IOs müssen den Speichercluster aktualisieren, um die DNS-Auflösung auf Organisationsebene zu aktivieren und eine Route von den logischen Replikationsschnittstellen (LIFs) zu den Objektspeicher-Endpunkten in jeder Organisation zu erstellen. Kopieren Sie die folgenden Befehle aus dem Bootstrapper und fügen Sie sie ein.
Wenn das Sicherungs-Repository keinen Fehlerstatus hat, aber eine Benachrichtigung dafür ausgelöst wird, ist der Benachrichtigungs-Messwert für das Repository möglicherweise fälschlicherweise erhöht worden. Dies ist ein bekanntes Problem in Version 1.12.0, das in Version 1.12.4 behoben wurde. Die Ursache für dieses Problem ist, dass das Sicherungs-Repository regelmäßig versucht, eine Verbindung zum Objektspeicher herzustellen, um den Systemstatus zu prüfen. Wenn die Verbindung fehlschlägt, wird der Status „Nicht fehlerfrei“ festgelegt. Wenn das Sicherungs-Repository jedoch wiederhergestellt wird, wird der Messwert für den Systemstatus nicht richtig zurückgesetzt, sodass die Benachrichtigung auf unbestimmte Zeit ausgelöst wird.
Um dieses Problem zu beheben, können Sie das Sicherungs-Repository manuell löschen und neu erstellen, um den Integritätsmesswert zurückzusetzen. Folgen Sie der Anleitung im BACK-R0003-Runbook, um das Sicherungs-Repository neu zu erstellen.
Fehlermeldung: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
Die Unterkomponente bil-storage-system-cluster kann aufgrund veralteter Jobs nicht abgeglichen werden. Die billing-storage-system-init-job-628 und billing-storage-system-init-job-629 bleiben nach einem erfolgreichen Abschluss bestehen.
Grafana-Pods in den Namespaces anthos-identity-service-obs-system und platform-obs-obs-system befinden sich aufgrund von Fehlern bei der Volumebereitstellung im Status Init. Die Fehlermeldung in den kubelet-Logs weist auf ein Problem mit mehreren Anhängen hin. Das Problem wird durch einen Fehler in Trident verursacht, bei dem das zugrunde liegende Gerät für LUKS-Zuordnungen nicht richtig identifiziert und überprüft wird, was zu einem Fehler bei der Mehrfachzuordnung führt.
Workaround:
Prüfen Sie, ob der PVC einen deletionTimestamp hat. Wenn kein deletionTimestamp vorhanden ist (Pod-Migration), führen Sie die folgenden Schritte aus:
Sehen Sie in der VolumeAttachment nach der PVC, um herauszufinden, wo das Volume derzeit angehängt ist.
Schließen Sie die Nodes im Cluster aus, die nicht mit diesem Wert übereinstimmen.
Löschen Sie die fehlerhafte Pod. Dadurch sollte sie zur ursprünglichen Node zurückmigriert werden.
Wenn Sie nach der Prüfung feststellen, dass ein deletionTimestamp vorhanden ist (Volume-Löschung), gehen Sie so vor:
Sehen Sie in der VolumeAttachment nach der PVC, um herauszufinden, wo das Volume derzeit angehängt ist.
Geben Sie auf der Node den Inhalt der zugehörigen Tracking-Datei aus:
cat/var/lib/trident/tracking/PVC_NAME.json
Prüfen Sie, ob das LUKS-Gerät, das im Feld devicePath der Tracking-Datei-Ausgabe gefunden wurde, tatsächlich geschlossen ist. Dieser Pfad sollte zu diesem Zeitpunkt nicht vorhanden sein:
statDEVICE_PATH
Prüfen Sie, ob die Seriennummer derzeit einem Multipath-Gerät zugeordnet ist.
Kopieren Sie den Wert im Feld iscsiLunSerial der Tracking-Datei.
Konvertieren Sie diesen Wert in den erwarteten Hex-Wert:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Prüfen Sie mit diesem neuen Wert, ob der Multipath-Eintrag noch vorhanden ist:
multipath-ll|grepSERIAL_HEX
Wenn sie nicht vorhanden ist, löschen Sie die Tracking-Datei.
Wenn sie vorhanden ist, wird ein etwas längerer serieller Hexadezimalwert als der gesuchte Wert angezeigt, der als multipathSerial bezeichnet wird. Führen Sie den folgenden Befehl aus und suchen Sie nach den Blockgeräten:
multipath-llMULTIPATH_SERIAL
Führen Sie dann die folgenden Befehle aus. Der letzte Befehl muss für jedes Blockgerät einzeln ausgeführt werden:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
Die Ausgabe zeigt ein nicht leeres Ergebnis.
Workaround:
Aktivieren oder deaktivieren Sie die Berechtigung für /etc/kubernetes/pki/etcd/ca.crt. Dies ist ein sehr zeitkritischer Vorgang. Die Berechtigung muss nach dem vorherigen Lauf des machine-init-Jobs, aber vor dem nächsten Lauf des machine-init-Jobs erfolgen, da machine-init die Berechtigung wieder auf „root“ setzt.
Starten Sie etcd auf dem zweiten Knoten neu, um etcd auf dem ersten Knoten aus dem Crash-Loop zu beenden.
Nachdem Sie diese beiden Schritte ausgeführt haben, wird die kube-apiserver im ersten Knoten ausgeführt und der nächste machine-init-Job wird erfolgreich abgeschlossen.
Wenn Sie ein Upgrade von Version 1.12.2 auf Version 1.12.4 durchführen und ein Knoten entfernt und dann wieder hinzugefügt wird, schlägt der machine-init-Prozess für diesen Knoten möglicherweise fehl.
Dieser Fehler tritt auf, weil der Netzwerk-Traffic vom neu hinzugefügten Knoten zu wichtigen Diensten der Steuerungsebene durch die Richtlinie ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes abgelehnt wird.
Dieser Fehler wird durch die Statusmeldungen in dieser Beispielausgabe hervorgehoben:
Rufen Sie CIDRs aus CIDRClaim/org-external-cidr -n root ab (insbesondere aus dem Feld .status.ipv4AllocationStatus.allocatedCidrBlocks). Führen Sie den folgenden Befehl im Administratorcluster des Stammverzeichnisses aus:
Fügen Sie diese CIDRs dem ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes und insbesondere dem Feld .spec.ingress.fromCIDR hinzu. Wenden Sie diese Änderung mit dem folgenden Befehl im Stammadministratorcluster an:
CIDRs für die Organisation abrufen (z.B. org-1) aus CIDRClaim/org-external-cidr -n org-1 (insbesondere dem Feld .status.ipv4AllocationStatus.allocatedCidrBlocks). Dieser Befehl wird für den Administratorcluster der obersten Ebene ausgeführt, um die CIDRs für „org-1“ abzurufen:
Fügen Sie diese CIDRs dem ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes und insbesondere dem Feld .spec.ingress.fromCIDR hinzu. Wenden Sie diese Änderung mit dem folgenden Befehl auf den entsprechenden Administratorcluster der Organisation an:
Auf einem Bare-Metal-Knoten des Systemclusters können zwei anetd-Container nicht beendet werden. Nachdem der Prozess zwangsweise beendet und kubelet und containerd neu gestartet wurden, wird der anetd-Pod neu erstellt, aber alle Container bleiben in podInit hängen und containerd meldet die Fehlermeldung:
Dadurch wird verhindert, dass die Container Network Interface (CNI) gestartet wird, und es werden keine weiteren Pods geplant.
Workaround:
Führen Sie diese Maßnahmen aus, um diesen Knotenstatus zu vermeiden:
Planen Sie nicht mehr als 10 PVCs gleichzeitig auf einem einzelnen Knoten. Warten Sie, bis sie gemountet sind, bevor Sie weitere planen. Dies war am deutlichsten beim Erstellen von VMs zu sehen.
Aktualisieren Sie die Datei /etc/lvm/lvm.conf auf jedem Knoten, sodass sie die Zeile filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] im Block devices{} enthält.
Wenn der Knoten in einen Zustand gerät, in dem Zeitüberschreitungen für das Anhängen und Mounten von Volumes auftreten oder ein Volume nicht gelöscht werden kann, prüfen Sie die Anzahl der hängenden vgs-Prozesse auf dem Knoten, um festzustellen, ob sich der Knoten in diesem besonders schlechten Zustand befindet. Die zuverlässigste Methode, einen Knoten in diesem Zustand zu beheben, ist, ihn neu zu starten.
Es gibt einen weiteren Fehlermodus, der auftreten kann. Dieser Fehlermodus hat bei dem Mount-Versuch die folgende Signatur: mount(2) system call failed: No space left on device. Dies ist wahrscheinlich auf die Mount-Weitergabe auf dem Knoten zurückzuführen. Prüfen Sie dies mit dem Befehl cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Wenn einer dieser Werte größer als 1 ist, löschen Sie den Pod, der ihn verwendet. Dadurch sollte das Unmounten ausgelöst werden. Wenn das nicht funktioniert, heben Sie die Bereitstellung des Pfads manuell auf. Wenn das Problem weiterhin besteht, starte das Gerät neu.
In bestimmten Szenarien kann es aufgrund von Race-Bedingungen vorkommen, dass bei der ersten Einrichtung von Google Distributed Cloud (GDC) Air-Gapped die erforderlichen Switch-ACLs für Kubernetes-benutzerdefinierte Ressourcen nicht erstellt werden.
Beim Bereitstellen von Server während der Clustererstellung kann es vorkommen, dass der Server als bereitgestellt markiert wird, aber die Bedingung Provision-Ready fehlt. Daher kann NodePool diesen Server nicht nutzen. Eine Beispiel-Fehlermeldung in NodePool könnte so aussehen:
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
In seltenen Fällen kann es vorkommen, dass das Problem durch das Zurücksetzen von iLO nicht vollständig behoben wird. In diesem Fall muss der Server neu bereitgestellt werden. Die detaillierten Verfahren finden Sie in den Runbooks OS-P0002 und OS-P0003.
Sie finden nxos.10.3.1.bin nicht, aber etwas Ähnliches wie nxos64-cs.10.3.1.F.bin im Bootflash-Verzeichnis des Switches.
Workaround:
Führen Sie auf dem Bootstrapper-Computer die folgenden Schritte aus. Sie müssen diese Schritte ausführen, während die Vorinstallation läuft. Wenn es mehrere /tmp/preinstall-bootstrap--Ordner gibt, wenden Sie die Änderungen auf den aktuellen Ordner an, der vom Vorinstallationsprozess verwendet wird. Sehen Sie dazu in den Logs des Vorinstallationsprozesses nach. Wenn Sie den Vorinstallationsbefehl neu starten müssen, wird dadurch auch ein neuer /tmp/preinstall-bootstrap--Ordner erstellt.
Wechseln Sie zum Ordner /tmp/preinstall-bootstrap-RANDOM_NUMBER:
Suchen Sie im Ordner nach der Datei poap.py.
Entfernen Sie die Zeile mit der MD5-Prüfsumme vollständig aus dieser Datei, sodass head -n 4 poap.py so aussieht:
Das Upgrade von Version 1.11.x auf Version 1.12.1 schlägt fehl, weil der pnet-Controller die benutzerdefinierte Ressource (Custom Resource, CR) hairpinlink nicht erfolgreich generiert.
Workaround:
Bearbeiten Sie nach dem Upgrade im Administratorcluster der obersten Ebene die Datei clusterroles/pnet-core-backend-controllers-role.
Suchen Sie nach hairpinlinks und fügen Sie der Ressource die Berechtigungen create,update,delete hinzu.
Prüfen Sie, ob die CRs hairpinlinks und hairpinbgpsessions generiert wurden.
Dieses Problem wird durch die unsachgemäße Bereinigung des Upgradejobs verursacht. Es sind keine Maßnahmen erforderlich und der Job kann im Absturzschleifenstatus verbleiben.
Das ist ein Problem für Server, auf denen die Zeit nicht synchronisiert wird. Die Konfiguration wird nicht richtig angewendet und muss in einen anderen Namespace geändert werden, damit sie richtig angewendet wird.
Workaround:
Führen Sie die folgenden Schritte für alle Cluster aus:
Vorhandene Betriebssystemrichtlinien auflisten:
kubectlgetospolicies-nntp-system
Die Ausgabe zeigt admin-ntp-policy oder worker-ntp-policy.
Speichern Sie die Richtlinie anhand ihres Namens in einer YAML-Datei:
Bearbeiten Sie die Datei, indem Sie metadata.namespace von ntp-system in gpc-system ändern und status: line und alles danach entfernen.
Wenden Sie die bearbeitete Datei auf den Cluster an:
kubectlapply-fntp-ospolicy.yaml
Warten Sie einige Minuten, bis der Controller die Betriebssystemrichtlinie angewendet hat.
Stellen Sie eine SSH-Verbindung zu einem der Knoten her, auf die die OSPolicy angewendet wird, und führen Sie cat /etc/chrony.conf aus. Die Ausgabe enthält am Anfang der Datei eine Meldung, dass sie von Ansible verwaltet wird und dass die Server nist.time.gov oder ntp.pool aus der Konfiguration entfernt wurden.
Der Sicherungs- und Wiederherstellungsprozess für VMs kann von Nutzern aufgrund falscher rollenbasierter Zugriffssteuerung (Role-based Access Control, RBAC) und Schemaeinstellungen im VM-Manager nicht gestartet werden.
Die Namen von VM-Sicherungsplänen dürfen maximal 63 Zeichen lang sein.
Möglicherweise wird die folgende Fehlermeldung angezeigt:
VM-Sicherungsplannamen sind eine Verkettung des Namens VirtualMachineBackupPlanTemplate, des Ressourcentyps (entweder vm oder vm-disk) und des Namens der Ressource. Dieser verkettete String darf maximal 63 Zeichen lang sein.
Halten Sie die Namen dieser Ressourcen beim Erstellen kurz. Weitere Informationen zum Erstellen dieser Ressourcen finden Sie unter VM-Instanz erstellen und starten und Sicherungsplan für VMs erstellen.
Database Service-Arbeitslasten werden in separaten Projekten im Distributed Cloud-Systemcluster bereitgestellt und konfiguriert. Projekte werden zwar verwendet, um administrative Grenzen in Distributed Cloud zu erzwingen, haben aber keinen Einfluss darauf, wie und wo eine Arbeitslast ausgeführt wird. Daher können diese Arbeitslasten die zugrunde liegende Recheninfrastruktur mit anderen Datenbankinstanzen und verschiedenen Steuerungsebenensystemen gemeinsam nutzen.
Workaround:
Für Datenbankarbeitslasten, die zusätzliche Isolation erfordern, können Nutzer die Erstellung eines Knotenpools im Systemcluster anfordern. Dieser Knotenpool, auf den bei der Projekterstellung verwiesen werden muss, sorgt dafür, dass Datenbankarbeitslasten auf einer dedizierten Recheninfrastruktur bereitgestellt und ausgeführt werden. Die Konfiguration des isolierten Knotenpools muss vom Infrastruktur-Operator abgeschlossen werden.
Wenn in AlloyDB Omni-Version 15.2.1 mehrere AlloyDB Omni-Cluster auf demselben Knoten erstellt werden, bleibt der zuletzt erstellte Cluster im Status „Abgleichen“ hängen. PostgreSQL-Logs mit Befehl abrufen
Bei der Bereitstellung für Kunden muss der Administratornutzername der secret.yaml-Datei admin sein. Stattdessen enthält die Datei nach der ersten Erstellung TO-BE-FILLED. Der admin-Nutzername muss verwendet werden, um die erste Konfiguration auf der Firewall zu initialisieren, und zwar über die Loopback-IP admin\admin.
Workaround:
Prüfen Sie, ob TO-BE-FILLED in den folgenden Firewallanmeldedaten vorhanden ist:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Prüfen Sie, ob alle Firewall-Administratorkonten den Nutzernamen admin haben.
Standardmäßige IDPS-Firewallrichtlinien unterstützen die benutzerdefinierten IPs der Organisation für die Direct Connect-Verbindung nicht. Daher schlägt die Erstellung von Organisationen mit benutzerdefinierten IPs fehl, weil die benutzerdefinierten IPs keine Verbindung zu Harbor im Root-Administrator herstellen können.
Workaround:
Um den Traffic zu entsperren, erstellen Sie manuell eine SecurityPolicyRule für die benutzerdefinierten IP-Adressen der Organisation und stellen Sie sie auf den IDPS-Firewalls bereit. Führen Sie die Schritte im Runbook FW-G0002 aus, um die folgenden Schritte auszuführen:
1. Erstellen Sie einen eingehenden SecurityPolicyRule im virtuellen Root-Firewallsystem, damit die benutzerdefinierten IPs der Organisation auf Root-Harbor zugreifen können.
2. Erstellen Sie eine SecurityPolicyRule für eingehenden Traffic in der Firewall des Organisations-Vsys, damit der Root-Nutzer auf den API-Server der Organisation zugreifen kann.
Aufgrund eines bekannten Problems in CipherTrust Manager sind deaktivierte Testlizenzen weiterhin erkennbar und können fälschlicherweise Ablaufwarnungen auslösen.
Workaround:
Prüfen Sie anhand von HSM-R0003 die aktiven regulären Lizenzen und löschen Sie die deaktivierten Testlizenzen.
Das Hardwaresicherheitsmodul (HSM) führt beim Löschen eines KMS CTMKey unerwartete Aktionen aus. Beispiel: Der KMS-Dienst wird für die Organisation möglicherweise nicht gestartet.
Workaround:
Nutzer können die Daten durch Löschen der KMS-Schlüssel anstelle des KMS-Stammschlüssels kryptografisch vernichten. Dies wird als CTMKey dargestellt.
Führen Sie für jede der HSM-Datennetzwerk-IP-Adressen aus dem vorherigen Schritt Folgendes aus:
Exportieren Sie die IP-Adresse in eine Variable namens HSM_DATA_IP:
exportHSM_DATA_IP=HSM_DATA_IP_ADDRESS
Rufen Sie die Webserverzertifikate (Port 443), nae-Serverzertifikate (Port 9000) und kmip-Serverzertifikate (Port 5696) ab und prüfen Sie die Gültigkeit des Zertifikats:
Wenn Sie den ServiceNow-Webhook konfigurieren, führt das dazu, dass Lifecycle Management (LCM) die Änderungen am ConfigMap-Objekt mon-alertmanager-servicenow-webhook-backend und am Secret-Objekt mon-alertmanager-servicenow-webhook-backend im Namespace mon-system noch einmal abgleicht und zurücksetzt.
Workaround:
Pausieren Sie die LCM-Unterkomponente, damit die Änderungen nicht rückgängig gemacht werden:
Rufen Sie die Pfade zu den kubeconfig-Dateien der Administratorcluster des Stamm- und Organisationsadministrators ab. Speichern Sie die Pfade in den Umgebungsvariablen ROOT_ADMIN_KUBECONFIG und ORG_ADMIN_KUBECONFIG.
Pausieren Sie die LCM-Unterkomponente in einem der folgenden Cluster:
Pausieren Sie die LCM-Unterkomponente im Stamm-Administratorcluster:
Einige Messwerte aus den Nutzerclustern werden nicht erhoben. Dieses Problem betrifft die Nutzer-VM-Cluster, nicht den Systemcluster.
Sie können die folgenden Logs vom Prometheus-Server abrufen:
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Im Cortex-Mandanten sind die folgenden Logs verfügbar:
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Workaround:
So können Sie das Problem beheben:
Rufen Sie den Pfad zur kubeconfig-Datei des Clusters ab. Speichern Sie den Pfad in der Umgebungsvariable KUBECONFIG.
Stellen Sie einen Stubs-Dienst in den Nutzer-VM-Clustern bereit:
Messwerte, die für die Grafana-Instanz des Infrastrukturbetreibers vorgesehen sind, können sich in der Grafana-Instanz des Plattformadministrators befinden und umgekehrt. Das Problem wird durch ASM-Load-Balancing-Anfragen über Clustergrenzen hinweg verursacht, die unterschiedliche Standardmandanten haben.
Workaround:
Für den Workaround ist Zugriff auf die private-cloud-Quelle und die Möglichkeit erforderlich, ein Komponentenupdate bereitzustellen. Sie müssen die Mesh-Konfiguration ändern, um den cortex-tenant-Dienst so einzuschränken, dass er nur Traffic vom lokalen Cluster empfängt, und die ASM-Komponente bereitstellen.
Öffnen Sie die Datei manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Stellen Sie das Feld serviceSettings im Feld meshConfig vor.
Beim Upgrade von 1.11.0 auf 1.11.3 schlägt das Knotenupgrade für NodeOSInPlaceUpgradeCompleted fehl.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Workaround:
Melden Sie sich auf der Bare-Metal-Maschine an, die aktualisiert wird. Prüfen Sie, ob fstab/boot/efi enthält und das Verzeichnis eingebunden ist:
Führen Sie mount -a aus und prüfen Sie, ob das Verzeichnis eingebunden ist:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Fahren Sie hier mit den Prüfungen fort. Führen Sie folgende Befehle aus:
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Wenn nicht alle Dateien identisch sind, führen Sie diesen Befehl auf dem Computer aus und wiederholen Sie die Prüfungen.
Das Clusterupgrade hängt seit über einer Stunde. Der Status und die Spezifikation des Wartungsmodus der Bare-Metal-Maschine stimmen nicht überein. Beispielsweise mit dem Befehl:
Eine VM-Neustartaufgabe schlägt nach der manuellen Problemumgehung für den os-policy-Pod fehl. Die folgende Meldung wird angezeigt:
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Workaround:
Durch das Beenden und Starten der VM wird das Problem behoben. Folgen Sie der Anleitung unter VM starten und beenden.
Während eines Upgrades wird die OPA Gatekeeper-Unterkomponente nicht im Systemcluster installiert. Es werden jedoch Einschränkungen und Webhooks zur Durchsetzung dieser Einschränkungen installiert.
Mehrere Pods in einem Systemcluster bleiben möglicherweise im Status TaintToleration hängen:
Der Pod mit dem Containernamen istio-proxy ist nicht bereit und hat den Status ImagePullBackOff mit dem Ereignis Back-off pulling image "auto".
Workaround:
Prüfen Sie, ob der mutierende Webhook istio-revision-tag-default im Cluster vorhanden ist. Wenn nicht, warten Sie etwa 10 Minuten, um zu sehen, ob sich das System automatisch wiederherstellt. Wenn nicht, eskaliere das Problem.
Wenn der mutierende Webhook vorhanden ist, löschen Sie den problematischen Pod und prüfen Sie, ob er wieder hochgefahren wird. .spec.containers[].image darf nicht auto sein, sondern muss wie ein echtes Bild aussehen, z. B. gcr.io/gke-release/asm/proxyv2:<image version>.
Beim Upgrade von 1.11.1 auf 1.12.1 kann es sein, dass die von der Log-Komponente bereitgestellten ValidatingWebhookConfigurations, MutatingWebhookConfigurations und MonitoringRules nicht aktualisiert werden.
Workaround:
Sie benötigen kubectl und Zugriff auf das Runbook IAM-R0004, um die KUBECONFIG für den Root-Administratorcluster abzurufen.
Löschen Sie ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook aus dem Administrator-Root-Cluster:
Löschen Sie MonitoringRules audit-logs-alerts, audit-logs-sli-syslog-prober, audit-logs-sli-filelog-prober, audit-logs-sli-fluentbit-to-loki, audit-logs-sli-fluentbit-to-splunk, audit-logs-sli-fluentbit-backlog, audit-logs-sli-loki-ingester-failed-rate, audit-logs-sli-loki-io-up und audit-logs-sli-loki-pa-up aus infra-obs namespace im Administratorcluster des Stammverzeichnisses:
Aufgrund eines Problems im log-infra-backend-preinstall-Job sind Audit-Logs und Betriebs-Logs vom Typ „Loki“ nicht installiert und es werden keine Logs erfasst.
Symptome:
Im Systemcluster kann ein CrashLoopBackoff auftreten:
Erhöhen Sie den Arbeitsspeicher auf jedem Ingester, erhöhen Sie die Anzahl der Ingester oder beides. Dazu stellen Sie ein SubcomponentOverride im Administratorcluster der Organisation bereit, wie im folgenden Beispiel gezeigt:
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. Der Status der Bare-Metal-Maschine zeigt einen check_registry_mirror_reachability_pass-Prüfungsfehler an.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Workaround:
Löschen Sie den Kubernetes-Job, der dem fehlgeschlagenen HealthCheck entspricht.
Beim Upgrade von 1.11.x auf 1.12.x ist eine VM möglicherweise nicht bereit, weil zu viele Pods vorhanden sind. Dadurch wird das Leeren eines Bare-Metal-Knotens blockiert.
Beim Upgrade von 1.11.x auf 1.12.1 enthält NodeUpgrade mehrere Versionen für dasselbe Hardwaremodell, wodurch die Überprüfung des Firmware-Upgrades blockiert wird.
Workaround:
Gehen Sie so vor, um die NodeUpgrade-Kundenrichtlinie spec zu ändern:
Wenn das Upgrade für HPE Gen10-Server (GDC-4D) vorgesehen ist, entfernen Sie die ilo6-Modell-Firmware. Andernfalls entfernen Sie die Firmware des Modells ilo5.
Abschnitt zum Beibehalten des Eintrags mit dem neuesten redfishVersion für jede Beschreibung.
Wenn beispielsweise die beiden folgenden Einträge vorhanden sind, behalten Sie nur den mit 2.98 Oct 10 2023 bei:
Ironic hat ein Zeitlimit erreicht, während auf das Einschalten eines Servers gewartet wurde. Der Status ändert sich von cleaning zu clean failed zu available:
Wenn der Schalter aktiviert ist, wird "On" zurückgegeben.
Workaround:
Entfernen Sie den image-Block von den problematischen Servern und warten Sie, bis die Server wieder den Status „Verfügbar“ haben. Fügen Sie den image-Block wieder hinzu, sobald er verfügbar ist.
Dieses Problem tritt auf, wenn iLO-Fehler ignoriert und die HTTP-Antwort gelesen wird, anstatt sie sofort zurückzugeben. Dies führt zu einer Dereferenzierung eines Nullzeigers.
Knoten sollten sich während eines Upgrades im Wartungsmodus befinden. Wenn ein Knoten gewartet wird, haben Sie möglicherweise nicht genügend Ressourcen, um harbor-db zu planen.
Das Prometheus-Objekt StatefulSet ist falsch konfiguriert. Es verwendet die Speicherklasse standard anstelle von standard-rwo. Dieses Problem führt dazu, dass das StatefulSet-Objekt von Anthos Prometheus aus der Monitoring-Komponente nicht gestartet werden kann.
Das Problem tritt auf, weil der ObservabilityPipeline-Abgleich nur bei der ersten Installation diesen Wert festlegt und der ObsProjectInfra-Abgleich benutzerdefinierte Clusterressourcen überwacht.
Workaround:
Starten Sie die Bereitstellung von fleet-admin-controller im Administratorcluster der Organisation neu, um das Problem zu beheben.
Die mon-common-Unterkomponente muss ein Istio-Telemetrieobjekt im Cluster des Organisationsadministrators bereitstellen, um zu verhindern, dass alle Anfragen für Cortex protokolliert werden. Die Manifestdatei ist jedoch nicht in der Build-Datei enthalten.
Workaround:
Führen Sie die folgenden Schritte aus, um das Istio-Telemetrieobjekt im Administratorcluster der Organisation bereitzustellen:
Erstellen Sie eine YAML-Datei, in der die benutzerdefinierte Ressource (Custom Resource, CR) „Istio Telemetry“ im Namespace mon-system des Administratorclusters der Organisation definiert wird:
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Wenden Sie die Manifestdatei auf den Administratorcluster der Organisation im Namespace mon-system an:
Die Prober-ConfigMap wird mit jeder registrierten Prüfung befüllt.
Folge dem Runbook MON-R2009, um die MON-A0001-Benachrichtigung Blackbox monitoring metrics pipeline down stummzuschalten, da diese Benachrichtigung immer wieder ausgelöst wird.
Beim Upgrade von 1.11.x auf 1.12.x kann es passieren, dass ein Pod zum Herunterladen von Switch-Images im Status ErrImagePull mit der folgenden Warnung hängen bleibt:
Beim Upgrade von 1.11.x auf 1.12.1 blockiert die Hostfirewall das Herunterladen des Switch-Images aufgrund einer Abweichung der von der Hostfirewall verwendeten Schnittstellen.
Workaround:
Wenden Sie die folgende Problemumgehung vor dem Upgrade an, aber nur, wenn Sie ein Upgrade von 1.11.x auf 1.12.x durchführen.
Aktualisieren Sie die Administratorcluster für den Stammadministrator und die Organisation.
Rufen Sie den Namen und Namespace des Knotenpools für Bare-Metal-Knoten des Root-Administrators und Bare-Metal-Knoten des Organisationsadministrators ab. Verwenden Sie für den Root-Administratorcluster die Root-Administrator-kubeconfig. Mit dem folgenden Befehl wird eine Inventarliste der Maschinen erstellt und nach Bare-Metal-Maschinen gefiltert:
Die Felder NODEPOOL_NAME und NODEPOOL_NAMESPACE werden mit der Liste aller Knotenpools im jeweiligen Cluster gefüllt, wenn die obige YAML-Datei bereitgestellt wird.
Eine Beispiel-YAML-Datei für den Stammadministratorcluster mit den tatsächlichen Namen des Stammadministrator-Knotenpools und des Organisationsadministrator-Knotenpools könnte so aussehen:
Netzwerk-Switches, auf denen eine Version vor 9.3.10 vorinstalliert ist, können nicht gebootstrapped werden, da die erwartete Version des Switches 10.3(4a) ist.
Workaround:
Führen Sie ein manuelles Upgrade der Switch-Firmware von 9.3.5 auf 9.3.10 und dann von 9.3.10 auf 10.3.4a durch.
Die LUKS-Unterkomponente (Linux Unified Key Setup) wird während des Upgrades nicht neu bereitgestellt. So prüfen Sie die Unterkomponente file-netapp-trident:
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
In diesem Beispiel sind zwei Speicherklassen fehlgeschlagen: standard-rwo und standard-block.
Workaround:
Löschen Sie die StorageClasses, die vom Job nicht erstellt werden konnten, z. B. standard-rwo, standard-block, standard-rwo-non-luks und standard-block-non-luks.
Lösen Sie die Neuerstellung von StorageClasses aus, indem Sie den oclcm-Backend-Controller für Ihren Cluster neu starten (Root-Administratorcontroller für Root- und Organisationsadministratorcluster, Organisationsadministratorcontroller für System- und Nutzercluster).
Prüfen Sie bei Version 1.12.4, ob die installierten Storage-Klassen die Annotation disk.gdc.goog/luks-encrypted: auf „true“ gesetzt haben (mit Ausnahme der Storage-Klassen ohne LUKS). Wenn die Anmerkung nicht auf „true“ gesetzt ist, wiederholen Sie die Schritte 1 und 2.
Starten Sie die Bereitstellung von netapp-trident und netapp-trident DaemonSet im Cluster neu.
Prüfen Sie, ob das LUKS-Secret für Ihre PersistentVolumeClaim-Ressourcen (PVC) erstellt wurde. Jeder PVC muss ein Secret im Format g-luks-$pvc_name haben.
Prüfen Sie, ob die Unterkomponente file-netapp-trident im Status einen Fehler aufweist.
Knotenpools in Nutzerclustern, die auf Kubernetes-Version 1.27.x ausgeführt werden, werden möglicherweise nicht initialisiert. Dadurch kann der Nutzercluster keine Containerarbeitslasten verarbeiten.
Workaround:
Erstellen Sie keinen Nutzercluster mit der Kubernetes-Version 1.27.x.
VMRuntime im Zielcluster (kann Admin- oder Systemcluster sein) hat den Status „VMRuntime.ready = false“ und network-controller-manager im Namespace kube-system ist ausstehend.
Wenn Sie die Bereitstellung network-controller-manager löschen, sollte sie automatisch mit den erforderlichen Zertifikaten durch den VMM-Operator neu erstellt werden. Die Bereitstellung sollte den Status Running erreichen und der VMRuntime-Status sollte sich anschließend in „ready=true“ ändern.
Die VM-Importer-Pods befinden sich in einer Absturzschleife und das Datenvolumen bleibt länger als 90 Minuten im Importstatus. Der Status der Pods könnte so aussehen:
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Workaround:
Wenn der Fehler auf der Root-Ebene auftritt, ersetzen Sie in den folgenden Schritten KUBECONFIG durch die kubeconfig-Datei des Root-Administrators.
Wenn der Fehler in der Organisation auftritt, ersetzen Sie in den folgenden Schritten KUBECONFIG durch die kubeconfig des Organisationsadministrators.
Die Datei enthält möglicherweise die folgende Meldung im Abschnitt backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Workaround:
Prüfen Sie den Namespace file-system, um zu bestätigen, dass er nicht in org-admin cluster beendet wird:
Pausieren Sie die Unterkomponente file-observability, bis die Unterkomponente mon-admin aktiv ist. Fügen Sie dazu die folgenden Annotationen in die Unterkomponente ein:
Laden Sie ksctl herunter und konfigurieren Sie es.
Führen Sie ksctl system info get --url=https://HSM_MANAGEMENT_IP aus, um zu prüfen, ob alle HSM-Versionen auf .Spec.TargetVersion von ctmclusterupgraderequest aktualisiert wurden:
Aktualisieren Sie das Feld Status.FirmwareVersion jedes HSM auf die im vorherigen Schritt abgerufene aktualisierte Version:
Beispiel:
kubectledit-statushsmHSM_NAME-ngpc-system
Aktualisiere den Status der letzten Bedingung von ctmclusterupgraderequest.status.conditions von False zu True. Danach wird auch der Status der letzten Bedingung hsmupgraderequest.status.conditions auf „Wahr“ gesetzt.
Während eines Upgrades ist die Verwaltungs-IP eines Servers nicht erreichbar, insbesondere nach einem Switch-Betriebssystem-Upgrade.
Bei Rocky Linux muss die Ziel-IP, die zum Erreichen der statischen Routen verwendet wird, erreichbar sein, bevor die statischen Routen hinzugefügt werden. Wenn der Switch nach einem Betriebssystem-Upgrade neu gestartet wird, ist die Verwaltungs-IP möglicherweise vorübergehend nicht erreichbar.
Workaround:
Stellen Sie über die Daten-IP-Adresse eine SSH-Verbindung zum Server her und starten Sie den Netzwerkdienst neu, um die fehlenden statischen Routen neu zu erstellen:
Bei der manuellen Bereitstellung der Organisation gdchservices hat das Ticketsystem keinen funktionierenden Upstream, es werden keine VMs erstellt und der Midserver-Pod ist im Cluster gdchservices-system im Namespace support fehlerhaft.
Workaround:
Erstellen Sie eine neue benutzerdefinierte TicketingSystem-Ressource mit dem richtigen VM-Image im gdchservices-admin-Cluster:
Die neue Unterkomponente muss die folgende Spezifikation haben und in der chatURL muss die Version angezeigt werden, auf die die Cluster bereits aktualisiert wurden:
Wenn der Fehler während der Postflight-Prüfungen auftritt und alle anderen Prüfungen ohne Fehler abgeschlossen wurden, überspringen Sie die Postflight-Prüfungen. Wenn das Upgrade neu gestartet wird, müssen Sie die Preflight-Prüfungen auch mit der kubeconfig des Root-Administrators überspringen:
Wenn der Fehler während der Preflight-Prüfungen auftritt und alle anderen Preflight-Prüfungen ohne Fehler abgeschlossen wurden, überspringen Sie die Preflight-Prüfungen:
Das Portfolio-Schema hat sich in GDC-Version 1.12 geändert. Das Feld portfolioName wurde in portfolioID umgestaltet. Suchen Sie die YAML-Datei mit der in der Fehlermeldung erwähnten benutzerdefinierten Portfolio-Ressource. Benennen Sie das Feld portfolioName in portfolioID um.
Im Folgenden sind die möglichen Gründe dafür aufgeführt, warum für einen Patchjob, für den nur Preflight-Jobs abgeschlossen wurden, kein laufender Job erstellt wird:
Wenn NTP fehlschlägt, können alle anderen Patch-Jobs nicht ausgeführt werden.
Der Knoten befindet sich in einem fehlerhaften Zustand.
Der OS Config-Agent wird nicht ausgeführt.
Der OS Config-Agent kann nicht mit dem OS Config-Dienst kommunizieren.
Es gibt ein Problem mit dem OS Config-Dienst.
Workaround:
Prüfen Sie die benutzerdefinierte Ressource `NodeTargetPolicy` des Knotens.
Suchen Sie nach `.spec.osPolicies` des benutzerdefinierten `NodeTargetPolicy`-Ressourcenobjekts mit `ref.name=admin-ntp-policy` und `type: Ready` mit dem Status „false“:
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
siem-*-preinstall-Jobs im Root- und org-1-Namespace im Root-Administratorcluster schlagen wiederholt fehl.
Workaround:
Es wird erwartet, dass die Jobs fehlschlagen, wenn das Feature-Gate „SIEMComponent“ deaktiviert ist. Die Fehler bedeuten nicht, dass die Komponente defekt ist. Der Abgleich der SIEM-Komponente kann pausiert werden, wenn die Störungen störend sind. Es wird jedoch generell empfohlen, die Komponente nach Möglichkeit aktiviert zu lassen. Wenn der Abgleich der Komponenten pausiert ist, muss er manuell wieder aktiviert werden, wenn die Installation der SIEM-Komponente bei zukünftigen Upgrades nicht mehr eingeschränkt ist.
Möglicherweise gibt es Probleme mit vgs, blkid und gather_facts von Ansible reagiert nicht. Dieses Problem betrifft sowohl Rocky als auch Ubuntu.
Führen Sie diese Schritte aus, wenn die Knoten bereits aktualisiert wurden. Der Prozess zum Aktualisieren der Datei lvm.conf umfasst die folgenden Schritte:
Rufen Sie eine Liste aller Knoten ab, damit dieser Fix auf alle angewendet werden kann.
Erstellen Sie ein Ansible-Playbook und eine OS Policy-Datei.
Wenden Sie die Korrektur auf die Knoten an.
Prüfen Sie, ob die Korrektur angewendet wurde.
Voraussetzungen:
Folgen Sie der Anleitung im IAM-R0004-Runbook, um die ROOTCONFIG für den Root-Administratorcluster und die ORGCONFIG für den Organisationsadministratorcluster zu generieren.
Folgen Sie der Anleitung im IAM-R0005-Runbook, um die folgenden Rollen der Organisation zu erhalten.
Workaround:
Ermitteln Sie die InventoryMachines, die den Clustern entsprechen:
Halten Sie die Ausgabe getrennt. Beheben Sie jeweils nur einen Cluster. Die Ausgabe könnte so aussehen:
NAME
bm-2bca8e3f
bm-4caa4f4e
Playbook und Richtliniendatei erstellen:
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
Der vorherige Inventarabschnitt muss wie in diesem Beispiel ausgefüllt werden.
Fügen Sie für jeden Knoten, den Sie in Schritt 1 gefunden haben, einen Absatz hinzu. Sie bearbeiten jeweils einen Cluster. Füllen Sie den Inventarbereich also mit Knoten für einen Cluster aus.
Starten Sie den Server neu, damit die neue Einstellung wirksam wird.
Folgen Sie der Anleitung im OS-P0005-Runbook, um zu prüfen, ob die Knoten aktualisiert wurden.
Nachdem Sie bestätigt haben, dass die Richtlinie erfolgreich abgeschlossen wurde, löschen Sie sie mit dem k9s-Tool:
Rufen Sie die Betriebssystemrichtlinien auf, z. B. :ospolicies.
Suchen Sie die lvm-conf-device-filter-node-update-Richtlinie und wählen Sie sie aus.
Drücken Sie Strg + D.
Bestätigen Sie den Löschvorgang.
Wenn Sie dieses Problem eskalieren möchten, erstellen Sie ein Ticket mit dem Runbook SUPP-G0008.
Das Ticket sollte unter anderem die folgenden Informationen enthalten:
Dieses Problem tritt auf, wenn die Umgebung zuvor mit Version 1.11 bereitgestellt und dann auf Version 1.12 aktualisiert wurde. Wenn Sie einen neuen Cluster oder eine neue Organisation in einer Version 1.12.x erstellen, wird für die Bereitstellung von Bare Metal- und VM-Knoten das Rocky-Betriebssystem anstelle des Ubuntu-Betriebssystems ausgewählt, da die Rocky-Betriebssystemversion in den CRs ReleaseMetadata und Userclustermetadata angegeben ist.
Workaround:
Wenden Sie den folgenden Workaround an, bevor Sie eine neue Organisation erstellen:
Prüfen Sie, ob es OrganizationUpgrade-CRs gibt, die nicht den Status Succeeded: true haben:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
Wenn das der Fall ist, eskaliere den Fall an das Technikteam, bevor du mit den nächsten Schritten fortfährst.
Entfernen Sie alle vorhandenen OrganizationUpgrade-CRs, um versehentliche Knoten-Betriebssystem-Upgrades zu vermeiden:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Definieren Sie die Ziel-GDC-Version für die Erstellung der neuen Organisation. Für diese Zielversion sollte es entsprechende ReleaseMetadata geben:
TARGET_RELEASE=
Ermitteln Sie die neueste OSImageMetadata-CR für das Ziel-Ubuntu-Betriebssystem im Administratorcluster des Stammverzeichnisses und definieren Sie die Variable OS_VERSION:
Achten Sie darauf, dass die Variable dieselbe Haupt-, Neben- und Patchversion wie TARGET_RELEASE verwendet, z.B.1.12.4. Falls nicht, eskaliere den Fall an das Engineering-Team, bevor du mit den nächsten Schritten fortfährst.
Aktualisieren Sie das Ziel ReleaseMetadata, damit das Ubuntu-OS_VERSION im Administrator-Root-Cluster verwendet wird:
Aktualisieren Sie das Ziel-UserclusterMetadata, um das Ubuntu-OS_VERSION im Stamm-Administratorcluster und im Administratorcluster der Organisation für jede Organisation zu verwenden. Führen Sie den folgenden Befehl für jeden Cluster aus:
Wenn lokale VM-Images mit der gdcloud compute images import-CLI importiert werden, bleibt der Importstatus bei WaitingForTranslationVM oder ImportJobNotCreated hängen. Das liegt daran, dass das temporäre Laufwerk, das für die Übersetzung oder den Import erstellt wird, genau die gleiche Größe wie das qcow2- oder Rohbild hat. LUKS fügt jedoch einen Overhead von einigen MiB hinzu, wodurch die Laufwerksbereitstellung fehlschlägt.
Workaround:
Erstellen Sie manuell ein neues VirtualMachineImageImport mit demselben Bildnamen, aber mit einem größeren spec.minimumDiskSize. Wenn das Image beispielsweise mit dem folgenden Befehl importiert wurde:
Wenn die ursprüngliche VirtualMachineImageImport, die automatisch von der CLI erstellt wurde, minimumDiskSize als X Gi hat, erstellen Sie eine neue mit X+1 Gi. Der Wert basiert auf der Größe des importierten Bilds. Bei qcow2 wäre es die virtuelle Größe, z. B. sollte 20Gi durch 21Gi ersetzt werden.
Ersetzen Sie die Platzhalterwerte entsprechend dem Aufruf der CLI.
Wenn das Objekt nicht vorhanden ist, lösen Sie den Befehl gdcloud compute images import ... noch einmal aus. Wenn die Konsolenausgabe von Uploading image to ... zu Image import has started for ... wechselt, drücken Sie Strg + C, damit das lokale Bild in den Objektspeicher hochgeladen wird und die VirtualMachineImageImport zur Referenzierung erhalten bleibt, um eine neue zu erstellen.
Erstellen Sie eine neue VirtualMachineImageImport mit einem größeren minimumDiskSize:
Der Pod importer-image-import-$VMII im Namespace des Systemclusters stürzt mit dem folgenden Fehler ab: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). Das VirtualMachineImageImport-VMII-Objekt hat nach zwei Stunden nach Beginn des Imports den Bedingungstyp Ready mit dem Status False und dem Grund TranslationInProgress.
Workaround:
Um die Geschwindigkeit zu verbessern, ändern Sie die Mindestlaufwerksgröße des Images auf 200 GiB:
Zum Löschen und Anwenden von ValidatingWebhookConfiguration benötigen Sie die kubeconfig-Datei des Clusteradministrators für den Administratorcluster der Organisation. Sie können dieses Runbook unter IAM-R0004 abrufen.
Wenn Sie den Import mit gdcloud starten, kann der Parameter minimumDiskSize nicht angegeben werden. Sie müssen ein VMII-Objekt erstellen und es wie im vorherigen Befehl gezeigt ändern.
Der VirtualMachineImageImport-Prozess wird fortgesetzt, bleibt aber in einem späteren Schritt wieder hängen. Im Namespace des Projekts im Systemcluster sehen Sie, dass der Job image-import-$VMII immer wieder mit dem Fehler error: stream error: stream ID x; NO_ERROR; received from peer fehlschlägt. An diesem Punkt ist der Bildimport abgeschlossen. Das endgültige Bild wird in den Objektspeicher hochgeladen, aber VirtualMachineImage fehlt. So erstellen Sie manuell ein VirtualMachineImage-Objekt:
`$NAME` muss mit `VMII.ImageMetadata.Name` übereinstimmen und `$OS_NAME` kann einer der folgenden Werte sein: [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`]. Er muss mit dem Typ des importierten Images übereinstimmen.
Die istio-eastwestgateway-Bereitstellung im Namespace istio-system hängt fest. In den Pod-Ereignissen wird der Fehler Back-off pulling image "auto" von kubelet angezeigt.
Prüfen Sie zur Diagnose des Problems, ob die mutatingwebhookconfiguration mit dem Namen istio-revision-tag-default im selben Cluster wie die hängende Gateway-Bereitstellung vorhanden ist.
Wenn die Konfiguration nicht vorhanden ist, warten Sie, bis der Webhook vorhanden ist. Das sollte in Kürze geschehen, da er sich in einer Abgleichsschleife befindet.
Ändern Sie die ConfigMap cortex-config im Systemcluster und legen Sie das Zeitlimit für Memcached im index_cache auf zwei Sekunden fest, sodass die index_cache-Konfiguration so aussieht:
Der Bare-Metal-Knoten wird als NotReady angezeigt und der Server bleibt auf dem Startbildschirm mit der letzten Meldung Retrieving encryption keys hängen.
Workaround:
Starten Sie iLO neu.
Starten Sie den Server neu, nachdem iLO wieder funktioniert.
Der Speicherort des fluent-bit-Installationsprogramms wurde in operations_center\bin\fluent-bit-win64.msi geändert.
Für Copy-ConfigHostFiles.ps1 muss das Client-Installationsprogramm fluent-bit dem Muster fluent-bit-*-win64.* entsprechen.
Das Installationsprogramm kann das Installationsprogramm nicht finden, da das Muster nicht mehr übereinstimmt.
Der Speicherort des Nessus-Installationsprogramms wurde in operations_center\bin\NessusAgent-x64.msi geändert.
Für Copy-ConfigHostFiles.ps1 muss der Name des Clientinstallationsprogramms mit dem Dateinamen /NessusAgent-10.4.1-x64.msi übereinstimmen.
Das Installationsprogramm kann das Installationsprogramm nicht finden, da das Muster nicht mehr übereinstimmt.
Dieses Problem wird durch eine fehlende S3-Endpunktkonfiguration für die neue Organisation verursacht.
Workaround:
Erstellen Sie manuell eine HA-Gruppe für die neue Organisation.
Besorgen Sie sich über das Break-Glass-Verfahren eine kubeconfig-Datei des Root-Administratorclusters, die Lesezugriff auf die folgenden Ressourcen hat:
Rufen Sie die Anmeldedaten für die StorageGRID Management UI aus dem Secret gpc-system/objectstorage-breakglass-root-level1 im Root-Administratorcluster ab.
Melden Sie sich mit den Anmeldedaten aus dem vorherigen Schritt in der StorageGRID Management-Benutzeroberfläche an. Die URL hat den Status ObjectStorageSite:
Rufen Sie den Tab Konfiguration auf und klicken Sie auf Hochverfügbarkeitsgruppen.
Öffnen Sie die Detailansicht jeder HA-Gruppe und notieren Sie sich die virtuelle IP-Adresse (VIPs).
Neue HA-Gruppe erstellen:
Gruppenname: Das Namensmuster ist ORGANIZATION_NAME-ha. In diesem Fall ist es org-2-ha.
Gruppenbeschreibung: Verwenden Sie vorhandene HA-Gruppen für das Beschreibungsmuster.
Schnittstellen: Wählen Sie alle eth2 aus.
Prioritätsreihenfolge: Die primäre Schnittstelle sollte die höchste Priorität haben.
SubnetCIDR: Dieses Feld wird automatisch von StorageGRID ausgefüllt.
Prüfen Sie, ob das Subnetz mit dem status.ipv4SubnetStatus.cidrBlock im SubnetClaimexternal-objectstorage-client-lif-cidr übereinstimmt.
Virtuelle IP: Die nächste IP-Adresse im verfügbaren IP-Bereich. Die IP-Adresse darf nicht mit der reservierten IP-Adresse, der Client-IP-Adresse des Administrator-Knotens und den VIPs vorhandener HA-Gruppen kollidieren.
Rotieren Sie die StorageGRID-Break-Glass-Anmeldedaten.
Beim Upgrade der Stammorganisation von 1.12.2 auf 1.12.4 hat die Unterkomponente iac-gitlab den Status „Wird abgeglichen“.
Prüfen Sie zur Diagnose des Problems die Prometheus-Logs, z. B.:
Wenn dieses Problem während des Upgrades auftritt, löschen Sie den Migrationsjob, da er ein Zeitlimit von 3.600 Sekunden hat, und fahren Sie dann mit dem Upgrade fort:
Sehen Sie sich die vorherige Fehlermeldung an und notieren Sie sich den Namespace und den Namen der Bereitstellung. In diesem Beispiel ist NAMEiam-authzpdp-backend-server und NAMESPACEiam-system.
Notieren Sie sich den Pod, in dem nicht alle Container bereit sind. In diesem Fall ist POD_NAMEiam-authzpdp-backend-server-6875654c4b-pvscg. Einer der beiden Container ist nicht bereit, was durch den Status 1/2 angezeigt wird. Wenn es mehrere solcher Pods gibt, wiederholen Sie den nächsten Schritt für jeden betroffenen Pod.
Löschen Sie den Pod, der nicht vollständig fehlerfrei ist:
kubectldeletepod-nNAMESPACEPOD_NAME>
Führen Sie den Befehl aus Schritt 2 noch einmal aus. Alle Pods sollten jetzt fehlerfrei sein. Dieser Schritt kann einige Minuten dauern.
Wenn der gelöschte Pod nicht durch einen fehlerfreien Pod ersetzt wird, öffnen Sie ein Support-Ticket.
Beim Upgrade der Mandantenorganisation von Version 1.12.2 auf Version 1.12.4 schlägt das Upgrade der Unterkomponente opa gatekeeper mit einem ReconciliationError fehl.
Workaround:
Bearbeiten Sie das mutatingwebhookconfiguration-Objekt edr-sidecar-injector-webhook-cfg des betroffenen Nutzerclusters. Wenn es mehr als einen betroffenen Nutzercluster gibt, wiederholen Sie die Schritte für jeden betroffenen Nutzercluster:
Bearbeiten Sie den Abschnitt webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values, um die folgenden beiden Werte hinzuzufügen:
Beim Upgrade von 1.12.2 auf 1.12.4 wird ansibleplaybook nicht im Rahmen des Clusterupgrades aktualisiert. Die im ansibleplaybook aktualisierten Korrekturen werden nicht angewendet und blockieren die Betriebssystemrichtlinie, in der die vorherige Version des ansibleplaybook ausgeführt wird.
Workaround:
Löschen Sie den Kubernetes-Job create-ansible-playbooks:
Beim Erstellen einer neuen Organisation kann es vorkommen, dass für die core-dns-Unterkomponente in den Logs ein Zeitüberschreitungsfehler angezeigt wird:
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Workaround:
Aktualisieren Sie den gpc-coredns-forwarder-udp-Dienst und den gpc-coredns-forwarder-tcp-Dienst des Root-Administratorclusters und fügen Sie die neuen IP-Bereiche in den Quellbereichen des Load-Balancers hinzu.
Wenn Änderungen am CR überschrieben werden, pausieren Sie die Unterkomponente dns-core mit der Anmerkung lcm.private.gdc.goog/paused="true".
Beim Upgrade von 1.12.2 auf 1.12.4 bleibt die Unterkomponente file-netapp-trident beim Löschen von StorageClasses hängen. Dort wird der folgende Status angezeigt:
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Workaround:
Pausieren Sie die Unterkomponente „file-netapp-trident“:
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Löschen Sie die StorageClasses, die vom Job nicht erstellt werden konnte, z. B. standard-rwo, standard-block, standard-rwo-non-luks und standard-block-non-luks:
Lösen Sie die Neuerstellung von StorageClasses aus, indem Sie den oclcm-backend-Controller für Ihren Cluster neu starten (Root-Administratorcontroller für Root- und Organisationsadministratorcluster, Organisationsadministratorcontroller für System- und Nutzercluster):
Prüfen Sie, ob das LUKS-Secret für Ihre PersistentVolumeClaim-Ressourcen (PVC) erstellt wurde. Jeder PVC muss ein Secret im Format g-luks-$pvc_name haben.
kubectlgetsecret-n$pvc_namespaceg-luks-$pvc_name
Prüfen Sie, ob die Unterkomponente file-netapp-trident im Status keinen Fehler aufweist:
primary-prometheus-shardX-replicaX-Pods sind im Namespace obs-system und im Namespace mon-system sichtbar. Wenn primary-prometheus-shardX-replicaX nach einem Upgrade auf Version 1.12 nur im Namespace obs-system vorhanden ist, handelt es sich um ein anderes unbekanntes Problem und der Workaround sollte nicht ausgeführt werden.
Das beabsichtigte Verhalten ist, dass primary-prometheus-shardX-replicaX erst nach Abschluss des Upgrades auf Version 1.12 im Namespace mon-system vorhanden ist.
Workaround:
Löschen Sie die primary-prometheus-shardX-replicaX-StatefulSets im Namespace obs-system manuell.
Löschen Sie die primary-prometheus-shardX-replicaX-StatefulSets im Namespace mon-system nicht.
Ein ClusterCIDRConfig ist ein erforderliches Objekt, um PodCIDRs zuzuweisen. Obwohl die ClusterCIDRConfig erstellt wurde, wurde die PodCIDRs nicht zugewiesen. Dieses Problem tritt auf, wenn eine ClusterCIDRConfig gleichzeitig mit dem Bootstrapping der ipam-controller-Pods erstellt wird. Die Clustererstellung hängt im Abgleichsstatus fest:
Prüfen Sie, ob das ClusterCIDRConfig-Objekt im Cluster erstellt wurde:
Führen Sie „describe“ für eines der Knotenobjekte des Clusters aus, das im Abgleich hängen geblieben ist, und prüfen Sie, ob im Knotenobjekt ein CIDRNotAvailable-Ereignis vorhanden ist:
Die MonitoringTarget zeigt den Status Not Ready an, wenn Nutzercluster erstellt werden. Dadurch wird in der Benutzeroberfläche für vortrainierte APIs fortlaufend der Status Enabling angezeigt.
Workaround:
Öffnen Sie das Menü in Ihrem Chrome-Browser (Dreipunkt-Symbol).
Klicken Sie auf Weitere Tools > Entwicklertools, um die Console zu öffnen.
Klicken Sie in der Konsole auf den Tab Netzwerk.
Suchen Sie die ai-service-status-Anfragen.
Klicken Sie in einer ai-service-status-Anfrage auf den Tab Antwort, um den Inhalt der Anfrage aufzurufen.
Prüfen Sie, ob alles bereit ist, mit Ausnahme der Komponenten MonitoringTarget und LoggingTarget.
Beim Upgrade von Object Storage wird möglicherweise eine Warnung wie diese angezeigt:
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError:ErrorMessage:{"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked
Workaround:
Prüfen Sie, ob für jeden Knoten entsprechende SSH-Anmeldedaten in einem Secret gespeichert sind.
Während Upgrades wird der Translation DB-Cluster neu erstellt. Dadurch ist das Secret des ODS-Systemclusters secret-store veraltet und nicht mehr synchronisiert. Aus diesem Grund schlägt die Initialisierung des Translation-Frontend-Pods und -Dienstes fehl.
Der Server kann keine Verbindung zum Schlüsselmanager herstellen, sodass der Serverstatus nicht verfügbar ist. Dieses Problem führt dazu, dass der server-encrypt-and-create-logical-drive-Job fehlschlägt und der Administratorcluster nicht bereit ist. In den Joblogs wird möglicherweise ein Fehler wie dieser angezeigt:
Loki hat nur ein PersistentVolume (PV) für Write-Ahead-Logs (WAL) und Indexe. Das WAL kann das PV füllen, wenn ein Loki-Pod stundenlang keine Verbindung zum Speicher-Bucket herstellen kann. Wenn auf dem persistenten Volume kein Speicherplatz mehr vorhanden ist, kann Loki nur wiederhergestellt werden, wenn Sie das persistente Volume löschen und StatefulSet neu starten.
Workaround:
Um einen Loki-Pod aus diesem Zustand wiederherzustellen, müssen Sie die entsprechende StatefulSet herunterskalieren und das PV mit dem Fehler „Kein Speicherplatz mehr“ löschen.
So stellst du den Loki-Pod wieder her:
Prüfen Sie, ob der IO Tool-Container auf der Workstation installiert ist. Weitere Informationen finden Sie im Betriebshandbuch OOPS-P0065.
Bitten Sie Ihren Sicherheitsadministrator, Ihnen die folgenden Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Bearbeiten von Ressourcen benötigen:
observability-viewer
observability-admin
Legen Sie die Umgebungsvariable KUBECONFIG auf den Pfad zur kubeconfig-Datei im Administratorcluster der obersten Ebene fest. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Legen Sie für die Umgebungsvariable ORG_NAME den Namen der betroffenen Organisation fest.
Speichern Sie den folgenden Inhalt in einer YAML-Datei mit dem Namen log-admin-overrides.yaml:
Legen Sie die Umgebungsvariable KUBECONFIG auf den Pfad zur kubeconfig-Datei im Cluster fest, in dem der betroffene Loki-Pod ausgeführt wird. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Legen Sie für die Umgebungsvariable LOKI_POD_NAME den Namen des betroffenen Loki-Pods fest.
Legen Sie die Umgebungsvariable KUBECONFIG mit dem Pfad zur kubeconfig-Datei im Administratorcluster der betroffenen Organisation fest. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Bearbeiten Sie den Inhalt der YAML-Datei log-admin-overrides.yaml so:
Jobs werden kontinuierlich geplant. Sobald ein Job beendet wird, wird ein neuer Job geplant. Die Jobs, die kontinuierlich geplant werden, sind:
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Workaround:
Pausieren Sie die folgenden Unterkomponenten:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Heben Sie die Pausierung der untergeordneten Komponenten auf, wenn sich das Fleet-Info-Secret im Administratorcluster der Root-Ebene ändert. Dieses Problem tritt auf, wenn sich die Verwaltungsschalter der Instanz ändern, z. B. kr get managementswitches -A, oder wenn sich ein cidrclaim im Organisations-Namespace ändert.
Setzen Sie die Unterkomponenten fort, wenn sich eine NodePool-Ressource im Administratorcluster der Organisation ändert. Aktivieren Sie die untergeordneten Komponenten, bevor Sie beginnen.
Beim Upgrade von 1.12.2 auf 1.12.4 ist kein fehlerfreier Upstream für ServiceNow verfügbar. Möglicherweise wird die folgende Meldung angezeigt: failed to stage volume: LUKS passphrase cannot be empty.
Die Speicherklasse system-performance-rwo ist nicht für LUKS aktiviert. Die Volume-Anhängung gibt an, dass der PVC LUKS-fähig ist.
Der Abgleich sucht nach einem Secret mit den LUKS-Passphrasen. Da die Volume-Anhängung angibt, dass LUKS aktiviert ist, die Speicherklasse jedoch nicht, wird die geheime Passphrase nicht erstellt.
Workaround:
Rufen Sie die Kubeconfig für den Stamm- oder Organisationsadministratorcluster ab, in dem das Problem auftritt:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Löschen Sie die Speicherklasse system-performance-rwo und erstellen Sie sie neu:
Beim Upgrade von Version 1.12.2 auf Version 1.12.4 bleibt das Organisationsupgrade in der Phase NodeUpgrade hängen und bei der Aufgabe zum Knotenupgrade wird der folgende Fehler angezeigt:
Rufen Sie die Kubeconfig für den Stamm- oder Organisationsadministratorcluster ab, in dem das Knoten-Upgrade fehlschlägt, und prüfen Sie, ob nodeupgradetask fehlgeschlagen ist:
kubelet gibt immer wieder das folgende Spam-Log aus:
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
Der runc init-Prozess ist eingefroren, sodass kubelet den cgroup-Pod nicht löschen kann.
Workaround:
Verwenden Sie das folgende Script, um den Prozess zu finden, der das Löschen von cgroup verhindert:
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Prüfen Sie den Status des Gefrierfachs mit cat freezer.state. Der Status sollte FROZEN sein.
Echo "THAWED" > freezer.state
Die cgroup wurde gelöscht. Kubelet stops spamming the log.
PTaaS wird in der Organisation gdchservices bereitgestellt.
Sehen Sie sich die Anmerkungen und Labels des PTaaS-Projekts gdch-perftest und des Buckets perftest-bucket-reports im Namespace „perftest“ gdch-perftest an. Dem Bucket fehlen möglicherweise das Label app.kubernetes.io/managed-by=Helm und die Annotationen meta.helm.sh/release-name=perf-ptaas-assets und meta.helm.sh/release-namespace=gdch-perftest.
Fügen Sie diese Labels und Annotationen manuell hinzu:
Sehen Sie sich die Anmerkungen des PTaaS-Projekts gdch-perftest an. Das Projekt ist möglicherweise mit der Annotation meta.helm.sh/release-name=perf-ptaas-assets falsch konfiguriert.
Ändern Sie diese Anmerkung in meta.helm.sh/release-name=perf-ptaas-backend:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-23 (UTC)."],[],[]]
