Problemi noti di Google Distributed Cloud con air gap 1.14.x

Backup e ripristino

La modifica del piano di ripristino del backup del cluster non funziona

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomi:

La risorsa personalizzata RestorePlan non può essere modificata utilizzando la console GDC.

Soluzione temporanea:

Crea un nuovo piano di ripristino ed elimina quello precedente oppure modifica il piano di ripristino utilizzando kubectl CLI.

Dimensioni del disco di origine non valide

Versioni: 1.14.4, 1.14.5

Sintomi:l'interfaccia utente mostra in modo errato le dimensioni di un disco pari a 0 MB e l'ora di creazione come "Sconosciuta" a causa di una modifica del modello dei dati di backend dopo la migrazione all'architettura dell'organizzazione v2.

Soluzione: non esiste un metodo alternativo per visualizzare queste informazioni tramite la UI.

Riavvio dei pod dell'agente e del control plane a causa di memoria insufficiente

Versioni: 1.14.3, 1.14.4

Sintomi:i pod dell'agente e del control plane potrebbero riavviarsi se esauriscono la memoria.

Soluzione alternativa: aumenta la memoria per i pod del control plane e dell'agente seguendo le istruzioni nel runbook BACK-R0005. Aumenta la memoria per i pod a 2 GiB.

Gli SLO di backup e ripristino non vengono applicati

Versioni: 1.14.3, 1.14.4

Sintomi: le metriche e gli avvisi dell'obiettivo del livello di servizio (SLO) di GDC non sono configurati per impostazione predefinita, in quanto la definizione di risorsa personalizzata necessaria non è installata. Questi avvisi vengono utilizzati in Grafana.

Soluzioni alternative: Per attivare gli SLO per il backup e il ripristino in GDC, segui il runbook BACK-T0001.

I criteri di conservazione non vengono applicati ai backup importati

Versioni: possono essere interessate tutte le versioni di Google Distributed Cloud (GDC) con air gap.

Sintomi:il collegamento di un repository di backup al cluster sincronizza tutti i metadati di backup e ripristino e considera i repository come backup importati. Questi backup importati vengono ignorati erroneamente durante la riconciliazione, il che significa che i criteri di conservazione vengono ignorati e i backup vengono conservati a tempo indeterminato.

Soluzione: i backup importati sono etichettati con backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME. Per consentire la riconciliazione normale e l'applicazione dei criteri di conservazione, rimuovi l'etichetta dai backup utilizzando i seguenti comandi kubectl:

1. Imposta le variabili di ambiente richieste:

   export KUBECONFIG=KUBECONFIG
   export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
   export NAMESPACE=BACKUP_PLAN_NAMESPACE
   

   Sostituisci quanto segue:

   • KUBECONFIG: il percorso del file kubeconfig.
   • BACKUP_REPOSITORY_NAME: il nome del repository di backup.
   • NAMESPACE: lo spazio dei nomi che contiene il piano di backup.

2. Elenca tutti i backup importati:

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

3. Rimuovi le etichette in base alle esigenze:

   • Rimuovi le etichette da tutti i backup:

     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-
     

   • Rimuovi le etichette per un singolo backup:

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

Il backup parziale della VM non riesce

Versioni: 1.14.3, 1.14.4

Sintomi: se il backup di una VM su più VM non riesce, l'intero backup della VM viene contrassegnato come non riuscito.

Soluzione alternativa: limita il numero di VM per piano di backup.

Eseguire la pulizia delle risorse di backup orfane dopo l'eliminazione del cluster utente o di servizio

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomi: quando viene eliminato un cluster utente o di servizio, le risorse dell'agente di backup associate (come StatefulSet, pod, secret e così via) create nell'infrastruttura dell'organizzazione e nel cluster di gestione non vengono pulite automaticamente. Ciò può lasciare risorse orfane e, se il cluster viene creato di nuovo con lo stesso nome, il pod dell'agente di backup non funziona.

Soluzione alternativa: le risorse orfane esistono in uno spazio dei nomi dedicato nel cluster di infrastruttura dell'organizzazione. Per pulirli, devi eliminare questo spazio dei nomi.

1. Imposta i file kubeconfig per l'infrastruttura dell'organizzazione e i cluster di gestione.

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

2. Identifica lo spazio dei nomi delle risorse orfane. Lo spazio dei nomi segue il pattern gpc-backup-<cluster-name>-system. Ad esempio:

   • gpc-backup-user-vm-1-cluster-system
   • gpc-backup-user-vm-2-cluster-system
   • gpc-backup-g-org-1-shared-service-cluster-system

3. Elimina lo spazio dei nomi. Verranno eliminate tutte le risorse al suo interno, inclusi StatefulSet e pod dell'agente di backup nell'infrastruttura e il secret nel cluster di gestione.

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

4. Per confermare che la pulizia è stata eseguita correttamente, esegui di nuovo il comando get all.

   # 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:?}"
   

   Il comando ora dovrebbe non riuscire perché lo spazio dei nomi non esiste più. Dovresti visualizzare un errore come Error from server (NotFound): namespaces "<namespace-name>" not found.

L'eliminazione di VirtualMachineRestore non è supportata tramite CLI o UI

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomi: il controller VirtualMachineRestore non esegue automaticamente la pulizia delle risorse sottostanti (VolumeRestore, Restore) dopo l'eliminazione di una risorsa VirtualMachineRestore. Ciò richiede l'esecuzione di una pulizia manuale. Ciò vale sia per l'eliminazione tramite kubectl delete sia tramite l'interfaccia utente.

Soluzione alternativa: la soluzione alternativa prevede l'eliminazione manuale delle risorse dipendenti nell'ordine corretto e poi la rimozione del finalizzatore dalla risorsa VirtualMachineRestore.

1. Imposta il file kubeconfig in modo che punti al cluster di gestione.

   export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
   

2. Identifica il VirtualMachineRestore da eliminare e il relativo spazio dei nomi.

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

3. Trova ed elimina le risorse VolumeRestore associate. Questi vengono creati con un'etichetta che li collega a VirtualMachineRestore.

   # 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:?}"
   

4. Trova ed elimina le risorse Restore associate. Questi vengono creati con un'etichetta che li collega a VirtualMachineRestore.

   # 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:?}"
   

5. Ora esegui kubectl delete se non l'hai già fatto e rimuovi il finalizzatore dalla risorsa VirtualMachineRestore. Questo è il passaggio finale che consente al garbage collector di Kubernetes di eliminare la risorsa.

   kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
   

6. Verifica l'eliminazione.

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

   Il comando dovrebbe restituire un errore NotFound, a conferma dell'eliminazione della risorsa.

Il pod del control plane di backup si arresta in modo anomalo a causa di memoria insufficiente

Versioni: 1.14.4 e successive

Sintomi:il pod gpcbackup-controlplane-controller nello spazio dei nomi di sistema gpc-backup del cluster di infrastruttura dell'organizzazione mostra lo stato CrashLoopBackOff. Quando si verifica questo errore, le operazioni di backup e ripristino non vanno a buon fine, smettono di rispondere o non funzionano come previsto.

Soluzione alternativa: aumenta i limiti di memoria per il deployment di gpcbackup-controlplane-controller seguendo le istruzioni riportate in BACK-R0005. Questo metodo applica un SubcomponentOverride per regolare le richieste e i limiti di CPU e memoria.

L'eliminazione del cluster utente è bloccata

Versioni: 1.14.7 e successive

Sintomi: i cluster sono bloccati nello stato di eliminazione a causa di problemi con il finalizzatore.

Soluzione: controlla se i volumi di archiviazione hanno relazioni SnapMirror prima di eliminare il cluster. Per ulteriori informazioni, vedi BACK-R0109.

Il ripristino è bloccato a causa di una richiesta di volume permanente in attesa

Versioni: 1.14.3 e successive

Sintomi: a volte i controller Persistent Volume Claim (PVC) non sono in grado di comunicare con gli agenti di backup nel cluster dell'infrastruttura dell'organizzazione. Sebbene questo problema non influisca sulla funzionalità di backup, può causare il blocco di un'operazione di ripristino del volume nello stato Pending e il relativo timeout. Questo problema riguarda le operazioni di ripristino che prevedono il ripristino di un volume, ad esempio la funzionalità di ripristino del servizio di database per la clonazione e il ripristino di un carico di lavoro utente.

Se si verifica questo problema, le successive operazioni di ripristino all'interno del cluster interessato non andranno a buon fine finché non riavvii manualmente l'agente di backup corrispondente.

Per confermare che il problema di ripristino è correlato a questo problema specifico, devi esaminare i log dell'agente di backup:

1. Segui IAM-R0005 per ottenere il ruolo di debugger BACK necessario (back-cluster-debugger) applicando la risorsa ExpirationClusterRoleBinding.

2. Segui IAM-R0004 per generare il file kubeconfig per il cluster di infrastruttura dell'organizzazione. Tutti gli agenti di backup vengono eseguiti nel cluster dell'infrastruttura dell'organizzazione.

3. Identifica l'agente di backup che facilita il ripristino:

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

   Sostituisci ORG_INFRA_KUBECONFIG con il percorso del file kubeconfig del cluster di infrastruttura dell'organizzazione.

   L'output è simile al seguente:

   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
   

   Leggi l'output e determina l'agente di backup corrispondente al tuo ripristino. Ad esempio, se lo spazio dei nomi stateful set interessato nell'output è gpc-backup-user-vm-1-cluster-system, l'agente di backup è gpcbackup-agent-user-vm-1.

4. Cerca il messaggio di errore nei log del set con stato per confermare il problema:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
       -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
   

   Sostituisci quanto segue:

   • ORG_INFRA_KUBECONFIG: il percorso del file kubeconfig del cluster di infrastruttura dell'organizzazione.

   • BACKUP_AGENT: l'agente di backup identificato nel passaggio precedente.

   • NAMESPACE: lo spazio dei nomi identificato nel passaggio precedente.

   Se sono presenti log corrispondenti, stai riscontrando questo problema noto.

Soluzione alternativa: per risolvere il problema, segui questi passaggi:

1. Riavvia l'agente di backup:

   kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
      statefulsets/BACKUP_AGENT -n NAMESPACE
   

   Sostituisci quanto segue:

   • ORG_INFRA_KUBECONFIG: il percorso del file kubeconfig del cluster di infrastruttura dell'organizzazione.

   • BACKUP_AGENT: l'agente di backup che hai identificato quando hai confermato il problema.

   • NAMESPACE: lo spazio dei nomi che hai identificato durante la conferma del problema.

   L'output è simile al seguente:

   statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
   

2. Attendi fino a 20 minuti affinché le operazioni in attesa riprendano automaticamente.

Puoi eseguire un altro ripristino per lo stesso cluster di destinazione al termine del riavvio dell'agente di backup. Dopo aver completato questa soluzione alternativa, non ci sono effetti collaterali. È necessario completare questa soluzione alternativa una sola volta per cluster interessato.

Gestione dei cluster

Il sottocomponente kub-gpu-controller non viene riconciliato

Versioni: 1.14.3

Sintomi:il sottocomponente g-gdchservices-shared-service-cluster/kub-gpu-controller nell'organizzazione gdchservices non viene riconciliato. Viene restituito il seguente output:

│ 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
│ >

Questo errore impedisce l'avvio delle macchine GPU nell'organizzazione gdchservices.

Soluzione alternativa:esegui l'upgrade alla versione 1.14.4 o successive per risolvere il problema.

Il cluster standard non può rimuovere un pool di nodi

Versioni: 1.14.3, 1,14.4, 1.14.5

Correzione: 1.14.6

Sintomi: la rimozione dei node pool obsoleti dai cluster standard non va a buon fine e i node pool non vengono eliminati entro i tempi previsti. I cluster standard sono in anteprima privata e potrebbero non essere disponibili per tutti i clienti.

Soluzione alternativa:rimuovi manualmente i node pool obsoleti.

Il cluster è bloccato nello stato di eliminazione

Versioni: 1.14.6 e successive

Sintomi:quando elimini un cluster Kubernetes, potrebbe bloccarsi nello stato Deleting. Controlla lo stato del cluster eseguendo questo comando:

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

L'output è simile al seguente:

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

Puoi anche verificare il problema controllando lo stato dello spazio dei nomi del cluster:

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

L'output è simile al seguente:

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

Lo spazio dei nomi del cluster è bloccato nello stato Terminating e le condizioni NamespaceContentRemaining e NamespaceFinalizersRemaining sono impostate come True.

Soluzione alternativa:per risolvere il problema, segui questi passaggi:

1. Applica una patch all'API delle regole di forwarding:

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

2. Applica una patch all'API dei servizi di backend:

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

Servizio di database

Questa sezione contiene i problemi noti del servizio di database.

Clonazione del database AlloyDB Omni bloccata

Versioni: 1.14.6 e precedenti

Correzione: 1.14.7

Sintomi: quando un utente clona un cluster AlloyDB Omni da un determinato momento nel tempo, il cluster di database clonato si blocca con l'errore DBSE0005 e non può diventare pronto. La risorsa restore.alloydb corrispondente è bloccata nella fase "ProvisionInProgress".

Soluzione alternativa: per risolvere il problema, scegli con attenzione il momento nel tempo da COMPLETETIME dei backup riusciti.

Elenca i backup di AlloyDB Omni disponibili da clonare sul server API di gestione.

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

Output di esempio:

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

Scegli un valore COMPLETETIME come punto nel tempo per la clonazione. Tieni presente che l'orario è UTC.

DNS

GlobalCustomerRootDNSServerNotReachable attiva un falso avviso

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

Sintomi: viene attivato l'avviso DNS DNS-A0021 che suggerisce GlobalCustomerRootDNSServerNotReachable. La CR Probe per global-customer-root-dns in org-mp non ha egress: true in spec.

Soluzione temporanea:

1. Imposta il percorso KUBECONFIG per org-mgmt:

   export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
   

2. Metti in pausa il componente secondario core-mz che gestisce la richiesta personalizzata del probe:

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

3. Modifica la CR del probe corrente da org-mp:

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

4. Aggiorna la specifica in modo da includere egress: True e applica la modifica. Tieni presente che CLUSTER_NAME e GLOBAL_CUSTOMER_ROOT_IP rimangono invariati.

   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
   

Questa soluzione alternativa corregge il probe e gli eventuali falsi avvisi si attenuano in 15 minuti.

Archiviazione di file/blocchi

Impossibile montare il volume di condivisione file nella VM

Versioni: 1.14.6, 1.14.7

Sintomi: si verifica un errore durante l'aggiornamento delle autorizzazioni di archiviazione di rete quando viene aggiunto un nuovo nodo a un cluster, il che può causare il rifiuto delle richieste di montaggio NFS. Potresti visualizzare l'errore access denied by server durante il montaggio di una condivisione file NFS.

Soluzione alternativa: riavvia i riconciliatori file-share o proxy-group oppure modifica la risorsa FileShare per attivare un aggiornamento.

Firewall

Manca la regola del criterio di sicurezza per l'indirizzo nel CR subnet

Versioni: 1.14.3

Sintomi: un'organizzazione non è raggiungibile perché il gruppo di indirizzi firewall non è presente nella risorsa personalizzata della subnet globale creata dal cliente nel server API globale dell'organizzazione.

Soluzione:segui i passaggi descritti nel manuale di assistenza FW-G0002 per aggiungere manualmente una regola dei criteri di sicurezza per consentire il traffico.

I firewall GDC negano il traffico verso OIR sia per il piano di gestione che per il piano dati

Versioni: 1.14.3, 1.14.4

Sintomi: dopo il deployment della risorsa personalizzata OCITTopology, la connettività tra OIR e il control plane e il data plane di GDC viene interrotta.

Soluzione alternativa: segui i passaggi descritti nel manuale di assistenza FW-G0002 per aggiungere manualmente le regole dei criteri di sicurezza nel cluster di amministrazione principale per consentire il traffico.

Sono necessarie le seguenti regole del criterio di sicurezza:

  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

Sostituisci quanto segue:

• OCIT_CIDR: gli intervalli di indirizzi IP nel campo ocitCIDR del questionario di input del cliente (CIQ).
• MGMT_CIDR: gli intervalli di indirizzi IP nel campo oobManagementCIDRs del questionario di input del cliente (CIQ).
• ZONE_INFRA_CIDR: gli intervalli di indirizzi IP nel campo zoneInfraCIDRs del questionario di input del cliente (CIQ).

Il firewall GDC nega il traffico tra zone e organizzazioni

Versioni: 1.14.3, 1.14.4, 1.14.5

Sintomi:il traffico cross-zone e cross-organization è bloccato per impostazione predefinita dai firewall.

Soluzione alternativa:segui i passaggi riportati nel runbook per aggiungere manualmente le regole dei criteri di sicurezza per consentire il traffico.

Il firewall non supporta AttachmentGroup il cui identificatore è uguale al nome dell'organizzazione

Versioni: 1.14.3 e successive

Sintomi: dopo l'implementazione di un AttachmentGroup, se il campo identifier nell'oggetto AttachmentGroup è uguale a orgName, il firewall non riesce ad analizzare questo oggetto e gli aggiornamenti della configurazione del firewall si bloccano. Di seguito è riportato un esempio di AttachmentGroup problematico:

  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

Soluzione:evita di utilizzare il nome dell'organizzazione come identificatore. Esistono alcune opzioni per correggere il AttachmentGroup non valido.

Scegli una delle seguenti opzioni per risolvere il problema relativo a AttachmentGroup.

• Aggiungi una stringa alla fine dell'identificatore originale con un simbolo trattino:

  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
  

• Aggiungi una stringa all'inizio dell'identificatore originale con un simbolo trattino:

  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
  

• Sostituisci l'identificatore originale con una stringa diversa:

  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
  

Porto

Il secret della CLI di Harbor non è più valido dopo il backup e il ripristino

Versioni: 1.14.3

Sintomi: dopo un backup e un ripristino di Harbor, i secret della CLI diventano non validi e devono essere ricreati.

Soluzione alternativa:per risolvere il problema, segui questi passaggi:

1. Accedi a Harbor con un account utente IAP.
2. Fai clic sul tuo nome utente e seleziona Profilo utente.
3. Fai clic su Altro.
4. Crea un altro secret della CLI automaticamente o manualmente.

Per ulteriori informazioni su Harbor in GDC, consulta la panoramica di Harbor.

Il job di backup e ripristino di Harbor compete per l'autorizzazione

Versioni: 1.14.3, 1.14.4

Sintomi:quando esistono più istanze di Harbor in progetti utente diversi, le operazioni di backup e ripristino competono per i controlli dell'accesso basato sui ruoli e registrano un tasso di errore elevato.

Soluzione alternativa:per risolvere questo problema, segui questi passaggi per creare manualmente un binding del ruolo per ogni spazio dei nomi in cui vengono create le istanze Harbor:

1. Imposta le variabili di ambiente richieste:

   INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
   INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
   

   Sostituisci quanto segue:

   • INFRA_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di infrastruttura.
   • INSTANCE_NAMESPACE: lo spazio dei nomi in cui vengono create le istanze Harbor di Managed Harbor Service (MHS).

2. Crea l'associazione di ruolo per la soluzione alternativa:

   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
   

Le dimensioni del backup di Harbor mostrano valori pari a 0

Versioni: 1.14.3, 1.14.4

Sintomi: al momento la misurazione delle dimensioni del backup per i backup di Harbor non è implementata. Nella console GDC, i campi SizeBytes mostrano un valore di 0 e la colonna Dimensioni mostra un valore di 0 MB. Per il momento, questa configurazione è il comportamento previsto.

Errore di autorizzazione per le risorse di backup nella pagina della console di Harbor Registry

Versioni: 1.14.3, 1.14.4

Sintomi:se non disponi del ruolo Amministratore istanza Harbor, visualizzi un errore di autorizzazione nella risorsa di backup quando visualizzi la pagina Harbor Container Registry nella console GDC. Questo errore viene visualizzato perché le informazioni di backup sono state aggiunte di recente alla pagina Harbor Container Registry, ma l'autorizzazione di lettura per la risorsa di backup non è stata concessa ai ruoli IAM diversi da Amministratore istanza Harbor.

Gli altri elementi della console GDC nella pagina Harbor Container Registry continuano a funzionare come previsto. Per ulteriori informazioni sui ruoli in GDC, consulta Definizioni dei ruoli.

La pagina di rotazione della password del database è bloccata

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Sintomi: vengono generati errori relativi all'autenticazione per le richieste al database, ad esempio failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)), e sono presenti molte richieste di rotazione generate automaticamente per un singolo secret ruotabile.

Soluzione alternativa:elimina le richieste di rotazione aggiuntive non pronte per un secret ruotabile.

1. Imposta KUBECONFIG sul server API mp.

2. Esporta lo spazio dei nomi:

   NAMESPACE=haas-system
   

3. Per scoprire se alcuni secret ruotabili in haas-system non sono pronti:

   kubectl get rotatablesecrets -n ${NAMESPACE?}
   

   L'output potrebbe essere simile a questo esempio:

   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
   

4. Esporta il nome del secret ruotabile, ad esempio:

   ROTATABLE_SECRET=haasdb-pw-haas-alice
   

5. Elimina le richieste di rotazione aggiuntive che non sono pronte:

   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?}
   

Modulo di sicurezza hardware

Le licenze di prova HSM disattivate sono ancora rilevabili

Versioni: 1.14.3, 1.14.4, 1.14.5

Sintomi: a causa di un problema noto esistente in CipherTrust Manager, le licenze di prova disattivate sono ancora rilevabili e potrebbero attivare avvisi di scadenza errati.

Soluzione alternativa: consulta HSM-R0003 per verificare le licenze normali attive ed eliminare le licenze di prova disattivate.

Perdita di descrittori di file host-daemon HSM

Versioni: 1.14.x

Sintomi: se gli HSM vengono eseguiti per più di 30 giorni, una perdita di descrittori di file può causare l'interruzione della risposta del servizio host-daemon, con conseguente errore ServicesNotStarted.

Soluzione alternativa:riavvia il servizio host-daemon. Per farlo, chiedi all'operatore dell'infrastruttura di connettersi all'HSM tramite SSH come utente ksadmin ed esegui il seguente comando:

sudo systemctl restart host-daemon

Se non funziona, il tuo IO può riavviare l'HSM non integro.

Gli HSM non funzionano e restituiscono l'errore ValidateNetworkConfig dopo l'avvio

Versioni: 1.14.x

Sintomi: le risorse personalizzate HSM non entrano nello stato Ready e non vanno a buon fine a causa di un errore ValidateNetworkConfig. Questo errore mostra il seguente messaggio: data0 interface MAC address {} is not active. Questo errore si verifica se il sistema viene riavviato e viene impostata un'interfaccia dati principale diversa.

Soluzione alternativa: segui il runbook HSM-R0059 e riapplica la configurazione di rete HSM per la rete di dati. È sicuro seguire questo runbook anche se più di un HSM presenta questo errore.

SALUTE

Avvisi SLO di falso allarme

Versioni: 1.14.3

Sintomi: un indicatore SLO successRange viene attivato erroneamente.

Soluzione: chiedi all'operatore dell'infrastruttura (IO) di verificare se l'avviso è un problema reale o un falso allarme.

A questo scopo, quando viene attivato un avviso, segui il runbook corrispondente per risolvere la causa sottostante dell'avviso relativo all'obiettivo del livello di servizio (SLO).

1. Scenario 1: se il runbook risolve correttamente il problema e l'avviso smette di attivarsi, l'IO può chiudere l'incidente associato.

2. Scenario 2: se il runbook è completato, ma l'avviso continua a essere attivato, si tratta di un potenziale falso allarme. Controlla se lo SLO è violato:

   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" }'
   

3. In base all'output: se conferma che l'avviso è un falso allarme, l'IO deve disattivare l'avviso all'interno dell'istanza air-gap di GDC; in caso contrario, riassegna la richiesta all'assistenza cloud.

4. In entrambi i casi, è opportuno che IO esegua il riassegnamento all'assistenza cloud per verificare che il componente operativo sia integro.

Configurazioni SLO basate su indicatori non valide

Versioni: 1.14.3, 1.14.4

Sintomi: un sottoinsieme di obiettivi del livello di servizio (SLO) non verrà compilato con eventi buoni, cattivi o totali a causa di una configurazione errata. Gli SLO in questione si basano sui contatori Prometheus e devono essere configurati di conseguenza.

Soluzione:

Versione 1.14.3: non è disponibile alcuna soluzione. Di conseguenza, gli avvisi SLO non verranno attivati per gli SLO interessati.

Versione 1.14.4: è disponibile una soluzione alternativa per correggere l'SLO. Per risolvere il problema, l'impostazione isGauge: true deve essere applicata alla specifica SLO.

Esempio di configurazione di un indicatore per un 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
```

L'elenco noto di SLO fisse con questa impostazione è:

• SLO del firewall:
  • fw-packet-discard-errors-slo
  • fw-packet-discard-no-error-slo
  • fw-packet-discard-unknown-protocol-slo
  • fw-uptime-slo
• SLO dei file:
  • 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

Gestione di identità e accessi

Errore durante la creazione dell'associazione di ruoli IAM

Versioni: 1.14.3

Sintomi:i nomi delle associazioni di ruoli IAM vengono generati dal sistema. Questi nomi hanno una lunghezza massima di 63 caratteri, nel formato user-idp-prefix-rolename. Nei casi in cui il nome generato supera il limite di 63 caratteri, non è possibile creare le associazioni dei ruoli. Di conseguenza, le autorizzazioni definite utilizzando ruoli predefiniti o personalizzati non verranno assegnate agli utenti.

Soluzione alternativa: la creazione del binding del ruolo potrebbe riuscire se il nome del ruolo predefinito o personalizzato è molto breve, ad esempio 4-5 caratteri.

Impossibile creare l'associazione di ruoli IAM per project-service-accounts

Versioni: 1.14.3 1.14.4 1.14.5 1.14.6

Sintomi: un account di servizio di progetto (PSA) con il ruolo organization-iam-admin non può utilizzare il comando gdcloud projects add-iam-policy-binding per assegnarsi un altro ruolo, ad esempio il ruolo project-iam-admin. Questa carenza impedisce a un PSA di gestire le proprie autorizzazioni.

Soluzione:verifica di avere il ruolo organization-iam-admin. Quindi, assegnati il ruolo project-iam-admin nello spazio dei nomi del progetto del PSA di destinazione e assegna al PSA il ruolo project-iam-admin. Questa configurazione delle autorizzazioni consente al PSA di assegnare autorizzazioni aggiuntive a se stesso o ad altri PSA.

I nuovi progetti subiscono ritardi nella creazione dei ruoli predefiniti

Versioni: 1.14.3

Sintomi: quando viene creato un nuovo progetto, mancano i ruoli predefiniti, ad esempio project-bucket-object-admin.

Soluzione alternativa: attendi 15-60 minuti o riavvia manualmente il controller iam-org-admin-cm-backend-controller nello spazio dei nomi iam-system nel cluster dell'infrastruttura dell'organizzazione.

La console GDC non può creare il primo binding del ruolo

Versioni: 1.14.4

Sintomi: quando crei la prima associazione di ruoli per una nuova identità di servizio utilizzando la console GDC, la creazione dell'associazione di ruoli viene segnalata come riuscita, ma in realtà non funziona. Qualsiasi ulteriore azione sull'identità del servizio non va a buon fine e non ha effetto, inclusa l'aggiunta di associazioni di ruoli aggiuntive o l'eliminazione di associazioni di ruoli.

Soluzione alternativa: utilizza gcloud CLI per creare il primo binding del ruolo per un'identità di servizio. Tutte le azioni future con l'identità del servizio eseguite utilizzando la console GDC funzionano correttamente dopo l'associazione del primo ruolo. Per ulteriori informazioni, vedi Assegnare un binding del ruolo all'identità del servizio.

Gli AO non possono concedersi l'accesso ai ruoli nel cluster di infrastruttura

Versioni: 1.14.3. 1.14.4

Correzione: 1.14.3 hotfix 21

Sintomi: gli AO non hanno modo di concedere a se stessi o ad altri utenti l'accesso a qualsiasi ruolo nel cluster di infrastruttura.

Soluzione: gli utenti AO devono contattare gli IO per ottenere l'accesso richiesto. I IO possono utilizzare IAC per fornire agli utenti AO l'accesso richiesto.

Il token del account di servizio esistente non è più valido

Versioni: 1.14.3

Correzione: 1.14.3 hotfix 21

Sintomi: il token dell'account di servizio esistente emesso dal cluster utente diventa non valido perché l'argomento service-account-issuer apiserver viene modificato dopo che il cluster è in stato di esecuzione dopo il bootstrap. Questo problema causa l'autenticazione non riuscita del pod, ad esempio il pod con un container secondario istio-proxy, nel cluster utente utilizzando il token del account di servizio e occorrono ore prima che il token del account di servizio venga aggiornato con le nuove configurazioni.

Soluzione: riavvia manualmente il pod sul cluster utente per rinnovare il token dell'account di servizio con le nuove configurazioni.

Infrastructure as Code (IaC)

Riconciliazione del sottocomponente non riuscita a causa dello spazio dei nomi mancante

Versioni: 1.14.3

Sintomi:la riconciliazione di un sottocomponente non va a buon fine. Ciò si verifica perché lo spazio dei nomi config-management-monitoring richiesto non viene creato automaticamente nel cluster gdchservices-mp.

Soluzione alternativa: crea lo spazio dei nomi config-management-monitoring nel cluster gdchservices-mp utilizzando il seguente 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

La raccolta delle metriche di IAC ConfigSync non va a buon fine

Versioni: 1.14.3, 1.14.4

Sintomi: un problema nel sottosistema di monitoraggio ConfigSync di IAC impedisce l'avvio del deployment di otel-collector. Le metriche di Config Sync non vengono raccolte per il monitoraggio e gli avvisi.

Soluzione alternativa:completa i seguenti passaggi nel cluster root-admin:

1. Metti in pausa il sottocomponente iac-configsync-mon.
2. Modifica l'oggetto MetricsProxySidecar/iac-configsync-metrics nello spazio dei nomi config-management-monitoring.

3. Nel file YAML MetricsProxySidecar/iac-configsync-metrics, trova quanto segue:

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

   Modifica questa sezione nel seguente modo:

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

4. Riavvia il deployment di otel-collector nello spazio dei nomi config-management-monitoring.

IAC RootSync non riesce

Versioni: 1.14.3

Sintomi:si è verificato un problema nella sincronizzazione delle risorse di ConfigSync da GitLab ai cluster a causa di un secret iac-creds mancante . I iac-creds non vengono ruotati a causa di un problema di iacmanager.

Soluzione alternativa:completa i seguenti passaggi nel cluster:

1. Segui il runbook IAC-R0015 per risolvere il problema della credenziale segreta iac-creds mancante. Ruota le credenziali di IaC Manager e Config Sync.

Inventario

La riconciliazione del controllo dell'inventario non riesce

Versioni: 1.14.3

Sintomi:la riconciliazione del sottocomponente inv-audit non riesce perché HarborRobotAccount è disponibile solo nel piano di gestione.

Soluzione alternativa: crea un silenzio in AlertManager per disattivare l'avviso component_reconciliation_errors per component: inv.

Sistema di gestione delle chiavi

Il KMS configurato per utilizzare una chiave radice CTM non esegue il failover quando un HSM non è disponibile

Versioni: 1.14.x

Sintomi:alcune richieste a KMS non vanno a buon fine quando un HSM non è disponibile e sono presenti altri HSM disponibili che avrebbero potuto essere utilizzati. Questo problema si verifica solo quando KMS è configurato per utilizzare una chiave radice CTM.

Soluzione alternativa: rimuovi l'HSM non disponibile da HSMCluster seguendo il runbook HSM-P0006. Quindi riavvia il deployment di kms-backend:

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

Questo comando riavvia i pod kms-backend e ristabilisce la connessione agli HSM in HSMCluster.

Bilanciatori del carico

La creazione del bilanciatore del carico globale non riesce a causa dell'esaurimento del CIDR della subnet

Versioni: 1.14.3

Sintomi: la creazione del bilanciatore del carico esterno o interno globale non riesce a causa di indirizzi IP insufficienti nelle subnet globali. Il sistema non è in grado di allocare dinamicamente indirizzi IP per i bilanciatori del carico globali a causa di un controller che utilizza un percorso di codice errato. Il bilanciatore del carico fa riferimento a una sola subnet e, se questa non ha più indirizzi IP disponibili, non è possibile passare a un'altra subnet. Questa limitazione comporta la visualizzazione dell'errore.

Soluzione alternativa:devi creare la tua subnet e creare indirizzi IP statici per le tue risorse ForwardingRule. Per saperne di più sulla creazione di subnet, consulta Configurare le subnet per il networking dei workload. Quando crei una risorsa ForwardingRule, puoi specificare la subnet nel campo cidrRef.

Versioni: 1.14.3

Sintomo: gli oggetti del bilanciatore del carico non entrano nello stato Ready.

Soluzione alternativa: devi creare risorse Backend in cui il campo spec ha un valore. Le risorse Backend identificano gli endpoint per il bilanciatore del carico. Se non viene fornito un valore per il campo spec, potrebbero verificarsi stati di errore.

La modifica delle risorse del bilanciatore del carico non riconcilia i servizi

Versioni: 1.14.3

Sintomi:la modifica delle risorse personalizzate del bilanciatore del carico non riconcilia i servizi di bilanciamento del carico.

Soluzione alternativa:per risolvere il problema, elimina e ricrea il bilanciatore del carico eliminando le risorse BackendService e ForwardingRule del bilanciatore del carico.

I nomi delle zone errati non vengono rifiutati

Versioni: 1.14.3

Sintomi:la risorsa globale BackendService non rifiuta i nomi di zona errati. Se il nome della zona non è corretto, il bilanciamento del carico non riesce anziché convalidare e rifiutare la configurazione.

Soluzione alternativa:devi fornire i nomi corretti delle zone utilizzate. Se il bilanciatore del carico è configurato in modo errato, le risorse personalizzate del bilanciatore del carico devono essere eliminate e ricreate.

Errore del webhook del bilanciatore del carico globale e zonale

Versioni: 1.14.3

Sintomi: viene restituito il seguente errore:

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

Soluzione alternativa:per risolvere il problema, riavvia ed elimina il pod unet-global-cm:

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

Il pod Loki si arresta in modo anomalo o viene terminato a causa di errori di memoria durante la riproduzione di WAL

Versioni: 1.14.3, 1.14.4, 1.14.5

Sintomi:

I pod audit-logs-loki-io nello spazio dei nomi obs-system entrano nello stato CrashLoopBackOff. Ciò è causato da errori prematuri del probe di attività o da un arresto per esaurimento della memoria (OOM) durante la riproduzione del log Write-Ahead (WAL), a causa di un valore wal_replay_ceiling che supera il limite di memoria del pod.

Soluzione:

Segui questi passaggi per modificare la configurazione di Loki in modo da consentire una riproduzione WAL riuscita. Le modifiche devono essere applicate al cluster interessato (ad es. root-admin o org-infra)

1. Imposta KUBECONFIG=/path/to/affected-cluster.kubeconfig come variabile di ambiente.

2. Metti in pausa LoggingPipelineReconciler per impedire al controller di ripristinare le modifiche manuali. Applica questo manifest:

   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"
   

   Conferma che l'override sia attivo. L'output dovrebbe includere "disable-reconcilers=LoggingPipelineReconciler".

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

3. Abbassa il valore di replay_memory_ceiling in ConfigMap audit-logs-loki-io-cm a 8GB.

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

   Modifica la sezione wal:

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

4. (Facoltativo) Scala il proxy dell'oggetto. Se i pod obj-proxy sono vicini ai limiti delle risorse, esegui lo scale up del deployment per gestire l'aumento del carico durante il ripristino.

   a. Controlla l'utilizzo delle risorse:

   kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
   

   b. Se l'utilizzo è elevato, ridimensiona il deployment:

   kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
   

   c. Se necessario, puoi anche aumentare il limite di memoria del pod (ad es. da 12000Mi a 16000Mi).

5. Aumenta le dimensioni del PVC per il pod interessato (ad es. loki-storage-audit-logs-loki-io-0 da 70Gi a 75Gi) per evitare la pressione sul disco. Segui la procedura interna SUPP-R001 per ridimensionare il PVC. Il riavvio nel passaggio successivo applica la nuova dimensione.

6. Aggiungi un startupProbe al audit-logs-loki-io StatefulSet per consentire la riproduzione di WAL prima dell'inizio dei controlli di attività. Il salvataggio della modifica attiva un riavvio sequenziale dei pod (5-10 minuti).

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

   Aggiungi questo startupProbe alla specifica del contenitore audit-logs-loki-io:

   startupProbe:
     failureThreshold: 1000
     httpGet:
       path: /ready
       port: loki
       scheme: HTTP
     periodSeconds: 10
     successThreshold: 1
     timeoutSeconds: 10
   

Verificare la soluzione alternativa

1. Controlla lo stato di pod e StatefulSet: verifica che tutti i pod audit-logs-loki-io siano Running e che StatefulSet mostri tutte le repliche come pronte.

   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}
   

2. Conferma che il PVC è stato ridimensionato. L'output previsto è 75Gi.

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

3. Conferma il recupero WAL riuscito controllando i log del pod per i messaggi errors=false.

   kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
   

4. Verifica che l'utilizzo della directory /wal all'interno del pod sia basso.

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

5. Controlla lo stato di Loki Ring:

   a. Esegui il port forwarding del servizio Loki:

   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. Verifica che tutte le istanze siano in stato integro all'indirizzo http://<DATA_IP>:43100/ring.

Pulisci l'override e il proxy dell'oggetto

Una volta completata la verifica, esegui i seguenti passaggi di pulizia.

1. Rimuovi l'override del sottocomponente:

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

2. Se hai aumentato lo scale up del deployment di obj-proxy, riducilo alle dimensioni originali.

Monitoraggio

I webhook di AlertManager non riescono a inviare avvisi per alcuni cluster

Versione: 1.14.3

Sintomi:i webhook di AlertManager non riescono a inviare richieste e notifiche di avviso a ServiceNow da qualsiasi cluster diverso dal cluster amministratore principale o dal cluster in cui si trova l'istanza ServiceNow. Pertanto, gli avvisi non vengono creati in ServiceNow per l'organizzazione.

Puoi identificare che il webhook non riesce a inviare avvisi se ricevi ripetutamente messaggi di log degli errori. Segui questi passaggi per cercare errori ripetuti:

1. Esporta le variabili di ambiente:

   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   

   Sostituisci MGMT_API_KUBECONFIG con il percorso del file kubeconfig del server API Management.

2. Trova il pod:

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

3. Recupera i log:

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

   Sostituisci POD_NAME con il nome del pod.

4. Cerca errori ripetuti simili ai seguenti:

   Errorsendingtherequest ... read: connection reset by peer
   

Nota: gli errori che riguardano CHANGE_ME indicano che questo webhook non è stato configurato. Questo problema si verifica solo per i cluster che non hanno un'istanza ServiceNow.

Soluzione alternativa:la soluzione alternativa consigliata per questo problema è mettere in pausa due sottocomponenti, uno per gli avvisi di meta-monitoraggio e uno per gli avvisi regolari. Poi, sostituisci l'etichetta egress.networking.gke.io/enabled: "true" con networking.private.gdc.goog/infra-access: enabled nel deployment mon-alertmanager-servicenow-webhook-backend del cluster interessato. Questa etichetta consente al pod di comunicare con altri cluster di infrastruttura senza fare affidamento a un gateway di uscita.

Per applicare la soluzione alternativa consigliata:

1. Esporta le variabili di ambiente:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
   export ORG=ORG
   

   Sostituisci quanto segue:

   • ROOT_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione principale.
   • MGMT_API_KUBECONFIG: il percorso del file kubeconfig del server dell'API Management.
   • ORG: lo spazio dei nomi dell'organizzazione.

2. Metti in pausa i sottocomponenti:

   • Metti in pausa il sottocomponente mon-alertmanager-servicenow-webhook:

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

   • Metti in pausa il sottocomponente mon-meta-monitoring:

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

3. Aggiorna il deployment mon-alertmanager-servicenow-webhook-backend che copre la maggior parte degli avvisi:

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

4. Sostituisci l'etichetta in spec.template.metadata.labels da egress.networking.gke.io/enabled: "true" a networking.private.gdc.goog/infra-access: "enabled".

5. Aggiorna il deployment meta-alertmanager-servicenow-webhook che copre gli avvisi relativi allo stack di monitoraggio:

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

6. Sostituisci l'etichetta in spec.template.metadata.labels da egress.networking.gke.io/enabled: "true" a networking.private.gdc.goog/infra-access: "enabled".

In alternativa, puoi utilizzare Grafana per visualizzare gli stessi avvisi.

Gli incidenti ServiceNow vengono duplicati occasionalmente

Versione: 1.14.3

Sintomi:potresti visualizzare incidenti ServiceNow duplicati per lo stesso pod.

Soluzione alternativa:puoi identificare i ticket duplicati confrontando le impronte nell'incidente.

Le metriche dell'infrastruttura potrebbero essere eccessivamente sensibili

Versione: 1.14.3

Sintomi: potresti visualizzare avvisi per l'allarme oclcm-reconciler-success-rate.

Soluzione: puoi disattivare l'audio dell'avviso in tutta sicurezza. Si tratta di un avviso eccessivamente rumoroso e stiamo lavorando per migliorare il segnale.

Le metriche di riconciliazione potrebbero essere eccessivamente sensibili

Versione: 1.14.3, 1.14.4, 1.14.5

Sintomi: potresti visualizzare avvisi per l'allarme component_reconciliation_errors.

Soluzione:puoi disattivare l'audio dell'avviso in modo sicuro seguendo il runbook MON-R2009. Questo è un avviso eccessivamente rumoroso.

Due falsi avvisi sono aperti nel cluster di amministrazione principale

Versione: 1.14.3

Sintomi:gli avvisi MON-A0001_slow e MON-A0001_fast sono in stato di attivazione nel cluster di amministrazione principale.

L'incidente su ServiceNow è simile al seguente esempio:

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

L'incidente ha la seguente descrizione:

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

Nota: il campo u_organization_id mostra il valore root, ma il cluster nella descrizione è ORG_NAME-admin. Puoi trovare l'avviso nell'istanza Grafana del cluster di amministrazione principale.

Soluzione alternativa:segui questi passaggi per risolvere il problema solo nel cluster di amministrazione principale:

1. Elimina l'etichetta monitoring.gdc.goog/metamonitoring-project=mon-system in mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

2. Elimina tutte le regole di registrazione con nome mon_metrics_pipeline_absent e valore dell'etichetta del cluster ORG_NAME-admin da mon-a0001-blackbox-monitoring-obs-system MonitoringRule.

   L'esempio seguente mostra una regola di registrazione mon_metrics_pipeline_absent da eliminare:

   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
   

Gli avvisi MON_A0001_slow e MON_A0001_fast tornano allo stato Normal dopo alcuni minuti (circa 40 minuti).

Il gestore dei controller dell'amministratore root mostra un tasso di errore elevato

Versione: 1.14.3

Sintomi: potresti visualizzare avvisi per l'allarme ControllerReconciliationErrorRateHigh. Il gestore del controller mostrerà i log con il messaggio: ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

Soluzione: puoi disattivare in sicurezza il controller che genera errori.

1. Esporta le variabili di ambiente:

   export ROOT_KUBECONFIG=ROOT_KUBECONFIG
   

2. Modifica il deployment di Gestione controller amministratore root:

   kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
     -n gpc-system root-admin-controller
   

   Nel contenitore manager, se non è già presente un argomento --disable-reconcilers, aggiungine uno con il valore --disable-reconcilers=ApplianceStorageTunnelReconciler. In caso affermativo, aggiungi il ApplianceStorageTunnelReconciler riconciliatore con una virgola. Ad esempio: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

I log degli errori dovrebbero essere cancellati.

Le dashboard KUB non mostrano dati in tutti i riquadri PA

Versioni: 1.14.3

Sintomi: le dashboard KUB non mostrano dati in tutti i pannelli di Grafana per gli amministratori della piattaforma.

Soluzione: metti in pausa il sottocomponente KSM e aggiorna monitoringtarget e metricsproxysidecar:

1. Metti in pausa il sottocomponente:

   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
   

   Sostituisci quanto segue:

   • ORG_NAME: il nome dell'organizzazione
   • ROOT_ADMIN_KUBECONFIG: il percorso del file kubeconfig di root-admin

2. Aggiungi quanto segue a mon-kube-state-metrics-metrics-proxy metricsproxysidecar nella sezione .spec.destinations:

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

   Il file collaterale metricsproxysidecar aggiornato potrebbe avere il seguente aspetto:

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

3. Rimuovi la sezione matchClusters: da mon-pa-kube-state-metrics monitoringtarget spec. Il mon-pa-kube-state-metrics monitoringtarget spec aggiornato potrebbe avere il seguente aspetto:

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

Autorizzazioni configurate in modo errato per il ruolo observability-admin-debugger

Versioni: 1.14.3, 1.14.4

Sintomi: i pod cortex o prometheus non possono essere riavviati nello spazio dei nomi mon-system.

Soluzione:

Per le organizzazioni:

1. Metti in pausa il sottocomponente iam-common.

2. Aggiorna roleTemplate observability-admin-debugger/iam-system come segue:

   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"
   

Per l'amministratore principale:

1. Metti in pausa il sottocomponente iam-common.

2. Aggiorna roleTemplate observability-admin-debugger-root/iam-system come segue:

   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"
   

Ruolo di debug di Grafana mancante

Versioni: 1.14.3, 1.14.4

Sintomi:il ruolo grafana-debugger-cp non è presente negli spazi dei nomi del progetto shadow di osservabilità (*-obs-system). Agli utenti non può essere concesso il set corretto di autorizzazioni necessarie per eseguire il debug dei problemi relativi a Grafana.

Soluzione alternativa: crea la seguente risorsa personalizzata ClusterRoleTemplate in infra-cp e utilizza il ClusterRole corrispondente creato per ottenere le autorizzazioni grafana-debugger.

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"

Le metriche e i log tra zone non sono visibili dopo l'aggiunta di una nuova zona

Versioni: 1.14.*

Sintomi: la dashboard di Grafana non mostra log e metriche per la zona appena aggiunta.

Soluzione alternativa 1: riavvia il deployment di datasource-proxy:

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

In questo modo, i pod datasource-proxy verranno riavviati e la configurazione dell'endpoint tra zone verrà aggiornata per la zona appena aggiunta.

Il finalizzatore MonitoringTarget blocca l'eliminazione dello spazio dei nomi

Versioni: 1.14.3, 1.14.4

Sintomi:lo spazio dei nomi non viene eliminato e nell'organizzazione corrispondente sono presenti cluster non integri.

Soluzione alternativa:rimuovi manualmente i finalizer dalle risorse personalizzate MonitoringTarget che hanno bloccato l'eliminazione dello spazio dei nomi.

Eliminazione del progetto bloccata a causa di finalizzatori in attesa per dashboard e origine dati

Versioni: 1.14.3, 1.14.4

Correzione: 1.14.3 hotfix 22

Sintomi: i progetti non vengono eliminati e lo spazio dei nomi di terminazione presenta errori come il seguente esempio:

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

Soluzione: elimina manualmente i finalizzatori del dashboard e dell'origine dati.

Le metriche di KSM non sono visibili

Versioni: 1.14.3

Correzione: 1.14.3 hotfix 22

Sintomi: le dashboard KUB mostrano No Data in tutti i pannelli.

Soluzione: metti in pausa il sottocomponente KSM e aggiorna monitoringtarget e metricsproxysidecar.

1. Metti in pausa il sottocomponente:

   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
   

   Sostituisci quanto segue:

   • ORG_NAME: il nome dell'organizzazione.
   • ROOT_ADMIN_KUBECONFIG: il percorso del file kubeconfig di root-admin.

2. Aggiungi quanto segue a mon-kube-state-metrics-metrics-proxy metricsproxysidecar in .spec.destinations:

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

   La metrica mon-kube-state-metrics-metrics-proxy aggiornata di sidecar proxy ha il seguente aspetto:

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

3. Rimuovi la sezione matchClusters: dalla specifica mon-pa-kube-state-metrics monitoringtarget. La specifica mon-pa-kube-state-metrics monitoringtarget aggiornata ha il seguente aspetto:

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

La pipeline delle metriche di sistema non è attiva

Versione: 1.14.3

Sintomi:l'avviso MON-A0001 è attivo anche dopo aver seguito il runbook MON-R0001.

Soluzione temporanea:

1. Se il problema si verifica nel cluster di amministrazione, crea il seguente SubcomponentOverride in root-admin utilizzando il runbook IAC-R0004. Per gli altri cluster, come quello utente, perimetrale o condiviso, crea 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
   

2. Trova il NAMESPACE corretto:

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

   L'output è il seguente:

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

   Lo spazio dei nomi è la radice, se la pipeline non è disponibile per root-admin, o org-1, se la pipeline non è disponibile per org-1 admin:

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

   L'output è il seguente:

   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
   

   In questo caso, lo spazio dei nomi corretto potrebbe essere g-org-1-perimeter-cluster, g-org-1-shared-service-cluster, user-vm-1-cluster o user-vm-2-cluster a seconda del cluster per cui la pipeline delle metriche di sistema non è disponibile.

3. Dopo aver applicato SubcomponentOverride, riavvia il deployment di cortex-tenant nei rispettivi cluster. Controlla se i valori sono aggiornati nel cluster corrispondente:

   kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
   

4. Aggiorna il campo della concorrenza.

5. Riavvia i deployment di cortex-tenant:

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

Multitenancy

La console non indica errori di creazione pool di nodi

Versione: 1.14.4, 1.14.5, 1.14.6

Correzione: 1.14.7

Sintomi: nella console GDC, quando la creazione di un pool di nodi non riesce, l'interfaccia utente mostra erroneamente un messaggio creation in progress, che indica che ipool di nodiol è stato creato correttamente.

Soluzione alternativa:utilizza gcloud CLI per convalidare la creazione del pool di nodi.

Multizona

La zona inaccessibile reindirizza alla pagina di autenticazione

Versione: 1.14.x

Sintomi: quando una zona è inaccessibile, la console GDC reindirizza a una pagina che mostra un errore di autenticazione. Tuttavia, l'inaccessibilità della zona potrebbe non essere causata da un problema di autenticazione, ma piuttosto da un'interruzione zonale.

Soluzione alternativa:utilizza l'URL zonale per risolvere il problema. Se anche l'URL di zona non funziona, chiedi al tuo operatore dell'infrastruttura (IO) di verificare se la zona per cui ricevi problemi di autenticazione non è disponibile.

Il ruolo per visualizzare le zone utilizzando gcloud CLI non viene applicato

Versione: 1.14.x

Sintomi: il ruolo IAM richiesto per utilizzare il comando gdcloud zones list non viene applicato all'universo GDC per impostazione predefinita. Il ruolo mancante, che non è disponibile come ruolo predefinito, impedisce l'utilizzo di gcloud CLI per elencare le zone.

Soluzione alternativa: applica le risorse di binding del ruolo e del ruolo IAM global-zone-viewer al server API globale:

1. Crea un file YAML del ruolo, ad esempio global-zone-viewer.yaml, con i seguenti contenuti:

   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
   

2. Applica il file YAML al server API globale dell'organizzazione:

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

Questo binding del ruolo autentica tutti gli utenti del sistema per visualizzare le zone utilizzando gdcloud zones list.

Errori di accesso intermittenti all'URL della console globale

Versioni: 1.14.x

Sintomi:quando accedi alla console GDC con l'URL globale, potresti ricevere errori che indicano che la tua sessione non è più valida. Questo errore potrebbe essere causato da un bug di rete sottostante e non da una rappresentazione accurata dello stato della sessione.

Soluzione alternativa:accedi alla console GDC con gli URL di zona per gestire le risorse globali da ogni zona. Per saperne di più sul cambio dei contesti di zona dalla console GDC, consulta Gestire le risorse tra le zone.

Networking

La modifica dell'ordine delle zone MultiZoneNetworkConfig causa l'errore di sostituzione della configurazione

Versioni: tutte le versioni 1.14.x possono essere interessate.

Sintomi:

1. Lo stato di READY per i commutatori top-of-rack (ToR) è False. Puoi verificarlo eseguendo il comando seguente:

   kubectl get torswitches -A
   

2. La sostituzione della configurazione dello switch non riesce e viene visualizzato un errore che indica che la voce esiste già. Puoi visualizzarlo nei log di sostituzione della configurazione dello switch. Il messaggio di errore è simile al seguente:

   % Insertion failed - entry already exists
   

Questo problema è causato dalla modifica dell'ordine delle zone all'interno di MultiZoneNetworkConfig. Il sistema genera numeri di sequenza per le regole delle liste di controllo degli accessi BGP in base alla posizione di ogni zona nell'elenco di configurazione. Se l'ordine delle zone viene modificato, il sistema genera nuove regole con numeri di sequenza diversi che sono in conflitto con le regole già presenti sullo switch.

Soluzioni:

Per risolvere questo problema, rimuovi manualmente la configurazione dell'elenco di controllo del percorso AS BGP in conflitto da ogni switch ToR interessato. In questo modo, il sistema può riconciliare e applicare la configurazione corretta.

1. Stabilisci una connessione SSH a ogni switch ToR che non si trova nello stato Ready.

2. Inserisci la modalità di configurazione globale:

   config t
   

3. Rimuovi la configurazione dell'elenco di accesso in conflitto:

   no ip as-path access-list other-zones
   

4. Esci dalla modalità di configurazione.

Dopo l'esecuzione di questo comando su tutti gli switch interessati, il riconciliatore applicherà la configurazione corretta e gli switch passeranno allo stato READY.

Config-replace commit expiry

Versioni: tutte le versioni 1.14.x possono essere interessate.

Sintomi:

Un numero elevato di elenchi di controllo dell'accesso (ACL) causa un timeout durante la configurazione degli switch di rete. La risorsa personalizzata BorderLeafSwitch non è nello stato Ready e, quando viene stabilita una connessione SSH con l'opzione non pronta, viene visualizzato lo stato Commit expiry.

Ad esempio, il seguente comando mostra lo stato:

sh config-replace log verify

L'output è simile al seguente:

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

Soluzione temporanea:

Nelle versioni 1.14.3 o 1.14.7+, modifica la risorsa personalizzata SubcomponentOverride denominata pnet-core-override nello spazio dei nomi root e aggiungi un campo httpTimeout a .spec.operableParameters.netDevGW.

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

Attendi 15 minuti per consentire all'infrastruttura di automazione di eseguire il push delle nuove configurazioni sugli switch. Configura httpTimeout in base alle esigenze finché i messaggi Commit expiry non scompaiono.

Nelle versioni 1.14.4, 1.14.5 e 1.14.6, esegui manualmente config-replace e commit delle modifiche.

1. Mettere in pausa il trasferimento:

   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"
   

2. Segui il runbook PNET-P0001 per ottenere l'accesso allo switch.

3. Trova la configurazione da sostituire:

   switch-cli# dir | grep new_config
   

4. Completa la sostituzione della configurazione:

   switch-cli# configure replace <new_config_file>
   

   L'operazione potrebbe richiedere più di cinque minuti.

5. Dopo che la sostituzione della configurazione è andata a buon fine, esegui il commit della modifica:

   switch-cli# configure replace commit
   

6. Riattiva il trasferimento:

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

Il deployment con ASN BGP a 4 byte non riesce

Versioni: 1.14.3, 1.14.4

Sintomi: la configurazione del Border Gateway Protocol (BGP) con un numero di sistema autonomo (ASN) di 4 byte sugli switch di rete comporta errori di configurazione. Senza una configurazione BGP applicata correttamente, la rete all'interno di questa zona GDC potrebbe non essere in grado di stabilire un routing corretto, con conseguenti problemi di connettività, impossibilità di pubblicizzare le route o instabilità generale della rete. Al momento non è disponibile alcuna soluzione.

Traffico anycast globale bloccato

Versioni: 1.14.3

Sintomi: il traffico diretto verso gli endpoint anycast globali è bloccato dagli elenchi di controllo dell'accesso (ACL).

Soluzione temporanea:

Per risolvere il problema del traffico anycast globale bloccato dagli elenchi di controllo dell'accesso (ACL), devi creare una risorsa personalizzata SubcomponentOverride nel cluster di amministrazione principale per consentire esplicitamente il traffico verso i blocchi CIDR anycast del server DNS globale. Segui questi passaggi:

1. Trova tutti i blocchi CIDR anycast globali. Per trovare i blocchi CIDR anycast globali da aggiornare, segui questi passaggi:

   1. Connettiti al server API globale principale.

   2. Elenca tutte le risorse personalizzate della subnet in tutti gli spazi dei nomi utilizzando il comando:

      kubectl get subnet -A
      

   3. Filtra l'output per trovare le risorse di subnet in cui il filtro metadata.name contiene la parola chiave anycast.

   4. Per ogni risorsa di subnet trovata con anycast nel nome, annota il valore di spec.subnet. Questo valore rappresenta un blocco CIDR anycast globale.

2. Nel cluster di amministrazione principale, crea una risorsa personalizzata SubcomponentOverride denominata pnet-trafficpolicy-dc-override nello spazio dei nomi principale. Per ogni subnet anycast che hai identificato nel passaggio precedente, aggiungi le regole come mostrato nel file YAML:

   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
   

   Sostituisci quanto segue:

   • INTERCONNECT_RULE_DESCRIPTION: il testo descrittivo per la regola di rete di interconnessione.
   • GLOBAL_ANYCAST_CIDR: il blocco CIDR anycast globale, ad esempio 136.125.38.128/28. Per ogni anycast trovato nel passaggio precedente, crea la regola utilizzando questo file YAML.
   • HAIRPIN_RULE_DESCRIPTION: il testo descrittivo per la regola di rete hairpin.

L'errore parziale di DCI causa la perdita di traffico

Versioni: 1.14.3

Sintomi: quando entrambi i link Data Center Interconnect (DCI) che collegano lo switch leaf di confine di una zona allo switch dell'operatore o quando lo switch leaf di confine di una zona subisce un guasto hardware, viene perso circa il 50% del traffico di rete tra zone.

Nome VRF troppo lungo

Versioni: 1.14.2

Sintomi: potresti visualizzare un messaggio come questo esempio, che indica che gli switch non sono integri quando esegui questo comando:

sh config-replace log verify

L'output potrebbe essere simile a questo esempio:

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

Soluzione alternativa: il nome del CR dell'organizzazione può contenere un massimo di 19 caratteri.

La comunicazione dei pod StatefulSet non riesce

Versioni: 1.14.3, 1.14.4

Corretto: 1.14.3 hotfix 23, 1.14.5

Sintomi: problemi o interruzioni della connettività dovuti all'eliminazione degli oggetti Cilium Endpoint (CEP) non gestiti correttamente dopo il riavvio del pod StatefulSet. Ciò potrebbe comportare l'identità dell'endpoint non gestito che causa l'erronea eliminazione del traffico legittimo da parte delle norme di rete. I pod interessati possono essere verificati controllando l'assenza del relativo oggetto CEP:

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

Soluzione alternativa: riavvia i pod StatefulSet interessati per aggiornare il relativo UID e aggiornare i metadati associati:

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

Il nodo non è raggiungibile sulla rete di dati

Si tratta di un problema raro che può verificarsi se il pod anetd viene coinvolto in un ciclo di arresti anomali.

Una risorsa del kernel essenziale per la connettività dei nodi può bloccarsi in uno stato danneggiato.

Questa guida descrive i sintomi del problema e i passaggi da seguire per risolverlo.

Versioni:

Possono essere interessate tutte le versioni di Google Distributed Cloud (GDC) con air gap.

Sintomi:

Se si verifica questo problema, potresti notare i seguenti sintomi:

• I nodi sono bloccati nello stato NotReady
• La descrizione del nodo mostra il messaggio kubelet:kubelet was found unhealthy; repair flag : true
• L'accesso SSH al nodo non è possibile sulla rete di dati

Soluzione temporanea:

Utilizza le seguenti istruzioni per riparare ogni nodo non integro:

1. Ottieni l'indirizzo IP di gestione del nodo interessato:

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

2. Ottieni l'accesso SSH al nodo interessato.

3. Connettiti al nodo utilizzando SSH e l'indirizzo IP di gestione del nodo.

4. Sul nodo, esegui il seguente comando e chiudi la connessione SSH:

   tc filter del dev bond0 egress
   

5. Riavvia il DaemonSet anetd per il cluster con il nodo interessato:

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

La creazione di un PNP di uscita che consente tutto il traffico nega il traffico imprevisto

Versioni:

Possono essere interessate tutte le versioni di Google Distributed Cloud (GDC) con air gap.

Sintomi: la policy di rete del progetto (PNP) allow-all-egress consente il traffico verso gli endpoint all'interno del progetto e gli endpoint esterni al di fuori del cluster, ma non consente il traffico verso gli endpoint di sistema. Questo problema può comportare il blocco dell'accesso al sistema e ai servizi proprietari, ad esempio la risoluzione DNS e l'archiviazione di oggetti.

Il PNP allow-all-egress potrebbe avere il seguente aspetto:

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

Soluzione: elimina il allow-all-egress PNP. Per impostazione predefinita, una volta disattivata la protezione dall'esfiltrazione di dati, il traffico è consentito verso gli endpoint di progetto ed esterni al di fuori degli endpoint di cluster e di sistema.

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

Problema con la dashboard Grafana dello SLO di disponibilità multizona tra zone

Versioni: 1.14.3

Sintomi: in Grafana, il pannello SLO pnet-cross-zone-availability non mostra alcuna metrica.

Soluzione: segui il runbook PNET-P0001 per ottenere l'accesso allo switch e controllare manualmente la sessione BGP multizona e lo stato della connettività.

I gateway di ingresso del piano dati e di gestione non vengono riconciliati

Versioni: 1.14.3

Sintomi: i sottocomponenti asm-dataplane-ingress o asm-management-ingress non vengono riconciliati e viene visualizzato il seguente errore:

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'

Altri valori possibili nella stringa di errore anziché BackendService sono ForwardingRuleInternal e ForwardingRuleExternal. Allo stesso modo, il nome della risorsa potrebbe essere dataplane-ingress-gateway, dataplane-ingress-gateway-global o management-ingress-gateway-global anziché management-ingress-gateway.

Soluzione alternativa:identifica se la risorsa è presente nel server API di gestione o nel server API globale. Questo può essere dedotto dalla versione API del tipo di risorsa nella stringa di errore. Ad esempio, una risorsa con il suffisso networking.gdc.goog è presente nel server API di gestione, mentre una risorsa con il suffisso networking.global.gdc.goog è presente nel server API globale.

Dopo aver identificato il server API, elimina la risorsa utilizzando il file kubeconfig corrispondente. Ad esempio:

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

La pagina dei criteri di rete del progetto non supporta il campo del selettore di progetto nell'API ProjectNetworkPolicy

Versioni: 1.14.3, 1.14.4

Sintomi: quando crei una policy di rete del progetto che include il campo projectSelector e lo visualizzi nella console GDC, la UI mostra tutti i progetti selezionati per la policy anziché i progetti nel campo projectSelector.

Soluzione alternativa: utilizza l'API per creare e leggere un criterio di rete del progetto che includa il campo projectSelector.

Sistema operativo

Il provisioning del server non riesce

Versioni: 1.14.3

Sintomi: durante il provisioning del server, potrebbero essere visualizzati i seguenti errori 401 nella risorsa personalizzata BaremetalHost corrispondente durante il download dell'immagine del sistema operativo dal registro Harbor e il server è bloccato in un ciclo di deprovisioning e riprovisioning.

Per verificare la presenza di questi errori, descrivi la risorsa personalizzata BaremetalHost:

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

L'output potrebbe essere simile a questo esempio:

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

Soluzione:

1. Recupera il nome e lo spazio dei nomi di nodePoolClaim a cui appartiene il server:

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

   L'output potrebbe essere simile a questo esempio:

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

2. Recupera il nome dell'immagine sistema operativo da NodePoolClaim:

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

3. Ottieni l'URL dell'immagine del sistema operativo da OSImageMetadata:

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

4. Aggiorna la risorsa personalizzata Server con l'URL dell'immagine del sistema operativo più recente:

   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'"}]'
   

L'aggiornamento del nodo del sistema operativo potrebbe bloccarsi nel passaggio NodeOSInPlaceUpgradePostProcessingCompleted

Versioni: 1.14.3, 1.14.4

Sintomi:

Durante l'upgrade di un nodo, NodeUpgradeTask si blocca al passaggio NodeOSInPlaceUpgradePostProcessingCompleted con un errore del riconciliatore con il messaggio failed verifying delta after upgrade e non è stato possibile completare l'operazione. Questo errore indica che la procedura di verifica dell'upgrade ha rilevato discrepanze impreviste nel pacchetto sul nodo. In particolare, identifica i pacchetti che si trovano ancora nello stato "need-upgrade" o che vengono visualizzati come pacchetti "only-in-new" dopo il tentativo di upgrade.

Il messaggio di errore elenca i pacchetti specifici per cui la verifica non è riuscita. Snippet di esempio:

{"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"}

Questo sintomo potrebbe essere causato da due problemi. Rileva prima quale problema è la causa:

1. Cause-A: La macchina non è raggiungibile, pertanto OSArtifactSnapShot non è aggiornato.

   Controlla se il nodo in fase di upgrade è ancora integro o meno e se il job OSArtifactSnapShot corrispondente non va a buon fine.

   Se OSArtifactSnapShot non è aggiornato e la macchina non è raggiungibile per più di 20 minuti, vai al passaggio Mitigation-A. In caso contrario, continua a controllare la presenza di Cause-B.

2. Cause-B: Errore di upgrade RPM silenzioso

   In rari casi, l'upgrade RPM su una macchina potrebbe non riuscire in modo invisibile dopo un upgrade parziale. Devono essere presenti due ConfigMap contenenti la differenza del pacchetto prima e dopo l'upgrade:

   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
   in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
   

   Se "after-upgrade" contiene un numero inferiore di pacchetti rispetto a "before-upgrade", significa che l'upgrade è stato interrotto automaticamente e non è stato eseguito l'upgrade di tutti i pacchetti. Procedi verso Mitigation-B.

Soluzione:

Mitigation-A: repair unreachable machine

Prova a riparare la macchina riavviandola. Se la macchina è ancora irraggiungibile dopo i tentativi di riavvio, contatta il team SERV per ulteriore assistenza. Dopo che la macchina è di nuovo raggiungibile, elimina OSArtifactSnapShot per forzare la riconciliazione. Una volta riconciliato OSArtifactSnapShot, NodeUpgradeTask deve procedere al passaggio successivo.

Mitigation-B: riprova a NodeUpgradeTask

1. Accedi tramite SSH alla macchina in fase di upgrade e raccogli i seguenti log per la risoluzione dei problemi futuri. Devono essere raccolti i seguenti file:

   • /var/log/dnf.log
   • /var/log/dnf.rpm.log
   • dnf history > dnf_history.log
   • rpm -qa --last > rpm_last.log

2. Elimina NodeUpgradeTask non riuscito. In questo modo, verrà attivato un nuovo tentativo di NodeUpgradeTask sul nodo specifico. Il nuovo NodeUpgradeTask dovrebbe completare l'upgrade dell'RPM e procedere al passaggio successivo.

L'aggiornamento del nodo del sistema operativo potrebbe bloccarsi nel passaggio di creazione del server dei pacchetti

Versioni: 1.14.3, 1.14.4

Sintomi:

Quando viene creato un NodeUpgrade CR, viene riattivato e rimane in in-progress per più di 30 minuti, la creazione del server dei pacchetti potrebbe non riuscire in modo invisibile. Il sintomo è un NodeUpgrade che rimane con: .status.upgradeStatus=in-progress ma non è caricato alcun .status.tasks:

status:
  duration: 0s
  upgradeStatus: in-progress

Per verificare ulteriormente che l'operazione non riesca durante la creazione del server dei pacchetti, leggi il log del controller di upgrade del sistema operativo:

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

Se il log del controller mostra failed to create package server e failed to create package repo server DNS registration con il motivo dettagliato (uno dei seguenti)

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

Poi suggerisce che alcune altre risorse del server dei pacchetti utilizzate da altri NodeUpgrade sono ancora attive e in conflitto con la risorsa da creare per l'attuale NodeUpgrade in attesa.

Soluzione:

Per ulteriore conferma, puoi controllare la risorsa server di pacchetti effettiva (di determinate API, ad esempio dnsregistration.network.private.gdc.goog nel server API di gestione del cluster che gestisce la CR NodeUpgrade) e trovare NodeUpgrade proprietario di queste risorse. Se il NodeUpgrade proprietario del DNSRegistration è già stato completato, ma la risorsa DNSRegistration non è ancora stata eliminata, puoi eliminare l'oggetto DNSRegistration se tutti gli oggetti NodeUpgrade a cui fa riferimento sono stati completati.

1. Elenca tutte le CR DNSRegistration per il server di pacchetti NodeUpgrade:

   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
   

2. Esegui una query sulla risposta predefinita del proprietario NodeUpgrade per un particolare 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"'
   

Gli upgrade del sistema operativo del nodo potrebbero riscontrare problemi e interrompersi in qualsiasi fase della procedura

Versioni: 1.14.4, 1.14.5, 1.14.6

Sintomi:

NodeUpgradeTask CR ancora sotto in-progress per più di 2 ore, anche se potrebbe essere in grado di completare automaticamente la richiesta se ha abbastanza tempo.

La richiesta di ripristino NodeUpgradeTask è in corso da più di due ore. Sebbene alla fine possa essere completato automaticamente, il problema di fondo è l'incapacità di os-policy-reconciler di gestire in modo efficiente un volume elevato di CR OSPolicy. Questo problema si verifica durante il passaggio NodeOSInPlaceUpgradeCompleted.

Per confermare ulteriormente questo errore durante la creazione del server dei pacchetti, consulta il log del controller di upgrade del sistema operativo.

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

Se nel log del controller manca una voce OSPolicy di NodeUpgradeTask, significa che il controller è sovraccarico.

Soluzione:

Metti in pausa tutte le richieste di revisione non essenziali di OSPolicy durante il processo di upgrade.

"storage cp" di un file di grandi dimensioni causa l'arresto anomalo di kube-api di org-mgmt

Versioni: 1.14.3 e successive

Sintomi: durante un'operazione gdcloud storage cp o gdcloud system container-registry load-oci da una workstation OIC, esiste una leggera possibilità che l'accesso a org-infra venga perso e che org-mgmt's kube-api non funzioni. Si tratta di un problema raro e la raccolta dei dati per l'ingegneria è utile.

Soluzione alternativa: quando si verifica questo problema, prova a seguire questi passaggi:

1. Per ogni nodo del control plane (CP), esegui uptime per verificare se i nodi sono stati riavviati nelle ultime 24 ore.
2. Prendi nota dell'ora del riavvio.
3. Controlla la presenza di kernel panic su ciascun nodo CP verificatisi subito prima del riavvio eseguendo dmesg | grep -i 'kernel panic'.
4. Su ogni nodo CP, controlla se le schede NIC Mellanox sono installate eseguendo: lspci | grep -i eth | grep -i mellanox. Se non sono presenti NIC Mellanox, interrompi la lettura di questo problema noto.

5. Su ogni nodo CP, controlla le seguenti impostazioni di rete su 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
   

   Se rx-gro-hw (vedi sopra) è impostato su "off" in tutti i nodi, non leggere questo problema noto.

6. Raccogli alcune informazioni per aiutare Google a diagnosticare il problema:

   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
   

7. Su ogni nodo CP, esegui i seguenti comandi:

   dmesg | grep -i 'kernel panic'
   
   journalctl -u disable-rx-gro-hw.service
   
   systemctl status disable-rx-gro-hw
   
   modinfo mlx5_core | grep ^version:
   

8. Per risolvere il problema delle impostazioni di rete, rx-gro-hw deve essere off eseguendo i seguenti comandi su tutti i nodi CP:

   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
   

9. Controlla di nuovo le impostazioni:

   [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"
   

10. Riprova l'operazione originale, ad esempio gdcloud storage cp o gdcloud system container-registry load-oci. Se l'errore persiste, contatta il team di ingegneria.

Operations Suite Infrastructure Core Services (OIC)

Rendimento scarso di Jumphost

Versioni: possono essere interessate tutte le versioni di Google Distributed Cloud (GDC) con air gap.

Sintomi: le operazioni del browser o del sistema richiedono tempi eccessivi per essere completate.

Soluzione:

Aumenta il conteggio di vCPU sui jumphost tramite Hyper-V Manager su BM03 e BM04:

1. Seleziona una VM Jumphost e poi fai clic su Impostazioni nel riquadro delle azioni.
2. Seleziona Processore, quindi aumenta il conteggio in Numero di processori virtuali a 4 o più a seconda del carico di lavoro.
3. Ripeti l'operazione per gli altri jumphost.

Resource Manager

Impossibile eliminare i progetti nella console GDC

Versioni: 1.14.3, 1.14.4

Sintomi: la console GDC fornisce il pulsante Elimina Elimina per i progetti esistenti nella pagina Dettagli progetto, ma il pulsante non funziona.

Soluzione alternativa: per eliminare un progetto esistente, devi utilizzare gcloud CLI. Per saperne di più, consulta la sezione Eliminare un progetto.

Playbook Ansible dell'organizzazione mancanti

Versioni: 1.14.3

Sintomi: durante la creazione di un'organizzazione, il job create-ansible-playbooks che crea i playbook Ansible richiesti non riesce in modo invisibile. I playbook Ansible mancanti causano problemi come la mancanza di macchine virtuali perimetrali e problemi con la creazione di un'organizzazione globale.

Soluzione: segui il runbook OS-R0009 per creare manualmente i playbook Ansible dell'organizzazione mancanti.

L'organizzazione globale asimmetrica mostra configurazioni di zona inesistenti

Versioni: 1.14.4

Sintomi: quando crei un'organizzazione globale v1 con solo un sottoinsieme di configurazioni di organizzazione zonali, tutte le zone mostrano comunque uno stato di replica dell'organizzazione. Ad esempio, se hai un universo GDC con tre zone, ma crei solo una configurazione dell'organizzazione zonale per due zone, la terza zona mostra comunque uno stato di replica errato per la terza organizzazione zonale inesistente.

Per confermare lo stato errato, stampa lo stato dell'organizzazione globale:

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

L'output YAML è simile al seguente:

...

- 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

...

Tieni presente che ciò si verifica solo per le organizzazioni v1, poiché le configurazioni zonali asimmetriche non sono supportate per le organizzazioni v2.

Soluzione alternativa: puoi ignorare lo stato di replica errato, poiché l'organizzazione zonale non esiste a meno che tu non l'abbia creata appositamente.

Cluster

Il pool di nodi worker del cluster di infrastruttura non viene eliminato

Versioni: 1.14.3, 1.14.4

Sintomi: quando rimuovi un pool di nodi worker dalla specifica CR Organization, il pool di nodi non viene eliminato automaticamente, ovvero il comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} restituisce comunque il pool di nodi da eliminare.

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

Soluzione: dopo aver rimosso il pool di nodi worker dalla specifica CR Organization, elimina manualmente la CR NodePoolClaim per questo pool di nodi dal cluster di amministrazione principale eseguendo il comando: sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

Attendi che NodePoolClaim e i relativi CR NodePool vengano eliminati completamente, ovvero che il comando kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} non restituisca più il pool di nodi worker.

Archiviazione

L'eliminazione dei bucket creati con il comando gdcloud config set zone non va a buon fine

Versioni: 1.14.7 e successive

Sintomi: i bucket creati con il comando gdcloud config set zone non vengono eliminati a causa di problemi di autorizzazione, perché il comando tenta di operare nella zona errata.

Soluzione: utilizza la console per impostare la zona specifica per un bucket o sostituisci il flag --zone con --location nel comando gcloud.

Attivazione avvisi SLO basati su obiettivi

Versioni: 1.14.3, 1.14.4

Sintomi: gli avvisi SLO per OBJ vengono attivati a causa dell'errore ErrFailedStreamingDecryptRequest nel proxy OBJ: obj-list-object-ops-availability-slo, obj-rw-object-ops-error-rate-slo.

Soluzione: disattiva l'audio dell'avviso. L'errore viene erroneamente identificato come errore di sistema quando è causato dall'interruzione della connessione da parte dell'utente, che non viene conteggiata ai fini dello SLO.

S3 UploadPart Empty ETag

Versioni: 1.14.3

Sintomi: dopo aver inviato una richiesta UploadPart, ottieni un codice di stato 200 Success nel messaggio di risposta, ma il campo ETag è vuoto. Questo errore si verifica perché si verifica un InternalServerError a causa di un'interruzione della rete e il codice di stato non viene aggiornato a 500 InternalServerError.

Soluzione alternativa: riprova a inviare la richiesta come se non fosse riuscita in precedenza.

Il montaggio dei pod non riesce a causa dell'errore Trident mkfs.ext4

Versioni: 1.14.3

Sintomi: dopo aver tentato di montare i pod, noti che tutti i pod in transizione verso o da un determinato nodo non riescono. Viene visualizzato un messaggio di errore RPC: DeadlineExceeded desc = context deadline exceeded, che indica che il nodo è bloccato. Quando si verifica questo messaggio, non puoi più eseguire altre operazioni Trident sul nodo in questione. I volumi che forniscono dati non sono interessati, ma i volumi che si spostano verso e dal nodo potrebbero subire un'interruzione.

Soluzione:

1. Ispeziona i log di Trident sul nodo che il pod sta tentando di montare e verifica che la coda stia aumentando. I log potrebbero essere simili ai seguenti:

   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"
   

2. Accedi al nodo e guarda l'output di dmesg. I log potrebbero essere simili ai seguenti:

   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)
   

3. Dopo aver confermato che si è verificato un errore mkfs.ext4 di Trident, riavvia il nodo.

Trident non riesce a creare un volume a causa di un errore già esistente

Versioni: 1.14.3

Sintomi:

Una PVC non viene sottoposta al provisioning e mostra un evento come il seguente:

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

Quando si verifica questo evento, il PVC non viene eseguito il provisioning finché non esegui la soluzione alternativa.

Soluzione:

Per risolvere il problema, procedi nel seguente modo:

1. Prendi nota del nome del volume interno dell'evento. Ad esempio, l'evento di esempio visualizzato nella sezione Sintomi mostra il nome del volume interno trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a.
2. Segui il runbook FILE-R0105 per accedere a ONTAP.

3. Elimina il volume:

   volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a
   

file_block_iscsi_sessions_unhealthy alert segnala un falso positivo

Versioni: 1.14.3

Sintomi: in alcuni ambienti, viene attivato l'avviso file_block_iscsi_sessions_unhealthy che indica che uno o più nodi riscontrano errori iSCSI. Il controller file-observability utilizza un raccoglitore di metriche personalizzato per monitorare l'integrità delle sessioni iSCSI su ogni nodo Kubernetes, ma in alcuni casi il raccoglitore di metriche non è in grado di analizzare l'output del comando iscsiadm e segnala zero sessioni iSCSI in esecuzione anche se iSCSI ha sessioni integre.

Soluzione:

Segui questi passaggi per verificare che iSCSI non stia riscontrando problemi e disattiva l'avviso se si tratta di un falso positivo:

1. Dalla pagina di esplorazione di Grafana, esegui la query fb_sessions_running_count{job="file-observability-backend-target.file-system"}. La query restituisce una metrica per ogni nodo del cluster. Se uno dei nodi segnala una metrica fb_sessions_running_count pari a 0, annota il nome del nodo.

2. Per ogni nodo con metriche fb_sessions_running_count che restituiscono 0, esegui i seguenti comandi:

   1. Stabilisci una connessione SSH con il nodo interessato.

   2. Esegui il comando iscsiadm -m session. Devi visualizzare più righe restituite. Ogni riga è una sessione iSCSI in esecuzione. Se il comando non restituisce nulla o se nell'output sono presenti errori, riassegna il problema al team di ingegneria del blocco dei file.

   3. Se il comando precedente ha restituito correttamente le sessioni iSCSI, hai confermato che l'avviso per questo nodo è un falso positivo.

3. Quando confermi che tutti i nodi interessati hanno sessioni iSCSI integre e che l'avviso viene attivato erroneamente, crea un silenzio in AlertManager per disattivare l'avviso file_block_iscsi_sessions_unhealthy.

L'avviso file_block_storage_disk_failure viene attivato per i dischi di riserva

Versioni: 1.14.3

Sintomi: in alcuni ambienti, viene attivato l'avviso file_block_storage_disk_failure che indica che uno o più dischi in ONTAP non sono integri. Il controller file-observability utilizza un raccoglitore di metriche personalizzato per monitorare l'integrità di ogni disco in ONTAP, ma nelle versioni precedenti di GDC il raccoglitore non considera un disco di riserva come integro e attiva un avviso per il disco di riserva.

Soluzione:

Segui questi passaggi per verificare che i dischi siano di scorta e disattivare l'avviso per il disco:

1. Dalla pagina di esplorazione di Grafana, esegui la query disks_labels_healthy{job="file-observability-backend-target.file-system"}. La query restituirà una metrica per ogni disco in ONTAP. Se uno dei dischi segnala una metrica pari a 0 (non integro), annota il nome del disco.

2. Per ogni disco con metriche disks_labels_healthy che restituiscono 0, esegui questi comandi:

   1. Esegui SSH sul cluster ONTAP ed esegui il comando disk show -disk <disk-name> -fields state utilizzando il nome del disco raccolto dalla query della metrica.

   2. Verifica che l'output del comando indichi che lo stato del disco è present o spare. Se il disco si trova in uno stato diverso da present o spare, riassegna il problema al team di ingegneria del blocco dei file.

   3. Se il disco in questione segnala present o spare, possiamo confermare che l'avviso non deve essere attivato per questo disco. Crea un silenzio in AlertManager per silenziare l'avviso file_block_storage_disk_failure con l'etichetta disk_name impostata sul nome del disco.

3. Una volta creati i silenzi per tutti i dischi di scorta, vai a Grafana per verificare che gli avvisi non vengano più attivati.

L'avviso file_block_storage_node_peer_connection_unhealthy viene attivato dopo il ripristino della connessione

Versioni: 1.14.3

Sintomi: in alcuni ambienti, viene attivato l'avviso file_block_storage_node_peer_connection_unhealthy che indica che una o più connessioni tra i nodi ONTAP non funzionano. Il controller file-observability utilizza un raccoglitore di metriche personalizzate per monitorare l'integrità di queste connessioni. Esiste un problema noto per cui questo avviso continuerà a essere attivato anche dopo il ripristino della connessione non riuscita.

Soluzione:

Segui questi passaggi per verificare che le connessioni tra i nodi siano integre e disattiva l'avviso per i nodi:

1. Dalla pagina di esplorazione di Grafana, esegui la query storage_node_peer_connections{job="file-observability-backend-target.file-system"}. La query restituisce una metrica per ogni connessione tra i nodi di archiviazione nel cluster. Se una connessione segnala una metrica storage_node_peer_connections di 0, annota le etichette source_node, destination_ip e storage_cluster_name della metrica.

2. Per ogni metrica storage_node_peer_connections che restituisce 0, esegui i seguenti comandi:

   1. Stabilisci una connessione SSH con il cluster di archiviazione ONTAP dall'etichetta storage_cluster_name.

   2. Esegui questo comando sul cluster ONTAP utilizzando i valori delle etichette source_node e destination_ip:

   ping -node <node-name> -destination <destination-ip> -verbose -show-detail
   

   Se il comando ping non va a buon fine, riassegna il problema al team di ingegneria del blocco dei file. Se il comando ping ha esito positivo, significa che le connessioni dei nodi sono integre e l'avviso viene attivato erroneamente.

   1. Crea un silenziamento in AlertManager per silenziare l'avviso file_block_storage_node_peer_connection_unhealthy con le etichette source_node e destination_ip impostate sul nodo di origine e sull'IP di destinazione della metrica.

3. Una volta creati i silenzi per tutti i nodi integri, vai a Grafana per verificare che gli avvisi non vengano più attivati.

L'avviso file_block_nodes_not_reachable viene attivato dopo il ripristino della connessione

Versioni: 1.14.3

Sintomi: in alcuni ambienti, viene attivato l'avviso file_block_nodes_not_reachable che indica che una o più connessioni dai servizi IPsec sui nodi Kubernetes a ONTAP non vanno a buon fine. Il controller file-observability utilizza un raccoglitore di metriche personalizzate per monitorare l'integrità di queste connessioni. Esiste un problema noto per cui questo avviso continuerà a essere attivato anche dopo il ripristino della connessione non riuscita.

Soluzione:

Segui questi passaggi per verificare che le connessioni sui nodi siano integre e disattiva l'avviso per i nodi:

1. Dalla pagina di esplorazione di Grafana, esegui la query fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}. La query restituisce una metrica per ogni nodo del cluster. Se uno dei nodi segnala una metrica fb_all_nodes_reachable pari a 0, annota il nome del nodo.

2. Per ogni nodo con metriche fb_all_nodes_reachable che restituiscono 0, esegui i seguenti comandi:

   1. Stabilisci una connessione SSH con il nodo interessato.

   2. Esegui questo comando:

      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
      

      Il comando tenterà di eseguire il ping di ONTAP utilizzando tutte le connessioni IPsec. Se uno dei ping nel comando non va a buon fine, riassegna il problema al team di tecnici del blocco dei file. Se i comandi ping hanno esito positivo, significa che le connessioni dei nodi sono integre e l'avviso viene attivato erroneamente.

   3. Se tutti i ping nel comando hanno esito positivo, abbiamo confermato che le connessioni sul nodo sono integre e l'avviso viene attivato erroneamente. Crea un silenzio in AlertManager per disattivare l'avviso file_block_nodes_not_reachable con l'etichetta node_name impostata sul nome del nodo.

3. Una volta creati i silenzi per tutti i nodi integri, vai a Grafana per verificare che gli avvisi non vengano più attivati.

file_block_storage_high_node_total_latency avviso attivato durante carichi di lavoro elevati

Versioni: 1.14.3

Sintomi: l'avviso file_block_storage_high_node_total_latency potrebbe essere attivato in determinati ambienti a causa di carichi di lavoro elevati sui nodi di archiviazione. Questo avviso rimane attivo finché questi carichi di lavoro non vengono elaborati completamente. Anche quando le prestazioni di lettura e scrittura sui volumi sono veloci, i nodi di archiviazione possono comunque segnalare una latenza elevata per operazioni a blocchi specifiche.

Soluzione:

Per verificare le latenze del volume corrette e disattivare l'avviso di latenza del nodo di archiviazione:

1. Controlla gli avvisi di latenza del volume:

   1. In Grafana, verifica che gli avvisi file_block_storage_high_volume_write_latency e file_block_storage_high_volume_read_latency non vengano attivati e che segnalino tempi di latenza ottimali per i volumi.

2. Riassegna se la latenza del volume è elevata:

   1. Se vengono attivati gli avvisi di scrittura del volume o di lettura del volume, significa che la latenza è elevata nell'intero sistema di archiviazione. Riassegna questo problema al team tecnico di blocco dei file.

3. Disattiva l'avviso di latenza del nodo (se i volumi sono integri):

   1. Se gli avvisi di scrittura e lettura del volume sono integri, è probabile che l'avviso di latenza del nodo sia un falso positivo.

   2. Crea un silenzio in AlertManager per l'avviso file_block_storage_high_node_total_latency.

   3. Dopo aver creato la soppressione, vai a Grafana per verificare che l'avviso non venga più attivato.

Upgrade dei nodi bloccato

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6, 1.14.7

Sintomi: questo blocco si verifica quando una LUN (Logical Unit Number) diventa di sola lettura, spesso a causa di problemi con gli snapshot. In questo caso, il nodo viene isolato per spostare il pod interessato in un nodo diverso. Poiché la procedura di upgrade dei nodi prevede un controllo preliminare per assicurarsi che i nodi non siano isolati, questo stato impedisce l'avanzamento dell'upgrade.

Soluzione alternativa: disattiva manualmente il sottocomponente file-read-only-lun-cleanup prima di avviare la procedura di upgrade:

1. Identifica ogni organizzazione interessata.

2. Applica un SubcomponentOverride per ogni organizzazione nell'ambiente.

   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
   

3. Verifica che nessuno dei nodi nelle organizzazioni interessate sia isolato:

   1. Elenca i nodi dell'organizzazione:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      L'output è simile al seguente:

      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
      

      Prendi nota dei nomi dei nodi con stato SchedulingDisabled. Per questo output di esempio, il nodo isolato è admin-node0-zone1.

   2. Rimuovi la protezione dai nodi che hanno restituito lo stato SchedulingDisabled dal passaggio precedente:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
      

   3. Verifica che tutti i nodi siano pronti:

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes
      

      L'output è simile al seguente:

      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
      

L'avviso file_block_zombie_luns_present viene attivato dopo la risoluzione degli errori multipath

Versioni: 1.14.3 e successive

Sintomi: l'avviso file_block_zombie_luns_present potrebbe essere attivato in determinati ambienti a causa dell'impossibilità del controller file-observability di analizzare l'output del comando multipath -ll. Questa situazione comporta l'attivazione costante dell'avviso relativo alle LUN zombie anche quando il servizio multipath è integro su tutti i nodi.

Soluzione:

Per verificare che i servizi multipath siano integri sui nodi in questione, segui questi passaggi:

1. Dalla pagina di esplorazione di Grafana, esegui la query zombie_lun_exists{job="file-observability-backend-target.file-system"}. La query restituisce una metrica per ogni nodo del cluster. Se uno dei nodi segnala una metrica zombie_lun_exists pari a 1, annota il nome del nodo.

2. Per ogni nodo con metriche zombie_lun_exists che restituiscono 1, esegui i seguenti comandi:

   1. Stabilisci una connessione SSH con il nodo interessato.

   2. Esegui questo comando:

      multipath -ll
      

      Il comando restituisce informazioni su tutti i dispositivi a blocchi gestiti dal servizio multipath. Verifica che nessuno dei dispositivi di blocco contenga la stringa failed undef unknown o la stringa failed faulty running nei relativi stati.

   3. Se uno dei dispositivi presenta lo stato failed faulty running, segui il runbook FILE-R0020 per risolvere il problema delle LUN zombie.

   4. Se uno dei dispositivi contiene lo stato failed undef unknown, segui il runbook FILE-R0021 per risolvere il problema delle LUN super zombie.

3. Disattiva gli avvisi LUN zombie, se i nodi sono integri:

   1. Se non vengono trovati dispositivi di blocco non validi su nessuno dei nodi, l'avviso LUN zombie è un falso positivo.

   2. Crea un silenzio in AlertManager per l'avviso file_block_zombie_luns_present.

   3. Dopo aver creato la sospensione, vai a ServiceNow per verificare che l'avviso non venga più attivato.

Impossibile eliminare il bucket vuoto dalla console

Versioni: 1.14.4 e successive

Sintomi: nella console GDC non puoi eliminare un bucket vuoto. Il bucket potrebbe contenere indicatori di eliminazione e potenzialmente altre versioni degli oggetti quando il controllo delle versioni degli oggetti è abilitato con le policy di conservazione. Potresti visualizzare un errore come questo:

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

Soluzione alternativa: utilizza il comando gdcloud storage rm -a per eliminare gli oggetti, inclusi i marcatori di eliminazione, per rendere eliminabile il bucket.

System Artifact Registry

I job di replica di Harbor si bloccano

Versioni: 1.14.3

Sintomi:i job di replica degli artefatti Harbor si bloccano. Questo problema blocca la distribuzione degli artefatti all'organizzazione e impedisce la creazione di organizzazioni.

Soluzione alternativa:per risolvere il problema, segui i passaggi descritti nel runbook SAR-R1010.

Stato di errore temporaneo non cancellato durante la riconciliazione della risorsa personalizzata dell'account robot Harbor

Versioni: 1.14.3

Sintomi:si attiva erroneamente un avviso CustomResourceErrorStatusAlert etichettato con kind=HarborRobotAccount e code=SAR2002. Ad esempio, l'avviso falso ha il campo message impostato su "Error getting robot: failed to list robots: 503 Service Unavailable".

Soluzione alternativa:chiedi all'operatore dell'infrastruttura (IO) di verificare se l'avviso è un problema reale o un falso allarme e disattiva l'avviso se si tratta di un falso allarme, seguendo le istruzioni riportate di seguito.

Quando viene attivato un avviso, segui il runbook SAR-E2002 per identificare e risolvere la causa principale dell'avviso.

A causa di questo problema noto, anche se il runbook risolve correttamente la causa principale, l'avviso potrebbe continuare a essere attivato erroneamente. Continua a controllare lo stato di errore dell'oggetto risorsa personalizzata (CR) HarborRobotAccount (HRD) di destinazione per cui viene generato l'avviso:

1. Imposta le variabili di ambiente richieste:

   export KUBECONFIG=KUBECONFIG
   export HRD_NAME=HRD_NAME
   export HRD_NAMESPACE=HRD_NAMESPACE
   

   Sostituisci quanto segue:

   • KUBECONFIG: il percorso del file kubeconfig.
   • HRD_NAME: il nome della risorsa personalizzata HarborRobotAccount di destinazione.
   • HRD_NAMESPACE: lo spazio dei nomi che contiene la risorsa personalizzata HarborRobotAccount di destinazione.

2. Controlla lo stato di errore della risorsa personalizzata di destinazione HarborRobotAccount:

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

Se il valore di lastUpdateTime indica che il campo errorStatus è stato aggiornato l'ultima volta più di 30 minuti fa, l'avviso è un falso allarme. Per mitigare il falso allarme, disattiva l'avviso all'interno dell'istanza air-gapped di GDC seguendo il runbook MON-R2009.

Falso allarme per l'avviso SAR-R0003

Versioni: 1.14.3 e successive

Sintomi:viene attivato erroneamente un avviso con codice SAR-R0003, OC SAR e gravità critical.

Soluzione:segui il runbook MON-R2009 per disattivare l'avviso.

Sistema di gestione dei ticket

Impossibile avviare correttamente ServiceNow MID Server

Versioni: 1.14.3

Correzione: 1.14.4

Sintomi: il server MID ServiceNow, che si integra con Splunk, non riesce a registrarsi con ServiceNow all'avvio a causa di una mancata corrispondenza della versione.

Soluzione:

1. Metti in pausa il sottocomponente ts-mid-server.

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

1. Esegui l'override della stringa di versione del MID Server.

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

Esegui l'upgrade

L'annotazione del cluster di servizi condivisi non viene aggiornata dopo un upgrade del cluster riuscito

Versioni: 1.14.4

Sintomi:le CR dei cluster perimetrali e dei servizi condivisi per clusters.baremetal.cluster.gke.io riflettono la versione GKE corretta dopo l'upgrade. Le CR clusters.cluster.gdc.goog mostrano ancora la versione di GKE precedente.

Soluzione alternativa: aggiorna l'annotazione upgrade.gdc.goog/version in clusters.baremetal.cluster.gke.io con il nuovo nome UserClusterMetadata corrispondente alla versione GKE aggiornata.

L'upgrade del nodo di amministrazione dell'organizzazione è bloccato

Versioni: 1.14.6

Correzione: 1.14.7

Sintomi: il processo di upgrade dei nodi per il control plane di amministrazione dell'organizzazione gdchservices è bloccato. L'upgrade del nodo non riesce perché non è possibile stabilire una connessione SSH al nodo, il che comporta un errore Connection timed out.

L'upgrade del componente aggiuntivo è bloccato

Versioni: 1.14.6

Correzione: 1.14.7

Sintomi: l'upgrade del componente aggiuntivo per il cluster di amministrazione principale si blocca durante l'upgrade da qualsiasi versione 1.14.x precedente alla 1.14.6. Un messaggio di stato potrebbe indicare che l'upgrade ha superato il limite di tempo previsto:

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'

Soluzione: aggiorna manualmente spec.addOnSetTemplateRef della risorsa addonset root-admin in modo che punti al modello corretto per la nuova versione.

Il report di assistenza non riesce

Versioni: 1.14.3, 1.14.4, 1.14.5, 1.14.6

Correzione: 1.14.7

Sintomi: il comando gdcloud resource-support get-report non riesce quando viene eseguito per un cluster utente a causa di un problema di autorizzazioni.

L'avvio della VM potrebbe bloccarsi dopo il completamento dell'upgrade del nodo del sistema operativo

Versioni: 1.14.6

Sintomi: durante l'upgrade dalla versione 1.14.3 alla 1.14.6, le macchine virtuali nei cluster perimetrali o di servizi condivisi non riescono ad avviarsi e diventano irraggiungibili dopo un upgrade del sistema operativo.

Ad esempio, il seguente comando può confermare il problema:

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

L'output del log della console VM mostra un messaggio di panico del kernel simile al seguente:

[    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) ]---

Soluzione alternativa: completa i seguenti passaggi per risolvere il problema:

1. Imposta le seguenti variabili di ambiente:

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

2. Arresta la VM non riuscita:

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

3. Apri l'editor per scollegare il disco di avvio dalla VM non riuscita:

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

4. Sostituisci il disco di avvio con un nome segnaposto nella specifica della VM:

   # 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
   

5. Crea un secret dello script di avvio:

   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
   

6. Crea una VM helper:

   1. Recupera l'immagine VM per il disco di avvio della VM. L'immagine non deve avere la stessa famiglia di sistemi operativi del disco di avvio del nodo VM problematico, quindi utilizza grep per trovare l'immagine Ubuntu:

      # 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}')
      

   2. Crea il disco di avvio della VM e la VM. Crea un nuovo disco di avvio e una nuova VM con un disco secondario collegato e uno script di avvio per l'accesso alla console:

      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
      

   3. Verifica che la VM helper sia in esecuzione:

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

7. Console alla VM helper e rigenera initramfs:

   1. Console alla VM helper:

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

   2. Utilizza le seguenti credenziali:

      username="newuser"

      password="Lime+blaze8legend"

   3. Monta le partizioni del disco collegato:

      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/
      

   4. Stabilisci una connessione chroot al punto di montaggio e rigenera initramfs:

      sudo chroot /mnt/kernelpanic/
      dracut --regenerate-all --force
      

   5. Verifica che venga generato il nuovo initramfs per la nuova versione del kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:

      ls /boot/initramfs-* -l
      

      L'output è simile al seguente:

      -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
      

8. Arresta la VM helper:

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

9. Scollega il disco dalla VM helper:

   1. Apri la specifica della VM helper in un editor:

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

   2. Rimuovi il seguente codice dal file YAML:

      - virtualMachineDiskRef:
          name: PROBLEM_VM_BOOT_DISK
        autoDelete: false
      

10. Ricollega il disco di avvio alla VM non riuscita:

    1. Apri la specifica della VM non riuscita in un editor:

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

    2. Aggiorna la specifica come segue:

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

11. Avvia la VM non riuscita:

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

12. Verifica che l'upgrade sia stato corretto:

    1. Controlla che la risorsa personalizzata Node per questa VM mostri Ready e utilizzi la versione kernel più recente 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64:

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

       L'output è simile al seguente:

       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
       

    2. Controlla la versione del kernel dopo aver stabilito una connessione SSH alla VM:

       uname -a
       

       L'output deve mostrare la nuova versione del kernel 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.

L'ingester rimane in stato non integro e non viene dimenticato automaticamente dopo l'upgrade

Versioni: 1.14.x

Sintomi:il componente secondario log-infra non è in uno stato integro dopo l'upgrade. Per eseguire il controllo, esegui: none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra Per controllare lo stato di un sottocomponente, devi utilizzare il file kubeconfig del cluster principale per KUBECONFIG e lo spazio dei nomi del cluster corrente per CLUSTER_NAMESPACE. Il comando restituirà lo stato del sottocomponente. Se lo stato non è ReconciliationCompleted, indica che il sottocomponente non è integro nel cluster.

Alcuni pod Loki nel cluster non sono integri. Per elencare tutti i pod Loki, esegui: none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' Questo comando mostra tutti i pod Loki, incluse le colonne STATUS e READY. Un pod è considerato non integro se il suo STATUS non è Running o se alcuni dei suoi container non sono pronti. La colonna READY, formattata come a/b, indica il numero di container pronti a sul totale b. Un pod è integro quando a e b sono uguali.

Controlla i log dei pod Loki non integri: none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

I log di output di esempio dei pod non integri sono simili ai seguenti:

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"

Soluzione alternativa:per eliminare un ingester non integro dall'anello Loki, consulta il runbook AL-R0031.

Vertex AI

Le richieste di traduzione potrebbero generare il codice di errore RESOURCE_EXHAUSTED

Versioni: 1.14.3

Sintomi: dopo aver inviato una richiesta di traduzione, ottieni il codice di errore RESOURCE_EXHAUSTED nel messaggio di risposta. Questo errore si verifica quando superi un limite di frequenza del sistema. Una risorsa è stata esaurita, ad esempio una quota per utente, il numero massimo di query al secondo o l'intero file system è esaurito.

Soluzione alternativa: chiedi all'operatore dell'infrastruttura di riavviare gli shard di backend del servizio di traduzione. Dopodiché, invia di nuovo le richieste di traduzione con intervalli più lunghi tra una richiesta e l'altra o inviando richieste più brevi.

batchTranslateDocument requests return error 503

Versioni: 1.14.3

Sintomi: dopo aver inviato una richiesta batchTranslateDocument, ottieni il codice di errore 503 "Batch Document translation is not implemented" nel messaggio di risposta. Questo errore si verifica perché il metodo BatchTranslateDocument richiede il servizio Aspose, che viene implementato solo quando il parametro operabile enableRAG è impostato su true nel cluster.

Soluzione alternativa: chiedi all'operatore dell'infrastruttura di impostare il parametro operabile enableRAG su true nel cluster di amministrazione dell'organizzazione seguendo questi passaggi:

1. Crea una risorsa personalizzata SubcomponentOverride in un file YAML denominato vai-translation.yaml con il parametro operabile enableRAG impostato su true:

   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
   

   Sostituisci SHARED_SERVICE_CLUSTER_NAMESPACE con lo spazio dei nomi del cluster di servizi condivisi.

2. Applica la risorsa personalizzata SubcomponentOverride al cluster di amministrazione dell'organizzazione:

   kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
   

   Sostituisci ORG_MGMT_KUBECONFIG con il percorso del file kubeconfig di gestione nel cluster di amministrazione dell'organizzazione.

L'inizializzazione del pod e del servizio frontend di traduzione o OCR non riesce.

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

Sintomi: durante gli upgrade, il cluster DB viene ricreato, il che causa l'obsolescenza e la mancata sincronizzazione del secret-store ODS nel cluster shared-service. Per questo motivo, l'inizializzazione del pod e del servizio frontend di traduzione o OCR non riesce.

Soluzione:

Elimina il secret nel cluster di servizi condivisi:

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

Sostituisci SHARED_SERVICE_CLUSTER_KUBECONFIG con il percorso del file kubeconfig nel cluster shared-service.

Se il servizio problematico è Traduzione, sostituisci VAI_API_NAMESPACE con "g-vai-translation-sie"; se il servizio problematico è OCR, sostituisci VAI_API_NAMESPACE con "g-vai-ocr-sie".

Un controller ricrea automaticamente il secret e lo sincronizza nuovamente con il cluster DB.

Vertex AI Search

Cerca componenti bloccati nello stato di riconciliazione

Versioni: 1.14.6

Sintomi:i sottocomponenti vaisearch-conversation e vaisearch-frontend sono bloccati nello stato Reconciling se nell'organizzazione non viene creata alcuna risorsa personalizzata SearchConfig.

Soluzione alternativa:il problema può essere ignorato. Al momento della creazione della risorsa personalizzata SearchConfig, i sottocomponenti devono completare la riconciliazione.

Server

Rotazione delle credenziali del BIOS bloccata nella fase di richiesta di ripristino

Versioni: 1.14.4

Sintomi:la rotazione delle credenziali del BIOS si blocca nello stato di richiesta di reimpostazione. Puoi verificarlo controllando l'annotazione gdch.cluster.gke.io/rotation-status per il secret delle credenziali del BIOS del server:

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

Sostituisci SERVER_NAME con il nome del server. L'output del comando è reset-requested se la rotazione è bloccata.

Soluzione alternativa: per completare la rotazione delle credenziali del BIOS, segui il runbook SERV-R0018.

Impossibile eseguire il provisioning dei server installati in precedenza

Versioni: 1.14.6

Sintomi: i server non vengono sottoposti al provisioning dopo il deprovisioning e il riprovisioning, in particolare in relazione a problemi con la gestione delle chiavi iLO (Integrated Lights-Out) e HSM (Hardware Security Module). I server, in precedenza parte di un'organizzazione disattivata, riscontrano errori durante il provisioning delle immagini, il che indica l'impossibilità di trovare un dispositivo adatto, spesso a causa di dischi bloccati da chiavi vecchie o eliminate. Potresti visualizzare un errore simile al seguente:

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

Soluzione alternativa: elimina e reinstalla i server interessati per aiutarli a raggiungere uno stato di provisioning. Per ulteriori informazioni, consulta i runbook SERV-R0020 e SERV-R0021.

Macchine virtuali

L'importazione dell'immagine non riesce

Versioni: 1.14.4. 1.14.5

Correzione: 1.14.6

Sintomi: l'importazione di un'immagine utilizzando il comando gdcloud compute images import non riesce e viene visualizzato un errore Unauthorized a causa dei timeout della sessione.

Soluzione: utilizza l'API KRM per l'importazione di immagini personalizzate anziché gcloud CLI.

L'importazione dell'immagine KRM richiede molto tempo

Versioni: 1.14.6 e successive

Sintomi: l'importazione di un'immagine utilizzando l'API KRM richiede molto tempo per essere completata. La risorsa VirtualMachineImageImport rimane nello stato TranslationJobInProgress per un periodo prolungato, il che indica che la fase di traduzione non viene completata come previsto. Il pod image-translation entra nello stato CrashLoopBackOff.

Soluzione:

1. Prova di nuovo l'importazione creando una nuova risorsa VirtualMachineImageImport con un nome diverso.
2. Monitora lo stato di VirtualMachineImageImport controllando periodicamente la risorsa finché il suo stato non cambia in WaitingForTranslationJob. Per ulteriori informazioni, consulta il runbook VMM R0007.