Google monitora e gestisce da remoto i deployment di 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 del 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 del 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 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 Google Cloud Distributed Cloud connesso.
- Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
- (Facoltativo) Il valore
machine_iddella macchina Distributed Cloud Connected di destinazione per filtrare i risultati restituiti.
Utilizza Esplora metriche per controllare le versioni software attuali e di destinazione del cluster
Vai a Metrics Explorer:
Nella console Google Cloud , vai alla sezione Monitoring.
Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
Nella pagina Metrics Explorer, vai alla pagina Configurazione.
Fai clic su Seleziona una metrica.
Utilizza la barra di ricerca per cercare il tipo di risorsa Cluster. Puoi anche utilizzare l'identificatore completo della risorsa
edgecontainer.googleapis.com/Cluster.Nei risultati restituiti, fai clic sul tipo di risorsa Cluster.
Ottieni la versione software attuale del cluster:
Nella sezione Metrica, cerca il valore
current_cluster_version.Seleziona la metrica Uptime macchina. Il percorso completo è
edgecontainer.googleapis.com/edge_cluster/current_cluster_version.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.
Ottieni la versione software di destinazione del cluster:
Fai clic su Add Query (Aggiungi query).
Nella sezione Metrica, cerca il valore
target_cluster_version.Seleziona la metrica Versione cluster di destinazione. Il percorso completo è
edgecontainer.googleapis.com/edge_cluster/target_cluster_version.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.
Controlla lo stato dell'upgrade del software del cluster nel grafico visualizzato.
Se le righe Versione cluster attuale e Versione cluster di destinazione indicano valori diversi, il cluster è in fase di upgrade del software.
Se le righe Current Cluster Version e Target Cluster Version 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 regione Google Cloud in cui è stato creato il cluster.
Nell'output del comando, prendi nota dei valori dei seguenti campi:
- Se il valore del campo
statusèUPDATING, è in corso un upgrade del software del cluster. - Se i valori dei campi
clusterVersionetargetVersionsono diversi, confrontali con i valori restituiti da Metrics Explorer.
Comprendere i risultati
La tabella seguente spiega i risultati restituiti da Metrics Explorer e dal comando gcloud.
| Stato del cluster | Diagnosi | Risoluzione |
|---|---|---|
| In stato di integrità I valori currentVersion e targetVersion corrispondonoIl valore "status" è RUNNING |
Il cluster esegue la versione target del software Distributed Cloud connesso. | Nessuno. |
| Upgrading Il valore currentVersion è inferiore a targetVersionIl valore "status" è UPDATING |
È in corso l'upgrade del cluster alla versione di destinazione del software Google Distributed Cloud connesso. | Monitora il cluster in Metrics Explorer finché i valori della versione attuale e di quella di destinazione del cluster non corrispondono. |
| Bloccato Il valore currentVersion è inferiore a targetVersion a tempo indeterminatoIl valore "status" è UPDATING a tempo indeterminato |
L'upgrade alla versione di destinazione del software Distributed Cloud connesso non è riuscito su almeno un nodo del cluster. | Controlla la connettività della macchina e i log di sistema; contatta Google per assistenza. |
| Rollback Il valore currentVersion è superiore a targetVersionIl valore "status" è UPDATING |
Il cluster sta eseguendo il rollback a una versione precedente del software Distributed Cloud connesso. | Contatta Google per identificare il motivo del rollback. |
Se l'upgrade del software sul cluster non è riuscito o se è stato eseguito il rollback del cluster a una versione software precedente, controlla quanto segue:
- Integrità del nodo. Verifica che ogni macchina fisica connessa a Distributed Cloud disponga di connettività di rete e che l'uptime sia segnalato come descritto nella sezione successiva.
- Periodi di manutenzione. Verifica se l'upgrade del 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 per la 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.
Riavvio della macchina Distributed Cloud connessa
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 aiuta a determinare se facevano parte di una manutenzione pianificata o se erano il risultato di un guasto hardware o di un'interruzione di corrente.
Questa procedura utilizza le seguenti metriche di Monitoring:
Uptime della macchina (
/machine/uptime): indica il tempo, in secondi, 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 Google Cloud Distributed Cloud connesso.
- Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
- (Facoltativo) Il valore
machine_iddella 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:
Nella console Google Cloud , vai alla sezione Monitoring.
Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
Nella pagina Metrics Explorer, vai alla pagina Configurazione.
Fai clic su Seleziona una metrica.
Utilizza la barra di ricerca per cercare il tipo di risorsa Machine. Puoi anche utilizzare l'identificatore completo della risorsa
edgecontainer.googleapis.com/Machine.Nei risultati restituiti, fai clic sul tipo di risorsa Macchina.
Controlla l'uptime della macchina:
Nella sezione Metrica, cerca il valore
uptime.Seleziona la metrica Uptime macchina. Il percorso completo è
edgecontainer.googleapis.com/machine/uptime.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.Nel grafico temporale visualizzato, verifica che il grafico di uptime sia in continua crescita. Se in qualsiasi momento il valore di uptime scende a zero e si riavvia, significa che la macchina è stata riavviata.
Controlla il conteggio dei riavvii della macchina:
Nella sezione Metrica, cerca il valore
restart_count.Seleziona la metrica Riavvi della macchina. Il percorso completo è
edgecontainer.googleapis.com/machine/restart_count.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.Nel grafico temporale visualizzato, verifica che la linea del grafico rimanga su
0, il che indica che non si sono verificati riavvii. Se in un qualsiasi momento la linea sale a1, significa che la macchina è stata riavviata. Prendi nota del timestamp esatto del riavvio per un'ulteriore risoluzione dei problemi.(Facoltativo) Per visualizzare i singoli eventi anziché un grafico, vai alla sezione Aggregazione della pagina, imposta il campo Periodo di allineamento su
1 minutee il campo Allineatore per serie su Delta.
Comprendere i risultati
La tabella seguente spiega i risultati restituiti da Metrics Explorer.
| Stato della macchina | Diagnosi | Risoluzione |
|---|---|---|
| Stabile La metrica "Uptime macchina" aumenta costantemente Il delta della metrica "Riavvi macchina" è 0 |
La macchina non è stata riavviata. | Nessuno. |
| Riavvio pulito La metrica "Uptime macchina" scende a 0La metrica "Riavvi macchina" sale a 1 |
La macchina è stata riavviata e si è riconnessa a Google Cloud. | Controlla i log di sistema per determinare il motivo del riavvio. |
| Interruzione di corrente Il grafico della metrica "Uptime macchina" presenta un'interruzione senza dati La metrica "Riavvio macchina" non è cambiata durante l'interruzione dell'uptime macchina |
La macchina ha perso l'alimentazione o la connettività di rete prima di potersi riavviare. | 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" si alterna tra 0 e 1Il valore della metrica "Connettività di rete" si alterna tra 0 e 1 |
Connessione di rete instabile, perdita di pacchetti o latenza eccessiva. | Controlla la rete locale per verificare la presenza di congestione e hardware difettoso. |
Se i passaggi per la 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 a Google Cloud per le tue macchine connesse a Distributed Cloud utilizzando la funzionalità Metrics Explorer di Cloud Monitoring.
Questa procedura utilizza le seguenti metriche di Monitoring:
Macchina connessa (
/machine/connected): indica se la macchina è connessa a Google Cloud.Connettività di rete (
/machine/network/connectivity): indica se l'interfaccia di rete principale della macchina dispone di connessione a internet.
Per completare i passaggi descritti in questa sezione, devi soddisfare i seguenti prerequisiti:
- Accesso alla console Google Cloud e al tuo progetto Google Cloud Distributed Cloud connesso.
- Il ruolo IAM Visualizzatore Monitoring, che consente di visualizzare le metriche di Monitoring.
- (Facoltativo) Il valore
machine_iddella macchina Distributed Cloud Connected di destinazione per filtrare i risultati restituiti.
Utilizza Esplora metriche per controllare la connettività della macchina
Vai a Metrics Explorer:
Nella console Google Cloud , vai alla sezione Monitoring.
Nell'albero di navigazione a sinistra, fai clic su Esplora metriche.
Seleziona il tipo di risorsa di destinazione:
Nella pagina Metrics Explorer, vai alla pagina Query.
Utilizza la barra di ricerca per cercare il tipo di risorsa Machine. Puoi anche utilizzare l'identificatore completo della risorsa
edgecontainer.googleapis.com/Machine.Nei risultati restituiti, fai clic sul tipo di risorsa Macchina.
Controlla la connessione della macchina a Google Cloud:
Nella sezione Metrica, cerca il valore
connected.Seleziona la metrica Machine Connected. Il percorso completo è
edgecontainer.googleapis.com/machine/connected.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.Nel grafico temporale visualizzato, verifica che la linea Integrità rimanga al 100% in modo continuo. Se in un qualsiasi momento questo valore è pari allo 0% o Non integro, la macchina ha perso la connettività con Google Cloud all'ora indicata.
Controlla la connessione a internet della macchina:
Nella sezione Metrica, cerca il valore
connectivity.Seleziona la metrica Connettività di rete. Il percorso completo è
edgecontainer.googleapis.com/machine/network/connectivity.(Facoltativo) Filtra in base al valore
machine_iddi destinazione utilizzando la sezione Filtro.Nel grafico a linee temporali visualizzato, verifica che la linea Integrità rimanga al 100% in modo continuo. Se in un qualsiasi momento questo valore è 0% Non integro, la macchina ha perso la connessione a internet nell'ora indicata.
Comprendere i risultati
La tabella seguente spiega i risultati restituiti da Metrics Explorer.
| Stato della macchina | Diagnosi | Risoluzione |
|---|---|---|
| In stato di integrità Il valore della metrica "Macchina connessa" è 1Il valore della metrica "Connettività di rete" è 1 |
Funzionamento normale. | Nessuno. |
| Disconnesso Il valore della metrica "Macchina connessa" è 0Il valore della metrica "Connettività di rete" è 1 |
La macchina dispone di connessione a 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" è 0Il valore della metrica "Connettività di rete" è 0 |
La macchina non dispone di connessione a internet. | Controlla i cavi di alimentazione e di rete, la configurazione della rete locale e lo stato dell'indicatore LED. Verifica la configurazione della VLAN e del routing. |
| Intermittente Il valore della metrica "Macchina connessa" si alterna tra 0 e 1Il valore della metrica "Connettività di rete" si alterna tra 0 e 1 |
Connessione di rete instabile, perdita di pacchetti o latenza eccessiva. | Controlla la rete locale per verificare la presenza di congestione e hardware difettoso. |
Se noti valori costanti di 0 per una delle due 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 di una macchina virtuale può bloccarsi nello stato Pending e non riuscire a pianificare un nodo se si verifica una delle seguenti condizioni:
- Distributed Cloud Connected non può allocare alla macchina virtuale le risorse richieste, come tempo di CPU, memoria o spazio su disco.
- Si è verificato un errore nella configurazione della macchina virtuale.
- Si è verificato un errore nello spazio di archiviazione della macchina virtuale.
- Il nodo di destinazione è contaminato.
Per risolvere il problema, segui questi passaggi:
Ottieni le credenziali del cluster come descritto in Ottieni le credenziali per un cluster.
Recupera le 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 readyL'output del comando contiene messaggi che potrebbero indicare vincoli delle risorse, errori di pianificazione, errori 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, ad esempio CPU, memoria o spazio su disco. Ad esempio:
5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.
Per risolvere questo problema, controlla le risorse allocate alle macchine virtuali interessate e agli altri workload pianificati sul nodo, quindi procedi come segue in base alle tue 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 è contaminato. 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, segui questi passaggi:
Utilizza il seguente comando 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 i taint imprevisti, rimuovili come descritto in Taint 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 nello 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 non è stato possibile montare il volume permanente corrispondente sul nodo di destinazione.
Per risolvere il problema, segui questi passaggi:
Utilizza il seguente comando per ottenere lo stato delle richieste di volumi permanenti (PVC) nello spazio dei nomi della macchina virtuale interessata:
kubectl get pvc -n NAMESPACE
Sostituisci
NAMESPACEcon 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 26mVerifica che la 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 di configurazione del sottosistema di archiviazione e assicurarti che sia disponibile l'elementoStorageClassappropriato.
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 siano utili per applicare policy di sicurezza personalizzate, i webhook configurati in modo errato possono causare interruzioni a livello di cluster, soprattutto durante operazioni critiche come gli upgrade del software e gli aggiornamenti dei certificati. In particolare, un webhook di ammissione bloccato o non disponibile può bloccare il control plane di Kubernetes, impedendo l'ulteriore pianificazione dei workload sul cluster.
Deadlock del control plane
Un deadlock di dipendenza circolare può verificarsi quando un webhook di ammissione è responsabile della convalida delle risorse necessarie per il recupero del webhook stesso. Ad esempio, se un webhook di ammissione è configurato per convalidare i pod e il pod del webhook deve essere ripianificato durante un upgrade 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 workload.
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. Questo causa i seguenti problemi:
- Upgrade del software non riusciti: non è possibile pianificare i componenti di sistema e le VM durante e dopo un upgrade del software dei nodi.
- I servizi di sistema non possono essere avviati: i pod dell'infrastruttura, come Symcloud Storage e VM Runtime on GDC, non possono essere avviati.
- Nodi bloccati in modalità di manutenzione: non è possibile riconciliare o uscire dai nodi in modalità di manutenzione perché il controller è bloccato dalla logica di 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 impongano 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 gli 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"]
Recupera un cluster bloccato da webhook non riusciti
Se il tuo cluster è stato bloccato da webhook non riusciti e i comandi kubectl per la creazione di risorse scadono o restituiscono errori,
in genere è perché il webhook ha il campo failurePolicy impostato su Fail. Segui i passaggi descritti in questa sezione per ripristinare il cluster dal deadlock. Se il webhook che non funziona è un webhook di mutazione, utilizza mutatingwebhookconfiguration anziché validatingwebhookconfiguration.
Identifica i webhook con errori:
Elenca i webhook di convalida di cui è stato eseguito il deployment nel cluster:
kubectl get validatingwebhookconfigurations
Elenca i webhook mutanti di cui è stato eseguito il deployment nel cluster:
kubectl get mutatingwebhookconfigurations
Verifica se i pod che supportano i webhook sono in esecuzione:
kubectl get pods -A | grep WEBHOOK_SERVICE
Sostituisci
WEBHOOK_SERVICEcon il nome del servizio del webhook di destinazione.Imposta il campo
failurePolicydel webhook non riuscito suIgnore:kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \ --type='json' \ -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'Sostituisci
WEBHOOK_SERVICEcon il nome del servizio del webhook di destinazione.(Facoltativo) Se il passaggio precedente non è riuscito, forza l'eliminazione della configurazione del webhook interessato:
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
Sostituisci
WEBHOOK_CONFIGcon il nome della configurazione del webhook di destinazione.
Dopo aver modificato o forzato l'eliminazione della configurazione del webhook, il server API Kubernetes riprende l'elaborazione delle richieste, risolvendo il deadlock e consentendo il completamento dei processi bloccati.