Assicurati la stabilità del piano di controllo quando utilizzi i webhook

I webhook di ammissione, o webhooks in Kubernetes, sono un tipo di ammissione un controller, che può essere utilizzato nei cluster Kubernetes per convalidare o modificare le richieste di controllo prima della persistenza di una richiesta. È normale 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 sul piano di controllo le prestazioni e l'affidabilità. 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, il che potrebbe ridurre la funzionalità del cluster.

Google Kubernetes Engine (GKE) monitora i cluster e utilizza Servizio di motore per suggerimenti per fornire indicazioni su come ottimizzare l'uso della piattaforma. Per aiutarti ad assicurarti che il tuo cluster rimanga stabile e con un buon rendimento, consulta i consigli di GKE per i seguenti scenari:

  • Webhook che funzionano, ma non hanno endpoint disponibili.
  • Webhook considerati non sicuri perché operano su elementi critici per il sistema di risorse e spazi dei nomi.

Con queste indicazioni, puoi visualizzare le istruzioni su come controllare il tuo potenziale webhook configurati in modo errato e, se necessario, aggiornali.

Per scoprire di più su come gestire gli approfondimenti e i consigli di Recommenders, consulta l'articolo Ottimizzare l'utilizzo di GKE con approfondimenti e consigli.

Identificare i webhook configurati in modo errato che potrebbero influire sul cluster

Per ottenere insight che identificano i webhook che potrebbero influire sulla configurazione rendimento e stabilità, segui le istruzioni per visualizzare approfondimenti e personalizzati. Puoi ottenere approfondimenti nei seguenti modi:

  • Utilizza la console Google Cloud.
  • Utilizza Google Cloud CLI o l'API Recommender, filtrando con i sottotipi K8S_ADMISSION_WEBHOOK_UNSAFE e K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Dopo aver identificato i webhook tramite gli approfondimenti, segui le istruzioni per risolvere i problemi relativi ai webhook rilevati.

Quando GKE rileva webhook configurati in modo errato

GKE genera un'informazione e un consiglio se uno dei seguenti criteri è vero per un cluster:

Risolvere i problemi relativi ai webhook rilevati

Le sezioni seguenti forniscono istruzioni per la risoluzione dei problemi relativi ai webhook rilevati da GKE come potenzialmente configurati in modo errato.

Dopo aver implementato le istruzioni e aver configurato correttamente i webhook, il consiglio viene risolto entro 24 ore e non compare più Google Cloud. Se sono trascorse meno di 24 ore dall'implementazione delle indicazioni del consiglio, puoi contrassegnarlo come risolto. Se non vuoi implementare il consiglio, puoi ignorarlo.

Webhook che non segnalano endpoint disponibili

Se un webhook segnala che non ha endpoint disponibili, il servizio che supporta l'endpoint dell'webhook ha uno o più pod non in esecuzione. A per rendere disponibili gli endpoint webhook, segui le istruzioni per trovare Risolvi i problemi dei pod del servizio che supportano questo endpoint webhook:

  1. Visualizza approfondimenti e consigli, scegliendo un approfondimento alla volta per la risoluzione dei problemi. GKE genera un insight per cluster, che elenca uno o più webhook con un endpoint danneggiato che deve essere esaminato. Per ciascuno di questi webhook, l'approfondimento indica anche il nome del servizio, l'endpoint non funzionante e l'ultima volta che l'endpoint è stato chiamato.

  2. Trova i pod di gestione per il servizio associato al webhook:

    Console

    Nel riquadro della barra laterale degli insight, consulta la tabella dei webhook configurati in modo errato. Fai clic sul nome del servizio.

    kubectl

    Esegui il seguente comando per descrivere il servizio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Sostituisci SERVICE_NAME e SERVICE_NAMESPACE con il nome e lo spazio dei nomi del servizio, rispettivamente.

    Se non riesci a trovare il nome del servizio elencato nel webhook, significa che causata da una mancata corrispondenza tra il nome elencato configurazione e il nome effettivo del servizio. Per correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione dell'webhook in modo che corrisponda all'oggetto Service corretto.

  3. Controlla i pod di pubblicazione per questo servizio:

    Console

    In Pod in pubblicazione in Dettagli servizio, consulta l'elenco dei pod a supporto di questo Servizio.

    kubectl

    Identifica quali pod non sono in esecuzione elencando il deployment o i pod:

    kubectl get deployment -n SERVICE_NAMESPACE

    In alternativa, esegui questo comando:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Per i pod non in esecuzione, controlla i relativi log per capire perché non sono in esecuzione. Per istruzioni sui problemi comuni relativi ai pod, consulta Risolvere i problemi relativi ai carichi di lavoro di cui è stato eseguito il deployment.

Webhook considerati non sicuri

Se un webhook intercetta 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.

  1. Segui le istruzioni per visualizzare approfondimenti e consigli, scegliendo un approfondimento alla volta per la risoluzione dei problemi. Solo GKE genera un insight per cluster, che elenca uno o più webhook configurazioni, ciascuno dei quali elenca uno o più webhook. Per ogni configurazione webhook elencata, l'approfondimento indica il motivo per cui la configurazione è stata segnalata.

  2. Controlla la configurazione dell'webhook:

    Console

    Visualizza la tabella nel riquadro della barra laterale dell'approfondimento. In ogni riga è riportato il nome della configurazione del webhook e il motivo per cui è stata segnalata.

    Per ispezionare ogni configurazione, fai clic sul nome per accedere a questa configurazione. nel cluster GKE Browser oggetti Fitbit.com.

    kubectl

    Esegui questo comando kubectl per ottenere la configurazione del webhook, sostituendo CONFIGURATION_NAME con il nome del configurazione webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Se questo comando non restituisce alcun risultato, eseguilo di nuovo, sostituendo validatingwebhookconfigurations con mutatingwebhookconfigurations.

    Nella sezione webhooks sono elencati uno o più webhook.

  3. 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 segnalato se scope è *. In alternativa, un webhook viene segnalato se l'ambito è Namespaced e una delle seguenti condizioni è vera:

    • La condizione operator è NotIn e values omette kube-system e kube-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 su Namespaced, non su *, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati inoltre che, se operator è NotIn, includi kube-system e kube-node-lease in values (in questo esempio, con blue-system).

    • La condizione operator è In e values include kube-system e kube-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 su Namespaced, non su *, in modo che il webhook operi solo in spazi dei nomi specifici. Assicurati che, se operator è In, non includi kube-system e kube-node-lease in values. In questo ad esempio, solo blue-system deve essere in values perché operator è In.

    Escludi risorse corrispondenti

    Un webhook viene segnalato anche nei seguenti casi: nodes, tokenreviews, subjectaccessreviews, o certificatesigningrequests sono elencati nella sezione Risorse, come nell'esempio seguente:

    - admissionReviewVersions:
...
  resources:
  - 'pods'
  - 'nodes'
  - 'tokenreviews'
  - 'subjectacessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

    Rimuovi nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests dalla sezione delle risorse. Puoi conservare pods in resources.

Passaggi successivi