Problemi noti di Google Distributed Cloud con air gap 1.12.x
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il cluster di archiviazione per il backup del volume utilizza il server DNS esterno
anziché il forwarder, il che impedisce al backup del volume di risolvere gli endpoint di archiviazione di oggetti a livello di organizzazione. Nella versione 1.12, il traffico di backup richiede
nuovi percorsi per ogni organizzazione.
Soluzione temporanea:
I proprietari dell'organizzazione devono aggiornare il cluster di archiviazione per attivare la risoluzione DNS a livello di organizzazione e per creare una route dalle interfacce logiche di replica (LIF) agli endpoint di archiviazione degli oggetti in ogni organizzazione. Copia e incolla i seguenti comandi dal bootstrapper.
Il recupero del gateway in entrata dell'amministratore dell'organizzazione dai nodi ONTAP non riesce perché
non esiste una route dalla subnet di backup ai control plane dell'organizzazione.
Soluzione temporanea:
I proprietari dell'organizzazione devono aggiornare il cluster di archiviazione per attivare la risoluzione DNS a livello di organizzazione e per creare una route dalle interfacce logiche di replica (LIF) agli endpoint di archiviazione degli oggetti in ogni organizzazione. Copia e incolla i seguenti comandi dal bootstrapper.
Se il repository di backup non presenta alcun tipo di stato di errore, ma
viene generato un avviso, la metrica di avviso per il repository potrebbe essere
generata per errore. Si tratta di un problema noto della versione 1.12.0, risolto
nella versione 1.12.4. La causa di questo problema è che il repository di backup
tenta periodicamente di connettersi all'object storage come controllo di integrità
e passa a uno stato non integro se la connessione non riesce. Tuttavia, se il
repository di backup viene ripristinato, la metrica che indica il suo stato di integrità non
tornerà correttamente, facendo sì che l'avviso rimanga bloccato in uno
stato di attivazione indefinito.
Per risolvere il problema, puoi eliminare e ricreare manualmente il repository di backup per reimpostare la metrica di integrità. Segui i passaggi del
runbook BACK-R0003 per ricreare il repository di backup.
Messaggio di errore: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found
Il sottocomponente bil-storage-system-cluster non viene riconciliato a causa di job obsoleti. billing-storage-system-init-job-628 e billing-storage-system-init-job-629 rimangono dopo il completamento.
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 temporanea:
Controlla il PVC per un deletionTimestamp. Se non è presente alcun deletionTimestamp (migrazione dei pod), segui questi passaggi:
Controlla VolumeAttachment per PVC per identificare a cosa è attualmente collegato il volume.
Isola Nodes nel cluster che non corrispondono a questo valore.
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:
Controlla VolumeAttachment per PVC per identificare a cosa è attualmente collegato il volume.
Su Node, restituisci i contenuti del file di monitoraggio:
cat/var/lib/trident/tracking/PVC_NAME.json
Verifica che il dispositivo LUKS trovato nel campo devicePath dell'output del file di monitoraggio sia effettivamente chiuso. Questo percorso non deve esistere a questo punto:
statDEVICE_PATH
Verifica se il numero di serie è attualmente mappato a un dispositivo multipath.
Copia il valore nel campo iscsiLunSerial del file di monitoraggio.
Converti questo valore nel valore esadecimale previsto:
echo'iISCSILUNSERIAL>'|xxd-l12-ps
Con questo nuovo valore, verifica se la voce multipath esiste ancora:
multipath-ll|grepSERIAL_HEX
Se non esiste, elimina il file di monitoraggio.
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-llMULTIPATH_SERIAL
Quindi, esegui i seguenti comandi, con l'ultimo eseguito in modo univoco per ogni dispositivo a blocchi:
kubectl--kubeconfig=ADMIN_KUBECONFIGlogs-pkube-apiserver-{first_node_name}-nkube-system|grep"etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"
L'output mostra un risultato non vuoto.
Soluzione temporanea:
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.
Riavvia etcd nel secondo nodo per ripristinare
etcd nel primo nodo dal ciclo di arresti anomali.
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.
Dopo aver completato la configurazione dell'esportazione in un sistema SIEM esterno, l'input SIEM non è incluso nella pipeline di elaborazione Fluent Bit e i log del server API Kubernetes non sono presenti in questo SIEM.
Quando esegui l'upgrade dalla versione 1.12.2 alla 1.12.4, se un nodo viene rimosso e poi aggiunto di nuovo, il processo machine-init per quel nodo potrebbe non riuscire.
Questo errore si verifica perché il traffico di rete dal nodo riaggiunto ai servizi essenziali del control plane viene negato dal criterio ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes.
Questo errore è evidenziato dai messaggi di stato in questo output di esempio:
Per risolvere il problema, procedi nel seguente modo:
Per il cluster di amministrazione principale:
Recupera i CIDR da CIDRClaim/org-external-cidr -n root (in particolare dal campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Esegui questo comando nel cluster di amministrazione principale:
Aggiungi questi CIDR a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, in particolare al campo .spec.ingress.fromCIDR. Applica questa modifica nel cluster amministratore principale con il comando:
Per il cluster di amministrazione dell'organizzazione:
Recupera i CIDR per l'organizzazione (ad es. org-1) da CIDRClaim/org-external-cidr -n org-1 (in particolare il campo .status.ipv4AllocationStatus.allocatedCidrBlocks). Questo comando viene eseguito sul cluster di amministrazione principale per ottenere i CIDR per "org-1":
Aggiungi questi CIDR a ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes, in particolare al campo .spec.ingress.fromCIDR. Applica questa modifica nel rispettivo cluster di amministrazione dell'organizzazione con il comando:
Su un nodo bare metal del cluster di sistema, non è possibile terminare due container anetd. Dopo aver interrotto forzatamente il processo, riavviato kubelet e containerd, il pod anetd viene ricreato, ma tutti i container sono bloccati in podInit e containerd segnala il messaggio di errore:
In questo modo, l'interfaccia di rete del container (CNI) non viene avviata e la pianificazione degli altri pod viene interrotta.
Soluzione temporanea:
Esegui queste mitigazioni per evitare questo stato del nodo:
Non pianificare più di 10 PVC alla volta su un singolo nodo. Attendi che vengano montati prima di programmarne altri. Questo era più evidente quando si tentava di creare VM.
Aggiorna il file /etc/lvm/lvm.conf su ogni nodo in modo che includa la riga: filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] nel blocco devices{}
Se il nodo entra in uno stato in cui mostra timeout per i collegamenti e i montaggi dei volumi o non è in grado di eliminare un volume, controlla il numero di processi vgs in attesa sul nodo per verificare se il nodo si trova in questo stato particolarmente grave. Il modo più affidabile per correggere un nodo in questo stato è riavviarlo.
Esiste un'altra modalità di errore che potrebbe verificarsi. Questa modalità di errore presenta la seguente firma nel tentativo di montaggio: mount(2) system call failed: No space left on device. Probabilmente è dovuto alla propagazione del montaggio sul nodo. Verifica questa condizione eseguendo cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c. Se uno di questi mostra un valore maggiore di uno, elimina il pod che lo utilizza e dovrebbe essere attivato lo smontaggio. Se non riesci, smonta manualmente il percorso. Se il problema persiste, esegui un riavvio.
In alcuni scenari, a causa di condizioni di competizione, Google Distributed Cloud (GDC) air-gapped
non riesce a creare le risorse personalizzate Kubernetes ACL switch necessarie
durante il bootstrapping iniziale di Distributed Cloud.
Quando viene eseguito il provisioning di Server durante la creazione di un cluster,
è possibile che il server venga contrassegnato come sottoposto a provisioning, ma manchi
la condizione Provision-Ready. Di conseguenza, il
NodePool non può utilizzare questo server. Un esempio di messaggio di evento
di errore in NodePool potrebbe essere il seguente:
SERVER_NAME=ROOT_ADMIN_KUBECONFIG=ILO_IP=$(kubectlgetservers${SERVER_NAME}-ngpc-system--template={{.spec.bmc.ip}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG})SECRET_NAME=$(kubectlgetsecrets-ogo-template='{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}'-ngpc-system--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|grepbmc|grep${SERVER_NAME})ILO_USER=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.username}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)ILO_PASS=$(kubectlgetsecrets${SECRET_NAME}-ngpc-system--template={{.data.password}}--kubeconfig=${ROOT_ADMIN_KUBECONFIG}|base64-d)# Perform iLO Resetcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"https://${ILO_IP}/redfish/v1/Managers/1/Actions/Manager.Reset--data'{"ResetType":"ForceRestart"}'-XPOST|jq
# Perform server power cycle, start with power off target servercurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/json"-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"ForceOff"}'|jq.
# Verify target server powered off successfullycurl-kqs-u${ILO_USER}:${ILO_PASS}https://${ILO_IP}/redfish/v1/Systems/1|jq'.PowerState'# Power server backcurl-k-u${ILO_USER}:${ILO_PASS}-H"Content-Type: application/jsonls "-H"OData-Version: 4.0"-XPOSThttps://${ILO_IP}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset--data'{"ResetType":"On"}'|jq.
In rari casi, la procedura di ripristino di iLO precedente potrebbe non risolvere completamente
il problema, quindi è necessario eseguire il nuovo provisioning del server. Per le procedure dettagliate, consulta i runbook OS-P0002
e OS-P0003.
Non riesci a trovare nxos.10.3.1.bin, ma trovi qualcosa di simile
come nxos64-cs.10.3.1.F.bin nella directory bootflash dello
switch.
Soluzione temporanea:
Sulla macchina bootstrapper, completa i seguenti passaggi. Devi
completare questi passaggi durante il processo di preinstallazione. Se sono presenti
più cartelle /tmp/preinstall-bootstrap-, applica le modifiche
alla cartella corrente utilizzata dal processo di preinstallazione controllando i
log del processo di preinstallazione. Se devi riavviare il comando di preinstallazione, questa azione crea anche una nuova cartella /tmp/preinstall-bootstrap-.
Vai alla cartella /tmp/preinstall-bootstrap-RANDOM_NUMBER.
All'interno della cartella, trova il file poap.py.
Rimuovi completamente la riga con il checksum MD5 in questo file in modo che
head -n 4 poap.py abbia questo aspetto:
Questo problema è causato dalla pulizia impropria del job di upgrade. Non è necessario alcun intervento e il job può essere lasciato nello stato di loop di arresto anomalo.
Questo è un problema per i server che non mantengono l'ora sincronizzata. La
configurazione non è applicata correttamente e deve essere modificata in uno spazio dei nomi
diverso per essere applicata correttamente.
Soluzione temporanea:
Applica i passaggi seguenti a tutti i cluster:
Elenca le policy del sistema operativo esistenti:
kubectlgetospolicies-nntp-system
L'output mostra admin-ntp-policy o worker-ntp-policy.
In base al nome del criterio, salvalo in un file .yaml:
Modifica il file cambiando metadata.namespace da
ntp-system a gpc-system e rimuovendo
status: line e tutto ciò che segue.
Applica il file modificato al cluster:
kubectlapply-fntp-ospolicy.yaml
Attendi qualche minuto affinché il controller applichi il criterio del sistema operativo.
Stabilisci una connessione SSH a uno dei nodi a cui si applica OSPolicy
ed esegui cat /etc/chrony.conf. L'output mostra
un messaggio all'inizio del file che indica che è gestito da Ansible e
che i server nist.time.gov o ntp.pool sono stati rimossi
dalla configurazione.
Il processo di backup e ripristino della VM non può essere avviato dagli utenti a causa di impostazioni di controllo dell'accesso basato sui ruoli (RBAC) e dello schema improprie nel gestore VM.
I nomi dei piani di backup delle VM non possono contenere più di 63 caratteri.
Ad esempio, potresti visualizzare questo messaggio di errore:
I nomi dei piani di backup delle VM sono una concatenazione del nome VirtualMachineBackupPlanTemplate, del tipo di risorsa (vm o vm-disk) e del nome della risorsa. Questa stringa concatenata deve contenere meno di 63 caratteri.
Per farlo, mantieni brevi i nomi di queste risorse quando le crei. Per informazioni dettagliate sulla creazione di queste risorse, consulta Crea e avvia un'istanza VM e Crea un piano di backup per le VM.
I carichi di lavoro del servizio di database vengono sottoposti a provisioning e configurati in progetti separati nel cluster di sistema Distributed Cloud. Sebbene i progetti vengano utilizzati per applicare i limiti amministrativi in Distributed Cloud, non influiscono su come e dove viene eseguito un workload. Pertanto, questi carichi di lavoro potrebbero condividere l'infrastruttura di calcolo sottostante con altre istanze di database e vari sistemi del control plane.
Soluzione temporanea:
Per i carichi di lavoro del database che richiedono un isolamento aggiuntivo, gli utenti possono richiedere la creazione di un pool di nodi sul cluster di sistema. Questo pool di nodi, a cui è necessario fare riferimento durante la creazione del progetto, garantisce che i carichi di lavoro del database vengano sottoposti a provisioning ed eseguiti su un'infrastruttura di calcolo dedicata. La configurazione del pool di nodi isolato deve essere completata dall'operatore dell'infrastruttura.
Per AlloyDB Omni versione 15.2.1, quando vengono creati più cluster AlloyDB Omni sullo stesso nodo, l'ultimo cluster creato rimane bloccato in uno stato di riconciliazione. Recuperare i log di PostgreSQL con il comando
Durante l'implementazione del cliente, il nome utente dell'amministratore del file secret.yaml deve essere admin. Il file contiene invece TO-BE-FILLED dopo la prima creazione. Il nome utente admin deve essere utilizzato per inizializzare la prima configurazione sul firewall e sull'IP loopback admin\admin
Soluzione temporanea:
Verifica che TO-BE-FILLED non sia presente nelle seguenti credenziali firewall:
CELL_ID/CELL_ID-secret.yaml
CELL_ID-ab-rack/CELL_ID-secret.yaml
CELL_ID-ac-rack/CELL_ID-secret.yaml
Verifica che tutti gli account amministratore del firewall abbiano il nome utente admin.
Le policy firewall IDPS predefinite non supportano gli IP personalizzati dell'organizzazione per l'interconnessione Direct Connect (DX). Di conseguenza, la creazione dell'organizzazione con IP personalizzati non riesce perché gli IP personalizzati non possono connettersi a Harbor nell'amministratore principale.
Soluzione temporanea:
Per sbloccare il traffico, crea manualmente un SecurityPolicyRule per gli IP personalizzati dell'organizzazione e implementalo nei firewall IDPS. Segui i passaggi del runbook FW-G0002 per completare i seguenti passaggi:
1. Crea un SecurityPolicyRule in entrata nel sistema virtuale firewall root per consentire agli IP personalizzati dell'organizzazione di accedere a Harbor root
2. Crea un SecurityPolicyRule in entrata nel firewall dell'organizzazione vsys per consentire all'utente root di accedere all'API Server dell'organizzazione.
A causa di un problema noto esistente in CipherTrust Manager, le licenze di prova disattivate sono ancora rilevabili e potrebbero attivare falsi avvisi di scadenza.
Soluzione temporanea:
Consulta HSM-R0003 per verificare le licenze normali attive ed eliminare
le licenze di prova disattivate.
Il modulo di sicurezza hardware (HSM) si comporta in modo imprevisto durante l'eliminazione di un CTMKey KMS. Ad esempio, il servizio KMS potrebbe non avviarsi per l'organizzazione.
Soluzione temporanea:
Gli utenti possono eseguire la distruzione crittografica dei dati eliminando le chiavi KMS anziché la chiave radice KMS, che si manifesta come CTMKey.
La configurazione del webhook ServiceNow comporta la riconciliazione e il ripristino delle modifiche apportate all'oggetto ConfigMapmon-alertmanager-servicenow-webhook-backend e all'oggetto Secretmon-alertmanager-servicenow-webhook-backend nello spazio dei nomi mon-system da parte di Lifecycle Management (LCM).
Soluzione temporanea:
Metti in pausa il sottocomponente LCM per consentire l'applicazione delle modifiche senza che vengano ripristinate:
Ottieni i percorsi dei file kubeconfig dei cluster di amministrazione principale e di amministrazione dell'organizzazione. Salva i percorsi rispettivamente nelle variabili di ambiente ROOT_ADMIN_KUBECONFIG e ORG_ADMIN_KUBECONFIG.
Metti in pausa il sottocomponente LCM in uno dei seguenti cluster:
Metti in pausa il sottocomponente LCM nel cluster di amministrazione principale:
Alcune metriche dei cluster di utenti non vengono raccolte. Questo problema riguarda i cluster VM utente, ma non il cluster di sistema.
Puoi visualizzare i seguenti log dal server Prometheus:
prometheus-serverts=2024-02-21T16:07:42.300Zcaller=dedupe.go:112component=remotelevel=warnremote_name=cortex-remote-writeurl=http://cortex-tenant.mon-system.svc:9009/pushmsg="Failed to send batch, retrying"err="server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Puoi visualizzare i seguenti log dal tenant Cortex:
cortex-tenanttime="2024-02-23T18:03:44Z"level=errormsg="proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
Soluzione temporanea:
Per risolvere il problema, segui questi passaggi:
Ottieni il percorso del file kubeconfig del cluster. Salva il percorso nella variabile di ambiente KUBECONFIG.
Esegui il deployment di un servizio stub nei cluster VM utente:
Le metriche destinate all'istanza Grafana dell'operatore dell'infrastruttura possono trovarsi nell'istanza Grafana dell'amministratore della piattaforma e viceversa. Il problema è causato dalle richieste di bilanciamento del carico ASM tra i limiti del cluster, che hanno tenant predefiniti diversi.
Soluzione temporanea:
La soluzione alternativa richiede l'accesso all'origine private-cloud e la possibilità di implementare un aggiornamento dei componenti. Devi modificare la configurazione del mesh per limitare il servizio cortex-tenant alla ricezione del traffico solo dal cluster locale e implementare il componente ASM.
Apri il file manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml.
Introduci il campo serviceSettings nel campo meshConfig.
Il campo meshConfig inizialmente è simile al seguente esempio:
Durante l'upgrade dalla versione 1.11.0 alla 1.11.3, l'upgrade del nodo non riesce per NodeOSInPlaceUpgradeCompleted.
kalogs-ngpc-systemos-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn|grepGDCH-OS-ANSIBLE-CHECK-A50[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":true,
"msg":""},
"execution":{"success":false,
"msg":"errors found when simluating play execution on host: 10.3.20.9",
"tasks":[{"task":"os/upgrade : Copy GRUB file to BOOT location",
"error":"Source /boot/efi/EFI/ubuntu/grubx64.efi not found"}]}},
"diff":null
}
Soluzione temporanea:
Accedi alla macchina bare metal di cui viene eseguito l'upgrade. Controlla se fstab ha /boot/efi e se la directory è montata:
Esegui mount -a e controlla se la directory è montata:
# mount -a
root@mb-aa-bm04:~#ls/boot/efi/
EFI
Procedi con i controlli qui. Esegui questi comandi:
C
# Ensure all three cmds prints `Files are identical`if["$(sha256sum/boot/efi/EFI/ubuntu/shimx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/BOOTX64.EFI|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grubx64.efi|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/BOOT/grubx64.efi|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fiif["$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"=="$(sha256sum/boot/efi/EFI/ubuntu/grub.cfg|awk'{ print $1 }')"];thenecho"Files are identical.";elseecho"Files are different.";fi
Se non tutti i file sono identici, esegui questo comando sul computer e ripeti i controlli.
L'upgrade del cluster è bloccato da più di un'ora. Lo stato e le specifiche della modalità di manutenzione della macchina bare metal non corrispondono. Ad esempio, il comando:
Un'attività di riavvio della VM non riesce dopo la soluzione alternativa manuale per il pod os-policy. Viene visualizzato il seguente messaggio:
kologsos-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp-ngpc-system
playbook:server-reboot.yaml
{"custom_stats":{},
"global_custom_stats":{},
"plays":[{"play":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.694226Z"},
"id":"5251f140-5a01-5cce-6150-000000000006",
"name":"Run OS Upgrade Tasks"},
"tasks":[{"hosts":{"172.20.128.10":{"action":"setup",
"changed":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out",
"unreachable":true}},
"task":{"duration":{"end":"2024-01-12T03:50:52.749714Z",
"start":"2024-01-12T03:50:42.704562Z"},
"id":"5251f140-5a01-5cce-6150-00000000000b",
"name":"os/reboot : Gather OS distribution information"}}]}],
"stats":{"172.20.128.10":{"changed":0,
"failures":0,
"ignored":0,
"ok":0,
"rescued":0,
"skipped":0,
"unreachable":1}}}[GDCH-OS-ANSIBLE-CHECK]{"syntax":{"success":true,
"msg":""},
"apply":{"reachablity":{"success":false,
"msg":"Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"},
"execution":{"success":false,
"msg":"",
"tasks":null
}},
"diff":null
}[GDCH-OS-ANSIBLE-CHECK]
Error:reachabilityerr:Failedtoconnecttothehostviassh:ssh:connecttohost172.20.128.10port22:Connectiontimedout
Soluzione temporanea:
L'arresto e l'avvio della VM risolvono il problema. Segui le istruzioni riportate in Avviare e arrestare una VM.
Quando esegui l'upgrade di un'organizzazione principale dalla versione 1.11.1 alla 1.12.1, l'upgrade potrebbe non riuscire nella fase del componente aggiuntivo con errori di pull di Helm:
Durante un upgrade, il sottocomponente OPA Gatekeeper non viene installato nel cluster di sistema. Tuttavia, i vincoli vengono installati e l'webhook per applicarli viene installato.
Diversi pod in un cluster di sistema potrebbero bloccarsi nello stato TaintToleration:
Il pod con il nome del container istio-proxy non è pronto e ha lo stato ImagePullBackOff con l'evento Back-off pulling image "auto".
Soluzione temporanea:
Verifica che il webhook mutante istio-revision-tag-default sia presente nel cluster. In caso contrario, attendi circa 10 minuti per vedere se il sistema si ripristina automaticamente. In caso contrario, riassegna il problema.
Se il webhook di modifica è presente, elimina il pod problematico e verifica che venga ripristinato. .spec.containers[].image non deve essere auto, ma deve apparire come un'immagine reale simile alla seguente: gcr.io/gke-release/asm/proxyv2:<image version>.
Quando esegui l'upgrade dalla versione 1.11.1 alla 1.12.1, l'upgrade di ValidatingWebhookConfigurations, MutatingWebhookConfigurations e MonitoringRules implementati dal componente Log potrebbe non riuscire.
Soluzione temporanea:
Assicurati di avere kubectl e di poter accedere al runbook IAM-R0004 per ottenere KUBECONFIG per il cluster di amministrazione principale.
Elimina ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook dal cluster di amministrazione principale:
Elimina MonitoringRules audit-logs-alerts, audit-logs-sli-syslog-prober, audit-logs-sli-filelog-prober, audit-logs-sli-fluentbit-to-loki, audit-logs-sli-fluentbit-to-splunk, audit-logs-sli-fluentbit-backlog, audit-logs-sli-loki-ingester-failed-rate, audit-logs-sli-loki-io-up e audit-logs-sli-loki-pa-up da infra-obs namespace nel cluster di amministrazione principale:
A causa di un problema nel job log-infra-backend-preinstall,
i log di controllo e i log operativi Loki non sono installati e i log non vengono
raccolti.
Sintomi:
Potresti visualizzare un errore CrashLoopBackoff nel cluster di sistema:
Aumenta la memoria di ogni ingester, il numero di ingester o entrambi. Puoi farlo eseguendo il deployment di un SubcomponentOverride sul cluster di amministrazione dell'organizzazione, come mostrato nell'esempio seguente:
apiVersion:lcm.private.gdc.goog/v1
kind:SubcomponentOverride
metadata:
name:mon-cortex-ingester-override
namespace:org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory:"6Gi"# 6Gi is the default, increase to add more memory to each ingesterreplicas:4# 4 is the default, increase to create more ingester instances.subComponentRef:mon-cortex
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. Lo stato di Baremetalmachine mostra check_registry_mirror_reachability_pass errore di controllo.
kubectl--kubeconfig=${ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG}getbaremetalmachines-A-ojson|jq'.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
addOn:{}anthosBareMetal:
conditions:
-lastTransitionTime:"2024-09-12T12:10:55Z"message:'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin cluster: in-progress'observedGeneration:1reason:ABMUpgradeTimeout
status:Unknown
type:Succeeded
startTime:"2024-09-12T12:10:55Z"node:{}
2. I controlli di integrità mostrano l'errore netutil mancante.
{"lastHealthcheck":{"error":{"code":"500",
"reason":"[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"},
"lastCompletedTime":"2024-09-14T05:11:39Z",
"lastStatus":"Error",
"monitoredComponentVersion":"1.28.900-gke.112",
"version":"1.28.900-gke.112"},
"lastScheduledTime":"2024-09-14T05:26:00Z"}
Soluzione temporanea:
Elimina il job Kubernetes corrispondente al controllo di integrità non riuscito
Durante l'upgrade dalla versione 1.11.x alla 1.12.x, una VM potrebbe non essere pronta a causa di un numero eccessivo di pod, il che blocca lo svuotamento di un nodo bare metal.
Quando esegui l'upgrade dalla versione 1.11.x alla 1.12.1, NodeUpgrade contiene più versioni per lo stesso modello hardware, bloccando la verifica dell'upgrade del firmware.
Soluzione temporanea:
Segui questi passaggi per modificare il NodeUpgrade CR spec:
Se l'upgrade riguarda i server HPE Gen10 (GDC-4D), rimuovi il firmware del modello ilo6. In caso contrario, rimuovi il firmware del modello ilo5.
Sezione per conservare la voce con il redfishVersion più recente per ogni descrizione.
Ad esempio, se esistono entrambe le seguenti voci, mantieni solo quella con 2.98 Oct 10 2023:
Se l'interruttore è attivo, l'output restituisce "On".
Soluzione temporanea:
Rimuovi il blocco image dai server problematici e
attendi che i server tornino allo stato disponibile. Una volta disponibili, aggiungi di nuovo il blocco image.
Questo problema si verifica quando gli errori iLO vengono ignorati e la risposta HTTP viene letta anziché restituita immediatamente, il che comporta un dereferenziazione del puntatore nullo.
Durante un upgrade, i nodi dovrebbero essere in modalità di manutenzione. Se un nodo è in manutenzione, potresti non avere risorse sufficienti per pianificare harbor-db.
Quando esegui l'upgrade dalla versione 1.11.1 alla 1.12.1, l'eliminazione del bucket Cortex potrebbe non riuscire e viene visualizzato il seguente errore:
L'oggetto Prometheus StatefulSet è configurato in modo errato con la classe di archiviazione standard anziché standard-rwo. Questo problema causa l'avvio dell'oggetto StatefulSet di Anthos Prometheus dal componente di monitoraggio.
Il problema si verifica perché il riconciliatore ObservabilityPipeline imposta questo valore solo alla prima installazione e il riconciliatore ObsProjectInfra monitora le risorse personalizzate del cluster.
Soluzione temporanea:
Riavvia il deployment di fleet-admin-controller nel cluster di amministrazione dell'organizzazione per risolvere il problema.
Il sottocomponente mon-common deve eseguire il deployment di un oggetto Istio Telemetry nel cluster di amministrazione dell'organizzazione per impedire il logging di controllo di tutte le richieste per Cortex. Tuttavia, il file manifest non è incluso nel file di build.
Soluzione temporanea:
Segui questi passaggi per eseguire il deployment dell'oggetto Istio Telemetry nel cluster di amministrazione dell'organizzazione:
Crea un file YAML che definisca la risorsa personalizzata (CR) Istio Telemetry nello spazio dei nomi mon-system del cluster di amministrazione dell'organizzazione:
# Disable access logging from workloads internal to GDCH.# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion:telemetry.istio.io/v1alpha1
kind:Telemetry
metadata:
name:disable-audit-logging
namespace:mon-system
spec:
accessLogging:
-providers:
-name:otel
disabled:true
Applica il file manifest al cluster di amministrazione dell'organizzazione nello spazio dei nomi mon-system:
ConfigMap Prober viene compilato man mano che ogni probe viene registrato.
Segui il runbook MON-R2009 per disattivare l'avviso MON-A0001, Blackbox monitoring metrics pipeline down, perché questo avviso continuerà a essere attivato.
Quando esegui l'upgrade dalla versione 1.11.x alla 1.12.x, un pod di download dell'immagine dello switch potrebbe bloccarsi nello stato ErrImagePull con il seguente avviso:
Quando esegui l'upgrade dalla versione 1.11.x alla 1.12.1, il firewall host blocca il download dell'immagine dello switch a causa di una mancata corrispondenza delle interfacce utilizzate dal firewall host.
Soluzione temporanea:
Applica la seguente soluzione alternativa prima di eseguire l'upgrade, solo se esegui l'upgrade
dalla versione 1.11.x alla versione 1.12.x.
Aggiorna i cluster di amministrazione root e di amministrazione dell'organizzazione.
Recupera il nome e lo spazio dei nomi del pool di nodi per i nodi bare metal dell'amministratore root
e i nodi bare metal dell'amministratore dell'organizzazione. Per il cluster root-admin, utilizza il file kubeconfig root-admin. Il seguente comando elenca un inventario
delle macchine e filtra l'elenco in base alle macchine bare metal:
I campi NODEPOOL_NAME e NODEPOOL_NAMESPACE
vengono compilati con l'elenco di tutti i nodepool nel rispettivo cluster
quando viene eseguito il deployment del file YAML precedente.
Un esempio di file YAML per il cluster amministratore root con i nomi effettivi
del pool di nodi amministratore root e del pool di nodi amministratore dell'organizzazione potrebbe essere simile al seguente:
Gli switch di rete precaricati con una versione precedente alla 9.3.10 non riescono a eseguire il bootstrap perché la versione prevista dello switch è 10.3(4a).
Soluzione temporanea:
Esegui l'upgrade manuale del firmware dello switch dalla versione 9.3.5 alla 9.3.10 e poi dalla 9.3.10 alla 10.3.4a.
Le connessioni vengono interrotte sullo switch perché gli switch non hanno
la configurazione più recente a causa della scadenza dei certificati sullo switch.
conditions:
-lastTransitionTime:"2024-03-28T01:37:20Z"message:'Reconciliation error: E0100 - deploy: failed to install chart: release file-netapp-trident-backend failed, and has been uninstalled due to atomic being set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io "standard-rwo" is invalid: parameters: Forbidden: updates to parameters are forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io "standard-block" is invalid: parameters: Forbidden: updates to parameters are forbidden.'observedGeneration:1reason:ReconciliationError
status:"True"type:Reconciling
In questo esempio, due classi di archiviazione non sono riuscite: standard-rwo
e standard-block.
Soluzione temporanea:
Elimina StorageClasses che il job non è riuscito a creare,
come standard-rwo, standard-block, standard-rwo-non-luks e standard-block-non-luks.
Attiva la ricreazione di StorageClasses riavviando oclcm-backend-controller per il tuo cluster
(controller root-admin per i cluster root e di amministrazione dell'organizzazione, controller org-admin per i cluster di sistema e utente).
Per la versione 1.12.4, verifica che le classi di archiviazione installate abbiano l'annotazione disk.gdc.goog/luks-encrypted: impostata su true (escluse le classi di archiviazione non LUKS). Se l'annotazione non è impostata su true, ripeti i passaggi 1 e 2.
Riavvia il deployment di netapp-trident e netapp-trident DaemonSet nel cluster.
Verifica che il secret LUKS sia stato creato per le risorse PersistentVolumeClaim (PVC). Ogni PVC deve avere un secret nel formato g-luks-$pvc_name.
Verifica che il sottocomponente file-netapp-trident non presenti errori nello stato.
Dopo l'upgrade dell'organizzazione principale dalla versione 1.12.1 alla 1.12.x, la convalida post-upgrade non va a buon fine e viene visualizzato il seguente errore:
I node pool all'interno dei cluster utente che eseguono Kubernetes versione 1.27.x potrebbero non inizializzarsi, impedendo al cluster utente di gestire i carichi di lavoro dei container.
Soluzione temporanea:
Non creare un cluster utente con Kubernetes 1.27.x.
L'importazione dell'immagine della VM non riesce al passaggio di conversione dell'immagine se un'immagine di origine Ubuntu contiene origini APT predefinite in sources.list.
Soluzione temporanea:
Assicurati che la directory /var/lib/apt/lists/ sia vuota nell'immagine di origine.
VMRuntime sul cluster di destinazione (potrebbe essere il cluster di amministrazione o di sistema) ha lo stato VMRuntime.ready = false e network-controller-manager nello spazio dei nomi kube-system è in attesa
L'eliminazione del deployment network-controller-manager dovrebbe ricrearlo automaticamente con i certificati richiesti dall'operatore VMM. Il deployment dovrebbe passare allo stato Running e successivamente lo stato di VMRuntime dovrebbe cambiare in ready=true.
Il ciclo di arresti anomali dei pod di VM Importer e il volume di dati rimane bloccato nello stato di importazione per più di 90 minuti. Lo stato dei pod potrebbe
avere il seguente aspetto:
Il messaggio di errore potrebbe avere il seguente aspetto:
message:'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network" with kind Network: admission webhook "vnetwork.networking.gke.io" denied the request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher: Forbidden: Field is immutable'observedGeneration:2
Soluzione temporanea:
Se l'errore si verifica nella radice, nei passaggi successivi sostituisci KUBECONFIG con il file kubeconfig dell'amministratore root.
Se l'errore si verifica nell'organizzazione, nei passaggi successivi sostituisci KUBECONFIG con il file kubeconfig dell'amministratore dell'organizzazione.
Durante o dopo l'upgrade dalla versione 1.11.x alla 1.12.2, i job con il nome bm-system-add-ons-* potrebbero non riuscire e generare il seguente errore:
Il file potrebbe contenere il seguente messaggio nella sezione backendStatus.
message:'E0100 - deploy: failed to install chart: release file-observability-backend failed, and has been uninstalled due to atomic being set: deployments.apps "file-observability-backend-controller" not found'
Soluzione temporanea:
Controlla lo spazio dei nomi file-system per verificare che non termini con org-admin cluster:
Metti in pausa il sottocomponente file-observability finché il sottocomponente mon-admin non è attivo aggiungendo le seguenti annotazioni al sottocomponente:
Esegui ksctl system info get --url=https://HSM_MANAGEMENT_IP per verificare che tutte le versioni di HSM siano state aggiornate alla versione .Spec.TargetVersion di ctmclusterupgraderequest:
Aggiorna il campo Status.FirmwareVersion di ogni HSM alla versione di cui è stato eseguito l'upgrade ottenuta nel passaggio precedente:
Ad esempio:
kubectledit-statushsmHSM_NAME-ngpc-system
Aggiorna l'ultimo stato della condizione ctmclusterupgraderequest.status.conditions da False a True. Dopodiché, anche lo stato dell'ultima condizione hsmupgraderequest.status.conditions diventa true.
Durante un upgrade,
l'IP di gestione di un server non è raggiungibile, in particolare dopo un upgrade del sistema operativo dello switch.
Con Rocky Linux, quando vengono aggiunte route statiche, l'IP di destinazione utilizzato
per raggiungere le route statiche deve essere raggiungibile prima di aggiungere le route
statiche. Se lo switch si riavvia dopo un upgrade del sistema operativo, questo IP di gestione
potrebbe essere temporaneamente irraggiungibile.
Soluzione temporanea:
Stabilisci una connessione SSH al server utilizzando l'indirizzo IP dei dati
e riavvia il servizio di rete per ricreare le route statiche mancanti:
Quando esegui il deployment dell'organizzazione gdchservices manualmente, il sistema di gestione dei ticket non ha upstream integri, non vengono create VM e il pod midserver non è integro nel cluster gdchservices-system nello spazio dei nomi support.
Soluzione temporanea:
Crea una nuova risorsa personalizzata TicketingSystem con l'immagine VM corretta nel cluster gdchservices-admin:
Se l'errore si verifica durante i controlli post-volo e tutti gli altri controlli
vengono completati senza errori, salta i controlli post-volo. Quando
l'upgrade viene riavviato, devi saltare anche i controlli preliminari utilizzando
kubeconfig dell'amministratore root:
Se l'errore si verifica durante i controlli preflight e tutti gli altri controlli preflight
vengono completati senza errori, salta i controlli preflight:
Lo schema Portfolio è cambiato nella versione 1.12 di GDC. Il campo portfolioName è stato refactorizzato in portfolioID. Trova il file YAML contenente la risorsa personalizzata del portfolio menzionata nel messaggio di errore. Rinomina il campo portfolioName in portfolioID.
Di seguito sono riportati i potenziali motivi per cui non viene creato un job in esecuzione per un job di applicazione patch che ha completato solo i job di preflight:
L'errore NTP impedisce l'esecuzione di tutti gli altri job di patch.
Il nodo è in uno stato non integro.
L'agente OS Config non è in esecuzione.
L'agente OS Config non può comunicare con il servizio OS Config.
Si è verificato un problema con il servizio OS Config.
Soluzione temporanea:
Controlla la CR `NodeTargetPolicy` del nodo.
Cerca `.spec.osPolicies` del CR `NodeTargetPolicy` con `ref.name=admin-ntp-policy` e `type: Ready` con stato false:
# Enter the node InventoryMachine name.NAME=kubectlgetnodetargetpolicy-ngpc-system$NAME-ojsonpath="{.spec.osPolicies}"|jq
NodeUpgrade CR menziona version: rocky-86-xyz nelle sue specifiche, anche se il nodo di cui viene eseguito l'upgrade è Ubuntu.
Soluzione temporanea:
Non è necessaria una soluzione alternativa perché queste informazioni sono innocue. L'upgrade del nodo viene eseguito correttamente a una versione più recente di Ubuntu.
I job siem-*-preinstall nello spazio dei nomi root e org-1 nel cluster di amministrazione root non vengono eseguiti ripetutamente.
Soluzione temporanea:
È previsto che i job non vadano a buon fine quando il feature gate SIEMComponent è disattivato. Gli errori non indicano che il componente è guasto. La riconciliazione del componente SIEM può essere sospesa se il rumore è di disturbo, ma in genere è consigliabile lasciare il componente abilitato, se possibile. Se la riconciliazione dei componenti è in pausa, deve essere riattivata manualmente quando l'installazione del componente SIEM non sarà più limitata negli upgrade futuri.
Potrebbero esserci problemi con vgs, blkid e
gather_facts di Ansible che non rispondono. Questo problema riguarda
sia i sistemi operativi Rocky che Ubuntu.
Esegui questi passaggi se i nodi sono già stati aggiornati. La procedura per
aggiornare il file lvm.conf prevede i seguenti passaggi:
Recupera un elenco di tutti i nodi in modo che questa correzione possa essere applicata a tutti.
Crea un playbook Ansible e un file di criteri del sistema operativo.
Applica la correzione ai nodi.
Controlla se la correzione è stata applicata.
Prerequisiti:
Segui i passaggi descritti nel runbook IAM-R0004 per generare ROOTCONFIG
per il cluster di amministrazione principale e ORGCONFIG per il cluster di amministrazione dell'organizzazione.
Segui i passaggi del runbook IAM-R0005 per ottenere i seguenti ruoli dell'organizzazione.
Soluzione temporanea:
Identifica i InventoryMachines che corrispondono ai cluster:
Mantieni l'output separato. Correggi un cluster alla volta. L'output potrebbe
essere simile al seguente:
NAME
bm-2bca8e3f
bm-4caa4f4e
Crea un playbook e un file di criteri:
apiVersion:system.private.gdc.goog/v1alpha1
kind:AnsiblePlaybook
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
playbook:|-name:Addadevicefilterto/etc/lvm/lvm.conf
hosts:all
gather_facts:no
tasks:
# Change lvm.conf-name:Configurelvmforfilteringout"dm"and"sg"devices
ansible.builtin.lineinfile:
path:/etc/lvm/lvm.conf
insertafter:'^(\s+|)devices(\s+|)\{'line:' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'---
apiVersion:system.private.gdc.goog/v1alpha1
kind:OSPolicy
metadata:
name:lvm-conf-device-filter-node-update
namespace:gpc-system
spec:
interval:
period:1m
inventory:
# this is the inventory from step 1 above,# see the syntex belowpolicy:
installPlaybook:
name:lvm-conf-device-filter-node-update
La sezione dell'inventario precedente deve essere compilata come in questo esempio.
Aggiungi un paragrafo per ogni nodo trovato nel passaggio 1. Dovrai creare un cluster
alla volta, quindi compila la sezione dell'inventario con i nodi per un cluster.
Questo problema si verifica se l'ambiente è stato precedentemente implementato con la versione 1.11
e poi è stato eseguito l'upgrade alla versione 1.12. Quando crei un nuovo cluster o una nuova organizzazione in
una versione 1.12.x, viene selezionato Rocky OS anziché Ubuntu OS per
il provisioning dei nodi bare metal e delle macchine virtuali a causa della versione di Rocky OS
specificata nei CR ReleaseMetadata e
Userclustermetadata.
Soluzione temporanea:
Applica la seguente soluzione alternativa prima di creare una nuova organizzazione:
Controlla se sono presenti richieste di modifica OrganizationUpgrade non nello stato Succeeded: true:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')STATUS=$(kubectl--kubeconfig=KUBECONFIGgetorganizationupgrade${NAME}-n${NAMESPACE}-ojson|jq'.status.conditions[] | select(.type=="Succeeded") | .status')if[["$STATUS"!="True"]];thenecho"Not in Succeeded: true state, stop following operations"fidone
In questo caso, contatta il team tecnico prima di procedere
con i passaggi successivi.
Rimuovi tutti i CR OrganizationUpgrade esistenti per evitare
aggiornamenti accidentali del sistema operativo dei nodi:
foritemin$(kubectl--kubeconfig=KUBECONFIGgetOrganizationUpgrade-A-ocustom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace--no-headers);doNAME=$(echo$item|awk'{print $1}')NAMESPACE=$(echo$item|awk'{print $2}')echo"Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE"kubectl--kubeconfig=KUBECONFIGdeleteOrganizationUpgrade$NAME-n$NAMESPACEdone
Definisci la versione di GDC di destinazione per la creazione della nuova organizzazione. Deve essere presente un ReleaseMetadata corrispondente per questa versione di destinazione:
TARGET_RELEASE=
Identifica l'ultima versione di OSImageMetadata CR per il sistema operativo Ubuntu di destinazione nel cluster di amministrazione principale e definisci la variabile OS_VERSION:
Assicurati che la variabile utilizzi la stessa versione major.minor.patch,
ad esempio 1.12.4, di TARGET_RELEASE. In caso contrario, riassegna la richiesta al team
di ingegneria prima di procedere con i passaggi successivi.
Aggiorna la destinazione ReleaseMetadata per utilizzare Ubuntu
OS_VERSION nel cluster di amministrazione root:
Aggiorna il target UserclusterMetadata in modo che utilizzi Ubuntu
OS_VERSION nel cluster di amministrazione root e nel cluster di amministrazione dell'organizzazione
per ogni organizzazione. Esegui questo comando per ogni cluster:
Quando le immagini VM locali vengono importate utilizzando l'interfaccia a riga di comando gdcloud compute images import, lo stato dell'importazione rimane bloccato su WaitingForTranslationVM o ImportJobNotCreated. Questo perché il disco temporaneo
creato per la traduzione o l'importazione utilizza le dimensioni esatte dell'immagine qcow2 o raw,
ma LUKS aggiunge un overhead di alcuni MiB che causa l'errore di 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:
Se il 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.
Se l'oggetto non è presente, attiva di nuovo il comando gdcloud compute images import .... Dopo che 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.
Crea un nuovo VirtualMachineImageImport con un minimumDiskSize più grande:
Il pod importer-image-import-$VMII nello spazio dei nomi del progetto del cluster di sistema si arresta in modo anomalo con il seguente errore: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`). L'oggetto VMII VirtualMachineImageImport ha la condizione Tipo Ready con Stato False e Motivo TranslationInProgress dopo 2 ore dall'inizio dell'importazione.
Soluzione temporanea:
Per migliorare la velocità, modifica le dimensioni minime del disco dell'immagine impostandole su 200 Gi come segue:
Tieni presente che per eliminare e applicare ValidatingWebhookConfiguration, devi disporre del file kubeconfig dell'amministratore del cluster per il cluster di amministrazione dell'organizzazione. Puoi ottenere questo runbook IAM-R0004.
Se utilizzi gdcloud per avviare l'importazione, tieni presente che non è possibile fornire il parametro minimumDiskSize. Devi creare un oggetto VMII e modificarlo come mostrato nel comando precedente.
Il processo di VirtualMachineImageImport continua, ma si blocca di nuovo in un passaggio successivo. Nello spazio dei nomi del progetto nel cluster di sistema, il job image-import-$VMII non va a buon fine in modo continuo e viene visualizzato l'errore: error: stream error: stream ID x; NO_ERROR; received from peer. A questo punto, l'importazione dell'immagine viene completata. L'immagine finale viene caricata nell'archiviazione di oggetti, ma manca VirtualMachineImage. Puoi creare manualmente un VirtualMachineImage nel seguente modo:
`$NAME` deve corrispondere a `VMII.ImageMetadata.Name`, mentre `$OS_NAME` può essere uno dei seguenti valori: [`ubuntu-2004`, `ubuntu-2204`, `windows-2019`, `rhel-8`] e deve corrispondere al tipo di immagine importata.
Il deployment di istio-eastwestgateway nello spazio dei nomi istio-system è bloccato e gli eventi dei pod mostrano un errore Back-off pulling image "auto" da kubelet.
Per diagnosticare il problema, controlla se il mutatingwebhookconfiguration denominato istio-revision-tag-default esiste nello stesso cluster del
deployment del gateway bloccato.
Modifica il configMap cortex-config nel cluster di sistema
e imposta il timeout per memcached all'interno di index_cache su due secondi in modo
che la configurazione di index_cache sia simile a questa:
Il nodo bare metal viene visualizzato come NotReady e il server
è bloccato nella schermata di avvio con l'ultimo messaggio che dice
Retrieving encryption keys.
La posizione del programma di installazione di fluent-bit è cambiata in operations_center\bin\fluent-bit-win64.msi.
Copy-ConfigHostFiles.ps1 prevede che il programma di installazione client fluent-bit
corrisponda al pattern fluent-bit-*-win64.*.
Il programma di installazione non riesce a trovare il programma di installazione perché il pattern non corrisponde più.
La posizione del programma di installazione di Nessus è stata modificata in operations_center\bin\NessusAgent-x64.msi.
Copy-ConfigHostFiles.ps1 prevede che il programma di installazione del client
corrisponda al nome file /NessusAgent-10.4.1-x64.msi.
Il programma di installazione non riesce a trovare il programma di installazione perché il pattern non corrisponde più.
Modifica le righe precedenti per aggiungere la posizione corretta del programma di installazione,
modificando Nessus-10.4.1-x64.msi in NessusAgent-x64.msi:
Recupera le credenziali di accesso alla UI di gestione di StorageGRID dal secret
gpc-system/objectstorage-breakglass-root-level1 nel cluster root-admin.
Accedi alla UI di gestione di StorageGRID con le credenziali del passaggio precedente. L'URL ha lo stato ObjectStorageSite:
Vai alla scheda Configurazione e fai clic su Gruppi ad alta disponibilità.
Apri la visualizzazione dettagliata di ogni gruppo HA e annota il relativo indirizzo IP virtuale (VIP).
Crea un nuovo gruppo HA:
Nome gruppo: il pattern del nome è ORGANIZATION_NAME-ha
. In questo caso, è org-2-ha.
Descrizione gruppo: utilizza i gruppi HA esistenti per il
pattern di descrizione.
Interfacce: seleziona tutti i eth2.
Ordine di priorità: l'interfaccia principale deve avere la priorità più alta.
SubnetCIDR: questo campo viene compilato automaticamente da StorageGRID.
Verifica che la subnet corrisponda a status.ipv4SubnetStatus.cidrBlock
in SubnetClaimexternal-objectstorage-client-lif-cidr.
IP virtuale: l'IP successivo nell'intervallo IP disponibile. L'IP
non può entrare in conflitto con l'IP riservato, l'IP client del nodo di amministrazione e
i VIP dei gruppi HA esistenti.
Quando esegui l'upgrade dell'organizzazione principale dalla versione 1.12.2 alla 1.12.4, il
componente secondario iac-gitlab ha uno stato di riconciliazione in corso.
Per diagnosticare il problema, controlla i log di Prometheus, ad esempio:
Fai riferimento al messaggio di errore precedente e annota lo spazio dei nomi e il nome del
deployment. In questo esempio, NAME è
iam-authzpdp-backend-server e NAMESPACE è
iam-system.
Prendi nota del pod in cui non tutti i contenitori sono pronti. In questo caso,
POD_NAME è iam-authzpdp-backend-server-6875654c4b-pvscg
che ha uno dei due container non pronto, come indicato dallo stato 1/2. Se ci sono più pod di questo tipo, ripeti il passaggio successivo
per ogni pod interessato.
Elimina il pod non completamente integro:
kubectldeletepod-nNAMESPACEPOD_NAME>
Esegui di nuovo il comando del passaggio 2. Nota che tutti i pod dovrebbero
essere integri ora. Questo passaggio potrebbe richiedere alcuni minuti.
Se il pod eliminato non viene sostituito da un pod integro, apri un ticket di assistenza.
Durante l'upgrade dell'organizzazione tenant dalla versione 1.12.2 alla 1.12.4, l'upgrade del sottocomponente opa gatekeeper non riesce e viene visualizzato un messaggio ReconciliationError.
Soluzione temporanea:
Modifica l'oggetto mutatingwebhookconfigurationedr-sidecar-injector-webhook-cfg del cluster di utenti interessato. Se sono presenti più cluster utente interessati, ripeti i passaggi per ogni cluster utente interessato:
Quando esegui l'upgrade dalla versione 1.12.2 alla 1.12.4, ansibleplaybook non viene aggiornato nell'ambito dell'upgrade del cluster. Le correzioni aggiornate in ansibleplaybook non vengono applicate e bloccano il criterio del sistema operativo che esegue la versione precedente di ansibleplaybook.
Soluzione temporanea:
Elimina il job Kubernetes create-ansible-playbooks:
Quando crei una nuova organizzazione, potresti notare che il sottocomponente core-dns
va in timeout nei log:
[INFO]192.0.2.0:60741-40400"A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000828817s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.A:readudp10.244.4.184:59927->192.0.2.1:53:i/otimeout
[INFO]192.0.2.0:51401-5813"AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232"--02.000585231s
[ERROR]plugin/errors:2objectstorage-tenant-mgmt.gdch.example.com.AAAA:readudp10.244.4.184:48542->192.0.2.1:53:i/otimeout
Soluzione temporanea:
Aggiorna il servizio gpc-coredns-forwarder-udp
e il servizio gpc-coredns-forwarder-tcp del cluster di amministrazione root
e aggiungi i nuovi intervalli IP negli intervalli di origine del bilanciatore del carico.
Se le modifiche di CR vengono sostituite, metti in pausa il sottocomponente dns-core
con l'annotazione lcm.private.gdc.goog/paused="true".
Quando esegui l'upgrade dalla versione 1.12.2 alla 1.12.4, il sottocomponente file-netapp-trident è bloccato sull'eliminazione di StorageClasses. Mostra il seguente stato:
status:
backendStatus:
conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
-lastTransitionTime:"2024-04-08T00:12:53Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-05-01T10:10:08Z"message:Fetchedparametersfromdefault,runtime
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-05-02T06:04:04Z"message:'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:DeployError
status:"False"type:Deployed
-lastTransitionTime:"2024-04-23T06:50:12Z"message:Readinesscheckjobpassed
observedGeneration:1reason:ReadinessCheckDone
status:"True"type:Ready
deploymentFinished:falselastDeployTimestamp:"2024-05-02T06:03:16Z"readyAfterDeploy:trueversion:""conditions:
-lastTransitionTime:"2024-05-02T06:04:14Z"message:'Reconciliation error: E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks" found'observedGeneration:2reason:ReconciliationError
status:"True"type:Reconciling
crdsStatus:
conditions:
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Successfullypulledchart
observedGeneration:2reason:ChartPullDone
status:"True"type:ChartPull
-lastTransitionTime:"2024-04-07T08:02:33Z"message:Noparameterstofetch
observedGeneration:2reason:ParametersDone
status:"True"type:Parameters
-lastTransitionTime:"2024-04-07T08:02:34Z"message:Readinesssourceisempty
observedGeneration:2reason:ReadinessCheckSkipped
status:"True"type:Ready
-lastTransitionTime:"2024-05-01T18:37:52Z"message:Ready
observedGeneration:2reason:ReconciliationCompleted
status:"False"type:Reconciling
deploymentFinished:truelastDeployTimestamp:"2024-05-02T06:04:03Z"readyAfterDeploy:trueversion:1.12.3-gdch.312
Soluzione temporanea:
Metti in pausa il sottocomponente file-netapp-trident:
## Set KUBECONFIG to root-admin KUBECONFIGexportKUBECONFIG=ROOT_ADMIN_KUBECONFIGkubectlannotatesubcomponentfile-netapp-trident-n$cluster_namespacelcm.private.gdc.goog/paused=true
Elimina StorageClasses che il job non è riuscito a creare,
come standard-rwo, standard-block, standard-rwo-non-luks e standard-block-non-luks:
Attiva la ricreazione di StorageClasses riavviando oclcm-backend-controller per il tuo cluster
(controller root-admin per i cluster root e org-admin, controller org-admin per i cluster di sistema e utente):
I pod primary-prometheus-shardX-replicaX sono visibili nello spazio dei nomi obs-system e nello spazio dei nomi mon-system. Se primary-prometheus-shardX-replicaX esiste solo
nello spazio dei nomi obs-system dopo un upgrade alla versione 1.12, allora
si tratta di un problema sconosciuto diverso e la soluzione alternativa non deve essere eseguita.
Il comportamento previsto è che
primary-prometheus-shardX-replicaX esista solo nello
spazio dei nomi mon-system dopo il completamento dell'upgrade alla versione 1.12.
Soluzione temporanea:
Elimina manualmente i primary-prometheus-shardX-replicaX
StatefulSet nello spazio dei nomi obs-system.
Non eliminare i primary-prometheus-shardX-replicaX
StatefulSet nello spazio dei nomi mon-system.
Un ClusterCIDRConfig è un oggetto obbligatorio per assegnare
PodCIDRs. Nonostante la creazione di ClusterCIDRConfig, non è stato assegnato PodCIDRs. 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:
Controlla se l'oggetto ClusterCIDRConfig è stato creato sul
cluster:
Esegui describe per uno degli oggetti nodo del cluster bloccato nella riconciliazione e verifica se è presente un evento CIDRNotAvailable sull'oggetto nodo:
MonitoringTarget mostra lo stato Not Ready durante la creazione dei cluster di utenti, il che fa sì che le API preaddestrate mostrino continuamente lo stato Enabling nell'interfaccia utente.
Soluzione temporanea:
Apri il menu del browser Chrome (icona con tre puntini).
Fai clic su Altri strumenti > Strumenti per sviluppatori per aprire la console.
Fai clic sulla scheda Rete nella console.
Trova le richieste ai-service-status.
Fai clic sulla scheda Risposta in una richiesta ai-service-status per visualizzare i contenuti della richiesta.
Verifica che tutto sia pronto, ad eccezione dei componenti MonitoringTarget e LoggingTarget.
Quando esegui l'upgrade dell'archiviazione oggetti, potresti visualizzare un avviso come questo:
TypeReasonAgeFromMessage
-------------------------
WarningReconcileError55m(x2over55m)ObjectStorageAdminNodeReconcilerReconcileerror,retrying:errorstoringthesshcreds:500InternalServerError: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 temporanea:
Controlla che ogni nodo abbia le credenziali SSH corrispondenti memorizzate in un secret.
Durante gli upgrade, il cluster Translation DB viene ricreato, il che causa l'obsolescenza e la mancata sincronizzazione del secret del cluster di sistema ODS secret-store. Per questo motivo, l'inizializzazione del pod e del servizio frontend di traduzione non va a buon fine.
Il server non può connettersi al gestore delle chiavi, impedendo la disponibilità dello stato del server. Questo problema causa l'errore del job server-encrypt-and-create-logical-drive e il cluster di amministrazione non diventa pronto. Nei log dei job potresti visualizzare un errore simile al seguente:
Loki ha un solo volume permanente (PV) sia per i log write-ahead (WAL) sia per gli indici. Il WAL può riempire il PV se un pod Loki non riesce a connettersi al bucket di archiviazione per ore. Se il PV non ha più spazio, Loki non può eseguire il recupero a meno che tu non elimini il PV e riavvii StatefulSet.
Soluzione temporanea:
Per recuperare un pod Loki da questo stato, devi ridurre lo scale down del StatefulSet corrispondente ed eliminare il PV senza spazio rimanente.
Per recuperare il pod Loki:
Assicurati che il contenitore dello strumento IO sia installato sulla workstation. Per maggiori dettagli, consulta il manuale operativo OOPS-P0065.
Per ottenere le autorizzazioni necessarie per modificare le risorse, chiedi all'Amministratore sicurezza di concederti i seguenti ruoli:
observability-viewer
observability-admin
Imposta la variabile di ambiente KUBECONFIG con il percorso del file kubeconfig nel cluster di amministrazione principale. Per maggiori dettagli, consulta il runbook IAM-R0004.
Imposta la variabile di ambiente ORG_NAME con il nome dell'organizzazione interessata.
Salva i seguenti contenuti in un file YAML denominato log-admin-overrides.yaml:
Imposta la variabile di ambiente KUBECONFIG con il percorso del file kubeconfig nel cluster in cui è in esecuzione il pod Loki interessato. Per maggiori dettagli, consulta il runbook IAM-R0004.
Imposta la variabile di ambiente LOKI_POD_NAME con il nome del pod Loki interessato.
Imposta la variabile di ambiente KUBECONFIG con il percorso del file kubeconfig nel cluster di amministrazione dell'organizzazione interessata. Per maggiori dettagli, consulta il runbook IAM-R0004.
Modifica i contenuti nel file YAML log-admin-overrides.yaml nel seguente modo:
I job vengono pianificati continuamente. Non appena un job viene terminato, ne viene pianificato uno nuovo. I job programmati continuamente sono:
unet-networkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-parameter
unet-nodenetworkpolicy-assets-readiness
unet-userclusterpolicy-assets-parameter
unet-clustermesh-backend-parameter
unet-clustermesh-backend-readiness
Soluzione temporanea:
Metti in pausa i seguenti sottocomponenti:
unet-networkpolicy
unet-nodenetworkpolicy
unet-nodenetworkpolicy
unet-userclusterpolicy
unet-clustermesh
Riattiva i sottocomponenti ogni volta che viene modificato il secret fleet-info nel cluster amministratore principale. Questo problema si verifica quando viene modificata la gestione degli switch dell'istanza, ad esempio kr get managementswitches -A o quando viene modificato un cidrclaim nello spazio dei nomi dell'organizzazione.
Riattiva i componenti secondari ogni volta che viene modificata una risorsa NodePool nel cluster di amministrazione dell'organizzazione. Disattiva la modalità di pausa dei sottocomponenti prima di iniziare.
Quando esegui l'upgrade dalla versione 1.12.2 alla 1.12.4, non è disponibile un upstream integro per ServiceNow. Potresti visualizzare il seguente messaggio: failed to stage volume: LUKS passphrase cannot be empty.
La classe di archiviazione system-performance-rwo non è abilitata per LUKS. L'allegato del volume indica che il PVC è abilitato per LUKS.
Il riconciliatore cerca un segreto con le passphrase LUKS. Poiché l'allegato del volume indica che LUKS è abilitato e la classe di archiviazione non lo è, la passphrase segreta non viene creata.
Soluzione temporanea:
Ottieni il Kubeconfig per il cluster root o org-admin in cui si verifica il problema:
exportKUBECONFIG=${ROOT_OR_ORG_ADMIN_KUBECONFIG}
Elimina la classe di archiviazione system-performance-rwo e ricreala:
Quando esegui l'upgrade dalla versione 1.12.2 alla 1.12.4, l'upgrade dell'organizzazione si blocca nella fase NodeUpgrade e l'attività di upgrade del nodo mostra il seguente errore:
kubelet continua a stampare il seguente log di spam:
May2223:08:00control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthoskubelet[3751]:time="2024-05-22T23:08:00Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May2223:09:04control-1kubelet[3751]:time="2024-05-22T23:09:04Z"level=warningmsg="Failed to remove cgroup (will retry)"error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
Il processo runc init è bloccato, impedendo a kubelet di eliminare il pod cgroup.
Soluzione temporanea:
Utilizza il seguente script per trovare il processo che blocca l'eliminazione di cgroup:
# Find matching cgroup directoriesMATCHING_CGROUPS=$(find/sys/fs/cgroup-typed-name"*74353c*")if[-z"$MATCHING_CGROUPS"];thenecho"No cgroups found containing 'd06aac'."exit0fiecho"Matching cgroups:"forcgroupin$MATCHING_CGROUPS;doecho"- $cgroup"# Print cgroup path# Check if cgroup.procs existsif[-f"$cgroup/cgroup.procs"];thenecho" Processes:"# List PIDs in cgroup.procsforpidin$(cat"$cgroup/cgroup.procs");do# Get process detailsps-opid,comm,cmd--no-headers$pid2>/dev/null# Suppress errors if process doesn't existdoneelseecho" No cgroup.procs file found."# Handle cases where cgroup.procs is missingfiecho# Add a newline for better readabilitydone
Controlla lo stato del congelatore utilizzando cat freezer.state. Lo stato deve essere FROZEN.
Echo "THAWED" > freezer.state
cgroup è stato eliminato. Kubelet smette di inviare spam al log.
PTaaS viene implementato nell'organizzazione gdchservices.
Esamina le annotazioni e le etichette del progetto PTaaS gdch-perftest e del bucket perftest-bucket-reports nello spazio dei nomi perftest gdch-perftest. Il bucket potrebbe non avere l'etichetta app.kubernetes.io/managed-by=Helm e le annotazioni meta.helm.sh/release-name=perf-ptaas-assets e meta.helm.sh/release-namespace=gdch-perftest.
Aggiungi manualmente queste etichette e annotazioni:
Esamina le annotazioni del progetto PTaaS gdch-perftest. Il progetto potrebbe essere configurato in modo errato con l'annotazione: meta.helm.sh/release-name=perf-ptaas-assets.
Modifica questa annotazione in meta.helm.sh/release-name=perf-ptaas-backend:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-23 UTC."],[],[]]
