I webhook di ammissione, o webhook in Kubernetes, sono un tipo di controller di ammissione, che può essere utilizzato nei cluster Kubernetes per convalidare o modificare le richieste al piano di controllo prima che una richiesta venga resa persistente. È comune che le applicazioni di terze parti utilizzino webhook che operano su risorse e spazi dei nomi critici per il sistema. I webhook configurati in modo errato possono
influire sulle prestazioni e sull'affidabilità del piano di controllo. Ad esempio, un webhook configurato in modo errato creato da un'applicazione di terze parti potrebbe impedire a GKE di creare e modificare le risorse nello spazio dei nomi kube-system
gestito, con conseguente riduzione della funzionalità del cluster.
Google Kubernetes Engine (GKE) monitora i cluster e utilizza il servizio del motore per suggerimenti per fornire indicazioni su come ottimizzare l'utilizzo della piattaforma. Per assicurarti che il cluster rimanga stabile ed efficiente, consulta i suggerimenti di GKE per gli scenari seguenti:
- Webhook che funzionano, ma per cui non sono disponibili endpoint.
- Webhook considerati non sicuri in quanto operano su risorse e spazi dei nomi critici del sistema.
Con questa guida, puoi visualizzare le istruzioni su come verificare i webhook potenzialmente configurati in modo errato e aggiornarli, se necessario.
Per scoprire di più su come gestire gli insight e i suggerimenti dei motori per suggerimenti, consulta Ottimizzare l'utilizzo di GKE con insight e suggerimenti.
Identifica i webhook configurati in modo errato che potrebbero influire sul cluster
Per ottenere insight che identificano i webhook che potrebbero influire sulle prestazioni e sulla stabilità del cluster, segui le istruzioni per visualizzare insight e suggerimenti. Puoi ottenere approfondimenti nei seguenti modi:
- Utilizzare la console Google Cloud.
- Utilizza Google Cloud CLI, o l'API Recommender, filtrando con i sottotipi
K8S_ADMISSION_WEBHOOK_UNSAFE
eK8S_ADMISSION_WEBHOOK_UNAVAILABLE
.
Dopo aver identificato i webhook tramite gli insight, segui le istruzioni per risolvere i problemi dei webhook rilevati.
Quando GKE rileva webhook configurati in modo errato
GKE genera un insight e un suggerimento se uno dei seguenti criteri è vero per un cluster:
K8S_ADMISSION_WEBHOOK_UNAVAILABLE
: il cluster GKE ha uno o più webhook che non segnalano endpoint disponibili. Segui le istruzioni per controllare che i webhook non segnalino endpoint disponibili.K8S_ADMISSION_WEBHOOK_UNSAFE
: il cluster GKE ha uno o più webhook considerati non sicuri in base alle risorse che intercettano. Segui le istruzioni per controllare i webhook considerati non sicuri. I seguenti webhook sono considerati non sicuri:- Webhook che intercettano risorse, inclusi pod e Lease, nello spazio dei nomi
kube-system
. - Webhook che intercettano i lease nello spazio dei nomi
kube-node-lease
. - Webhook che intercettano risorse di sistema con ambito cluster, tra cui
Nodes
,TokenReviews
,SubjectAccessReviews
eCertificateSigningRequests
.
- Webhook che intercettano risorse, inclusi pod e Lease, nello spazio dei nomi
Risolvi i problemi relativi ai webhook rilevati
Le seguenti sezioni contengono le istruzioni per risolvere i problemi relativi ai webhook che GKE ha rilevato come potenzialmente configurati in modo errato.
Dopo aver implementato le istruzioni e aver configurato correttamente i webhook, il suggerimento viene risolto entro 24 ore e non viene più visualizzato nella console. Se sono trascorse meno di 24 ore dall'implementazione delle indicazioni del suggerimento, puoi contrassegnarlo come risolto. Se non vuoi implementare il consiglio, puoi ignorarlo.
Webhook che segnalano nessun endpoint disponibile
Se un webhook segnala che non ha endpoint disponibili, il servizio che supporta l'endpoint webhook dispone di uno o più pod non in esecuzione. Per rendere disponibili gli endpoint webhook, segui le istruzioni per trovare e risolvere i problemi dei pod del servizio che supportano questo endpoint webhook:
Visualizza approfondimenti e suggerimenti, scegliendo un approfondimento alla volta per la risoluzione dei problemi. GKE genera un insight per cluster e questo insight elenca uno o più webhook con un endpoint inaccessibile che deve essere esaminato. Per ognuno di questi webhook, il report indica anche il nome del servizio, quale endpoint non funziona e l'ultima volta che l'endpoint è stato chiamato.
Trova i pod di gestione per il servizio associato al webhook:
Console
Nel riquadro della barra laterale degli insight, visualizza la tabella dei webhook configurati in modo errato. Fai clic sul nome del servizio.
kubectl
Esegui questo comando per descrivere il servizio:
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
Sostituisci SERVICE_NAME e SERVICE_NAMESPACE con rispettivamente il nome e lo spazio dei nomi del servizio.
Se non riesci a trovare il nome del servizio nell'elenco del webhook, l'endpoint non disponibile potrebbe essere causato da una mancata corrispondenza tra il nome elencato nella configurazione e il nome effettivo del servizio. Per correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione webhook in modo che corrisponda all'oggetto Service corretto.
Ispeziona i pod di gestione per questo servizio:
Console
In Pod in uso in Dettagli servizio, visualizza l'elenco dei pod che supportano questo servizio.
kubectl
Identifica quali pod non sono in esecuzione elencando i deployment o i pod:
kubectl get deployment -n SERVICE_NAMESPACE
In alternativa, esegui questo comando:
kubectl get pods -n SERVICE_NAMESPACE -o wide
Per tutti i pod non in esecuzione, esamina i log dei pod per capire perché il pod non è in esecuzione. Per istruzioni sui problemi comuni relativi ai pod, consulta Risoluzione dei problemi relativi ai carichi di lavoro di cui è stato eseguito il deployment.
Webhook considerati non sicuri
Se un webhook intercetta le risorse negli spazi dei nomi gestiti dal sistema o determinati tipi di risorse, GKE lo considera non sicuro e consiglia di aggiornare i webhook per evitare di intercettare queste risorse.
- Segui le istruzioni per visualizzare approfondimenti e consigli, scegliendo un approfondimento alla volta per la risoluzione dei problemi. GKE genera un solo insight per cluster e questo insight elenca una o più configurazioni di webhook, ciascuna delle quali elenca uno o più webhook. Per ogni configurazione di webhook elencata, l'insight indica il motivo per cui la configurazione è stata segnalata.
Esamina la configurazione del webhook:
Console
Nel riquadro della barra laterale degli approfondimenti, visualizza la tabella. In ogni riga è riportato il nome della configurazione webhook e il motivo per cui questa configurazione è stata segnalata.
Per esaminare ogni configurazione, fai clic sul nome per passare a questa configurazione nella dashboard del browser oggetti di GKE.
kubectl
Esegui questo comando
kubectl
per ottenere la configurazione webhook, sostituendo CONFIGURATION_NAME con il nome della configurazione webhook:kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
Se il comando non restituisce nulla, eseguilo di nuovo, sostituendo
validatingwebhookconfigurations
conmutatingwebhookconfigurations
.Nella sezione
webhooks
sono elencati uno o più webhook.Modifica la configurazione, a seconda del motivo per cui il webhook è stato segnalato:
Escludi gli spazi dei nomi kube-system e kube-node-lease
Un webhook viene contrassegnato se
scope
è*
. In alternativa, un webhook viene segnalato se l'ambito èNamespaced
e una delle seguenti condizioni è vera:La condizione
operator
èNotIn
evalues
omettekube-system
ekube-node-lease
, come nell'esempio seguente:webhooks: - admissionReviewVersions: ... namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - blue-system objectSelector: {} rules: - apiGroups: ... scope: '*' sideEffects: None timeoutSeconds: 3
Assicurati di impostare
scope
suNamespaced
, non su*
, in modo che il webhook funzioni solo in spazi dei nomi specifici. Inoltre, assicurati che, seoperator
èNotIn
, includikube-system
ekube-node-lease
invalues
(in questo esempio, conblue-system
).La condizione
operator
èIn
evalues
includekube-system
ekube-node-lease
, come nell'esempio seguente:namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - blue-system - kube-system - kube-node-lease
Assicurati di impostare
scope
suNamespaced
, non su*
, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati che seoperator
èIn
, non includerekube-system
ekube-node-lease
invalues
. In questo esempio, soloblue-system
deve essere invalues
poichéoperator
èIn
.
Escludi risorse corrispondenti
Un webhook viene contrassegnato anche se
nodes
,tokenreviews
,subjectaccessreviews
ocertificatesigningrequests
sono elencati nelle risorse, come nell'esempio seguente:- admissionReviewVersions: ... resources: - 'pods' - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3
Rimuovi
nodes
,tokenreviews
,subjectaccessreviews
ecertificatesigningrequests
dalla sezione delle risorse. Puoi conservarepods
inresources
.