Per informazioni sulla versione, consulta le note di rilascio di Distributed Cloud connesso.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Risolvi i problemi di Distributed Cloud connesso

Google monitora e gestisce da remoto l'hardware Google Distributed Cloud connesso. A questo scopo, gli ingegneri Google hanno accesso Secure Shell (SSH) all'hardware Distributed Cloud connesso. Se Google rileva un problema, un tecnico di Google ti contatta per risolverlo. Se hai identificato un problema, contatta immediatamente l'Assistenza Google per diagnosticarlo e risolverlo.

Upgrade software di Distributed Cloud connesso

Questa sezione descrive come utilizzare Metrics Explorer per verificare se un cluster connesso a Distributed Cloud è in fase di upgrade software.

Questa procedura utilizza le seguenti metriche di Monitoring:

Versione attuale del cluster (/edge_cluster/current_cluster_version): indica la versione attuale del software Distributed Cloud connesso in esecuzione sul cluster.
Versione del cluster di destinazione (/edge_cluster/target_cluster_version): indica la versione di destinazione di Distributed Cloud Connected a cui viene eseguito l'upgrade del cluster.

Per completare i passaggi descritti in questa sezione, devi soddisfare i seguenti prerequisiti:

Accesso alla console Google Cloud e al tuo progetto Distributed Cloud connesso Google Cloud .
Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
(Facoltativo) il valore machine_id della macchina Distributed Cloud connected di destinazione per filtrare i risultati restituiti.

Utilizzare Esplora metriche per controllare le versioni software attuali e di destinazione del cluster

Vai a Metrics Explorer:
1. Nella console Google Cloud , vai alla sezione Monitoring.
2. Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
1. Nella pagina Metrics Explorer, vai alla pagina Configurazione.
2. Fai clic su Seleziona una metrica.
3. Utilizza la barra di ricerca per cercare il tipo di risorsa Cluster. Puoi anche utilizzare l'identificatore di risorsa completo edgecontainer.googleapis.com/Cluster.
4. Nei risultati restituiti, fai clic sul tipo di risorsa Cluster.
Ottieni la versione software attuale del cluster:
1. Nella sezione Metrica, cerca il valore current_cluster_version.
2. Seleziona la metrica Tempo di attività della macchina. Il percorso completo è edgecontainer.googleapis.com/edge_cluster/current_cluster_version.
3. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
Ottieni la versione software di destinazione del cluster:
1. Fai clic su Aggiungi query.
2. Nella sezione Metrica, cerca il valore target_cluster_version.
3. Seleziona la metrica Versione cluster di destinazione. Il percorso completo è edgecontainer.googleapis.com/edge_cluster/target_cluster_version.
4. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
Controlla lo stato dell'upgrade software del cluster nel grafico visualizzato.
- Se le righe Versione attuale del cluster e Versione di destinazione del cluster indicano valori diversi, il cluster è in fase di upgrade del software.
- Se le righe Versione attuale del cluster e Versione di destinazione del cluster indicano lo stesso valore, il cluster non è in fase di upgrade del software.
Verifica il risultato del passaggio precedente utilizzando il seguente comando:
```
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
```
Sostituisci quanto segue:
- CLUSTER_ID: l'ID del cluster di destinazione.
- REGION: la Google Cloud regione in cui è stato creato il cluster.
Nell'output del comando, annota i valori dei seguenti campi:
- Se il valore del campo status è UPDATING, il cluster è in fase di upgrade del software.
- Se i valori dei campi clusterVersion e targetVersion sono diversi, confrontali con i valori restituiti da Metrics Explorer.

Comprendere i risultati

La seguente tabella spiega i risultati restituiti da Metrics Explorer e dal comando gcloud.

Stato del cluster	Diagnosi	Risoluzione
In salute I valori di `currentVersion` e `targetVersion` corrispondono Il valore di `status` è `RUNNING`	Il cluster esegue la versione di destinazione del software Distributed Cloud connected.	Nessuno.
Upgrade Il valore di `currentVersion` è inferiore a `targetVersion` Il valore di "status" è `UPDATING`	Il cluster sta eseguendo l'upgrade alla versione di destinazione del software Distributed Cloud connesso.	Monitora il cluster in Metrics Explorer finché i valori della versione del cluster attuale e di destinazione non corrispondono.
Bloccato Il valore di `currentVersion` è inferiore a `targetVersion` a tempo indeterminato Il valore di "status" è `UPDATING` a tempo indeterminato	L'upgrade alla versione di destinazione del software connesso a Distributed Cloud non è riuscito su almeno un nodo del cluster.	Controlla la connettività della macchina e i log di sistema; contatta Google per ricevere assistenza.
Rollback Il valore di `currentVersion` è superiore a `targetVersion` Il valore di "status" è `UPDATING`	luster sta eseguendo il rollback a una versione precedente del software Google Distributed Cloud connesso.	Contatta Google per identificare il motivo del rollback.

Se l'upgrade software sul cluster non è riuscito o il cluster è stato sottoposto a rollback a una versione software precedente, controlla quanto segue:

Integrità del nodo. Verifica che ogni macchina fisica Distributed Cloud connessa abbia la connettività di rete e che il tempo di attività venga segnalato come descritto nella sezione successiva.
Periodi di manutenzione. Verifica se l'upgrade software è stato messo in pausa a causa di un periodo di esclusione dalla manutenzione.
Log di sistema. Esamina i log di sistema per identificare i possibili motivi dell'errore di upgrade del software, ad esempio i timeout di espulsione dei pod.

Se i passaggi di risoluzione elencati nella tabella non risolvono il problema, contatta l'assistenza Google con il valore machine_id della macchina interessata e il timestamp dell'interruzione.

Riavvii delle macchine Distributed Cloud connected

Questa sezione descrive come utilizzare Metrics Explorer per verificare se una macchina fisica connessa a Distributed Cloud è stata riavviata e determinare il motivo del riavvio. Il monitoraggio dei riavvii consente di determinare se facevano parte di una manutenzione pianificata o se sono stati causati da un guasto hardware o da un'interruzione di corrente.

Questa procedura utilizza le seguenti metriche di Monitoring:

Machine Uptime (/machine/uptime): indica il tempo, in secondi, trascorso dall'ultimo riavvio.
Riavvii della macchina (/machine/restart_count): indica il numero totale di riavvii della macchina di destinazione dal suo deployment.

Per completare i passaggi descritti in questa sezione, devi soddisfare i seguenti prerequisiti:

Accesso alla console Google Cloud e al tuo progetto Distributed Cloud connesso Google Cloud .
Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
(Facoltativo) il valore machine_id della macchina Distributed Cloud connected di destinazione per filtrare i risultati restituiti.

Utilizza Esplora metriche per controllare l'uptime della macchina e il conteggio dei riavvii

Vai a Metrics Explorer:
1. Nella console Google Cloud , vai alla sezione Monitoring.
2. Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
1. Nella pagina Metrics Explorer, vai alla pagina Configurazione.
2. Fai clic su Seleziona una metrica.
3. Utilizza la barra di ricerca per cercare il tipo di risorsa Macchina. Puoi anche utilizzare l'identificatore di risorsa completo edgecontainer.googleapis.com/Machine.
4. Nei risultati restituiti, fai clic sul tipo di risorsa Macchina.
Controlla l'uptime della macchina:
1. Nella sezione Metrica, cerca il valore uptime.
2. Seleziona la metrica Tempo di attività della macchina. Il percorso completo è edgecontainer.googleapis.com/machine/uptime.
3. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
4. Nel grafico temporale visualizzato, verifica che il grafico dell'uptime sia in continuo aumento. Se in un determinato momento il valore di uptime scende a zero e si riavvia, significa che la macchina è stata riavviata.
Controlla il conteggio dei riavvii della macchina:
1. Nella sezione Metrica, cerca il valore restart_count.
2. Seleziona la metrica Riavvii del computer. Il percorso completo è edgecontainer.googleapis.com/machine/restart_count.
3. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
4. Nel grafico temporale visualizzato, verifica che la linea del grafico rimanga a 0, il che indica che non si sono verificati riavvii. Se in un dato momento la linea raggiunge il picco di 1 significa che la macchina è stata riavviata; annota il timestamp esatto del riavvio per ulteriori risoluzioni dei problemi.
5. (Facoltativo) Per visualizzare i singoli eventi anziché un grafico, vai alla sezione Aggregazione della pagina, imposta il campo Periodo di allineamento su 1 minute e il campo Allineamento per serie su Delta.

Comprendere i risultati

La seguente tabella spiega i risultati restituiti da Metrics Explorer.

Stato della macchina	Diagnosi	Risoluzione
Stabile La metrica "Tempo di attività della macchina" aumenta costantemente Il delta della metrica "Riavvii della macchina" è `0`	La macchina non è stata riavviata.	Nessuno.
Riavvio pulito La metrica "Tempo di attività della macchina" scende a `0` La metrica "Riavvii della macchina" aumenta fino a `1`	La macchina è stata riavviata e riconnessa a Google Cloud.	Controlla i log di sistema per determinare il motivo del riavvio.
Interruzione di corrente Il grafico della metrica "Tempo di attività della macchina" presenta un'interruzione senza dati La metrica "Riavvii della macchina" non è cambiata durante l'interruzione del tempo di attività della macchina	La macchina ha perso l'alimentazione o la connettività di rete prima di poter essere riavviata.	Controlla i cavi di alimentazione e di rete, la configurazione della rete locale e lo stato dell'indicatore LED.
Intermittente Il valore della metrica "Macchina connessa" alterna `0` e `1` Il valore della metrica "Connettività di rete" alterna `0` e `1`	Connessione di rete instabile, perdita di pacchetti o latenza eccessiva.	Controlla la rete locale per rilevare congestioni e hardware difettoso.

Se i passaggi di risoluzione elencati nella tabella non risolvono il problema, contatta l'assistenza Google con il valore machine_id della macchina interessata e il timestamp dell'interruzione.

Connettività delle macchine Distributed Cloud connected

Questa sezione descrive come controllare la connettività a internet e Google Cloud per le macchine connesse a Distributed Cloud utilizzando la funzionalità Metrics Explorer di Cloud Monitoring.

Questa procedura utilizza le seguenti metriche di Monitoring:

Attrezzo connesso (/machine/connected): indica se l'attrezzo è connesso a Google Cloud.
Connettività di rete (/machine/network/connectivity): indica se l'interfaccia di rete principale della macchina ha connettività a internet.

Per completare i passaggi descritti in questa sezione, devi soddisfare i seguenti prerequisiti:

Accesso alla console Google Cloud e al tuo progetto Distributed Cloud connesso Google Cloud .
Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
(Facoltativo) il valore machine_id della macchina Distributed Cloud connected di destinazione per filtrare i risultati restituiti.

Utilizzare Esplora metriche per controllare la connettività della macchina

Vai a Metrics Explorer:
1. Nella console Google Cloud , vai alla sezione Monitoring.
2. Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
1. Nella pagina Metrics Explorer, vai alla pagina Query.
2. Utilizza la barra di ricerca per cercare il tipo di risorsa Macchina. Puoi anche utilizzare l'identificatore di risorsa completo edgecontainer.googleapis.com/Machine.
3. Nei risultati restituiti, fai clic sul tipo di risorsa Macchina.
Controlla la connessione della macchina a Google Cloud:
1. Nella sezione Metrica, cerca il valore connected.
2. Seleziona la metrica Macchina connessa. Il percorso completo è edgecontainer.googleapis.com/machine/connected.
3. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
4. Nel grafico temporale visualizzato, verifica che la linea Integrità rimanga al 100% in modo contiguo. Se in un determinato momento questo valore è 0% o Non integro, la macchina ha perso la connettività con Google Cloud all'ora indicata.
Controlla la connettività a internet della macchina:
1. Nella sezione Metrica, cerca il valore connectivity.
2. Seleziona la metrica Connettività di rete. Il percorso completo è edgecontainer.googleapis.com/machine/network/connectivity.
3. (Facoltativo) Filtra in base al valore machine_id di destinazione utilizzando la sezione Filtro.
4. Nel grafico temporale visualizzato, verifica che la linea Integrità rimanga al 100% in modo contiguo. Se in un determinato momento questo valore è 0% Non integro, la macchina ha perso la connettività a internet all'ora indicata.

Comprendere i risultati

La seguente tabella spiega i risultati restituiti da Metrics Explorer.

Stato della macchina	Diagnosi	Risoluzione
In buono stato Il valore della metrica "Macchina connessa" è `1` Il valore della metrica "Connettività di rete" è `1`	Funzionamento normale.	Nessuno.
Disconnesso Il valore della metrica "Macchina connessa" è `0` Il valore della metrica "Connettività di rete" è `1`	La macchina ha connettività internet, ma non riesce a connettersi a Google Cloud.	Controlla le regole firewall per i servizi Google e gli endpoint API. Verifica che gli agenti connessi di Distributed Cloud siano in esecuzione sulla macchina.
Isolato Il valore della metrica "Macchina connessa" è `0` Il valore della metrica "Connettività di rete" è `0`	La macchina non ha connettività a internet.	Controlla i cavi di alimentazione e di rete, la configurazione della rete locale e lo stato dell'indicatore LED. Verifica la configurazione di VLAN e routing.
Intermittente Il valore della metrica "Macchina connessa" alterna `0` e `1` Il valore della metrica "Connettività di rete" alterna `0` e `1`	Connessione di rete instabile, perdita di pacchetti o latenza eccessiva.	Controlla la rete locale per rilevare congestioni e hardware difettoso.

Se noti valori costanti di 0 per una delle metriche, segui i passaggi per la risoluzione dei problemi descritti nella tabella per risolverli. Se il problema persiste, contatta l'Assistenza Google con il valore machine_id della macchina interessata e il timestamp dell'interruzione.

Macchine virtuali bloccate nello stato `Pending`

Un workload della macchina virtuale può bloccarsi nello stato Pending e non essere pianificato su un nodo se si verifica uno dei seguenti scenari:

Distributed Cloud connesso non può allocare le risorse richieste, come tempo CPU, memoria o spazio su disco, alla macchina virtuale.
Si è verificato un errore nella configurazione della macchina virtuale.
Si è verificato un errore con l'archiviazione della macchina virtuale.
Il nodo di destinazione è compromesso.

Per risolvere il problema, segui questi passaggi:

Ottieni le credenziali del cluster come descritto in Ottenere le credenziali per un cluster.

Ottieni informazioni sulla macchina virtuale interessata:

kubectl describe virtualmachine VM_NAME -n NAMESPACE

Sostituisci quanto segue:

VM_NAME: il nome della macchina virtuale di destinazione.
NAMESPACE: lo spazio dei nomi della macchina virtuale di destinazione.

Il comando restituisce un output simile al seguente:

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

L'output del comando contiene messaggi che potrebbero indicare vincoli delle risorse, errori di pianificazione, guasti di archiviazione e altri problemi.

Esamina l'output per determinare le cause dell'errore di pianificazione, come spiegato nelle sezioni successive.

Risorse insufficienti

Potresti visualizzare un messaggio che indica risorse insufficienti, come CPU, memoria o spazio su disco. Ad esempio:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Per risolvere il problema, controlla le risorse allocate alle macchine virtuali interessate e ad altri carichi di lavoro pianificati sul nodo, poi procedi nel seguente modo a seconda delle esigenze aziendali:

Fare lo scale down di altri workload pianificati sul nodo.
Riduci la quantità di risorse allocate alla macchina virtuale interessata.
Aggiungi altre macchine al cluster interessato.

Nodi con taint

Potresti visualizzare un messaggio che indica che il nodo di destinazione è compromesso. Ad esempio:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Per risolvere il problema, procedi nel seguente modo:

Utilizza il comando seguente per verificare la presenza di taint sul nodo:

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

Il comando restituisce un output simile al seguente:

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

Esegui una delle seguenti operazioni:
- Per le contaminazioni impreviste, rimuovile come descritto in Contaminazioni e tolleranze.
- Per i taint previsti, aggiungi le tolleranze corrispondenti alla configurazione della macchina virtuale, come descritto in Taint e tolleranze.

Errori di archiviazione

Potresti visualizzare un messaggio che indica un errore con lo spazio di archiviazione della macchina virtuale. Ad esempio:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Questo messaggio potrebbe indicare che il volume permanente corrispondente non viene montato sul nodo di destinazione.

Per risolvere il problema, procedi nel seguente modo:

Utilizza il seguente comando per ottenere lo stato delle rivendicazioni di volumi permanenti (PVC) nello spazio dei nomi della macchina virtuale interessata:

kubectl get pvc -n NAMESPACE

Sostituisci NAMESPACE con il nome dello spazio dei nomi di destinazione.

Il comando restituisce un output simile al seguente:

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

Verifica che il PVC corrispondente abbia lo stato Bound; se lo stato è Pending, il sottosistema di archiviazione non è riuscito a eseguire il provisioning del volume. In questi casi, devi risolvere i problemi relativi alla configurazione del sottosistema di archiviazione e assicurarti che sia disponibile l'StorageClass appropriato.

Blocchi della pianificazione causati da webhook di ammissione non riusciti

I webhook di ammissione ti consentono di intercettare le richieste al server API Kubernetes prima che l'oggetto diventi persistente. Sebbene utili per l'applicazione di criteri di sicurezza personalizzati, gli webhook configurati in modo errato possono causare interruzioni a livello di cluster, soprattutto durante operazioni critiche come gli upgrade software e gli aggiornamenti dei certificati. In particolare, un webhook di ammissione bloccato o non disponibile può bloccare il control plane Kubernetes, impedendo qualsiasi ulteriore pianificazione dei workload sul cluster.

Stallo del control plane

Un deadlock di dipendenza circolare può verificarsi quando un webhook di ammissione è responsabile della convalida delle risorse necessarie per il ripristino del webhook stesso. Ad esempio, se un webhook di controllo è configurato per convalidare i pod e il pod webhook deve essere riprogrammato durante un aggiornamento del software del nodo, il server API Kubernetes potrebbe tentare di contattare il webhook per autorizzare la creazione del nuovo pod. Se il webhook non è raggiungibile, la richiesta non va a buon fine, il pod non viene creato e il cluster entra in uno stato di deadlock in cui non è possibile pianificare nuovi carichi di lavoro.

Quando un webhook è configurato con failurePolicy: Fail, qualsiasi errore di comunicazione o timeout tra il server API e il webhook comporta il rifiuto della richiesta API. Ciò causa i seguenti problemi:

Gli upgrade software non riescono: i componenti di sistema e le VM non possono essere pianificati durante e dopo un upgrade software del nodo.
Impossibile avviare i servizi di sistema: non è possibile avviare i pod dell'infrastruttura, come Symcloud Storage e VM Runtime su GDC.
Nodi bloccati in modalità di manutenzione: i nodi in modalità di manutenzione non possono essere riconciliati o uscire dalla modalità perché il controller è bloccato dalla logica di controllo dell'ammissione.

Best practice per la configurazione dei webhook

Segui le best practice descritte in questa sezione per evitare il deadlock del control plane descritto in precedenza. Queste best practice si applicano a tutti gli oggetti ValidatingWebhookConfiguration e MutatingWebhookConfiguration.

Utilizza `failurePolicy: Ignore`

A meno che i requisiti della tua attività non prevedano che una richiesta API debba non riuscire se non può essere convalidata, imposta sempre il campo failurePolicy su Ignore. In questo modo, il server API Kubernetes continua a funzionare anche quando il servizio webhook interessato non è disponibile, consentendo la pianificazione e il ripristino dei pod critici per il sistema.

Escludi spazi dei nomi riservati

I webhook non devono mai intercettare le richieste di risorse negli spazi dei nomi riservati. Devi escludere questi spazi dei nomi dalla configurazione del webhook utilizzando il campo namespaceSelector. Consulta Limitazioni dello spazio dei nomi di gestione per un elenco completo degli spazi dei nomi riservati. Ad esempio:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Recuperare un cluster in deadlock a causa di webhook non riusciti

Se il tuo cluster è in deadlock a causa di webhook non riusciti e i tuoi comandi kubectl per la creazione di risorse vanno in timeout o restituiscono errori, in genere è perché il webhook ha failurePolicy impostato su Fail. Segui i passaggi descritti in questa sezione per ripristinare il cluster dall'impasse. Se il webhook non riuscito è un webhook di modifica, utilizza mutatingwebhookconfiguration anziché validatingwebhookconfiguration.

Identifica i webhook non riusciti:
1. Elenca i webhook di convalida di cui è stato eseguito il deployment sul cluster:
```
kubectl get validatingwebhookconfigurations
```
2. Elenca i webhook mutanti di cui è stato eseguito il deployment sul cluster:
```
kubectl get mutatingwebhookconfigurations
```
Verifica se i pod che supportano questi webhook sono in esecuzione:
```
kubectl get pods -A | grep WEBHOOK_SERVICE
```
Sostituisci WEBHOOK_SERVICE con il nome del servizio del webhook di destinazione.

Imposta failurePolicy del webhook non riuscito su Ignore:

kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

Sostituisci WEBHOOK_SERVICE con il nome del servizio del webhook di destinazione.

(Facoltativo) Se il passaggio precedente non è riuscito, elimina forzatamente la configurazione del webhook interessato:
```
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
```
Sostituisci WEBHOOK_CONFIG con il nome della configurazione del webhook di destinazione.

Dopo aver modificato o eliminato forzatamente la configurazione del webhook, l'API server Kubernetes riprende l'elaborazione delle richieste, risolvendo il deadlock e consentendo il completamento dei processi bloccati.

Risolvi i problemi di Distributed Cloud connesso Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Upgrade software di Distributed Cloud connesso

Utilizzare Esplora metriche per controllare le versioni software attuali e di destinazione del cluster

Comprendere i risultati

Riavvii delle macchine Distributed Cloud connected

Utilizza Esplora metriche per controllare l'uptime della macchina e il conteggio dei riavvii

Comprendere i risultati

Connettività delle macchine Distributed Cloud connected

Utilizzare Esplora metriche per controllare la connettività della macchina

Comprendere i risultati

Macchine virtuali bloccate nello stato Pending

Risorse insufficienti

Nodi con taint

Errori di archiviazione

Blocchi della pianificazione causati da webhook di ammissione non riusciti

Stallo del control plane

Best practice per la configurazione dei webhook

Utilizza failurePolicy: Ignore

Escludi spazi dei nomi riservati

Recuperare un cluster in deadlock a causa di webhook non riusciti

Risolvi i problemi di Distributed Cloud connesso

Macchine virtuali bloccate nello stato `Pending`

Utilizza `failurePolicy: Ignore`