| Installation |
1.9.0
1.9.1
1.9.2 |
iLO kann den Schlüssel gelegentlich nicht vom HSM abrufen
Symptome:
`server.status.conditions` enthält einen Eintrag mit dem Typ `KeyManagerConfigured` und dem Status `True`, aber keinen mit dem Typ `DiskEncryptionEnabled`. Es gibt fehlgeschlagene Pods mit dem Namen „server-encrypt-and-create-logical-drive-$SERVER-xxxxx“ mit dem Fehler „ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0“. Fehler beim SSH-Zugriff auf den Pod aufgrund eines ungültigen Schlüssels.
Workaround:
So beheben Sie das Problem:
Rufen Sie die iLO-Benutzeroberfläche > „Information“ > „Diagnostics“ > „Reset“ auf, um iLO zurückzusetzen. Wenn während des Zurücksetzens in iLO angezeigt wird, dass sich der Server im Power-On Self-Test (POST) befindet, starten Sie den Bereitstellungsvorgang neu:
Wenn die Installation des Administratorclusters erfolgreich war:
export KUBECONFIG=<root-admin-kubeconfig path>
Aktualisieren Sie den SSH-Schlüssel:
Rufen Sie den aktuellen öffentlichen SSH-Schlüssel ab. Beachten Sie, dass dieser möglicherweise rotiert wurde und sich daher von /root/.ssh/id_rsa.pub unterscheidet.
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
Fügen Sie den öffentlichen Schlüssel in die ConfigMap „ironic-vars“ ein:
kubectl -n gpc-system edit cm/ironic-vars
IRONIC_RAMDISK_SSH_KEY hinzufügen: \ Starten Sie Ironic neu:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
Stellen Sie das Gerät neu bereit, um IPA neu zu installieren:
Sichern Sie „bmc-credential-$SERVER“, da durch das Löschen von „bmh“ auch das Secret gelöscht wird.
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
Entfernen Sie aus der Datei nicht anwendbare Attribute wie „last-applied“, „creationtimestamp“, „finalizer“, „ownerreference“, „resourceversion“ und „uid“.
Löschen Sie den BareMetalHost:
kubectl -n gpc-system delete bmh/$SERVER
Rufen Sie das Secret „bmc-credentials-$SERVER“ oder die vorherige Sicherung aus „cellcfg“ ab und wenden Sie es an.
Weisen Sie den Server an, etwas anderes zu tun.
So entfernen Sie den zwischengespeicherten BMH-Status:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
Warten Sie, bis der Server bereitgestellt wurde. Sehen Sie sich an, wie BMH-Objekte erstellt werden. Möglicherweise müssen Sie Verschlüsselungsjobs löschen, um sie neu auszulösen.
|
| Vorgänge |
1.9.0
1.9.1
1.9.2 |
Symptome:
Der VM-Status bleibt mit STATUS von Provisioning oder Starting erhalten, wenn storageClassName standard-block ist.
Workaround:
So beheben Sie das Problem:
Prüfen Sie, ob für die VM STATUS Provisioning oder Starting angezeigt wird:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG ist der Dateipfad der kubeconfig-Datei des Systemclusters.
PROJECT ist das GDC-Projekt, in dem sich die VM befindet.
Optional: Zusätzliche Statusdetails abrufen:
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME ist der Name der VM, die nicht reagiert.
VM löschen:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME ist der Name Ihres Namespace.
Prüfen Sie, ob der Löschvorgang erfolgreich war:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
Ein Ergebnis, das dem folgenden ähnelt, bestätigt den Erfolg:
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
Alle Laufwerke dieser VM löschen:
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME Ersetzen Sie DISK_NAME_1 und DISK_NAME_2 bis DISK_NAME_N durch den Namen jedes Ihrer Laufwerke und achten Sie darauf, dass alle Laufwerke aufgeführt sind. Prüfen Sie, ob der Löschvorgang erfolgreich war:
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
Ein Ergebnis, das dem folgenden ähnelt, bestätigt den Erfolg:
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
Erstellen Sie die VM und die Laufwerke neu.
Starten Sie die VM neu.
|
| Vorgänge |
1.9.2 |
Symptome:
gdcloud system container-registry load-oci schlägt mit Fehlern fehl. Wenn Sie den Befehl noch einmal ausführen, wird er für unterschiedliche Zeiträume ausgeführt und schlägt an verschiedenen Stellen im Prozess fehl, z. B. beim Push oder Retagging, aber mit ähnlichen Fehlern.
Workaround:
So beheben Sie das Problem:
Exportieren Sie KUBECONFIG in die kubeconfig-Datei des Stammadministrators:
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- Mit diesem Befehl wird
deployment/root-admin-tftp-manager-controller auf 0 Replikate zurückskaliert:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- Führen Sie die fehlgeschlagenen Vorgänge aus.
- Skalieren Sie
deployment/root-admin-tftp-manager-controller auf ein Replikat hoch:
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| Vorgänge |
1.9.1
1.9.2
1.9.3 |
Symptome:
gdcloud system container-registry load-oci schlägt mit Fehlern fehl. Wenn Sie den Befehl noch einmal ausführen, wird er für unterschiedliche Zeiträume ausgeführt und schlägt an verschiedenen Stellen im Prozess fehl, z. B. beim Push oder Retagging, aber mit ähnlichen Fehlern.
Workaround:
Sie können die Meldung ignorieren. Sie verschwindet nach einer Weile.
|
| Vorgänge |
1.9.2 |
Workaround:
Starten Sie den Pod, der das Problem verursacht, neu, um das Problem zu beheben.
|
| Vorgänge |
1.9.0
1.9.1
1.9.2 |
Symptome:
Der Status der Bedingung „Server bereit“ ist „Falsch“ und die Meldung enthält „job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...“. Die Logs des fehlgeschlagenen Jobs enthalten „Failed to connect to the host via ssh ... Permission denied (publickey).“
Workaround:
So beheben Sie das Problem:
Rufen Sie den aktuellen öffentlichen SSH-Schlüssel aus dem Root-Administratorcluster ab:
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dFügen Sie den Schlüssel in die ConfigMap ironic-vars ein:
kubectl -n gpc-system edit cm/ironic-vars Fügen Sie den vorhandenen IRONIC_RAMDISK_SSH_KEY hinzu oder ersetzen Sie ihn:
<SSH public key>
Starten Sie die Ironic-Bereitstellung neu:
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic Für jeden betroffenen Server:
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| Vorgänge |
1.9.2 |
Workaround:
Um das Problem zu vermeiden, dass IP-Adressen knapp werden, legen Sie die Pod-CIDR-Größe beim Erstellen eines Nutzerclusters mit Hochverfügbarkeit auf /21 oder höher fest.
|
| Installation |
1.9.2 |
Workaround:
Starten Sie die Pods neu, um das Problem zu beheben.
Weitere Informationen finden Sie im MON-R0001-Runbook.
|
| Plattformauthentifizierung |
1.9.13 |
Symptome:
Für alle cplb-init- und storage-ipsec-config-bm-XXXXX-Jobs wird die folgende Meldung angezeigt: Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out.
Workaround:
1. Prüfen Sie, ob die BGP-VRF auf aggswitch inaktiv ist.
2. Prüfen Sie, ob es nicht übertragene Änderungen für die neue Staging-Konfiguration auf der Firewall gibt.
3. Bereinigen Sie alle securitypolicyrules, die die gelöschte Organisation im Namen hatten, und starten Sie den Root-Admin-Controller neu.
|
| Upgrade |
1.9.1
1.9.2
1.9.11 |
Symptome:
Server hängt seit über 20 Minuten bei .status.bareMetalHostStatus.provisionState fest.deprovisioning
Die Verwaltungs-IP-Adresse des Servers, der aktualisiert wird, ist in der Ausgabe eines dieser Befehle enthalten:
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
Workaround:
So beheben Sie das Problem:
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| Upgrade |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
Symptome:
Eine Upgradeaufgabe in NodeUpgrade ist seit über 2 Stunden nicht abgeschlossen.
Ein entsprechendes NodeUpgradeTask hängt bei der Bedingung NodeResumeCompleted und bleibt über eine Stunde lang unvollendet.
bm-system-x.x.x.x-machine-init-Jobs bleiben über einen längeren Zeitraum unvollendet. x.x.x.x ist die Adresse des Knotens.
Workaround:
Die Adresse eines fehlerhaften Knotens finden Sie in den x.x.x.x des hängenden bm-system-x.x.x.x-machine-init-Jobs.
So finden Sie einen fehlerfreien Steuerungsebenenknoten für den fehlerhaften Knoten:
- Suchen Sie den Knotenpool des fehlerhaften Knotens.
Prüfen Sie den Knotenpool der Steuerungsebene im selben Cluster wie den fehlerhaften Knoten und wählen Sie eine Adresse aus dem .spec.address dieses Knotenpools der Steuerungsebene aus.
Führen Sie auf dem Bootstrapper oder OC IT Folgendes aus:
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
Führen Sie auf dem fehlerfreien Knoten der Steuerungsebene folgenden Befehl aus:
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| Upgrade |
1.9.1
1.9.2 |
Symptome:
Der ODS Fleet Operator-Pod befindet sich in einer Crash-Schleife.
Führen Sie Folgendes aus, um den Status des Pods zu prüfen:
ko get pods -n ods-fleet-operator
In den ODS Fleet Operator-Logs wird ein Fehler bei der Leader-Auswahl angezeigt, der dem folgenden ähnelt:
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
So rufen Sie die ODS Fleet Operator-Logs auf:
ko logs deployment/fleet-controller-manager -n ods-fleet-system
Die folgende Meldung wird angezeigt:
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition.
Workaround:
So bearbeiten Sie das Deployment:
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
Bearbeiten Sie das Feld resources des Containers manager so:
Vorher:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
Nachher:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| Upgrade |
1.9.2
1.9.3 |
Symptome:
Die folgende Fehlermeldung wird angezeigt:
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
Workaround:
Gehen Sie so vor, um das Problem zu beheben:
Melden Sie sich auf allen bereitgestellten GPU-Knoten an:
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
Entfernen Sie alte Pakete:
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
Löschen Sie den Pod des Daemonsets „kubevm-gpu-driver-daemonset“, der nicht reagiert. Dadurch wird die Installation neu gestartet:
# kug get pods -A | grep gpu | grep Init
Optional: Wenn bei der Installation des Add‑ons ein Zeitüberschreitungsfehler aufgetreten ist, starten Sie die Installation des Add‑ons neu:
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| Upgrade |
1.9.10
1.9.11 |
Symptome:
Das gpcbackup-agent-0 zeigt failed to stage volume: iSCSI login failed an und das Volume kann nicht bereitgestellt werden.
Prüfen Sie, ob der Pod das Volume nicht anhängen kann. In den folgenden Beispielen wird die kubeconfig-Datei des Systemclusters verwendet:
-
Beschreiben Sie den Pod:
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Wenn der Pod fehlschlägt, wird eine Ausgabe ähnlich dem folgenden Beispiel angezeigt:
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
Prüfen Sie den Knoten, für den der Pod fehlschlägt:
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
Die Ausgabe sollte in etwa so aussehen:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
Rufen Sie den netapp-trident-Pod auf demselben Knoten ab, für den der gpcbackup-agent-0-Pod fehlgeschlagen ist:
kos get pod -o wide -n netapp-trident
Die Ausgabe sollte in etwa so aussehen:
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
Prüfen Sie die Logs des netapp-trident-Pods auf demselben Knoten, auf dem der gpcbackup-agent-0-Pod fehlgeschlagen ist:
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
Die Ausgabe sollte in etwa so aussehen:
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
Workaround:
So beheben Sie das Problem:
-
Rufen Sie den Namen von InventoryMachine ab:
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
Prüfen Sie, ob der vorherige Job vorhanden ist:
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
Die Ausgabe sollte in etwa so aussehen:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
Job löschen:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Die Ausgabe sollte in etwa so aussehen:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Prüfen Sie, ob StorageEncryptionConnection vorhanden ist:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Die Ausgabe sollte in etwa so aussehen:
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
Löschen Sie das StorageEncryptionConnection:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
Die Ausgabe sollte in etwa so aussehen:
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
Starten Sie den root-admin-controller-Pod neu:
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
Prüfen Sie, ob der neue Job neu erstellt und erfolgreich ausgeführt wurde:
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
Die Ausgabe sollte in etwa so aussehen:
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| Upgrade |
1.9.10
1.9.11 |
Symptome:
Ein Harbor-Registrierungs-Pod zeigt eine Fehlermeldung ähnlich der folgenden an:
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
Workaround:
Gehen Sie zur Behebung des Problems so vor:
-
Prüfen Sie den PersistentVolumeClaim (PVC) der Harbor-Registry und notieren Sie sich den Namen des PVC-Volumes:
kubectl get pvc harbor-registry -n harbor-system
-
Um zu prüfen, ob die Volume-Anhängung sich auf demselben Knoten wie der Harbor-Registry-Pod befindet, listen Sie die volumeattachment auf und suchen Sie nach dem Eintrag, der dem Namen des Volumes zugeordnet ist:
kubectl get volumeattachment | grep [volume-name]
-
Wenn die Volume-Einbindung sich auf einem anderen Knoten als der Harbor-Registry-Pod befindet, entfernen Sie volumeattachment:
kubectl delete volumeattachment [volumeattachment-name]
-
Starten Sie den Harbor-Registry-Pod neu.
Die Harbor-Registrierung im Administratorcluster des Stammverzeichnisses muss fehlerfrei sein und das Knoten-Upgrade muss erfolgreich abgeschlossen werden.
|
| Installation |
1.9.2
1.9.3
1.9.4
1.9.5
|
Symptome:
Die folgende Fehlermeldung wird angezeigt:
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Ein Pod-Log enthält Folgendes:
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
Die CoreDNS-Version ist 1.8.6.
Workaround:
Starten Sie die coredns-Bereitstellung neu, um das Problem zu beheben.
Wenn KUBECONFIG für den richtigen Cluster festgelegt ist, führen Sie Folgendes aus:
kubectl rollout restart deployment coredns -n kube-system
Der Name des Nutzerclusters ist Teil der Fehlermeldung.
So finden Sie die kubeconfig-Datei in /root/release/user/: Suchen Sie nach den kubeconfigs: org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
Wenn kubeconfig-Dateien fehlen, generieren Sie sie so:
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| Upgrade |
1.9.2
1.9.3 |
Symptome:
Die folgende Fehlermeldung wird angezeigt:
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
Dieses Problem ist in der Regel vorübergehend und sollte sich von selbst beheben.
|
| Installation |
1.9.3 |
Die Installation eines Add-ons schlägt mit dem folgenden Fehler fehl:
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition.
Workaround:
Die Add-on-Installation kann fehlschlagen, wenn sich Knoten im Status NotReady befinden. Prüfen Sie mit dem folgenden Befehl, ob sich Knoten im Status NotReady befinden:
kubectl get nodes
Rufen Sie Details für den Knoten mit dem Status NotReady ab:
$ kubectl describe node | grep PodCIDRs
In einem Cluster mit diesem Problem sind einem Knoten keine PodCIDRs zugewiesen, z. B.:
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
So beheben Sie das Problem: Starten Sie die Bereitstellung von ipam-controller im betroffenen Cluster neu:
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| Upgrade |
1.9.3 |
Ein Upgrade schlägt mit dem folgenden Fehler fehl:
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded.
Workaround:
Aktualisieren Sie das Feld <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> des AddOnSet abm-overrides manuell auf den Namen der AddOnSetTemplate der gewünschten Version im selben Namespace wie der Cluster, der aktualisiert wird.</code.spec.addonsettemplateref<>
|
| Installation |
1.9.3 |
Symptome:
Ein Flottenadministratorcontroller kann nicht bereitgestellt werden und der TestCreateFleetAdminCluster- oder TestSimOverlayCreateFleetAdminCluster-Test schlägt fehl. Der Flottenmanager-Controller befindet sich in einer Absturzschleife. Der folgende Fehler wird in den Logs des Flottenadministrator-Controllers angezeigt: Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced.
Workaround:
Stellen Sie die Logmon-CRD im Administratorcluster der Organisation bereit. Starten Sie den Flottenadministrator-Controller neu.
|
| Installation |
1.9.3 |
Symptome:
Die folgende Fehlermeldung wird angezeigt:
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
Workaround:
Starten Sie sowohl die Bereitstellung als auch das DaemonSet im Cluster neu, um das Problem zu beheben:
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
Hinweis:Führen Sie den folgenden Befehl aus, bevor Sie das Deployment und das DaemonSet neu starten, um auf den richtigen Cluster zu verweisen:
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| Upgrade |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
Symptome:
Ein Pod kann aufgrund unzureichender CPU nicht geplant werden.
Workaround:
Fügen Sie einem vorhandenen Nutzercluster, der mit n2-standard-4-Worker-Knoten erstellt wurde, vor dem Upgrade einen neuen n2-standard-8-NodePool mit drei Knoten hinzu. Erstellen Sie für neue Nutzercluster einen n2-standard-8-NodePool mit mindestens drei Knoten. Weitere Informationen finden Sie unter Nutzercluster für Containerarbeitslasten erstellen.
|
| Vorgänge |
1.9.0
1.9.2
1.9.3
1.9.4 |
Symptome:
Die VM-Instanz PHASE zeigt Scheduling und READY bleibt False und erreicht nie den Status True. Dies betrifft zwei Maschinentypen, wie im Workaround aufgeführt. Andere Maschinentypen sind nicht betroffen und benötigen keine Umgehungslösung.
Workaround:
- Wenn Sie Nutzercluster erstellen, die A100 40G-GPUs verwenden, wählen Sie in der Benutzeroberfläche immer den Maschinentyp „a2-highgpu-1g-gdc“ aus.
- Wenn Sie Nutzercluster erstellen, die A100 80G-GPUs verwenden, wählen Sie in der Benutzeroberfläche immer den Maschinentyp „a2-ultragpu-1g-gdc“ aus.
|
| Vorgänge |
1.9.0
1.9.2
1.9.3
1.9.4 |
Symptome:
Bei Knotenpools mit VM-Instanzen mit Arbeitsspeichergrößen über 32 GB kann es vorkommen, dass die VM-Instanz ausgeführt wird, dann beendet wird und wieder ausgeführt wird. Diese Sequenz kann sich wiederholen. Schließlich wird ein Fehler aufgrund von unzureichendem Arbeitsspeicher (OOMKilled) ausgegeben und die Instanz schlägt fehl.
Dies sind die drei betroffenen VM-Typen:
- n2-highmem-8-gdc: 64 GB Arbeitsspeicher
- a2-highgpu-1g-gdc: 85 GB Arbeitsspeicher
- a2-ultragpu-1g-gdc: 170 GB Arbeitsspeicher
Workaround:
- Maschinentyp überprüfen:
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- Suchen Sie nach dem VM-Typ in
spec.compute.virtualMachineTypeName in der Ausgabe.
- Wenn der VM-Typ einer der drei aufgeführten Typen ist, bearbeiten Sie
configmap, um eine Speicherüberschreibung einzufügen:
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- Fügen Sie einen Abschnitt
memory.guest und resources.overcommitGuestOverhead ein, wie im folgenden Beispiel gezeigt:
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- Ändern Sie in
memory die Werte von guest so:
- Für n2-highmem-8-gdc gilt: MEMORY_SIZE
63.6G.
- Für a2-highgpu-1g-gdc gilt: MEMORY_SIZE
84G.
- Für a2-ultragpu-1g-gdc gilt MEMORY_SIZE
168G.
- Wiederholen Sie diesen Vorgang für alle betroffenen VMs.
|
| Upgrade |
1.9.4 |
Symptome:
Ein bm-system-*-Job bleibt beim Schritt Gathering Facts hängen. Beim Versuch, manuell eine SSH-Verbindung zum Server herzustellen, wird PTY allocation request failed on channel 0 angezeigt.
Workaround:
Starten Sie den Server mit einer der folgenden Methoden neu:
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
iLO-Benutzeroberfläche kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| Upgrade |
1.9.4
1.9.10 |
Symptome:
Ein Upgrade schlägt fehl, weil der Job backup-ipsec-* fehlgeschlagen ist.
Workaround:
Gehen Sie so vor:
Die vorinstallierten Schlüssel finden Sie im Namespace gpc-system im Administratorcluster der Organisation. Die Schlüssel haben den Namen <node-name>-pre-shared-key.
Verwenden Sie kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }', um den Schlüssel-Hash aus dem YAML-Code des vorinstallierten Schlüssels eines funktionierenden Knotens abzurufen.
Sie müssen den Schlüssel-Hash von einem anderen Knoten als dem Knoten abrufen, auf dem das IPsec-Upgrade fehlgeschlagen ist. Wenden Sie den Hash für diesen vorinstallierten Schlüssel auf das Secret für den vorinstallierten Schlüssel des fehlerhaften Knotens in der gpc-system im Administratorcluster der Organisation an. Löschen Sie das storageencryptionconnection-Objekt mit demselben Namen wie der fehlerhafte Knoten im Stammadministratorcluster. Löschen Sie den zugehörigen storage-ipsec-config-<node-name>-Job im Administratorcluster der Organisation. Löschen Sie den zugehörigen backup-ipsec-for-upgrade-<node-name>-Upgradejob.
|
| Upgrade |
1.9.4 |
Symptome:
Das Aktualisieren von Organisationsclustern dauert lange.
Workaround:
Warten Sie, bis clamav auf natürliche Weise heruntergefahren wird.
|
| Upgrade |
1.9.5 |
Symptome:
Es werden verschiedene Zertifikate angezeigt:
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
Workaround:
Hinweis: Rotieren Sie das harbor-harbor-https-Zertifikat, bevor Sie die folgenden Schritte ausführen.
Gehen Sie so vor:
Es gibt Kopien der Zertifikatsdaten, die in Secrets im Cluster gespeichert sind. Nachdem Sie das harbor-harbor-https-Zertifikat rotiert haben, müssen Sie auch die Secret-Kopien aktualisieren.
- Rufen Sie die Artifact Registry-URL ab.
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- Aktualisieren Sie die Kopien des Artifact Registry-Zertifikats-Secrets in jedem Namespace.
Alle Namespaces abrufen, in denen eine Kopie eines Artifact Registry-Zertifikats als Secret gespeichert ist.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Aktualisieren Sie die Kopie des Artifact Registry-Zertifikats-Secrets in jedem Namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- Für den Root-Administratorcluster müssen Sie auch eine Korrektur mit dem Namen „certificate secret copy“ (Kopie des Secret für das Zertifikat) mit dem Namen
ca-cert-in-cluster-registry im Namespace anthos-creds aktualisieren.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- Aktualisieren Sie
registry-cert im Namespace kube-system.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- Wenn Sie Zertifikate für den Organisationsadministratorcluster rotieren, müssen Sie auch die Kopien des Zertifikatssecrets aktualisieren, die im Root-Administratorcluster vorhanden sind.
Alle Namespaces abrufen, in denen eine Kopie eines Artifact Registry-Zertifikat-Secrets gespeichert ist.
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
Aktualisieren Sie die Kopie des Artifact Registry-Zertifikats-Secrets in jedem Namespace.
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done .
|
| Upgrade |
1.10.0
1.10.1 |
Symptome:
Nach dem Starten eines OrganizationUpgrade wird der kube-apiserver-Pod nicht auf einem oder mehreren Knoten ausgeführt.
- Ermitteln Sie den Knoten, auf dem das Upgrade blockiert ist:
kubectl get po -n kube-system -l component=kube-apiserver
Sie erhalten folgende Ausgabe:
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- Stellen Sie eine SSH-Verbindung zu dem Knoten her, der gerade aktualisiert wurde:
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
Der Containerstatus wird als Exited angezeigt:
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- Prüfen Sie die Logs des
Exited-Pods:
crictl logs f1771b8aad929
Sie erhalten folgende Ausgabe:
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
Das Flag wird in der Datei /etc/kubernetes/manifests/kube-apiserver.yaml konfiguriert:
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
Workaround:
Entfernen Sie das Flag aus der Datei /etc/kubernetes/manifests/kube-apiserver.yaml.
- Sichern Sie die Datei:
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- Entfernen Sie die Zeile:
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- Prüfen Sie, ob die Zeile entfernt wurde:
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- Listen Sie den
kube-apiserver-Container auf:
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet erkennt die Änderung automatisch und startet den kube-apiserver-Pod:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- Wiederholen Sie diese Schritte für alle betroffenen Knoten.
|
| Upgrade |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
Symptome:
Die kube-state-metrics-Bereitstellung stürzt nach der Zertifikatsrotation in einer Organisation immer wieder ab. Dieses Problem kann zu einem Verlust von Monitoringdaten führen.
|
| Upgrade |
1.9.6 |
Symptome:
Nach dem Upgrade ist der Worker-Knoten nicht ausgeglichen.
Workaround:
Worker-Knoten manuell ausgleichen:
- Bei einer Pod-Arbeitslast löschen Sie Pods im Deployment.
- Löschen Sie für eine VM-Arbeitslast „virt-launcher“, ohne das GVM-Objekt der Steuerungsebene zu ändern.
|
| Upgrade |
1.9.6 |
Beim Upgrade von Version 1.9.5 auf Version 1.9.6 kann es vorkommen, dass das GPU-Geräte-Plug-in nicht gestartet werden kann.
Symptome:
Möglicherweise wird der folgende Fehler angezeigt, der die Bereitschaft der VM-Laufzeit und den Upgradeprozess blockiert:
Failed to initialize NVML: could not load NVML library
Workaround:
- Prüfen Sie, ob
nvidia-container-runtime auf dem Knoten richtig konfiguriert ist:
- Stellen Sie eine SSH-Verbindung zu dem Knoten her, bei dem Sie ein Problem vermuten.
- Rufen Sie die Liste der Pods ab:
crictl pods
- Prüfen Sie die Pods:
crictl inspectp $pod_hash | grep runtimeOption -A1
Wenn die Ausgabe so aussieht, ist der Knoten richtig konfiguriert. Wenn die Ausgabe nicht so aussieht, ist nvidia-container-runtime nicht auf dem Knoten konfiguriert:
binary_name": "/usr/bin/nvidia-container-runtime"
- Wenn
nvidia-container-runtime nicht richtig konfiguriert ist, starten Sie containerd neu, um das Problem zu beheben:
systemctl restart containerd
|
| Upgrade |
1.9.7 |
Beim Upgrade auf Version 1.9.7 bleibt die Firmware des Stammknotenpools des Administratorclusters im Status in process.
Symptome:
- Informationen zur
NodeUpgrade-Seite finden Sie im Workaround Zeitüberschreitung des Artefaktservers:
NodeUpgrade hängt im Status in process fest und die Bedingung für NodeROMFirmwareUpgradeCompleted im Status Nodeupgradetask wird nie abgeschlossen.- Die URL in
spec.firmware.firmwarePackages.url im NodeUpgrade-Objekt kann hängen bleiben, wenn sie beispielsweise mit Folgendem verbunden ist:
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- Informationen zur
Harbor-Seite finden Sie im Workaround Artifact server unauthorized:
- Im Artefaktserverprotokoll wird möglicherweise ein Fehler im Zusammenhang mit dem unautorisierten Zugriff auf ein Repository angezeigt:
gdch-hpe-firmware/ilo, z. B.:
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- Im Harbor-Projekt muss
gdch-hpe-firmware die Spec.harborProjectConfig.accessLevel als private haben:
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
Workaround:
|
| Netzwerk mit geringerer Leistung |
1.9.0 – 1.9.6 |
Symptome:
BGP-Sitzungen sind im internen Netzwerk einer Organisation inaktiv. Nur einer der internen BGP-Peering-Endpunkte der Organisation wird den TORSwitchInternal-Objekten hinzugefügt.
Workaround:
Ändern Sie das in {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim verwendete Subnetz so, dass es sich nicht mit den analogen AddressPoolClaim-Ressourcen einer anderen Organisation überschneidet.
- Symptome untersuchen:
- Führen Sie für jeden Organisationssystemcluster Folgendes aus:
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- Prüfen Sie das Feld
State jedes BGPSession-Objekts auf State von NotEstablished. Notieren Sie sich die LocalIP der einzelnen zugehörigen NotEstablished BGPSession für die spätere Verwendung.
- Ermitteln Sie, ob
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" die Ursache ist:
- Führen Sie für jede aktive Organisation Folgendes aus:
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- Suchen Sie im Feld
ClusterIP (3.Spalte) der Ausgabe nach dem in Schritt 1b notierten LocalIPs. Notieren Sie sich die LocalIP, die mit Einträgen in der dritten Spalte der Ausgabe übereinstimmen, für später. Wenn es mehrere unterschiedliche Administratorcluster für die Organisation gibt und die Ausgabe aus Schritt 2a die in Schritt 1b genannten LocalIP enthält, fahren Sie mit Schritt 3 fort.
- Überlappende IPs für Organisationssystemcluster auflösen
- Ausführen:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- Notieren Sie die Anzahl der zurückgegebenen
SubnetClaim-Objekte aus der Abfrage in 3a. Dies muss der Anzahl der aktiven Organisationen entsprechen.
- Notieren Sie sich für jede Zeile den Namespace (Spalte 1) und den CIDR-Block (Spalte 3). Der CIDR-Block jeder Zeile sollte mit dem CIDR-Block jeder anderen Zeile übereinstimmen.
- Führen Sie für jede Organisation die folgenden Schritte aus:
- Rufen Sie das
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim-Objekt im Administratorcluster der Organisation auf.
- Berechnen Sie die
Start IP des Anspruchs auf den Worker-Knotenadresspool dieser Organisation. Nehmen Sie dazu den CIDR-Block aus 3.c und das Feld Size in der AddressPoolClaim aus 3.d.i. Beginnen Sie mit der vorletzten IP-Adresse im CIDR-Block und zählen Sie Size IP abwärts. Dies ist die neue Start IP für die erste Organisation (wird in Schritt 3.d.iii verwendet). Zählen Sie für jede zusätzliche Organisation Size IP herunter, beginnend mit der neuen Start IP der vorherigen Organisation.
Beispiel:
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- Fügen Sie im
AddressPoolClaim aus Schritt 3.c.i das folgende Feld im Feld Spec hinzu:
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
Verwenden Sie den folgenden Befehl:
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
Das Ergebnis muss so aussehen, wenn Sie beispielsweise org-1 aus 3.d.ii verwenden:
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- Bereinigen Sie, um unnötige BGP-Sitzungen auf der TORSwitch-Hardware zu vermeiden.
- Führen Sie folgenden Befehl aus, um alle
TORSwitchInternal-Ressourcen aufzulisten, die aktualisiert werden müssen:
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- Führen Sie für jede der
TORSwitchInternals, die in der Ausgabe des vorherigen Befehls aufgeführt sind, den folgenden Befehl aus:
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- Entfernen Sie für alle
TORSwitchInternal-Objekte alle Einträge aus der .spec.ebgpNeighbors-Liste, deren NeighborIP mit einem der LocalIP aus Schritt 2b übereinstimmt. Beispiel: LocalIP von 2.2.2.2 wurde in Schritt 2b notiert. Unten sehen Sie ein Beispiel für TORSwitchInternal vor und nach dem Bereinigungsschritt.
Vor dem Bereinigen:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
Nach der Bereinigung. Beachten Sie den entfernten Eintrag ebgpNeighbor:
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- Führen Sie Schritt 1 aus und prüfen Sie, ob alle
BGPSession-Objekt-States zu Established zurückgekehrt sind. Es kann etwa 10 Minuten dauern, bis alle Änderungen an die physischen TORSwitch-Konfigurationen des GDC weitergegeben wurden.
|
| Upgrade |
1.9.7 – 1.9.21 |
Während eines Upgrades kann es vorkommen, dass das Upgrade des Knotens und des Betriebssystems nicht fortgesetzt wird.
Symptome:
Es kann einige Stunden dauern, bis ein Knoten den Status Ready, SchedulingDisabled erhält.
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
Workaround:
- Folgen Sie dem Runbook PLATAUTH-SSH 0001, um den SSH-Schlüssel für den betreffenden Knoten abzurufen. Führen Sie nach dem Herstellen einer Verbindung zum Knoten mit SSH den folgenden Befehl aus:
multipath -ll | grep fail
- Fahren Sie nur dann mit dem nächsten Schritt fort, wenn die Ausgabe so aussieht:
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- Führen Sie Folgendes aus, um das Problem zu beheben:
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| Upgrade |
1.9.8-1.9.21 |
Symptome:
Wenn ein ABM-Cluster-Upgrade länger als 2 Stunden hängt, ist das Leeren des Knotens möglicherweise blockiert.
Workaround:
Bei den folgenden Vorgängen wird der Stammadministratorcluster als Beispiel verwendet. ${TARGET_KUBECONFIG} bezieht sich auf die kubeconfig für den Ziel-ABM-Cluster, dessen Knotenentleerung blockiert ist, ${KUBECONFIG} auf die kubeconfig für den Cluster, der den Ziel-ABM-Cluster verwaltet. Für den Root-Administratorcluster verweisen beide auf die kubeconfig des Root-Administrators.
Führen Sie die folgenden Schritte aus, um zu prüfen, ob das ABM-Cluster-Upgrade hängen geblieben ist:
- Prüfen Sie die Knoten, die beim Beenden hängen geblieben sind:
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
Die Ausgabe sieht in etwa so aus:
{"10.200.0.2": 2}
Das bedeutet, dass für den Knoten „10.200.0.2“ zwei Pods geleert werden.
- Prüfen Sie, ob Pods weiterhin vom Knoten (als
${NODE_BEING_DRAINED} bezeichnet) entfernt werden:
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
Die Anzahl der Ausgabepods muss mit der Anzahl der im vorherigen Schritt gemeldeten Pods übereinstimmen, die geleert werden.
Prüfen Sie für jeden Pod yetToDrain aus Schritt 1 den Status des Pods:
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Wenn sich der Pod im Status Running befindet oder der Pod im Namespace obs-system den Status audit-logs-loki-0 oder loki-0 hat und für den Pod kein Ereignis mit dem Fehler unable to unmount volume vorliegt, löschen Sie den Pod explizit mit einem grace-period.
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- In allen anderen Fällen, in denen ein Pod nicht entleert werden kann, eskaliere die Anfrage an die Bereitschaftsdienste.
- Prüfen Sie, ob der Verbindungsausgleich für den Knoten abgeschlossen ist.
- Wiederholen Sie Schritt 1, wenn andere Knoten im Status „Draining“ hängen bleiben.
|
| Upgrade |
1.9.6
1.9.7
1.9.8
|
Versionen 1.9 mit signierten Artefakten können nicht verteilt werden, da das Flag Override in DistributionPolicy auf „false“ gesetzt ist. Dadurch wird die Verteilung verhindert, wenn in der Zielregistrierung ein Artefakt mit demselben Namen vorhanden ist.
Symptome:
Die folgenden Probleme können auftreten:
- Das Artefakt mit der Signatur wird übertragen. Das Log könnte so aussehen:
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- Fehler beim Pushen des Artefakts. Das Log könnte so aussehen:
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 404 – Artefakt nicht gefunden. Das Log könnte so aussehen:
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- Die Verteilung des Artefakts schlägt fehl.
Workaround:
So beheben Sie das Problem:
- Aktualisieren Sie die benutzerdefinierte Ressource (Custom Resource, CR)
DistributionPolicy, um Spec.Override auf true festzulegen.
- Lösen Sie eine Replikation noch einmal aus, indem Sie das SAR-1005-Runbook befolgen.
- Nachdem der neue Replikationslauf erfolgreich abgeschlossen wurde, aktualisieren Sie die
ManualDistribution CR execution-ids in Annotation mit der ID der erfolgreichen Ausführung.
|
| Hardwaresicherheitsmodul (HSM) |
1.9.9 |
HSMs melden möglicherweise zeitweise ServicesNotStarted, was dazu führen kann, dass Bare-Metal-Server nicht als fehlerfrei gemeldet werden und die folgende Meldung angezeigt wird:
"message": "failed to get master key name"
Symptome:
Die folgenden Probleme können auftreten:
Workaround:
So beheben Sie das Problem:
- Installieren Sie das Tool
kstl auf dem ersten HSM, indem Sie die folgenden Befehle ausführen:
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- Prüfen Sie, ob ein HSM Probleme beim Neustart hat. Rufen Sie für jedes HSM, das bei
ServicesNotStarted hängen bleibt, die $HSM_MGMT_IP ab und prüfen Sie, ob der Dienst ausgefallen ist:
ksctl services status --url=https://$HSM_MGMT_IP
- Alle HSMs, HSM-Cluster und HSM-Mandanten pausieren:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- Stellen Sie eine SSH-Verbindung zum HSM her, während der Dienst nicht ausgeführt wird:
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- Achten Sie darauf, dass Sie sich im richtigen HSM befinden. Prüfen Sie, ob Sie eine SSH-Verbindung mit dem richtigen
$HSM_MGMT_IP hergestellt haben.
- Starten Sie das erste HSM im HSM neu:
ksadmin@ciphertrust:~ sudo reboot
- Warten Sie, bis das erste HSM von außerhalb des HSM fehlerfrei ist:
watch -c ksctl services status --url=https://$HSM_MGMT_IP
Dieser Schritt kann etwa fünf Minuten dauern, bis die HSMs neu gestartet sind.
- Wiederholen Sie diese Schritte für die anderen HSMs, bei denen Dienste ausgefallen sind.
- HSMs, HSM-Cluster und HSM-Mandanten reaktivieren:
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- Prüfen Sie, ob alles übereinstimmt. Es kann fünf bis zehn Minuten dauern, bis die HSMs abgeglichen sind.
|
| Monitoring |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
Symptome:
Die alertmanager-servicenow-webhook-Benachrichtigungen erreichen ServiceNow im Organisationssystemcluster für GDC-Versionen vor 1.11.3 nicht. Die Logs enthalten die Fehlermeldung read: connection reset by peer. Dieses Problem wird durch ein fehlendes Label verursacht, das den ausgehenden Traffic ermöglicht. Wenn der Webhook zwischen Organisationen kommunizieren muss, muss er Egress-NAT verwenden.
Workaround:
Sie müssen ausgehenden Traffic für alertmanager-servicenow-webhook in Organisationssystemclustern aktivieren. So beheben Sie das Problem:
- Legen Sie die erforderlichen Voraussetzungen fest:
- Installieren Sie die gcloud-Befehlszeile (CLI).
- Rufen Sie die Pfade zu den kubeconfig-Dateien der Administratorcluster des Stamm- und Organisationsadministrators ab. Speichern Sie die Pfade in den Umgebungsvariablen
ROOT_KUBECONFIG und ORG_SYSTEM_KUBECONFIG.
- Bitten Sie Ihren Sicherheitsadministrator, Ihnen die Rolle „Observability Admin“ (
observability-admin) im Namespace obs-system für die Cluster „root admin“ und „org admin“ zuzuweisen.
- Prüfen Sie, ob das Problem in Ihrer Umgebung auftritt:
- Rufen Sie die Bereitstellung
alertmanager-servicenow-webhook ab:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- So rufen Sie die Logs für das
alertmanager-servicenow-webhook-Deployment auf:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
Wenn die Logs die Fehlermeldung read: connection reset by peer enthalten, besteht das Problem und Sie müssen mit den Schritten dieser Problemumgehung fortfahren.
- Label für ausgehenden Traffic hinzufügen:
- Rufen Sie die aktuelle YAML-Datei für die
alertmanager-servicenow-webhook-Bereitstellung ab:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Fügen Sie der YAML-Datei für die
alertmanager-servicenow-webhook-Bereitstellung das Egress-Label hinzu:
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- Ersetzen Sie die YAML-Datei für die
alertmanager-servicenow-webhook-Bereitstellung durch die aktualisierte Datei:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
Die Bereitstellung muss automatisch neu gestartet werden.
- Prüfen Sie, ob das Problem behoben wurde, indem Sie die Schritte unter Bestätigen, dass das Problem in Ihrer Umgebung auftritt noch einmal ausführen. Die Fehlermeldung der Logs darf nicht angezeigt werden. Eskaliere den Fall andernfalls an das Engineering-Team.
Rollback-Strategie:
Wenn die Schritte zur Problemumgehung fehlschlagen oder Sie einen Verlust bei den Messwerten feststellen, setzen Sie die YAML-Datei für die alertmanager-servicenow-webhook-Bereitstellung in den ursprünglichen Zustand zurück:
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| Upgrade |
1.9.10 |
Symptome:
Das Upgrade bleibt bei Schritt NodeMaintain hängen.
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
Für den Knotenpool, der gerade erstellt wird, wird Folgendes angezeigt:nodeupgradetask
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
Workaround:
Gehen Sie so vor:
- Rufen Sie den Namen der Bereitstellung „cap-controller-manager“ ab.
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- Geben Sie den Namen von cap-controller-manager an, z. B. cap-controller-manager-1.28.0-gke.435:
export CAP_DEPLOYMENT_NAME=
- Starten Sie den cap-controller-manager neu.
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| Upgrade |
1.9.10 |
Symptome:
Das Upgrade bleibt beim Postflight-Prüfungsschritt AdminClusterHealth hängen.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
Das Organisationsobjekt enthält folgende Informationen:
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
Workaround:
Gehen Sie so vor:
Verwenden Sie den folgenden Befehl, um die Preflights zu überspringen:
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| Upgrade |
1.9.9 |
Symptome:
Für die NodeUpgradeTask ist möglicherweise die Bedingung failed to monitor failover registry recreation: failed to monitor job: job not complete festgelegt, die den Abschluss einer Aufgabe verhindert.
Workaround:
So beheben Sie das Problem:
- Löschen Sie den Job mit dem Namen
create-failover-registry-***, der den Abschlussstatus „0/1“ hat.
- Löschen Sie die Annotation
failover-registry-creation-job-name aus dem Serverobjekt, das aktualisiert wird.
Der Controller erstellt den Job automatisch neu.
|
| Upgrade |
1.9.20 |
Symptome:
Der Knoten schlägt beim Job backup-ipsec-for-upgrade-bm fehl.
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
Workaround:
Löschen Sie den Job „backup-ipsec-for-upgrade-bm“ und warten Sie, bis er neu erstellt wird.
|
| Google Distributed Cloud |
1.9.9 |
Symptome:
Ein Knotenpool der Steuerungsebene wird nicht bereit, da der etcd-Cluster nicht gestartet werden kann. Möglicherweise tritt das folgende Problem auf:
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
Workaround:
So beheben Sie das Problem:
- Prüfen Sie, ob die Clustererstellung beim Job zur Maschineninitialisierung hängen bleibt.
Die Aufgabe kubeadm join ist aus folgenden Gründen fehlgeschlagen:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
Die Aufgabe kubeadm reset ist aus folgenden Gründen fehlgeschlagen:
panic: runtime error: invalid memory address or nil pointer dereference
- Stellen Sie über SSH eine Verbindung zu einem funktionierenden Knoten der Steuerungsebene her.
- Führen Sie den Befehl
etcdctl aus, um die veralteten Daten zu bereinigen.
etcd-Mitgliedschaft prüfen:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- Entfernen Sie die alte Mitgliedschaft:
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| VM sichern und wiederherstellen |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
Symptome:
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:
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
Workaround:
VM-Sicherungsplannamen sind eine Verkettung des Namens VirtualMachineBackupPlanTemplate, des Ressourcentyps (entweder vm oder vm-disk) und des Namens der Ressource. Die zusammengefügte Zeichenfolge 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.
|
| Upgrade |
1.9.9 |
Symptome:
Ein Upgrade schlägt beim Sicherungsjob ipsec mit dem folgenden Vorlagenfehler fehl:
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
Workaround:
Gehen Sie so vor:
Melden Sie sich auf dem Knoten an, auf dem die Upgradeaufgabe fehlgeschlagen ist. Speichern Sie die swanctl.conf als Sicherung. Entfernen Sie die Zeile mit den geschweiften Klammern in der Datei /etc/swanctl/swanctl.conf. Löschen Sie den fehlerhaften backup-ipsec-for-upgrade-Job und warten Sie, bis er neu erstellt wurde. Der nachfolgende Job wird dann erfolgreich abgeschlossen. Fügen Sie die in Schritt 3 entfernte Zeile wieder zu /etc/swanctl/swanctl.conf hinzu.
|
| Knotenplattform |
1.9.6
1.9.7
1.9.8
1.9.9 |
Wenn ein Firmware-Upgrade im Root-Administratorcluster gestartet wird, scheint es nach Abschluss des Knoten-Upgrades auf einem der Knoten hängen zu bleiben.
Symptome:
- Der
nodeupgradetask bleibt in der Phase NodeResumeCompleted hängen.
- Der
machine-init-Job schlägt fehl und im Log wird angezeigt, dass kubeadm join fehlgeschlagen ist.
- Sie können keine SSH-Verbindung zum Knoten über die IP-Adresse der Datenebene herstellen.
Das Problem wird dadurch verursacht, dass der aktualisierte Knoten keinen eingehenden Netzwerkverkehr mehr akzeptiert.
Workaround:
- Sehen Sie sich die Logs von
job/nodeupgradetask an, um die IP-Adressen zu ermitteln und herauszufinden, welcher Knoten das Problem hat.
- Starten Sie den
anetd-client-Pod des betroffenen Knotens neu.
- Prüfen Sie die SSH-Verbindung über die Dataplane-IP zum betroffenen Knoten.
Optionale Schritte für weitere Untersuchungen:
- Stellen Sie eine Shell-Verbindung zu einem Cilium-Agent-Container eines der funktionierenden anetd-Pods her.
- Führen Sie „cilium-bugtool“ aus und warten Sie etwa 10 Sekunden. Das Tool speichert Logs im Verzeichnis
/var/log/network/policy_action.log.
- Suchen Sie nach
deny, um zu sehen, ob Traffic abgelehnt wird:
grep -r "deny" /var/log/network/ to
Notieren Sie sich, welche Server abgelehnt werden, möglicherweise die Bare-Metal-Knoten des Root-Administrators.
|
| Upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Symptome:
- Ein Upgrade schlägt beim
atat-webhooks-Add-on fehl.
- Abgelaufene ATAT-Add-on-Labels können dazu führen, dass Organisationsupgrades fehlschlagen.
Beispiel:
Invalid value: "TO1234": The current date 2024-05-06 is not within the valid range of this TaskOrder: 2023-12-16 - 2024-04-16.
Workaround:
Nutzer müssen die ATAT-Add-on-Labels ihres Portfolios aktualisieren. Folge dem Runbook ATAT-R0003, um das Problem zu beheben.
|
| Upgrade |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
Symptome:
- Das Upgrade des Knotenbetriebssystems auf Bare Metal-Tenants schlägt beim Upgrade von 1.9.12 auf 1.9.13 fehl. Die folgende Meldung wird angezeigt:
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
Workaround:
- Entfernen Sie die Annotation
cluster.private.gdc.goog/ssh-trusted-ca-versions aus der CR des Root-Administrators und des Organisationsadministrators.
- Löschen Sie die fehlgeschlagenen Ansible-Jobs. Neue Jobs werden automatisch erstellt, weil die Annotation
cluster.private.gdc.goog/host-key-rotation-in-progress in der Server-CR auf „true“ gesetzt ist.
- Nach der Rotation werden die
cluster.private.gdc.goog/ssh-trusted-ca-versions-Anmerkungen wieder dem Server-CR hinzugefügt.
|
| Knoten, Upgrade |
1.9.* |
Symptome:
Nach dem Upgrade bleiben Pods auf einigen Bare-Metal-Knoten im Status CrashLoopBackOff hängen und iptables -L -v -n | grep CILIUM auf dem Knoten gibt ein leeres Ergebnis zurück.
Workaround:
So beheben Sie das Problem:
- Führen Sie dazu diesen Befehl aus:
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force.
- Führen Sie
iptables -L -v -n | grep CILIUM noch einmal aus und prüfen Sie, ob eine Ausgabe erfolgt.
|
| Logging |
1.9.14
1.9.15 |
Symptome:
Der audit-logs-loki-0-Pod befindet sich im Status CrashLoopBackOff.
Prüfen Sie den Pod-Status:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Dabei ist SYSTEM_KUBECONFIG der Pfad zur kubeconfig-Datei.
Der Loki-Fehler wird wie in der folgenden Ausgabe angezeigt, wobei CrashLoopBackOff der Status ist:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
Workaround:
So beheben Sie das Problem:
- Exportieren Sie den Pfad zur kubeconfig-Datei in eine Umgebungsvariable mit dem Namen
SYSTEM_KUBECONFIG.
- Skalieren Sie den Logmon-Operator herunter:
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Loki-Ressourcen herunterskalieren:
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- Löschen Sie die PersistentVolumeClaims (PVCs)
audit-logs-loki-storage-audit-logs-loki-0 und loki-storage-loki-0.
- Löschen Sie die nichtflüchtigen Volumes (Persistent Volumes, PV)
obs-system/loki-storage-loki-0 und obs-system/audit-logs-loki-storage-audit-logs-loki-0.
- Skalieren Sie den Logmon-Operator vertikal:
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- Aktualisieren Sie die Logging-Konfiguration ab Version 1.9.
- Prüfen Sie, ob der
audit-logs-loki-0-Pod ausgeführt wird:
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Der Status Running muss in der Ausgabe wie im folgenden Beispiel angezeigt werden:
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infrastruktur als Code |
1.9.16 |
Symptome:
Beim Upgrade auf 1.9.16 schlägt die Installation des GitLab-Add-ons fehl. Möglicherweise wird ein Fehler wie der folgende angezeigt:
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
Der Postgres-Pod, z. B. gpc-system/gitlab-postgresql-0, befindet sich im Status „Wird beendet“.
Workaround:
- Erzwingen Sie das Löschen des Postgres-Pods, der im Status „Terminating“ (Wird beendet) hängen geblieben ist:
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- Prüfen Sie, ob der Postgres-Pod nach dem Löschen neu erstellt wird.
|
| Identitäts- und Zugriffsverwaltung |
1.9.19
1.9.20 |
Symptome:
Wenn Sie ein Upgrade von Version 1.9.18 durchführen und versuchen, auf die GDC-Konsole zuzugreifen, wird möglicherweise die folgende Meldung angezeigt:
Authentication failed, please contact your system administrator
Workaround:
- Rufen Sie die erforderliche CA ab:
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- Öffnen Sie die Clientkonfigurationsdatei zur Bearbeitung:
kubectl edit clientconfig -n kube-public default
- Suchen Sie in der Clientkonfiguration nach
certificateAuthorityData und aktualisieren Sie die erforderliche Zertifizierungsstelle mit dem folgenden Pfad: spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
