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

Artifact Registry

Errore di riconciliazione del sottocomponente sar-failoverregistry

Versioni: 1.13.1, 1.13.3, 1.13.4

Sintomi:quando crei il cluster di amministrazione principale con il comando gdcloud system admin-cluster install, l'operazione potrebbe non riuscire se è presente un lungo elenco di server durante il bootstrapping. Il messaggio di output dell'errore è il seguente:

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

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

  1. Nello stesso cluster Kubernetes del sottocomponente, elenca i server e verifica che ogni risorsa personalizzata del server abbia un'etichetta con la chiave cluster.private.gdc.goog/inventory-machine:

    kubectl get servers -n gpc-system

  2. Trova la risorsa personalizzata del componente simile alla seguente:

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

  3. Nella risorsa personalizzata del componente System Artifact Registry (SAR), aggiungi il selettore di etichette nei server runtimeParameterSources per sar-failover-registry:

    1. Visualizza la risorsa server esistente:

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

    2. Aggiorna il campo dei server nella risorsa personalizzata del componente:

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

  4. Verifica che le modifiche nel componente SAR del passaggio precedente vengano propagate al sottocomponente sar-failverregistry:

    1. Visualizza i dettagli del componente SAR:

      kubectl get component | grep sar

    2. Visualizza i dettagli del componente sar-failoverregistry:

      kubectl get subcomponent sar-failoverregistry -n root

      Utilizza il flag -n per specificare lo spazio dei nomi.

Backup e ripristino

Gli snapshot non riescono a causa di spazio del volume insufficiente

Versioni: tutte le versioni 1.13.x

Sintomi:si verifica un problema intermittente con il backup del volume permanente che può influire sui flussi di lavoro dei job di backup periodici. Per alcuni volumi con un tasso di modifica elevato, gli snapshot del volume creati per i backup in corso possono causare l'esaurimento dello spazio del volume, che viene quindi impostato in modalità di sola lettura.

Soluzione alternativa: per evitare potenziali conseguenze sui workload di produzione, segui i passaggi nel runbook BACK-R0104. Se vuoi, puoi anche rimuovere gli snapshot accumulati seguendo il runbook BACK-R0106.

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

Versioni: tutte le versioni 1.13.x

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.

Il backup non riesce per lo snapshot PVC

Versioni: tutte le versioni 1.13.x

Sintomi:si sono verificati errori di backup a causa del superamento del limite di snapshot ONTAP di 1023 per risorsa PersistentVolumeClaim (PVC).

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

  1. Aggiorna il piano di backup in modo che i limiti non vengano mai raggiunti. Configura un piano di backup per eseguire il backup ogni ora o riduci il valore di deleteLockDays a tre in modo che il numero di snapshot non superi 1023:

    apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS

    Sostituisci quanto segue:

    • LOCK_DAYS: blocca l'eliminazione del backup per il numero di giorni specificato dopo la creazione del backup. Utilizza i seguenti valori:

      • Se il campo volumeStrategy è impostato sul valore LocalSnapshotOnly, utilizza il valore 2.
      • Se il campo volumeStrategy è impostato sul valore ProvisionerSpecific, utilizza il valore 7.

    • RETENTION_DAYS: elimina i backup dopo il numero di giorni specificato dopo la creazione del backup. Se il campo volumeStrategy è impostato su un valore LocalSnapshotOnly, utilizza un valore inferiore a 3.

  2. Per eliminare manualmente gli snapshot in eccesso dal tuo ambiente utilizzando i comandi di eliminazione degli snapshot del volume, segui questi passaggi:

    1. Inizializza le variabili:

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

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      Sostituisci quanto segue:

      • ORG_NAME: il nome della tua organizzazione.
      • PVC_NAME: il nome della risorsa PVC correlata al piano di backup.

    2. NetApp ONTAP è un sistema operativo utilizzato per amministrare lo spazio di archiviazione per GDC. Ottieni l'accesso a ONTAP:

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

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

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

echo $PASSWORD

    3. Elenca tutti gli snapshot per la risorsa PVC selezionata:

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      Utilizza la password del passaggio precedente per accedere alla macchina all'indirizzo IP definito dalla variabile MGMT_IP.

    4. Trova il PVC con il numero più alto di snapshot:

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

    5. Imposta il nome della risorsa PVC su quello con il numero elevato di snapshot:

      export PV_NAME=

    6. Elimina lo snapshot per la risorsa PVC che contiene un numero elevato di snapshot. Il limite per il numero di snapshot per una risorsa PVC è 1023:

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

    7. Accedi a ONTAP ed esegui questi comandi per eliminare lo snapshot:

      echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

    8. Esegui i comandi elencati nel passaggio precedente per eliminare lo snapshot. Al termine, esci dalla sessione SSH

  3. Ripeti i passaggi di eliminazione finché tutti gli snapshot PVC incriminati non vengono puliti.

Ripristino da un backup incompatibile con la quota SVM

Versioni: 1.13.1

Sintomi:il problema è un'incompatibilità tra le funzionalità NetApp. Questa incompatibilità impedisce la distribuzione della quota tenant e l'implementazione corretta dei ripristini. Il problema si verifica solo quando viene ripristinato un backup in un cluster utente con quota limitata.

Soluzione alternativa:se si verifica questo problema, il ripristino non riesce e viene visualizzato il messaggio di errore DP volumes are not supported on storage-limit enabled Vserver. L'operatore dell'infrastruttura deve disattivare la quota per il cluster utente e riavviare la procedura di ripristino. Al termine del ripristino, l'IO deve riattivare le quote tenant e il sistema dovrebbe continuare a funzionare come previsto. Per ulteriori dettagli, consulta il runbook FILE A0030.

Fatturazione

Le metriche di fatturazione non vengono visualizzate correttamente nella dashboard di fatturazione

Versioni: 1.13.1

Sintomi:le metriche di fatturazione non vengono emesse correttamente in Cortex a causa della mancanza di MetricsProxySidecar.

Soluzione: crea una risorsa billing-monetizer MetricsProxySidecar. Quindi, esegui uno script per aggiornare metricExpression.

  1. Esporta la seguente variabile kubeconfig:

    export KUBECONFIG=KUBECONFIG_PATH

    Sostituisci la variabile KUBECONFIG_PATH con il percorso del file kubeconfig per il cluster di amministrazione dell'organizzazione. Segui i passaggi descritti in Service-manual IAM-R0101 per generare il file kubeconfig richiesto per questa soluzione alternativa.

  2. Crea una risorsa billing-monetizer MetricsProxySidecar per gli spazi dei nomi billing-system e partner-billing-system:

    Per billing-system:

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

    Per partner-billing-system:

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

  3. Esegui lo script seguente per aggiornare metricExpression. In questo modo, container_name="monetizer" viene rimosso da skuconfig, che include billing_total_cost{container_name="monetizer":

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

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

L'utente non riesce a creare BillingAccountBinding a causa di bug nel webhook di convalida

Versioni: 1.13.0, 1.13.1, 1.13.3

Sintomi:il bug si trova nella logica del webhook di convalida BillingAccountBinding. Se un utente tenta di creare una risorsa BillingAccountBinding, il webhook restituisce l'errore permission denied.

Soluzione alternativa:per creare risorse BillingAccountBinding, notifica all'operatore dell'infrastruttura e crea le risorse corrispondenti tramite IAC.

Archiviazione a blocchi

I pod Grafana sono bloccati nello stato Init a causa di errori di montaggio del volume.

Versioni: 1.13.3

Sintomi:

I pod Grafana negli spazi dei nomi anthos-identity-service-obs-system e platform-obs-obs-system sono bloccati nello stato Init a causa di errori di montaggio del volume. Il messaggio di errore nei log di kubelet indica un problema di multi-attach. Il problema deriva da un bug in Trident, che non riesce a identificare e verificare correttamente il dispositivo sottostante per i mapping LUKS, causando un errore di multi-attach.

Soluzione:

Controlla il PVC per un deletionTimestamp. Se non è presente alcun deletionTimestamp (migrazione dei pod), segui questi passaggi:

  1. Controlla VolumeAttachment per PVC per identificare a cosa è attualmente collegato il volume.
  2. Isola il Nodes nel cluster che non corrisponde a questo valore.
  3. Elimina Pod non riuscito. In questo modo, verrà eseguita la migrazione di nuovo a Node originale.

Dopo aver eseguito il controllo, se è presente un deletionTimestamp (eliminazione del volume), segui questi passaggi:

  1. Controlla VolumeAttachment per PVC per identificare a cosa è attualmente collegato il volume.

  2. Su Node, restituisci i contenuti del file di monitoraggio:

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. Verifica che il dispositivo LUKS trovato nel campo devicePath dell'output del file di monitoraggio sia effettivamente chiuso. Questo percorso non dovrebbe esistere a questo punto:

    stat DEVICE_PATH

  4. Verifica se il numero di serie è attualmente mappato a un dispositivo multipath.

    1. Copia il valore nel campo iscsiLunSerial del file di monitoraggio.

    2. Converti questo valore nel valore esadecimale previsto:

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. Con questo nuovo valore, verifica se la voce multipath esiste ancora:

      multipath -ll | grep SERIAL_HEX

    4. Se non esiste, elimina il file di monitoraggio.

    5. Se esiste, vedrai un valore esadecimale seriale leggermente più lungo di quello cercato, denominato multipathSerial. Esegui il seguente comando e trova i dispositivi di blocco:

      multipath -ll MULTIPATH_SERIAL

    6. Quindi, esegui i seguenti comandi, con l'ultimo eseguito in modo univoco per ogni dispositivo a blocchi:

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

I pod di avvio della macchina virtuale non riescono a mappare i volumi

Versioni: 1.13.1

Sintomi:

Potresti visualizzare un avviso simile a questo:

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

Per diagnosticare il problema:

  1. Assicurati che i volumi e i pod si trovino sullo stesso nodo.
  2. Trova il nodo su cui si trovano i pod e controllane l'integrità.
  3. Controlla la connettività dei nodi.
  4. Controlla IPSEC.
  5. Controlla il percorso multiplo per verificare se è presente un zombie.

  6. Controlla i log di Trident per scoprire quale passaggio del flusso CSI potrebbe aver introdotto questo zombie:

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

Soluzione alternativa: per risolvere il problema, segui i passaggi riportati nei seguenti runbook:

  1. Per problemi relativi ai nodi, consulta il runbook FILE-R0010.
  2. Per problemi relativi a IPSEC, consulta il runbook FILE-R0007.
  3. Per problemi relativi alle LUN zombie, consulta il runbook FILE-R0020.
  4. Per problemi relativi ai super zombie LUN, consulta il runbook FILE-R0021.

Errori relativi allo spazio di archiviazione

Versioni: 1.13.1

Sintomi: gli errori relativi allo spazio di archiviazione possono essere identificati dall'attivazione dell'avviso file_block_zombie_luns_present o dall'impossibilità di avviare il pod a causa di un problema nella chiamata MountVolume che persiste per più di un ciclo di riconciliazione. Il timeout potrebbe durare circa due minuti. La ripetizione dello stesso errore indica che si è verificato un problema nel percorso CSI NodeStage o NodePublish e richiede una soluzione alternativa. L'unica eccezione è l'indicazione di un errore di timeout. Potresti visualizzare alcuni errori come questo:

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

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

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

Soluzione:

  1. Per verificare se il Node che contiene Pod può essere corretto per PVC non riuscito, isola il nodo corrente in cui è pianificato il pod ed elimina Pod:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Pod deve essere pianificato per un Node completamente diverso, il che comporta l'esecuzione forzata di NodeStage, NodePublish, NodeUnpublish e NodeUnstage. Potrebbe non essere possibile risolvere immediatamente il problema del volume perché potrebbero essere ancora aperte sessioni per questo volume sul Node originale.

  2. Una volta completato il passaggio precedente, rimuovi la protezione del nodo in questione:

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. Se gli errori sono ancora presenti, isola tutti gli altri Nodes tranne quello in cui era originariamente pianificato il Pod ed elimina il Pod. In questo modo, Pod inizierà a essere eseguito sul Node originale, dove potrebbero ancora essere presenti dispositivi esistenti.

  4. Una volta completato il passaggio precedente, rimuovi la protezione dei nodi in questione.

  5. Come ultimo tentativo per salvare PV e i relativi dati, Node può essere riavviato per eliminare gli errori multipath, udev e devmapper su Node. Sebbene questo passaggio sia piuttosto arduo, è quello che ha maggiori probabilità di riuscita.

  6. Se le mitigazioni precedenti non riescono a risolvere il problema con il volume, significa che i dati sono stati danneggiati e sono inutilizzabili. L'unica opzione rimasta per continuare con il comportamento previsto del container è eliminare PV, PVC e Pod non riusciti, seguito da un riavvio del nodo in cui era ospitato il PV. Questa azione comporta la perdita completa dei dati già scritti nel volume.

Volumi permanenti creati con dimensioni errate

Versioni: 1.13.1

Sintomi: i carichi di lavoro con un volume permanente vengono creati con dimensioni inferiori di circa 16 MiB. Se i carichi di lavoro dipendono esattamente dalle dimensioni pubblicizzate da un volume persistente, la piccola discrepanza fa sì che il carico di lavoro non vada a buon fine durante l'espansione o il provisioning. Questo problema è più probabile per i volumi permanenti di cui è stato eseguito il provisioning con una classe di archiviazione standard-block rispetto a quelli di cui è stato eseguito il provisioning con una classe di archiviazione standard-rwo. Questo problema potrebbe verificarsi su volumi permanenti con una classe di archiviazione standard-rwo che utilizza la modalità volumemode:block.

Soluzione alternativa: alloca un volume persistente di almeno 16 MiB più grande di quello effettivamente richiesto.

Impossibile eliminare la macchina virtuale di archiviazione

Versioni: 1.13.1

Sintomi: il StorageVirtualMachine potrebbe mostrare un errore come questo:

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

Soluzione alternativa: elimina il finalizer da StorageVirtualMachines nello spazio dei nomi dell'organizzazione.

La disattivazione dell'organizzazione non comporta la pulizia delle risorse

Versioni: 1.13.1

Sintomi: quando si disattiva un'organizzazione, rimangono alcune risorse StorageVirtualMachines, ad esempio:

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

Soluzione: elimina queste risorse.

Errore di riconciliazione dell'eliminazione

Versioni: 1.13.1

Sintomi: quando un StorageVirtualMachine viene eliminato prima della pulizia dei cluster a seconda di quel StorageVirtualMachine, è possibile che si verifichi un problema di pulizia di alcuni volumi persistenti (PV) dei cluster. Nello specifico, quando i PV criptati con LUKS non vengono puliti, il loro secret impedisce l'eliminazione del namespace in cui si trovano. Nei log potrebbe essere visualizzato un avviso simile al seguente:

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

Soluzione alternativa:elimina il finalizzatore dai secret g-luks-gdc-vm-disk-* nello spazio dei nomi del cluster di servizio.

L'upgrade bare metal è bloccato

Versioni: 1.13.1, 1.13.5, 1.13.6

Sintomi:i job Ansible si bloccano durante la raccolta dei fatti quando sono presenti LUN zombie. L'esecuzione del comando multipath -ll potrebbe mostrare il seguente problema:

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

Potresti anche visualizzare il seguente messaggio di errore:

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

Soluzione alternativa: controlla la connettività SSH con il nodo di destinazione, quindi utilizza il seguente runbook: FILE-R0020.

Errore multi-allegato Trident

Versioni: 1.13.3

Sintomi: i pod e i PVC potrebbero essere bloccati su nodi diversi con il pod bloccato durante l'inizializzazione in attesa del PVC.

Soluzione temporanea:

  1. Controlla la PVC per un deletionTimestamp:

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

  2. Se non è presente deletionTimestamp (migrazione del pod):

    1. Controlla VolumeAttachment per il PVC per identificare dove è collegato il volume.
    2. Isola i nodi nel cluster che non corrispondono a questo valore.
    3. Elimina il pod non riuscito. Questa azione esegue la migrazione del pod al nodo originale.

  3. Se è presente un deletionTimestamp (eliminazione del volume):

    1. Controlla VolumeAttachment per il PVC per identificare dove è collegato il volume.
    2. Nel nodo, restituisci i contenuti del file di monitoraggio, /var/lib/trident/tracking/PVC_NAME.json.
    3. Verifica che il dispositivo LUKS trovato nel campo devicePath dell'output del file di monitoraggio sia effettivamente chiuso. Questo percorso non dovrebbe esistere a questo punto: stat DEVICE_PATH. Se il percorso esiste ancora, si verifica un problema diverso.
    4. Verifica se il numero di serie è mappato a un dispositivo multipath.
    5. Copia il valore nel campo iscsiLunSerial del file di monitoraggio.
    6. Converti questo valore nel valore esadecimale previsto: echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. Con questo nuovo valore, verifica se la voce multipath esiste ancora: multipath -ll | grep SERIAL_HEX.
    8. Se non esiste, elimina il file di monitoraggio.

    9. Se esiste, vedrai un valore esadecimale seriale leggermente più lungo di quello che hai cercato. Registra questo valore come MULTIPATH_SERIAL. Esegui multipath -ll MULTIPATH_SERIAL e visualizzi un messaggio simile a questo:

      3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running

    10. Esegui questi comandi:

      1. systemctl restart iscsid
      2. systemctl restart multipathd
      3. multipath -f MULTIPATH_SERIAL
      4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

    11. Esegui l'ultimo comando in modo univoco per ogni dispositivo a blocchi.

Errore nella configurazione IPsec

Versioni: 1.13.4

Sintomi: la configurazione IPsec di ONTAP rileva un errore a causa di una chiave precondivisa (PSK) non valida contenente 0X, che viene interpretata come stringa esadecimale.

Potresti visualizzare un avviso come questo:

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

Soluzione temporanea:

  1. Recupera le connessioni di crittografia dello spazio di archiviazione:

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    Cerca la voce con Ready=False e annota il nome di PRESHAREKEY. L'output potrebbe essere simile a questo esempio:

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

  2. Questa macchina esegue un'organizzazione GPU, quindi elimina secrets gpc-system/vm-5a77b2a2-pre-shared-key in gpu-org-admin.

  3. Attendi che il sistema ricrei secret/vm-5a77b2a2-pre-shared-key.

  4. Cerca un job con un pattern come gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2. Tieni presente che gli ultimi 8 caratteri vengono generati in modo casuale. Quando la chiave sarà di nuovo disponibile, elimina il job, ad esempio jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl in gpu-org-admin.

La macchina virtuale di archiviazione non è stata creata

Versioni: 1.13.5

Sintomi:il servizio Harbor su gpu-org non viene avviato a causa di un problema con il provisioning dei volumi. Questo problema è causato dal pod file-storage-backend-controller che fa riferimento a una macchina di inventario inesistente.

Potresti visualizzare un errore del controller di archiviazione simile a questo, che indica che InventoryMachine non è stato trovato:

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

Soluzione temporanea:

  1. Elimina il pod file-storage-backend-controller.
  2. Consenti al controller di archiviazione di recuperare nuovamente le macchine di inventario presenti.

Le reti intercluster di archiviazione non vengono riconciliate

Versioni: 1.13.5, 1.13.6

Sintomi: dopo un upgrade, la risorsa personalizzata StorageCluster nel cluster di amministrazione root non diventa pronta a causa di una configurazione errata delle subnet intercluster nella specifica. Il cluster di archiviazione segnala Not Ready e include un evento con questo errore:

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

Se si verifica questo errore, la rivendicazione della subnet intercluster utilizzata dal cluster di archiviazione non include il campo kind nel riferimento. Se esamini la risorsa personalizzata StorageCluster, troverai un riferimento alla richiesta di subnet intercluster con solo un nome e uno spazio dei nomi, ad esempio:

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

Soluzione alternativa: aggiorna la specifica StorageCluster in modo da includere il campo kind: SubnetClaim nel riferimento alla richiesta di subnet:

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

Dopo aver aggiornato la specifica StorageCluster, riavvia il deployment file-storage-backend-controller e verifica che il cluster di archiviazione sia pronto.

Gestione dei cluster

Il job machine-init non riesce durante il provisioning del cluster

Versioni: 1.13.1

Sintomi:

  1. Durante il provisioning del cluster, il job machine-init del secondo nodo del control plane non riesce e viene visualizzato il seguente messaggio:

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. Visualizza i log:

    kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

    L'output mostra un risultato non vuoto.

Soluzione temporanea:

  1. Attiva o disattiva l'autorizzazione di /etc/kubernetes/pki/etcd/ca.crt. Si tratta di un'operazione molto sensibile al tempo. Il cambio di autorizzazione deve avvenire dopo l'esecuzione precedente del job machine-init, ma prima dell'esecuzione successiva del job machine-init, poiché machine-init sovrascrive l'autorizzazione riportandola alla radice.

  2. Riavvia etcd nel secondo nodo per ripristinare etcd nel primo nodo da un loop di arresto anomalo.

Dopo aver completato questi due passaggi, l'kube-apiserver nel primo nodo inizia a essere eseguito e il successivo job machine-init ha esito positivo.

Nessuna connettività dal cluster di servizio al bucket di archiviazione di oggetti

Versioni: 1.13.1

Sintomi: la connessione per un pod di database in esecuzione nel cluster di servizio a un bucket di archiviazione oggetti nel cluster di amministrazione dell'organizzazione non riesce.

Soluzione: segui le istruzioni nel runbook KUB-R0305.

Il controllo preliminare non riesce

Versioni: 1.13.1

Sintomi: potresti visualizzare il seguente messaggio nello stato dell'oggetto cluster:

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

Dovresti anche visualizzare un oggetto PreflightCheck corrispondente con lo stesso nome e spazio dei nomi dell'oggetto cluster presente da diverse ore, mentre l'errore o l'esito negativo indicato nell'oggetto PreflightCheck non è più un problema.

Soluzione alternativa: elimina l'oggetto PreflightCheck.

La creazione del pool di nodi worker del cluster utente non riesce

Versioni: 1.13.5

Sintomi: la creazione del pool di nodi worker del cluster utente potrebbe smettere di rispondere per uno di questi tipi di macchine:

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

Soluzione alternativa: elimina il pool di nodi e ricrealo selezionando altri tipi di macchine disponibili dal menu a discesa dell'interfaccia utente di creazione del cluster utente.

I cluster di utenti, una volta ricreati, potrebbero rimanere bloccati nella riconciliazione a causa di una pulizia impropria

Versioni: 1.13.x

Sintomi: quando i cluster utente vengono creati con lo stesso nome di un cluster eliminato in precedenza, potrebbero rimanere bloccati in Reconciling all'infinito con lo stato che menziona la fase di installazione del componente aggiuntivo ONE.

Soluzione: disinstalla il componente aggiuntivo Helm CLUSTER_NAME-abm-overrides e riavvia il deployment managed-adm-controller. Segui MKS-R0004 per la procedura dettagliata.

Servizio di database

Questa sezione contiene i problemi noti del servizio di database.

Clonazione del database AlloyDB Omni bloccata

Versioni: tutte le versioni 1.13.x

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.

L'applicazione delle IOPS influisce sulle prestazioni di archiviazione

Versioni: 1.13.1

Soluzione alternativa: per risolvere il problema, segui una di queste opzioni:

  • Aumenta le dimensioni dello spazio di archiviazione.
  • Esegui l'override della quota IOPS.

Errore di riconciliazione durante l'upgrade del componente secondario dbs-fleet

Versioni: 1.13.3

Sintomi: durante l'upgrade dell'organizzazione principale dalla versione 1.13.1 alla 1.13.3, potresti visualizzare un errore di riconciliazione. Controlla la presenza di errori di riconciliazione:

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

L'errore potrebbe avere il seguente aspetto:

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

Soluzione alternativa: segui i passaggi nel runbook OCLCM-R0122.

La creazione di DBCluster non riesce

Versioni: 1.13.3

Sintomi: dopo l'upgrade a 1.13.3, la riconciliazione dei nuovi DBcluster non riesce e viene visualizzato il seguente errore nello stato:

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

Soluzione temporanea

Verifica che nel cluster di amministrazione dell'organizzazione siano presenti localrollout CR che terminano sia con cpa-v0.12.46 che con cpa-v0.12.51. Ad esempio:

kubectl get localrollouts -A

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

Trova ed elimina i localrollout CR che terminano con cpa-v0.12.46, assicurandoti che gli altri localrollout CR rimangano invariati.

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

Dovrebbe essere restituito un elenco simile a questo:

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

Elimina ciascuno dei seguenti elementi:

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

Verifica che i CR localrollout che terminano con cpa-v0.12.51 siano ancora presenti:

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

DNS

DNSSEC deve essere disattivato esplicitamente in resolved.conf

Versioni: 1.13.1, 1.13.3, 1.13.4

Sintomi: la risoluzione DNS non riesce sui nodi bare metal o VM. Per verificare che la risoluzione DNS non riesca, stabilisci una connessione SSH al nodo interessato ed esegui systemctl status systemd-resolved. L'output contiene righe come DNSSEC validation failed for question . IN SOA: no-signature.

Soluzione:

  1. Aggiungi la seguente riga a /etc/systemd/resolved.conf sul nodo interessato.

    DNSSEC=false

  2. Riavvia il servizio systemd-resolved:

    systemctl restart systemd-resolved.service

Servizio portuale

Creazione del servizio Harbor non riuscita

Versioni: 1.13.6

Sintomi: la creazione di un'istanza Harbor non riesce a causa di una mancata corrispondenza dello spazio dei nomi causata da una limitazione della lunghezza nel nome ServiceIsolationEnvironment. Potresti vedere un messaggio simile a questo:

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

Soluzione alternativa: abbrevia il nome dell'istanza Harbor per risolvere il problema attuale. Assicurati che la lunghezza combinata di PROJECT_NAME e HARBOR_INSTANCE_NAME sia inferiore a 27 caratteri.

L'eliminazione delle istanze di Harbor non comporta l'eliminazione dei mirror del registro associati

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

Sintomi: l'eliminazione delle istanze di Harbor non comporta l'eliminazione dei mirror del registro associati. Il pool di nodi potrebbe essere bloccato nello stato Provisioning. Ciò è causato dal fatto che i mirror del registro creati dal controller MHS non vengono eliminati quando vengono eliminate le istanze Harbor.

Soluzione alternativa: Devi rimuovere manualmente i mirror del registro. Per mitigare il problema, segui questi passaggi:

  1. Connettiti al cluster di amministrazione dell'organizzazione. Per maggiori informazioni, consulta la pagina Architettura del cluster GDC.

  2. Esegui questo script per rimuovere tutti i mirror del registro che corrispondono al valore della variabile di ambiente HARBOR_INSTANCE_URL da tutti i cluster Kubernetes che hanno l'etichetta lcm.private.gdc.goog/cluster-type=user:

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

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

    Sostituisci HARBOR_INSTANCE_URL con l'URL dell'istanza Harbor.

Modulo di sicurezza hardware

Le licenze di prova HSM disattivate sono ancora rilevabili

Versioni: 1.13.1, 1.13.3-1.13.11

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

Certificati HSM scaduti

Versioni: 1.13.11

Sintomi: quando esegui l'upgrade di un'organizzazione, potresti visualizzare un avviso come questo:

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

org-1-system-cluster è bloccato in un upgrade della versione ABM a causa della scadenza dei certificati HSM (Hardware Security Module).

Potresti anche visualizzare un errore come questo esempio in HPE server iLO, StorageGRID o ONTAP:

Not able to connect SSL to Key Manager server at IP_ADDRESS

Soluzione:

Ruota manualmente la CA radice e il certificato dell'interfaccia web con ksctl:

  1. Metti in pausa tutte le RP HSM, HSMCluster e HSMTenant.

  2. Crea una nuova CA radice con gli attributi copiati da quella precedente. Trova il vecchio ID cliente con ksctl ca locals list. Un esempio potrebbe avere il seguente aspetto:

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

  3. Autofirma la nuova CA con una durata di un anno. Un esempio potrebbe essere il seguente:

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

  4. Aggiorna l'interfaccia web per utilizzare questa nuova CA per la generazione automatica dei certificati. Un esempio potrebbe avere il seguente aspetto:

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

  5. Genera un nuovo certificato dell'interfaccia web, firmato dalla nuova CA. Il flag --url è l'IP di gestione dell'HSM (da kubectl get hsm -n gpc-system). Un esempio potrebbe avere il seguente aspetto:

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

  6. A questo punto, openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text mostra ancora il vecchio certificato. Per recuperare il nuovo certificato, devi riavviare l'HSM.

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    Ora openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text mostra il nuovo certificato.

  7. Elimina la vecchia CA dal CR HSM:

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

  8. Riattiva l'HSM: 

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

    Assicurati che l'HSM diventi integro.

  9. Ripeti questi passaggi per gli altri due HSM. Hanno già la nuova CA radice autofirmata perché la CA è condivisa tra gli HSM di un cluster. Salta i passaggi 2 e 3, ma ripeti i passaggi 4-8.

  10. Segui l'attività HSM T0008 di rotazione CA per automatizzare la rotazione di tutti i certificati, ma salta il passaggio Finalizza la rotazione aggiungendo una nuova annotazione di rotazione a hsmcluster in cui viene aggiunto ca-rotation-finalizing annotation.

Carica il nuovo nome della CA su iLO:

  1. Nell'interfaccia iLO, apri la pagina Administration - Key Manager (Amministrazione - Gestione chiavi) e fai clic sulla scheda Key Manager (Gestione chiavi).
  2. Ruota il nome del certificato.
  3. Esegui un riavvio a freddo.
  4. Verifica che l'handshake SSL ricominci a funzionare.

Gestione di identità e accessi

I pod gatekeeper-audit nello spazio dei nomi opa-system vengono riavviati di frequente

Versioni: 1.13.3

Sintomi: controlla lo stato dei pod gatekeeper-audit-*** nello spazio dei nomi opa-system:

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

L'output potrebbe essere simile a questo esempio:

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

Questo problema è causato da limiti di risorse bassi.

Infrastructure as Code (IaC)

La creazione eccessiva di token Gitlab rischia di riempire i database Gitlab

Versioni: 1.13.1

Sintomi: il sottocomponente iac-manager crea ripetutamente un nuovo token per l'utente configsync-ro, anche quando non è necessario. Ciò può comportare il riempimento del database Gitlab e rendere inaccessibile IAC. Il pod pg-gitlab-database-0 nello spazio dei nomi gitlab-system potrebbe non essere in grado di avviarsi e mostrare eventi come:

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

Soluzione temporanea:

Collabora con il tuo contatto Google per ottenere hotfix_3 per la release 1.13.1 e applicala.

Key Management System (KMS)

La modifica del tipo di chiave radice invalida tutte le chiavi esistenti

Versioni: 1.13.x

Sintomi:una volta creata un'organizzazione, il KMS viene automaticamente sottoposto a provisioning con una chiave root software. Per eseguire la migrazione da una chiave radice software a una chiave CTM, gli utenti eseguono l'override di un sottocomponente. In questo modo, il tipo di chiave radice viene modificato, il che invalida tutte le chiavi software esistenti nel KMS.

Soluzione alternativa: se possibile, evita di aggiornare il tipo di chiave principale. Se aggiorni il tipo di chiave principale, tutte le chiavi esistenti verranno invalidate.

kms-rootkey-controller CrashLoopBackOff a causa di OOMKILL

Versioni: 1.13.1

Sintomi:quando l'utilizzo della memoria kms-rootkey-controller supera il limite 600Mi, il controller entra in uno stato CrashLoopBackOff a causa di uno stato OOMKilled.

Soluzione:crea un SubcomponentOverride per aggiornare il limite di memoria a 1500Mi. Per istruzioni, vedi KMS Runbook 0007. Dopo aver completato i passaggi dei prerequisiti del runbook, esegui questi comandi:

  1. Crea una risorsa personalizzata SubcomponentOverride:

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

    Nell'esempio seguente, viene visualizzata una risorsa personalizzata SubcomponentOverride completa:

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

  2. Applica la risorsa SubcomponentOverride:

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

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

Logging

Il logger di controllo dell'archiviazione degli oggetti non riesce a risolvere l'host DNS

Versioni: 1.13.x

Sintomi:

Nel cluster di amministrazione principale, il deployment obs-system/log-remote-logger contiene più errori come i seguenti:

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

Soluzione alternativa: applica la patch al deployment di obs-system/log-remote-logger con il seguente comando:

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

HaaS Logger mostra errori nel cluster di amministrazione principale

Versioni: 1.13.x

Sintomi:

Nel cluster di amministrazione principale, il deployment obs-system/log-remote-logger contiene più errori come i seguenti:

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

Soluzione: esegui l'upgrade alla versione 1.13.8 per correggere l'errore. In alternativa, modifica il deployment di obs-system/log-remote-logger nel seguente modo:

Negli argomenti del container remote-logger, aggiorna il flag --disabled-loggers in modo da includere santricity e HaaS:

YAML

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

Santricity Logger non funziona

Versioni: 1.13.x

Sintomi:

Nel cluster di amministrazione principale, il deployment obs-system/log-remote-logger contiene più errori come i seguenti:

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

Soluzione: esegui l'upgrade alla versione 1.13.8 per correggere l'errore.

I log della destinazione di logging vengono inviati al progetto errato

Versioni: 1.13.x

Sintomi: i log di DaemonSet obs-system/oplogs-forwarder mostrano avvisi simili ai seguenti:

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

Questi avvisi comportano l'instradamento dei log al progetto (ID tenant) errato. Questo problema deriva da un bug noto in Fluent Bit. Per maggiori informazioni, vedi il problema di Fluent Bit su GitHub.

Soluzione: esegui l'upgrade alla versione 1.13.8 per correggere l'errore.

I log di controllo dello spazio dei nomi della piattaforma non sono visibili all'amministratore della piattaforma

Versioni: 1.13.x

Sintomi: i log di controllo dello spazio dei nomi della piattaforma sono visibili all'operatore dell'infrastruttura (IO) anziché all'amministratore della piattaforma (PA).

Soluzione alternativa: aggiungi manualmente l'etichetta observability.gdc.goog/auditlog-destination=pa allo spazio dei nomi platform in tutti i cluster dell'organizzazione. Per implementare questa soluzione alternativa manuale, segui questi passaggi:

  1. Imposta KUBECONFIG sul cluster di destinazione.

  2. Aggiungi l'etichetta richiesta allo spazio dei nomi:

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

  3. Verifica che l'etichetta sia stata aggiunta correttamente:

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

I pod non riescono a inizializzare i container

Versioni: 1.13.x

Sintomi: la creazione dei pod non riesce e viene visualizzato un errore simile al seguente:

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

Questi errori impediscono l'avvio dei pod su un nodo specifico. Il comportamento osservato deriva da un caso limite noto in cui il file di stato logrotate-daemon viene bloccato, impedendo al daemon di eseguire la rotazione dei file prevista. Per confermare questo errore, segui questi passaggi:

  1. Imposta KUBECONFIG sul cluster di destinazione.

  2. Identifica l'istanza anthos-audit-logs-forwarder-xxxx pianificata sul nodo.

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

  3. Recupera i log dall'istanza anthos-audit-logs-forwarder-xxxx pianificata sul nodo da verificare.

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

Soluzione:

Per risolvere il problema, segui questi passaggi:

  1. Esegui il recupero manuale dello spazio su disco nella directory /var/log del nodo.

  2. Imposta KUBECONFIG sul cluster di destinazione.

  3. Identifica il nodo di destinazione nel cluster.

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

  4. Connettiti al nodo utilizzando SSH e libera manualmente spazio nella directory /var/log sul nodo. logrotate gestisce i file in queste directory.

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

  5. Controlla la presenza di file di log insolitamente grandi (dimensioni superiori a 100 MB) o di file più vecchi di un paio di giorni. Quando hai il file di destinazione, puoi troncare i log nel seguente modo:

    truncate -s 1G <target_file>

  6. Identifica l'istanza anthos-audit-logs-forwarder-xxxx pianificata sul nodo.

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

  7. Riavvia l'istanza anthos-audit-logs-forwarder-xxxx pianificata sul nodo.

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

Marketplace

Il pull dell'immagine Prisma Cloud non riesce

Versioni: 1.13.7

Sintomi: la creazione di un'istanza di servizio Prisma Cloud da Marketplace non va a buon fine. Il problema è causato da un tag immagine errato.

Soluzione:

  1. Modifica il deployment twistlock-console per modificare il tag dell'immagine:

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

  2. Trova la seguente riga:

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. Sostituisci console_33_01_137 con console_33.01.137:

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

  4. Verifica che il pod venga eseguito correttamente:

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

    L'output potrebbe essere simile a questo esempio:

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

Monitoraggio

Numero elevato di avvisi creati in ServiceNow

Versioni: 1.13.x

Sintomi:

Dopo aver configurato Monitoring per inviare avvisi a ServiceNow utilizzando le attività di routine MON-T0016 e MON-T1016, in ServiceNow viene creato automaticamente un numero elevato di incidenti.

Il problema presenta le seguenti caratteristiche:

  • Tutti gli incidenti sono vuoti.
  • Solo il cluster amministratore principale e l'organizzazione gdchservices possono inviare avvisi a ServiceNow.

Soluzione alternativa: esegui l'attività di manutenzione MON-T0018 subito dopo aver eseguito le attività di manutenzione MON-T0016 e MON-T1016.

Più avvisi duplicati creati in ServiceNow

Versioni: 1.13.x

Sintomi:

Dopo aver configurato Monitoring per inviare avvisi a ServiceNow utilizzando le attività ripetitive MON-T0016, MON-T1016 e MON-T0018, in ServiceNow vengono creati più avvisi duplicati.

Il problema presenta le seguenti caratteristiche:

  • Per alcuni avvisi vengono creati più incidenti duplicati anche dopo l'applicazione dell'attività di routine MON-T0018.

Soluzione alternativa: esegui l'attività di manutenzione MON-T0019 subito dopo aver eseguito le attività di manutenzione MON-T0016, MON-T1016 e MON-T0018.

Impossibile visualizzare le metriche di Vertex AI

Versioni: 1.13.1

Sintomi: le metriche non vengono emesse dal pod dvs-frontend-server.

Soluzione alternativa: la versione 1.13.1 non supporta le metriche criptate per i servizi Vertex AI. Se il servizio Vertex AI non viene abilitato per più di un'ora, riavvia il pod controller mon-admin.

Errore di riconciliazione in mon-cortex

Versioni: 1.13.1, 1.13.9

Sintomi: il pod mon-cortex presenta un errore di riconciliazione. Visualizza lo stato del pod mon-cortex:

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

L'output potrebbe essere simile al seguente:

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

Potrebbe essere registrato un messaggio come questo:

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

Soluzione:

  1. Controlla quale pod Cortex mostra un messaggio come questo:

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

  2. Elimina la PVC associata al pod e riavvialo.

Il pod metrics-server-exporter nel cluster di sistema è in crash loop

Versioni: 1.13.1

Sintomi: il pod metrics-server-exporter nel cluster di sistema è in crash looping con OOMKilled, ma non sembra raggiungere il limite. Diagnostica l'errore:

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

L'output potrebbe essere simile al seguente:

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

Soluzione alternativa:riduci la quantità di dati pubblicati sull'endpoint delle metriche eliminando il pod e riavviandolo. Il vecchio time-series memorizzato viene cancellato, riducendo la memoria necessaria.

Ignorare i messaggi di errore di riconciliazione di ObservabilityPipeline

Versioni: 1.13

Sintomi:

L'oggetto ObservabilityPipeline mostra i log Reconciler error come i seguenti nel pod root-admin-controller:

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

Soluzione:

Ignora i log che soddisfano tutte le seguenti condizioni:

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

Se stai eseguendo il debug di un avviso a causa di un numero elevato di errori di riconciliazione, ignora questi log perché sono falsi negativi.

Il ConfigMap mon-prober-backend-prometheus-config viene reimpostato

Versioni: 1.13.0 e 1.13.1

Sintomi:

  • L'avviso MON-A0001 è attivato.

  • L'oggetto ConfigMap mon-prober-backend-prometheus-config viene reimpostato in modo da non includere job di probe, ad esempio:

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

Soluzione:

Per risolvere il problema, procedi nel seguente modo:

  1. Imposta le seguenti variabili di ambiente:

    • KUBECONFIG: il percorso del file kubeconfig nel cluster.
    • TARGET_CLUSTER: il nome del cluster in cui stai risolvendo il problema.

  2. Metti in pausa il componente secondario mon-prober su tutti i cluster:

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

    Ad esempio:

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

  3. Riavvia il controller amministratore MON su ogni cluster di amministrazione:

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    ConfigMap Prober viene compilato man mano che ogni probe viene registrato.

  4. Segui il runbook MON-R2009 per disattivare l'avviso MON-A0001, Blackbox monitoring metrics pipeline down, perché questo avviso continuerà a essere attivato.

Componente gateway dello store Cortex OOMKilled crashloop

Versioni: 1.13.3

Sintomi: se visualizzi errori su Grafana durante il caricamento delle metriche o se le metriche non vengono caricate, il pod cortex-store-gateway potrebbe essere in crash loop.

Per diagnosticare il pod cortex-store-gateway e verificare se è in crash loop, controlla il suo stato:

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

Sostituisci SYSTEM_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di sistema.

Se il pod è in crash loop, l'output è simile al seguente esempio:

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

Soluzione: aumenta temporaneamente il limite di memoria cortex-store-gateway utilizzando un SubcomponentOverride. Per informazioni dettagliate sull'implementazione di un SubComponentOverride, consulta il runbook MON-R2008.

Di seguito è riportato un esempio di SubcomponentOverride con un limite di memoria specificato:

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

Lascia l'override in posizione finché tutti i podcortex-store-gateway non hanno uno stato Ready e assicurati che il componente secondario mon-cortex non sia in pausa:

  • Verifica che i pod cortex-store-gateway abbiano lo stato Ready:

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    Se tutti i pod hanno lo stato Ready, l'output è simile al seguente esempio:

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    La colonna READY deve mostrare un valore N/N per tutti i pod per essere pronti. In caso contrario, mostra valori come 1/3 o 2/3.

  • Assicurati che il componente secondario mon-cortex non sia in pausa in una determinata organizzazione:

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    Sostituisci quanto segue:

    • ORG_ADMIN_KUBECONFIG: il percorso del file kubeconfig dal cluster di amministrazione dell'organizzazione.
    • SYSTEM_CLUSTER: il nome del cluster di sistema.

    Se il sottocomponente è in pausa, l'output mostra la seguente riga:

    lcm.private.gdc.goog/paused: true

    In caso contrario, l'output è vuoto.

Backoff del pull dell'immagine proxy delle metriche del control plane di Kube nel cluster utente

Versioni: 1.13.3

Sintomi: quando le metriche relative a kube-scheduler o kube-controller-manager (ad esempio le metriche scheduler_pending_pods e workqueue_depth) non sono visibili in Grafana, potrebbe esserci un problema di pullback dell'immagine con il pod kube-control-plane-metrics-proxy.

Per diagnosticare il pod kube-control-plane-metrics-proxy e verificare se presenta un problema di backoff del pull delle immagini, controlla il suo stato:

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

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

Se il pod presenta un problema di backoff del pull dell'immagine, l'output è simile al seguente esempio:

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

Soluzione alternativa: segui questi passaggi per risolvere il problema:

  1. Estrai l'immagine gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 dal progetto gpc-system-container-images Harbor. Per istruzioni e autorizzazioni necessarie per eseguire il pull di un'immagine, consulta Eseguire il pull di un'immagine con Docker.

  2. Esegui il push dell'immagine gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 nel progetto library Harbor. Per le istruzioni e le autorizzazioni necessarie per eseguire il push di un'immagine, consulta Eseguire il push di un'immagine.

    Il progetto library viene utilizzato per il deployment degli artefatti nel cluster utente.

Un aumento del WAL fa sì che Prometheus utilizzi molta memoria

Versioni: 1.13.3

Sintomi: il nodo VM del control plane di sistema segnala gli eventi NodeHasInsufficientMemory e EvictionThresholdMet:

kubectl describe node NODE_NAME | grep Events -A100

L'output potrebbe essere simile al seguente esempio:

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

Prometheus utilizza molta memoria a causa della crescita del WAL (write-ahead log), che influisce sulla memoria del nodo. L'aumento del WAL potrebbe verificarsi perché Cortex non è stato implementato, quindi questo problema potrebbe essere una conseguenza del mancato funzionamento di Cortex. L'istanza Prometheus perde la connettività a Cortex per un periodo di tempo prolungato, durante il quale memorizza i dati nel buffer in memoria e sul volume permanente (PV). Quando Prometheus viene terminato, carica tutti i dati nel WAL in memoria all'avvio.

Un'altra causa principale potrebbero essere problemi di connettività di rete (mesh di servizi, reti fisiche e superiori).

Soluzione alternativa: per ripristinare questo stato, l'azione consigliata è risolvere la causa principale e ripristinare il corretto funzionamento di Cortex o risolvere i problemi di connettività di rete. Poi, attendi che il WAL di Prometheus si esaurisca. Non perdi dati, ma se Cortex non era disponibile, il nodo non è disponibile per il periodo di tempo necessario per il ripristino di Cortex.

In alternativa, puoi fare lo scale down Prometheus STS a zero ed eliminare il PV. Questa azione riduce il tempo totale in cui il nodo non è disponibile, ma comporta la perdita di dati. Inoltre, finché Cortex rimane inattivo o riscontri problemi di connettività di rete, devi ripetere questa azione periodicamente. Finché esiste un problema di connessione tra Prometheus e Cortex, il PV si riempirà di nuovo.

Per fare lo scale down Prometheus STS a zero ed eliminare il PV:

  1. Riduci le dimensioni del componente logmon-operator:

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

    Sostituisci ORG_SYSTEM_KUBECONFIG con il percorso del file kubeconfig nel cluster di sistema dell'organizzazione.

  2. Ridimensiona il componente anthos-prometheus-k8s:

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

  3. Elimina la richiesta di volume permanente:

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

  4. Esegui il backup di logmon-operator:

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

  5. Attendi che anthos-prometheus-k8s sia pronto.

Bootstrap multizona

Ruoli del cluster mancanti

Versioni: 1.13.1

Sintomi:non esistono ruoli specifici per il bootstrapping multizona da utilizzare in Aggiungi ruoli richiesti.

Soluzione:utilizza il ruolo del cluster cluster-admin come specificato nelle istruzioni collegate. In questo modo, l'utente dispone di un accesso superiore a quello minimo richiesto per svolgere le attività successive.

Risorsa Bootstrap incompatibile

Versioni: 1.13.1

Sintomi: la risorsa Bootstrap creata nel passaggio 3 di Crea il file di bootstrap è incompatibile con la logica che la elabora.

Soluzione alternativa:modifica il file YAML generato come specificato nel passaggio 4.

La risorsa GlobalAPIZone non viene creata nell'API globale

Versioni: 1.13.1

Sintomi:il control plane non crea una risorsa GlobalAPIZone per la zona nell'API globale, pertanto i componenti che si basano su questa risorsa non funzionano correttamente.

Soluzione: crea la risorsa come indicato in Crea risorsa GlobalAPIZone.

Networking

Rete di nodi di archiviazione degli oggetti inattiva

Versioni: 1.13.1, 1.13.3, 1.13.4

Sintomi:

  1. Durante la fase di bootstrapping dell'object storage, la rete della griglia viene visualizzata come inattiva nell'interfaccia utente del programma di installazione del nodo di amministrazione OBJ.
  2. cables.csv e Cell CR mostrano che il valore MPN in cables.csv è QSFP-100G-CU2.5M per le connessioni tra i nodi di archiviazione degli oggetti objsadmin e TOR Switch.

Spiegazione Nella versione 1.13, il campo MPN in cables.csv viene utilizzato per determinare la velocità impostata sullo switch Tor. Se la velocità non è impostata su queste porte, la connettività dello switch Tor al nodo objsadmin non andrà a buon fine. L'elenco utilizzato per mappare l'MPN alla velocità non teneva conto di un valore fornito dall'integratore di sistemi, causando l'errore del bootstrap dell'archiviazione di oggetti. Nella maggior parte delle configurazioni 1.13, il fornitore ha utilizzato: QSFP-100G-CU2.5M.

Soluzione:

  1. Utilizza kubectl get -A cell -oyaml nel cluster root-admin per trovare la connessione correlata all'appliance di archiviazione degli oggetti e allo switch TOR.
  2. Modifica tutte le occorrenze di mpn in "QSFP-100G-CU3M" per objsadm -> torsw connect.

Ecco un esempio:

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

Nodo non raggiungibile

Versioni: 1.13.1, 1.13.3, 1.13.4

Sintomi:

  1. Durante la fase di bootstrapping della rete alcuni switch non sono raggiungibili.
  2. Durante la fase di installazione DHCP, alcuni server non sono raggiungibili tramite il loro indirizzo IP iLO.

Soluzione:

  1. Ricarica gli switch di gestione interessati. Per maggiori dettagli, consulta il runbook PNET-R0018.

PodCIDR non assegnato ai nodi anche se ClusterCIDRConfig è stato creato

Versioni: 1.13.1

Sintomi: un ClusterCIDRConfig è un oggetto obbligatorio per assegnare PodCIDRs. Nonostante la creazione di ClusterCIDRConfig, PodCIDRs non è stato assegnato. Questo problema si verifica se viene creato un ClusterCIDRConfig contemporaneamente all'avvio dei pod ipam-controller. La creazione del cluster è bloccata nello stato di riconciliazione.

  1. Controlla se l'oggetto ClusterCIDRConfig è stato creato sul cluster:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    L'output potrebbe essere simile al seguente:

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

  2. Esegui describe per uno degli oggetti nodo del cluster bloccato nella riconciliazione e verifica se è presente un evento CIDRNotAvailable nell'oggetto nodo:

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    Gli eventi di output potrebbero avere il seguente aspetto:

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

Soluzione:

  1. Riavvia i pod ipam-controller-manager:

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

  2. Dopo che i pod ipam-controller-manager sono in esecuzione, controlla se podCIDR è assegnato ai nodi:

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

    L'output potrebbe essere simile al seguente:

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

Deriva NTP

Versioni: 1.13.1

Sintomi: un nodo VM ha un'ora imprecisa o non sincronizzata dopo essere stato inattivo o in esecuzione per un po' di tempo.

Soluzione:

  1. Stabilisci una connessione SSH al nodo VM e modifica il file /etc/chrony.conf.
  2. Sostituisci la riga makestep 1.0 3 con makestep 1.0 -1.

  3. Riavvia il servizio chronyd:

    systemctl restart chronyd

Devi apportare questa modifica una sola volta a ogni VM. La modifica non verrà sovrascritta.

Per una soluzione rapida e immediata per modificare l'ora, stabilisci una connessione SSH al nodo VM ed esegui chronyc -a makestep.

Log di controllo di SyncServer non analizzati

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

Sintomi: i log di controllo di SyncServer non vengono analizzati correttamente da log-remote-logger. Alcuni log di controllo non saranno disponibili in Grafana e potresti visualizzare messaggi di errore nel pod root-admin log-remote-logger, ad esempio:

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

Soluzione alternativa: i log di controllo sono ancora disponibili su SyncServer. Segui NTP-P0002 per accedere all'interfaccia utente di SyncServer e visualizzare i log in Logs > Events.

Impossibile estrarre l'immagine dall'immagine dell'opzione

Versioni: 1.13.3

Sintomi: potresti visualizzare un messaggio simile a questo nell'oggetto SwitchImageHostRequest quando esegui un'inversione RMA o quando esegui il bootstrapping del cluster root-admin:

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

Se hai accesso a kubectl, utilizzalo per verificare se stai riscontrando questo problema:

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

L'output potrebbe essere simile al seguente esempio:

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

Soluzione:

Crea manualmente un SwitchImageHostRequest con il tag immagine corretto:

  1. Accedi al server bootstrapper.

  2. Utilizza gdcloud per identificare la versione corretta dell'immagine di cambio:

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    L'output potrebbe essere simile al seguente esempio:

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    Da questo output, la versione corretta dell'immagine dell'interruttore è 1.13.3-gdch.5385.

  3. Modifica l'oggetto SwitchImageHostRequest che segnala l'errore:

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

  4. Modifica o sostituisci i campi name, fromVersion e toVersion in modo che corrispondano alla versione dell'immagine di commutazione prevista. In questo caso, è 1.13.3-gdch.5385. Vedi l'output diff riportato di seguito, che illustra le modifiche da apportare all'oggetto SwitchImageHostRequest.

    kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

La comunicazione dei pod StatefulSet non riesce

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

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

Problemi di connettività alle istanze DBS

Versioni: 1.13.0, 1.13.1

Sintomi: le istanze di Database Services (DBS) non sono accessibili e i client di database mostrano timeout di connessione.

Questo problema potrebbe essere rilevato tramite un altro componente di sistema che si basa su DBS. Ad esempio, la fatturazione potrebbe segnalare messaggi di errore come i seguenti:

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

Soluzione alternativa: l'errore è causato da un componente del sistema di rete che non è in grado di pianificare il cluster di servizi dell'organizzazione.

  1. Imposta le seguenti variabili di ambiente:

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    Sostituisci quanto segue:

    • KUBECONFIG_PATH: il percorso del file kubeconfig del cluster di amministrazione dell'organizzazione.
    • ORG_NAME: il nome della tua organizzazione, ad esempio org-1.

  2. Aggiorna la configurazione del componente di rete per consentirne la pianificazione:

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

La connettività di Networking viene ripristinata dopo alcuni minuti.

La mesh del cluster non è configurata con le informazioni sulla zona

Versioni: 1.13.5

Sintomi: una VM non può connettersi a un cluster di database nello stesso progetto. La connettività al bilanciatore del carico interno è interessata. Questo problema è causato da un Clustermesh che non riesce a scambiare oggetti di servizio tra i cluster a causa della mancanza di informazioni sulla zona nella configurazione del nome del cluster.

Soluzione alternativa: negli ambienti di cui è stato eseguito il bootstrap come multizona, esegui i seguenti passaggi manuali della soluzione alternativa per far funzionare il bilanciatore del carico interno:

  1. Nel cluster di amministrazione dell'organizzazione, recupera il nome della zona:

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

    L'output potrebbe essere simile a questo esempio:

    zone1

  2. Nel cluster di amministrazione dell'organizzazione, recupera l'ID sito della zona:

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

    L'output potrebbe essere simile a questo esempio:

    1

  3. Elenca tutti i cluster:

    ​​kubectl get clusters -A

    L'output potrebbe essere simile a questo esempio:

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

  4. Per ogni cluster, costruisci il CILIUM_CLUSTERNAME:

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

    L'output potrebbe essere simile a questo esempio:

    org-1-system-zone1

  5. Per ogni cluster, imposta gli altri parametri come segue. L'esempio seguente per org-1-system:

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. Per ogni cluster, crea un oggetto AddOnConfiguration e archivialo in un file addonconfig.yaml. Crea questo file per tutti i cluster esistenti e per tutti i nuovi cluster che creerai in futuro:

    In questa pagina, imposta le seguenti variabili per aggiornare l'esempio di codice:

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

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

  7. Applica addonconfig.yaml al cluster di amministrazione dell'organizzazione:

    kubectl apply -f addonconfig.yaml

  8. Nei cluster di sistema, di servizio e utente, assicurati che cluster-name sia aggiornato in cilium-config sul cluster. L'aggiornamento potrebbe richiedere un po' di tempo, ma questo passaggio è necessario prima di riavviare il deployment di clustermesh-apiserver.

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. Nei cluster di sistema, di servizio e utente, riavvia il deployment di clustermesh-apiserver:

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

Vengono generati indirizzi IP EVPN errati

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

Sintomi: gli indirizzi IP di peering della sessione di interconnessione EVPN multizona (MZ) generati da Hardware Asset Management System (HAMS) non terminano con .65 o .66, il che è errato e impedisce l'instaurazione delle sessioni BGP EVPN MZ.

Soluzione:

Per risolvere manualmente il problema, segui questi passaggi:

  1. Elenca tutte le risorse InterconnectSession:

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

  2. Esamina le risorse EVPN multizona InterconnectSession generate che hanno un valore interconnectType di ZonePeering e un addressFamily di EVPN:

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

  3. Per ciascuna delle risorse InterconnectSession che corrispondono a questi parametri, applica la seguente correzione:

    1. Controlla il nome della risorsa personalizzata della sessione di interconnessione.
    2. Se il nome termina con un numero dispari, aggiorna l'ultima parte dell'indirizzo IP peer a 65 utilizzando il comando nel passaggio successivo.
    3. Se il nome termina con un numero pari, aggiorna l'ultima parte dell'indirizzo IP peer a 66 utilizzando il comando nel passaggio successivo.

  4. Modifica la risorsa InterconnectSession con l'indirizzo IP del peer errato:

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

  5. Applica questa correzione a tutte le risorse InterconnectSession che causano l'errore.

La dashboard del control plane di Networking superiore non mostra dati

Versioni: 1.13.7

Sintomi: le query Prometheus in TestUpperNetworkingMetrics non vanno a buon fine a causa della mancanza di metriche nel cluster org-1-system. I pannelli di clustermesh nella dashboard del control plane di Upper Networking per gli amministratori dell'organizzazione IO non mostrano dati. Il problema deriva da una mancata corrispondenza nell'etichetta source_cluster tra Cilium e il sistema di monitoraggio.

Soluzione alternativa: rimuovi il filtro source_cluster dal dashboard del control plane UNET per visualizzare i dati.

Errori fuorvianti visualizzati durante l'installazione di rete

Versioni: 1.13.1

Sintomi: durante l'installazione della rete, vengono visualizzati alcuni messaggi di avviso relativi al cablaggio. Ad esempio:

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

Questi messaggi di errore possono essere ignorati.

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

Archiviazione di oggetti

Impossibile eliminare l'organizzazione di archiviazione

Versioni: 1.13.1

Sintomi: l'eliminazione di un'organizzazione potrebbe non riuscire a causa di un problema che impedisce il completamento dell'eliminazione di SVM. Potresti visualizzare un avviso come questo:

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

È possibile ignorare alcuni avvisi di upgrade dell'object storage

Versioni: 1.13.3

Sintomi: quando esegui l'upgrade dell'object storage, potresti visualizzare un avviso come questo:

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

Soluzione:

  1. Controlla che ogni nodo abbia le credenziali SSH corrispondenti archiviate in un secret.

    1. Controlla i nodi di amministrazione:

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

    2. Controlla i nodi di archiviazione:

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

      L'output riuscito è simile a questo esempio per i nodi di archiviazione:

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

      Se non viene trovato un secret, l'errore ha il seguente aspetto:

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

  2. Se il comando non restituisce errori, puoi ignorare senza problemi gli errori segnalati dai riconciliatori.

ObjectStorageStorageNodeReconciler report maintenance.gdu.gdu_server_locked

Versioni: 1.13.3

Sintomi: mostra i dettagli di objectstoragestoragenode:

kubectl describe objectstoragestoragenode zv-aa-objs02

L'output potrebbe essere simile al seguente esempio:

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

Soluzione alternativa: questo problema può essere ignorato. Il servizio GDU potrebbe bloccarsi temporaneamente quando riceve troppe richieste, ma si sbloccherà dopo alcuni minuti.

Il controllo dell'archiviazione degli oggetti dell'upgrade post-volo 1.12.x -> 1.13.x non va a buon fine

Versioni: 1.13.x

Sintomo: la CR ObjectStorageUpgrade non va a buon fine e viene visualizzato l'errore

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

Pod gpc-system/upgrade-managed-check-objectstorageupgrade non riusciti con errore

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

Causa principale: L'upgrade del componente operativo Object Storage dalla versione 1.12.x alla 1.13.x non riesce se il cluster KIND di bootstrapping non è stato disattivato o eliminato. Anche se l'upgrade va a buon fine, i servizi di archiviazione di oggetti comuni, come la creazione di nuovi bucket o credenziali S3 tramite Kubernetes RBAC, potrebbero non riuscire a causa di errori di convalida del certificato TLS. Questo perché un pod di archiviazione di oggetti specifico all'interno del cluster KIND tenta continuamente di installare il certificato server TLS dell'endpoint di gestione StorageGRID, valido nella versione 1.12.x, ma che potrebbe non essere riconosciuto nella versione 1.13.x. Durante l'upgrade, StorageGRID installa un nuovo certificato del server TLS verificabile, ma il pod del cluster KIND lo sostituisce con il certificato precedente non valido, causando l'errore del certificato TLS.

Soluzione alternativa: Devono essere soddisfatti i seguenti requisiti:

  • L'upgrade dell'archiviazione di oggetti dalla versione 1.12.x alla 1.13.x
  • Il cluster di bootstrapping (il cluster KIND) esiste ancora

Segui questi passaggi:

  1. Acquisisci un kubeconfig con autorizzazione di visualizzazione e modifica della risorsa ObjectStorageSite nel cluster di bootstrapping (il cluster KIND).

  2. Imposta un alias per kubectl che si connette al cluster di bootstrapping (il cluster KIND):

    alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

  3. Recupera l'istanza della risorsa personalizzata ObjectStorageSite dal cluster di bootstrap. Deve essere presente un'istanza di risorsa ObjectStorageSite:

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. Aggiungi un'annotazione di pausa dell'archiviazione degli oggetti all'istanza della risorsa ObjectStorageSite:

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

  5. Verifica che l'annotazione di pausa dell'object storage sia stata aggiunta all'istanza ObjectStorageSite:

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. Acquisisci un kubeconfig con accesso in visualizzazione e autorizzazione di patch di stato alle risorse ObjectStorageCluster nel cluster amministratore root.

  7. Imposta un alias per kubectl che si connette al cluster di amministrazione principale:

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

  8. Controlla se esiste un'istanza di risorsa ObjectStorageCluster nel cluster di amministrazione principale:

    kubectlrootadmin get ObjectStorageCluster

    Se non è presente un'istanza della risorsa ObjectStorageCluster, la soluzione alternativa è stata completata. Potresti dover eseguire di nuovo la procedura di upgrade di Object Storage.

  9. Recupera l'URL dell'endpoint di gestione dallo stato della risorsa ObjectStorageSite nel cluster di bootstrapping:

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

  10. Verifica se la variabile di ambiente $MGMT_ENDPOINT è stata impostata. L'endpoint deve iniziare con https://:

    echo ${MGMT_ENDPOINT:?}

  11. Esegui i passaggi rimanenti solo quando è presente esattamente un'istanza della risorsa ObjectStorageCluster nel cluster di amministrazione principale. In caso contrario, esegui di nuovo la procedura di upgrade di Object Storage:

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

  12. Riavvia il pod gpc-system/obj-infra-cluster-cm:

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

  13. Verifica se l'endpoint di gestione è stato aggiunto allo stato della risorsa ObjectStorageCluster:

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. Riavvia il controllo post-volo eliminando il job Kubernetes di controllo post-volo gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>. Il job verrà ricreato a breve.

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

    Il certificato dell'endpoint del bilanciatore del carico StorageGRID è scaduto

Versioni: 1.13.10, 1.13.11, 1.13.12

Sintomi:il proxy di archiviazione di oggetti segnala 502 Bad Gateway.

Soluzione:segui OBJ T0003.

Sistema operativo

Pod bloccati nello stato init

Versioni: 1.13.1

Sintomi: il nodo segnala che è pronto, ma l'accesso SSH al nodo è lento e e top -n 1 mostra più di 100 processi zombie.

Soluzione:

  1. Segui OS-P0001 per svuotare il server. Lo scaricamento potrebbe richiedere più di 20 minuti. Se lo scaricamento non riesce dopo un'ora, vai al passaggio successivo.

  2. Riavvia il server stabilendo una connessione SSH al server ed emettendo il seguente comando:

    systemctl reboot

  3. Per ripristinare completamente il server potrebbe essere necessario un secondo riavvio.

  4. Verifica che l'accesso SSH non sia più lento e che il numero di processi zombie sia molto inferiore, preferibilmente inferiore a 30.

  5. Rimuovi il server dal pool impostando maintenance su false sul server.

bm-system-machine-preflight-check Il job Ansible per un nodo bare metal o VM non va a buon fine

Versioni: 1.13.1

Sintomi:il modulo del kernel nf_tables non viene caricato dopo il riavvio, causando l'errore Either ip_tables or nf_tables kernel module must be loaded nei job Ansible del cluster. Questo problema si verifica quando il nodo bare metal o VM viene riavviato prima del provisioning completo. Il job Ansible potrebbe generare un errore come questo:

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

Soluzione temporanea:

Stabilisci una connessione SSH al nodo ed esegui il seguente comando:

modprobe nf_tables

VM con spazio esaurito sul dispositivo

Versioni: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Sintomi: quando la directory dei log /var/log è piena, Node potrebbe bloccarsi con lo stato NotReady e i pod potrebbero non avviarsi a causa dell'errore no space left on device. Per verificarlo, esegui questo comando sul nodo e controlla se l'utilizzo è intorno al 100%.

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

Soluzione:

  1. Accedi al nodo in cui si verifica il problema ed elimina i vecchi archivi dei log per /var/log/messages.

    find /var/log -name "messages*" -mtime +4 -delete

    Ti consigliamo inoltre di continuare ad applicare la seguente soluzione alternativa per evitare che si verifichi. La soluzione alternativa consiste nel creare un AnsiblePlaybook e applicare la modifica tramite una risorsa personalizzata OSPolicy responsabile della configurazione sicura del sistema operativo di destinazione (macchine BM+VM). Per ulteriori dettagli, consulta la procedura OS-P0005.

  2. Imposta le seguenti variabili di ambiente:

    export KUBECONFIG=<the path to the kubeconfig file>

  3. Crea un playbook Ansible per la soluzione alternativa:

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

  4. Identifica gli inventari di destinazione a cui deve essere applicata la modifica. La destinazione può essere un singolo InventoryMachine o un NodePool. Fai riferimento alla procedura OS-P0005 (2. Identifica l'inventario di destinazione per le configurazioni di runtime) per i dettagli.

    Il seguente esempio di OSPolicy include due inventari di destinazione in spec.inventory. Puoi aggiungere altri inventari in base alle esigenze.

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

  5. Convalida

    Fai riferimento alla procedura OS-P0005 (convalida) per monitorare lo stato di esecuzione delle norme.

Pod bloccati nello stato ContainerCreating

Versioni: 1.13.3, 1.13.5, 1.13.6

Sintomi: un nodo viene visualizzato come integro, ma ha molti pod bloccati nello stato ContainerCreating e non puoi stabilire una connessione SSH al server.

Soluzione alternativa: riavvia il server e verifica di poter stabilire una connessione SSH al nodo quando viene ripristinato.

Impossibile accedere tramite SSH al nodo di cui è stato eseguito il provisioning

Versioni: 1.13.5

Sintomi: viene eseguito il provisioning di un nodo, ma il timeout SSH si verifica sia sugli IP di gestione che su quelli dei dati.

Soluzione: riavvia il nodo tramite iLO. Dopo l'avvio, accedi tramite SSH e disattiva clamonacc con systemctl stop clamonacc; systemctl disable clamonacc.

I nodi Bare Metal non riescono ad avviarsi dall'immagine sistema operativo più recente perché l'avvio protetto non riconosce la firma del sistema operativo

Versioni: 1.13.12

Sintomi: dopo l'upgrade alla versione 1.13.12, se il nodo viene riavviato, il sistema operativo non riesce ad avviarsi con il nuovo kernel. La schermata della console iLO mostra un problema relativo all'avvio protetto:

../../grub-core/loader/i386/efi/linux.c:385:(hd0,gpt2)/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64 has invalid signature,..:
 ../../grub-core/loader/i386/efi/linux.c:256: you need to load the kernel first.

Soluzione:

  1. Per qualsiasi nodo che non si avvia a causa di questo problema, accedi alla schermata GRUB tramite la console iLO e seleziona Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64 come destinazione di avvio. Questa procedura fa sì che il nodo si avvii con il kernel precedente noto.

  2. Per tutti i server bare metal di cui è stato eseguito l'upgrade alla versione GDC 1.13.12, esegui i seguenti passaggi per evitare l'errore di avvio:

    1. Stabilisci una connessione SSH al server.
    2. Esegui i seguenti comandi sul server per rimuovere il kernel problematico:
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. Verifica che il kernel predefinito sia stato ripristinato correttamente a una versione funzionante:
    grubby --default-kernel

Il risultato è /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64.

Infrastruttura della suite operativa (OI)

L'SSA non è necessaria per Hardware 3.0

La configurazione dell'adattatore RAID è diversa per Hardware 3.0. I server OIC hardware 3.0 utilizzano un'unità autocrittografata, pertanto l'avvio di Smart Storage Administration (SSA) non è più necessario. Sono necessari passaggi aggiuntivi per determinare gli identificatori del disco per server. Vedi Bootstrap del server OI.

Sicurezza perimetrale

Il cluster di sistema dell'organizzazione si blocca durante il bootstrap dell'organizzazione

Versioni: 1.13.1

Sintomi:durante l'avvio dell'organizzazione, il cluster di sistema dell'organizzazione potrebbe bloccarsi. I pod edr-sidecar-injector sono in stato In attesa. Quando provi a eliminare questi pod, potresti visualizzare un messaggio di errore come questo:

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

Allo stesso tempo, altri pod in attesa potrebbero presentare messaggi di errore come questo:

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

Il sistema richiede un intervento manuale per sbloccarsi.

Soluzione:

  1. Duplica MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg sul cluster di sistema.
  2. Duplica ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration sul cluster di sistema.
  3. Elimina sia la CR edr-sidecar-injector-webhook-cfg sia la CR gatekeeper-validating-webhook-configuration dal cluster di sistema.
  4. Attendi il ripristino dei pod edr-sidecar-injector e di gatekeeper-controller-manager.
  5. Ripristina il CR webhook con il comando kubectl apply.

I gruppi di indirizzi firewall PANW non vengono aggiornati con le modifiche alla rivendicazione CIDR

Versioni: 1.13.1

Sintomi: durante il bootstrap, OCIT cidr-claim si aggiorna con il valore corretto, ma il firewall AddressGroups no. Una coppia di AddressGroups, in particolare vsys1-root-ocit-network-cidr-group e ocvsys1-root-ocit-network-cidr-group, utilizza blocchi di rete che non si sovrappongono a quelli effettivamente in uso in OIR. OIR non è in grado di risolvere i record di zona GDC e le query vanno in timeout senza una risposta.

Soluzione: dopo le modifiche a cidr-claim, assicurati che AddressGroup venga aggiornato con l'ultima versione di cidr-claim riavviando il deployment di fw-core-backend-controller nello spazio dei nomi fw-system nel cluster root-admin.

Server fisici

Il bootstrap del server non riesce a causa di problemi POST sul server HPE

Versioni: 1.13.1

Sintomi:il bootstrap del server non va a buon fine quando un server non supera il processo di avvio POST. L'accesso a ILO e il controllo della console del server mostrano il seguente errore:

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

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

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

ACTION : Reboot the server.

Soluzione temporanea:

Da iLO, fai clic sul pulsante di accensione e seleziona Cold Boot.

Server bloccati nello stato di provisioning

Versioni: 1.13.1, 1.13.3, 1.13.5

Sintomi:i server sono bloccati in uno stato di provisioning durante il bootstrap del server. Controlla lo stato dei server:

k get servers -A | grep -v availabl

L'output potrebbe essere simile al seguente:

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

Soluzione:

  1. Avvia dhcp manualmente con una configurazione scaricata dal cluster KIND. In questo esempio /tmp/dhcp.conf è la configurazione DHCP del cluster KIND:

    docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION

    Sostituisci VERSION con la versione di rilascio come descritto nelle istruzioni di upgrade in Upgrade manuale del componente File per i cluster di amministratori root e dell'organizzazione, ad esempio 1.13.1-gdch.525.

  2. Controlla la configurazione del BIOS sul server e verifica che NetworkBoot non sia abilitato per le NIC del piano dati (denominate nel pattern Slot{i}Nic{i}).

  3. Controlla il BIOS tramite la chiamata API:

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    Dove $bmcUser e $bmcPassword sono le password per gli ILO, che possono essere trovate nel file o nella directory cellcfg in un secret chiamato bmc-credentials-<server-name>, ad esempio bmc-credentials-ai-aa-bm01. Verifica che l'output di questo comando mostri Slot1Nic1: Disabled.

  4. Se uno di questi Slot{i}Nic{i} ha NetworkBoot, disabilitalo con l'API delle impostazioni del BIOS.

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

    Sostituisci Slot{i}Nic{i} con il nome dello slot che presenta il problema nel payload.

  5. Riavvia il server.

Il provisioning del server DL380a non riesce

Versioni: 1.13.3, 1.13.4, 1.13.5

Sintomi: il provisioning del server non riesce durante il job di crittografia per il modello HPE DL380a. Lo stato di Server CR è bloccato su available durante il bootstrap del server:

# server name
export SERVER_NAME=

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

Soluzione temporanea:

  1. Segui IAM-R0004 per generare KUBECONFIG per root-admin-cluster.

  2. Segui PLATAUTH-G0001 per generare la chiave SSH root-id_rsa per CLUSTER_NS=root.

  3. Metti in pausa il server aggiungendo l'annotazione server.system.private.gdc.goog/paused alla risorsa personalizzata del server:

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

  4. Accedi al server dall'IP di gestione:

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

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

  5. Attiva la crittografia manualmente:

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

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

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

    L'output dei comandi dovrebbe essere simile al seguente:

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

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

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

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

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

    Se l'ultimo comando non va a buon fine o visualizzi errori come "Invalid BIOS EKM status" (Stato EKM del BIOS non valido), prova a riavviare il server e iLO, quindi ripeti questo passaggio.

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

    Se l'ultimo comando è andato a buon fine, riavvia il server come indicato.

  6. Crea manualmente l'unità logica:

    Dopo il riavvio del server, accedi di nuovo al server dall'IP di gestione ed elenca tutte le unità disponibili:

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

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

    L'output dell'ultimo comando potrebbe essere simile a questo esempio:

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

    Devi salvare i due ID EID:Slt con Size uguale a 1.60 TB, in questo caso:

    252:1,252:2

    Poi crea un'unità logica utilizzando gli ID EID:Slt:

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

    L'output dell'ultimo comando è simile a questo esempio:

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

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

  7. Stato della crittografia del disco simulata nel report CR del server.

    Modifica lo stato della richiesta di modifica del server:

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

    Aggiungi o modifica lo stato DiskEncryptionEnabled su true:

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

  8. Elimina il job di crittografia del server, se presente:

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

  9. Riattiva il server in modo che il provisioning riprenda:

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

L'eliminazione sicura non riesce senza una licenza

Versioni: 1.13.5

Sintomi: quando un server si blocca durante l'installazione, potresti visualizzare uno stato sul server CR simile al seguente:

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

Soluzione alternativa: segui le istruzioni nel runbook SERV-R0014.

Sicurezza della piattaforma

BYO SubCA reconciler non verifica se i certificati hanno una chiave pubblica corrispondente

Versioni: 1.13.1

Sintomi: quando la modalità PKI BYO SubCA genera una nuova richiesta di firma del certificato (CSR) mentre un certificato firmato in precedenza viene caricato nella SubCA, il riconciliatore non controlla se la nuova CSR corrisponde al vecchio certificato firmato e contrassegna la risorsa personalizzata (CR) cert-manager CertificateRequest come Ready. Ciò si verifica durante il rinnovo o la rotazione manuale del certificato della SubCA. Il controller cert-manager tenta di aggiornare lo stato di Certificate CR, il che attiva il seguente messaggio di errore:

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

Soluzione temporanea:

Segui le istruzioni per caricare un nuovo certificato BYO SubCA firmato per la nuova CSR.

Il problema di cert-manager comporta l'emissione senza esito di PKI BYO con ACME

Versioni: 1.13.1

Sintomi:l'errore si verifica al primo rilascio o rinnovo dei certificati BYO con ACME (Automated Certificate Management Environment). Quando esegui il comando per controllare lo stato del certificato, visualizzi che il certificato è not ready:

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

L'output è simile al seguente:

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

Soluzione temporanea:

Riavvia il deployment di cert-manager nel cluster di amministrazione dell'organizzazione:

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

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

Resource Manager

Lo stato del progetto non è disponibile nella console GDC

Versioni: 1.13.1+

Sintomi:la console GDC non mostra lo stato di un progetto. I progetti che non si trovano nello stato Ready non possono supportare nuove risorse o elaborare nuove modifiche alle risorse esistenti. A causa dell'impossibilità di confermare lo stato del progetto, non è chiaro quando le risorse di un progetto possono essere gestite, il che comporta errori quando si tentano nuove azioni del progetto.

Soluzione:consulta il runbook RM-R0100 per stampare lo stato del progetto utilizzando kubectl CLI.

Esegui l'upgrade

bm-system e altri job bloccati

Versioni: 1.13.1

Sintomi:bm-system e altri job che eseguono il playbook Ansible sono bloccati su gathering facts.

Soluzione alternativa:inserisci il nome del nodo bloccato ed esegui multipath -ll | grep failed e multipath -ll | grep #. Se il risultato non è vuoto,segui i runbook FILE R0020 e FILE R0021.

IP gestione non raggiungibile

Versioni: 1.13.1, 1.13.3, 1.13.4, 1.13.5

Sintomi: durante un upgrade l'IP di gestione di un server non è raggiungibile, in particolare dopo un cambio.

Con Rocky Linux, quando vengono aggiunte route statiche, l'IP di destinazione utilizzato per raggiungere le route statiche deve essere raggiungibile prima dell'aggiunta delle route statiche. Se lo switch si riavvia dopo un upgrade del sistema operativo, l'IP di gestione potrebbe essere temporaneamente irraggiungibile.

Soluzione alternativa: stabilisci una connessione SSH al server utilizzando l'indirizzo IP dei dati e riavvia il servizio di rete per ricreare le route statiche mancanti:

systemctl restart NetworkManager.service

Il numero di versione di storagecluster non viene visualizzato

Versioni: 1.13.3

Sintomi: dopo un upgrade, il CR StorageCluster non mostra alcun valore per il campo di stato StorageVersion.

Controlla la versione:

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

Segui i passaggi della soluzione alternativa se il campo della versione è vuoto.

Soluzione: riavvia il deployment di file-storage-backend-controller:

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

Il server Bare Metal è bloccato nello stato di provisioning

Versioni: 1.13.1

Sintomi:

Il server bare metal è bloccato nello stato "provisioning" per molto tempo durante la creazione di un'organizzazione.

Soluzione:

È possibile che la configurazione del BIOS del server sia stata modificata in modo che il server utilizzi la scheda di rete errata per l'avvio PXE.

Segui questi passaggi per disabilitare l'avvio di rete della NIC del piano dati.

  • Accesso richiesto:
    • Devi disporre dell'accesso alle credenziali di amministratore BMC dei server bloccati.
    • Segui IAM-R0005 per ottenere il ruolo ClusterRole hardware-admin nel cluster root-admin per 1 ora.
    • Segui IAM-R0004 per generare il file KUBECONFIG per il cluster root-admin.

  1. Imposta il nome del server bloccato.

    export SERVER_NAME=

  2. Imposta l'IP e le credenziali del BMC del server.

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

  3. Identifica lo slot PCIe della scheda di rete del piano dati sul server.

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    Ad esempio, l'output seguente indica che la scheda di rete è installata nello slot 3.

    ["s3p1","s3p2"]

    Imposta la variabile PCIEslot:

    export DATA_NIC_SLOT=3

  4. Verifica che l'avvio di rete non sia disattivato.

    curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

    Se il risultato è "NetworkBoot", devi disattivarlo esplicitamente.

  5. Utilizza BMC per disattivare la funzione di avvio di rete sulla scheda di rete del piano dati.

    Sostituisci "Slot3" nel seguente comando con il numero di slot effettivo.

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

    e poi riavvia la macchina.

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

    Il server impiega 10-15 minuti per riattivarsi e riprende automaticamente il processo di provisioning.

L'upgrade dell'object storage mostra un errore durante il controllo postflight o preflight

Versioni: 1.13.1

Sintomi: i controlli preflight o postflight non riescono a essere completati e viene visualizzato un errore. Controlla i log:

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

L'errore potrebbe avere il seguente aspetto:

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

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

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

Soluzione:

  1. Se l'errore si verifica durante i controlli post-volo e tutti gli altri controlli vengono completati senza errori, ignora i controlli post-volo. Quando il riavvio dell'upgrade, devi saltare anche i controlli preliminari utilizzando kubeconfig di amministrazione root:

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

    Ad esempio, se l'errore si verifica in org-1, il comando ha il seguente aspetto:

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

  2. Se l'errore si verifica durante i controlli preflight e tutti gli altri controlli preflight vengono completati senza errori, salta i controlli preflight:

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

    Ad esempio, se l'errore si verifica in org-1, il comando ha il seguente aspetto:

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

Potresti dover applicare questa soluzione alternativa più di una volta se non viene applicata.

Rollback degli upgrade di Helm

Versioni: 1.13.3

Sintomi: un problema di upgrade di Helm comporta una serie di rollback, senza riuscire a trovare un Certificate e un ServiceEntry. Potresti visualizzare un messaggio simile a questo:

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

Soluzione alternativa: segui i passaggi nel runbook OCLCM-R0122.

Upgrade del nodo o ABM bloccato perché il pod dhcp-tftp-core-server non è stato svuotato

Versioni: 1.13.3, 1.14.4, 1.14.5

Sintomi: l'upgrade del nodo potrebbe bloccarsi. Nello stato della macchina bare metal il pod dhcp-tftp-core-server non viene svuotato. Potresti visualizzare un messaggio simile a questo:

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

Soluzione alternativa: elimina forzatamente il pod dhcp-tftp-core-server-* per continuare. Il comando ha il seguente aspetto:

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

OrganizationUpgrade è bloccato nella fase di upgrade dei nodi

Versioni: 1.13.3

Sintomi: OrganizationUpgrade è bloccato nella fase di upgrade del nodo. Potresti visualizzare un messaggio simile a questo:

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

Soluzione:

  1. Controlla la presenza di upgradetaskrequest CR nel cluster radice ka get upgradetaskrequest -n gpc-system. Controlla se il nodo è ancora in stato di esecuzione. Assicurati che sia bloccato nell'attività per il servizio.

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

  2. Crea manualmente nodeupgrade CR per ogni rivendicazione del node pool:

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

  3. Crea un nodeupgrade CR per ogni rivendicazione del node pool. I dettagli dell'annotazione upgrade.private.gdc.goog/target-release-version devono essere ottenuti dal nome CRMD del sistema operativo della destinazione:

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

  4. Utilizza la versione da qui nelle annotazioni upgrade.private.gdc.goog/target-release-version:

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

  5. Applica il seguente yaml per ogni NodePoolClaim:

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

  6. Una volta completati gli upgrade dei nodi per i nodi del cluster di servizio, aggiorna lo stato della CR UpgradeTaskRequest su True, in modo che l'upgrade dell'organizzazione proceda alla fase successiva:

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

  7. L'upgrade dell'organizzazione dovrebbe ora procedere alla fase successiva e lo stato del servizio o del nodo sarà completato:

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

Il kernel non riesce a creare un container

Versioni: 1.13.3

Sintomi: il kernel non riesce ad allocare memoria cgroup, causando errori nella creazione di nuovi container.

Potresti visualizzare un messaggio simile a questo:

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

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

e il nodo utilizza un numero molto elevato di cgroup:

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

Soluzione:

Prova una delle seguenti soluzioni:

  1. Esegui echo 3 > /proc/sys/vm/drop_caches sul nodo e riavvia kubelet.
  2. Se il metodo precedente non funziona, prova a riavviare il nodo.

Errore di connettività intermittente al VIP del cluster esterno

Versioni: 1.13.3

Sintomi: errori di connessione intermittenti al VIP virtuale del cluster esterno, ad esempio il VIP del control plane, il VIP istio-gateway o il VIP Harbor, comportano un errore dial tcp :: connect: no route to host.

Per diagnosticare il problema:

  1. Connettiti al cluster di amministrazione principale. Questa soluzione alternativa presuppone che tu stia eseguendo il debug per gli indirizzi IP in un cluster di amministrazione principale. Se esegui il debug dei problemi di connettività con altri cluster Kubernetes come i cluster di amministrazione dell'organizzazione o di sistema dell'organizzazione, modifica il valore di KUBECONFIG con il percorso kubeconfig del cluster corretto.

  2. Esistono due categorie note di indirizzi IP che possono essere interessati. Verifica se il Border Gateway Protocol (BGP) pubblicizza gli indirizzi IP agli switch top-of-rack (ToR):

    • Se l'IP è un indirizzo IP del control plane Kubernetes come 192.0.2.100, utilizza questo comando per ottenere le informazioni di configurazione:

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      Sostituisci KUBECONFIG con il percorso del file kubeconfig nel cluster di amministrazione principale.

    • Per alcune configurazioni, la risorsa personalizzata BGPAdvertisedRoute definisce quali route nell'indirizzo IP vengono pubblicizzate ad altre reti o sistemi utilizzando BGP. Se l'indirizzo IP viene pubblicizzato dalla risorsa personalizzata BGPAdvertisedRoute, utilizza questo comando per ottenere le informazioni di configurazione:

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      Sostituisci TARGET_IP_ADDRESS con l'indirizzo IP che presenta problemi di connettività intermittenti.

  3. Controlla lo stato delle risorse personalizzate BGPSession. Un BGPSessionrappresenta una singola sessione di peering BGP stabilita tra il tuo cluster Kubernetes e un peer BGP esterno. Ispeziona i log dei pod BGPAdvertiser e verifica che tutte le risorse BGPSession si trovino nello stato Established:

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

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

    L'output di un pod BGPAdvertiser integro contiene il seguente snippet:

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

  4. Verifica la stabilità della connessione. Crea ed esegui uno script per verificare se la connettività è intermittente o instabile:

    1. Crea lo script:

      #!/bin/bash

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

    2. Esegui lo script:

      ./script.sh TARGET_IP_ADDRESS:PORT

      Sostituisci PORT con il numero di porta che presenta problemi.

      Se la connessione presenta problemi, visualizzerai un output simile al seguente:

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

  5. L'output precedente conferma il problema. Controlla le route sugli switch TOR per verificare se la configurazione degli switch TOR è la causa del problema.

    Supponendo che il traffico venga eliminato per un indirizzo IP di esempio 192.0.2.201 e che venga pubblicizzato dalla risorsa BGPAdvertisedRoute, esamina gli hop nella risorsa BGPAdvertisedRoute per identificare i potenziali punti di errore:

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

  6. Guarda gli indirizzi IP nel campo nextHops. Per ogni indirizzo IP, trova il nome del server. Ad esempio:

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. Questo output mostra che gli hop successivi sono verso i server nel rack aa e nel rack ab. Accedi agli switch TOR nei rack aa e ab e confronta le route in entrambi i rack:

    show ip route 192.0.2.201 vrf root-external-vrf

  8. Se le route sono diverse tra gli switch TOR nei due rack, si verifica il problema che la soluzione alternativa mitiga. L'output per questo problema è simile al seguente:

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

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

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

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

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

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

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

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

    In questo output, le route nel rack aa si trovano nello stato previsto e mostrano tre hop successivi elencati rispetto al prefisso. Tuttavia, nel rack ab, il prefisso ha solo due hop successivi. Quando il traffico destinato al prefisso viene sottoposto ad hashing al rack ab il nodo corrispondente all'hop successivo mancante non riceve mai il traffico e la rete riscontra il problema di connettività.

Segui la soluzione alternativa per mitigare il problema.

Soluzione:

Questa soluzione alternativa aiuta a risolvere i problemi di connettività intermittente a determinati indirizzi IP all'interno dei cluster Kubernetes.

Per risolvere questo problema, devi applicare diverse modifiche alla configurazione della sessione BGP tra gli switch di aggregazione. Gli switch di aggregazione (AGG) aggregano il traffico da più switch TOR. Segui questi passaggi per aggiornare tutte le configurazioni necessarie:

  1. Un file di configurazione denominato switchstaticconfig rappresenta le configurazioni statiche su un singolo switch. Scarica il file switchstaticconfig per entrambi gli switch AGG:

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

  2. Ottieni il numero di sistema autonomo (ASN) dell'ambiente:

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    Questo output mostra un valore ASN di 65030. Devi utilizzare il valore ASN restituito qui nei passaggi successivi.

  3. Un indirizzo IP di loopback su uno switch AGG funge da indirizzo stabile e sempre attivo per la gestione, il routing e la risoluzione dei problemi, anche se altre connessioni di rete non sono attive. Recupera gli indirizzi IP di loopback di ciascuno degli switch AGG:

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    L'output è simile al seguente:

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  4. Aggiorna staticswitchconfig per l'interruttore za-ab-aggsw01 AGG. Aggiungi questo snippet alla sezione config:

    spec:
  config: |

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

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    Sostituisci quanto segue:

    • ASN: il valore ASN del passaggio precedente. In questo esempio, questo valore è 65030.
    • LOOPBACK_ADDRESS: Questo è l'indirizzo IP di loopback dello switch AGG za-ac-aggsw01. In questo esempio, il valore è 192.0.2.2.

  5. Applica lo stesso aggiornamento all'altro interruttore AGG, za-ac-aggsw01. Devi fornire l'indirizzo di loopback corretto. L'indirizzo IP di loopback è diverso per ogni switch:

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. Crea ed esegui lo stesso script utilizzato per diagnosticare il problema in questo passaggio per verificare che la correzione sia riuscita. L'output non mostra messaggi di errore.

Durante l'upgrade viene visualizzato l'errore Incorrect version of Trident

Versioni: 1.13.3, 1.13.4, 1.13.5

Sintomi: quando esegui l'upgrade da versioni precedenti alla 1.13.3, ontap mostra l'errore Incorrect version of Trident. Potresti visualizzare un messaggio simile a questo:

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

Soluzione:

  1. Aggiorna releasemetadata della versione a cui stai eseguendo l'upgrade:

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

    L'output potrebbe essere simile al seguente:

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

  2. Scegli la versione a cui eseguire l'upgrade, come indicato nell'esempio seguente:

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. Aggiorna tridentVersion nella sezione fileBlockStorage di .yaml alla versione menzionata nell'errore. Se il messaggio di errore era simile a questo:

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    Modifica tridentVersion in v23.10.0-gke.5 in releasemetadata.yaml.

    Ad esempio, se il valore originale era: infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6,

    Modificalo con il seguente valore:

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5.

  4. Applica le modifiche:

    kubectl apply -f releasemetadata.yaml

  5. Applica di nuovo l'upgrade dello spazio di archiviazione di ontap.

Impossibile pianificare i pod

Versioni: 1.13.3. 1.13.4, 1.13.5

Sintomi: durante il provisioning del cluster utente, la pianificazione di alcuni pod non va a buon fine. Potresti visualizzare un messaggio simile a questo:

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

Soluzione:

Aumenta le dimensioni del pool di nodi del control plane del cluster utente:

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

L'upgrade non riesce nel sottocomponente iac-zoneselection-global

Versioni: 1.13.1

Sintomi: durante un upgrade alla versione 1.13.3, si verifica un errore nel sottocomponente iac-zoneselection-global. Potresti visualizzare un messaggio simile a questo:

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

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

Soluzione:

L'upgrade alla versione 1.13.3 corregge l'errore.

Upgrade check jobs has deadline exceeded

Versioni: 1.12.x, 1.13.x

Sintomi:durante l'upgrade dell'organizzazione, il controllo dell'upgrade mostra lo stato False con il motivo DeadlineExceeded. Potresti visualizzare un messaggio simile a questo:

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

Soluzione:

  1. Elimina i job di controllo dell'upgrade non riuscito corrispondenti ai controlli dell'upgrade non riuscito.
  2. Attendi che vengano ricreati i job di controllo dell'upgrade.
  3. Esamina i log dei job ricreati e risolvi i problemi.

Il componente aggiuntivo meta-monitoring non funziona perché la posizione di strongswan si trova in una directory di runtime diversa

Versioni: 1.12.x, 1.13.x

Sintomi: durante l'upgrade alla versione 1.13.4 o 1.13.5, il componente aggiuntivo meta-monitoring non funziona:

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

Controlla il componente aggiuntivo:

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

Il messaggio della condizione potrebbe avere il seguente aspetto:

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

Soluzione:

  1. Assicurati che le sessioni BGP nel cluster di sistema dell'organizzazione non vadano a buon fine, ad esempio:

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

  2. Assicurati che i pod ang-node siano bloccati su ContainerCreating, ad esempio:

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

    Viene visualizzato il seguente errore:

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

  3. Applica la seguente modifica a ang-overrides AddonConfiguration nel cluster di amministrazione dell'organizzazione:

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

    Modifica quanto segue:

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

    a quanto segue:

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

  4. Dopo circa un minuto, verifica che i pod ang-node si trovino ora nello stato Running:

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

  5. Assicurati che le sessioni BGP nel cluster di sistema dell'organizzazione siano ora in esecuzione.

  6. Il componente aggiuntivo meta-monitoring passerà alla fase successiva.

L'upgrade dell'organizzazione principale è bloccato a causa dell'errore del job di firma

Versioni: 1.13.3, 1.13.4

Sintomi: durante l'upgrade dalla versione 1.13.3 alla 1.13.4, potresti visualizzare un messaggio come questo:

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

Soluzione:

  1. Disattiva il controllo preflight:

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

  2. Elimina il job artifact-signature-verification-*** non riuscito.

  3. Attendi il completamento dell'upgrade della radice.

  4. (Facoltativo) Attiva il controllo pre-volo se l'ambiente è stato aggiornato alla versione 1.13.4 o successive.

Una volta che il controller raggiunge la versione 1.13.4, gli upgrade non dovrebbero presentare questo problema.

L'upgrade dell'organizzazione tenant non riesce nella fase di controllo preflight con ErrImagePull

Versioni: 1.13.3

Sintomi: l'upgrade dell'organizzazione tenant non riesce nella fase di controllo preflight con ErrImagePull per il pod di convalida del pacchetto. Potresti visualizzare un messaggio simile a questo:

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

I pod mostrano un errore ImagePullBackOff:

kubectl describe po -n package-validation-system POD_NAME

Viene visualizzato un errore pull immagine, ad esempio il seguente:

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

Soluzione:

Salta i controlli preliminari:

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

Impossibile trovare serviceaccount durante l'upgrade dell'organizzazione principale

Versioni: 1.13.8, 1.13.9

Sintomi: durante l'upgrade alla versione 1.13.8, il deployment di addon per i controlli dell'accesso basato sui ruoli non riesce se sono stati eseguiti upgrade precedenti e se esistono già componenti aggiuntivi. I sintomi possono trovarsi in una delle seguenti fasi:

  1. controlli pre-volo o post-volo
  2. qualsiasi fase che preveda un'attività di upgrade e il messaggio indica che il job è in esecuzione anche se l'attività è bloccata. Il messaggio status.conditions indica che il job è in esecuzione da molto tempo, il che indica la presenza di un problema.

Per verificare se si è verificato un errore di controllo preliminare dell'upgrade, controlla lo stato dell'oggetto OrganizationUpgrade corrispondente per l'organizzazione che esegue l'upgrade:

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

  1. Se il job non riesce a superare il controllo preliminare, potrebbe essere visualizzato un errore come questo o un messaggio UpgradeCheckRBACDeploymentInProgress:

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

  2. Se il job non va a buon fine nella fase AnthosBareMetal (ABM) in cui è in esecuzione il job dell'attività, viene visualizzato il seguente output:

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

  3. Se l'errore si verifica nei controlli, la upgradecheckrequest CR non va a buon fine:

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

    L'output potrebbe essere simile a questo esempio:

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

  4. Se l'errore si verifica nelle attività, upgradetaskrequests CR non va a buon fine:

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

    L'output potrebbe essere simile a questo esempio:

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

  5. Se l'errore indica un errore RBAC durante la ricerca di un account di servizio, verifica se è stato implementato un componente aggiuntivo precedente:

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

Soluzione temporanea:

  1. Controlla se è stato implementato un componente aggiuntivo precedente:

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

  2. Recupera i componenti aggiuntivi precedenti esistenti per lo stesso componente, upgrade-task-mz per l'attività:

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

  3. Elimina questo componente aggiuntivo:

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

  4. Dopo aver eliminato il componente aggiuntivo, elimina anche il upgradetaskrequest o il upgradecheckrequest corrispondente. Verrà ricreato.

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. Continua a monitorare il nuovo upgradetaskrequest, upgradecheckrequest o il job corrispondente direttamente.

L'upgrade non riesce su shared-service-cluster upgrade

Versioni: 1.13.3

Sintomi: l'upgrade di Anthos Bare Metal è bloccato con una o più macchine bare metal. Tutte le altre macchine bare metal sono state aggiornate correttamente o l'upgrade non è ancora iniziato. Una macchina bare metal è in modalità di manutenzione, ma mostra comunque la versione precedente sia per i campi ABM VERSION corrente che DESIRED ABM VERSION.

Segui Anthos bare metal per ottenere lo stato e i dettagli di baremetalmachine per il cluster:

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

Output previsto:

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

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

Output previsto:

true

Soluzione temporanea:

  1. Esci dalla modalità di manutenzione della macchina di inventario:

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

  2. Attendi che la macchina dell'inventario esca dalla modalità di manutenzione. L'operazione potrebbe richiedere fino a 10 minuti.

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

  3. Monitora le macchine bare metal per verificare che la macchina visualizzi l'aggiornamento della versione ABM selezionata.

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

Installazione del componente aggiuntivo system-dashboards non riuscita

Versioni: 1.13.5

Sintomi: l'upgrade dalla versione 1.12.4 alla 1.13.5 non riesce durante l'upgrade del componente aggiuntivo per il componente aggiuntivo system-dashboards:

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

Soluzione alternativa:segui i passaggi nel runbook OCLCM-R0122.

NodeUpgradeTask CR è bloccato alla condizione NodeOSInPlaceUpgradePostProcessingCompleted

Versioni: 1.13.5

Sintomi: durante l'upgrade alla versione 1.13.5, NodeUpgradeTask CR è bloccato alla condizione NodeOSInPlaceUpgradePostProcessingCompleted.

Controlla se il job os-artifact-collector corrispondente è stato completato. Se il job è bloccato per molte ore, viene visualizzato il seguente messaggio:

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

Soluzione temporanea:

  1. Elimina il job o il pod per forzare il nuovo tentativo.

La distribuzione delle immagini non riesce durante un upgrade

Versioni: 1.13.5

Sintomi: la distribuzione delle immagini non riesce durante un upgrade dalla versione 1.12.4 alla 1.13.x:

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

Controlla i pod obj-proxy in gpc-system dell'organizzazione per verificare che la verifica del certificato non sia riuscita:

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

Soluzione temporanea:

  1. Riavvia il pod obj-proxy utilizzando KUBECONFIG dell'organizzazione su cui si verifica l'errore:

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

  2. Controlla i log di obj-proxy: 

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

    L'output previsto è il seguente:

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

  3. Controlla i log dei pod disponibili, ad esempio: 

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. I job di distribuzione delle immagini devono essere completati dopo l'applicazione della soluzione alternativa.

Il nodo non funziona durante l'upgrade del cluster utente

Versioni: 1.13.3

Sintomi: un job in esecuzione su un nodo non riesce durante l'upgrade del cluster utente e viene visualizzato un messaggio di errore simile al seguente:

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

  1. Accedi al nodo e controlla se la partizione è piena:

    df -h /

    L'output potrebbe essere simile a questo esempio:

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

  2. Controlla se /etc/kubernetes/tmp sta utilizzando una grande quantità di spazio: du -s /etc/kubernetes/tmp. Questo problema si verifica quando Kubernetes esegue più backup del solito.

Soluzione temporanea:

  1. Cancella tutti i backup su rm -f /etc/kubernetes/tmp/*:

    df -h /

    L'output potrebbe essere simile a questo esempio:

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

Ricreazione e errore dell'upgrade dell'amministratore root per i controlli preflight

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

Sintomo: l'upgrade dell'organizzazione principale non va a buon fine per il controllo preflight, ad esempio:

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

Il cluster root-admin e kubeapiserver per root-admin sono stati aggiornati alla versione ABM scelta.

Esempio:

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

Output di esempio per kubectl describe kubeapiserver root-admin -n root:

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

Output di esempio per kubectl get cluster root-admin -n root:

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

Soluzione temporanea

Applica l'omissione del controllo preliminare per continuare l'upgrade:

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

Gli spazi dei nomi platform-obs-obs-system o platform-obs rimangono bloccati nello stato di terminazione

Versioni: 1.13.5

Sintomi: il deployment dei componenti aggiuntivi non riesce durante l'upgrade o il bootstrap e viene visualizzato un messaggio di errore simile a questo: 

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

Viene visualizzato il seguente output:

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

Se gli stati DEPLOYED o READY mostrano false o sono vuoti, controlla gli addon corrispondenti per l'errore, ad esempio:

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

Viene visualizzato il seguente output:

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

Il componente aggiuntivo è bloccato perché tenta di creare contenuti negli spazi dei nomi in fase di eliminazione. Questo blocco persiste perché anche l'eliminazione dello spazio dei nomi è bloccata.

Soluzione temporanea:

  1. Prima di iniziare un upgrade, annota i progetti per evitare l'eliminazione:

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

    Viene visualizzato il seguente output:

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

    Se l'ambiente presenta già i sintomi descritti in precedenza, segui la seguente soluzione alternativa:

  2. L'eliminazione dello spazio dei nomi è bloccata a causa di risorse con finalizzatori. Per procedere con l'eliminazione, rimuovi i finalizzatori utilizzando lo script fornito: 

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

  3. Attendi l'eliminazione della risorsa. Dopo aver eseguito lo script, elimina le risorse e gli spazi dei nomi di terminazione. Potresti dover eseguire di nuovo lo script se lo spazio dei nomi è ancora bloccato nello stato di terminazione. Una volta terminato, lo spazio dei nomi verrà ricreato automaticamente. Verifica che gli spazi dei nomi siano ricreati e nello stato ATTIVO:

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    Viene visualizzato il seguente output:

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    Con gli spazi dei nomi attivi, i componenti aggiuntivi bloccati dovrebbero essere sottoposti a deployment entro pochi minuti. Verifica che gli stati DEPLOYED e READY siano ora impostati su true:

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

    Viene visualizzato il seguente output:

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

Cicli di arresto anomalo di UPORC nel cluster KIND durante il bootstrap

Versioni: 1.13.x

Sintomi: il deployment uporc-root-backend-controller nello spazio dei nomi uporc-system si blocca in loop nel cluster KIND.

Soluzione temporanea:

  1. Controlla se gli oggetti ComponentGroupReleaseMetadata e ReleaseMetadata corrispondono:

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    Se gli oggetti corrispondono, non è necessaria alcuna soluzione alternativa.

  2. Se gli oggetti non corrispondono, contatta il team UPORC per ricevere assistenza, in quanto potrebbe trattarsi di altri problemi sottostanti.

Impossibile eseguire l'upgrade del nodo

Versioni: 1.13.6

Sintomi: l'upgrade del nodo non è riuscito alle ore NodeOSInPlaceUpgradeCompleted.

  1. Controlla i log dei job ospolicy os-upgrade.
  2. Se il log include un errore che suggerisce che il file di configurazione è danneggiato, inserisci la macchina del nodo e controlla manualmente il contenuto del file per verificare se è danneggiato. L'errore nel log potrebbe menzionare il codice di errore configparser.DuplicateOptionError e il file /etc/yum.repos.d/gdch.repo.

Soluzione: solo se hai confermato che il file è danneggiato, elimina manualmente il file /etc/yum.repos.d/gdch.repo danneggiato sul nodo danneggiato.

Il job Ansible per l'upgrade rigenera automaticamente il file nell'ambito del playbook Ansible.

### NodeUpgradeTask CR è bloccato alla condizione NodeOSInPlaceUpgradePostProcessingCompleted

Versioni: 1.13.5

Sintomi: durante l'upgrade alla versione 1.13.5, NodeUpgradeTask CR è bloccato alla condizione NodeOSInPlaceUpgradePostProcessingCompleted.

Controlla se il job os-artifact-collector corrispondente è stato completato. Se il job è bloccato per molte ore, viene visualizzato il seguente messaggio:

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

Soluzione temporanea:

  1. Elimina il job o il pod per forzare il nuovo tentativo.

NodeUpgradeTask CR è bloccato alla condizione NodeBIOSFirmwareUpgradeCompleted

Versioni: 1.13.5

Sintomi: durante l'upgrade alla versione 1.13.5, NodeUpgradeTask CR è bloccato alla condizione NodeBIOSFirmwareUpgradeCompleted.

Controlla se la condizione NodeBIOSFirmwareUpgradeCompleted corrispondente è bloccata e viene visualizzata la seguente condizione:

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

Soluzione temporanea:

  1. Nel CR NodeUpgrade, modifica manualmente "U30 v3.20 (05/29/2024)" in "U30 v3.20 (05/27/2024)".

L'upgrade del cluster è bloccato perché un nodo non riesce a entrare in modalità di manutenzione

Versioni: 1.13.5, 1.13.6, 1.13.7

Sintomi: l'upgrade del cluster (cluster di amministrazione dell'organizzazione, di sistema o utente) è bloccato perché un nodo non riesce a entrare in modalità di manutenzione.

Il cluster mostra MaintenanceMode impostato su true, ma Status è bloccato su false durante l'esecuzione di:

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

Viene visualizzato il seguente output:

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

Soluzione temporanea:

Imposta KUBECONFIG sul file kubeconfig del cluster contenente il nodo da svuotare. Il cluster può essere il cluster utente o un cluster di servizi condivisi.

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

Timeout persistente durante il root iniziale organizationupgrade

Versioni: 1.13.3

Sintomi: se l'annotazione per ignorare il periodo di manutenzione è presente durante l'upgrade di un'organizzazione, la CR organizationupgrade viene patchata ripetutamente, reimpostando lo stato di avanzamento.

Soluzione:

Metti in pausa il sottocomponente rm-org e fare lo scale down le repliche rm-org-backend-controller.

  1. Se l'alias non è dichiarato, esegui:

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

  2. Metti in pausa il sottocomponente e fare lo scale down del deployment per rm-org:

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

  3. Al termine dell'upgrade del cluster, ridimensiona il deployment:

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

La riconciliazione del sottocomponente obj-syslog-server non riesce nell'organizzazione principale

Versioni: 1.13.3, 1.13.4, 1.13.5, 1.13.6

Sintomi:durante l'upgrade alla versione 1.13.x, il sottocomponente obj-syslog-server risulta essere nello stato ReconciliationError:

root        obj-syslog-server     ReconciliationError

con una condizione simile a:

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

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

Potresti notare che il pod syslog-server-abcdefg-wxyz si trova nello stato CrashLoopBackOff con il seguente errore:

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

Soluzione temporanea:

Per riportare il sottocomponente a uno stato integro, rimuovi l'volumeMounts non necessario.

  1. Modifica il deployment attuale:

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

    kubectl edit deployments syslog-server -n istio-system

  2. Rimuovi i volumeMounts che non sono necessari in spec.containers.volumeMounts. Rimuovi i seguenti percorsi di montaggio:

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

  3. Applica le modifiche e il sottocomponente tornerà a ReconciliationCompleted dopo l'applicazione delle modifiche.

Upgrade di ABM o dei nodi bloccato su maintenanceMode false

Versioni: 1.13.4

Sintomi: il nodo è bloccato all'upgrade del cluster AnthosBaremetal e non entra in modalità di manutenzione.

Controlla baremetalmachine su un nodo del cluster di servizio, ad esempio:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

Soluzione:

Riavvia anthos-cluster-operator per propagare BMM.MaintenanceMode:

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

L'upgrade non riesce per il componente aggiuntivo atat-webhooks per l'organizzazione tenant

Versioni: 1.13.5

Sintomi: l'upgrade del componente aggiuntivo atat-webhooks non viene recuperato:

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

Potresti visualizzare un messaggio simile a questo:

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

Controlla i pod per atat-webhooks-parameters-*****: 

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

Potresti visualizzare un errore simile al seguente:

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

Soluzione:

  1. Crea una copia del portfolio attuale:

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. Aggiorna portfolio-org-1 Pop End Date a una data futura:

    kubectl delete portfolios -n atat-system portfolio-org-1

    Se questo comando smette di rispondere, elimina la condizione .Metadata.Finalizers dal portafoglio attivo prima di eliminare il portafoglio. La condizione potrebbe avere questo aspetto:

    │     portfolio.finalizers.atat.config.google.com

  3. Applica di nuovo il file YAML copiato:

    kubectl apply -f portfolio-org-1

  4. Controlla di nuovo le date per assicurarti che sia i portafogli sia il configmap siano aggiornati.

  5. Se il job non viene recuperato, elimina il job atat-webhooks-parameters non riuscito e verrà recuperato. Attendi il completamento:

    kubectl delete jobs -n org-1 atat-webhooks-parameters

Il controllo post-volo o dell'upgrade non riesce a causa di errori DeadlineExceeded o BackoffLimitExceeded.

Versioni: 1.13.8

Sintomi:

Durante l'upgrade dalla versione 1.13.7 alla 1.13.8, i controlli post-volo sono ancora in stato di attesa e mostrano errori DeadlineExceeded o BackoffLimitExceeded.

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

Soluzione:

Identifica il punto in cui i job non riescono:

  1. Controlla se i job non riescono a essere eseguiti durante i controlli preflight o postflight:

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. Controlla se i job non riescono durante l'upgrade:

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. Elimina i job:

    kubectl delete jobs -n gpc-system CHECK_NAME

I controlli di upgrade includono risultati non pertinenti al livello di controllo

Versioni: 1.13.x

Sintomi:

I controlli di upgrade dell'organizzazione potrebbero non riuscire a causa di risultati inclusi in modo errato da altri livelli. Ad esempio, i controlli dell'organizzazione principale potrebbero mostrare i risultati dell'organizzazione tenant, mentre i controlli dell'organizzazione tenant potrebbero mostrare i risultati del cluster di utenti.

Log di errore di esempio per i controlli dell'organizzazione root:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

Soluzione:

Salta completamente i controlli preflight o postflight con:

Preflight:

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

Postflight:

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

Vertex AI

Le API preaddestrate mostrano lo stato Enabling nell'interfaccia utente

Versioni: 1.13.1

Sintomi: MonitoringTarget mostra lo stato Not Ready durante la creazione dei cluster utente, facendo sì che le API preaddestrate mostrino continuamente lo stato Enabling nell'interfaccia utente.

Soluzione:

  1. Apri il menu del browser Chrome (icona con tre puntini).
  2. Fai clic su Altri strumenti > Strumenti per sviluppatori per aprire la console.
  3. Fai clic sulla scheda Rete nella console.
  4. Trova le richieste ai-service-status.
  5. Fai clic sulla scheda Risposta in una richiesta ai-service-status per visualizzare i contenuti della richiesta.
  6. Verifica che tutto sia pronto, ad eccezione dei componenti MonitoringTarget e LoggingTarget.

La funzione API preaddestrata streaming_recognize di Speech-to-Text non funziona

Versioni: 1.13.3

Sintomi: quando si chiama la funzione API preaddestrata streaming_recognize di Speech-to-Text, un problema con la libreria client causa un messaggio di errore 400 simile al seguente:

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

Soluzione alternativa: utilizza il seguente script Python per consentire il funzionamento della funzione streaming_recognize:

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

Sostituisci quanto segue:

Lo script Python introduce le seguenti differenze tra le funzioni streaming_recognize e recognize per consentire il funzionamento della soluzione alternativa per streaming_recognize:

  • Riga 4: un'ulteriore istruzione import rispetto allo script recognize (from google.cloud.speech_v1p1beta1.services.speech import client).
  • Riga 18: il cliente viene restituito da client.SpeechClient() anziché da speech_v1p1beta1.SpeechClient().

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

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

Sintomi: durante gli upgrade, il cluster Translation DB viene ricreato, il che causa l'obsolescenza e la mancata sincronizzazione del secret secret-store del cluster di sistema ODS. Per questo motivo, l'inizializzazione del pod e del servizio frontend di traduzione non va a buon fine.

Soluzione:

Elimina il secret nel cluster di sistema:

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

Sostituisci SYSTEM_CLUSTER_KUBECONFIG con il percorso del file kubeconfig nel cluster di sistema.

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

Il polling dello stato del job non è supportato per l'API batchTranslateDocument

Versioni: 1.13.3

Sintomi: Vertex AI non supporta le operazioni GET e LIST nelle API del servizio di traduzione. La chiamata all'API Translation BatchTranslateDocument restituisce un'operazione a lunga esecuzione simile al seguente esempio:

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

Questo problema è dovuto a una limitazione dell'APIP (autorizzazione) che impedisce di chiamare direttamente l'endpoint. Gli endpoint non supportano il polling dello stato del job e non puoi eseguire operazioni GET sull'operazione a lunga esecuzione a causa della limitazione APIP.

Soluzione alternativa: in qualità di operatore dell'applicazione (AO), controlla regolarmente lo stato del job nella cartella s3_destination e cerca un file di output del job appena creato. Se la cartella contiene il file di output, il job è stato completato correttamente.

Le richieste batchTranslateDocument potrebbero causare problemi di prestazioni

Versioni: 1.13.3

Sintomi: il servizio di traduzione di documenti batch legge uno o più file di input utente#39;utente e scrive i file di output temporanei di elaborazione e traduzione in StorageGRID. Viene creato un nuovo client curl per ogni azione di lettura/scrittura perché il riutilizzo del client non va a buon fine.

I client S3 curl nel file binario sono a utilizzo singolo, il che significa che ogni client può eseguire una sola azione di lettura/scrittura sui bucket StorageGRID. Pertanto, viene creato un nuovo client curl ogni volta che viene stabilita la comunicazione con il client StorageGRID dal server batchTranslateDocument per leggere e scrivere file nei bucket.

Tuttavia, questa soluzione non è ottimale per i clienti curl. Potrebbe causare i seguenti problemi:

  • Degrado delle prestazioni: aumento della latenza e riduzione del throughput
  • Esaurimento delle risorse: overhead di memoria e CPU ed esaurimento dei socket
  • Sovraccarico del server: limitazione di frequenza o limitazione

La console GDC mostra uno stato incoerente dopo l'abilitazione delle API preaddestrate

Versioni: 1.13.3

Sintomi: quando abiliti per la prima volta le API preaddestrate, la console GDC potrebbe mostrare uno stato incoerente dopo alcuni minuti per il servizio abilitato. La console GDC riporta lo stato di Enabling a Disabled e mostra di nuovo il pulsante Attiva nell'interfaccia utente anche se il servizio è in fase di attivazione.

Soluzione alternativa: lo stato diventa coerente dopo alcuni minuti e il servizio riflette lo stato corretto.

Per verificare lo stato del servizio, apri la scheda Rete nella console del browser e controlla lo stato della richiesta ai-service-status. Il payload deve mostrare che l'operatore L2 è abilitato.

Le richieste di traduzione con più di 250 caratteri causano l'arresto anomalo dei pod translation-prediction-server

Versioni: 1.13.3

Sintomi: quando invii richieste di traduzione con circa 250 caratteri o più (incluse le richieste di traduzione di documenti), i pod translation-prediction-0 o translation-prediction-1 potrebbero arrestarsi in modo anomalo, richiedendo il ricaricamento del modello. Il ricaricamento del modello avviene automaticamente e questo processo può richiedere circa 30 minuti.

Questo problema è dovuto a una limitazione dei contenitori di traduzione.

Soluzione alternativa: dividi le richieste di traduzione in modo che non superino i 250 caratteri. Un intervallo compreso tra 200 e 250 caratteri è sicuro per tutte le lingue. Se una richiesta lunga causa l'arresto anomalo dei pod, non è necessaria alcuna altra azione per risolvere il problema.

GPUAllocation per il cluster di servizi condivisi non è configurato correttamente

Versioni: 1.13.3

Sintomi: i workload Vertex AI non possono essere pianificati a causa della mancanza di risorse GPU sufficienti. Ad esempio, se non riesci a visualizzare o attivare gli endpoint di servizio Vertex AI, il problema potrebbe essere causato dalla mancanza di risorse GPU sufficienti.

Questo problema di assegnazione delle risorse può essere causato da alcune risorse GPUAllocation situate all'interno del cluster di servizi condivisi a cui manca la seguente annotazione:

processed: "true"

Soluzione:

  1. Segui IAM-R0004 per generare il file kubeconfig per g-ORG_NAME-shared-service-cluster.

  2. Elenca tutte le allocazioni di GPU nel cluster di servizi che non hanno l'annotazione processed: "true":

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

    L'output è simile al seguente:

    zi-ad-bm08

  3. Apri la risorsa GPUAllocation non allocata in un editor:

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. Modifica l'allocazione delle GPU in base al numero totale di allocazioni delle GPU presenti nel cluster di servizio:

    • Se è presente una sola risorsa personalizzata di allocazione GPU, aggiungi l'annotazione processed: "true" e modifica la relativa specifica in modo che sia simile alla seguente:

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • Se sono presenti due risorse personalizzate di allocazione GPU, individua quella senza l'annotazione processed: "true", aggiungila e modifica la relativa specifica in modo che sia simile alla seguente:processed: "true"

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • Se sono presenti quattro risorse personalizzate di allocazione GPU, individua quella senza l'annotazione processed: "true", aggiungila e modifica la relativa specifica in modo che sia simile alla seguente:processed: "true"

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. Salva le modifiche alla risorsa personalizzata GPUAllocation e verifica che il relativo stato di allocazione sia aggiornato a true:

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    L'output è simile al seguente:

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

Durante l'upgrade dalla versione 1.9.x alla 1.13.3, il controller OCLCM mostra errori

Versioni: 1.13.3

Sintomi: durante l'upgrade dalla versione 1.9.x alla 1.13.3, il controller Operable Component Lifecycle Management (OCLCM) per i sottocomponenti di Vertex AI potrebbe mostrare errori. Questo problema è causato da un errore nel job del componente aggiuntivo ai_platform. Gli errori che ricevi durante l'upgrade indicano che OCLCM non può trasferire la proprietà di questi componenti di Vertex AI.

Di seguito sono riportati i componenti di Vertex AI interessati nel cluster di amministrazione dell'organizzazione:

Nome Spazio dei nomi
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role N/D
aip-l2operator-role N/D
aip-web-plugin-role N/D
aip-l1operator-rolebinding N/D
aip-l2operator-rolebinding N/D
aip-web-plugin-rolebinding N/D
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

Soluzione alternativa: per risolvere il problema, devi rimuovere manualmente i componenti Vertex AI interessati dal cluster amministrativo dell'organizzazione. Poi, la nuova versione di Vertex AI basata su OCLCM li reinstalla.

Rimuovi manualmente i componenti Vertex AI interessati nel cluster di amministrazione dell'organizzazione:

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

Sostituisci quanto segue:

  • ORG_ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig nel cluster di amministrazione dell'organizzazione.
  • NAMESPACE: lo spazio dei nomi del componente Vertex AI che vuoi rimuovere. Se il componente non ha uno spazio dei nomi, rimuovi -n NAMESPACE dal comando.
  • COMPONENT_NAME: il nome del componente Vertex AI che vuoi rimuovere.

Il seguente esempio mostra come rimuovere il componente aip-l1operator-deployment esistente nello spazio dei nomi ai-system sul cluster di amministrazione dell'organizzazione:

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

Le richieste di traduzione potrebbero generare il codice di errore RESOURCE_EXHAUSTED

Versioni: 1.13.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.13.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: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

    Sostituisci ORG_ADMIN_NAMESPACE con lo spazio dei nomi del cluster di amministrazione dell'organizzazione.

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

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

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

Servizi preaddestrati di Vertex AI non disponibili

Versioni: 1.13.7, 1.13.9

Sintomi: i servizi Vertex AI OCR e Translation non vengono avviati a causa di problemi di pianificazione di Kubernetes. Nei log potrebbe essere visualizzato un avviso come questo:

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

Soluzione alternativa: aggiungi altri nodi di lavoro al pool predefinito ed elimina i pod sui nodi GPU in modo che i workload AI possano essere pianificati.

Macchine virtuali

L'importazione di immagini BYO non riesce per le immagini qcow2 e raw

Versioni: 1.13.1, 1.13.3

Sintomi:quando le immagini VM locali vengono importate utilizzando l'interfaccia a riga di comando gdcloud compute images import, lo stato dell'importazione è bloccato su WaitingForTranslationVM o ImportJobNotCreated. Questo perché il disco temporaneo creato per la traduzione o l'importazione utilizza le stesse dimensioni dell'immagine qcow2/raw, ma LUKS aggiunge un overhead di alcuni MiB che causa l'errore del provisioning del disco.

Soluzione temporanea:

Crea manualmente un nuovo VirtualMachineImageImport con lo stesso nome dell'immagine, ma con un spec.minimumDiskSize più grande.

Ad esempio, se questo era il comando utilizzato per importare l'immagine:

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

Se l'VirtualMachineImageImport originale creato automaticamente dalla CLI ha minimumDiskSize come X Gi, creane uno nuovo con X+1 Gi. Il valore si basa sulle dimensioni dell'immagine importata. Nel caso di qcow2, si tratta della dimensione virtuale, ad esempio 20 Gi devono essere sostituiti con 21 Gi.

Sostituisci i valori dei segnaposto in base a come è stata chiamata la CLI.

  1. Trova il VirtualMachineImageImport:

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    Se l'oggetto non è presente, attiva di nuovo il comando gdcloud compute images import .... Quando l'output della console passa da Uploading image to .. a Image import has started for ..., premi Ctrl+C in modo che l'immagine locale venga caricata nell'object storage e VirtualMachineImageImport venga conservato come riferimento per crearne uno nuovo.

  2. Crea un nuovo VirtualMachineImageImport con un minimumDiskSize più grande:

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

Il provisioning di un disco da un'immagine non va a buon fine

Versioni: 1.13.1, 1.13.3

Sintomi: quando viene eseguito il provisioning di un disco da un'immagine personalizzata, minimumDiskSize potrebbe essere troppo vicino alla dimensione virtuale, causando l'errore del provisioning del disco. Il disco VM è in stato di attesa, ma non viene mai sottoposto al provisioning.

Soluzione alternativa: crea manualmente un nuovo disco con un spec.minimumDiskSize più grande.

Il plug-in del dispositivo NVIDIA DaemonSet non funziona quando un cluster ha GPU

Versioni: 1.13.3

Sintomi: il plug-in del dispositivo NVIDIA DaemonSet non funziona e viene visualizzato il messaggio driver rpc error sui nodi del cluster con GPU:

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

Sostituisci KUBECONFIG con il percorso del file kubeconfig nel cluster.

Ottieni un output simile al seguente esempio:

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

Questo problema causa la mancata disponibilità delle GPU per le macchine virtuali (VM) e i pod. Le implicazioni si basano sui seguenti tipi di cluster:

  • Cluster di sistema: la risorsa personalizzata GPUAllocation non viene creata per quel nodo bare metal e le GPU in quel nodo non sono configurate in modalità VM per l'utilizzo da parte del servizio e del cluster utente. Per risolvere il problema, consulta la soluzione alternativa per il cluster di sistema.
  • Cluster di servizi o utente: la risorsa personalizzata GPUAllocation non viene creata per il nodo VM e le GPU in quel nodo non sono utilizzabili dai pod sul cluster. Per risolvere il problema, consulta la soluzione alternativa per il servizio o il cluster di utenti.

Soluzione alternativa per il cluster di sistema:

Per risolvere il problema nel cluster di sistema, segui questi passaggi:

  1. Imposta la variabile di ambiente KUBECONFIG con il percorso del file kubeconfig nel cluster di sistema. Per maggiori dettagli, consulta il runbook IAM-R0004.

  2. Identifica il nodo che presenta il problema:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    L'output deve stampare il nome del nodo e l'indirizzo IP del nodo Kubernetes.

    Se sono presenti più nodi, esegui i passaggi su tutti. In questo caso, l'output è simile al seguente esempio:

    Node:                 yy-ab-bm04/172.20.128.26

  3. Imposta la variabile di ambiente NODE_NAME con il nome del nodo, ad esempio:

    export NODE_NAME=yy-ab-bm04

  4. Stabilisci una connessione SSH con il nodo. Per maggiori dettagli, consulta il runbook PLATAUTH-G0001.

  5. Verifica che il nodo abbia GPU:

    nvidia-smi -L

    L'output deve stampare le GPU nel nodo come nell'esempio seguente:

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. Attiva la modalità di persistenza sulle GPU:

    nvidia-smi -pm 1

    Questa azione garantisce che i driver NVIDIA vengano sempre caricati in modo che il plug-in del dispositivo non scada.

    L'output deve essere simile all'esempio seguente:

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. Esci dalla sessione SSH:

    exit

  8. Verifica che il plug-in del dispositivo sia in esecuzione eseguendo una query su DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Verifica che la risorsa personalizzata GPUAllocation sia creata e configurata in modalità VM:

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    L'output deve essere simile all'esempio seguente:

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

Soluzione alternativa per il servizio o il cluster utente:

Per risolvere il problema nel servizio o nel cluster, segui questi passaggi:

  1. Imposta la variabile di ambiente KUBECONFIG con il percorso del file kubeconfig nel servizio o nel cluster utente. Per maggiori dettagli, consulta il runbook IAM-R0004.

  2. Identifica il nodo che presenta il problema:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    L'output deve stampare il nome del nodo e l'indirizzo IP del nodo Kubernetes.

    Se sono presenti più nodi, esegui i passaggi su tutti. In questo caso, l'output è simile al seguente esempio:

    Node:                 vm-948fa7f4/172.20.128.21

  3. Imposta la variabile di ambiente NODE_NAME con il nome del nodo, ad esempio:

    export NODE_NAME=vm-948fa7f4

  4. Stabilisci una connessione SSH con il nodo. Per maggiori dettagli, consulta il runbook PLATAUTH-G0001.

  5. Verifica che il nodo abbia GPU:

    nvidia-smi -L

    L'output deve stampare le GPU nel nodo come nell'esempio seguente:

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. Attiva la modalità di persistenza sulle GPU:

    nvidia-smi -pm 1

    Questa azione garantisce che i driver NVIDIA vengano sempre caricati in modo che il plug-in del dispositivo non scada.

    L'output deve essere simile all'esempio seguente:

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. Esci dalla sessione SSH:

    exit

  8. Verifica che il plug-in del dispositivo sia in esecuzione eseguendo una query su DaemonSet:

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. Verifica che la risorsa personalizzata GPUAllocation sia creata e configurata in modalità VM:

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    L'output deve essere simile all'esempio seguente:

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

VM del cluster di sistema non pronta

Versioni: 1.13.3

Sintomi: la VM del cluster di sistema non è pronta. Potresti visualizzare un messaggio simile a questo:

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

Soluzione:

  1. Trova VirtualMachineInstance ed eliminalo.
  2. Riavvia una nuova VM.

Spazio di lavoro temporaneo dei report sul volume di dati non trovato

Versioni: 1.13.3, 1.13.4

Sintomi: durante la creazione di un disco VM, il volume di dati viene segnalato come riuscito:

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

Tuttavia, un pod di importazione, ad esempio importer-gdc-vm-disk-vm-ce34b8ea-disk, va in crash in loop con un messaggio come questo:

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

Soluzione: elimina il pod dell'importatore dopo aver verificato che lo stato del volume di dati sia Succeeded.

Le VM nei progetti con nomi superiori a 45 caratteri rimangono in stato arrestato

Versioni: 1.13.5

Sintomi: quando crei una VM, questa rimane nello stato Stopped se il nome del progetto contiene più di 45 caratteri.

Soluzione alternativa: crea un progetto con un nome non superiore a 45 caratteri.

Allocazione GPU mancante nel cluster di servizio

Versioni: 1.13.5

Sintomi: GPUAllocation non è presente nel cluster di servizi condivisi di gpu-org. Quando ottieni le allocazioni della GPU, potresti visualizzare un messaggio:

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

L'output ha il seguente aspetto:

No resources found

Soluzione:

  1. Aggiungi un taint al nodo GPU:

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. Rimuovi il taint per consentire la pianificazione del pod virt-launcher della VM.

Impossibile pianificare la VM worker del cluster di servizi condivisi

Versioni: 1.13.6

Sintomi: una VM worker Kubernetes non è stata pianificata a causa di risorse CPU insufficienti sul nodo designato, nonostante le GPU disponibili. Potresti visualizzare un evento come questo:

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

Soluzione:

  1. Arresta manualmente le VM non GPU per liberare risorse CPU.
  2. Dopo la pianificazione della VM in attesa, avvia le VM non GPU.