Diese Seite wurde von der Cloud Translation API übersetzt.

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

Sichern und wiederherstellen

Bearbeiten des Wiederherstellungsplans für Clustersicherungen ist nicht möglich

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptome:

Die benutzerdefinierte RestorePlan-Ressource kann nicht über die GDC-Konsole bearbeitet werden.

Workaround:

Erstellen Sie entweder einen neuen Wiederherstellungsplan und löschen Sie den alten oder bearbeiten Sie den Wiederherstellungsplan mit der kubectl CLI.

Ungültige Größe des Quelllaufwerks

Versionen: 1.14.4, 1.14.5

Symptome:In der Benutzeroberfläche wird die Größe eines Laufwerks fälschlicherweise als 0 MB und die Erstellungszeit als „Unbekannt“ angezeigt. Das liegt an einer Änderung des Backend-Datenmodells nach der Migration zur V2-Organisationsarchitektur.

Problemumgehung:Es gibt keine alternative Methode, um diese Informationen über die Benutzeroberfläche aufzurufen.

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

Versionen:1.14.3, 1.14.4

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.

SLOs für Sicherung und Wiederherstellung werden nicht angewendet

Versionen:1.14.3, 1.14.4

Symptome:Die Messwerte und Benachrichtigungen für das GDC-Service Level Objective (SLO) sind nicht standardmäßig konfiguriert, da die erforderliche benutzerdefinierte Ressourcendefinition nicht installiert ist. Diese Benachrichtigungen werden in Grafana verwendet.

Problemumgehungen:Wenn Sie SLOs für die Sicherung und Wiederherstellung in GDC aktivieren möchten, folgen Sie dem BACK-T0001-Runbook.

Aufbewahrungsrichtlinien werden nicht auf importierte Sicherungen angewendet

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

Symptome:Wenn Sie ein Sicherungs-Repository an den Cluster anhängen, werden alle Sicherungs- und Wiederherstellungsmetadaten synchronisiert und die Repositorys werden als importierte Sicherungen behandelt. Diese importierten Sicherungen werden während der Abstimmung fälschlicherweise übersprungen. Das bedeutet, dass Aufbewahrungsrichtlinien ignoriert und Sicherungen auf unbestimmte Zeit beibehalten werden.

Problemumgehung:Importierte Sicherungen sind mit backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME gekennzeichnet. Wenn Sie den normalen Abgleich und die Anwendung von Aufbewahrungsrichtlinien zulassen möchten, entfernen Sie das Label mit den folgenden kubectl-Befehlen aus den Back-ups:

Legen Sie die erforderlichen Umgebungsvariablen fest:
```
export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE
```
Ersetzen Sie Folgendes:
- KUBECONFIG: Der Pfad zur kubeconfig-Datei.
- BACKUP_REPOSITORY_NAME: der Name des Sicherungs-Repositorys.
- NAMESPACE: der Namespace, der den Sicherungsplan enthält.

Alle importierten Sicherungen auflisten:

kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME

Entfernen Sie die Labels nach Bedarf:

Entfernen Sie die Labels aus allen Sicherungen:

kubectl get backups.backup.gdc.goog -l
backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
-o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
$NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-

Labels für eine einzelne Sicherung entfernen:

export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
$NAMESPACE backup.gdc.goog/imported-repository-

Teilweise VM-Sicherung schlägt fehl

Versionen: 1.14.3, 1.14.4

Symptome: Wenn die Sicherung einer von vielen VMs fehlschlägt, wird die gesamte VM-Sicherung als fehlgeschlagen markiert.

Problemumgehung: Beschränken Sie die Anzahl der VMs pro Sicherungsplan.

Verwaiste Sicherungsressourcen nach dem Löschen von Nutzer- oder Dienstclustern bereinigen

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptome: Wenn ein Nutzer- oder Dienstcluster gelöscht wird, werden die zugehörigen Backup-Agent-Ressourcen (z. B. StatefulSet, Pods, Secret usw.), die im Infrastruktur- und Verwaltungscluster der Organisation erstellt wurden, nicht automatisch bereinigt. Dadurch können verwaiste Ressourcen entstehen. Wenn der Cluster mit demselben Namen noch einmal erstellt wird, funktioniert der Backup-Agent-Pod nicht.

Problemumgehung: Die verwaisten Ressourcen befinden sich in einem dedizierten Namespace im Infrastrukturcluster der Organisation. Um sie zu bereinigen, müssen Sie diesen Namespace löschen.

Legen Sie die kubeconfig-Dateien für die Infrastruktur- und Verwaltungscluster der Organisation fest.

export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

Ermitteln Sie den Namespace der verwaisten Ressourcen. Der Namespace folgt dem Muster gpc-backup-<cluster-name>-system. Beispiel:
- gpc-backup-user-vm-1-cluster-system
- gpc-backup-user-vm-2-cluster-system
- gpc-backup-g-org-1-shared-service-cluster-system

Löschen Sie den Namespace. Dadurch werden alle Ressourcen darin gelöscht, einschließlich des StatefulSet und des Pods des Sicherungs-Agents im Infrastruktur- und des Secrets im Verwaltungscluster.

# Replace <namespace-name> with the actual namespace
kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"

Führen Sie den Befehl get all noch einmal aus, um zu prüfen, ob die Bereinigung erfolgreich war.
```
# Replace <namespace-name> with the actual namespace
kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
Der Befehl sollte jetzt fehlschlagen, da der Namespace nicht mehr vorhanden ist. Es sollte ein Fehler wie Error from server (NotFound): namespaces "<namespace-name>" not found angezeigt werden.

Das Löschen von VirtualMachineRestore wird über die CLI oder die Benutzeroberfläche nicht unterstützt.

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptome: Der VirtualMachineRestore-Controller bereinigt die zugrunde liegenden Ressourcen (VolumeRestore, Restore) beim Löschen einer VirtualMachineRestore-Ressource nicht automatisch. In diesem Fall ist eine manuelle Bereinigung erforderlich. Dies gilt unabhängig davon, ob Sie kubectl delete oder die Benutzeroberfläche zum Löschen verwenden.

Problemumgehung: Löschen Sie die abhängigen Ressourcen manuell in der richtigen Reihenfolge und entfernen Sie dann den Finalizer aus der VirtualMachineRestore-Ressource.

Legen Sie die kubeconfig-Datei so fest, dass sie auf den Verwaltungscluster verweist.
```
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
```

Identifizieren Sie das zu löschende VirtualMachineRestore und seinen Namespace.

export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
export NAMESPACE=<namespace-of-vm-restore>

Suchen Sie die zugehörigen VolumeRestore-Ressourcen und löschen Sie sie. Sie werden mit einem Label erstellt, das sie mit dem VirtualMachineRestore verknüpft.

# Find and delete all associated VolumeRestores.
kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

Suchen Sie die zugehörigen Restore-Ressourcen und löschen Sie sie. Sie werden mit einem Label erstellt, das sie mit dem VirtualMachineRestore verknüpft.

# Find and delete all associated Restores.
kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

Führen Sie nun kubectl delete aus, falls noch nicht geschehen, und entfernen Sie den Finalizer aus der VirtualMachineRestore-Ressource. Dies ist der letzte Schritt, der es dem Kubernetes-Garbage Collector ermöglicht, die Ressource zu löschen.
```
kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
```

Bestätigen Sie den Löschvorgang.

kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

Der Befehl sollte einen NotFound-Fehler zurückgeben, der bestätigt, dass die Ressource gelöscht wurde.

Der Sicherungs-Steuerungsebenen-Pod stürzt aufgrund von unzureichendem Arbeitsspeicher ab

Versionen: 1.14.4 und höher

Symptome:Der gpcbackup-controlplane-controller-Pod im Systemnamespace gpc-backup des Infrastrukturclusters der Organisation hat den Status CrashLoopBackOff. Wenn dieser Fehler auftritt, schlagen Sicherungs- und Wiederherstellungsvorgänge fehl, reagieren nicht mehr oder funktionieren nicht wie erwartet.

Problemumgehung:Erhöhen Sie die Speicherlimits für die gpcbackup-controlplane-controller-Bereitstellung gemäß BACK-R0005. Bei dieser Methode wird ein SubcomponentOverride verwendet, um die CPU- und Speicheranforderungen und ‑limits anzupassen.

Löschung des Nutzerclusters hängt

Versionen: 1.14.7 und höher

Symptome:Cluster bleiben aufgrund von Finalizer-Problemen im Status „Wird gelöscht“ hängen.

Problemumgehung: Prüfen Sie, ob Speicher-Volumes SnapMirror-Beziehungen haben, bevor Sie den Cluster löschen. Weitere Informationen finden Sie unter BACK-R0109.

Die Wiederherstellung hängt aufgrund eines ausstehenden Anspruchs auf ein nichtflüchtiges Volume fest

Versionen: 1.14.3 und höher

Symptome:PVC-Controller (PersistentVolumeClaim) können manchmal nicht mit Sicherungs-Agents im Infrastrukturcluster der Organisation kommunizieren. Dieses Problem hat zwar keine Auswirkungen auf die Sicherungsfunktion, kann aber dazu führen, dass ein Volume-Wiederherstellungsvorgang im Status Pending hängen bleibt und schließlich das Zeitlimit überschritten wird. Dieses Problem betrifft Wiederherstellungsvorgänge, bei denen ein Volume wiederhergestellt wird, z. B. die Wiederherstellungsfunktion des Database Service zum Klonen und die Wiederherstellung einer Nutzerarbeitslast.

Wenn dieses Problem auftritt, schlagen nachfolgende Wiederherstellungsvorgänge im betroffenen Cluster fehl, bis Sie den entsprechenden Sicherungsagenten manuell neu starten.

Um zu bestätigen, dass Ihr Problem mit der Wiederherstellung mit diesem spezifischen Problem zusammenhängt, müssen Sie die Logs des Sicherungs-Agents untersuchen:

Folgen Sie IAM-R0005, um die erforderliche BACK Debugger-Rolle (back-cluster-debugger) zu erhalten, indem Sie die ExpirationClusterRoleBinding-Ressource anwenden.
Folgen Sie IAM-R0004, um die kubeconfig-Datei für den Infrastrukturcluster der Organisation zu generieren. Alle Sicherungs-Agents werden im Infrastrukturcluster der Organisation ausgeführt.

Ermitteln Sie den Sicherungs-Agenten, der die Wiederherstellung ermöglicht:

kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
    --all-namespaces | grep gpcbackup-agent

Ersetzen Sie ORG_INFRA_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Infrastrukturclusters der Organisation.

Die Ausgabe sieht etwa so aus:

NAMESPACE                                          NAME                                     READY   AGE
gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
gpc-backup-system                                  gpcbackup-agent                          1/1     22d
gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d

Lesen Sie sich die Ausgabe durch und ermitteln Sie den Sicherungs-Agent, der Ihrer Wiederherstellung entspricht. Wenn der betroffene StatefulSet-Namespace in der Ausgabe beispielsweise gpc-backup-user-vm-1-cluster-system ist, lautet der Name des Sicherungs-Agents gpcbackup-agent-user-vm-1.

Suchen Sie in den StatefulSet-Logs nach der Fehlermeldung, um das Problem zu bestätigen:
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
```
Ersetzen Sie Folgendes:
- ORG_INFRA_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Infrastrukturclusters der Organisation.
- BACKUP_AGENT: der Sicherungs-Agent, den Sie im vorherigen Schritt identifiziert haben.
- NAMESPACE: Der Namespace, den Sie im vorherigen Schritt identifiziert haben.
Wenn passende Logs vorhanden sind, liegt dieses bekannte Problem vor.

Problemumgehung: So umgehen Sie das Problem:

Starten Sie den Sicherungs-Agent neu:
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE
```
Ersetzen Sie Folgendes:
- ORG_INFRA_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Infrastrukturclusters der Organisation.
- BACKUP_AGENT: der Sicherungs-Agent, den Sie bei der Bestätigung des Problems identifiziert haben.
- NAMESPACE: der Namespace, den Sie beim Bestätigen des Problems identifiziert haben.
Die Ausgabe sieht etwa so aus:
```
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
```
Warten Sie bis zu 20 Minuten, bis ausstehende Vorgänge automatisch fortgesetzt werden.

Sie können eine weitere Wiederherstellung für denselben Zielcluster durchführen, nachdem der Neustart des Sicherungs-Agents abgeschlossen ist. Nachdem Sie diesen Workaround ausgeführt haben, gibt es keine Nebenwirkungen. Dieser Workaround muss nur einmal pro betroffenen Cluster ausgeführt werden.

Clusterverwaltung

Die Unterkomponente „`kub-gpu-controller`“ wird nicht abgeglichen

Versionen: 1.14.3

Symptome:Die untergeordnete Komponente g-gdchservices-shared-service-cluster/kub-gpu-controller in der Organisation gdchservices wird nicht abgeglichen. Die folgende Ausgabe wird zurückgegeben:

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

Dieser Fehler verhindert, dass GPU-Maschinen in der Organisation gdchservices gestartet werden.

Problemumgehung:Führen Sie ein Upgrade auf Version 1.14.4 oder höher durch, um das Problem zu beheben.

Knotenpool kann nicht aus Standardcluster entfernt werden

Versionen: 1.14.3, 1.14.4, 1.14.5

Behoben: 1.14.6

Symptome:Das Entfernen veralteter Knotenpools aus Standardclustern schlägt fehl und die Knotenpools werden nicht innerhalb des erwarteten Zeitrahmens gelöscht. Standardcluster befinden sich in der privaten Vorschau und sind möglicherweise nicht für alle Kunden verfügbar.

Problemumgehung:Entfernen Sie veraltete Knotenpools manuell.

Cluster hängt im Status „Wird gelöscht“ fest

Versionen: 1.14.6 und höher

Symptome:Beim Löschen eines Kubernetes-Clusters kann es vorkommen, dass er im Status Deleting hängen bleibt. Prüfen Sie den Status Ihres Clusters mit dem folgenden Befehl:

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

Die Ausgabe sieht etwa so aus:

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

Sie können das Problem auch prüfen, indem Sie den Status des Clusternamespace prüfen:

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

Die Ausgabe sieht etwa so aus:

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

Der Clusternamespace befindet sich im Status Terminating und die Bedingungen NamespaceContentRemaining und NamespaceFinalizersRemaining sind auf True festgelegt.

Problemumgehung: So umgehen Sie das Problem:

Patchen Sie die API für Weiterleitungsregeln:

kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'

Patchen Sie die API für Backend-Dienste:

kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'

Datenbankdienst

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

Klonen der AlloyDB Omni-Datenbank bleibt hängen

Versionen: 1.14.6 und früher

Behoben: 1.14.7

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.

DNS

„GlobalCustomerRootDNSServerNotReachable“ löst fälschlicherweise eine Benachrichtigung aus

Versionen:1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7, 1.14.8

Symptome:Die DNS-Benachrichtigung DNS-A0021 wird ausgelöst und deutet auf GlobalCustomerRootDNSServerNotReachable hin. Die Probe-CR für global-customer-root-dns in org-mp enthält nicht egress: true in der Spezifikation.

Workaround:

Legen Sie den KUBECONFIG-Pfad für org-mgmt fest:

export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG

Pausieren Sie die Antwortvorlage für die core-mz-Unterkomponente:

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true

Bearbeiten Sie die aktuelle CR der Probe aus org-mp:

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns

Aktualisieren Sie die Spezifikation, um egress: True einzuschließen, und übernehmen Sie die Änderung. CLUSTER_NAME und GLOBAL_CUSTOMER_ROOT_IP bleiben unverändert.

apiVersion: prober.private.gdc.goog/v1alpha1
kind: Probe
metadata:
  name: global-customer-root-dns
spec:
  egress: True
  matchClusters:
  - CLUSTER_NAME
  probeJobs:
  - moduleName: dns_udp_global_customer_root
    name: healthy-dns-global-customer-root
    targets:
    - GLOBAL_CUSTOMER_ROOT_IP

Durch diesen Workaround wird das Prober-Problem behoben und alle Fehlalarme sollten innerhalb von 15 Minuten verschwinden.

Datei-/Blockspeicher

Fileshare-Volume kann in VM nicht bereitgestellt werden

Versionen: 1.14.6, 1.14.7

Symptome: Beim Hinzufügen eines neuen Knotens zu einem Cluster können die Berechtigungen für den Netzwerkspeicher nicht aktualisiert werden. Dies kann dazu führen, dass NFS-Mount-Anfragen abgelehnt werden. Beim Bereitstellen einer NFS-Dateifreigabe wird möglicherweise der Fehler access denied by server angezeigt.

Problemumgehung: Starten Sie die file-share- oder proxy-group-Abstimmungsfunktionen neu oder ändern Sie die FileShare-Ressource, um ein Update auszulösen.

Firewall

Für die Adresse im Subnetz-CR fehlt eine Sicherheitsrichtlinienregel.

Versionen: 1.14.3

Symptome:Eine Organisation ist nicht erreichbar, da die Firewall-Adressgruppe in der globalen benutzerdefinierten Subnetzressource fehlt, die vom Kunden auf dem globalen API-Server der Organisation erstellt wurde.

Problemumgehung:Folgen Sie der Anleitung im Servicehandbuch FW-G0002, um manuell eine Sicherheitsrichtlinienregel hinzuzufügen, die den Traffic zulässt.

GDC-Firewalls lehnen Traffic in Richtung OIR sowohl für die Verwaltungs- als auch für die Datenebene ab.

Versionen: 1.14.3, 1.14.4

Symptome:Nach der Bereitstellung der benutzerdefinierten OCITTopology-Ressource ist die Verbindung zwischen der OIR-Verwaltungs- und Datenebene und der GDC-Verwaltungs- und Datenebene unterbrochen.

Problemumgehung:Folgen Sie der Anleitung im Servicehandbuch FW-G0002, um dem Root-Administratorcluster manuell Sicherheitsrichtlinienregeln hinzuzufügen, damit der Traffic zugelassen wird.

Die folgenden Regeln für Sicherheitsrichtlinien sind erforderlich:

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

Ersetzen Sie Folgendes:

OCIT_CIDR: die IP-Adressbereiche im Feld ocitCIDR des Customer Input Questionnaire (CIQ).
MGMT_CIDR: die IP-Adressbereiche im Feld oobManagementCIDRs des Customer Input Questionnaire (CIQ).
ZONE_INFRA_CIDR: die IP-Adressbereiche im Feld zoneInfraCIDRs des Customer Input Questionnaire (CIQ).

GDC-Firewall lehnt zonen- und organisationsübergreifenden Traffic ab

Versionen: 1.14.3, 1.14.4, 1.14.5

Symptome:Zonen- und organisationsübergreifender Traffic wird standardmäßig von Firewalls blockiert.

Problemumgehung:Folgen Sie der Anleitung im Runbook, um manuell Regeln für Sicherheitsrichtlinien hinzuzufügen, damit der Traffic zugelassen wird.

Die Firewall unterstützt keine AttachmentGroup, deren Kennung mit dem Organisationsnamen übereinstimmt

Versionen: 1.14.3 und höher

Symptome:Wenn nach der Bereitstellung eines AttachmentGroup das Feld identifier in diesem AttachmentGroup-Objekt mit orgName übereinstimmt, kann die Firewall dieses Objekt nicht parsen und Firewallkonfigurationsupdates bleiben hängen. Ein Beispiel für ein problematisches AttachmentGroup:

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

Workaround:Verwenden Sie nicht den Namen der Organisation als Kennung. Es gibt mehrere Möglichkeiten, die schlechte AttachmentGroup zu beheben.

Wählen Sie eine der folgenden Optionen aus, um das Problem mit AttachmentGroup zu beheben.

Hängen Sie mit einem Bindestrich ein String an das Ende der ursprünglichen Kennung an:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: myorg-orgdx
  entities:
    - orgName: myorg
      domainType: OrgMixed

Hängen Sie mit einem Bindestrich ein String an den Anfang der ursprünglichen Kennung an:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: orgdx-myorg
  entities:
    - orgName: myorg
      domainType: OrgMixed

Ersetzen Sie die ursprüngliche Kennung durch einen anderen String:

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: dxidentifier
  entities:
    - orgName: myorg
      domainType: OrgMixed

Hafen

Harbor-CLI-Secret wird nach Sicherung und Wiederherstellung ungültig

Versionen:1.14.3

Symptome:Nach einer Harbor-Sicherung und ‑Wiederherstellung werden die CLI-Secrets ungültig und müssen neu erstellt werden.

Problemumgehung: So beheben Sie das Problem:

Melden Sie sich mit einem IAP-Nutzerkonto in Harbor an.
Klicken Sie auf Ihren Nutzernamen und wählen Sie Nutzerprofil aus.
Klicken Sie auf das Dreipunkt-Menü Mehr.
Erstellen Sie automatisch oder manuell ein weiteres CLI-Secret.

Weitere Informationen zu Harbor in GDC finden Sie in der Harbor-Übersicht.

Harbor-Sicherungs- und ‑Wiederherstellungsjob konkurriert um Berechtigung

Versionen: 1.14.3, 1.14.4

Symptome:Wenn mehrere Harbor-Instanzen in verschiedenen Nutzerprojekten vorhanden sind, konkurrieren die Sicherungs- und Wiederherstellungsvorgänge um rollenbasierte Zugriffssteuerungen und weisen eine hohe Fehlerrate auf.

Problemumgehung:Um dieses Problem zu umgehen, erstellen Sie manuell eine Rollenbindung für jeden Namespace, in dem Harbor-Instanzen erstellt werden:

Legen Sie die erforderlichen Umgebungsvariablen fest:
```
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
```
Ersetzen Sie Folgendes:
- INFRA_CLUSTER_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Infrastrukturclusters.
- INSTANCE_NAMESPACE: Der Namespace, in dem MHS-Harbor-Instanzen erstellt werden.

Erstellen Sie die Rollenbindung für die Problemumgehung:

kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
--role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
--namespace=haas-system

Größe der Harbor-Sicherung wird als 0 angezeigt

Versionen: 1.14.3, 1.14.4

Symptome:Die Messung der Sicherungsgröße für Harbor-Sicherungen ist derzeit nicht implementiert. In der GDC-Konsole haben die Felder SizeBytes den Wert 0 und in der Spalte Size wird der Wert 0 MB angezeigt. Diese Konfiguration ist derzeit das erwartete Verhalten.

Berechtigungsfehler bei Sicherungsressourcen auf der Konsolenseite der Harbor-Registrierung

Versionen: 1.14.3, 1.14.4

Symptome:Wenn Sie nicht die Rolle „Harbor Instance Admin“ haben, wird auf der Sicherungsressource ein Berechtigungsfehler angezeigt, wenn Sie die Seite Harbor Container Registry in der GDC-Konsole aufrufen. Dieser Fehler wird angezeigt, weil die Sicherungsinformationen neu auf der Seite Harbor Container Registry hinzugefügt wurden, die Leseberechtigung für die Sicherungsressource jedoch nicht für andere IAM-Rollen als „Harbor Instance Admin“ erteilt wurde.

Die anderen GDC-Konsolenelemente auf der Seite Harbor Container Registry funktionieren weiterhin wie erwartet. Weitere Informationen zu Rollen in GDC finden Sie unter Rollendefinitionen.

Seite „Rotation des Datenbankpassworts hängt“

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Symptome:Es werden Fehler bezüglich der Authentifizierung für Anfragen an die Datenbank ausgegeben, z. B. failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), und es sind viele automatisch generierte Rotationsanfragen für ein einzelnes rotierbares Secret vorhanden.

Problemumgehung:Löschen Sie zusätzliche Rotationsanfragen für ein rotierbares Secret, die noch nicht bereit sind.

Legen Sie KUBECONFIG auf den MP API-Server fest.
Exportieren Sie den Namespace:
```
NAMESPACE=haas-system
```

Prüfen, ob rotierbare Secrets in haas-system nicht bereit sind:

kubectl get rotatablesecrets -n ${NAMESPACE?}

Die Ausgabe könnte so aussehen:

NAME                        CREDENTIALID   READY     AGE
haasdb-pw-ar-test           HAAS-0002      True      109d
haasdb-pw-gardener-harbor   HAAS-0002      True      178d
haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
haasdb-pw-myinstance        HAAS-0002      True      80d
haasdb-pw-osd               HAAS-0002      True      158d
haasdb-pw-saptest           HAAS-0002      True      91d

Exportieren Sie den Namen des rotierenden Secrets. Beispiel:
```
ROTATABLE_SECRET=haasdb-pw-haas-alice
```

Löschen Sie zusätzliche Rotationsanfragen, die noch nicht bereit sind:

CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')

kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}

Hardwaresicherheitsmodul

Deaktivierte HSM-Testlizenzen sind weiterhin erkennbar

Versionen:1.14.3, 1.14.4, 1.14.5

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.14.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.

HSMs schlagen nach dem Hochfahren mit dem Fehler `ValidateNetworkConfig` fehl

Versionen: 1.14.x

Symptome:Die benutzerdefinierten HSM-Ressourcen erreichen nicht den Status Ready und schlagen aufgrund eines ValidateNetworkConfig-Fehlers fehl. Bei diesem Fehler wird die folgende Meldung angezeigt: data0 interface MAC address {} is not active. Dieser Fehler tritt auf, wenn das System neu gestartet wird und eine andere primäre Datenschnittstelle festgelegt wird.

Problemumgehung:Folgen Sie dem Runbook HSM-R0059 und wenden Sie die HSM-Netzwerkkonfiguration für das Datennetzwerk noch einmal an. Dieses Runbook kann auch dann befolgt werden, wenn der Fehler auf mehreren HSMs auftritt.

Integrität

SLO-Fehlalarme

Versionen: 1.14.3

Symptome: Ein SLO vom Typ „successRange“ wird fälschlicherweise ausgelöst.

Problemumgehung: Bitten Sie den Infrastrukturbetreiber (Infrastructure Operator, IO), zu prüfen, ob es sich bei der Benachrichtigung um ein echtes Problem oder einen Fehlalarm handelt.

Wenn eine Benachrichtigung ausgelöst wird, folgen Sie dem entsprechenden Runbook, um die zugrunde liegende Ursache der SLO-Benachrichtigung (Service Level Objective) zu beheben.

Fall 1: Wenn das Problem durch das Runbook behoben wird und der Alert nicht mehr ausgelöst wird, kann der IO den zugehörigen Vorfall schließen.

Fall 2: Wenn das Runbook abgeschlossen ist, der Alarm aber weiterhin ausgelöst wird, handelt es sich möglicherweise um einen Fehlalarm. Prüfen Sie, ob das SLO verletzt wurde:

kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'

Anhand der Ausgabe: Wenn bestätigt wird, dass es sich bei der Benachrichtigung um einen Fehlalarm handelt, sollte der IO die Benachrichtigung in der GDC-Air-Gap-Instanz stummschalten. Andernfalls eskaliere den Fall an den Cloud-Support.
In beiden Fällen ist es angemessen, dass IO den Fall an den Cloud-Support eskaliert, um zu prüfen, ob die betriebsbereite Komponente fehlerfrei ist.

Ungültige SLO-Konfigurationen auf Grundlage von Messwerten

Versionen: 1.14.3, 1.14.4

Symptome: Für eine Teilmenge von Service Level Objectives (SLOs) werden aufgrund einer Fehlkonfiguration keine guten, schlechten oder Gesamtereignisse erfasst. Die betreffenden SLOs basieren auf Prometheus-Messinstrumenten und müssen entsprechend konfiguriert werden.

Problemumgehung:

Version 1.14.3: Es gibt keine Problemumgehung. Folglich werden die SLO-Benachrichtigungen für die betroffenen SLOs nicht ausgelöst.

Version 1.14.4: Es ist eine Problemumgehung verfügbar, um das SLO zu korrigieren. Um dieses Problem zu beheben, muss die Einstellung isGauge: true auf die SLO-Spezifikation angewendet werden.

Beispiel für eine Messkonfiguration für ein SLO:

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

Die bekannten SLOs, die mit dieser Einstellung festgelegt werden, sind:

Firewall-SLOs:
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
Datei-SLOs:
- file-ontap-appliance-availability-slo
- file-ipsec-networking-availability-slo
- file-ontap-networking-availability-slo
- file-iscsi-client-availability-slo
- file-multipath-client-availability-slo
- file-trident-client-availability-slo

Identitäts- und Zugriffsverwaltung

Fehler beim Erstellen der IAM-Rollenbindung

Versionen:1.14.3

Symptome:Namen von IAM-Rollenbindungen werden vom System generiert. Diese Namen dürfen maximal 63 Zeichen lang sein und müssen dem Format user-idp-prefix-rolename entsprechen. Wenn der generierte Name das Limit von 63 Zeichen überschreitet, können keine Rollenbindungen erstellt werden. Folglich werden die Berechtigungen, die mit vordefinierten oder benutzerdefinierten Rollen festgelegt wurden, nicht den Nutzern zugewiesen.

Problemumgehung:Das Erstellen von Rollenbindungen kann erfolgreich sein, wenn der Name der vordefinierten oder benutzerdefinierten Rolle sehr kurz ist, z. B. 4–5 Zeichen.

Fehler beim Erstellen der IAM-Rollenbindung für Projekt-Dienstkonten

Versionen:1.14.3, 1.14.4, 1.14.5, 1.14.6

Symptome:Ein Projekt-Dienstkonto (PSA) mit der Rolle organization-iam-admin kann mit dem Befehl gdcloud projects add-iam-policy-binding keine andere Rolle, z. B. die Rolle project-iam-admin, zuweisen. Aufgrund dieses Mangels kann ein PSA seine eigenen Berechtigungen nicht verwalten.

Problemumgehung:Prüfen Sie, ob Sie die Rolle organization-iam-admin haben. Weisen Sie sich dann im Projekt-Namespace der Ziel-PSA die Rolle project-iam-admin zu und weisen Sie der PSA die Rolle project-iam-admin zu. Mit dieser Berechtigungskonfiguration kann die PSA sich selbst oder anderen PSAs zusätzliche Berechtigungen zuweisen.

Verzögerungen bei der Erstellung vordefinierter Rollen in neuen Projekten

Versionen: 1.14.3

Symptome:Wenn ein neues Projekt erstellt wird, fehlen Standardrollen wie project-bucket-object-admin.

Problemumgehung:Warten Sie 15 bis 60 Minuten oder starten Sie den iam-org-admin-cm-backend-controller-Controller im Namespace iam-system im Infrastrukturcluster der Organisation manuell neu.

In der GDC-Konsole kann keine erste Rollenbindung erstellt werden.

Versionen:1.14.4

Symptome:Wenn Sie die erste Rollenbindung für eine neue Dienstidentität über die GDC-Konsole erstellen, wird die Erstellung der Rollenbindung als erfolgreich gemeldet, sie funktioniert aber nicht. Alle weiteren Aktionen für die Dienstidentität schlagen fehl und haben keine Auswirkungen, einschließlich des Hinzufügens oder Löschens von Rollenbindungen.

Problemumgehung:Verwenden Sie die gcloud CLI, um die erste Rollenbindung für eine Dienstidentität zu erstellen. Alle zukünftigen Aktionen mit der Dienstidentität, die über die GDC-Konsole ausgeführt werden, funktionieren nach der ersten Rollenbindung korrekt. Weitere Informationen finden Sie unter Dienstidentität eine Rollenbindung zuweisen.

AOs können sich selbst keinen Zugriff auf Rollen im Infrastrukturcluster gewähren.

Versionen: 1.14.3. 1.14.4

Behoben: 1.14.3 Hotfix 21

Symptome: AOs können sich selbst oder anderen Nutzern keinen Zugriff auf Rollen im Infrastrukturcluster gewähren.

Problemumgehung: AO-Nutzer müssen sich an IOs wenden, um den erforderlichen Zugriff zu erhalten. Die IOs können IAC verwenden, um den AO-Nutzern den erforderlichen Zugriff zu gewähren.

Vorhandenes Dienstkonto-Token wird ungültig

Versionen: 1.14.3

Behoben: 1.14.3 Hotfix 21

Symptome: Das vorhandene Dienstkonto-Token, das vom Nutzercluster ausgestellt wurde, wird ungültig, weil das service-account-issuer-Apiserver-Argument geändert wird, nachdem der Cluster nach dem Bootstrapping ausgeführt wird. Dieses Problem führt dazu, dass der Pod, z. B. der Pod mit einem istio-proxy-Sidecar-Container, im Nutzercluster die Authentifizierung mit dem Dienstkonto-Token nicht besteht. Es dauert Stunden, bis das Dienstkonto-Token mit den neuen Konfigurationen aktualisiert wird.

Workaround: Starten Sie den Pod im Nutzercluster manuell neu, damit das Dienstkonto-Token mit den neuen Konfigurationen erneuert wird.

Infrastruktur als Code (IaC)

Abstimmungsfehler bei der Unterkomponente aufgrund eines fehlenden Namespace

Versionen:1.14.3

Symptome:Eine untergeordnete Komponente kann nicht abgeglichen werden. Das liegt daran, dass der erforderliche config-management-monitoring-Namespace im Cluster gdchservices-mp nicht automatisch erstellt wird.

Problemumgehung:Erstellen Sie den Namespace config-management-monitoring im Cluster gdchservices-mp mit dem folgenden Manifest:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

Erfassung von IAC ConfigSync-Messwerten schlägt fehl

Versionen:1.14.3, 1.14.4

Symptome:Ein Problem im ConfigSync-Monitoring-Subsystem von IAC verhindert den Start der otel-collector-Bereitstellung. ConfigSync-Messwerte werden nicht für Monitoring und Benachrichtigungen erfasst.

Problemumgehung:Führen Sie die folgenden Schritte im root-admin-Cluster aus:

Pausieren Sie die Unterkomponente iac-configsync-mon.
Bearbeiten Sie das MetricsProxySidecar/iac-configsync-metrics-Objekt im Namespace config-management-monitoring.

Suchen Sie im MetricsProxySidecar/iac-configsync-metrics-YAML nach Folgendem:

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-target-cert

Ändern Sie diesen Abschnitt so:

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-mon-target-cert

Starten Sie das otel-collector-Deployment im Namespace config-management-monitoring neu.

IAC RootSync schlägt fehl

Versionen:1.14.3

Symptome:Es gibt ein Problem beim Synchronisieren von ConfigSync-Ressourcen von GitLab mit Clustern aufgrund eines fehlenden iac-creds-Secrets . Die iac-creds werden aufgrund eines iacmanager-Problems nicht rotiert.

Problemumgehung:Führen Sie die folgenden Schritte im Cluster aus:

Folgen Sie dem Runbook IAC-R0015, um das Problem des fehlenden Secrets „iac-creds“ zu beheben. Es rotiert die Anmeldedaten des IaC-Managers und von ConfigSync.

Inventar

Inventarprüfung kann nicht abgeglichen werden

Versionen:1.14.3

Symptome:Die Unterkomponente inv-audit kann nicht abgeglichen werden, da HarborRobotAccount nur auf der Verwaltungsebene verfügbar ist.

Problemumgehung:Erstellen Sie eine Stummschaltung in AlertManager, um die component_reconciliation_errors-Benachrichtigung für component: inv stummzuschalten.

Schlüsselverwaltungssystem

Für KMS, die für die Verwendung eines CTM-Root-Schlüssels konfiguriert sind, erfolgt kein Failover, wenn ein HSM nicht verfügbar ist

Versionen:1.14.x

Symptome:Einige Anfragen an den KMS schlagen fehl, wenn ein HSM nicht verfügbar ist und andere verfügbare HSMs verwendet werden könnten. Dieses Problem tritt nur auf, wenn der KMS für die Verwendung eines CTM-Stammschlüssels konfiguriert ist.

Problemumgehung:Entfernen Sie das nicht verfügbare HSM aus dem HSMCluster, indem Sie dem Runbook HSM-P0006 folgen. Starten Sie dann die kms-backend-Bereitstellung neu:

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

Mit diesem Befehl werden die kms-backend-Pods neu gestartet und die Verbindung zu HSMs im HSMCluster wird wiederhergestellt.

Load-Balancer

Erstellen eines globalen Load-Balancers schlägt aufgrund von CIDR-Erschöpfung des Subnetzes fehl

Versionen:1.14.3

Symptome:Die Erstellung eines globalen externen oder internen Load-Balancers schlägt fehl, weil in globalen Subnetzen nicht genügend IP-Adressen vorhanden sind. Das System kann keine IP-Adressen für globale Load Balancer dynamisch zuweisen, da ein Controller einen falschen Codepfad verwendet. Der Load-Balancer verweist nur auf ein Subnetz. Wenn in diesem Subnetz keine IP-Adressen mehr verfügbar sind, kann nicht zu einem anderen Subnetz gewechselt werden. Diese Einschränkung führt dazu, dass der Fehler angezeigt wird.

Problemumgehung:Sie müssen ein eigenes Subnetz erstellen und statische IP-Adressen für Ihre ForwardingRule-Ressourcen erstellen. Weitere Informationen zum Erstellen von Subnetzen finden Sie unter Subnetze für das Arbeitslastnetzwerk konfigurieren. Wenn Sie eine ForwardingRule-Ressource erstellen, können Sie das Subnetz im Feld cidrRef angeben.

Versionen: 1.14.3

Symptom:Load-Balancer-Objekte erreichen nicht den Status Ready.

Problemumgehung:Sie müssen Backend-Ressourcen erstellen, bei denen das Feld spec einen Wert hat. Die Backend-Ressourcen geben Endpunkte für den Load-Balancer an. Wenn Sie keinen Wert für das Feld spec angeben, kann es zu Fehlern kommen.

Durch das Ändern von Load-Balancer-Ressourcen werden Dienste nicht abgeglichen

Versionen: 1.14.3

Symptome:Durch das Ändern benutzerdefinierter Load-Balancer-Ressourcen werden die Load-Balancer-Dienste nicht abgeglichen.

Workaround:Um dieses Problem zu beheben, löschen Sie den Load-Balancer und erstellen Sie ihn neu. Löschen Sie dazu die BackendService- und ForwardingRule-Ressourcen des Load-Balancers.

Falsche Zonenamen werden nicht abgelehnt

Versionen: 1.14.3

Symptome:Die globale BackendService-Ressource lehnt falsche Zonennamen nicht ab. Wenn der Name der Zone falsch ist, schlägt der Load-Balancer fehl, anstatt die Konfiguration zu validieren und abzulehnen.

Problemumgehung:Sie müssen die richtigen Namen der verwendeten Zonen angeben. Wenn der Load-Balancer falsch konfiguriert ist, müssen die benutzerdefinierten Load-Balancer-Ressourcen gelöscht und neu erstellt werden.

Webhook-Fehler bei globalen und zonalen Load Balancern

Versionen: 1.14.3

Symptome:Der folgende Fehler wird zurückgegeben:

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

Problemumgehung:Starten Sie den unet-global-cm-Pod neu und löschen Sie ihn, um dieses Problem zu beheben:

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

Logging

Loki-Pod stürzt ab oder wird während der WAL-Wiedergabe (Write-Ahead Log) durch OOMKilled beendet

Versionen: 1.14.3, 1.14.4, 1.14.5

Symptome:

Die audit-logs-loki-io-Pods im Namespace obs-system wechseln in den Status CrashLoopBackOff. Dies wird durch vorzeitige Liveness-Probe-Fehler oder einen OOM-Kill (Out Of Memory) während der WAL-Wiedergabe (Write-Ahead Log) verursacht, da der Wert von wal_replay_ceiling das Arbeitsspeicherlimit des Pods überschreitet.

Problemumgehung:

Führen Sie die folgenden Schritte aus, um die Konfiguration von Loki so anzupassen, dass ein erfolgreiches WAL-Replay möglich ist. Änderungen müssen auf den betroffenen Cluster angewendet werden (z. B. root-admin oder org-infra).

Legen Sie KUBECONFIG=/path/to/affected-cluster.kubeconfig als Umgebungsvariable fest.

Pausieren Sie LoggingPipelineReconciler, um zu verhindern, dass der Controller manuelle Änderungen rückgängig macht. Wenden Sie dieses Manifest an:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: log-logging-pipeline-pause
  namespace: root
spec:
  subComponentRef: "log-admin"
  backend:
    operableParameters:
      controller:
        disableReconcilers: "LoggingPipelineReconciler"

Prüfen Sie, ob die Überschreibung aktiv ist. Die Ausgabe sollte "disable-reconcilers=LoggingPipelineReconciler" beinhalten.

kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq

Senken Sie den Wert von replay_memory_ceiling in der ConfigMap audit-logs-loki-io-cm auf 8GB.

kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}

Ändern Sie den Abschnitt wal:

[...]
  wal:
    replay_memory_ceiling: 8GB ## <-- Change to 8GB
[...]

Optional: Skalieren Sie den Objekt-Proxy. Wenn die obj-proxy-Pods sich ihren Ressourcenlimits nähern, skalieren Sie das Deployment, um die erhöhte Last während der Wiederherstellung zu bewältigen.

a. Ressourcennutzung prüfen:
```
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
```
b. Bei hoher Nutzung:
```
kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
```
c. Bei Bedarf können Sie auch das Arbeitsspeicherlimit des Pods erhöhen, z.B. von 12000Mi auf 16000Mi.
Erhöhen Sie die PVC-Größe für den betroffenen Pod (z.B. loki-storage-audit-logs-loki-io-0 von 70Gi auf 75Gi verschoben, um den Festplatten-Druck zu verringern. Folgen Sie dem internen Verfahren SUPP-R001, um die Größe des PVC zu ändern. Beim Neustart im nächsten Schritt wird die neue Größe angewendet.
Fügen Sie dem audit-logs-loki-io StatefulSet ein startupProbe hinzu, damit genügend Zeit für die WAL-Wiedergabe bleibt, bevor die Aktivitätsprüfungen beginnen. Durch das Speichern der Änderung wird ein rollierender Neustart der Pods ausgelöst (5–10 Minuten).
```
kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
```
Fügen Sie der audit-logs-loki-io-Containerspezifikation Folgendes hinzu:startupProbe
```
startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10
```

Workaround prüfen

Pod- und StatefulSet-Status prüfen: Prüfen Sie, ob alle audit-logs-loki-io-Pods Running sind und das StatefulSet alle Replikate als bereit anzeigt.

kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}

Prüfen Sie, ob die Größe des PVC geändert wurde. Die erwartete Ausgabe ist 75Gi.

kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo

Prüfen Sie die Pod-Logs auf errors=false-Meldungen, um zu bestätigen, dass die WAL-Wiederherstellung erfolgreich war.
```
kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
```

Prüfen Sie, ob die Nutzung des Verzeichnisses /wal im Pod gering ist.

kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal

Loki-Ring-Status prüfen:

a. Führen Sie eine Portweiterleitung des Loki-Dienstes durch:

DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}

b. Prüfen Sie unter http://<DATA_IP>:43100/ring, ob alle Instanzen fehlerfrei sind.

Überschreibung und Objekt-Proxy bereinigen

Führen Sie nach der erfolgreichen Bestätigung die folgenden Bereinigungsschritte aus.

Überschreibung der Unterkomponente entfernen:

kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}

Wenn Sie die obj-proxy-Bereitstellung hochskaliert haben, skalieren Sie sie wieder auf die ursprüngliche Größe zurück.

Monitoring

AlertManager-Webhooks senden für einige Cluster keine Benachrichtigungen

Version: 1.14.3

Symptome:AlertManager-Webhooks können keine Anfragen und Benachrichtigungen von Clustern, die nicht der Administrator-Root-Cluster oder der Cluster sind, in dem sich die ServiceNow-Instanz befindet, an ServiceNow senden. Daher werden in ServiceNow keine Benachrichtigungen für die Organisation erstellt.

Sie können erkennen, dass der Webhook keine Benachrichtigungen sendet, wenn Sie wiederholt Fehlermeldungen erhalten. So suchen Sie nach wiederholten Fehlern:

Umgebungsvariablen exportieren:
```
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
```
Ersetzen Sie MGMT_API_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Management API-Servers.

Suchen Sie den Pod:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
  -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-

Rufen Sie die Logs ab:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system

Ersetzen Sie POD_NAME durch den Namen des Pods.

Suchen Sie nach wiederholten Fehlern, die so aussehen:

Errorsendingtherequest ... read: connection reset by peer

Problemumgehung:Die empfohlene Problemumgehung für dieses Problem besteht darin, zwei untergeordnete Komponenten zu pausieren, eine für Meta-Monitoring-Benachrichtigungen und eine für reguläre Benachrichtigungen. Ersetzen Sie dann das Label egress.networking.gke.io/enabled: "true" durch networking.private.gdc.goog/infra-access: enabled in der mon-alertmanager-servicenow-webhook-backend-Bereitstellung des betroffenen Clusters. Mit diesem Label kann der Pod mit anderen Infrastrukturclustern kommunizieren, ohne auf ein Ausgangsgateway angewiesen zu sein.

So wenden Sie die empfohlene Problemumgehung an:

Umgebungsvariablen exportieren:
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG
```
Ersetzen Sie Folgendes:
- ROOT_KUBECONFIG: der Pfad zur kubeconfig-Datei des Stammadministratorclusters.
- MGMT_API_KUBECONFIG: der Pfad zur kubeconfig-Datei des Management API-Servers.
- ORG: der Namespace der Organisation.

Unterkomponenten pausieren:

Pausieren Sie die Unterkomponente mon-alertmanager-servicenow-webhook:

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

Pausieren Sie die Unterkomponente mon-meta-monitoring:

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

Aktualisieren Sie die mon-alertmanager-servicenow-webhook-backend-Bereitstellung, die die meisten Benachrichtigungen abdeckt:

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system mon-alertmanager-servicenow-webhook-backend

Ersetzen Sie das Label in spec.template.metadata.labels von egress.networking.gke.io/enabled: "true" zu networking.private.gdc.goog/infra-access: "enabled".
Aktualisieren Sie die meta-alertmanager-servicenow-webhook-Bereitstellung, die Warnungen im Zusammenhang mit dem Monitoring-Stack abdeckt:
```
kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system meta-alertmanager-servicenow-webhook
```
Ersetzen Sie das Label in spec.template.metadata.labels von egress.networking.gke.io/enabled: "true" zu networking.private.gdc.goog/infra-access: "enabled".

Alternativ können Sie dieselben Benachrichtigungen in Grafana ansehen.

ServiceNow-Vorfälle werden gelegentlich dupliziert

Version: 1.14.3

Symptome:Möglicherweise werden doppelte ServiceNow-Vorfälle für denselben Pod angezeigt.

Problemumgehung:Sie können doppelte Tickets identifizieren, indem Sie die Fingerabdrücke in der Beschreibung des Vorfalls vergleichen.

Infrastrukturmesswerte sind möglicherweise zu sensibel

Version: 1.14.3

Symptome:Möglicherweise werden Alarme für die Benachrichtigung oclcm-reconciler-success-rate angezeigt.

Problemumgehung:Sie können die Benachrichtigung stummschalten. Diese Benachrichtigung ist zu laut und wir arbeiten daran, das Signal zu verbessern.

Abstimmungsmesswerte sind möglicherweise zu sensibel

Version: 1.14.3, 1.14.4, 1.14.5

Symptome:Möglicherweise werden Alarme für die Benachrichtigung component_reconciliation_errors angezeigt.

Problemumgehung:Sie können die Benachrichtigung gefahrlos stummschalten, indem Sie dem Runbook MON-R2009 folgen. Diese Benachrichtigung ist zu laut.

Im Stammadministratorcluster sind zwei falsche Benachrichtigungen offen.

Version: 1.14.3

Symptome:Die Benachrichtigungen MON-A0001_slow und MON-A0001_fast befinden sich im Stammadministratorcluster im Status „Wird ausgelöst“.

Das Incident in ServiceNow sieht in etwa so aus:

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

Der Vorfall hat die folgende Beschreibung:

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

Problemumgehung: Führen Sie die folgenden Schritte aus, um das Problem nur im Administratorcluster des Stammverzeichnisses zu beheben:

Löschen Sie das Label „monitoring.gdc.goog/metamonitoring-project=mon-system“ in der mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

Löschen Sie alle Aufzeichnungsregeln mit dem Namen mon_metrics_pipeline_absent und dem Clusterlabelwert ORG_NAME-admin aus dem mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

Das folgende Beispiel zeigt eine mon_metrics_pipeline_absent-Aufzeichnungsregel, die gelöscht werden soll:

Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
    Labels:
      _source_project:  blackbox-monitoring-obs-system
      Cluster:          gdchservices-admin
      Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
    Record:             mon_metrics_pipeline_absent

Sowohl die MON_A0001_slow- als auch die MON_A0001_fast-Benachrichtigungen wechseln nach einigen Minuten (ca. 40 Minuten) wieder in den Status Normal.

Controller-Manager des Root-Administrators weist eine hohe Fehlerrate auf

Version: 1.14.3

Symptome:Möglicherweise werden Benachrichtigungen für die Benachrichtigung ControllerReconciliationErrorRateHigh angezeigt. Im Controller-Manager werden Logs mit folgender Meldung angezeigt: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Workaround:Sie können den Controller, der den Fehler verursacht, einfach deaktivieren.

Umgebungsvariablen exportieren:
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
```
Bearbeiten Sie das Deployment des Root-Admin-Controller-Managers:
```
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller
```
Wenn im Container manager noch kein Argument --disable-reconcilers vorhanden ist, fügen Sie eines mit dem Wert --disable-reconcilers=ApplianceStorageTunnelReconciler hinzu. Wenn ja, fügen Sie den ApplianceStorageTunnelReconciler-Abstimmer mit einem Komma hinzu. Beispiel: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler.

Die Fehlerlogs sollten gelöscht werden.

In KUB-Dashboards werden in allen PA-Bereichen keine Daten angezeigt

Versionen: 1.14.3

Symptome:In den KUB-Dashboards werden in Grafana für Plattformadministratoren in allen Bereichen keine Daten angezeigt.

Problemumgehung:Pausieren Sie die KSM-Unterkomponente und aktualisieren Sie monitoringtarget und metricsproxysidecar:

Unterkomponente pausieren:

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

Ersetzen Sie Folgendes:

ORG_NAME: der Name der Organisation
ROOT_ADMIN_KUBECONFIG: der Pfad zur root-admin-Kubeconfig

Fügen Sie Folgendes zum mon-kube-state-metrics-metrics-proxy-Messwert „proxysidecar“ im Abschnitt .spec.destinations hinzu:

  - certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

Der aktualisierte Sidecar-Container „metricsproxysidecar“ könnte so aussehen:

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

Entfernen Sie den Abschnitt matchClusters: aus dem Monitoringziel spec mon-pa-kube-state-metrics. Das aktualisierte mon-pa-kube-state-metricsmonitoringtarget spec könnte so aussehen:

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics

Berechtigungen für die Rolle „observability-admin-debugger“ sind falsch konfiguriert

Versionen: 1.14.3, 1.14.4

Symptome:IOs können die Cortex- oder Prometheus-Pods im Namespace mon-system nicht neu starten.

Problemumgehung:

Für Organisationen:

Pausieren Sie die Unterkomponente iam-common.

Aktualisieren Sie die observability-admin-debugger/iam-system-Rollenvorlage so:

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

Für Root-Administratoren:

Pausieren Sie die Unterkomponente iam-common.

Aktualisieren Sie die observability-admin-debugger-root/iam-system-Rollenvorlage so:

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

Grafana-Debugger-Rolle fehlt

Versionen: 1.14.3, 1.14.4

Symptome:Die Rolle grafana-debugger-cp ist in den Namespaces des Observability-Schattenprojekts (*-obs-system) nicht vorhanden. Nutzern kann nicht die richtige Berechtigungsgruppe gewährt werden, die zum Debuggen von Grafana-bezogenen Problemen erforderlich ist.

Problemumgehung: Erstellen Sie die folgende benutzerdefinierte ClusterRoleTemplate-Ressource in infra-cp und verwenden Sie die entsprechende ClusterRole, die erstellt wird, um die Berechtigungen für grafana-debugger zu erhalten.

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

Zonenübergreifende Messwerte und Logs sind nach dem Hinzufügen einer neuen Zone nicht sichtbar

Versionen: 1.14.*

Symptome:Im Grafana-Dashboard werden keine Logs und Messwerte für die neu hinzugefügte Zone angezeigt.

Problemumgehung 1:Stellen Sie das Datasource-Proxy-Deployment neu bereit:

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

Dadurch werden die Datasource-Proxy-Pods neu gestartet und die zonenübergreifende Endpunktkonfiguration für die neu hinzugefügte Zone aktualisiert.

Der Finalizer `MonitoringTarget` verhindert das Löschen des Namespace.

Versionen: 1.14.3, 1.14.4

Symptome:Der Namespace wird nicht gelöscht und es gibt fehlerhafte Cluster in der entsprechenden Organisation.

Problemumgehung:Entfernen Sie die Finalizer manuell aus den benutzerdefinierten Ressourcen MonitoringTarget, die das Löschen des Namespace verhindert haben.

Das Löschen des Projekts bleibt aufgrund von ausstehenden Finalizern für Dashboard und Datenquelle hängen

Versionen: 1.14.3, 1.14.4

Behoben: 1.14.3 Hotfix 22

Symptome: Projekte werden nicht gelöscht und der Namespace wird mit Fehlern wie im folgenden Beispiel beendet:

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

Problemumgehung: Löschen Sie die Finalizer für das Dashboard und die Datenquelle manuell.

Messwerte aus KSM sind nicht sichtbar

Versionen: 1.14.3

Behoben: 1.14.3 Hotfix 22

Symptome: In KUB-Dashboards wird in allen Bereichen No Data angezeigt.

Problemumgehung: Pausieren Sie die KSM-Unterkomponente und aktualisieren Sie monitoringtarget und metricsproxysidecar.

Unterkomponente pausieren:

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

Ersetzen Sie Folgendes:

ORG_NAME: Der Name der Organisation.
ROOT_ADMIN_KUBECONFIG: Der Pfad zur kubeconfig des Root-Administrators.

Fügen Sie Folgendes zu mon-kube-state-metrics-metrics-proxy metricsproxysidecar in .spec.destinations hinzu:

- certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

Der aktualisierte mon-kube-state-metrics-metrics-proxy-Sidecar-Proxy für Messwerte sieht so aus:

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

Entfernen Sie den Abschnitt matchClusters: aus der mon-pa-kube-state-metrics-Monitoringtarget-Spezifikation. Die aktualisierte mon-pa-kube-state-metrics-Monitoringtarget-Spezifikation sieht so aus:

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics`

Die Messwertpipeline des Systems ist ausgefallen

Version: 1.14.3

Symptome:Die Benachrichtigung MON-A0001 ist auch nach dem Befolgen des Runbooks MON-R0001 aktiv.

Workaround:

Wenn das Problem im Administratorcluster auftritt, erstellen Sie die folgende SubcomponentOverride in root-admin mit dem IAC-R0004-Runbook. Für andere Cluster wie Nutzer-, Perimeter- oder freigegebene Cluster erstellen Sie die SubcomponentOverride in ${ORG}-mp.

kind: SubcomponentOverride
metadata:
  name: mon-cortex-tenant
  namespace: <NAMESPACE>
spec:
  backend:
    operableParameters:
      concurrency: 1024
      resourcesLimit:
        cpu: "8"
        memory: 16Gi
  subComponentRef: mon-cortex-tenant

So finden Sie die richtige NAMESPACE:

kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

Die Ausgabe sieht so aus:

org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
root                 mon-cortex-tenant                      47h   ReconciliationCompleted

Der Namespace ist entweder der Stamm, wenn die Pipeline für root-admin nicht verfügbar ist, oder org-1, wenn die Pipeline für org-1 admin nicht verfügbar ist:

kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

Die Ausgabe sieht so aus:

g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted

Der richtige Namespace kann je nachdem, für welchen Cluster die Pipeline für Systemmesswerte ausgefallen ist, g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster oder user-vm-2-cluster sein.

Nachdem Sie SubcomponentOverride angewendet haben, starten Sie die cortex-tenant-Bereitstellung in den entsprechenden Clustern neu. Prüfen Sie, ob die Werte im entsprechenden Cluster aktualisiert wurden:
```
kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
```
Aktualisieren Sie das Feld für die Nebenläufigkeit.

Starten Sie die cortex-tenant-Bereitstellungen neu:

kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system

Mehrinstanzenfähigkeit

In der Console werden keine Fehler beim Erstellen von Knotenpools angezeigt

Version: 1.14.4, 1.14.5, 1.14.6

Behoben: 1.14.7

Symptome:Wenn in der GDC-Konsole das Erstellen eines Knotenpools fehlschlägt, wird in der Benutzeroberfläche fälschlicherweise eine creation in progress-Meldung angezeigt, die darauf hinweist, dass der Knotenpool erfolgreich erstellt wurde.

Problemumgehung:Verwenden Sie die gdcloud CLI, um die Erstellung von Knotenpools zu validieren.

Mehrere Zonen

Auf Zone kann nicht zugegriffen werden, Weiterleitung zur Authentifizierungsseite

Version: 1.14.x

Symptome:Wenn eine Zone nicht zugänglich ist, wird die GDC-Konsole zu einer Seite weitergeleitet, auf der ein Authentifizierungsfehler angezeigt wird. Die Nichterreichbarkeit der Zone muss jedoch nicht unbedingt auf ein Authentifizierungsproblem zurückzuführen sein, sondern kann auch durch einen zonalen Ausfall verursacht werden.

Problemumgehung:Verwenden Sie die zonale URL, um das Problem zu umgehen. Wenn die zonale URL ebenfalls nicht funktioniert, bitten Sie Ihren Infrastruktur-Operator (IO), zu prüfen, ob die Zone, für die Sie Authentifizierungsprobleme erhalten, ausgefallen ist.

Rolle zum Aufrufen von Zonen mit der gcloud CLI wird nicht angewendet

Version: 1.14.x

Symptome:Die erforderliche IAM-Rolle für die Verwendung des Befehls gdcloud zones list wird standardmäßig nicht auf das GDC-Universum angewendet. Die fehlende Rolle, die nicht als vordefinierte Rolle verfügbar ist, verhindert, dass Zonen mit der gcloud CLI aufgelistet werden können.

Problemumgehung:Wenden Sie die IAM-Rolle global-zone-viewer und die Ressourcen für die Rollenbindung auf den globalen API-Server an:

Erstellen Sie eine YAML-Datei für die Rolle, z. B. global-zone-viewer.yaml, mit folgendem Inhalt:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

Wenden Sie die YAML-Datei auf den globalen API-Server der Organisation an:

kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml

Mit dieser Rollenbindung werden alle Nutzer im System authentifiziert, um Zonen mit gdcloud zones list aufzurufen.

Gelegentliche globale Anmeldefehler bei der Konsolen-URL

Versionen: 1.14.x

Symptome:Wenn Sie sich mit der globalen URL in der GDC Console anmelden, erhalten Sie möglicherweise Fehlermeldungen, dass Ihre Sitzung nicht mehr gültig ist. Dieser Fehler kann durch einen zugrunde liegenden Netzwerkfehler verursacht werden und muss nicht unbedingt den tatsächlichen Sitzungsstatus widerspiegeln.

Problemumgehung:Melden Sie sich mit den zonalen URLs in der GDC-Konsole an, um globale Ressourcen in den einzelnen Zonen zu verwalten. Weitere Informationen zum Wechseln von Zonenkontexten über die GDC-Konsole finden Sie unter Ressourcen zonenübergreifend verwalten.

Netzwerk

Anpassen der Reihenfolge von `MultiZoneNetworkConfig`-Zonen führt zu einem Fehler beim Ersetzen der Konfiguration

Versionen: Alle Versionen von 1.14.x können betroffen sein.

Symptome:

Der READY-Status für ToR-Switches (Top of Rack) ist „False“. Mit dem folgenden Befehl können Sie dies bestätigen:
```
kubectl get torswitches -A
```
Der Austausch der Switch-Konfiguration schlägt mit einem Fehler fehl, der angibt, dass der Eintrag bereits vorhanden ist. Das ist in den Protokollen zum Ersetzen der Switch-Konfiguration zu sehen. Die Fehlermeldung sieht etwa so aus:
```
% Insertion failed - entry already exists
```

Dieses Problem wird durch das Anpassen der Reihenfolge von Zonen innerhalb von MultiZoneNetworkConfig verursacht. Das System generiert Sequenznummern für BGP-Zugriffslistenregeln basierend auf der Position der einzelnen Zonen in der Konfigurationsliste. Wenn die Reihenfolge der Zonen geändert wird, generiert das System neue Regeln mit anderen Sequenznummern, die mit den bereits auf dem Switch vorhandenen Regeln in Konflikt stehen.

Problemumgehungen:

Um dieses Problem zu beheben, entfernen Sie die in Konflikt stehende BGP AS-Pfad-Zugriffslistenkonfiguration manuell von jedem betroffenen ToR-Switch. So kann das System die richtige Konfiguration abgleichen und anwenden.

Stellen Sie eine SSH-Verbindung zu jedem ToR-Switch her, der sich nicht im Status Ready befindet.
Rufen Sie den globalen Konfigurationsmodus auf:
```
config t
```
Entfernen Sie die in Konflikt stehende Konfiguration der Zugriffsliste:
```
no ip as-path access-list other-zones
```
Konfigurationsmodus beenden

Nachdem dieser Befehl auf allen betroffenen Switches ausgeführt wurde, wendet der Abgleich die richtige Konfiguration an und die Switches wechseln in den Status READY.

Ablauf von Config-Replace-Commits

Versionen: Alle Versionen von 1.14.x können betroffen sein.

Symptome:

Eine große Anzahl von Access Control Lists (ACLs) führt beim Konfigurieren von Netzwerk-Switches zu einem Zeitüberschreitungsfehler. Die benutzerdefinierte Ressource BorderLeafSwitch befindet sich nicht im Status Ready. Wenn eine SSH-Verbindung mit dem nicht bereiten Switch hergestellt wird, wird der Status Commit expiry angezeigt.

Der folgende Befehl zeigt beispielsweise den Status an:

sh config-replace log verify

Die Ausgabe sieht etwa so aus:

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

Problemumgehung:

Bearbeiten Sie in Version 1.14.3 oder 1.14.7+ die benutzerdefinierte Ressource SubcomponentOverride mit dem Namen pnet-core-override im Namespace root und fügen Sie .spec.operableParameters.netDevGW das Feld httpTimeout hinzu.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

Warten Sie 15 Minuten, damit die Automatisierungsinfrastruktur neue Konfigurationen an die Switches senden kann. Konfigurieren Sie httpTimeout nach Bedarf, bis die Commit expiry-Meldungen verschwinden.

Führen Sie in den Versionen 1.14.4, 1.14.5 und 1.14.6 den Konfigurationsersatz manuell durch und übernehmen Sie die Änderungen.

Umstellung pausieren:

export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"

Folgen Sie dem PNET-P0001-Runbook, um Zugriff auf den Switch zu erhalten.
Konfiguration zum Ersetzen suchen:
```
switch-cli# dir | grep new_config
```
Schließen Sie den Konfigurationsersatz ab:
```
switch-cli# configure replace <new_config_file>
```
Das kann mehr als fünf Minuten dauern.
Nachdem der Befehl „config-replace“ erfolgreich ausgeführt wurde, übernehmen Sie die Änderung:
```
switch-cli# configure replace commit
```

Schalter reaktivieren:

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-

Bereitstellung mit 4‑Byte-BGP-ASN schlägt fehl

Versionen: 1.14.3, 1.14.4

Symptome: Die Konfiguration des Border Gateway Protocol (BGP) mit einer 4‑Byte-ASN (Autonomous System Number) auf Netzwerk-Switches führt zu Konfigurationsfehlern. Ohne eine korrekt angewendete BGP-Konfiguration kann das Netzwerk in dieser GDC-Zone möglicherweise kein korrektes Routing einrichten, was zu Verbindungsproblemen, der Unfähigkeit, Routen zu bewerben, oder allgemeiner Netzwerkinstabilität führen kann. Derzeit gibt es keine Problemumgehung.

Globaler Anycast-Traffic blockiert

Versionen: 1.14.3

Symptome:Der Traffic, der an die globalen Anycast-Endpunkte gerichtet ist, wird durch Access Control Lists (ACLs) blockiert.

Workaround:

Um das Problem zu beheben, dass globaler Anycast-Traffic durch Zugriffssteuerungslisten (Access Control Lists, ACLs) blockiert wird, müssen Sie im Root-Admin-Cluster eine benutzerdefinierte Ressource vom Typ SubcomponentOverride erstellen, um Traffic zu den Anycast-CIDR-Blöcken des globalen DNS-Servers explizit zuzulassen. Gehen Sie so vor:

Alle globalen Anycast-CIDR-Blöcke finden. So finden Sie die globalen Anycast-CIDR-Blöcke, die aktualisiert werden müssen:
1. Verbindung zum globalen Root-API-Server herstellen
2. Listen Sie alle benutzerdefinierten Subnetzressourcen in allen Namespaces mit dem folgenden Befehl auf:
```
kubectl get subnet -A
```
3. Filtern Sie die Ausgabe, um Subnetzressourcen zu finden, bei denen der Filter metadata.name das Keyword anycast enthält.
4. Notieren Sie sich für jede Subnetzressource, die mit anycast im Namen gefunden wird, den Wert von spec.subnet. Dieser Wert stellt einen globalen Anycast-CIDR-Block dar.

Erstellen Sie im Administratorcluster des Stamms eine benutzerdefinierte SubcomponentOverride-Ressource mit dem Namen pnet-trafficpolicy-dc-override im Stamm-Namespace. Fügen Sie für jedes Anycast-Subnetz, das Sie im vorherigen Schritt ermittelt haben, die Regeln wie in der YAML-Datei gezeigt hinzu:

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-trafficpolicy-dc-override
  namespace: root
spec:
  backend:
    operableParameters:
      breakglassRules:
        default-traffic-policy-data:
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: INTERCONNECT_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataInterconnect
          sourceEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: HAIRPIN_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataHairpin
          sourceEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
  subComponentRef: pnet-trafficpolicy-dc

Ersetzen Sie Folgendes:

INTERCONNECT_RULE_DESCRIPTION: Der beschreibende Text für die Interconnect-Netzwerkregel.
GLOBAL_ANYCAST_CIDR: Der globale Anycast-CIDR-Block, z. B. 136.125.38.128/28. Erstellen Sie für jeden Anycast, den Sie im vorherigen Schritt gefunden haben, die Regel mit dieser YAML-Datei.
HAIRPIN_RULE_DESCRIPTION: Der beschreibende Text für die Hairpin-Netzwerkregel.

Teilweiser DCI-Fehler führt zu Trafficverlusten

Versionen: 1.14.3

Symptome:Wenn beide Data Center Interconnect-Verbindungen (DCI) zwischen dem Border-Leaf-Switch einer Zone und dem Carrier-Switch ausfallen oder wenn der Border-Leaf-Switch einer Zone einen Hardwarefehler aufweist, geht etwa 50% des zonenübergreifenden Netzwerkverkehrs verloren.

Name des VRF zu lang

Versionen: 1.14.2

Symptome:Wenn Sie diesen Befehl ausführen, wird möglicherweise eine Meldung wie im folgenden Beispiel angezeigt, die darauf hinweist, dass die Switches nicht fehlerfrei sind:

sh config-replace log verify

Die Ausgabe könnte so aussehen:

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

Problemumgehung:Der Name des CR der Organisation darf maximal 19 Zeichen lang sein.

Kommunikation mit StatefulSet-Pod schlägt fehl

Versionen: 1.14.3, 1.14.4

Behoben: 1.14.3 Hotfix 23, 1.14.5

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*]

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

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*]

Problem mit dem Grafana-Dashboard für das SLO zur Verfügbarkeit über mehrere Zonen hinweg

Versionen: 1.14.3

Symptome: Im Grafana-Dashboard für das pnet-cross-zone-availability-SLO werden keine Messwerte angezeigt.

Problemumgehung: Folgen Sie dem PNET-P0001-Runbook, um Switch-Zugriff zu erhalten und den Status der BGP-Sitzung und der Verbindung manuell zu prüfen.

Abgleich von Ingress-Gateways für Daten- und Verwaltungsebene fehlgeschlagen

Versionen: 1.14.3

Symptome:Die Unterkomponenten asm-dataplane-ingress oder asm-management-ingress können mit dem folgenden Fehler nicht abgeglichen werden:

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

Andere mögliche Werte im Fehlerstring anstelle von BackendService sind ForwardingRuleInternal und ForwardingRuleExternal. Der Ressourcenname kann auch dataplane-ingress-gateway, dataplane-ingress-gateway-global oder management-ingress-gateway-global anstelle von management-ingress-gateway sein.

Problemumgehung:Ermitteln Sie, ob die Ressource auf dem Management API-Server oder dem globalen API-Server vorhanden ist. Dies kann aus der API-Version des Ressourcentyps im Fehlerstring abgeleitet werden. Eine Ressource mit dem Suffix networking.gdc.goog ist beispielsweise auf dem Management API-Server vorhanden, während eine Ressource mit dem Suffix networking.global.gdc.goog auf dem globalen API-Server vorhanden ist.

Nachdem Sie den API-Server identifiziert haben, löschen Sie die Ressource mit der entsprechenden kubeconfig-Datei. Beispiel:

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

Die Seite für Netzwerkrichtlinien für Projekte unterstützt das Feld für die Projektauswahl in der ProjectNetworkPolicy API nicht.

Versionen: 1.14.3, 1.14.4

Symptome: Wenn Sie eine Projektnetzwerkrichtlinie erstellen, die das Feld projectSelector enthält, und sie in der GDC Console aufrufen, werden in der Benutzeroberfläche alle für die Richtlinie ausgewählten Projekte anstelle der Projekte im Feld projectSelector angezeigt.

Problemumgehung: Verwenden Sie die API, um eine Projektnetzwerkrichtlinie zu erstellen und zu lesen, die das Feld projectSelector enthält.

Betriebssystem

Serverbereitstellung schlägt fehl

Versionen: 1.14.3

Symptome: Während der Serverbereitstellung werden möglicherweise die folgenden 401-Fehler für die entsprechende benutzerdefinierte Ressource BaremetalHost angezeigt, wenn das Betriebssystem-Image aus der Harbor-Registrierung heruntergeladen wird. Der Server befindet sich in einer Schleife aus Bereitstellung aufheben und erneuter Bereitstellung.

So prüfen Sie, ob diese Fehler vorliegen:BaremetalHost

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

Die Ausgabe könnte so aussehen:

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

Problemumgehung:

Rufen Sie den Namen und den Namespace des nodePoolClaim ab, zu dem der Server gehört:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'

Die Ausgabe könnte so aussehen:

{
"name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
"namespace": "gpu-org-lancer"
}

Rufen Sie den Namen des Betriebssystem-Images aus NodePoolClaim ab:

kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'

Rufen Sie die URL des Betriebssystem-Images über OSImageMetadata ab:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'

Aktualisieren Sie die benutzerdefinierte Ressource Server mit der neuesten Betriebssystem-Image-URL:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'

OS NodeUpgrade bleibt möglicherweise im Schritt „NodeOSInPlaceUpgradePostProcessingCompleted“ hängen

Versionen: 1.14.3, 1.14.4

Symptome:

Während eines Knoten-Upgrades bleibt NodeUpgradeTask im Schritt NodeOSInPlaceUpgradePostProcessingCompleted mit einem Reconciler-Fehler mit der Meldung failed verifying delta after upgrade hängen und kann nicht abgeschlossen werden. Dieser Fehler weist darauf hin, dass bei der Überprüfung des Upgrades unerwartete Paketabweichungen auf dem Knoten gefunden wurden. Insbesondere werden Pakete identifiziert, die sich entweder noch im Status „need-upgrade“ befinden oder nach dem Upgrade-Versuch als „only-in-new“-Pakete angezeigt werden.

In der Fehlermeldung werden bestimmte Pakete aufgeführt, bei denen die Bestätigung fehlgeschlagen ist. Beispiel für ein Snippet:

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

Dieses Symptom kann zwei Ursachen haben. Ermitteln Sie zuerst, welches Problem die Ursache ist:

Cause-A: Die Maschine ist nicht erreichbar, wodurch OSArtifactSnapShot veraltet ist.

Prüfen Sie, ob der Knoten, der aktualisiert wird, noch fehlerfrei ist und ob der entsprechende OSArtifactSnapShot-Job fehlschlägt.

Wenn OSArtifactSnapShot veraltet ist und das Gerät seit mehr als 20 Minuten nicht erreichbar ist, fahre mit Mitigation-A fort. Andernfalls suchen Sie weiter nach Cause-B.
Cause-B: Fehler beim stillen RPM-Upgrade

In seltenen Fällen kann das RPM-Upgrade auf einem Computer nach einem teilweisen Upgrade ohne Fehlermeldung fehlschlagen. Es sollten zwei ConfigMaps mit der Paketdifferenz vor und nach dem Upgrade vorhanden sein:
```
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
```
Wenn die ConfigMap „after-upgrade“ weniger Pakete enthält als die ConfigMap „before-upgrade“, bedeutet das, dass das Upgrade ohne Benachrichtigung abgebrochen wurde und nicht alle Pakete aktualisiert wurden. Fahren Sie weiter in Richtung Mitigation-B.

Problemumgehung:

Mitigation-A: Fehlerbehebung für nicht erreichbare Maschine

Versuchen Sie, den Computer durch einen Neustart zu reparieren. Wenn die Maschine nach mehreren Neustartversuchen immer noch nicht erreichbar ist, wenden Sie sich an das SERV-Team. Wenn die Maschine wieder erreichbar ist, löschen Sie OSArtifactSnapShot, um die Abstimmung zu erzwingen. Sobald OSArtifactSnapShot abgeglichen wurde, sollte NodeUpgradeTask mit dem nächsten Schritt fortfahren.

Mitigation-B: NodeUpgradeTask noch einmal versuchen

Stellen Sie eine SSH-Verbindung zur Maschine her, die aktualisiert wird, und erfassen Sie die folgenden Logs für die zukünftige Fehlerbehebung. Die folgenden Dateien sollten gesammelt werden:
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf history > dnf_history.log
- rpm -qa --last > rpm_last.log
Löschen Sie die fehlerhafte NodeUpgradeTask. Dadurch wird ein erneuter Versuch für die NodeUpgradeTask auf dem jeweiligen Knoten ausgelöst. Die neue NodeUpgradeTask sollte das RPM-Upgrade abschließen und mit dem nächsten Schritt fortfahren.

OS NodeUpgrade bleibt möglicherweise beim Erstellen des Paketservers hängen

Versionen: 1.14.3, 1.14.4

Symptome:

Wenn ein NodeUpgrade-CR erstellt und die Pausierung aufgehoben wird und es länger als 30 Minuten im Status in-progress bleibt, kann es bei der Erstellung des Paketservers zu einem stillen Fehler kommen. Das Symptom ist ein NodeUpgrade mit dem Status .status.upgradeStatus=in-progress, aber es ist kein .status.tasks geladen:

status:
  duration: 0s
  upgradeStatus: in-progress

Um zu bestätigen, dass dies beim Erstellen des Paketservers fehlschlägt, lesen Sie das OS-Upgrade-Controller-Log:

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Wenn im Controller-Log failed to create package server und failed to create package repo server DNS registration mit detailliertem Grund (einer der folgenden) angezeigt werden

spec.fqdnPrefix already used in an existing DNS registration
name already used in an existing DNS.

Dann wird vorgeschlagen, dass einige andere Paketserverressourcen, die von anderen NodeUpgrade verwendet werden, noch aktiv sind und mit der zu erstellenden Ressource für das aktuelle hängende NodeUpgrade in Konflikt stehen.

Problemumgehung:

Zur weiteren Bestätigung können Sie die tatsächliche Paketserverressource (einer bestimmten API, z. B. dnsregistration.network.private.gdc.goog im Management-API-Server des Clusters, der die benutzerdefinierte Ressource NodeUpgrade verwaltet) prüfen und die NodeUpgrade finden, die diese Ressource besitzt. Wenn die NodeUpgrade, die Eigentümer der DNSRegistration ist, bereits abgeschlossen ist, die DNSRegistration-Ressource aber noch nicht gelöscht wurde, können Sie das DNSRegistration-Objekt löschen, wenn alle referenzierten NodeUpgrade-Objekte abgeschlossen sind.

Listen Sie alle DNSRegistration-CRs für den NodeUpgrade-Paketserver auf:

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm

So fragen Sie den Eigentümer des NodeUpgrade-Kundenkontos nach einem bestimmten DNSRegistration:

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'

Bei Upgrades des Knotenbetriebssystems können Probleme auftreten und der Prozess kann in jeder Phase angehalten werden.

Versionen: 1.14.4, 1.14.5, 1.14.6

Symptome:

NodeUpgradeTask CR still under in-progress for more than 2 hours, though it might able to auto complete given enough time.

Die NodeUpgradeTask-Anfrage läuft seit mehr als zwei Stunden. Die automatische Vervollständigung kann zwar irgendwann erfolgen, das zugrunde liegende Problem ist jedoch, dass der os-policy-reconciler eine große Anzahl von OSPolicy-CRs nicht effizient verwalten kann. Dieses Problem tritt während des Schritts NodeOSInPlaceUpgradeCompleted auf.

Weitere Informationen zur Bestätigung dieses Fehlers beim Erstellen des Paketservers finden Sie im Protokoll des OS-Upgrade-Controllers.

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

Wenn im Controller-Log kein OSPolicy-Eintrag von NodeUpgradeTask vorhanden ist, bedeutet das, dass der Controller überlastet ist.

Problemumgehung:

Pausieren Sie während des Upgrades alle nicht wichtigen OSPolicy-Kampagnen.

„storage cp“ einer großen Datei führt zu Ausfall von org-mgmt kube-api

Versionen: 1.14.3 und höher

Symptome: Während eines gdcloud storage cp- oder gdcloud system container-registry load-oci-Vorgangs von einer OIC-Arbeitsstation aus besteht eine geringe Wahrscheinlichkeit, dass der Zugriff auf die Organisationsinfrastruktur verloren geht und die kube-api von org-mgmt ausfällt. Dieses Problem tritt nur selten auf. Das Erheben von Daten für das Engineering-Team ist hilfreich.

Problemumgehung: Wenn dieses Problem auftritt, versuchen Sie Folgendes:

Führen Sie für jeden Knoten der Steuerungsebene (Control Plane, CP) uptime aus, um zu prüfen, ob die Knoten in den letzten 24 Stunden neu gestartet wurden.
Notieren Sie sich die Uhrzeit des Neustarts.
Prüfen Sie mit dem Befehl dmesg | grep -i 'kernel panic', ob auf den einzelnen CP-Knoten kurz vor dem Neustart Kernel-Panics aufgetreten sind.
Prüfen Sie auf jedem CP-Knoten, ob Mellanox-NIC-Karten installiert sind: lspci | grep -i eth | grep -i mellanox. Wenn keine Mellanox-NICs vorhanden sind, können Sie diesen Abschnitt überspringen.

Prüfen Sie auf jedem CP-Knoten die folgenden Netzwerkeinstellungen auf data0:

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: on  # <--- Check this value

Wenn rx-gro-hw (siehe oben) für alle Knoten auf „off“ festgelegt ist, können Sie diesen bekannten Fehler ignorieren.

Stellen Sie Google einige Informationen zur Verfügung, damit das Problem leichter diagnostiziert werden kann:

k8s.org get po -n anthos-identity-service -l k8s-app=ais

k8s.org get po -n management-kube-system

k8s.org get po -n kube-system -l component=kube-apiserver

k8s.org get nodes -l node-role.kubernetes.io/control-plane

Führen Sie auf jedem CP-Knoten die folgenden Befehle aus:

dmesg | grep -i 'kernel panic'

journalctl -u disable-rx-gro-hw.service

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

Um das Problem mit den Netzwerkeinstellungen zu beheben, muss rx-gro-hw auf allen CP-Knoten off sein. Führen Sie dazu die folgenden Befehle aus:

ethtool -K data0 rx off gro off lro off
ethtool -K data1 rx off gro off lro off
ethtool -K bond00 rx off gro off lro off

Prüfen Sie die Einstellungen noch einmal:

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: off # <--- Check this, should be "off"

Wiederholen Sie den ursprünglichen Vorgang, z. B. gdcloud storage cp oder gdcloud system container-registry load-oci. Wenn weiterhin ein Fehler auftritt, wenden Sie sich an das Engineering-Team.

Operations Suite Infrastructure Core Services (OIC)

Schlechte Jumphost-Leistung

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

Symptome: Browser- oder Systemvorgänge dauern übermäßig lange.

Problemumgehung:

Erhöhen Sie die Anzahl der vCPUs auf den Jumphosts über den Hyper-V-Manager auf BM03 und BM04:

Wählen Sie eine Jumphost-VM aus und klicken Sie im Aktionsbereich auf die Einstellungen.
Wählen Sie Prozessor aus und erhöhen Sie dann die Anzahl unter Anzahl der virtuellen Prozessoren auf mindestens 4, je nach Arbeitslast.
Wiederholen Sie den Vorgang für die verbleibenden Jumphosts.

Resource manager

Projekte können in der GDC Console nicht gelöscht werden

Versionen: 1.14.3, 1.14.4

Symptome: In der GDC Console wird auf der Seite Projektdetails die Schaltfläche Löschen Löschen für vorhandene Projekte angezeigt, aber die Schaltfläche funktioniert nicht.

Problemumgehung: Wenn Sie ein vorhandenes Projekt löschen möchten, müssen Sie die gcloud CLI verwenden. Weitere Informationen finden Sie unter Projekt löschen.

Fehlende Ansible-Playbooks für die Organisation

Versionen: 1.14.3

Symptome: Beim Erstellen einer Organisation schlägt der Job create-ansible-playbooks, mit dem die erforderlichen Ansible-Playbooks erstellt werden, im Hintergrund fehl. Die fehlenden Ansible-Playbooks führen zu Problemen wie fehlenden Perimeter-VMs und Problemen beim Erstellen einer globalen Organisation.

Problemumgehung: Folgen Sie dem OS-R0009-Runbook, um die fehlenden Ansible-Playbooks für die Organisation manuell zu erstellen.

Asymmetrische globale Organisation zeigt nicht vorhandene zonale Konfigurationen an

Versionen: 1.14.4

Symptome: Wenn Sie eine globale Organisation der Version 1 mit nur einer Teilmenge der zonalen Organisationskonfigurationen erstellen, wird in allen Zonen weiterhin ein Organisationsreplikatstatus angezeigt. Wenn Sie beispielsweise ein GDC-Universum mit drei Zonen haben, aber nur eine zonale Organisationskonfiguration für zwei Zonen erstellen, wird für die dritte Zone weiterhin ein fehlerhafter Replikastatus für die nicht vorhandene dritte zonale Organisation angezeigt.

Um den fehlerhaften Status zu bestätigen, geben Sie den Status der globalen Organisation aus:

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

Die YAML-Ausgabe sieht etwa so aus:

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

Dies tritt nur bei v1-Organisationen auf, da asymmetrische zonale Konfigurationen für v2-Organisationen nicht unterstützt werden.

Problemumgehung: Sie können den fehlerhaften Replikatstatus ignorieren, da die zonale Organisation nur vorhanden ist, wenn Sie sie explizit erstellt haben.

Cluster

Der Worker-Knotenpool des Infrastrukturclusters wird nicht gelöscht

Versionen: 1.14.3, 1.14.4

Symptome: Wenn Sie einen Worker-Knotenpool aus der Organization-CR-Spezifikation entfernen, wird der Knotenpool nicht automatisch gelöscht. Das heißt, der Befehl kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} gibt weiterhin den zu löschenden Knotenpool aus.

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

Problemumgehung: Nachdem Sie den Worker-Knotenpool aus der Organization-CR-Spezifikation entfernt haben, löschen Sie die NodePoolClaim-CR für diesen Knotenpool manuell aus dem Administratorcluster des Stammverzeichnisses, indem Sie den folgenden Befehl ausführen: sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Warten Sie, bis NodePoolClaim und die zugehörigen NodePool-CRs vollständig gelöscht wurden. Das bedeutet, dass der Worker-Knotenpool nicht mehr in der Ausgabe des Befehls kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} enthalten ist.

Speicher

Mit dem Befehl `gdcloud config set zone` erstellte Buckets können nicht gelöscht werden

Versionen: 1.14.7 und höher

Symptome: Mit dem Befehl gdcloud config set zone erstellte Buckets können aufgrund von Berechtigungsproblemen nicht gelöscht werden, da der Befehl versucht, in der falschen Zone zu arbeiten.

Problemumgehung: Legen Sie die spezifische Zone für einen Bucket in der Konsole fest oder ersetzen Sie das Flag --zone im gcloud-Befehl durch --location.

OBJ-SLO-Benachrichtigungen ausgelöst

Versionen: 1.14.3, 1.14.4

Symptome: SLO-Benachrichtigungen für OBJ werden aufgrund des ErrFailedStreamingDecryptRequest-Fehlers im OBJ-Proxy ausgelöst: obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.

Problemumgehung: Schalten Sie die Benachrichtigung stumm. Der Fehler wird fälschlicherweise als Systemfehler identifiziert, obwohl er durch das Beenden der Verbindung durch den Nutzer verursacht wird. Dies wird nicht auf das SLO angerechnet.

S3 UploadPart Empty ETag

Versionen: 1.14.3

Symptome: Nach dem Senden einer UploadPart-Anfrage erhalten Sie in der Antwortnachricht den Statuscode 200 Success, das ETag-Feld ist jedoch leer. Dieser Fehler tritt auf, weil aufgrund einer Netzwerkunterbrechung ein InternalServerError auftritt und der Statuscode nicht auf 500 InternalServerError aktualisiert wird.

Problemumgehung: Wiederholen Sie die Anfrage so, als wäre sie zuvor fehlgeschlagen.

Pods können aufgrund des Trident-Fehlers `mkfs.ext4` nicht bereitgestellt werden

Versionen: 1.14.3

Symptome: Nach dem Versuch, Pods zu mounten, stellen Sie fest, dass alle Pods, die zu oder von einem bestimmten Knoten wechseln, fehlschlagen. Die RPC-Fehlermeldung DeadlineExceeded desc = context deadline exceeded wird angezeigt, was darauf hindeutet, dass der Knoten nicht reagiert. Wenn diese Meldung angezeigt wird, können Sie keine zusätzlichen Trident-Vorgänge auf dem betreffenden Knoten ausführen. Volumes, die Daten bereitstellen, sind nicht betroffen. Bei Volumes, die zum und vom Knoten verschoben werden, kann es jedoch zu einem Ausfall kommen.

Problemumgehung:

Sehen Sie sich die Trident-Logs auf dem Knoten an, auf dem der Pod versucht, das Volume einzuhängen, und prüfen Sie, ob die Warteschlange länger wird. Die Logs könnten so aussehen:

2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"

Melden Sie sich am Knoten an und sehen Sie sich die dmesg-Ausgabe an. Die Logs könnten so aussehen:

Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)

Nachdem Sie bestätigt haben, dass ein Trident-Fehler mkfs.ext4 aufgetreten ist, starten Sie den Knoten neu.

Trident kann ein Volume aufgrund eines bereits vorhandenen Fehlers nicht erstellen

Versionen: 1.14.3

Symptome:

Ein PVC wird nicht bereitgestellt und es wird ein Ereignis wie das folgende angezeigt:

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

Wenn dieses Ereignis eintritt, wird der PVC erst bereitgestellt, wenn Sie den Workaround ausführen.

Problemumgehung:

So können Sie das Problem beheben:

Notieren Sie sich den internen Volumennamen aus dem Ereignis. Das im Abschnitt Symptome angezeigte Beispielereignis enthält beispielsweise den internen Volumennamen trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
Folgen Sie dem Runbook FILE-R0105, um auf ONTAP zuzugreifen.

So löschen Sie das Volume:

volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

`file_block_iscsi_sessions_unhealthy alert` meldet falsch positives Ergebnis

Versionen: 1.14.3

Symptome: In einigen Umgebungen wird die file_block_iscsi_sessions_unhealthy-Benachrichtigung ausgelöst, die darauf hinweist, dass auf einem oder mehreren Knoten iSCSI-Fehler auftreten. Der file-observability-Controller verwendet einen benutzerdefinierten Messwerterfassungsprozess, um den Status der iSCSI-Sitzungen auf jedem Kubernetes-Knoten zu verfolgen. In einigen Fällen kann der Messwerterfassungsprozess die Ausgabe des Befehls iscsiadm jedoch nicht parsen und meldet null laufende iSCSI-Sitzungen, obwohl iSCSI fehlerfreie Sitzungen hat.

Problemumgehung:

Führen Sie die folgenden Schritte aus, um zu prüfen, ob bei iSCSI Probleme auftreten, und um die Benachrichtigung zu deaktivieren, wenn es sich tatsächlich um ein falsch-positives Ergebnis handelt:

Führen Sie auf der Seite „Explore“ in Grafana die Abfrage fb_sessions_running_count{job="file-observability-backend-target.file-system"} aus. Die Abfrage gibt einen Messwert für jeden Knoten im Cluster zurück. Wenn für einen Knoten der Messwert fb_sessions_running_count mit dem Wert 0 gemeldet wird, notieren Sie sich den Namen des Knotens.
Führen Sie für jeden Knoten, für den fb_sessions_running_count-Messwerte mit dem Wert 0 zurückgegeben werden, die folgenden Befehle aus:
1. Stellen Sie eine SSH-Verbindung zum betroffenen Knoten her.
2. Führen Sie den Befehl iscsiadm -m session aus. Es müssen mehrere Zeilen zurückgegeben werden. Jede Zeile steht für eine aktive iSCSI-Sitzung. Wenn der Befehl nichts zurückgibt oder Fehler in der Ausgabe enthalten sind, eskaliere das Problem an das Entwicklungsteam für Dateisperren.
3. Wenn der vorherige Befehl iSCSI-Sitzungen zurückgegeben hat, haben Sie bestätigt, dass die Benachrichtigung für diesen Knoten ein falsch-positives Ergebnis ist.
Wenn Sie bestätigen, dass alle betroffenen Knoten fehlerfreie iSCSI-Sitzungen haben und der Alarm fälschlicherweise ausgelöst wird, erstellen Sie in AlertManager eine Stummschaltung für den file_block_iscsi_sessions_unhealthy-Alarm.

`file_block_storage_disk_failure`-Benachrichtigung wird für Ersatzlaufwerke ausgelöst

Versionen: 1.14.3

Symptome: In einigen Umgebungen wird die file_block_storage_disk_failure-Benachrichtigung ausgelöst, die darauf hinweist, dass mindestens eine Festplatte in ONTAP fehlerhaft ist. Der file-observability-Controller verwendet einen benutzerdefinierten Messwerterfassungsprozess, um den Zustand jeder Festplatte in ONTAP zu erfassen. In früheren Versionen von GDC wird eine Ersatzfestplatte jedoch nicht als fehlerfrei betrachtet und es wird eine Benachrichtigung für die Ersatzfestplatte ausgelöst.

Problemumgehung:

So bestätigen Sie, dass die Festplatten Ersatzfestplatten sind, und blenden die Benachrichtigung für die Festplatte aus:

Führen Sie auf der Seite „Explore“ in Grafana die Abfrage disks_labels_healthy{job="file-observability-backend-target.file-system"} aus. Die Abfrage gibt einen Messwert für jede Festplatte in ONTAP zurück. Wenn für ein Laufwerk ein Messwert von 0 (nicht fehlerfrei) gemeldet wird, notieren Sie sich den Namen des Laufwerks.
Führen Sie für jede Festplatte, für die disks_labels_healthy-Messwerte mit dem Wert 0 zurückgegeben werden, die folgenden Befehle aus:
1. Stellen Sie eine SSH-Verbindung zum ONTAP-Cluster her und führen Sie den Befehl disk show -disk <disk-name> -fields state mit dem aus der Messwertabfrage abgerufenen Festplattennamen aus.
2. Prüfen Sie, ob der Status des Laufwerks in der Ausgabe des Befehls entweder present oder spare ist. Wenn sich das Laufwerk in einem anderen Status als present oder spare befindet, eskalieren Sie das Problem an das Engineering-Team für Dateiblocks.
3. Wenn für das betreffende Laufwerk present oder spare gemeldet wird, können wir bestätigen, dass für dieses Laufwerk keine Benachrichtigung ausgelöst werden sollte. Erstellen Sie in AlertManager eine Stummschaltung für die Benachrichtigung file_block_storage_disk_failure, wobei das Label disk_name auf den Namen des Laufwerks festgelegt ist.
Nachdem Stummschaltungen für alle Ersatzlaufwerke erstellt wurden, rufen Sie Grafana auf, um zu prüfen, ob die Benachrichtigungen nicht mehr ausgelöst werden.

Die Benachrichtigung „file_block_storage_node_peer_connection_unhealthy“ wird ausgelöst, nachdem die Verbindung wiederhergestellt wurde

Versionen: 1.14.3

Symptome: In einigen Umgebungen wird die file_block_storage_node_peer_connection_unhealthy-Warnung ausgelöst, die darauf hinweist, dass eine oder mehrere Verbindungen zwischen den ONTAP-Knoten fehlschlagen. Der file-observability-Controller verwendet einen benutzerdefinierten Messwerterfassungsprozess, um den Zustand dieser Verbindungen zu verfolgen. Es gibt ein bekanntes Problem, bei dem diese Benachrichtigung auch dann weiterhin ausgelöst wird, wenn die fehlgeschlagene Verbindung wiederhergestellt wurde.

Problemumgehung:

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Verbindungen zwischen den Knoten fehlerfrei sind, und um die Benachrichtigung für die Knoten zu deaktivieren:

Führen Sie auf der Seite „Explore“ in Grafana die Abfrage storage_node_peer_connections{job="file-observability-backend-target.file-system"} aus. Die Abfrage gibt einen Messwert für jede Verbindung zwischen Speicherknoten im Cluster zurück. Wenn für Verbindungen der Messwert storage_node_peer_connections mit dem Wert 0 gemeldet wird, notieren Sie sich die Labels source_node, destination_ip und storage_cluster_name des Messwerts.
Führen Sie für jede storage_node_peer_connections-Messwert, der 0 zurückgibt, die folgenden Befehle aus:
1. Stellen Sie über das Label storage_cluster_name eine SSH-Verbindung zum ONTAP-Storage-Cluster her.
2. Führen Sie den folgenden Befehl im ONTAP-Cluster mit den Werten aus den Labels source_node und destination_ip aus:
```
ping -node <node-name> -destination <destination-ip> -verbose -show-detail
```
Wenn der Ping-Befehl fehlschlägt, eskalieren Sie das Problem an das Entwicklerteam für Dateiblocks. Wenn der Ping-Befehl erfolgreich ist, sind die Knotenverbindungen in Ordnung und die Benachrichtigung wird fälschlicherweise ausgelöst.
1. Erstellen Sie in AlertManager eine Stummschaltung, um die Benachrichtigung file_block_storage_node_peer_connection_unhealthy mit den Labels source_node und destination_ip, die auf den Quellknoten und die Ziel-IP aus dem Messwert festgelegt sind, stummzuschalten.
Nachdem Stummschaltungen für alle fehlerfreien Knoten erstellt wurden, rufen Sie Grafana auf, um zu prüfen, ob die Benachrichtigungen nicht mehr ausgelöst werden.

Die Benachrichtigung „file_block_nodes_not_reachable“ wird nach dem Wiederherstellen der Verbindung ausgelöst

Versionen: 1.14.3

Symptome: In einigen Umgebungen wird die Benachrichtigung file_block_nodes_not_reachable ausgelöst, die darauf hinweist, dass eine oder mehrere Verbindungen von den IPsec-Diensten auf den Kubernetes-Knoten zu ONTAP fehlschlagen. Der file-observability-Controller verwendet einen benutzerdefinierten Messwerterfassungsprozess, um den Zustand dieser Verbindungen zu verfolgen. Es gibt ein bekanntes Problem, bei dem diese Benachrichtigung auch dann weiterhin ausgelöst wird, wenn die fehlgeschlagene Verbindung wiederhergestellt wurde.

Problemumgehung:

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Verbindungen auf den Knoten fehlerfrei sind, und um die Benachrichtigung für die Knoten zu deaktivieren:

Führen Sie auf der Seite „Explore“ in Grafana die Abfrage fb_all_nodes_reachable{job="file-observability-backend-target.file-system"} aus. Die Abfrage gibt einen Messwert für jeden Knoten im Cluster zurück. Wenn für einen Knoten der Messwert fb_all_nodes_reachable mit dem Wert 0 gemeldet wird, notieren Sie sich den Namen des Knotens.
Führen Sie für jeden Knoten, für den fb_all_nodes_reachable-Messwerte mit dem Wert 0 zurückgegeben werden, die folgenden Befehle aus:
1. Stellen Sie eine SSH-Verbindung zum betroffenen Knoten her.
2. Führen Sie dazu diesen Befehl aus:
```
journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
```
  Mit dem Befehl wird versucht, ontap über alle IPsec-Verbindungen zu pingen. Wenn Pings im Befehl fehlschlagen, eskaliere das Problem an das Engineering-Team für Dateiblocks. Wenn die Ping-Befehle erfolgreich sind, sind die Knotenverbindungen in Ordnung und die Benachrichtigung wird fälschlicherweise ausgelöst.
3. Wenn alle Pings im Befehl erfolgreich sind, haben wir bestätigt, dass die Verbindungen auf dem Knoten in Ordnung sind und der Alarm fälschlicherweise ausgelöst wird. Erstellen Sie in AlertManager eine Stummschaltung für die file_block_nodes_not_reachable-Benachrichtigung, wobei das Label node_name auf den Namen des Knotens festgelegt ist.
Nachdem Stummschaltungen für alle fehlerfreien Knoten erstellt wurden, rufen Sie Grafana auf, um zu prüfen, ob die Benachrichtigungen nicht mehr ausgelöst werden.

`file_block_storage_high_node_total_latency`-Benachrichtigung wird bei hoher Arbeitslast ausgelöst

Versionen: 1.14.3

Symptome: Die Benachrichtigung file_block_storage_high_node_total_latency kann in bestimmten Umgebungen aufgrund hoher Arbeitslasten auf Speicherknoten ausgelöst werden. Diese Benachrichtigung wird so lange angezeigt, bis diese Arbeitslasten vollständig verarbeitet wurden. Auch wenn die Lese- und Schreibleistung auf Volumes hoch ist, können Speicherknoten für bestimmte Blockvorgänge eine hohe Latenz melden.

Problemumgehung:

So prüfen Sie, ob die Latenzen des Volumes in Ordnung sind, und deaktivieren die Benachrichtigung zur Latenz des Speicherknotens:

Latenzbenachrichtigungen für Volumes prüfen:
1. Prüfen Sie in Grafana, ob die Benachrichtigungen file_block_storage_high_volume_write_latency und file_block_storage_high_volume_read_latency ausgelöst werden und ob für die Volumes optimale Latenzzeiten gemeldet werden.
Eskalieren, wenn die Volume-Latenz hoch ist:
1. Wenn entweder die Warnungen für das Schreiben oder Lesen von Volumes ausgelöst werden, deutet dies auf eine hohe Latenz im gesamten Speichersystem hin. Eskaliere dieses Problem an das Entwicklerteam für Dateisperren.
Latenzwarnung für Knoten stummschalten (wenn Volumes fehlerfrei sind):
1. Wenn sowohl die Warnungen für das Schreiben auf Volumes als auch für das Lesen von Volumes fehlerfrei sind, ist die Warnung für die Knotenlatenz wahrscheinlich ein Fehlalarm.
2. Erstellen Sie in AlertManager eine Stummschaltung für die file_block_storage_high_node_total_latency-Benachrichtigung.
3. Nachdem Sie die Stummschaltung erstellt haben, rufen Sie Grafana auf, um zu bestätigen, dass der Alarm nicht mehr ausgelöst wird.

Blockiertes Knotenupgrade

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Symptome: Diese Blockierung tritt auf, wenn eine LUN (Logical Unit Number) schreibgeschützt wird, was häufig auf Probleme mit Snapshots zurückzuführen ist. In diesem Fall wird der Knoten abgesichert, um den betroffenen Pod auf einen anderen Knoten zu verschieben. Da beim Knotenupgradeprozess eine Vorabprüfung durchgeführt wird, um sicherzustellen, dass Knoten nicht gesperrt sind, wird das Upgrade in diesem Zustand verhindert.

Problemumgehung: Deaktivieren Sie die Unterkomponente file-read-only-lun-cleanup manuell, bevor Sie den Upgradevorgang starten:

Ermitteln Sie jede betroffene Organisation.

Wenden Sie für jede Organisation in der Umgebung ein SubcomponentOverride an.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: file-read-only-lun-cleanup
  namespace: ORG_NAMESPACE
spec:
  subComponentRef: "file-read-only-lun-cleanup"
  disable: true

Prüfen Sie, ob keiner der Knoten in den betroffenen Organisationen gesperrt ist:

Listen Sie die Knoten in der Organisation auf:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

Die Ausgabe sieht etwa so aus:

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

Notieren Sie sich die Namen der Knoten mit dem Status SchedulingDisabled. In dieser Beispielausgabe ist der abgesperrte Knoten admin-node0-zone1.

Entfernen Sie die Knoten, die im vorherigen Schritt den Status SchedulingDisabled zurückgegeben haben, aus der Quarantäne:
```
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
```

Prüfen Sie, ob alle Knoten bereit sind:

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

Die Ausgabe sieht etwa so aus:

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

`file_block_zombie_luns_present`-Benachrichtigung wird nach Behebung von Mehrwegfehlern ausgelöst

Versionen: 1.14.3 und höher

Symptome: Die Benachrichtigung file_block_zombie_luns_present wird möglicherweise in bestimmten Umgebungen ausgelöst, weil der file-observability-Controller die Ausgabe des Befehls multipath -ll nicht parsen kann. Dies führt dazu, dass die Benachrichtigung zu Zombie-LUNs ständig ausgelöst wird, auch wenn der Multipath-Dienst auf allen Knoten fehlerfrei funktioniert.

Problemumgehung:

So prüfen Sie, ob die Multipath-Dienste auf den betreffenden Knoten einwandfrei funktionieren:

Führen Sie auf der Seite „Explore“ in Grafana die Abfrage zombie_lun_exists{job="file-observability-backend-target.file-system"} aus. Die Abfrage gibt einen Messwert für jeden Knoten im Cluster zurück. Wenn für einen Knoten der Messwert zombie_lun_exists mit dem Wert 1 angegeben ist, notieren Sie sich den Namen des Knotens.
Führen Sie für jeden Knoten, für den zombie_lun_exists-Messwerte mit dem Wert 1 zurückgegeben werden, die folgenden Befehle aus:
1. Stellen Sie eine SSH-Verbindung zum betroffenen Knoten her.
2. Führen Sie dazu diesen Befehl aus:
```
multipath -ll
```
  Der Befehl gibt Informationen zu allen Blockgeräten zurück, die vom Multipath-Dienst verwaltet werden. Prüfen Sie, ob der Status eines der Blockgeräte den String failed undef unknown oder den String failed faulty running enthält.
3. Wenn Geräte den Status failed faulty running haben, folgen Sie dem FILE-R0020-Runbook, um die Zombie-LUNs zu beheben.
4. Wenn Geräte den Status failed undef unknown haben, folgen Sie dem FILE-R0021-Runbook, um die Super-Zombie-LUNs zu beheben.
Zombie-LUN-Warnungen stummschalten, wenn Knoten fehlerfrei sind:
1. Wenn auf keinem der Knoten ungültige Blockgeräte gefunden werden, ist die Warnung zu Zombie-LUNs ein Falsch-Positiv.
2. Erstellen Sie in AlertManager eine Stummschaltung für die file_block_zombie_luns_present-Benachrichtigung.
3. Nachdem Sie die Stummschaltung erstellt haben, rufen Sie ServiceNow auf, um zu bestätigen, dass keine weiteren Benachrichtigungen mehr ausgelöst werden.

Leeren Bucket kann nicht über die Console gelöscht werden

Versionen: 1.14.4 und höher

Symptome: In der GDC-Konsole können Sie einen leeren Bucket nicht löschen. Der Bucket kann Löschmarkierungen und möglicherweise andere Versionen von Objekten enthalten, wenn die Objektversionsverwaltung mit Aufbewahrungsrichtlinien aktiviert ist. Möglicherweise wird ein Fehler wie dieser angezeigt:

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

Problemumgehung: Verwenden Sie den Befehl gdcloud storage rm -a, um Objekte, einschließlich Löschmarkierungen, zu löschen, damit der Bucket gelöscht werden kann.

System Artifact Registry

Harbor-Replikationsjobs bleiben hängen

Versionen: 1.14.3

Symptome:Replikationsjobs für Harbor-Artefakte bleiben hängen. Dieses Problem verhindert die Verteilung von Artefakten an Organisationen und die Erstellung von Organisationen.

Problemumgehung: Folgen Sie der Anleitung im SAR-R1010-Runbook, um das Problem zu beheben.

Der vorübergehende Fehlerstatus wird beim Abgleichen der benutzerdefinierten Ressource des Harbor-Roboterkontos nicht gelöscht.

Versionen: 1.14.3

Symptome:Eine CustomResourceErrorStatusAlert-Benachrichtigung mit dem Label kind=HarborRobotAccount und code=SAR2002 wird fälschlicherweise ausgelöst. Die falsche Benachrichtigung hat beispielsweise das Feld message auf „Error getting robot: failed to list robots: 503 Service Unavailable“ (Fehler beim Abrufen des Roboters: Fehler beim Auflisten von Robotern: 503 Service Unavailable) festgelegt.

Problemumgehung:Bitten Sie den Infrastruktur-Operator (IO), zu prüfen, ob die Benachrichtigung ein echtes Problem oder ein Fehlalarm ist, und die Benachrichtigung stummzuschalten, wenn es sich um einen Fehlalarm handelt. Folgen Sie dazu der Anleitung unten.

Wenn eine Warnung ausgelöst wird, folgen Sie dem Runbook SAR-E2002, um die zugrunde liegende Ursache der Warnung zu ermitteln und zu beheben.

Aufgrund dieses bekannten Problems kann der Alarm fälschlicherweise weiterhin ausgelöst werden, auch wenn das Runbook die zugrunde liegende Ursache erfolgreich behebt. Prüfen Sie weiterhin den Fehlerstatus des Zielobjekts der benutzerdefinierten Ressource (CR) HarborRobotAccount (HRD), für das eine Benachrichtigung gesendet wird:

Legen Sie die erforderlichen Umgebungsvariablen fest:
```
export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE
```
Ersetzen Sie Folgendes:
- KUBECONFIG: Der Pfad zur kubeconfig-Datei.
- HRD_NAME: der Name der Ziel-HarborRobotAccount-CR.
- HRD_NAMESPACE: der Namespace, der die Ziel-HarborRobotAccount-CR enthält.

Prüfen Sie den Fehlerstatus der Ziel-CR HarborRobotAccount:

kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'

Wenn der lastUpdateTime-Wert angibt, dass das Feld errorStatus vor mehr als 30 Minuten zuletzt aktualisiert wurde, ist die Benachrichtigung ein Fehlalarm. Um den Fehlalarm zu beheben, müssen Sie die Benachrichtigung in der Air-Gap-Instanz von GDC stummschalten. Folgen Sie dazu dem MON-R2009-Runbook.

Fehlalarm für SAR-R0003-Benachrichtigung

Versionen: 1.14.3 und höher

Symptome:Eine Benachrichtigung mit dem Code SAR-R0003, dem OC SAR und dem Schweregrad critical wird fälschlicherweise ausgelöst.

Problemumgehung:Folgen Sie dem MON-R2009-Runbook, um die Benachrichtigung stummzuschalten.

Ticketsystem

ServiceNow MID Server kann nicht richtig gestartet werden

Versionen: 1.14.3

Behoben: 1.14.4

Symptome: Der ServiceNow MID-Server, der in Splunk integriert ist, kann sich beim Start aufgrund einer Versionsabweichung nicht bei ServiceNow registrieren.

Problemumgehung:

Pausieren Sie die Unterkomponente ts-mid-server.

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

Überschreiben Sie die MID Server-Versionszeichenfolge.

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

Upgrade

Die Annotation des Shared Service-Clusters wird nach einem erfolgreichen Cluster-Upgrade nicht aktualisiert

Versionen: 1.14.4

Symptome:Die CRs für Perimeter- und Shared Service-Cluster für clusters.baremetal.cluster.gke.io spiegeln nach dem Upgrade die richtige GKE-Version wider. In den clusters.cluster.gdc.goog-CRs wird weiterhin die vorherige GKE-Version angezeigt.

Problemumgehung:Aktualisieren Sie die Annotation upgrade.gdc.goog/version in clusters.baremetal.cluster.gke.io auf den neuen UserClusterMetadata-Namen, der der aktualisierten GKE-Version entspricht.

Upgrade des Knotens des Organisationsadministrators bleibt hängen

Versionen: 1.14.6

Behoben: 1.14.7

Symptome:Der Knoten-Upgrade-Prozess für die Administrator-Steuerungsebene der Organisation gdchservices bleibt hängen. Das Knoten-Upgrade schlägt fehl, weil keine SSH-Verbindung zum Knoten hergestellt werden kann. Dies führt zu einem Connection timed out-Fehler.

Add-on-Upgrade bleibt hängen

Versionen: 1.14.6

Behoben: 1.14.7

Symptome:Das Add-on-Upgrade für den Stammadministratorcluster bleibt während des Upgrades von einer früheren 1.14.x-Version auf 1.14.6 hängen. Eine Statusmeldung kann darauf hinweisen, dass das Upgrade das erwartete Zeitlimit überschritten hat:

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

Problemumgehung: Aktualisieren Sie die spec.addOnSetTemplateRef der addonset-Ressource des Root-Administrators manuell, damit sie auf die richtige Vorlage für die neue Version verweist.

Supportbericht schlägt fehl

Versionen: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Behoben: 1.14.7

Symptome:Der Befehl gdcloud resource-support get-report schlägt fehl, wenn er aufgrund eines Berechtigungsproblems für einen Nutzercluster ausgeführt wird.

VM-Bootvorgang bleibt nach Abschluss des OS-Knoten-Upgrades hängen

Versionen: 1.14.6

Symptome: Während des Upgrades von 1.14.3 auf 1.14.6 können virtuelle Maschinen in den Perimeter- oder Shared Service-Clustern nicht gestartet werden und sind nach einem Betriebssystem-Upgrade nicht mehr erreichbar.

Mit dem folgenden Befehl kann das Problem beispielsweise bestätigt werden:

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

Die Ausgabe des VM-Konsolenlogs enthält eine Kernel-Panic-Meldung, die in etwa so aussieht:

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

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

Legen Sie die folgenden Umgebungsvariablen fest:

export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
export VM_NAMESPACE=VM_NAMESPACE
export VM_NAME=FAILED_VM_NAME

Beenden Sie die fehlgeschlagene VM:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
    $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

Öffnen Sie den Editor, um das Bootlaufwerk von der fehlgeschlagenen VM zu trennen:
```
kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
```

Ersetzen Sie das Bootlaufwerk in der VM-Spezifikation durch einen Platzhalternamen:

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      # This is a random placeholder name you put here. Doesn't need to exist
      name: VM_DISK_PLACEHOLDER_NAME

So erstellen Sie ein Secret für das Startskript:

cat <<'EOF' > script
#!/bin/bash
username="newuser"
password="Lime+blaze8legend"
sudo useradd -m -s /bin/bash "$username"
echo "$username:$password" | sudo chpasswd
sudo usermod -aG sudo "$username"
EOF

kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script

Helfer-VM erstellen:

Rufen Sie das VM-Image für das VM-Bootlaufwerk ab. Das Image darf nicht dieselbe Betriebssystemfamilie wie das Bootlaufwerk des Problem-VM-Knotens haben. Verwenden Sie daher grep, um das Ubuntu-Image zu finden:

# find the latest ubuntu-20.04 OS version
UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')

Erstellen Sie das VM-Bootlaufwerk und die VM. Erstellen Sie ein neues Bootlaufwerk und eine neue VM mit einem angehängten sekundären Laufwerk und einem Startskript für den Konsolenzugriff:

kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: HELPER_VM_BOOT_DISK_NAME
spec:
  source:
    image:
      name: UBUNTU_OS_VERSION
      namespace: vm-system
  size: 20Gi
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: HELPER_VM_NAME
spec:
  compute:
    virtualMachineType: n3-standard-2-gdc
  disks:
  - virtualMachineDiskRef:
      name: HELPER_VM_NAME-disk
    boot: true
    autoDelete: true
  - virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK
    autoDelete: false
  startupScripts:
  - scriptSecretRef:
      name: configure-password
    name: configure-password
EOF

Prüfen Sie, ob die Helper-VM ausgeführt wird:

kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME

Stellen Sie eine Verbindung zur Konsole der Helfer-VM her und generieren Sie initramfs neu:

Konsole zur Helfer-VM:

kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG

Verwenden Sie die folgenden Anmeldedaten:

username="newuser"

password="Lime+blaze8legend"

Stellen Sie die Partitionen des angehängten Laufwerks bereit:

sudo mkdir /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/

sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
sudo mount -t proc procfs /mnt/kernelpanic/proc/
sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/

Stellen Sie eine Chroot-Verbindung zum Bereitstellungspunkt her und generieren Sie die initramfs neu:
```
sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force
```

Prüfen Sie, ob das neue Initramfs für die neue Kernelversion 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 generiert wurde:

ls /boot/initramfs-* -l

Die Ausgabe sieht dann ungefähr so aus:

-rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
-rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
-rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img

Beenden Sie die Helfer-VM:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

Trennen Sie das Laufwerk von der Helfer-VM:

Öffnen Sie die Spezifikation der Helfer-VM in einem Editor:

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME

Entfernen Sie den folgenden Code aus der YAML-Datei:

- virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

Hängen Sie das Bootlaufwerk wieder an die fehlerhafte VM an:

Öffnen Sie die Spezifikation der fehlgeschlagenen VM in einem Editor:

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

Aktualisieren Sie die Spezifikation so:

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK

Starten Sie die fehlerhafte VM:

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'

Prüfen Sie, ob das Upgrade behoben wurde:

Prüfen Sie, ob die benutzerdefinierte Node-Ressource für diese VM Ready enthält und die neuere Kernelversion 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 verwendet:

kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide

Die Ausgabe sieht etwa so aus:

NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0

Prüfen Sie die Kernelversion, nachdem Sie eine SSH-Verbindung zur VM hergestellt haben:
```
uname -a
```
In der Ausgabe muss die neue Kernelversion 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 angezeigt werden.

Ingester bleibt fehlerhaft und wird nach dem Upgrade nicht automatisch vergessen

Versionen: 1.14.x

Symptome:Die Unterkomponente log-infra ist nach dem Upgrade nicht fehlerfrei. Führen Sie Folgendes aus, um den Status zu prüfen: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Wenn Sie den Status einer Unterkomponente prüfen möchten, müssen Sie die kubeconfig des übergeordneten Clusters für KUBECONFIG und den Namespace des aktuellen Clusters für CLUSTER_NAMESPACE verwenden. Der Befehl gibt den STATUS der Unterkomponente zurück. Wenn der STATUS nicht ReconciliationCompleted ist, ist die untergeordnete Komponente in diesem Cluster fehlerhaft.

Einige Loki-Pods im Cluster sind fehlerhaft. Führen Sie den folgenden Befehl aus, um alle Loki-Pods aufzulisten: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Mit diesem Befehl werden alle Loki-Pods angezeigt, einschließlich der Spalten STATUS und READY. Ein Pod gilt als fehlerhaft, wenn sein STATUS nicht Running ist oder wenn einige seiner Container nicht bereit sind. In der Spalte READY, die als a/b formatiert ist, wird die Anzahl der einsatzbereiten Container a von insgesamt b angegeben. Ein Pod ist fehlerfrei, wenn a und b gleich sind.

Prüfen Sie die Logs auf fehlerhafte Loki-Pods: none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

Beispiel-Ausgabelogs von fehlerhaften Pods sehen so aus:

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

Problemumgehung:Informationen zum Löschen eines fehlerhaften Ingesters aus dem Loki-Ring finden Sie im Runbook AL-R0031.

Vertex AI

Bei Übersetzungsanfragen kann der Fehlercode `RESOURCE_EXHAUSTED` ausgegeben werden

Versionen: 1.14.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.14.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 gesetzt 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: SHARED_SERVICE_CLUSTER_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true
```
Ersetzen Sie SHARED_SERVICE_CLUSTER_NAMESPACE durch den Namespace des Clusters mit freigegebenen Diensten.
Wenden Sie die benutzerdefinierte Ressource SubcomponentOverride auf den Administratorcluster der Organisation an:
```
kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
```
Ersetzen Sie ORG_MGMT_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Verwaltungsclusters im Administratorcluster der Organisation.

Der Frontend-Pod und ‑Dienst für die Übersetzung oder OCR können nicht initialisiert werden.

Versionen: 1.11.x, 1.12.x, 1.13.x, 1.14.x

Symptome:Während Upgrades wird der DB-Cluster neu erstellt. Dadurch ist das ODS-Secret-Store-Secret im Shared-Service-Cluster veraltet und nicht mehr synchron. Aus diesem Grund schlägt die Initialisierung des Frontend-Pods und -Dienstes für die Übersetzung oder OCR fehl.

Problemumgehung:

Löschen Sie das Secret im Shared-Service-Cluster:

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

Ersetzen Sie SHARED_SERVICE_CLUSTER_KUBECONFIG durch den Pfad zur kubeconfig-Datei im Shared-Service-Cluster.

Wenn der problematische Dienst Translation ist, ersetzen Sie VAI_API_NAMESPACE durch „g-vai-translation-sie“. Wenn der problematische Dienst OCR ist, ersetzen Sie VAI_API_NAMESPACE durch „g-vai-ocr-sie“.

Ein Controller erstellt das Secret automatisch neu und synchronisiert es wieder mit dem Datenbankcluster.

Vertex AI Search

Suchkomponenten bleiben im Status „Abstimmung“

Versionen: 1.14.6

Symptome:Die Unterkomponenten vaisearch-conversation und vaisearch-frontend bleiben im Status Reconciling, wenn in der Organisation keine benutzerdefinierte Ressource SearchConfig erstellt wird.

Problemumgehung:Das Problem kann ignoriert werden. Nachdem die benutzerdefinierte SearchConfig-Ressource erstellt wurde, sollten die untergeordneten Komponenten die Abstimmung abschließen.

Server

BIOS-Anmeldedatenrotation bleibt in der Phase „Zurücksetzen angefordert“ hängen

Versionen: 1.14.4

Symptome:Die Rotation der BIOS-Anmeldedaten bleibt im Status „Zurücksetzung angefordert“ hängen. Sie können dies überprüfen, indem Sie die gdch.cluster.gke.io/rotation-status-Annotation für das Secret mit den BIOS-Anmeldedaten des Servers prüfen:

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

Ersetzen Sie SERVER_NAME durch den Namen des Servers. Die Ausgabe des Befehls ist „reset-requested“, wenn die Rotation nicht funktioniert.

Problemumgehung:Folgen Sie dem SERV-R0018-Runbook, um die BIOS-Anmeldedatenrotation abzuschließen.

Bereitstellung zuvor installierter Server nicht möglich

Versionen: 1.14.6

Symptome:Die Bereitstellung von Servern schlägt fehl, nachdem sie aufgehoben und neu bereitgestellt wurden. Das Problem hängt insbesondere mit Problemen bei der iLO-Schlüsselverwaltung (Integrated Lights-Out) und der HSM-Schlüsselverwaltung (Hardware Security Module) zusammen. Auf den Servern, die zuvor Teil einer deaktivierten Organisation waren, treten bei der Bereitstellung von Images Fehler auf. Das deutet darauf hin, dass kein geeignetes Gerät gefunden werden kann, was oft an gesperrten Festplatten aufgrund alter oder gelöschter Schlüssel liegt. Möglicherweise wird ein Fehler wie der folgende angezeigt:

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

Problemumgehung:Löschen Sie die betroffenen Server und installieren Sie sie neu, damit sie bereitgestellt werden können. Weitere Informationen finden Sie in den Runbooks SERV-R0020 und SERV-R0021.

Virtuelle Maschinen

Image-Import schlägt fehl

Versionen: 1.14.4. 1.14.5

Behoben: 1.14.6

Symptome:Der Import eines Bildes mit dem Befehl gdcloud compute images import schlägt aufgrund von Sitzungszeitüberschreitungen mit dem Fehler Unauthorized fehl.

Problemumgehung: Verwenden Sie für den Import von eigenen Images die KRM API anstelle der gcloud CLI.

Der Import von KRM-Bildern dauert lange

Versionen: 1.14.6 und höher

Symptome:Der Import eines Bildes mit der KRM API dauert lange. Die VirtualMachineImageImport-Ressource verbleibt über einen längeren Zeitraum im Status TranslationJobInProgress. Das deutet darauf hin, dass die Übersetzungsphase nicht wie erwartet abgeschlossen wird. Der image-translation-Pod wechselt in den Status CrashLoopBackOff.

Problemumgehung:

Versuchen Sie den Import noch einmal, indem Sie eine neue VirtualMachineImageImport-Ressource mit einem anderen Namen erstellen.
Behalten Sie den Status von VirtualMachineImageImport im Blick, indem Sie die Ressource regelmäßig prüfen, bis sich ihr Status in WaitingForTranslationJob ändert. Weitere Informationen finden Sie im VMM R0007-Runbook.

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

Sichern und wiederherstellen

Bearbeiten des Wiederherstellungsplans für Clustersicherungen ist nicht möglich

Ungültige Größe des Quelllaufwerks

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

SLOs für Sicherung und Wiederherstellung werden nicht angewendet

Aufbewahrungsrichtlinien werden nicht auf importierte Sicherungen angewendet

Teilweise VM-Sicherung schlägt fehl

Verwaiste Sicherungsressourcen nach dem Löschen von Nutzer- oder Dienstclustern bereinigen

Das Löschen von VirtualMachineRestore wird über die CLI oder die Benutzeroberfläche nicht unterstützt.

Der Sicherungs-Steuerungsebenen-Pod stürzt aufgrund von unzureichendem Arbeitsspeicher ab

Löschung des Nutzerclusters hängt

Die Wiederherstellung hängt aufgrund eines ausstehenden Anspruchs auf ein nichtflüchtiges Volume fest

Clusterverwaltung

Die Unterkomponente „kub-gpu-controller“ wird nicht abgeglichen

Knotenpool kann nicht aus Standardcluster entfernt werden

Cluster hängt im Status „Wird gelöscht“ fest

Datenbankdienst

Klonen der AlloyDB Omni-Datenbank bleibt hängen

DNS

„GlobalCustomerRootDNSServerNotReachable“ löst fälschlicherweise eine Benachrichtigung aus

Datei-/Blockspeicher

Fileshare-Volume kann in VM nicht bereitgestellt werden

Firewall

Für die Adresse im Subnetz-CR fehlt eine Sicherheitsrichtlinienregel.

GDC-Firewalls lehnen Traffic in Richtung OIR sowohl für die Verwaltungs- als auch für die Datenebene ab.

GDC-Firewall lehnt zonen- und organisationsübergreifenden Traffic ab

Die Firewall unterstützt keine AttachmentGroup, deren Kennung mit dem Organisationsnamen übereinstimmt

Hafen

Harbor-CLI-Secret wird nach Sicherung und Wiederherstellung ungültig

Harbor-Sicherungs- und ‑Wiederherstellungsjob konkurriert um Berechtigung

Größe der Harbor-Sicherung wird als 0 angezeigt

Berechtigungsfehler bei Sicherungsressourcen auf der Konsolenseite der Harbor-Registrierung

Seite „Rotation des Datenbankpassworts hängt“

Hardwaresicherheitsmodul

Deaktivierte HSM-Testlizenzen sind weiterhin erkennbar

HSM-Host-Daemon-Dateideskriptor-Datenleck

HSMs schlagen nach dem Hochfahren mit dem Fehler ValidateNetworkConfig fehl

Integrität

SLO-Fehlalarme

Ungültige SLO-Konfigurationen auf Grundlage von Messwerten

Identitäts- und Zugriffsverwaltung

Fehler beim Erstellen der IAM-Rollenbindung

Fehler beim Erstellen der IAM-Rollenbindung für Projekt-Dienstkonten

Verzögerungen bei der Erstellung vordefinierter Rollen in neuen Projekten

In der GDC-Konsole kann keine erste Rollenbindung erstellt werden.

AOs können sich selbst keinen Zugriff auf Rollen im Infrastrukturcluster gewähren.

Vorhandenes Dienstkonto-Token wird ungültig

Infrastruktur als Code (IaC)

Abstimmungsfehler bei der Unterkomponente aufgrund eines fehlenden Namespace

Erfassung von IAC ConfigSync-Messwerten schlägt fehl

IAC RootSync schlägt fehl

Inventar

Inventarprüfung kann nicht abgeglichen werden

Schlüsselverwaltungssystem

Für KMS, die für die Verwendung eines CTM-Root-Schlüssels konfiguriert sind, erfolgt kein Failover, wenn ein HSM nicht verfügbar ist

Load-Balancer

Erstellen eines globalen Load-Balancers schlägt aufgrund von CIDR-Erschöpfung des Subnetzes fehl

Durch das Ändern von Load-Balancer-Ressourcen werden Dienste nicht abgeglichen

Falsche Zonenamen werden nicht abgelehnt

Webhook-Fehler bei globalen und zonalen Load Balancern

Logging

Loki-Pod stürzt ab oder wird während der WAL-Wiedergabe (Write-Ahead Log) durch OOMKilled beendet

Workaround prüfen

Überschreibung und Objekt-Proxy bereinigen

Monitoring

AlertManager-Webhooks senden für einige Cluster keine Benachrichtigungen

ServiceNow-Vorfälle werden gelegentlich dupliziert

Infrastrukturmesswerte sind möglicherweise zu sensibel

Abstimmungsmesswerte sind möglicherweise zu sensibel

Im Stammadministratorcluster sind zwei falsche Benachrichtigungen offen.

Controller-Manager des Root-Administrators weist eine hohe Fehlerrate auf

In KUB-Dashboards werden in allen PA-Bereichen keine Daten angezeigt

Berechtigungen für die Rolle „observability-admin-debugger“ sind falsch konfiguriert

Grafana-Debugger-Rolle fehlt

Zonenübergreifende Messwerte und Logs sind nach dem Hinzufügen einer neuen Zone nicht sichtbar

Der Finalizer MonitoringTarget verhindert das Löschen des Namespace.

Das Löschen des Projekts bleibt aufgrund von ausstehenden Finalizern für Dashboard und Datenquelle hängen

Messwerte aus KSM sind nicht sichtbar

Die Messwertpipeline des Systems ist ausgefallen

Die Unterkomponente „`kub-gpu-controller`“ wird nicht abgeglichen

HSMs schlagen nach dem Hochfahren mit dem Fehler `ValidateNetworkConfig` fehl

Der Finalizer `MonitoringTarget` verhindert das Löschen des Namespace.

Anpassen der Reihenfolge von `MultiZoneNetworkConfig`-Zonen führt zu einem Fehler beim Ersetzen der Konfiguration

Mit dem Befehl `gdcloud config set zone` erstellte Buckets können nicht gelöscht werden

Pods können aufgrund des Trident-Fehlers `mkfs.ext4` nicht bereitgestellt werden

`file_block_iscsi_sessions_unhealthy alert` meldet falsch positives Ergebnis

`file_block_storage_disk_failure`-Benachrichtigung wird für Ersatzlaufwerke ausgelöst

`file_block_storage_high_node_total_latency`-Benachrichtigung wird bei hoher Arbeitslast ausgelöst

`file_block_zombie_luns_present`-Benachrichtigung wird nach Behebung von Mehrwegfehlern ausgelöst

Bei Übersetzungsanfragen kann der Fehlercode `RESOURCE_EXHAUSTED` ausgegeben werden

`batchTranslateDocument`Anfragen geben Fehler zurück`503`