Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme mit Google Distributed Cloud mit Air Gap 1.13.x

Artifact Registry

Abstimmungsfehler bei der Unterkomponente `sar-failoverregistry`

Versionen: 1.13.1, 1.13.3, 1.13.4

Symptome:Beim Erstellen des Root-Administratorclusters mit dem Befehl gdcloud system admin-cluster install kann der Vorgang fehlschlagen, wenn beim Bootstrapping eine lange Liste von Servern vorhanden ist. Die Fehlermeldung lautet:

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

Problemumgehung: So beheben Sie das Problem:

Listen Sie im selben Kubernetes-Cluster wie die Unterkomponente die Server auf und bestätigen Sie, dass jede benutzerdefinierte Serverressource ein Label mit dem Schlüssel cluster.private.gdc.goog/inventory-machine hat:
```
kubectl get servers -n gpc-system
```

Suchen Sie die benutzerdefinierte Ressourcenkomponente, die so aussieht:

  apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

Fügen Sie in der benutzerdefinierten Ressource der System Artifact Registry-Komponente (SAR) den Label-Selektor in den runtimeParameterSources-Servern für sar-failover-registry hinzu:

Sehen Sie sich die vorhandene server-Ressource an:

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

Aktualisieren Sie das Feld „servers“ in der benutzerdefinierten Ressourcenkomponente:

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

Prüfen Sie, ob die Änderungen an der SAR-Komponente im vorherigen Schritt in die Unterkomponente sar-failverregistry übernommen wurden:
1. Rufen Sie die Details der SAR-Komponente ab:
```
kubectl get component | grep sar
```
2. Rufen Sie die Details der Komponente sar-failoverregistry ab:
```
kubectl get subcomponent sar-failoverregistry -n root
```
  Verwenden Sie das Flag -n, um den Namespace anzugeben.

Sichern und wiederherstellen

Snapshots schlagen aufgrund von zu wenig Speicherplatz fehl

Versionen:Alle Versionen von 1.13.x

Symptome:Es gibt ein unregelmäßiges Problem mit der Sicherung nichtflüchtiger Volumes, das sich auf die Arbeitsabläufe periodischer Sicherungsjobs auswirken kann. Bei einigen Volumes mit einer hohen Änderungsrate können Volumesnapshots, die für laufende Sicherungen erstellt werden, dazu führen, dass der Speicherplatz des Volumes erschöpft ist. Das Volume wird dann in den schreibgeschützten Modus versetzt.

Problemumgehung:Folgen Sie den Schritten im BACK-R0104-Runbook, um potenzielle Auswirkungen auf Produktionsarbeitslasten zu vermeiden. Optional können Sie auch angesammelte Snapshots entfernen. Folgen Sie dazu dem Runbook BACK-R0106.

Agent- und Steuerungsebenen-Pods werden aufgrund von Speichermangel neu gestartet

Versionen:Alle Versionen von 1.13.x

Symptome:Die Agent- und Steuerungsebenen-Pods werden möglicherweise neu gestartet, wenn der Arbeitsspeicher nicht mehr ausreicht.

Problemumgehung:Erhöhen Sie den Arbeitsspeicher für die Steuerungsebene und die Agent-Pods. Folgen Sie dazu der Anleitung im BACK-R0005-Runbook. Erhöhen Sie den Arbeitsspeicher für die Pods auf 2 GiB.

Sicherung für PVC-Snapshot schlägt fehl

Versionen:Alle Versionen von 1.13.x

Symptome:Sicherungsfehler sind aufgetreten, weil das ONTAP-Snapshot-Limit von 1.023 pro PersistentVolumeClaim-Ressource (PVC) überschritten wurde.

Problemumgehung: So beheben Sie das Problem:

Aktualisieren Sie den Sicherungsplan so, dass die Limits nie erreicht werden. Konfigurieren Sie einen Sicherungsplan, um stündlich Sicherungen zu erstellen, oder reduzieren Sie die deleteLockDays auf drei, damit die Anzahl der Snapshots nicht über 1.023 steigt:
```
apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS
```
Ersetzen Sie Folgendes:
- LOCK_DAYS: Sperrt das Löschen der Sicherung für die Anzahl der Tage, die nach der Erstellung der Sicherung angegeben werden. Verwenden Sie die folgenden Werte:
  - Wenn das Feld volumeStrategy auf den Wert LocalSnapshotOnly gesetzt ist, verwenden Sie den Wert 2.
  - Wenn das Feld volumeStrategy auf den Wert ProvisionerSpecific gesetzt ist, verwenden Sie den Wert 7.
- RETENTION_DAYS: Löscht Sicherungen nach der Anzahl der Tage, die nach der Sicherungserstellung angegeben wurden. Wenn das Feld volumeStrategy auf den Wert LocalSnapshotOnly gesetzt ist, verwenden Sie einen Wert, der kleiner als 3 ist.

So löschen Sie überflüssige Snapshots in Ihrer Umgebung manuell mit Befehlen zum Löschen von Volume-Snapshots:

Variablen initialisieren:

export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

Ersetzen Sie Folgendes:

ORG_NAME: Der Name Ihrer Organisation.
PVC_NAME: der Name der PVC-Ressource, die mit dem Sicherungsplan verknüpft ist.

NetApp ONTAP ist ein Betriebssystem, das zur Verwaltung des Speichers für GDC verwendet wird. ONTAP-Zugriff erhalten:

export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

Alle Snapshots für die ausgewählte PVC-Ressource auflisten:
```
ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list
```
Verwenden Sie das Passwort aus dem vorherigen Schritt, um sich auf dem Computer mit der IP-Adresse anzumelden, die durch die Variable MGMT_IP definiert wird.

Suchen Sie den PVC mit der höchsten Anzahl von Snapshots:

grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

Legen Sie den Ressourcennamen PVC auf den Namen mit der hohen Anzahl von Snapshots fest:
```
export PV_NAME=
```

Löschen Sie den Snapshot für die PVC-Ressource, die die hohe Anzahl von Snapshots enthält. Die maximale Anzahl von Snapshots für eine PVC-Ressource beträgt 1.023:

for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

Melden Sie sich in ONTAP an und führen Sie die folgenden Befehle aus, um den Snapshot zu löschen:
```
echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}
```
Führen Sie die im vorherigen Schritt aufgeführten Befehle aus, um den Snapshot zu löschen. Beenden Sie anschließend die SSH-Sitzung.

Wiederholen Sie die Löschvorgänge, bis alle anstößigen PVC-Schnappschüsse entfernt wurden.

Wiederherstellen aus einer Sicherung, die nicht mit dem SVM-Kontingent kompatibel ist

Versionen: 1.13.1

Symptome:Das Problem ist eine Inkompatibilität zwischen NetApp-Funktionen. Diese Inkompatibilität verhindert die Bereitstellung des Mandantenkontingents und die erfolgreiche Durchführung von Wiederherstellungen. Das Problem tritt nur auf, wenn eine Sicherung in einem Nutzercluster mit Kontingentbeschränkungen wiederhergestellt wird.

Problemumgehung:Wenn dieses Problem auftritt, schlägt die Wiederherstellung mit der Fehlermeldung DP volumes are not supported on storage-limit enabled Vserver fehl. Der Infrastrukturbetreiber (Infrastructure Operator, IO) muss das Kontingent für diesen Nutzercluster deaktivieren und den Wiederherstellungsvorgang neu starten. Nach Abschluss der Wiederherstellung muss der IO die Mandantenkontingente wieder aktivieren. Das System sollte dann wie vorgesehen funktionieren. Weitere Informationen finden Sie im Runbook FILE A0030.

Abrechnung

Abrechnungsbezogene Messwerte werden im Abrechnungsdashboard nicht richtig angezeigt

Versionen: 1.13.1

Symptome:Abrechnungsbezogene Messwerte werden aufgrund des fehlenden MetricsProxySidecar nicht korrekt an Cortex gesendet.

Problemumgehung:Erstellen Sie eine billing-monetizer-MetricsProxySidecar-Ressource. Führen Sie dann ein Skript aus, um metricExpression zu aktualisieren.

Exportieren Sie die folgende kubeconfig-Variable:
```
export KUBECONFIG=KUBECONFIG_PATH
```
Ersetzen Sie die Variable KUBECONFIG_PATH durch den Pfad zur kubeconfig-Datei für den Administratorcluster der Organisation. Folgen Sie der Anleitung im Servicehandbuch IAM-R0101, um die für diesen Workaround erforderliche Datei kubeconfig zu generieren.

Erstellen Sie eine billing-monetizer-MetricsProxySidecar-Ressource für die Namespaces billing-system und partner-billing-system:

Für billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

Für partner-billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

Führen Sie das folgende Skript aus, um die metricExpression zu aktualisieren. Dadurch wird die container_name="monetizer" aus der skuconfig entfernt, die Folgendes umfasst: billing_total_cost{container_name="monetizer":

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

Nutzer kann `BillingAccountBinding` aufgrund von Fehlern im Validierungs-Webhook nicht erstellen

Versionen: 1.13.0, 1.13.1, 1.13.3

Symptome:Der Fehler liegt in der Logik des BillingAccountBinding-Validierungs-Webhooks. Wenn ein Nutzer versucht, eine BillingAccountBinding-Ressource zu erstellen, gibt der Webhook den Fehler permission denied zurück.

Problemumgehung:Wenn Sie BillingAccountBinding-Ressourcen erstellen möchten, benachrichtigen Sie den Infrastrukturbetreiber und erstellen Sie die entsprechenden Ressourcen über IAC.

Blockspeicher

Grafana-Pods bleiben aufgrund von Fehlern beim Einbinden von Volumes im Status `Init` hängen.

Versionen: 1.13.3

Symptome:

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 ist auf einen Fehler in Trident zurückzuführen, 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.

Problemumgehung:

Prüfen Sie den PVC auf einen deletionTimestamp. 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 (Löschzeitstempel für das Volume) vorhanden ist, 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:
```
stat DEVICE_PATH
```
Prüfen Sie, ob die Seriennummer derzeit einem Multipath-Gerät zugeordnet ist.
1. Kopieren Sie den Wert im Feld iscsiLunSerial der Tracking-Datei.
2. Konvertieren Sie diesen Wert in den erwarteten Hex-Wert:
```
echo 'iISCSILUNSERIAL' | xxd -l 12 -ps
```
3. Prüfen Sie mit diesem neuen Wert, ob der Multipath-Eintrag noch vorhanden ist:
```
multipath -ll | grep SERIAL_HEX
```
4. Wenn sie nicht vorhanden ist, löschen Sie die Tracking-Datei.
5. Wenn sie vorhanden ist, sehen Sie einen etwas längeren seriellen Hexadezimalwert als den gesuchten, der als multipathSerial bezeichnet wird. Führen Sie den folgenden Befehl aus und suchen Sie nach den Blockgeräten:
```
multipath -ll MULTIPATH_SERIAL
```
6. Führen Sie dann die folgenden Befehle aus. Der letzte Befehl muss für jedes Blockgerät einzeln ausgeführt werden:
```
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
```

Launcher-Pods für virtuelle Maschinen können keine Volumes zuordnen

Versionen: 1.13.1

Symptome:

Möglicherweise wird eine Warnung wie diese angezeigt:

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

So diagnostizieren Sie das Problem:

Achten Sie darauf, dass sich Volumes und Pods auf demselben Knoten befinden.
Suchen Sie den Knoten, auf dem sich die Pods befinden, und prüfen Sie seinen Zustand.
Knotenverbindung prüfen
IPSEC prüfen
Prüfen Sie, ob ein Zombie vorhanden ist.
Prüfen Sie die Trident-Logs, um herauszufinden, in welchem Schritt des CSI-Ablaufs dieser Zombie eingeführt wurde:
```
kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main
```

Problemumgehung: Führen Sie die Schritte in den folgenden Runbooks aus, um dieses Problem zu umgehen:

Informationen zu Problemen mit Knoten finden Sie im Runbook FILE-R0010.
Informationen zu Problemen mit IPSEC finden Sie im Runbook FILE-R0007.
Informationen zu Problemen mit Zombie-LUNs finden Sie im FILE-R0020-Runbook.
Informationen zu Problemen mit Super-Zombie-LUNs finden Sie im Runbook FILE-R0021.

Speicherbezogene Fehler

Versionen: 1.13.1

Symptome: Speicherbezogene Fehler können durch die Auslösung der Benachrichtigung file_block_zombie_luns_present oder dadurch erkannt werden, dass der Pod aufgrund eines Problems im MountVolume-Aufruf, das länger als ein Abgleichzyklus andauert, nicht gestartet werden kann. Die Zeitüberschreitung kann etwa zwei Minuten dauern. Eine Wiederholung desselben Fehlers deutet darauf hin, dass etwas im NodeStage- oder NodePublish-CSI-Pfad fehlgeschlagen ist und eine Problemumgehung erforderlich ist. Die einzige Ausnahme ist die Angabe eines Zeitüberschreitungsfehlers. Möglicherweise werden einige Fehler wie die folgenden angezeigt:

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

Problemumgehung:

Wenn Sie prüfen möchten, ob die Node mit dem Pod für den fehlerhaften PVC korrigiert werden kann, sperren Sie den aktuellen Knoten, auf dem der Pod geplant ist, und löschen Sie den Pod:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE
```
Die Pod sollte für eine völlig andere Node geplant werden, was dazu führt, dass Trident die NodeStage-, NodePublish-, NodeUnpublish- und NodeUnstage-Vorgänge vollständig durchlaufen muss. Das Problem wird dadurch möglicherweise nicht sofort behoben, da für dieses Volume auf dem ursprünglichen Node möglicherweise noch Sitzungen geöffnet sind.
Nachdem der vorherige Schritt abgeschlossen ist, heben Sie die Sperrung des betreffenden Knotens auf:
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE
```
Wenn weiterhin Fehler vorhanden sind, sperren Sie alle anderen Nodes mit Ausnahme des Nodes, in dem die Pod ursprünglich geplant war, und löschen Sie die Pod. Dadurch sollte Pod auf dem ursprünglichen Node gestartet werden, auf dem sich möglicherweise noch vorhandene Geräte befinden.
Heben Sie nach Abschluss des vorherigen Schritts die Sperrung der betreffenden Knoten auf.
Als letzte Möglichkeit, die PV und ihre Daten zu retten, kann die Node neu gestartet werden, um Multipath-, udev- und devmapper-Fehler auf der Node zu beheben. Dieser Schritt ist zwar mühsam, aber am wahrscheinlichsten erfolgreich.
Wenn das Problem mit dem Volume durch die vorherigen Maßnahmen nicht behoben werden kann, sind die Daten beschädigt und können nicht mehr verwendet werden. Die einzige verbleibende Option, um das beabsichtigte Containerverhalten fortzusetzen, besteht darin, die Fehler PV, PVC und Pod zu beheben und dann den Knoten neu zu starten, auf dem das PV gehostet wurde. Diese Aktion führt zu einem vollständigen Datenverlust aller Daten, die bereits auf das Volume geschrieben wurden.

Nichtflüchtige Volumes mit falscher Größe erstellt

Versionen: 1.13.1

Symptome: Arbeitslasten mit einem persistenten Volume werden etwa 16 MiB zu klein erstellt. Wenn Arbeitslasten genau von der Größe abhängen, die von einem persistenten Volume beworben wird, führt die geringe Abweichung dazu, dass die Arbeitslast beim Erweitern oder Bereitstellen fehlschlägt. Dieses Problem tritt eher bei nichtflüchtigen Volumes auf, die mit einer standard-block-Speicherklasse bereitgestellt werden, als bei Volumes, die mit einer standard-rwo-Speicherklasse bereitgestellt werden. Dieses Problem kann bei nichtflüchtigen Volumes mit der Speicherklasse standard-rwo auftreten, die den Modus volumemode:block verwenden.

Problemumgehung: Weisen Sie ein nichtflüchtiges Volume zu, das mindestens 16 MiB größer ist als tatsächlich erforderlich.

Virtuelle Speichermaschine kann nicht gelöscht werden

Versionen: 1.13.1

Symptome: Auf dem StorageVirtualMachine wird möglicherweise ein Fehler wie dieser angezeigt:

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

Problemumgehung: Löschen Sie den Finalizer aus StorageVirtualMachines im Namespace „org“.

Durch Deaktivieren der Organisation werden Ressourcen nicht bereinigt

Versionen: 1.13.1

Symptome: Beim Deaktivieren einer Organisation bleiben einige StorageVirtualMachines-Ressourcen übrig, z. B.:

gpc-system secret/org-2-admin-backup-agent-cert-secret
gpc-system secret/org-2-admin-client-cert-secret
gpc-system secret/org-2-admin-server-cert-secret
gpc-system secret/org-2-admin-svm-credential
gpc-system secret/org-2-admin-backup-agent-cert-secret
gpc-system secret/org-2-admin-client-cert-secret
gpc-system secret/org-2-admin-server-cert-secret
gpc-system secret/org-2-admin-svm-credential

Problemumgehung: Löschen Sie diese Ressourcen.

Fehler beim Abgleich des Löschens

Versionen: 1.13.1

Symptome: Wenn ein StorageVirtualMachine vor dem Bereinigen von Clustern gelöscht wird, die von diesem StorageVirtualMachine abhängen, kann es zu Problemen beim Bereinigen einiger Persistent Volumes (PVs) der Cluster kommen. Wenn LUKS-verschlüsselte PVs nicht bereinigt werden, verhindert ihr Secret das Löschen des Namespace, in dem sie sich befinden. Möglicherweise wird in den Logs eine Warnung wie diese angezeigt:

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

Problemumgehung:Löschen Sie den Finalizer aus den g-luks-gdc-vm-disk-*-Secrets im Namespace des Dienstclusters.

Bare-Metal-Upgrade bleibt hängen

Versionen: 1.13.1, 1.13.5, 1.13.6

Symptome:Ansible-Jobs bleiben beim Erfassen von Fakten hängen, wenn Zombie-LUNs vorhanden sind. Wenn Sie den Befehl multipath -ll ausführen, wird möglicherweise das folgende Problem angezeigt:

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
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
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

Möglicherweise wird auch die folgende Fehlermeldung angezeigt:

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

Problemumgehung: Prüfen Sie die SSH-Verbindung zum Zielknoten und verwenden Sie dann das folgende Runbook: FILE-R0020.

Fehler beim Anhängen mehrerer Dateien in Trident

Versionen: 1.13.3

Symptome: Pods und PVCs sind möglicherweise auf verschiedenen Knoten verblieben und der Pod hängt in der Initialisierung fest und wartet auf den PVC.

Workaround:

Prüfen Sie das PVC auf deletionTimestamp:

kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

Wenn keine deletionTimestamp (Pod-Migration) vorhanden ist:
1. Prüfen Sie die VolumeAttachment für den PVC, um festzustellen, wo das Volume angehängt ist.
2. Isolieren Sie die Knoten im Cluster, die nicht mit diesem Wert übereinstimmen.
3. Löschen Sie den fehlerhaften Pod. Durch diese Aktion wird der POD zurück zum ursprünglichen Knoten migriert.
Hinweis: Bei dieser Aktion wird kein Zombie erstellt, da der serielle Hexadezimalwert, den Trident für den Multipath-Eintrag verwendet, aus der tatsächlichen LUN-Ressource in ONTAP stammt. Wenn das Gerät bereits vorhanden ist, wird der ursprüngliche Wert wiederhergestellt. Wenn das Gerät nicht vorhanden ist, wird der Wert korrekt erstellt.
Wenn deletionTimestamp (Volume deletion) vorhanden ist:
1. Prüfen Sie die VolumeAttachment für den PVC, um festzustellen, wo das Volume angehängt ist.
2. Geben Sie auf dem Knoten den Inhalt der zugehörigen Tracking-Datei /var/lib/trident/tracking/PVC_NAME.json aus.
3. 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: stat DEVICE_PATH. Wenn der Pfad weiterhin vorhanden ist, liegt ein anderes Problem vor.
4. Prüfen Sie, ob die Seriennummer einem Multipath-Gerät zugeordnet ist.
5. Kopieren Sie den Wert im Feld „iscsiLunSerial“ der Tracking-Datei.
6. Konvertieren Sie diesen Wert in den erwarteten Hexadezimalwert: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
7. Prüfen Sie mit diesem neuen Wert, ob der Multipath-Eintrag noch vorhanden ist: multipath -ll | grep SERIAL_HEX.
8. Wenn sie nicht vorhanden ist, löschen Sie die Tracking-Datei.
9. Wenn sie vorhanden ist, sehen Sie einen etwas längeren seriellen Hexadezimalwert als den, nach dem Sie gesucht haben. Notieren Sie diesen Wert als MULTIPATH_SERIAL. Wenn Sie multipath -ll MULTIPATH_SERIAL ausführen, wird eine Meldung wie diese angezeigt:
```
3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running
```
10. Führen Sie folgende Befehle aus:
  1. systemctl restart iscsid
  2. systemctl restart multipathd
  3. multipath -f MULTIPATH_SERIAL
  4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
11. Führen Sie den letzten Befehl für jedes Blockgerät einzeln aus.

Fehler in der IPsec-Konfiguration

Versionen: 1.13.4

Symptome:Bei der ONTAP-IPsec-Konfiguration tritt ein Fehler aufgrund eines ungültigen vorinstallierten Schlüssels (Pre-Shared Key, PSK) auf, der 0X enthält. Dieser wird als hexadezimale Zeichenfolge interpretiert.

Möglicherweise wird eine Warnung wie diese angezeigt:

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

Workaround:

Rufen Sie die Verbindungen für die Speicherverschlüsselung ab:

kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

Suchen Sie nach dem Eintrag mit Ready=False und notieren Sie sich den Namen des PRESHAREKEY. Die Ausgabe könnte so aussehen:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

Auf dieser Maschine wird eine GPU-Organisation ausgeführt. Löschen Sie daher secrets gpc-system/vm-5a77b2a2-pre-shared-key in gpu-org-admin.
Warten Sie, bis das System secret/vm-5a77b2a2-pre-shared-key neu erstellt hat.
Suchen Sie nach einem Job mit einem Muster wie gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Die letzten acht Zeichen werden zufällig generiert. Wenn der Schlüssel wieder verfügbar ist, löschen Sie den Job, z. B. jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl in gpu-org-admin.

Die virtuelle Storage-Maschine wird nicht erstellt

Versionen: 1.13.5

Symptome:Der Harbor-Dienst auf gpu-org kann aufgrund eines Problems beim Bereitstellen von Volumes nicht gestartet werden. Dieses Problem wird dadurch verursacht, dass der file-storage-backend-controller-Pod auf einen nicht vorhandenen Inventarcomputer verweist.

Möglicherweise wird ein Speichercontrollerfehler wie der folgende angezeigt, der darauf hinweist, dass InventoryMachine nicht gefunden wurde:

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

Workaround:

Löschen Sie den Pod file-storage-backend-controller.
Lassen Sie den Speichercontroller die vorhandenen Inventarmaschinen noch einmal abrufen.

Abstimmung von Storage-Intercluster-Netzwerken fehlgeschlagen

Versionen: 1.13.5, 1.13.6

Symptome: Nach einem Upgrade kann die benutzerdefinierte Ressource StorageCluster im Administratorcluster des Stammverzeichnisses aufgrund einer Fehlkonfiguration der Intercluster-Subnetze in der Spezifikation nicht bereit werden. Der Speichercluster meldet Not Ready und enthält ein Ereignis mit diesem Fehler:

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

Wenn dieser Fehler auftritt, enthält der vom Speichercluster verwendete Anspruch für das Intercluster-Subnetz das Feld kind nicht im Verweis. Bei der Überprüfung der benutzerdefinierten Ressource StorageCluster finden Sie einen Intercluster-Subnetzanspruchsverweis mit nur einem Namen und einem Namespace wie diesem:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Problemumgehung: Aktualisieren Sie die StorageCluster-Spezifikation, damit das Feld kind: SubnetClaim im Subnetzanspruchsverweis enthalten ist:

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

Nachdem Sie die StorageCluster-Spezifikation aktualisiert haben, starten Sie die file-storage-backend-controller-Bereitstellung neu und prüfen Sie, ob der Speichercluster bereit ist.

Clusterverwaltung

`machine-init`-Job schlägt während der Clusterbereitstellung fehl

Versionen: 1.13.1

Symptome:

Während der Clusterbereitstellung schlägt der machine-init-Job des zweiten Knotens der Steuerungsebene mit der folgenden Meldung fehl:
```
FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".
```

Rufen Sie die Logs auf:

kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-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 und vor dem nächsten Ausführen des machine-init-Jobs geändert werden, da machine-init die Berechtigung wieder in „root“ ändert.machine-init
Starten Sie etcd im zweiten Knoten neu, um etcd im 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.

Keine Verbindung vom Dienstcluster zum Object Storage-Bucket

Versionen: 1.13.1

Symptome:Die Verbindung für einen Datenbank-Pod, der im Servicecluster ausgeführt wird, zu einem Objektspeicher-Bucket im Administratorcluster der Organisation schlägt fehl.

Problemumgehung:Folgen Sie der Anleitung im KUB-R0305-Runbook.

Preflight-Prüfung fehlgeschlagen

Versionen: 1.13.1

Symptome: Möglicherweise wird im Status des Clusterobjekts die folgende Meldung angezeigt:

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

Außerdem sollte ein entsprechendes PreflightCheck-Objekt mit demselben Namen und Namespace wie das Clusterobjekt vorhanden sein, das seit mehreren Stunden vorhanden ist, obwohl der im PreflightCheck-Objekt angegebene Fehler oder Ausfall bekanntlich nicht mehr besteht.

Problemumgehung: Löschen Sie das PreflightCheck-Objekt.

Erstellung des Worker-Knotenpools des Nutzerclusters schlägt fehl

Versionen: 1.13.5

Symptome: Die Erstellung des Worker-Knotenpools des Nutzerclusters reagiert möglicherweise nicht mehr, wenn einer der folgenden Maschinentypen verwendet wird:

n2-standard-16-gdc
n2-standard-32-gdc
n2-highmem-16-gdc
n2-highmem-32-gdc

Problemumgehung: Löschen Sie den Knotenpool und erstellen Sie ihn neu, indem Sie in der Drop-down-Liste der Benutzeroberfläche zur Erstellung von Nutzerclustern andere verfügbare Maschinentypen auswählen.

Neu erstellte Nutzercluster bleiben aufgrund einer nicht ordnungsgemäßen Bereinigung möglicherweise beim Abgleich hängen.

Versionen: 1.13.x

Symptome: Wenn Nutzercluster mit demselben Namen wie ein zuvor gelöschter Cluster erstellt werden, bleiben sie möglicherweise unendlich lange im Status Reconciling hängen. Der Status gibt die Add-on-Installationsphase ONE an.

Problemumgehung: Deinstallieren Sie das Helm-Add-on CLUSTER_NAME-abm-overrides und starten Sie das managed-adm-controller-Deployment neu. Folge der Anleitung unter MKS-R0004.

Datenbankdienst

Dieser Abschnitt enthält bekannte Probleme für den Datenbankdienst.

Klonen der AlloyDB Omni-Datenbank bleibt hängen

Versionen: Alle Versionen von 1.13.x

Symptome: Wenn ein Nutzer einen AlloyDB Omni-Cluster zu einem bestimmten Zeitpunkt klont, bleibt der geklonte Datenbankcluster mit dem Fehler DBSE0005 hängen und kann nicht bereit werden. Die entsprechende restore.alloydb-Ressource befindet sich im Status „ProvisionInProgress“.

Problemumgehung: Um dieses Problem zu umgehen, wählen Sie den Zeitpunkt sorgfältig aus der COMPLETETIME erfolgreicher Sicherungen aus.

Listet verfügbare AlloyDB Omni-Sicherungen auf, aus denen auf dem Management API-Server geklont werden kann.

kubectl get backups.alloydb -n source-dbcluster-namespace

Beispielausgaben:

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

Wählen Sie einen COMPLETETIME-Wert als Zeitpunkt für den Klon aus. Die Zeit ist in UTC angegeben.

Die Erzwingung von IOPS wirkt sich auf die Speicherleistung aus

Versionen: 1.13.1

Problemumgehung: Führen Sie einen der folgenden Schritte aus, um das Problem zu umgehen:

Erhöhen Sie die Speichergröße.
IOPS-Kontingent überschreiben

Abstimmungsfehler beim Upgrade der Unterkomponente `dbs-fleet`

Versionen: 1.13.3

Symptome: Beim Upgrade der Stammorganisation von 1.13.1 auf 1.13.3 wird möglicherweise ein Abgleichsfehler angezeigt. Auf Abstimmungsfehler prüfen:

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

Der Fehler könnte so aussehen:

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

Problemumgehung: Folgen Sie der Anleitung im OCLCM-R0122-Runbook.

Fehler beim Erstellen von DBCluster

Versionen: 1.13.3

Symptome: Nach dem Upgrade auf 1.13.3 können neue DB-Cluster nicht abgeglichen werden. Im Status wird der folgende Fehler angezeigt:

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

Problemumgehung

Prüfen Sie, ob im Administratorcluster der Organisation localrollout CRs vorhanden sind, die sowohl mit cpa-v0.12.46 als auch mit cpa-v0.12.51 enden. Beispiel:

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

Suchen und löschen Sie localrollout-CRs, die mit cpa-v0.12.46 enden, damit andere localrollout-CRs nicht beeinträchtigt werden.

kubectl get localrollouts -A | grep cpa-v0.12.46

Es sollte eine Liste wie diese zurückgegeben werden:

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

Löschen Sie die einzelnen Elemente:

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

Prüfen Sie, ob localrollout-CRs, die mit cpa-v0.12.51 enden, noch vorhanden sind:

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

DNSSEC muss in „resolved.conf“ explizit deaktiviert werden.

Versionen: 1.13.1, 1.13.3, 1.13.4

Symptome: Die DNS-Auflösung schlägt auf Bare-Metal- oder VM-Knoten fehl. Um zu bestätigen, dass die DNS-Auflösung fehlschlägt, stellen Sie eine SSH-Verbindung zum betroffenen Knoten her und führen Sie systemctl status systemd-resolved aus. Die Ausgabe enthält Zeilen wie DNSSEC validation failed for question . IN SOA: no-signature.

Problemumgehung:

Fügen Sie dem betroffenen Knoten die folgende Zeile in /etc/systemd/resolved.conf hinzu.
```
DNSSEC=false
```

Starten Sie den Dienst systemd-resolved neu:

systemctl restart systemd-resolved.service

Hafenservice

Fehler beim Erstellen des Harbor-Dienstes

Versionen: 1.13.6

Symptome: Das Erstellen einer Harbor-Instanz schlägt aufgrund einer Namespace-Inkompatibilität fehl, die durch eine Längenbeschränkung im Namen ServiceIsolationEnvironment verursacht wird. Möglicherweise wird eine Meldung wie diese angezeigt:

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

Problemumgehung: Kürzen Sie den Namen der Harbor-Instanz, um das aktuelle Problem zu beheben. Die kombinierte Länge von PROJECT_NAME und HARBOR_INSTANCE_NAME darf maximal 26 Zeichen betragen.

Durch das Löschen von Harbor-Instanzen werden die zugehörigen Registry-Spiegel nicht gelöscht.

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8

Symptome: Beim Löschen von Harbor-Instanzen werden die zugehörigen Registry-Spiegelungen nicht gelöscht. Der Knotenpool befindet sich möglicherweise im Status Provisioning. Das liegt daran, dass die vom MHS-Controller erstellten Registry-Spiegel nicht gelöscht werden, wenn die Harbor-Instanzen gelöscht werden.

Problemumgehung: Sie müssen die Registry-Spiegel manuell entfernen. So beheben Sie das Problem:

Stellen Sie eine Verbindung zum Organisationsadministratorcluster her. Weitere Informationen finden Sie unter GDC-Clusterarchitektur.

Führen Sie dieses Skript aus, um alle Registry-Spiegel zu entfernen, die mit dem Wert der Umgebungsvariablen HARBOR_INSTANCE_URL in allen Kubernetes-Clustern übereinstimmen, die das Label lcm.private.gdc.goog/cluster-type=user haben:

LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

Ersetzen Sie HARBOR_INSTANCE_URL durch die URL Ihrer Harbor-Instanz.

Hardwaresicherheitsmodul

Deaktivierte HSM-Testlizenzen sind weiterhin erkennbar

Versionen:1.13.1, 1.13.3–1.13.11

Symptome:Aufgrund eines bekannten Problems in CipherTrust Manager sind deaktivierte Testlizenzen weiterhin erkennbar und lösen möglicherweise fälschlicherweise Ablaufwarnungen aus.

Problemumgehung:Weitere Informationen finden Sie unter HSM-R0003. Dort erfahren Sie, wie Sie die aktiven regulären Lizenzen prüfen und die deaktivierten Testlizenzen löschen.

HSM-Host-Daemon-Dateideskriptor-Datenleck

Versionen:1.13.x

Symptome:Wenn HSMs länger als 30 Tage ausgeführt werden, kann ein Leck bei Dateideskriptoren dazu führen, dass der Host-Daemon-Dienst nicht mehr reagiert, was zu einem ServicesNotStarted-Fehler führt.

Problemumgehung: Starten Sie den Host-Daemon-Dienst neu. Bitten Sie dazu Ihren Infrastrukturoperator (IO), als ksadmin-Nutzer eine SSH-Verbindung zum HSM herzustellen und den folgenden Befehl auszuführen:

sudo systemctl restart host-daemon

Wenn das nicht funktioniert, kann Ihr IO das fehlerhafte HSM neu starten.

HSM-Zertifikate abgelaufen

Versionen: 1.13.11

Symptome: Beim Aktualisieren einer Organisation wird möglicherweise eine Warnung wie diese angezeigt:

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

Das org-1-system-cluster hängt aufgrund abgelaufener HSM-Zertifikate (Hardware Security Module) in einem ABM-Versionsupgrade fest.

Möglicherweise wird auch ein Fehler wie im folgenden Beispiel in HPE-Server iLO, StorageGRID oder ONTAP angezeigt:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Problemumgehung:

Rotieren Sie das Stammzertifizierungsstellen- und das Webinterface-Zertifikat manuell mit ksctl:

Alle Antwortvorlagen für HSM, HSMCluster und HSMTenant pausieren.

Erstellen Sie eine neue Stamm-CA mit Attributen, die von der alten kopiert wurden. Suchen Sie die alte CA-ID mit ksctl ca locals list. Ein Beispiel:

ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

Signieren Sie die neue CA selbst mit einer Gültigkeitsdauer von einem Jahr. Ein Beispiel könnte so aussehen:

ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

Aktualisieren Sie die Weboberfläche, damit diese neue CA für die automatische Zertifikatsgenerierung verwendet wird. Ein Beispiel könnte so aussehen:

ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

Generieren Sie ein neues Webinterface-Zertifikat, das von der neuen Zertifizierungsstelle signiert ist. Das Flag --url ist die Verwaltungs-IP des HSM (aus kubectl get hsm -n gpc-system). Ein Beispiel könnte so aussehen:

ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

Zu diesem Zeitpunkt wird in openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text noch das alte Zertifikat angezeigt. Sie müssen das HSM neu starten, damit das neue Zertifikat übernommen wird.
```
ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot
```
Unter openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text wird nun das neue Zertifikat angezeigt.

Löschen Sie die alte CA aus der HSM-CR:

kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

HSM-Pausenmodus beenden:

kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

Stellen Sie sicher, dass das HSM fehlerfrei ist.

Wiederholen Sie diese Schritte für die anderen beiden HSMs. Sie haben bereits die neue selbstsignierte Root-Zertifizierungsstelle, da die Zertifizierungsstelle zwischen HSMs in einem Cluster geteilt wird. Überspringen Sie die Schritte 2 und 3, wiederholen Sie aber die Schritte 4 bis 8.
Folgen Sie der HSM T0008-Aufgabe zur CA-Rotation, um die Rotation aller Zertifikate zu automatisieren. Überspringen Sie jedoch den Schritt Rotation abschließen, indem Sie hsmcluster eine neue Rotationsanmerkung hinzufügen, in dem ca-rotation-finalizing annotation hinzugefügt wird.

Laden Sie den neuen CA-Namen in iLO hoch:

Öffnen Sie in der iLO-Schnittstelle die Seite „Administration“ – „Key Manager“ und klicken Sie auf den Tab Key Manager.
Rotieren Sie den Zertifikatsnamen.
Führen Sie einen Kaltstart durch.
Prüfen Sie, ob der SSL-Handshake wieder funktioniert.

Identitäts- und Zugriffsverwaltung

`gatekeeper-audit`-Pods im Namespace `opa-system` werden häufig neu gestartet

Versionen: 1.13.3

Symptome:Prüfen Sie den Status der gatekeeper-audit-***-Pods im Namespace opa-system:

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

Die Ausgabe könnte so aussehen:

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

Dieses Problem wird durch niedrige Ressourcenlimits verursacht.

Infrastruktur als Code (IaC)

Durch das Erstellen einer großen Anzahl von GitLab-Tokens besteht das Risiko, dass die GitLab-Datenbanken gefüllt werden.

Versionen:1.13.1

Symptome:Die Unterkomponente iac-manager erstellt wiederholt ein neues Token für den Nutzer configsync-ro, auch wenn dies nicht erforderlich ist. Dies kann dazu führen, dass die GitLab-Datenbank voll wird und IAC nicht mehr zugänglich ist. Der pg-gitlab-database-0-Pod im Namespace gitlab-system kann möglicherweise nicht gestartet werden und zeigt Ereignisse wie die folgenden an:

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

Workaround:

Wenden Sie sich an Ihren Google-Ansprechpartner, um hotfix_3 für Version 1.13.1 zu erhalten und anzuwenden.

Schlüsselverwaltungssystem (KMS)

Wenn Sie den Typ des Stammschlüssels ändern, werden alle vorhandenen Schlüssel ungültig.

Versionen: 1.13.x

Symptome:Wenn eine Organisation erstellt wird, wird der KMS automatisch mit einem Software-Stammschlüssel bereitgestellt. Um von einem Software-Root-Schlüssel zu einem CTM-Schlüssel zu migrieren, führen Nutzer eine Überschreibung der Unterkomponente durch. Dadurch wird der Root-Schlüsseltyp geändert, wodurch alle vorhandenen Softwareschlüssel im KMS ungültig werden.

Problemumgehung:Vermeiden Sie nach Möglichkeit die Aktualisierung des Root-Schlüsseltyps. Wenn Sie den Typ des Stammschlüssels aktualisieren, werden alle vorhandenen Schlüssel ungültig.

`kms-rootkey-controller` `CrashLoopBackOff` aufgrund von `OOMKILL`

Versionen: 1.13.1

Symptome:Wenn die kms-rootkey-controller-Speichernutzung das 600Mi-Limit überschreitet, wechselt der Controller aufgrund des Status OOMKilled in den Status CrashLoopBackOff.

Problemumgehung: Erstellen Sie eine SubcomponentOverride, um das Arbeitsspeicherlimit auf 1500Mi zu aktualisieren. Eine Anleitung finden Sie im KMS-Runbook 0007. Führen Sie nach Abschluss der erforderlichen Schritte aus dem Runbook die folgenden Befehle aus:

Benutzerdefinierte SubcomponentOverride-Ressource erstellen:

cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

Im folgenden Beispiel sehen Sie eine vollständige benutzerdefinierte SubcomponentOverride-Ressource:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

Wenden Sie die Ressource SubcomponentOverride an:

kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

Logging

Der Audit-Logger für Objektspeicher kann den DNS-Host nicht auflösen

Versionen: 1.13.x

Symptome:

Im Administratorcluster des Stammverzeichnisses enthält die obs-system/log-remote-logger-Bereitstellung mehrere Fehler wie die folgenden:

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

Problemumgehung: Patchen Sie das obs-system/log-remote-logger-Deployment mit dem folgenden Befehl:

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

HaaS Logger zeigt Fehler im Root-Administratorcluster an

Versionen: 1.13.x

Symptome:

Im Administratorcluster des Stammverzeichnisses enthält die obs-system/log-remote-logger-Bereitstellung mehrere Fehler wie die folgenden:

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

Problemumgehung: Führen Sie ein Upgrade auf Version 1.13.8 durch, um den Fehler zu beheben. Alternativ können Sie das obs-system/log-remote-logger-Deployment so ändern:

Aktualisieren Sie in den remote-logger-Containerargumenten das Flag --disabled-loggers, damit es Santricity und HaaS enthält:

YAML

args:
  - --disabled-loggers=santricity,haas

Santricity Logger schlägt fehl

Versionen: 1.13.x

Symptome:

Im Administratorcluster des Stammverzeichnisses enthält die obs-system/log-remote-logger-Bereitstellung mehrere Fehler wie die folgenden:

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

Problemumgehung: Führen Sie ein Upgrade auf Version 1.13.8 durch, um den Fehler zu beheben.

Logging Target-Logs werden an das falsche Projekt gesendet

Versionen: 1.13.x

Symptome: In den Logs des obs-system/oplogs-forwarder-DaemonSets werden Warnungen wie die folgenden angezeigt:

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

Diese Warnungen führen dazu, dass Logs an das falsche Projekt (Mandanten-ID) weitergeleitet werden. Dieses Problem ist auf einen bekannten Fehler in Fluent Bit zurückzuführen. Weitere Informationen finden Sie im GitHub-Problem zu Fluent Bit.

Problemumgehung: Führen Sie ein Upgrade auf Version 1.13.8 durch, um den Fehler zu beheben.

Audit-Logs aus dem Plattform-Namespace sind für den PA nicht sichtbar.

Versionen: 1.13.x

Symptome: Audit-Logs aus dem Plattform-Namespace sind für den Infrastrukturbetreiber (Infrastructure Operator, IO) anstelle des Plattformadministrators (Platform Administrator, PA) sichtbar.

Problemumgehung: Fügen Sie das Label observability.gdc.goog/auditlog-destination=pa dem Namespace platform in allen Clustern der Organisation manuell hinzu. So implementieren Sie diese manuelle Problemumgehung:

Setzen Sie KUBECONFIG auf den Zielcluster.

Fügen Sie dem Namespace das erforderliche Label hinzu:

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

Prüfen Sie, ob das Label erfolgreich hinzugefügt wurde:

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Pods können Container nicht initialisieren

Versionen: 1.13.x

Symptome: Die Pods können nicht erstellt werden. Es wird ein Fehler ähnlich dem folgenden angezeigt:

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

Diese Fehler verhindern, dass Pods auf einem bestimmten Knoten gestartet werden. Das beobachtete Verhalten ist auf einen bekannten Grenzfall zurückzuführen, in dem die Statusdatei logrotate-daemon gesperrt wird, sodass der Daemon die erwartete Dateirotation nicht ausführen kann. So bestätigen Sie diesen Fehler:

Setzen Sie KUBECONFIG auf den Zielcluster.

Ermitteln Sie die anthos-audit-logs-forwarder-xxxx-Instanz, die auf dem Knoten geplant ist.

KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

Rufen Sie Logs von der anthos-audit-logs-forwarder-xxxx-Instanz ab, die auf dem zu prüfenden Knoten geplant ist.

KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

Problemumgehung:

Gehen Sie so vor, um das Problem zu beheben:

Führen Sie eine manuelle Speicherplatzfreigabe im Verzeichnis /var/log des Knotens durch.
Setzen Sie KUBECONFIG auf den Zielcluster.

Ermitteln Sie den Zielknoten im Cluster.

KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

Stellen Sie über SSH eine Verbindung zum Knoten her und geben Sie manuell Speicherplatz im Verzeichnis /var/log auf dem Knoten frei. Der logrotate verwaltet Dateien in diesen Verzeichnissen.

/var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

Suchen Sie nach ungewöhnlich großen Logdateien (Größe über 100 MB) oder Dateien, die älter als ein paar Tage sind. Wenn Sie die Zieldatei haben, können Sie die Logs so kürzen:
```
truncate -s 1G <target_file>
```

Ermitteln Sie die anthos-audit-logs-forwarder-xxxx-Instanz, die auf dem Knoten geplant ist.

KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

Starten Sie die anthos-audit-logs-forwarder-xxxx-Instanz neu, die auf dem Knoten geplant ist.

KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Fehler beim Abrufen von Prisma Cloud-Images

Versionen: 1.13.7

Symptome: Das Erstellen einer Prisma Cloud-Dienstinstanz über den Marketplace schlägt fehl. Das Problem wird durch ein falsches Bild-Tag verursacht.

Problemumgehung:

Bearbeiten Sie das twistlock-console-Deployment, um das Image-Tag zu ändern:

KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

Suchen Sie die folgende Zeile:

image: HARBOR_IP/library/twistlock/console:console_33_01_137

Ersetzen Sie console_33_01_137 durch console_33.01.137:

image: HARBOR_IP/library/twistlock/console:console_33.01.137

Prüfen Sie, ob der Pod ordnungsgemäß ausgeführt wird:

KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

Die Ausgabe könnte so aussehen:

NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

Monitoring

Es werden sehr viele Benachrichtigungen in ServiceNow erstellt

Versionen: 1.13.x

Symptome:

Nachdem Sie Monitoring so konfiguriert haben, dass Benachrichtigungen mithilfe der Toil-Aufgaben MON-T0016 und MON-T1016 an ServiceNow gesendet werden, wird eine große Anzahl von Vorfällen automatisch in ServiceNow erstellt.

Das Problem hat die folgenden Merkmale:

Alle Vorfälle sind leer.
Nur der Administrator-Stammcluster und die Organisation gdchservices können Benachrichtigungen an ServiceNow senden.

Problemumgehung: Führen Sie die Toil-Aufgabe MON-T0018 unmittelbar nach den Toil-Aufgaben MON-T0016 und MON-T1016 aus.

Es wurden mehrere doppelte Benachrichtigungen in ServiceNow erstellt

Versionen: 1.13.x

Symptome:

Nachdem Sie Monitoring so konfiguriert haben, dass Benachrichtigungen mit den Toil-Aufgaben MON-T0016, MON-T1016 und MON-T0018 an ServiceNow gesendet werden, werden in ServiceNow mehrere doppelte Benachrichtigungen erstellt.

Das Problem hat die folgenden Merkmale:

Für einige Benachrichtigungen werden mehrere doppelte Vorfälle erstellt, auch nachdem die Toil-Aufgabe MON-T0018 angewendet wurde.

Problemumgehung: Führen Sie die Toil-Aufgabe MON-T0019 unmittelbar nach den Toil-Aufgaben MON-T0016, MON-T1016 und MON-T0018 aus.

Vertex AI-Messwerte können nicht angezeigt werden

Versionen: 1.13.1

Symptome: Der dvs-frontend-server-Pod gibt keine Messwerte aus.

Problemumgehung: Version 1.13.1 unterstützt keine verschlüsselten Messwerte für Vertex AI-Dienste. Wenn der Vertex AI-Dienst nicht innerhalb einer Stunde aktiviert wird, starten Sie den mon-admin-Controller-Pod neu.

Abgleichsfehler in `mon-cortex`

Versionen: 1.13.1, 1.13.9

Symptome: Der Pod mon-cortex weist einen Abgleichsfehler auf. Rufen Sie den Status des mon-cortex-Pods ab:

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

Die Ausgabe könnte so aussehen:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Möglicherweise wird eine Meldung wie diese protokolliert:

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

Problemumgehung:

Prüfen Sie, welcher Cortex-Pod eine solche Meldung ausgibt:

Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

Löschen Sie den PVC, der mit diesem Pod verknüpft ist, und starten Sie ihn neu.

Der `metrics-server-exporter`-Pod im Systemcluster befindet sich in einer Absturzschleife.

Versionen: 1.13.1

Symptome:Der metrics-server-exporter-Pod im Systemcluster befindet sich in einer Crash-Schleife mit OOMKilled, erreicht aber anscheinend nicht sein Limit. Fehlerdiagnose:

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

Die Ausgabe könnte so aussehen:

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

Problemumgehung:Reduzieren Sie die Menge der Daten, die am Messwerte-Endpunkt bereitgestellt werden, indem Sie den Pod löschen und neu starten lassen. Die alte time-series im Arbeitsspeicher wird dadurch gelöscht, wodurch der benötigte Arbeitsspeicher reduziert wird.

`ObservabilityPipeline`-Abstimmungsfehlermeldungen ignorieren

Versionen: 1.13

Symptome:

Das ObservabilityPipeline-Objekt zeigt Reconciler error-Logs wie die folgenden im root-admin-controller-Pod an:

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

Problemumgehung:

Logs ignorieren, die alle folgenden Bedingungen erfüllen:

"controller":"observabilitypipeline"
"namespace":"infra-obs"
"name":"default"
"err" enthält failed to get system cluster client to install per project overrides: root admin cluster has no system cluster.

Wenn Sie ein Problem mit einer Benachrichtigung aufgrund von hohen Abstimmungsfehlern beheben, ignorieren Sie diese Logs, da es sich um falsch negative Ergebnisse handelt.

Die `mon-prober-backend-prometheus-config`-ConfigMap wird zurückgesetzt

Versionen: 1.13.0 und 1.13.1

Symptome:

Die Benachrichtigung MON-A0001 wird ausgelöst.

Die mon-prober-backend-prometheus-config-ConfigMap wird zurückgesetzt und enthält keine Probe-Jobs mehr, z. B.:

apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

Problemumgehung:

So können Sie das Problem beheben:

Legen Sie die folgenden Umgebungsvariablen fest:
- KUBECONFIG: Der Pfad zur kubeconfig-Datei im Cluster.
- TARGET_CLUSTER: Der Name des Clusters, in dem Sie das Problem beheben.

Pausieren Sie die Unterkomponente mon-prober in allen Clustern:

kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

Beispiel:

kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

Starten Sie den MON-Administratorcontroller in jedem Administratorcluster neu:
```
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
```
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.

Cortex Store Gateway-Komponente – OOMKilled-Crashloop

Versionen: 1.13.3

Symptome: Wenn beim Laden von Messwerten in Grafana Fehler auftreten oder Messwerte überhaupt nicht geladen werden, befindet sich der cortex-store-gateway-Pod möglicherweise in einer Crash-Schleife.

Zur Diagnose des cortex-store-gateway-Pods und zur Prüfung, ob er sich in einer Crash-Schleife befindet, sehen Sie sich seinen Status an:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

Ersetzen Sie SYSTEM_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Systemclusters.

Wenn der Pod in einer Crash-Schleife steckt, sieht die Ausgabe so aus:

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

Problemumgehung: Erhöhen Sie das cortex-store-gateway-Speicherlimit vorübergehend, indem Sie eine SubcomponentOverride verwenden. Weitere Informationen zur Implementierung eines SubComponentOverride finden Sie im MON-R2008-Runbook.

Das folgende Beispiel zeigt ein SubcomponentOverride-Objekt mit einem angegebenen Speicherlimit:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

Lassen Sie die Überschreibung bestehen, bis alle cortex-store-gateway-Pods den Status Ready haben, und prüfen Sie, ob die Unterkomponente mon-cortex nicht pausiert ist:

Prüfen Sie, ob die cortex-store-gateway-Pods den Status Ready haben:
```
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway
```
Die Ausgabe sieht so aus, wenn alle Pods den Status Ready haben:
```
NAME                   READY   AGE
cortex-store-gateway   3/3     70d
```
In der Spalte READY muss für alle Pods der Wert N/N angezeigt werden, damit sie bereit sind. Andernfalls werden Werte wie 1/3 oder 2/3 angezeigt.
Prüfen Sie, ob die Unterkomponente mon-cortex in einer bestimmten Organisation pausiert ist:
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused
```
Ersetzen Sie Folgendes:
- ORG_ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters der Organisation.
- SYSTEM_CLUSTER: Der Name des Systemclusters.
Wenn die Unterkomponente pausiert ist, wird in der Ausgabe die folgende Zeile angezeigt:
```
lcm.private.gdc.goog/paused: true
```
Andernfalls ist die Ausgabe leer.

Kube-Steuerungsebene – Pullbackoff für Proxy-Image in Nutzercluster

Versionen: 1.13.3

Symptome: Wenn Messwerte für kube-scheduler oder kube-controller-manager (z. B. die Messwerte scheduler_pending_pods und workqueue_depth) in Grafana nicht sichtbar sind, liegt möglicherweise ein Problem mit dem Zurückziehen des Images für den kube-control-plane-metrics-proxy-Pod vor.

So diagnostizieren Sie den kube-control-plane-metrics-proxy-Pod und prüfen, ob ein Problem mit dem Pull-Backoff des Images vorliegt:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Nutzerclusters.

Wenn beim Pod ein Problem mit dem Image-Pull-Backoff auftritt, sieht die Ausgabe so aus:

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

Problemumgehung: Gehen Sie so vor, um das Problem zu beheben:

Laden Sie das gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0-Image aus dem Harbor-Projekt gpc-system-container-images herunter. Eine Anleitung und die zum Herunterladen eines Images erforderlichen Berechtigungen finden Sie unter Image mit Docker herunterladen.
Übertragen Sie das gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0-Image per Push in das Harbor-Projekt library. Eine Anleitung und die zum Hochladen eines Images erforderlichen Berechtigungen finden Sie unter Image hochladen.

Das library-Projekt wird für Artefakte verwendet, die im Nutzercluster bereitgestellt werden sollen.

Durch ein Wachstum des WAL verwendet Prometheus viel Arbeitsspeicher

Versionen: 1.13.3

Symptome: Der VM-Knoten der Systemsteuerungsebene meldet die Ereignisse NodeHasInsufficientMemory und EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

Die Ausgabe könnte in etwa so aussehen:

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

Prometheus verwendet viel Arbeitsspeicher, da das WAL (Write-Ahead-Log) immer größer wird. Das wirkt sich auf den Arbeitsspeicher des Knotens aus. Das Wachstum des WAL kann darauf zurückzuführen sein, dass Cortex nicht bereitgestellt wurde. Dieses Problem kann also eine Folge des Ausfalls von Cortex sein. Die Prometheus-Instanz verliert für längere Zeit die Verbindung zu Cortex. Während dieser Zeit werden Daten im Arbeitsspeicher und auf dem persistenten Volume (PV) gepuffert. Wenn Prometheus beendet wird, werden beim Start alle Daten im WAL in den Arbeitsspeicher geladen.

Eine weitere mögliche Ursache sind Probleme mit der Netzwerkverbindung (Service Mesh, physische und obere Netzwerke).

Problemumgehung: Um diesen Zustand zu beheben, wird empfohlen, die Ursache zu beheben und Cortex wieder in einen fehlerfreien Zustand zu versetzen oder Probleme mit der Netzwerkverbindung zu beheben. Warten Sie dann, bis das WAL von Prometheus geleert wurde. Es gehen keine Daten verloren. Wenn Cortex jedoch nicht verfügbar war, ist der Knoten für den Zeitraum, den Cortex für die Wiederherstellung benötigt, nicht verfügbar.

Alternativ können Sie Prometheus STS auf null herunterskalieren und das PV löschen. Dadurch wird die Gesamtdauer, in der der Knoten nicht verfügbar ist, verkürzt, es kommt jedoch zu Datenverlust. Außerdem müssen Sie diese Aktion regelmäßig wiederholen, solange Cortex nicht verfügbar ist oder Probleme mit der Netzwerkverbindung auftreten. Solange ein Verbindungsproblem zwischen Prometheus und Cortex besteht, füllt sich das PV wieder.

So skalieren Sie Prometheus STS auf null und löschen das PV:

Skalieren Sie die Komponente „logmon-operator“ herunter:
```
kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0
```
Ersetzen Sie ORG_SYSTEM_KUBECONFIG durch den Pfad zur kubeconfig-Datei im Organisationssystemcluster.

Skalieren Sie die anthos-prometheus-k8s-Komponente herunter:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

Löschen Sie den Anspruch auf das nichtflüchtige Volume:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

Skalieren Sie logmon-operator wieder hoch:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

Warten Sie, bis anthos-prometheus-k8s bereit ist.

Bootstrap in mehreren Zonen

Fehlende Clusterrollen

Versionen: 1.13.1

Symptome:Es gibt keine spezifischen Rollen für das Bootstrapping von Multi-Zone, die in Erforderliche Rollen hinzufügen verwendet werden können.

Problemumgehung:Verwenden Sie die Clusterrolle cluster-admin, wie in der verlinkten Anleitung beschrieben. Dadurch erhält der Nutzer mehr als den minimal erforderlichen Zugriff, um die späteren Aufgaben auszuführen.

Inkompatible `Bootstrap`-Ressource

Versionen: 1.13.1

Symptome:Die in Schritt 3 von Bootstrap-Datei erstellen erstellte Bootstrap-Ressource ist nicht mit der Logik kompatibel, die sie verarbeitet.

Problemumgehung:Bearbeiten Sie die generierte YAML-Datei wie in Schritt 4 beschrieben.

Die `GlobalAPIZone`-Ressource wird nicht in der globalen API erstellt.

Versionen: 1.13.1

Symptome:Auf der Steuerungsebene wird keine GlobalAPIZone-Ressource für die Zone in der globalen API erstellt. Daher funktionieren Komponenten, die auf diese Ressource angewiesen sind, nicht richtig.

Problemumgehung:Erstellen Sie die Ressource wie unter GlobalAPIZone-Ressource erstellen beschrieben.

Netzwerk

Objektspeicherknoten – Grid-Netzwerk ausgefallen

Versionen: 1.13.1, 1.13.3, 1.13.4

Symptome:

Während der Bootstrapping-Phase des Objektspeichers wird das Grid-Netzwerk in der Benutzeroberfläche des OBJ Admin-Knoteninstallationsprogramms als inaktiv angezeigt.
In „cables.csv“ und „Cell CR“ wird gezeigt, dass der MPN-Wert in „cables.csv“ QSFP-100G-CU2.5M für Verbindungen zwischen „objsadmin“-Knoten des Objektspeichers und dem TOR-Switch ist.

Erläuterung In Version 1.13 wird das Feld „MPN“ in „cables.csv“ verwendet, um die Geschwindigkeit des Tor-Switches zu bestimmen. Wenn die Geschwindigkeit für diese Ports nicht festgelegt ist, schlägt die Verbindung des Tor-Switches zum objsadmin-Knoten fehl. In der Liste, die zum Zuordnen der Herstellernummer zur Geschwindigkeit verwendet wurde, wurde ein Wert, der vom Systemintegrator angegeben wurde, nicht berücksichtigt. Dadurch konnte der Objekt-Speicher nicht gestartet werden. In den meisten 1.13-Einrichtungen wurde der Anbieter verwendet: QSFP-100G-CU2.5M.

Problemumgehung:

Verwenden Sie kubectl get -A cell -oyaml im Root-Administratorcluster, um die Verbindung zur Appliance für die Objektspeicherung und zum TOR-Switch zu finden.
Ändere alle Vorkommen von „mpn“ in „QSFP-100G-CU3M“ für objsadm –> torsw connect.

Hier ein Beispiel:

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

Knoten nicht erreichbar

Versionen: 1.13.1, 1.13.3, 1.13.4

Symptome:

Während der Netzwerk-Bootstrapping-Phase sind einige Switches nicht erreichbar.
Während der DHCP-Installationsphase sind einige Server nicht über ihre iLO-IP-Adresse erreichbar.

Problemumgehung:

Laden Sie die betroffenen Verwaltungsschalter neu. Weitere Informationen finden Sie im PNET-R0018-Runbook.

`PodCIDR` ist Knoten nicht zugewiesen, obwohl `ClusterCIDRConfig` erstellt wurde

Versionen: 1.13.1

Symptome: Ein ClusterCIDRConfig ist ein erforderliches Objekt, um PodCIDRs zuzuweisen. Obwohl die ClusterCIDRConfig erstellt wurde, wurde die PodCIDRs nicht zugewiesen. Dieses Problem tritt auf, wenn ein 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:

kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

Die Ausgabe könnte so aussehen:

apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

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:

kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

Die Ausgabereignisse könnten so aussehen:

  Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

Problemumgehung:

Starten Sie die ipam-controller-manager-Pods neu:

kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

Wenn die ipam-controller-manager-Pods ausgeführt werden, prüfen Sie, ob die podCIDR den Knoten zugewiesen ist:

kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

Die Ausgabe könnte so aussehen:

podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

NTP-Drift

Versionen: 1.13.1

Symptome: Ein VM-Knoten hat nach dem Ruhezustand oder nach einer Weile der Ausführung eine abweichende oder ungenaue Zeit.

Problemumgehung:

Stellen Sie eine SSH-Verbindung zum VM-Knoten her und bearbeiten Sie die Datei /etc/chrony.conf.
Ersetzen Sie die Zeile makestep 1.0 3 durch makestep 1.0 -1.
Starten Sie den „chronyd“-Dienst neu:
```
systemctl restart chronyd
```

Sie müssen diese Änderung nur einmal für jede VM vornehmen. Die Änderung wird nicht überschrieben.

Um die Zeit schnell zu korrigieren, stellen Sie eine SSH-Verbindung zum VM-Knoten her und führen Sie chronyc -a makestep aus.

SyncServer-Audit-Logs werden nicht geparst

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Symptome: Audit-Logs vom SyncServer werden von der log-remote-logger nicht richtig geparst. Einige Audit-Logs sind in Grafana nicht verfügbar und im log-remote-logger-Pod des Root-Administrators werden möglicherweise Fehlermeldungen wie die folgenden angezeigt:

Failed to fetch syncserver audit logs for syncserver-...

Problemumgehung: Die Audit-Logs sind weiterhin auf dem SyncServer verfügbar. Folgen Sie NTP-P0002, um auf die SyncServer-Benutzeroberfläche zuzugreifen und die Logs unter Logs > Events aufzurufen.

Bild für den Switch konnte nicht extrahiert werden

Versionen: 1.13.3

Symptome: Möglicherweise wird eine Meldung wie diese für das SwitchImageHostRequest-Objekt angezeigt, wenn Sie eine Switch-RMA durchführen oder den Root-Administratorcluster booten:

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

Wenn Sie Zugriff auf kubectl haben, können Sie damit prüfen, ob dieses Problem vorliegt:

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

Die Ausgabe könnte in etwa so aussehen:

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

Problemumgehung:

Erstellen Sie manuell eine SwitchImageHostRequest mit dem richtigen Image-Tag:

Melden Sie sich beim Bootstrapper-Server an.
So finden Sie die richtige Version des Switch-Bildes:gdcloud
```
release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch
```
Die Ausgabe könnte in etwa so aussehen:
```
│   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385
```
Aus dieser Ausgabe geht hervor, dass die richtige Version des Schalters 1.13.3-gdch.5385 ist.

Bearbeiten Sie das SwitchImageHostRequest-Objekt, in dem der Fehler gemeldet wird:

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

Bearbeiten oder ersetzen Sie die Felder name, fromVersion und toVersion, damit sie der erwarteten Version des Schalterbilds entsprechen. In diesem Fall lautet sie 1.13.3-gdch.5385. Die folgende diff-Ausgabe veranschaulicht die Änderungen, die am SwitchImageHostRequest-Objekt vorgenommen werden müssen.
```
kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385
```

Kommunikation mit StatefulSet-Pod schlägt fehl

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9, 1.13.10

Symptome: Konnektivitätsprobleme oder Unterbrechungen, da das Löschen von Cilium Endpoint-Objekten (CEP) nach Neustarts von StatefulSet-Pods nicht korrekt behandelt wird. Dies kann dazu führen, dass durch die Identität des nicht verwalteten Endpunkts Netzwerkrichtlinien fälschlicherweise legitimen Traffic verwerfen. Betroffene Pods können überprüft werden, indem Sie nach dem Fehlen des entsprechenden CEP-Objekts suchen:

kubectl get cep -A | grep [*POD_IP*]

Problemumgehung: Starten Sie die betroffenen StatefulSet-Pods neu, um ihre UID zu aktualisieren und die zugehörigen Metadaten zu aktualisieren:

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

Verbindungsprobleme mit DBS-Instanzen

Versionen: 1.13.0, 1.13.1

Symptome: Auf DBS-Instanzen (Database Services) kann nicht zugegriffen werden. Datenbankclients zeigen Zeitüberschreitungen bei der Verbindung an.

Dieses Problem kann durch eine andere Systemkomponente, die auf DBS basiert, erkannt werden. Die Abrechnung kann beispielsweise Fehlermeldungen wie die folgenden zurückgeben:

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

Problemumgehung: Der Fehler wird durch eine Netzwerkkomponente verursacht, die nicht in der Lage ist, die Planung im Dienstcluster der Organisation vorzunehmen.

Legen Sie die folgenden Umgebungsvariablen fest:
```
export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME
```
Ersetzen Sie Folgendes:
- KUBECONFIG_PATH: Der Pfad zur kubeconfig-Datei des Administratorclusters der Organisation.
- ORG_NAME: Der Name Ihrer Organisation, z. B. org-1.

Aktualisieren Sie die Konfiguration der Netzwerkkomponente, damit sie geplant werden kann:

kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

Die Netzwerkverbindung wird nach einigen Minuten wiederhergestellt.

Cluster-Mesh ist nicht mit Zoneninformationen konfiguriert

Versionen: 1.13.5

Symptome: Eine VM kann keine Verbindung zu einem Datenbankcluster im selben Projekt herstellen. Die Verbindung zum internen Load-Balancer ist beeinträchtigt. Dieses Problem wird durch eine Clustermesh verursacht, die keine Dienstobjekte zwischen Clustern austauschen kann, da in der Konfiguration des Clusternamens Zoneninformationen fehlen.

Problemumgehung: Führen Sie in Umgebungen, die als Multizone-Umgebungen gebootstrappt wurden, die folgenden manuellen Schritte zur Problemumgehung aus, damit der interne Load Balancer funktioniert:

Rufen Sie im Administratorcluster der Organisation den Zonennamen ab:

ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

Die Ausgabe könnte so aussehen:

zone1

Rufen Sie im Administratorcluster der Organisation die Zonen-Website-ID ab:

SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

Die Ausgabe könnte so aussehen:

Alle Cluster auflisten:

kubectl get clusters -A

Die Ausgabe könnte so aussehen:

NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

Erstellen Sie für jeden Cluster die CILIUM_CLUSTERNAME:

CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

Die Ausgabe könnte so aussehen:

org-1-system-zone1

Legen Sie für jeden Cluster die anderen Parameter so fest: Das folgende Beispiel für org-1-system:
```
CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592
```

Erstellen Sie für jeden Cluster ein AddOnConfiguration-Objekt und speichern Sie es in einer addonconfig.yaml-Datei. Erstellen Sie diese Datei für alle vorhandenen Cluster und alle neuen Cluster, die Sie in Zukunft erstellen:

Legen Sie auf dieser Seite die folgenden Variablen fest, um das folgende Codebeispiel zu aktualisieren:

CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

Wenden Sie addonconfig.yaml auf den Administratorcluster der Organisation an:
```
kubectl apply -f addonconfig.yaml
```
Prüfen Sie in System-, Dienst- und Nutzerclustern, ob cluster-name im cilium-config des Clusters aktualisiert wurde. Es kann einige Zeit dauern, bis die Aktualisierung abgeschlossen ist. Dieser Schritt ist jedoch erforderlich, bevor Sie die Bereitstellung von clustermesh-apiserver neu starten können.
```
kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo
```
Starten Sie in System-, Dienst- und Nutzerclustern die clustermesh-apiserver-Bereitstellung neu:
```
kubectl rollout restart deployment -n kube-system clustermesh-apiserver
```

Falsche EVPN-IP-Adressen werden generiert

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7

Symptome: Die vom Hardware Asset Management System (HAMS) generierten IP-Adressen für das Peering von EVPN-Interconnect-Sitzungen für mehrere Zonen (MZ) enden nicht mit .65 oder .66. Das ist falsch und verhindert, dass die MZ-EVPN-BGP-Sitzungen eingerichtet werden.

Problemumgehung:

So beheben Sie das Problem manuell:

Alle InterconnectSession-Ressourcen auflisten:

kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

Prüfen Sie die generierten EVPN-Multizone-InterconnectSession-Ressourcen mit dem interconnectType-Wert ZonePeering und dem addressFamily-Wert EVPN:

apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

Wenden Sie für jede der InterconnectSession-Ressourcen, die diesen Parametern entsprechen, die folgende Korrektur an:
1. Prüfen Sie den Namen der benutzerdefinierten Ressource für die Interconnect-Sitzung.
2. Wenn der Name mit einer ungeraden Zahl endet, aktualisieren Sie den letzten Teil der Peer-IP-Adresse mit dem Befehl im nächsten Schritt auf 65.
3. Wenn der Name mit einer geraden Zahl endet, aktualisieren Sie den letzten Teil der Peer-IP-Adresse mit dem Befehl im nächsten Schritt auf 66.

Ändern Sie die InterconnectSession-Ressource mit der falschen Peer-IP-Adresse:

kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

Wenden Sie diese Korrektur auf alle InterconnectSession-Ressourcen an, die den Fehler verursachen.

Im oberen Dashboard für die Netzwerksteuerungsebene werden keine Daten angezeigt

Versionen: 1.13.7

Symptome: Prometheus-Abfragen in TestUpperNetworkingMetrics schlagen aufgrund fehlender Messwerte im org-1-system-Cluster fehl. In den Clustermesh-Feldern im Dashboard der oberen Steuerungsebene für das Netzwerk für IO-Organisationsadministratoren werden keine Daten angezeigt. Das Problem ist auf eine Abweichung im source_cluster-Label zwischen Cilium und dem Überwachungssystem zurückzuführen.

Problemumgehung: Entfernen Sie den source_cluster-Filter aus dem UNET-Dashboard der Steuerungsebene, um Daten anzeigen zu lassen.

Irreführende Fehler bei der Netzwerkinstallation

Versionen: 1.13.1

Symptome: Während der Netzwerkinstallation werden einige Warnmeldungen zur Verkabelung angezeigt. Beispiel:

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

Diese Fehlermeldungen können ignoriert werden.

Durch das Erstellen eines PNP für ausgehenden Traffic, der alles zulässt, wird unerwarteter Traffic abgelehnt.

Versionen:

Alle Versionen von Google Distributed Cloud (GDC) Air Gapped können betroffen sein.

Symptome: Die Netzwerkrichtlinie für das Projekt allow-all-egress (Project Network Policy, PNP) lässt Traffic zu Endpunkten innerhalb des Projekts und zu externen Endpunkten außerhalb des Clusters zu, aber nicht zu Systemendpunkten. Dieses Problem kann dazu führen, dass der Zugriff auf System- und Erstanbieterdienste wie DNS-Auflösung und Objektspeicher blockiert wird.

Die allow-all-egress-PNP könnte so aussehen:

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

Problemumgehung: Löschen Sie die allow-all-egress PNP. Wenn der Schutz vor unbefugter Datenweitergabe deaktiviert ist, ist Traffic zu Projekt- und externen Endpunkten außerhalb des Clusters und der Systemendpunkte standardmäßig zulässig.

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

Objektspeicher

Speicherorganisation kann nicht gelöscht werden

Versionen: 1.13.1

Symptome: Das Löschen einer Organisation kann aufgrund eines Problems, das das Löschen des SVM verhindert, fehlschlagen. Möglicherweise wird eine Warnung wie diese angezeigt:

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

Einige Warnungen zum Upgrade des Objektspeichers können ignoriert werden

Versionen: 1.13.3

Symptome: Beim Upgrade des Objektspeichers wird möglicherweise eine Warnung wie diese angezeigt:

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

Problemumgehung:

Prüfen Sie, ob für jeden Knoten entsprechende SSH-Anmeldedaten in einem Secret gespeichert sind.

Administrator-Knoten prüfen:

kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

Speicherknoten prüfen:

kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

Die erfolgreiche Ausgabe für Speicherknoten sieht so aus:

NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

Wenn ein Secret nicht gefunden wird, sieht der Fehler so aus:

Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

Wenn der Befehl keine Fehler zurückgibt, können Sie die von den Abgleichern gemeldeten Fehler ignorieren.

`ObjectStorageStorageNodeReconciler` Berichte `maintenance.gdu.gdu_server_locked`

Versionen: 1.13.3

Symptome: Hier werden die Details des objectstoragestoragenode angezeigt:

kubectl describe objectstoragestoragenode zv-aa-objs02

Die Ausgabe könnte in etwa so aussehen:

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

Problemumgehung: Dieses Problem kann ignoriert werden. Der GDU-Dienst wird möglicherweise vorübergehend gesperrt, wenn zu viele Anfragen eingehen. Die Sperrung wird jedoch nach einigen Minuten aufgehoben.

Postflight-Prüfung für das Upgrade von 1.12.x auf 1.13.x schlägt fehl

Versionen: 1.13.x

Symptom: Die ObjectStorageUpgrade CR schlägt mit dem Fehler

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Pods gpc-system/upgrade-managed-check-objectstorageupgrade schlagen mit Fehler fehl

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

Ursache: Das Upgrade der Object Storage Operational Component von 1.12.x auf 1.13.x schlägt fehl, wenn der Bootstrapping-KIND-Cluster nicht deaktiviert oder gelöscht wurde. Auch wenn das Upgrade erfolgreich ist, können allgemeine Objektspeicherdienste wie das Erstellen neuer Buckets oder S3-Anmeldedaten über Kubernetes RBAC aufgrund von TLS-Zertifikatsvalidierungsfehlern fehlschlagen. Dies liegt daran, dass ein bestimmter Object Storage-Pod im KIND-Cluster fortlaufend versucht, das TLS-Serverzertifikat des StorageGRID-Verwaltungsendpunkts zu installieren. Dieses war in Version 1.12.x gültig, wird in Version 1.13.x jedoch möglicherweise nicht erkannt. Während des Upgrades wird in StorageGRID ein neues, überprüfbares TLS-Serverzertifikat installiert. Der KIND-Cluster-Pod ersetzt es jedoch durch das alte, ungültige Zertifikat, was zum TLS-Zertifikatsfehler führt.

Problemumgehung: Folgende Anforderungen müssen erfüllt sein:

Das Objektspeicher-Upgrade von 1.12.x auf 1.13.x
Der Bootstrapping-Cluster (der KIND-Cluster) ist noch vorhanden.

Gehen Sie so vor:

Rufen Sie ein kubeconfig ab, das die Berechtigung zum Ansehen und Ändern der ObjectStorageSite-Ressource im Bootstrapping-Cluster (dem KIND-Cluster) hat.
Legen Sie einen Alias für kubectl fest, der eine Verbindung zum Bootstrapping-Cluster (dem KIND-Cluster) herstellt:
```
alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>
```
Rufen Sie die benutzerdefinierte Ressourceninstanz ObjectStorageSite aus dem Bootstrap-Cluster ab. Es sollte eine ObjectStorageSite-Ressourceninstanz geben:
```
SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')
```

Fügen Sie der ObjectStorageSite-Ressourceninstanz eine Annotation für die Pausierung des Objektspeichers hinzu:

kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

Prüfen Sie, ob der ObjectStorageSite-Instanz die Annotation für das Pausieren des Objektspeichers hinzugefügt wurde:
```
kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq
```
Rufen Sie ein kubeconfig ab, das Lesezugriff und die Berechtigung zum Patchen des Status für ObjectStorageCluster-Ressourcen im Administratorcluster auf Stammebene hat.

Legen Sie einen Alias für die kubectl-Verbindung zum Administratorcluster auf Stammebene fest:

alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

Prüfen Sie, ob im Root-Admin-Cluster eine ObjectStorageCluster-Ressourceninstanz vorhanden ist:
```
kubectlrootadmin get ObjectStorageCluster
```
Wenn keine ObjectStorageCluster-Ressourceninstanz vorhanden ist, ist der Workaround abgeschlossen. Möglicherweise müssen Sie das Object Storage-Upgrade noch einmal durchführen.

Rufen Sie die Verwaltungs-Endpunkt-URL aus dem Status der ObjectStorageSite-Ressource im Bootstrap-Cluster ab:

MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

Prüfen Sie, ob die Umgebungsvariable $MGMT_ENDPOINT festgelegt wurde. Der Endpunkt sollte mit https:// beginnen:
```
echo ${MGMT_ENDPOINT:?}
```
Führen Sie die verbleibenden Schritte nur aus, wenn genau eine ObjectStorageCluster-Ressourceninstanz im Administrator-Stammcluster vorhanden ist. Führen Sie andernfalls die Prozedur für das Object Storage-Upgrade noch einmal aus:
```
kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"
```

Starten Sie den Pod „gpc-system/obj-infra-cluster-cm“ neu:

kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

Prüfen Sie, ob der Verwaltungs-Endpunkt dem Status der ObjectStorageCluster-Ressource hinzugefügt wurde:
```
kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq
```
Starten Sie die Postflight-Prüfung neu, indem Sie den Kubernetes-Job für die Postflight-Prüfung gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix> löschen. Der Job wird bald neu erstellt.

Knoten im Datennetzwerk nicht erreichbar

Dies ist ein seltenes Problem, das auftreten kann, wenn der anetd-Pod in einer Absturzschleife hängen bleibt.

Eine Kernelressource, die für die Knotenkonnektivität unerlässlich ist, kann in einem beschädigten Zustand hängen bleiben.

In diesem Leitfaden werden die Symptome dieses Problems sowie die Schritte beschrieben, die zur Behebung des Problems unternommen werden können.

Versionen:

Alle Versionen von Google Distributed Cloud (GDC) Air Gapped können betroffen sein.

Symptome:

Wenn dieses Problem auftritt, können die folgenden Symptome auftreten:

Knoten bleiben im Status NotReady
Beim Beschreiben des Knotens wird die Meldung kubelet:kubelet was found unhealthy; repair flag : true angezeigt.
SSH-Zugriff auf den Knoten ist im Data Network nicht möglich

Workaround:

Führen Sie die folgenden Schritte aus, um jeden fehlerhaften Knoten zu reparieren:

Rufen Sie die Management-IP-Adresse des betroffenen Knotens ab:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'

SSH-Zugriff auf den betroffenen Knoten erhalten
Stellen Sie über die Management-IP-Adresse des Knotens eine SSH-Verbindung zum Knoten her.
Führen Sie auf dem Knoten den folgenden Befehl aus und schließen Sie dann die SSH-Verbindung:
```
tc filter del dev bond0 egress
```

Starten Sie das DaemonSet anetd für den Cluster mit dem betroffenen Knoten neu:

kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system

Betriebssystem

Pods bleiben im Status `init`

Versionen: 1.13.1

Symptome: Der Knoten wird als bereit gemeldet, aber der SSH-Zugriff auf den Knoten ist langsam und top -n 1 zeigt mehr als 100 Zombieprozesse an.

Problemumgehung:

Folgen Sie der Anleitung unter OS-P0001, um den Server zu entleeren. Das Entleeren kann mehr als 20 Minuten dauern. Wenn das Entleeren nach einer Stunde nicht funktioniert, fahre mit dem nächsten Schritt fort.
Starten Sie den Server neu, indem Sie eine SSH-Verbindung zum Server herstellen und den folgenden Befehl ausführen:
```
systemctl reboot
```
Möglicherweise ist ein zweiter Neustart erforderlich, um den Server vollständig wiederherzustellen.
Prüfen Sie, ob der SSH-Zugriff nicht mehr langsam ist und die Anzahl der Zombieprozesse deutlich geringer ist, vorzugsweise unter 30.
Sie können den Server entleeren, indem Sie maintenance auf dem Server auf false setzen.

`bm-system-machine-preflight-check` Ansible-Job für einen Bare-Metal- oder VM-Knoten schlägt fehl

Versionen: 1.13.1

Symptome:Das Kernelmodul nf_tables wird nach dem Neustart nicht geladen. Daher schlagen Cluster-Ansible-Jobs mit dem Fehler Either ip_tables or nf_tables kernel module must be loaded fehl. Dieses Problem tritt auf, wenn der Bare-Metal- oder VM-Knoten neu gestartet wird, bevor er vollständig bereitgestellt wurde. Der Ansible-Job gibt möglicherweise einen Fehler wie diesen aus:

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

Workaround:

Stellen Sie eine SSH-Verbindung zum Knoten her und führen Sie den folgenden Befehl aus:

modprobe nf_tables

VM mit keinem Speicherplatz mehr auf dem Gerät

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Symptome:Wenn das Logverzeichnis „/var/log“ voll ist, bleibt Node möglicherweise im Status NotReady hängen und Pods können aufgrund des Fehlers no space left on device nicht gestartet werden. Führen Sie dazu den folgenden Befehl auf dem Knoten aus und prüfen Sie, ob die Auslastung bei etwa 100 % liegt.

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

Problemumgehung:

Melden Sie sich auf dem Knoten an, auf dem das Problem auftritt, und bereinigen Sie alte Logarchive für „/var/log/messages“.
```
find /var/log -name "messages*" -mtime +4 -delete
```
Außerdem wird empfohlen, den folgenden Workaround weiterhin anzuwenden, um das Problem zu vermeiden. Die Problemumgehung besteht darin, eine AnsiblePlaybook zu erstellen und die Änderung über eine benutzerdefinierte OSPolicy-CR anzuwenden, die für die sichere Konfiguration des Zielbetriebssystems (BM- und VM-Maschinen) verantwortlich ist. Weitere Informationen finden Sie im Prozess OS-P0005.

Legen Sie die folgenden Umgebungsvariablen fest:

export KUBECONFIG=<the path to the kubeconfig file>

Erstellen Sie ein Ansible-Playbook für die Problemumgehung:

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

Identifizieren Sie die Zielinventare, auf die die Änderung angewendet werden muss. Das Ziel kann ein einzelnes InventoryMachine oder ein NodePool sein. Siehe Prozess OS-P0005 (2. Weitere Informationen finden Sie unter „Zielinventar für die Laufzeitkonfigurationen ermitteln“.

Im folgenden OSPolicy-Beispiel sind zwei Zielinventare unter spec.inventory enthalten. Sie können bei Bedarf weitere Inventare hinzufügen.

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

Validierung

Verwenden Sie den Prozess OS-P0005 (Überprüfung), um den Status der Richtlinienausführung zu verfolgen.

Pods bleiben im Status `ContainerCreating`

Versionen: 1.13.3, 1.13.5, 1.13.6

Symptome: Ein Knoten wird als fehlerfrei angezeigt, hat aber viele Pods, die im Status ContainerCreating hängen bleiben, und Sie können keine SSH-Verbindung zum Server herstellen.

Problemumgehung: Schalten Sie den Server aus und wieder ein und prüfen Sie, ob Sie eine SSH-Verbindung zum Knoten herstellen können, wenn er wieder hochgefahren ist.

SSH-Verbindung zum bereitgestellten Knoten nicht möglich

Versionen: 1.13.5

Symptome: Ein Knoten wird bereitgestellt, aber für SSH tritt sowohl bei den Verwaltungs- als auch bei den Daten-IPs ein Zeitüberschreitungsfehler auf.

Problemumgehung: Starten Sie den Knoten über iLO neu. Stellen Sie nach dem Booten eine SSH-Verbindung her und deaktivieren Sie clamonacc mit systemctl stop clamonacc; systemctl disable clamonacc.

Operations Suite Infrastructure (OI)

SSA für Hardware 3.0 nicht erforderlich

Die Konfiguration des RAID-Adapters unterscheidet sich für Hardware 3.0. Hardware 3.0-OIC-Server verwenden ein selbstverschlüsselndes Laufwerk. Das Starten der Smart Storage Administration (SSA) ist daher nicht mehr erforderlich. Es sind zusätzliche Schritte erforderlich, um die Datenträgerkennungen für jeden Server zu ermitteln. Siehe OI-Server-Bootstrap.

Perimetersicherheit

Organisationssystemcluster bleibt während des Organisations-Bootstraps hängen

Versionen: 1.13.1

Symptome:Während des Bootstrap-Vorgangs der Organisation kann der Organisationssystemcluster hängen bleiben. Die edr-sidecar-injector-Pods haben den Status „Ausstehend“. Wenn Sie versuchen, diese Pods zu löschen, wird möglicherweise eine Fehlermeldung wie diese angezeigt:

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

Gleichzeitig können bei einigen anderen ausstehenden Pods Fehlermeldungen wie diese angezeigt werden:

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

Das System muss manuell entsperrt werden.

Problemumgehung:

Duplizieren Sie die MutatingWebhookConfiguration-CR edr-sidecar-injector-webhook-cfg im Systemcluster.
Duplizieren Sie die ValidatingWebhookConfiguration-CR gatekeeper-validating-webhook-configuration im Systemcluster.
Löschen Sie sowohl die CR edr-sidecar-injector-webhook-cfg als auch die CR gatekeeper-validating-webhook-configuration aus dem Systemcluster.
Warten Sie, bis die edr-sidecar-injector-Pods und die gatekeeper-controller-manager wieder aktiv sind.
Stellen Sie die Webhook-CR mit dem Befehl kubectl apply wieder her.

PANW-Firewall-Adressgruppen werden nicht mit CIDR-Anspruchsänderungen aktualisiert

Versionen: 1.13.1

Symptome:Während des Bootstrapping wird der OCIT cidr-claim mit dem richtigen Wert aktualisiert, die Firewall AddressGroups jedoch nicht. Ein Paar von AddressGroups, insbesondere vsys1-root-ocit-network-cidr-group und ocvsys1-root-ocit-network-cidr-group, verwendet Netzwerkblöcke, die sich nicht mit dem überschneiden, was tatsächlich in OIR verwendet wird. OIR kann keine GDC-Zoneneinträge auflösen und Anfragen laufen ohne Antwort ab.

Problemumgehung: Nach den cidr-claim-Änderungen müssen Sie dafür sorgen, dass AddressGroup mit den neuesten cidr-claim aktualisiert wird. Starten Sie dazu das fw-core-backend-controller-Deployment im fw-system-Namespace im Root-Admin-Cluster neu.

Physische Server

Server-Bootstrap schlägt aufgrund von POST-Problemen auf dem HPE-Server fehl

Versionen: 1.13.1

Symptome:Das Server-Bootstrapping schlägt fehl, wenn ein Server den POST-Bootvorgang nicht durchläuft. Wenn Sie sich in der iLO anmelden und die Console des Servers prüfen, wird der folgende Fehler angezeigt:

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

Workaround:

Klicken Sie in iLO auf die Ein/Aus-Taste und wählen Sie Cold Boot aus.

Server bleiben im Bereitstellungsstatus

Versionen: 1.13.1, 1.13.3, 1.13.5

Symptome:Die Server bleiben während des Server-Bootstrapping in einem Bereitstellungsstatus hängen. Prüfen Sie den Status der Server:

k get servers -A | grep -v availabl

Die Ausgabe könnte so aussehen:

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

Problemumgehung:

Starten Sie DHCP manuell mit einer Konfiguration, die aus dem KIND-Cluster heruntergeladen wurde. In diesem Beispiel ist /tmp/dhcp.conf die DHCP-Konfiguration des KIND-Clusters:
```
docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION
```
Ersetzen Sie VERSION durch die Releaseversion, wie in der Anleitung zum Upgrade unter Manuelles Upgrade der Dateikomponente für Root- und Organisationsadministratorcluster beschrieben, z. B. 1.13.1-gdch.525.
Prüfen Sie die BIOS-Konfiguration auf dem Server und vergewissern Sie sich, dass NetworkBoot nicht für Datenebene-NICs (mit dem Muster Slot{i}Nic{i}) aktiviert ist.
BIOS über den API-Aufruf prüfen:
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword
```
Dabei sind $bmcUser und $bmcPassword die Passwörter für die ILOs, die in der Datei oder dem Verzeichnis cellcfg in einem Secret mit dem Namen bmc-credentials-<server-name> zu finden sind, z. B. bmc-credentials-ai-aa-bm01. Prüfen Sie, ob in der Ausgabe dieses Befehls Slot1Nic1: Disabled angezeigt wird.
Wenn eine dieser Slot{i}Nic{i} NetworkBoot hat, deaktivieren Sie sie mit der BIOS-Einstellungen-API.
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'
```
Ersetzen Sie Slot{i}Nic{i} durch den Namen des Slots, der das Problem in der Nutzlast verursacht.
Starten Sie den Server neu.

DL380a-Server kann nicht bereitgestellt werden

Versionen: 1.13.3, 1.13.4, 1.13.5

Symptome:Die Serverbereitstellung schlägt beim Verschlüsselungsjob für das HPE DL380a-Modell fehl. Der Status des Server-CR ist während des Server-Bootstrapping auf available festgelegt:

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

Workaround:

Folgen Sie IAM-R0004, um die KUBECONFIG für die root-admin-cluster zu generieren.
Folge PLATAUTH-G0001, um den SSH-Schlüssel root-id_rsa für CLUSTER_NS=root zu generieren.

Pausieren Sie den Server, indem Sie der benutzerdefinierten Serverressource die Annotation server.system.private.gdc.goog/paused hinzufügen:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

Melden Sie sich über die Verwaltungs-IP beim Server an:

export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

Verschlüsselung manuell aktivieren:

/opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

Die Ausgabe der Befehle sollte in etwa so aussehen:

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

Wenn der letzte Befehl nicht erfolgreich ist oder Fehler wie „Invalid BIOS EKM status“ (Ungültiger BIOS-EKM-Status) angezeigt werden, starten Sie den Server und iLO neu und wiederholen Sie diesen Schritt.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

Wenn der letzte Befehl erfolgreich war, starten Sie den Server wie angewiesen neu.

Logisches Laufwerk manuell erstellen:

Nachdem der Server neu gestartet wurde, melden Sie sich noch einmal über die Verwaltungs-IP auf dem Server an und listen Sie alle verfügbaren Laufwerke auf:

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

Die Ausgabe des letzten Befehls könnte so aussehen:

{
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

Sie sollten die beiden EID:Slt-IDs mit Size gleich 1.60 TB speichern. In diesem Fall:

252:1,252:2

Erstellen Sie dann ein logisches Laufwerk mit EID:Slt-IDs:

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

Die Ausgabe des letzten Befehls sieht in etwa so aus:

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

Status der Speicherverschlüsselung im Server-CR simulieren.

Bearbeiten Sie den Status der Server-CR:

kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

So fügen Sie den Status DiskEncryptionEnabled hinzu oder ändern ihn in „true“:

  - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

Löschen Sie den Serververschlüsselungsjob, falls vorhanden:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

Heben Sie die Pausierung des Servers auf, damit die Bereitstellung fortgesetzt wird:

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

Sicheres Löschen schlägt ohne Lizenz fehl

Versionen: 1.13.5

Symptome: Wenn ein Server während der Serverinstallation hängen bleibt, sehen Sie möglicherweise einen Status auf dem Server-CR wie diesen:

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

Problemumgehung: Folgen Sie der Anleitung im SERV-R0014-Runbook.

Plattformsicherheit

BYO-SubCA-Abstimmungsfunktion prüft nicht, ob Zertifikate einen übereinstimmenden öffentlichen Schlüssel haben

Versionen: 1.13.1

Symptome:Wenn im PKI BYO SubCA-Modus eine neue Zertifikatsignierungsanfrage (Certificate Signing Request, CSR) generiert wird, während ein zuvor signiertes Zertifikat in die SubCA hochgeladen wird, prüft der Abgleichsdienst nicht, ob die neue CSR mit dem alten signierten Zertifikat übereinstimmt, und kennzeichnet die benutzerdefinierte Ressource (Custom Resource, CR) cert-manager CertificateRequest als Ready. Dies geschieht bei der Erneuerung oder manuellen Rotation von untergeordneten CA-Zertifikaten. Der cert-manager-Controller versucht, den Status des Certificate-CR zu aktualisieren, was die folgende Fehlermeldung auslöst:

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

Workaround:

Folgen Sie der Anleitung zum Hochladen eines neuen signierten BYO-Sub-CA-Zertifikats für die neue CSR.

cert-manager-Problem führt zu fehlgeschlagener Ausstellung von PKI BYO mit ACME

Versionen: 1.13.1

Symptome:Der Fehler tritt bei der Erstausstellung oder Verlängerung von BYO-Zertifikaten mit ACME (Automated Certificate Management Environment) auf. Wenn Sie den Befehl zum Prüfen des Zertifikatstatus ausführen, sehen Sie, dass das Zertifikat not ready ist:

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

Die Ausgabe sieht dann ungefähr so aus:

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

Workaround:

Starten Sie die Bereitstellung von cert-manager im Administratorcluster der Organisation neu:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

Resource manager

Projektstatus ist in der GDC Console nicht verfügbar

Versionen: 1.13.1+

Symptome:In der GDC Console wird der Status eines Projekts nicht angezeigt. In Projekten, die sich nicht im Status Ready befinden, können keine neuen Ressourcen unterstützt oder neue Änderungen an vorhandenen Ressourcen verarbeitet werden. Da der Projektstatus nicht bestätigt werden kann, ist unklar, wann die Ressourcen eines Projekts verwaltet werden können. Dies führt zu Fehlern, wenn neue Projekthandlungen versucht werden.

Problemumgehung:Im RM-R0100-Runbook finden Sie Informationen dazu, wie Sie den Status des Projekts mit der kubectl CLI ausgeben.

Upgrade

`bm-system` und andere Jobs hängen fest

Versionen: 1.13.1

Symptome:Der Job bm-system und andere Jobs, in denen das Ansible-Playbook ausgeführt wird, bleiben bei gathering facts hängen.

Problemumgehung:Geben Sie den Namen des Knotens ein, der nicht reagiert, und führen Sie multipath -ll | grep failed und multipath -ll | grep # aus. Wenn das Ergebnis nicht leer ist,folgen Sie den Runbooks FILE R0020 und FILE R0021.

Nicht erreichbare Verwaltungs-IP

Versionen: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Symptome: Während eines Upgrades ist die Management-IP eines Servers nicht erreichbar, insbesondere nach einem Switch.

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 diese Verwaltungs-IP möglicherweise vorübergehend nicht erreichbar.

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

systemctl restart NetworkManager.service

Die Versionsnummer für `storagecluster` wird nicht angezeigt

Versionen: 1.13.3

Symptome: Nach einem Upgrade wird im StorageCluster-CR kein Wert für das Statusfeld StorageVersion angezeigt.

Version prüfen:

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

Führen Sie die Schritte im Workaround aus, wenn das Feld „Version“ leer ist.

Problemumgehung: Starten Sie das file-storage-backend-controller-Deployment neu:

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

Bare-Metal-Server hängt im Bereitstellungsstatus fest

Versionen: 1.13.1

Symptome:

Der Bare-Metal-Server hängt lange Zeit im Status „Bereitstellung“ fest, wenn eine Organisation erstellt wird.

Problemumgehung:

Möglicherweise wurde die BIOS-Konfiguration des Servers so geändert, dass der Server die falsche Netzwerkkarte für den PXE-Boot verwendet.

So deaktivieren Sie den Netzwerk-Bootvorgang der Datenebene-NIC:

Erforderlicher Zugriff:
- Sie benötigen Zugriff auf die BMC-Administratoranmeldedaten der Server, die nicht reagieren.
- Folgen Sie der Anleitung unter IAM-R0005, um die ClusterRole „hardware-admin“ im Root-Administratorcluster für 1 Stunde zu erhalten.
- Folgen Sie der Anleitung unter IAM-R0004, um die KUBECONFIG für den Root-Administratorcluster zu generieren.

Legen Sie den Namen des Servers fest, der nicht reagiert.
```
export SERVER_NAME=
```

Legen Sie die IP-Adresse und die Anmeldedaten des BMC des Servers fest.

export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

Ermitteln Sie den PCIe-Steckplatz der Datenebene-Netzwerkkarte auf dem Server.
```
kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}
```
Die folgende Ausgabe gibt beispielsweise an, dass die Netzwerkkarte in Slot 3 installiert ist.
```
["s3p1","s3p2"]
```
Legen Sie die Variable „PCIEslot“ fest:
```
export DATA_NIC_SLOT=3
```
Prüfen Sie, ob der Netzwerkboot nicht deaktiviert ist.
```
curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"
```
Wenn das Ergebnis „NetworkBoot“ lautet, müssen Sie die Funktion explizit deaktivieren.

Verwenden Sie BMC, um die Netzwerkboot-Funktion auf der Datenebene-Netzwerkkarte zu deaktivieren.

Ersetzen Sie „Slot3“ im folgenden Befehl durch die tatsächliche Slotnummer.

curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

und starten Sie dann den Computer neu.

curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

Es dauert 10 bis 15 Minuten, bis der Server wieder betriebsbereit ist. Der Bereitstellungsvorgang wird dann automatisch fortgesetzt.

Beim Upgrade des Objektspeichers wird während der Postflight- oder Preflight-Prüfung ein Fehler angezeigt

Versionen: 1.13.1

Symptome:Die Preflight- oder Postflight-Prüfungen schlagen mit einem Fehler fehl. Logs prüfen:

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

Der Fehler könnte so aussehen:

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

Problemumgehung:

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:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Wenn der Fehler beispielsweise in org-1 auftritt, sieht der Befehl so aus:

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

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:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Wenn der Fehler beispielsweise in org-1 auftritt, sieht der Befehl so aus:

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

Möglicherweise müssen Sie diese Problemumgehung mehrmals anwenden, wenn sie nicht funktioniert.

Helm-Upgrade-Rollbacks

Versionen: 1.13.3

Symptome: Ein Problem beim Helm-Upgrade führt zu einer Reihe von Rollbacks, da keine Certificate und ServiceEntry gefunden werden können. Möglicherweise wird eine Meldung wie diese angezeigt:

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

Problemumgehung: Folgen Sie der Anleitung im OCLCM-R0122-Runbook.

Knoten-Upgrade oder ABM hängt, weil der dhcp-tftp-core-server-Pod nicht geleert wurde

Versionen: 1.13.3, 1.14.4, 1.14.5

Symptome: Das Knoten-Upgrade bleibt möglicherweise hängen. Im Status der Bare-Metal-Maschine ist der dhcp-tftp-core-server-Pod nicht geleert. Möglicherweise wird eine Meldung wie diese angezeigt:

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

Problemumgehung: Erzwingen Sie das Löschen des dhcp-tftp-core-server-*-Pods, um fortzufahren. Der Befehl sieht so aus:

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

`OrganizationUpgrade` bleibt beim Knotenupgrade hängen

Versionen: 1.13.3

Symptome: OrganizationUpgrade bleibt in der Phase des Knotenupgrades hängen. Möglicherweise wird eine Meldung wie diese angezeigt:

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

Problemumgehung:

Suchen Sie im Root-Cluster ka get upgradetaskrequest -n gpc-system nach upgradetaskrequest-CRs. Prüfen Sie, ob sich der Knoten noch im Status „Wird ausgeführt“ befindet. Prüfen Sie, ob das Gerät bei der Aufgabe für den Dienst hängen geblieben ist.

spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

Erstellen Sie manuell nodeupgrade CRs für jeden Knotenpool-Anspruch:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

Erstellen Sie für jeden Knotenpoolanspruch eine nodeupgrade-CR. Details zur Annotation upgrade.private.gdc.goog/target-release-version müssen aus dem OS CRMD-Namen des Ziels abgerufen werden:

kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

Verwenden Sie die Version von hier in den Annotationen upgrade.private.gdc.goog/target-release-version:

kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

Wenden Sie die folgenden yaml für jeden „NodepoolClaim“ an:

    apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

Nachdem die Knotenupgrades für die Knoten des Dienstclusters abgeschlossen sind, aktualisieren Sie den Status des UpgradeTaskRequest CR auf „True“, damit das Organisationsupgrade mit der nächsten Phase fortgesetzt wird:

    kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

Das Organisations-Upgrade sollte jetzt in die nächste Phase übergehen und der Status für den Dienst oder Knoten sollte „Abgeschlossen“ lauten:

Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

Kernel kann keinen Container erstellen

Versionen: 1.13.3

Symptome: Der Kernel kann keinen Speicher für cgroup zuweisen, was zu Fehlern beim Erstellen neuer Container führt.

Möglicherweise wird eine Meldung wie diese angezeigt:

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

und der Knoten eine sehr große Anzahl von Cgroups verwendet:

# cat /proc/cgroups | grep memory
memory  12      380360  1

Problemumgehung:

Führen Sie einen der folgenden Schritte aus:

Führen Sie echo 3 > /proc/sys/vm/drop_caches auf dem Knoten aus und starten Sie kubelet neu.
Wenn die vorherige Methode nicht funktioniert, starten Sie den Knoten neu.

Zeitweise Verbindungsfehler zum externen Cluster-VIP

Versionen: 1.13.3

Symptome: Zeitweilige Verbindungsfehler zur externen Cluster-VIP (Virtual IP), z. B. zur VIP der Steuerungsebene, zur istio-gateway-VIP oder zur Harbor-VIP, führen zu einem dial tcp :: connect: no route to host-Fehler.

So diagnostizieren Sie dieses Problem:

Stellen Sie eine Verbindung zum Administratorcluster der obersten Ebene her. Bei dieser Problemumgehung wird davon ausgegangen, dass Sie IP-Adressen in einem Administratorcluster auf Stammebene debuggen. Wenn Sie Verbindungsprobleme mit anderen Kubernetes-Clustern wie den Administrator- oder Systemclustern der Organisation beheben, ändern Sie den KUBECONFIG-Wert in den richtigen kubeconfig-Pfad des Clusters.
Es gibt zwei bekannte Kategorien von IP-Adressen, die betroffen sein können. Prüfen Sie, ob die IP-Adressen über das Border Gateway Protocol (BGP) für die Top-of-Rack-Switches (ToR) beworben werden:
- Wenn die IP-Adresse eine IP-Adresse der Kubernetes-Steuerungsebene wie 192.0.2.100 ist, verwenden Sie diesen Befehl, um die Konfigurationsinformationen abzurufen:
```
KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`
```
  Ersetzen Sie KUBECONFIG durch den Pfad zu Ihrer kubeconfig-Datei im Administratorcluster des Stammclusters.
- Bei einigen Konfigurationen wird mit der benutzerdefinierten Ressource BGPAdvertisedRoute definiert, welche Routen in der IP-Adresse über BGP an andere Netzwerke oder Systeme beworben werden. Wenn die IP-Adresse von der benutzerdefinierten Ressource BGPAdvertisedRoute beworben wird, verwenden Sie diesen Befehl, um die Konfigurationsinformationen abzurufen:
```
TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP
```
  Ersetzen Sie TARGET_IP_ADDRESS durch die IP-Adresse, bei der zeitweise Verbindungsprobleme auftreten.

Prüfen Sie den Status der benutzerdefinierten BGPSession-Ressourcen. Ein BGPSessionstellt eine einzelne BGP-Peering-Sitzung dar, die zwischen Ihrem Kubernetes-Cluster und einem externen BGP-Peer eingerichtet wurde. Prüfen Sie die Logs der BGPAdvertiser-Pods und vergewissern Sie sich, dass alle BGPSession-Ressourcen den Status Established haben:

KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

Die Ausgabe eines fehlerfreien BGPAdvertiser-Pods enthält das folgende Snippet:

I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

Prüfen Sie die Stabilität der Verbindung. Erstellen und führen Sie ein Skript aus, um zu prüfen, ob die Verbindung zeitweise unterbrochen oder instabil ist:

So erstellen Sie das Skript:

#!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

Führen Sie das Skript aus:

./script.sh TARGET_IP_ADDRESS:PORT

Ersetzen Sie PORT durch die Portnummer, bei der Probleme auftreten.

Wenn es Probleme mit der Verbindung gibt, sehen Sie eine Ausgabe wie die folgende:

Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

Die vorherige Ausgabe bestätigt das Problem. Prüfen Sie die Routen auf den TOR-Switches, um festzustellen, ob die TOR-Switch-Konfiguration die Ursache des Problems ist.

Angenommen, der Traffic wird für die Beispiel-IP-Adresse 192.0.2.201 verworfen und von der BGPAdvertisedRoute-Ressource beworben. Untersuchen Sie die Hops in der BGPAdvertisedRoute-Ressource, um potenzielle Fehlerquellen zu ermitteln:

apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

Sehen Sie sich die IP-Adressen im Feld nextHops an. Suchen Sie für jede IP-Adresse den Servernamen. Beispiel:
```
- 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01
```
Diese Ausgabe zeigt, dass die nächsten Hops zu Servern in Rack aa und Rack ab führen. Melden Sie sich bei den TOR-Switches in Rack aa und ab an und vergleichen Sie die Routen in beiden Racks:
```
show ip route 192.0.2.201 vrf root-external-vrf
```

Wenn sich die Routen zwischen den TOR-Switches in den beiden Racks unterscheiden, tritt das Problem auf, das durch den Workaround behoben wird. Die Ausgabe für dieses Problem sieht so aus:

zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

In dieser Ausgabe sind die Routen in Rack aa im erwarteten Zustand. Für das Präfix sind drei Next Hops aufgeführt. Im Rack ab hat das Präfix jedoch nur zwei nächste Hops. Wenn Traffic, der für das Präfix bestimmt ist, auf Rack ab gehasht wird, empfängt der Knoten, der dem fehlenden nächsten Hop entspricht, den Traffic nie und es kommt zu einem Verbindungsproblem im Netzwerk.

Folgen Sie der Anleitung, um das Problem zu beheben.

Problemumgehung:

Diese Problemumgehung kann bei zeitweiligen Verbindungsproblemen mit bestimmten IP-Adressen in Kubernetes-Clustern helfen.

Um dieses Problem zu beheben, müssen Sie mehrere Konfigurationsänderungen an der BGP-Sitzung zwischen den Aggregations-Switches vornehmen. AGG-Switches (Aggregate) aggregieren Traffic von mehreren TOR-Switches. So aktualisieren Sie alle erforderlichen Konfigurationen:

Eine Konfigurationsdatei namens switchstaticconfig stellt die statischen Konfigurationen auf einem einzelnen Switch dar. Laden Sie die Datei switchstaticconfig für beide AGG-Switches herunter:

export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

Rufen Sie die ASN (Autonomous System Number) der Umgebung ab:
```
root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030
```
Diese Ausgabe zeigt einen ASN-Wert von 65030. Sie müssen den ASN-Wert, der hier zurückgegeben wird, in den folgenden Schritten verwenden.
Eine Loopback-IP-Adresse auf einem AGG-Switch dient als stabile und immer aktive Adresse für Verwaltung, Routing und Fehlerbehebung, auch wenn andere Netzwerkverbindungen nicht funktionieren. Rufen Sie die Loopback-IP-Adressen der einzelnen AGG-Switches ab:
```
root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'
```
Die Ausgabe sieht dann ungefähr so aus:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Aktualisieren Sie die staticswitchconfig für den AGG-Schalter za-ab-aggsw01. Fügen Sie dieses Snippet in den Abschnitt config ein:
```
spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1
```
Ersetzen Sie Folgendes:
- ASN: Der ASN-Wert aus dem vorherigen Schritt. In diesem Beispiel ist der Wert 65030.
- LOOPBACK_ADDRESS: Dies ist die Loopback-IP-Adresse des AGG-Switches za-ac-aggsw01. In diesem Beispiel ist der Wert 192.0.2.2.
Wenden Sie dasselbe Update auf den anderen AGG-Switch, za-ac-aggsw01, an. Sie müssen die richtige Loopback-Adresse angeben. Die Loopback-IP-Adresse ist für jeden Switch unterschiedlich:
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
Erstellen und führen Sie das gleiche Skript aus, das Sie in diesem Schritt zur Diagnose des Problems verwendet haben, um zu prüfen, ob die Korrektur erfolgreich war. In der Ausgabe werden keine Fehlermeldungen angezeigt.

Fehler `Incorrect version of Trident` wird während des Upgrades angezeigt

Versionen: 1.13.3, 1.13.4, 1.13.5

Symptome: Beim Upgrade von Versionen unter 1.13.3 wird in ontap der Fehler Incorrect version of Trident angezeigt. Möglicherweise wird eine Meldung wie diese angezeigt:

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

Problemumgehung:

Aktualisieren Sie die releasemetadata der Version, auf die Sie ein Upgrade durchführen:

export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

Die Ausgabe könnte so aussehen:

NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

Wählen Sie die Version aus, auf die Sie ein Upgrade durchführen möchten, wie im folgenden Beispiel:
```
kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml
```
Aktualisieren Sie die tridentVersion im Abschnitt „fileBlockStorage“ der YAML-Datei auf die im Fehler angegebene Version. Wenn die Fehlermeldung so aussah:
```
Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5
```
Ändern Sie die tridentVersion in v23.10.0-gke.5 in releasemetadata.yaml.

Wenn der ursprüngliche Wert beispielsweise infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6 war,

Ändern Sie sie in den folgenden Wert:

infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.
Übernehmen Sie die Änderung:
```
kubectl apply -f releasemetadata.yaml
```
Wenden Sie das ontap-Speicherplatz-Upgrade noch einmal an.

Pods können nicht geplant werden

Versionen: 1.13.3. 1.13.4, 1.13.5

Symptome: Während der Bereitstellung des Nutzerclusters können einige Pods nicht geplant werden. Möglicherweise wird eine Meldung wie diese angezeigt:

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

Problemumgehung:

Skalieren Sie den Knotenpool der Steuerungsebene des Nutzerclusters hoch:

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

Fehler beim Upgrade der Unterkomponente `iac-zoneselection-global`

Versionen: 1.13.1

Symptome:Während eines Upgrades auf Version 1.13.3 tritt bei der Unterkomponente iac-zoneselection-global ein Fehler auf. Möglicherweise wird eine Meldung wie diese angezeigt:

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Problemumgehung:

Ein Upgrade auf Version 1.13.3 behebt den Fehler.

Frist für Upgrade-Prüfungsjobs überschritten

Versionen: 1.12.x, 1.13.x

Symptome:Während des Organisationsupgrades wird beim Upgrade-Check der Status False mit dem Grund DeadlineExceeded angezeigt. Möglicherweise wird eine Meldung wie diese angezeigt:

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

Problemumgehung:

Löschen Sie die fehlgeschlagenen Upgrade-Prüfjobs, die den fehlgeschlagenen Upgrade-Prüfungen entsprechen.
Warten Sie, bis die Upgrade-Prüfjobs neu erstellt wurden.
Sehen Sie sich die Logs der neu erstellten Jobs an und beheben Sie die Probleme.

Das `meta-monitoring`-Add-on schlägt fehl, weil sich der strongswan-Speicherort in einem anderen Laufzeitverzeichnis befindet.

Versionen: 1.12.x, 1.13.x

Symptome:Beim Upgrade auf 1.13.4 oder 1.13.5 schlägt das meta-monitoring-Add-on fehl:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

Add-on prüfen:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

Die Meldung zur Bedingung könnte so aussehen:

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

Problemumgehung:

Prüfen Sie, ob die BGP-Sitzungen im Organisationssystemcluster fehlschlagen, z. B.:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

Prüfen Sie, ob die ang-node-Pods im Status ContainerCreating hängen bleiben, z. B.:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

Der folgende Fehler wird angezeigt:

Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

Nehmen Sie die folgende Änderung an der ang-overrides AddonConfiguration im Organisationsadministratorcluster vor:

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

Ändern Sie Folgendes:

            volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

auf Folgendes:

            volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

Prüfen Sie nach etwa einer Minute, ob sich die ang-node-Pods jetzt im Status Running befinden:

NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

Prüfen Sie, ob die BGP-Sitzungen im Org System Cluster jetzt ausgeführt werden.
Das Add-on meta-monitoring wird mit der nächsten Phase fortgesetzt.

Upgrade der Stammorganisation bleibt aufgrund eines fehlgeschlagenen Signaturjobs hängen

Versionen: 1.13.3, 1.13.4

Symptome: Beim Upgrade von 1.13.3 auf 1.13.4 wird möglicherweise eine Meldung wie diese angezeigt:

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

Problemumgehung:

So deaktivieren Sie die Preflight-Prüfung:

kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

Löschen Sie den fehlgeschlagenen artifact-signature-verification-***-Job.
Warten Sie, bis das Root-Upgrade abgeschlossen ist.
Optional: Aktivieren Sie die Preflight-Prüfung, wenn die Umgebung auf Version 1.13.4 oder höher aktualisiert wird.

Wenn die Controller-Version 1.13.4 erreicht ist, sollte dieses Problem bei Upgrades nicht mehr auftreten.

Das Upgrade der Mandantenorganisation schlägt in der Preflight-Prüfungsphase mit `ErrImagePull` fehl

Versionen: 1.13.3

Symptome: Das Upgrade der Mandantenorganisation schlägt in der Preflight-Prüfungsphase mit ErrImagePull für den Pod zur Paketvalidierung fehl. Möglicherweise wird eine Meldung wie diese angezeigt:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Die Pods zeigen den Fehler ImagePullBackOff an:

kubectl describe po -n package-validation-system POD_NAME

Es wird ein Fehler beim Abrufen des Images angezeigt, z. B.:

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

Problemumgehung:

Preflight-Prüfungen überspringen:

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

`serviceaccount` konnte während des Upgrades der Stammorganisation nicht gefunden werden

Versionen: 1.13.8, 1.13.9

Symptome: Beim Upgrade auf Version 1.13.8 schlägt das addon-Deployment für RBACs fehl, wenn bereits Upgrades durchgeführt wurden und Add-ons vorhanden sind. Die Symptome können in einem der folgenden Stadien auftreten:

Preflight- oder Postflight-Prüfungen
Jede Phase, die eine Upgrade-Aufgabe umfasst, und die Meldung gibt an, dass der Job ausgeführt wird, obwohl die Aufgabe nicht weiterkommt. Die Meldung status.conditions weist darauf hin, dass der Job lange ausgeführt wird, was auf ein Problem hindeutet.

Wenn Sie prüfen möchten, ob ein Fehler bei der Preflight-Prüfung für das Upgrade aufgetreten ist, sehen Sie sich den Status des entsprechenden OrganizationUpgrade-Objekts für die Organisation an, die das Upgrade durchführt:

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

Wenn der Job bei PreflightCheck fehlschlägt, wird möglicherweise ein Fehler wie dieser oder eine UpgradeCheckRBACDeploymentInProgress-Meldung angezeigt:

  - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

Wenn der Job in der Anthos Bare Metal-Phase (ABM) fehlschlägt, in der der Aufgabenjob ausgeführt wird, wird die folgende Ausgabe angezeigt:

- Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

Wenn der Fehler in den Prüfungen liegt, schlägt der upgradecheckrequest CR fehl:

kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

Die Ausgabe könnte so aussehen:

NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

Wenn der Fehler in Aufgaben auftritt, schlägt upgradetaskrequests CR fehl:

kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

Die Ausgabe könnte so aussehen:

NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

Wenn der Fehler auf einen RBAC-Fehler beim Suchen nach einem Dienstkonto hinweist, prüfen Sie, ob ein vorheriges Add-on bereitgestellt wurde:

Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Workaround:

Prüfen, ob ein vorheriges Add-on bereitgestellt wurde:

  Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

Rufen Sie die Add-ons ab, die für dieselbe Komponente, upgrade-task-mz für die Aufgabe vorhanden sind:

kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

Dieses Add-on löschen:

kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

Nachdem Sie das Add-on gelöscht haben, löschen Sie auch das entsprechende upgradetaskrequest oder upgradecheckrequest. Sie wird neu erstellt.
```
kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc
```
Behalten Sie die neu erstellte upgradetaskrequest, upgradecheckrequest oder den entsprechenden Job im Blick.

Upgrade schlägt auf `shared-service-cluster upgrade` fehl

Versionen: 1.13.3

Symptome:Das Anthos Bare Metal-Upgrade bleibt bei einer oder mehreren Bare Metal-Maschinen hängen. Alle anderen Bare-Metal-Maschinen wurden erfolgreich aktualisiert oder das Upgrade wurde noch nicht gestartet. Eine Bare-Metal-Maschine befindet sich im Wartungsmodus, zeigt aber weiterhin die frühere Version für die Felder „CURRENT ABM VERSION“ (AKTUELLE ABM-VERSION) und „DESIRED ABM VERSION“ (GEWÜNSCHTE ABM-VERSION) an.

Folgen Sie der Anleitung unter Anthos Bare Metal, um den Status baremetalmachine und Details für den Cluster abzurufen:

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

Erwartete Ausgabe:

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

Erwartete Ausgabe:

true

Workaround:

Beenden Sie den Wartungsmodus des Inventargeräts:

export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

Warten Sie, bis das Inventargerät den Wartungsmodus beendet hat. Das kann bis zu 10 Minuten dauern.

kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

Beobachten Sie die Bare-Metal-Maschinen, um zu sehen, ob die ausgewählte ABM-Version aktualisiert wird.
```
kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}
```

Installation des Add-ons „`system-dashboards`“ fehlgeschlagen

Versionen: 1.13.5

Symptome: Das Upgrade von 1.12.4 auf 1.13.5 schlägt beim Add-on-Upgrade für das system-dashboards-Add-on fehl:

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

Problemumgehung:Folgen Sie der Anleitung im OCLCM-R0122-Runbook.

`NodeUpgradeTask` CR hängt bei der Bedingung `NodeOSInPlaceUpgradePostProcessingCompleted` fest

Versionen: 1.13.5

Symptome: Beim Upgrade auf Version 1.13.5 bleibt die NodeUpgradeTask-Antwortvorlage beim Zustand NodeOSInPlaceUpgradePostProcessingCompleted hängen.

Prüfen Sie, ob der entsprechende os-artifact-collector-Job abgeschlossen ist. Wenn der Job viele Stunden lang nicht abgeschlossen wird, wird die folgende Meldung angezeigt:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Workaround:

Löschen Sie den Job oder den Pod, um einen erneuten Versuch zu erzwingen.

Fehler bei der Bildverteilung während eines Upgrades

Versionen: 1.13.5

Symptome: Die Bildverteilung schlägt bei einem Upgrade von 1.12.4 auf 1.13.x fehl:

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

Prüfen Sie die obj-proxy-Pods in gpc-system in der Organisation, um zu sehen, ob die Zertifikatsüberprüfung fehlgeschlagen ist:

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

Workaround:

Starten Sie den obj-proxy-Pod mit KUBECONFIG der Organisation neu, bei der der Fehler auftritt:

export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

Prüfen Sie die Logs für obj-proxy:

kubectl get pods -n gpc-system | grep obj-proxy

Die erwartete Ausgabe sieht so aus:

obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

Prüfen Sie die Logs der verfügbaren Pods, z. B.:
```
kubectl logs obj-proxy-gdgzp -n gpc-system
```
Die Jobs zur Bildverteilung sollten nach Anwendung des Workarounds abgeschlossen werden.

Knoten fällt während des Nutzercluster-Upgrades aus

Versionen: 1.13.3

Symptome: Ein Job, der auf einem Knoten ausgeführt wird, schlägt während des Upgrades des Nutzerclusters fehl und es wird eine Fehlermeldung wie diese angezeigt:

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

Melden Sie sich am Knoten an und prüfen Sie, ob die Partition voll ist:

df -h /

Die Ausgabe könnte so aussehen:

Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

Prüfen Sie, ob /etc/kubernetes/tmp viel Speicherplatz belegt: du -s /etc/kubernetes/tmp. Dieses Problem tritt auf, wenn Kubernetes mehr Backups als üblich erstellt.

Workaround:

Alle Sicherungen auf rm -f /etc/kubernetes/tmp/* löschen:

df -h /

Die Ausgabe könnte so aussehen:

Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

Das Upgrade des Root-Administrators wird neu erstellt und schlägt bei Preflight-Prüfungen fehl

Versionen: 1.13.3, 1.13.4, 1.13.5, 1.13.6, 1.13.7, 1.13.8, 1.13.9

Symptom: Das Upgrade der Stammorganisation schlägt bei der Preflight-Prüfung fehl, z. B.:

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

Der Root-Administratorcluster und die kubeapiserver für den Root-Administrator wurden auf die ausgewählte ABM-Version aktualisiert.

Beispiel:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

Beispielausgabe für kubectl describe kubeapiserver root-admin -n root:

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

Beispielausgabe für kubectl get cluster root-admin -n root:

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

Problemumgehung

So überspringen Sie die Preflight-Prüfung, um mit dem Upgrade fortzufahren:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

Namespaces `platform-obs-obs-system` oder `platform-obs` bleiben im Beendigungsstatus hängen

Versionen: 1.13.5

Symptome: Add-ons können während des Upgrades oder Bootstraps nicht bereitgestellt werden und es wird eine Fehlermeldung wie diese angezeigt:

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

Die angezeigte Ausgabe sieht so aus:

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

Wenn für die Status DEPLOYED oder READY false angezeigt wird oder die Status leer sind, prüfen Sie die entsprechenden Add-ons auf Fehler, z. B.:

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

Die angezeigte Ausgabe sieht so aus:

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

Das Add-on ist blockiert, weil es versucht, Inhalte in den Namespaces zu erstellen, die gelöscht werden. Diese Blockierung bleibt bestehen, da auch das Löschen des Namespace blockiert ist.

Workaround:

Bevor Sie mit einem Upgrade beginnen, müssen Sie die Projekte mit Anmerkungen versehen, um ein Löschen zu verhindern:

export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

Die angezeigte Ausgabe sieht so aus:

project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

Wenn die Umgebung bereits die oben beschriebenen Symptome aufweist, führen Sie den folgenden Workaround aus:

Das Löschen des Namespace wird aufgrund von Ressourcen mit Finalizern blockiert. Entfernen Sie die Finalizer mit dem bereitgestellten Script, um mit dem Löschen fortzufahren:

  export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

Warten Sie, bis die Ressource gelöscht wurde. Löschen Sie nach dem Ausführen des Skripts die Ressourcen und die zu schließenden Namespaces. Möglicherweise müssen Sie das Skript noch einmal ausführen, wenn der Namespace immer noch den Status „Wird beendet“ hat. Nach der Beendigung wird der Namespace automatisch neu erstellt. Prüfen Sie, ob die Namespaces neu erstellt wurden und den Status „ACTIVE“ haben:
```
  export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system
```
Die angezeigte Ausgabe sieht so aus:
```
  NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s
```
Bei aktiven Namespaces sollten die Add-ons, die nicht bereitgestellt werden konnten, innerhalb weniger Minuten bereitgestellt werden. Prüfen Sie, ob die Status „DEPLOYED“ und „READY“ jetzt „true“ sind:
```
  export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards
```
Die angezeigte Ausgabe sieht so aus:
```
  NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998
```

UPORC-Absturzschleifen im KIND-Cluster während des Bootstrapping

Versionen:1.13.x

Symptome:Das Deployment uporc-root-backend-controller im Namespace uporc-system durchläuft im KIND-Cluster Crash-Schleifen.

Workaround:

Prüfen Sie, ob die Objekte ComponentGroupReleaseMetadata und ReleaseMetadata übereinstimmen:
```
export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata
```
Wenn die Objekte übereinstimmen, ist keine Behelfslösung erforderlich.
Wenn die Objekte nicht übereinstimmen, wenden Sie sich an das UPORC-Team, da dies auf andere zugrunde liegende Probleme hinweisen kann.

Knotenupgrade fehlgeschlagen

Versionen: 1.13.6

Symptome: Das Knotenupgrade ist bei NodeOSInPlaceUpgradeCompleted fehlgeschlagen.

Prüfen Sie die Logs der os-upgrade-ospolicy-Jobs.
Wenn das Log einen Fehler enthält, der darauf hindeutet, dass die Konfigurationsdatei beschädigt ist, rufen Sie den Knotencomputer auf und prüfen Sie den Dateiinhalt manuell, um festzustellen, ob er beschädigt ist. Im Protokollfehler werden möglicherweise der Fehlercode configparser.DuplicateOptionError und die Datei /etc/yum.repos.d/gdch.repo erwähnt.

Problemumgehung: Nur wenn Sie bestätigt haben, dass die Datei beschädigt ist, löschen Sie die beschädigte /etc/yum.repos.d/gdch.repo-Datei auf dem fehlerhaften Knoten manuell.

Der Ansible-Job für das Upgrade generiert die Datei automatisch als Teil des Ansible-Playbooks neu.

### Die NodeUpgradeTask-Antwortvorlage hängt bei der Bedingung NodeOSInPlaceUpgradePostProcessingCompleted fest.

Versionen: 1.13.5

Symptome: Beim Upgrade auf Version 1.13.5 bleibt die NodeUpgradeTask-Antwortvorlage beim Zustand NodeOSInPlaceUpgradePostProcessingCompleted hängen.

Prüfen Sie, ob der entsprechende os-artifact-collector-Job abgeschlossen ist. Wenn der Job viele Stunden lang nicht abgeschlossen wird, wird die folgende Meldung angezeigt:

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

Workaround:

Löschen Sie den Job oder den Pod, um einen erneuten Versuch zu erzwingen.

`NodeUpgradeTask` CR hängt bei der Bedingung `NodeBIOSFirmwareUpgradeCompleted` fest

Versionen: 1.13.5

Symptome: Beim Upgrade auf Version 1.13.5 bleibt die NodeUpgradeTask-Antwortvorlage beim Zustand NodeBIOSFirmwareUpgradeCompleted hängen.

Prüfen Sie, ob die entsprechende NodeBIOSFirmwareUpgradeCompleted-Bedingung mit der folgenden Bedingung angezeigt wird:

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

Workaround:

Bearbeiten Sie im NodeUpgrade CR "U30 v3.20 (05/29/2024)" manuell zu "U30 v3.20 (05/27/2024)".

Das Cluster-Upgrade wird blockiert, da ein Knoten nicht in den Wartungsmodus wechseln kann.

Versionen: 1.13.5, 1.13.6, 1.13.7

Symptome: Das Upgrade des Clusters (Organisationsadministrator-, System- oder Nutzercluster) wird blockiert, weil ein Knoten nicht in den Wartungsmodus wechselt.

Im Cluster ist MaintenanceMode auf true gesetzt, aber Status bleibt bei der Ausführung des folgenden Befehls bei false hängen:

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

Die angezeigte Ausgabe sieht so aus:

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

Workaround:

Legen Sie KUBECONFIG auf die kubeconfig-Datei des Clusters fest, der den Knoten enthält, für den das Training rückgängig gemacht werden soll. Der Cluster kann entweder der Nutzercluster oder ein Shared Services-Cluster sein.

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

Zeitüberschreitung während des anfänglichen Root-Vorgangs `organizationupgrade`

Versionen: 1.13.3

Symptome: Wenn die Anmerkung „Wartungsfenster ignorieren“ während eines Organisationsupgrades vorhanden ist, wird die organizationupgrade-CR wiederholt gepatcht, wodurch der Fortschritt zurückgesetzt wird.

Problemumgehung:

Pausieren Sie die Unterkomponente rm-org und skalieren Sie die rm-org-backend-controller-Replikate herunter.

Wenn der Alias nicht deklariert ist, führen Sie Folgendes aus:

alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

Pausieren Sie die Unterkomponente und verkleinern Sie das Deployment für rm-org:

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

Nach Abschluss des Clusterupgrades können Sie die Bereitstellung wieder verkleinern:

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

Für die Unterkomponente `obj-syslog-server` schlägt der Abgleich in der Stammorganisation fehl

Versionen: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Symptome:Während des Upgrades auf Version 1.13.x befindet sich die Unterkomponente obj-syslog-server im Status ReconciliationError:

root        obj-syslog-server     ReconciliationError

mit einer Bedingung wie:

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

Möglicherweise sehen Sie, dass sich der Pod syslog-server-abcdefg-wxyz im Status CrashLoopBackOff befindet und der folgende Fehler angezeigt wird:

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

Workaround:

Wenn Sie die Unterkomponente wieder in einen fehlerfreien Zustand versetzen möchten, entfernen Sie die unnötige volumeMounts.

Aktuelles Deployment bearbeiten:

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

kubectl edit deployments syslog-server -n istio-system

Entfernen Sie die volumeMounts, die in der spec.containers.volumeMounts nicht benötigt werden. Entfernen Sie die folgenden Mount-Pfade:

    - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

Wenden Sie die Änderungen an. Die untergeordnete Komponente wird nach dem Anwenden der Änderungen wieder auf ReconciliationCompleted zurückgesetzt.

ABM- oder Knotenupgrade bleibt bei `maintenanceMode false` hängen

Versionen: 1.13.4

Symptome: Der Knoten hängt beim Upgrade des AnthosBaremetal-Clusters fest und wechselt nicht in den Wartungsmodus.

Prüfen Sie die Bare-Metal-Maschine auf einem Dienstclusterknoten, z. B.:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

Problemumgehung:

Starten Sie anthos-cluster-operator neu, um BMM.MaintenanceMode zu übernehmen:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

Upgrade schlägt beim Upgrade des ATAT-Webhooks-Add‑ons für die Mandantenorganisation fehl

Versionen: 1.13.5

Symptome: Das Upgrade des Add-ons „atat-webhooks“ kann nicht wiederhergestellt werden:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Möglicherweise wird eine Meldung wie diese angezeigt:

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

Pods für atat-webhooks-parameters-***** prüfen:

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Möglicherweise wird ein Fehler wie der folgende angezeigt:

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

Problemumgehung:

So erstellen Sie eine Kopie des aktuellen Portfolios:

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

Aktualisieren Sie portfolio-org-1 Pop End Date auf ein zukünftiges Datum:
```
kubectl delete portfolios -n atat-system portfolio-org-1
```
Wenn dieser Befehl nicht mehr reagiert, löschen Sie die Bedingung .Metadata.Finalizers aus dem aktiven Portfolio, bevor Sie das Portfolio löschen. Die Bedingung könnte so aussehen:
```
│     portfolio.finalizers.atat.config.google.com 
```
Wenden Sie die kopierte YAML-Datei noch einmal an:
```
kubectl apply -f portfolio-org-1
```
Prüfen Sie noch einmal die Datumsangaben, um sicherzugehen, dass sowohl die Portfolios als auch die ConfigMap aktualisiert wurden.
Wenn der Job nicht wiederhergestellt wird, löschen Sie den fehlerhaften atat-webhooks-parameters-Job. Er wird dann wiederhergestellt. Warten Sie, bis der Vorgang abgeschlossen ist:
```
kubectl delete jobs -n org-1 atat-webhooks-parameters
```

Die Postflight- oder Upgrade-Prüfung schlägt aufgrund von `DeadlineExceeded`- oder `BackoffLimitExceeded`-Fehlern fehl.

Versionen: 1.13.8

Symptome:

Beim Upgrade von 1.13.7 auf 1.13.8 sind die Post-Flight-Prüfungen noch ausstehend und es werden DeadlineExceeded- oder BackoffLimitExceeded-Fehler angezeigt.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

Problemumgehung:

Ermitteln Sie, wo die Jobs fehlschlagen:

Prüfen Sie, ob die Jobs während der Preflight- oder Postflight-Prüfungen fehlschlagen:

kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

Prüfen Sie, ob die Jobs während des Upgrades fehlschlagen:

kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

Löschen Sie die Jobs:

kubectl delete jobs -n gpc-system CHECK_NAME

Upgrade-Prüfungen enthalten Ergebnisse, die für die Prüfstufe irrelevant sind.

Versionen: 1.13.x

Symptome:

Prüfungen für Organisationsupgrades können fehlschlagen, weil Ergebnisse von anderen Ebenen fälschlicherweise einbezogen wurden. Bei Prüfungen der Stammorganisation werden möglicherweise Ergebnisse der Mandantenorganisation angezeigt und bei Prüfungen der Mandantenorganisation Ergebnisse des Nutzerclusters.

Beispiel für Fehlerlogs für Prüfungen der Stammorganisation:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Problemumgehung:

Sie können die Preflight- oder Postflight-Prüfungen mit folgendem Befehl vollständig überspringen:

Preflight:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Nach Ausführung:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

Vortrainierte APIs haben in der Benutzeroberfläche den Status `Enabling`.

Versionen: 1.13.1

Symptome: Das MonitoringTarget hat den Status Not Ready, wenn Nutzercluster erstellt werden. Dadurch wird in der Benutzeroberfläche für vortrainierte APIs fortlaufend der Status Enabling angezeigt.

Problemumgehung:

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

Die vortrainierte API-Funktion `streaming_recognize` von Speech-to-Text schlägt fehl

Versionen: 1.13.3

Symptome: Beim Aufrufen der vortrainierten streaming_recognize-API-Funktion von Speech-to-Text wird aufgrund eines Problems mit der Clientbibliothek eine 400-Fehlermeldung ähnlich der folgenden angezeigt:

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Problemumgehung: Verwenden Sie das folgende Python-Skript, damit die Funktion streaming_recognize funktioniert:

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

Ersetzen Sie Folgendes:

ENDPOINT: der Speech-to-Text-Endpunkt. Weitere Informationen
APPLICATION_DEFAULT_CREDENTIALS_FILENAME: Der Name der JSON-Datei, die die von Ihnen im Projekt erstellten Dienstkontoschlüssel enthält, z. B. my-service-key.json.
CERT_NAME: der Name der Zertifikatsdatei der Zertifizierungsstelle (Certificate Authority, CA), z. B. org-1-trust-bundle-ca.cert. Weitere Informationen finden Sie unter CA-Zertifikatsdatei für das Vertrauensbündel in einer Entwicklungsumgebung generieren.

Das Python-Skript führt die folgenden Unterschiede zwischen den Funktionen streaming_recognize und recognize ein, damit der Workaround für streaming_recognize funktioniert:

Zeile 4: Eine zusätzliche import-Anweisung im Vergleich zum recognize-Script (from google.cloud.speech_v1p1beta1.services.speech import client).
Zeile 18: Der Client wird von client.SpeechClient() anstelle von speech_v1p1beta1.SpeechClient() zurückgegeben.

Die Initialisierung des Pods und Dienstes für das Übersetzungs-Frontend schlägt fehl

Versionen: 1.11.x, 1.12.x, 1.13.x

Symptome: Während Upgrades wird der Translation DB-Cluster neu erstellt. Dadurch ist das secret-store-Secret des ODS-Systemclusters veraltet und nicht mehr synchron. Aus diesem Grund schlägt die Initialisierung des Translation-Frontend-Pods und -Dienstes fehl.

Problemumgehung:

Löschen Sie das Secret im Systemcluster:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Ersetzen Sie SYSTEM_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei im Systemcluster.

Ein Controller erstellt das Secret automatisch neu und synchronisiert es wieder mit dem DB-Cluster.

Das Abrufen des Jobstatus wird für die `batchTranslateDocument` API nicht unterstützt.

Versionen: 1.13.3

Symptome: Vertex AI unterstützt keine GET- und LIST-Vorgänge in Translation Service APIs. Beim Aufrufen der Translation BatchTranslateDocument API wird ein Vorgang mit langer Ausführungszeit ähnlich dem folgenden Beispiel zurückgegeben:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Dieses Problem ist auf eine APIP-Beschränkung (Autorisierung) zurückzuführen, die verhindert, dass Sie den Endpunkt direkt aufrufen. Die Endpunkte unterstützen kein Job-Status-Polling und aufgrund der APIP-Einschränkung können Sie keine GET-Vorgänge für den lang andauernden Vorgang ausführen.

Problemumgehung: Als Application Operator (AO) können Sie den Status des Jobs prüfen, indem Sie regelmäßig Ihren s3_destination-Ordner auf eine neu erstellte Jobausgabedatei hin überprüfen. Wenn der Ordner die Ausgabedatei enthält, wurde der Job erfolgreich abgeschlossen.

`batchTranslateDocument`-Anfragen können zu Leistungsproblemen führen

Versionen: 1.13.3

Symptome: Der Batch-Dokumentübersetzungsdienst liest eine oder mehrere Eingabedateien des Nutzers und schreibt die temporären Verarbeitungs- und übersetzten Ausgabedateien in StorageGRID. Für jede Lese-/Schreibaktion wird ein neuer curl-Client erstellt, da die Wiederverwendung des Clients fehlschlägt.

Die S3-curl-Clients im Binärprogramm sind für die einmalige Verwendung vorgesehen. Das bedeutet, dass jeder Client nur eine einzige Lese-/Schreibaktion für StorageGRID-Buckets ausführen kann. Daher wird jedes Mal, wenn die Kommunikation mit dem StorageGRID-Client vom batchTranslateDocument-Server aus hergestellt wird, um Dateien in Buckets zu lesen und zu schreiben, ein neuer curl-Client erstellt.

Für curl-Kunden ist das jedoch nicht optimal. Das kann zu folgenden Problemen führen:

Leistungseinbußen: erhöhte Latenz und verringerter Durchsatz
Erschöpfung von Ressourcen: Arbeitsspeicher- und CPU-Overhead sowie Erschöpfung von Sockets
Serverüberlastung: Ratenbegrenzung oder Drosselung

In der GDC-Konsole wird nach der Aktivierung vortrainierter APIs ein inkonsistenter Status angezeigt

Versionen: 1.13.3

Symptome: Wenn Sie vortrainierte APIs zum ersten Mal aktivieren, wird in der GDC-Konsole nach einigen Minuten möglicherweise ein inkonsistenter Status für den aktivierten Dienst angezeigt. In der GDC-Konsole wird der Status von Enabling wieder auf Disabled zurückgesetzt und die Schaltfläche Aktivieren wird wieder in der Benutzeroberfläche angezeigt, auch wenn der Dienst tatsächlich aktiviert wird.

Problemumgehung: Der Status wird nach einigen Minuten konsistent und der Dienst spiegelt den richtigen Status wider.

Um den Status des Dienstes zu prüfen, öffnen Sie in der Browserkonsole den Tab Network (Netzwerk) und sehen Sie sich den Status der ai-service-status-Anfrage an. In der Nutzlast muss angegeben sein, dass der L2-Operator aktiviert ist.

Übersetzungsanfragen mit mehr als 250 Zeichen führen zum Absturz von `translation-prediction-server`-Pods

Versionen: 1.13.3

Symptome: Wenn Sie Übersetzungsanfragen mit etwa 250 Zeichen oder mehr senden (einschließlich Anfragen zur Dokumentübersetzung), stürzen die translation-prediction-0- oder translation-prediction-1-Pods möglicherweise ab, sodass das Modell neu geladen werden muss. Das Neuladen des Modells erfolgt automatisch und kann etwa 30 Minuten dauern.

Dieses Problem ist auf eine Einschränkung der Übersetzungscontainer zurückzuführen.

Workaround: Teilen Sie Übersetzungsanfragen auf, sodass sie weniger als 250 Zeichen lang sind. Ein Bereich zwischen 200 und 250 Zeichen ist für alle Sprachen sicher. Wenn ein langer Request die Pods zum Absturz bringt, sind keine weiteren Maßnahmen erforderlich, um das Problem zu beheben.

`GPUAllocation` für den Cluster mit freigegebenen Diensten ist nicht richtig konfiguriert

Versionen: 1.13.3

Symptome: Vertex AI-Arbeitslasten können aufgrund fehlender GPU-Ressourcen nicht geplant werden. Wenn Sie beispielsweise Vertex AI-Dienstendpunkte nicht aufrufen oder aktivieren können, kann dies an einem Mangel an GPU-Ressourcen liegen.

Dieses Ressourcenproblem kann dadurch verursacht werden, dass für einige der GPUAllocation-Ressourcen im freigegebenen Dienstcluster die folgende Annotation fehlt:

processed: "true"

Problemumgehung:

Folgen Sie IAM-R0004, um die kubeconfig-Datei für g-ORG_NAME-shared-service-cluster zu generieren.

Listen Sie alle GPU-Zuweisungen im Dienstcluster auf, die nicht die Annotation processed: "true" haben:

kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

Die Ausgabe sieht etwa so aus:

zi-ad-bm08

Öffnen Sie die nicht zugewiesene Ressource GPUAllocation in einem Editor:
```
kubectl edit gpuallocation -n vm-system NODE_NAME
```
Bearbeiten Sie die GPU-Zuweisung basierend auf der Gesamtzahl der GPU-Zuweisungen im Dienstcluster:
- Wenn es nur eine benutzerdefinierte Ressource für die GPU-Zuweisung gibt, fügen Sie ihr die Annotation processed: "true" hinzu und ändern Sie die Spezifikation so:
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0
```
- Wenn es zwei benutzerdefinierte Ressourcen für die GPU-Zuweisung gibt, suchen Sie die ohne die Anmerkung processed: "true", fügen Sie die Anmerkung processed: "true" hinzu und ändern Sie die Spezifikation so, dass sie wie folgt aussieht:
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0
```
- Wenn es vier benutzerdefinierte Ressourcen für die GPU-Zuweisung gibt, suchen Sie die ohne die Annotation processed: "true", fügen Sie die Annotation processed: "true" hinzu und ändern Sie die Spezifikation so, dass sie wie folgt aussieht:
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0
```

Speichern Sie die Änderungen an der benutzerdefinierten Ressource GPUAllocation und prüfen Sie, ob der Zuweisungsstatus auf true aktualisiert wurde:

kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

Die Ausgabe sieht etwa so aus:

NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Beim Upgrade von Version 1.9.x auf Version 1.13.3 werden im OCLCM-Controller Fehler angezeigt

Versionen: 1.13.3

Symptome: Beim Upgrade von Version 1.9.x auf Version 1.13.3 werden möglicherweise Fehler für den OCLCM-Controller (Operable Component Lifecycle Management) für Vertex AI-Unterkomponenten angezeigt. Dieses Problem wird durch einen Fehler im ai_platform-Add-on-Job verursacht. Die Fehler, die Sie während des Upgrades erhalten, weisen darauf hin, dass OCLCM das Eigentum an diesen Vertex AI-Komponenten nicht übertragen kann.

Die folgenden Vertex AI-Komponenten sind im Administratorcluster der Organisation betroffen:

Name	Namespace
`aip-l1operator-deployment`	`ai-system`
`aip-l2operator-deployment`	`ai-system`
`aip-web-plugin-frontend`	`ai-system`
`aip-web-plugin-backend`	`ai-system`
`aip-l1operator-sa`	`ai-system`
`aip-l2operator-sa`	`ai-system`
`aip-web-plugin-sa`	`ai-system`
`aip-l1operator-role`	–
`aip-l2operator-role`	–
`aip-web-plugin-role`	–
`aip-l1operator-rolebinding`	–
`aip-l2operator-rolebinding`	–
`aip-web-plugin-rolebinding`	–
`aip-l1operator-log`	`ai-system`
`aip-l2operator-log`	`ai-system`
`aip-web-plugin-frontend-log`	`ai-system`
`aip-web-plugin-backend-log`	`ai-system`
`log-rule-aipl-a004`	`platform-obs`
`mon-rule-aipl-a0001`	`platform-obs`
`mon-rule-aipl-a0003`	`platform-obs`
`aip-l1operator-mon`	`ai-system`
`aip-l1operator-mon-cm`	`ai-system`
`aip-l2operator-mon`	`ai-system`
`aip-l2operator-mon-cm`	`ai-system`
`aip-l1operator-webhook-svc`	`ai-system`
`aip-web-plugin-frontend-svc`	`ai-system`
`aip-web-plugin-backend-svc`	`ai-system`
`aip-web-plugin-frontend-virtualsvc`	`ai-system`
`aip-web-plugin-backend-virtualsvc`	`ai-system`
`aip-l1operator-selfsigned-issuer`	`ai-system`
`aip-l1operator-serving-cert`	`ai-system`
`aip-l1operator-validating-webhook`	`ai-system`
`aip-l1operator-mutating-webhook`	`ai-system`

Problemumgehung: Um dieses Problem zu beheben, müssen Sie die betroffenen Vertex AI-Komponenten manuell aus dem Cluster des Organisationsadministrators entfernen. Anschließend werden sie durch die neue OCLCM-basierte Version von Vertex AI neu installiert.

Entfernen Sie die betroffenen Vertex AI-Komponenten im Administratorcluster der Organisation manuell:

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Ersetzen Sie Folgendes:

ORG_ADMIN_CLUSTER_KUBECONFIG: der Pfad zur kubeconfig-Datei im Administratorcluster der Organisation.
NAMESPACE: Der Namespace der Vertex AI-Komponente, die Sie entfernen möchten. Wenn die Komponente keinen Namespace hat, entfernen Sie -n NAMESPACE aus dem Befehl.
COMPONENT_NAME: Der Name der Vertex AI-Komponente, die Sie entfernen möchten.

Das folgende Beispiel zeigt, wie Sie die Komponente aip-l1operator-deployment entfernen, die sich im Namespace ai-system im Administratorcluster der Organisation befindet:

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

Bei Übersetzungsanfragen kann der Fehlercode `RESOURCE_EXHAUSTED` ausgegeben werden

Versionen: 1.13.3

Symptome: Nach dem Senden einer Übersetzungsanfrage erhalten Sie in der Antwortnachricht den Fehlercode RESOURCE_EXHAUSTED. Dieser Fehler tritt auf, wenn Sie ein Systemfrequenzlimit überschreiten. Eine Ressource, z. B. ein nutzerbezogenes Kontingent, ist erschöpft oder der Speicherplatz für das gesamte Dateisystem ist ausgegangen.

Problemumgehung: Bitten Sie Ihren Infrastrukturbetreiber, die Backend-Shards des Übersetzungsdienstes neu zu starten. Senden Sie dann wieder Übersetzungsanfragen, aber mit längeren Verzögerungen zwischen den Anfragen oder mit kürzeren Anfragen.

`batchTranslateDocument`Anfragen geben Fehler zurück`503`

Versionen: 1.13.3

Symptome: Nach dem Senden einer batchTranslateDocument-Anfrage erhalten Sie in der Antwortnachricht den Fehlercode 503 "Batch Document translation is not implemented". Dieser Fehler tritt auf, weil für die Methode BatchTranslateDocument der Aspose-Dienst erforderlich ist, der nur bereitgestellt wird, wenn der operable-Parameter enableRAG im Cluster auf true festgelegt ist.

Behelfslösung: Bitten Sie Ihren Infrastruktur-Operator (IO), den operable-Parameter enableRAG im Administratorcluster der Organisation auf true zu setzen. Gehen Sie dazu so vor:

Erstellen Sie eine benutzerdefinierte Ressource vom Typ SubcomponentOverride in einer YAML-Datei mit dem Namen vai-translation.yaml, wobei der operable-Parameter enableRAG auf true gesetzt ist:
```
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: "vai-translation"
  namespace: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true
```
Ersetzen Sie ORG_ADMIN_NAMESPACE durch den Namespace des Organisationsadministratorclusters.
Wenden Sie die benutzerdefinierte Ressource SubcomponentOverride auf den Administratorcluster der Organisation an:
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml
```
Ersetzen Sie ORG_ADMIN_KUBECONFIG durch den Pfad zur kubeconfig-Datei im Administratorcluster der Organisation.

Vortrainierte Vertex AI-Dienste nicht verfügbar

Versionen: 1.13.7, 1.13.9

Symptome: Die Vertex AI-Dienste für OCR und Übersetzung können aufgrund von Kubernetes-Planungsproblemen nicht gestartet werden. Möglicherweise wird in den Protokollen eine Warnung wie diese angezeigt:

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Problemumgehung: Fügen Sie dem Standardpool weitere Worker-Knoten hinzu und entfernen Sie die Pods auf den GPU-Knoten, damit die KI-Arbeitslasten geplant werden können.

Virtuelle Maschinen

BYO-Image-Import schlägt für qcow2- und RAW-Images fehl

Versionen: 1.13.1, 1.13.3

Symptome: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 zum Übersetzen oder Importieren erstellt wird, genau die gleiche Größe wie das qcow2-/Rohbild hat. LUKS fügt jedoch einen Overhead von einigen MiB hinzu, wodurch die Laufwerkbereitstellung fehlschlägt.

Workaround:

Erstellen Sie manuell ein neues VirtualMachineImageImport mit demselben Bildnamen, aber mit einem größeren spec.minimumDiskSize.

Wenn das Image beispielsweise mit diesem Befehl importiert wurde:

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

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

Suchen Sie nach VirtualMachineImageImport:
```
kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml
```
Wenn das Objekt nicht vorhanden ist, lösen Sie den Befehl gdcloud compute images import ... noch einmal aus. Sobald 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 als Referenz für die Erstellung einer neuen beibehalten wird.

Erstellen Sie eine neue VirtualMachineImageImport mit einem größeren minimumDiskSize:

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

Bereitstellung eines Laufwerks aus einem Image schlägt fehl

Versionen: 1.13.1, 1.13.3

Symptome: Bei der Bereitstellung eines Laufwerks aus einem benutzerdefinierten Image ist die minimumDiskSize möglicherweise zu nah an der virtuellen Größe, was dazu führt, dass die Laufwerkbereitstellung fehlschlägt. Das VM-Laufwerk befindet sich im Status „Ausstehend“, wird aber nie bereitgestellt.

Problemumgehung: Erstellen Sie manuell ein neues Laufwerk mit einem größeren spec.minimumDiskSize.

Das NVIDIA-Geräte-Plug-in `DaemonSet` schlägt fehl, wenn ein Cluster GPUs hat

Versionen: 1.13.3

Symptome: Das NVIDIA-Geräte-Plug-in DaemonSet schlägt mit der Meldung driver rpc error auf Clusternodes mit GPUs fehl:

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei im Cluster.

Die Ausgabe sollte in etwa so aussehen:

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

Dieses Problem führt dazu, dass GPUs für virtuelle Maschinen (VMs) und Pods nicht verfügbar sind. Die Auswirkungen basieren auf den folgenden Clustertypen:

Systemcluster: Die benutzerdefinierte GPUAllocation-Ressource wird für diesen Bare-Metal-Knoten nicht erstellt und die GPUs in diesem Knoten werden nicht im VM-Modus für die Nutzung durch den Dienst- und Nutzercluster konfiguriert. Informationen zur Behebung dieses Problems finden Sie hier.
Dienst- oder Nutzercluster: Die benutzerdefinierte GPUAllocation-Ressource wird für diesen VM-Knoten nicht erstellt und die GPUs in diesem Knoten können nicht von Pods im Cluster verwendet werden. Informationen zur Behebung dieses Problems finden Sie im Workaround für den Dienst- oder Nutzercluster.

Workaround für den Systemcluster:

Gehen Sie so vor, um das Problem im Systemcluster zu beheben:

Legen Sie die Umgebungsvariable KUBECONFIG auf den Pfad zur kubeconfig-Datei im Systemcluster fest. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Ermitteln Sie den Knoten, auf dem das Problem auftritt:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
In der Ausgabe müssen der Knotenname und die IP-Adresse des Kubernetes-Knotens ausgegeben werden.

Wenn mehrere Knoten vorhanden sind, führen Sie die Schritte auf allen aus. In diesem Fall sieht die Ausgabe so aus:
```
Node:                 yy-ab-bm04/172.20.128.26
```
Legen Sie die Umgebungsvariable NODE_NAME mit dem Knotennamen fest, z. B.:
```
export NODE_NAME=yy-ab-bm04
```
Stellen Sie eine SSH-Verbindung zum Knoten her. Weitere Informationen finden Sie im PLATAUTH-G0001-Runbook.

Hinweis: Die IP-Adresse des Verwaltungs-Nodes unterscheidet sich von der IP-Adresse des vorherigen Befehls. Verwenden Sie die IP-Adresse des Verwaltungs-Nodes, wie im Runbook beschrieben.

Prüfen Sie, ob der Knoten GPUs hat:

nvidia-smi -L

In der Ausgabe müssen die GPUs im Knoten wie im folgenden Beispiel ausgegeben werden:

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

Aktivieren Sie den Persistenzmodus auf den GPUs:
```
nvidia-smi -pm 1
```
Dadurch wird sichergestellt, dass die NVIDIA-Treiber immer geladen werden, sodass für das Geräte-Plug-in kein Zeitlimit überschritten wird.

Die Ausgabe muss wie im folgenden Beispiel aussehen:
```
Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.
```
Hinweis :Der Persistenzmodus ist für den aktuellen Start aktiviert. Diese Aktion wird beim nächsten Neustart rückgängig gemacht. Wenn das Problem nach dem Neustart weiterhin besteht, wiederholen Sie diese Schritte.
Beenden Sie die SSH-Sitzung:
```
exit
```

Prüfen Sie, ob das Geräte-Plug-in ausgeführt wird. Fragen Sie dazu DaemonSet ab:

kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Prüfen Sie, ob die benutzerdefinierte Ressource GPUAllocation erstellt und im VM-Modus konfiguriert wurde:

kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

Die Ausgabe muss wie im folgenden Beispiel aussehen:

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

Problemumgehung für den Dienst oder Nutzercluster:

Gehen Sie so vor, um das Problem im Dienst oder Cluster zu beheben:

Legen Sie die Umgebungsvariable KUBECONFIG mit dem Pfad zur kubeconfig-Datei im Dienst- oder Nutzercluster fest. Weitere Informationen finden Sie im IAM-R0004-Runbook.
Ermitteln Sie den Knoten, auf dem das Problem auftritt:
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
In der Ausgabe müssen der Knotenname und die IP-Adresse des Kubernetes-Knotens ausgegeben werden.

Wenn mehrere Knoten vorhanden sind, führen Sie die Schritte auf allen aus. In diesem Fall sieht die Ausgabe so aus:
```
Node:                 vm-948fa7f4/172.20.128.21
```
Legen Sie die Umgebungsvariable NODE_NAME mit dem Knotennamen fest, z. B.:
```
export NODE_NAME=vm-948fa7f4
```
Stellen Sie eine SSH-Verbindung zum Knoten her. Weitere Informationen finden Sie im PLATAUTH-G0001-Runbook.

Hinweis: Die IP-Adresse des Verwaltungs-Nodes unterscheidet sich von der IP-Adresse des vorherigen Befehls. Verwenden Sie die IP-Adresse des Verwaltungs-Nodes, wie im Runbook beschrieben.

Prüfen Sie, ob der Knoten GPUs hat:

nvidia-smi -L

In der Ausgabe müssen die GPUs im Knoten wie im folgenden Beispiel ausgegeben werden:

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

Aktivieren Sie den Persistenzmodus auf den GPUs:
```
nvidia-smi -pm 1
```
Dadurch wird sichergestellt, dass die NVIDIA-Treiber immer geladen werden, sodass für das Geräte-Plug-in kein Zeitlimit überschritten wird.

Die Ausgabe muss wie im folgenden Beispiel aussehen:
```
Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.
```
Hinweis :Der Persistenzmodus ist für den aktuellen Start aktiviert. Diese Aktion wird beim nächsten Neustart rückgängig gemacht. Wenn das Problem nach dem Neustart weiterhin besteht, wiederholen Sie diese Schritte.
Beenden Sie die SSH-Sitzung:
```
exit
```

Prüfen Sie, ob das Geräte-Plug-in ausgeführt wird. Fragen Sie dazu DaemonSet ab:

kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Prüfen Sie, ob die benutzerdefinierte Ressource GPUAllocation erstellt und im VM-Modus konfiguriert wurde:

kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

Die Ausgabe muss wie im folgenden Beispiel aussehen:

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

VM des Systemclusters nicht bereit

Versionen: 1.13.3

Symptome: Die VM des Systemclusters ist nicht bereit. Möglicherweise wird eine Meldung wie diese angezeigt:

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

Problemumgehung:

Suchen Sie nach VirtualMachineInstance und löschen Sie es.
Neue VM neu starten

Berichte zum Datenvolumen: Scratch-Speicherplatz nicht gefunden

Versionen: 1.13.3, 1.13.4

Symptome: Beim Erstellen eines VM-Laufwerks wird das Datenvolume als erfolgreich gemeldet:

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Ein Import-Pod wie importer-gdc-vm-disk-vm-ce34b8ea-disk kann jedoch in einer Schleife abstürzen und eine Meldung wie diese ausgeben:

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

Problemumgehung: Löschen Sie den Importer-Pod, nachdem Sie bestätigt haben, dass der Status des Datenvolumens Succeeded ist.

VMs in Projekten mit Namen, die länger als 45 Zeichen sind, bleiben im Status „Beendet“

Versionen: 1.13.5

Symptome: Beim Erstellen einer VM bleibt die VM im Status Stopped, wenn der Projektname mehr als 45 Zeichen hat.

Problemumgehung: Erstellen Sie ein Projekt mit einem Namen, der nicht länger als 45 Zeichen ist.

GPU-Zuweisung im Dienstcluster fehlt

Versionen: 1.13.5

Symptome: Die GPUAllocation fehlt im Shared Service-Cluster von gpu-org. Beim Abrufen der GPU-Zuweisungen wird möglicherweise eine Meldung angezeigt:

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

Sie erhalten folgende Ausgabe:

No resources found

Problemumgehung:

Fügen Sie dem GPU-Knoten eine Markierung hinzu:

taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

Entfernen Sie die Markierung, um die Planung des virt-launcher-Pods der VM zu ermöglichen.

Worker-VM des Shared-Service-Clusters kann nicht geplant werden

Versionen: 1.13.6

Symptome: Eine Kubernetes-Worker-VM konnte aufgrund unzureichender CPU-Ressourcen auf dem zugewiesenen Knoten nicht geplant werden, obwohl GPUs verfügbar waren. Ein solches Ereignis könnte so aussehen:

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

Problemumgehung:

Beenden Sie VMs ohne GPU manuell, um CPU-Ressourcen freizugeben.
Nachdem die ausstehende VM geplant wurde, starten Sie die Nicht-GPU-VMs.

Bekannte Probleme mit Google Distributed Cloud mit Air Gap 1.13.x Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Artifact Registry

Abstimmungsfehler bei der Unterkomponente sar-failoverregistry

Sichern und wiederherstellen

Snapshots schlagen aufgrund von zu wenig Speicherplatz fehl

Agent- und Steuerungsebenen-Pods werden aufgrund von Speichermangel neu gestartet

Sicherung für PVC-Snapshot schlägt fehl

Wiederherstellen aus einer Sicherung, die nicht mit dem SVM-Kontingent kompatibel ist

Abrechnung

Abrechnungsbezogene Messwerte werden im Abrechnungsdashboard nicht richtig angezeigt

Nutzer kann BillingAccountBinding aufgrund von Fehlern im Validierungs-Webhook nicht erstellen

Blockspeicher

Grafana-Pods bleiben aufgrund von Fehlern beim Einbinden von Volumes im Status Init hängen.

Launcher-Pods für virtuelle Maschinen können keine Volumes zuordnen

Speicherbezogene Fehler

Nichtflüchtige Volumes mit falscher Größe erstellt

Virtuelle Speichermaschine kann nicht gelöscht werden

Durch Deaktivieren der Organisation werden Ressourcen nicht bereinigt

Fehler beim Abgleich des Löschens

Bare-Metal-Upgrade bleibt hängen

Fehler beim Anhängen mehrerer Dateien in Trident

Fehler in der IPsec-Konfiguration

Die virtuelle Storage-Maschine wird nicht erstellt

Abstimmung von Storage-Intercluster-Netzwerken fehlgeschlagen

Clusterverwaltung

machine-init-Job schlägt während der Clusterbereitstellung fehl

Keine Verbindung vom Dienstcluster zum Object Storage-Bucket

Preflight-Prüfung fehlgeschlagen

Erstellung des Worker-Knotenpools des Nutzerclusters schlägt fehl

Neu erstellte Nutzercluster bleiben aufgrund einer nicht ordnungsgemäßen Bereinigung möglicherweise beim Abgleich hängen.

Datenbankdienst

Klonen der AlloyDB Omni-Datenbank bleibt hängen

Die Erzwingung von IOPS wirkt sich auf die Speicherleistung aus

Abstimmungsfehler beim Upgrade der Unterkomponente dbs-fleet

Fehler beim Erstellen von DBCluster

DNS

DNSSEC muss in „resolved.conf“ explizit deaktiviert werden.

Hafenservice

Fehler beim Erstellen des Harbor-Dienstes

Durch das Löschen von Harbor-Instanzen werden die zugehörigen Registry-Spiegel nicht gelöscht.

Hardwaresicherheitsmodul

Deaktivierte HSM-Testlizenzen sind weiterhin erkennbar

HSM-Host-Daemon-Dateideskriptor-Datenleck

HSM-Zertifikate abgelaufen

Identitäts- und Zugriffsverwaltung

gatekeeper-audit-Pods im Namespace opa-system werden häufig neu gestartet

Infrastruktur als Code (IaC)

Durch das Erstellen einer großen Anzahl von GitLab-Tokens besteht das Risiko, dass die GitLab-Datenbanken gefüllt werden.

Schlüsselverwaltungssystem (KMS)

Wenn Sie den Typ des Stammschlüssels ändern, werden alle vorhandenen Schlüssel ungültig.

kms-rootkey-controller CrashLoopBackOff aufgrund von OOMKILL

Logging

Der Audit-Logger für Objektspeicher kann den DNS-Host nicht auflösen

HaaS Logger zeigt Fehler im Root-Administratorcluster an

Santricity Logger schlägt fehl

Logging Target-Logs werden an das falsche Projekt gesendet

Audit-Logs aus dem Plattform-Namespace sind für den PA nicht sichtbar.

Pods können Container nicht initialisieren

Marketplace

Fehler beim Abrufen von Prisma Cloud-Images

Monitoring

Es werden sehr viele Benachrichtigungen in ServiceNow erstellt

Es wurden mehrere doppelte Benachrichtigungen in ServiceNow erstellt

Vertex AI-Messwerte können nicht angezeigt werden

Abgleichsfehler in mon-cortex

Der metrics-server-exporter-Pod im Systemcluster befindet sich in einer Absturzschleife.

ObservabilityPipeline-Abstimmungsfehlermeldungen ignorieren

Die mon-prober-backend-prometheus-config-ConfigMap wird zurückgesetzt

Cortex Store Gateway-Komponente – OOMKilled-Crashloop

Kube-Steuerungsebene – Pullbackoff für Proxy-Image in Nutzercluster

Durch ein Wachstum des WAL verwendet Prometheus viel Arbeitsspeicher

Bootstrap in mehreren Zonen

Fehlende Clusterrollen

Inkompatible Bootstrap-Ressource

Die GlobalAPIZone-Ressource wird nicht in der globalen API erstellt.

Netzwerk

Objektspeicherknoten – Grid-Netzwerk ausgefallen

Knoten nicht erreichbar

PodCIDR ist Knoten nicht zugewiesen, obwohl ClusterCIDRConfig erstellt wurde

NTP-Drift

Bekannte Probleme mit Google Distributed Cloud mit Air Gap 1.13.x

Abstimmungsfehler bei der Unterkomponente `sar-failoverregistry`

Nutzer kann `BillingAccountBinding` aufgrund von Fehlern im Validierungs-Webhook nicht erstellen

Grafana-Pods bleiben aufgrund von Fehlern beim Einbinden von Volumes im Status `Init` hängen.

`machine-init`-Job schlägt während der Clusterbereitstellung fehl

Abstimmungsfehler beim Upgrade der Unterkomponente `dbs-fleet`

`gatekeeper-audit`-Pods im Namespace `opa-system` werden häufig neu gestartet

`kms-rootkey-controller` `CrashLoopBackOff` aufgrund von `OOMKILL`

Abgleichsfehler in `mon-cortex`

Der `metrics-server-exporter`-Pod im Systemcluster befindet sich in einer Absturzschleife.

`ObservabilityPipeline`-Abstimmungsfehlermeldungen ignorieren

Die `mon-prober-backend-prometheus-config`-ConfigMap wird zurückgesetzt

Inkompatible `Bootstrap`-Ressource

Die `GlobalAPIZone`-Ressource wird nicht in der globalen API erstellt.

`PodCIDR` ist Knoten nicht zugewiesen, obwohl `ClusterCIDRConfig` erstellt wurde

`ObjectStorageStorageNodeReconciler` Berichte `maintenance.gdu.gdu_server_locked`

Pods bleiben im Status `init`

`bm-system-machine-preflight-check` Ansible-Job für einen Bare-Metal- oder VM-Knoten schlägt fehl

Pods bleiben im Status `ContainerCreating`

`bm-system` und andere Jobs hängen fest

Die Versionsnummer für `storagecluster` wird nicht angezeigt

`OrganizationUpgrade` bleibt beim Knotenupgrade hängen

Fehler `Incorrect version of Trident` wird während des Upgrades angezeigt

Fehler beim Upgrade der Unterkomponente `iac-zoneselection-global`

Das `meta-monitoring`-Add-on schlägt fehl, weil sich der strongswan-Speicherort in einem anderen Laufzeitverzeichnis befindet.

Das Upgrade der Mandantenorganisation schlägt in der Preflight-Prüfungsphase mit `ErrImagePull` fehl

`serviceaccount` konnte während des Upgrades der Stammorganisation nicht gefunden werden

Upgrade schlägt auf `shared-service-cluster upgrade` fehl

Installation des Add-ons „`system-dashboards`“ fehlgeschlagen

`NodeUpgradeTask` CR hängt bei der Bedingung `NodeOSInPlaceUpgradePostProcessingCompleted` fest

Namespaces `platform-obs-obs-system` oder `platform-obs` bleiben im Beendigungsstatus hängen

`NodeUpgradeTask` CR hängt bei der Bedingung `NodeBIOSFirmwareUpgradeCompleted` fest

Zeitüberschreitung während des anfänglichen Root-Vorgangs `organizationupgrade`

Für die Unterkomponente `obj-syslog-server` schlägt der Abgleich in der Stammorganisation fehl

ABM- oder Knotenupgrade bleibt bei `maintenanceMode false` hängen