Garantire la stabilità del control plane quando si utilizzano webhook

I webhook di ammissione, o webhook in Kubernetes, sono un tipo di controller di ammissione, che possono essere utilizzati nei cluster Kubernetes per convalidare o modificare le richieste al control plane 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 control plane. 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 il servizio Recommender per fornire indicazioni su come ottimizzare l'utilizzo della piattaforma. Per assicurarti che il cluster rimanga stabile e performante, consulta i consigli di GKE per i seguenti scenari:

  • Webhook che funzionano, ma non hanno endpoint disponibili.
  • Webhook considerati non sicuri perché operano su risorse e spazi dei nomi fondamentali del sistema.

Con queste indicazioni, puoi visualizzare le istruzioni su come controllare i webhook potenzialmente configurati in modo errato e aggiornarli, se necessario.

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

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

Per ottenere approfondimenti che identificano i webhook che potrebbero influire sulle prestazioni e sulla stabilità del cluster, segui le istruzioni per visualizzare approfondimenti e consigli. 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 approfondimento e un consiglio se per un cluster è vero uno dei seguenti criteri:

Risolvere i problemi relativi ai webhook rilevati

Le seguenti sezioni contengono istruzioni per risolvere i problemi relativi agli webhook che GKE ha rilevato come potenzialmente configurati in modo errato.

Dopo aver implementato le istruzioni e configurato correttamente i webhook, il consiglio viene risolto entro 24 ore e non viene più visualizzato nella console.

Se non vuoi implementare il consiglio, puoi ignorarlo.

Webhook che non segnalano endpoint disponibili

Se un webhook segnala di non avere endpoint disponibili, il servizio che supporta l'endpoint webhook ha uno o più pod che non sono in esecuzione. Per rendere disponibili gli endpoint webhook, segui le istruzioni per trovare e risolvere i problemi relativi ai pod del servizio che supporta questo endpoint webhook:

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

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

    Console

    Nel riquadro della barra laterale dell'approfondimento, 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 il nome e lo spazio dei nomi del servizio, rispettivamente.

    Se non riesci a trovare il nome del servizio elencato nel 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 risolvere il problema di disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione del webhook in modo che corrisponda all'oggetto servizio corretto.

  3. Ispeziona i pod di pubblicazione per questo servizio:

    Console

    Nella sezione Pod di pubblicazione in Dettagli servizio, visualizza l'elenco dei pod che supportano questo servizio.

    kubectl

    Identifica i pod che 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 tutti i pod non in esecuzione, controlla i log per scoprire perché il pod non è in esecuzione. Per istruzioni sui problemi comuni relativi ai pod, vedi Risoluzione dei problemi relativi ai workload di cui è stato eseguito il deployment.

Webhook considerati non sicuri

Se un webhook intercetta risorse in spazi dei nomi gestiti dal sistema o determinati tipi di risorse, GKE lo considera non sicuro e ti 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 risolvere il problema. GKE genera un solo insight per cluster e questo insight elenca una o più configurazioni webhook, ognuna delle quali elenca uno o più webhook. Per ogni configurazione webhook elencata, l'approfondimento indica il motivo per cui la configurazione è stata segnalata.

  2. Esamina la configurazione del webhook:

    Console

    Nel riquadro della barra laterale dell'approfondimento, visualizza la tabella. Ogni riga contiene il nome della configurazione del webhook e il motivo per cui questa configurazione è stata contrassegnata.

    Per esaminare ogni configurazione, fai clic sul nome per passare a questa configurazione nel dashboard Esplora oggetti di GKE.

    kubectl

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

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Se questo comando non restituisce nulla, 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 contrassegnato se scope è *. In alternativa, un webhook viene segnalato se l'ambito è Namespaced e si verifica una delle seguenti condizioni:

    • 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 e 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 nel seguente esempio:

      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 esempio, solo blue-system deve trovarsi in values, poiché operator è In.

    Escludi risorse corrispondenti

    Un webhook viene segnalato anche se nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests sono elencati nelle risorse, come nell'esempio seguente:

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

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

Webhook che bloccano componenti critici del sistema

I webhook che intercettano le richieste di creazione o aggiornamento di ClusterRoles e ClusterRoleBindings possono interferire con la capacità del control plane di riconciliare queste risorse di sistema critiche. Ad esempio, durante l'upgrade di un cluster, il kube-apiserver potrebbe dover aggiornare i propri ruoli di sistema. Se un webhook non disponibile o configurato in modo errato blocca questo aggiornamento, kube-apiserver non diventerà integro, il che bloccherà l'upgrade del cluster.

GKE non rileva se i webhook intercettano ClusterRoles e ClusterRoleBindings, quindi non viene generato alcun approfondimento per questo scenario.

L'esempio seguente mostra una configurazione webhook problematica che intercetta ClusterRoles:

-   admissionReviewVersions:
  ...
  resources:
  -   'clusterroles'
  -   'clusterrolebindings'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

Per evitare questa situazione, assicurati che i webhook non intercettino le richieste per ClusterRoles e ClusterRoleBindings che hanno l'impostazione system: prefix.

Deadlock di ammissione

Quando un webhook è configurato per l'esito negativo, può creare una situazione in cui il cluster non può essere recuperato automaticamente. Ad esempio, se tutti i nodi di un cluster vengono eliminati, anche il webhook non sarà disponibile. Poiché l'aggiunta di un nuovo nodo richiede la convalida dell'ammissione, il webhook deve essere disponibile per approvare la richiesta. In questo modo si crea una dipendenza ciclica che può impedire il ripristino del control plane del cluster.

GKE non rileva scenari di deadlock di ammissione, quindi non viene generato alcun approfondimento per questo scenario. Tuttavia, potrebbe verificarsi un deadlock di ammissione se i pod webhook non sono attivi, nel qual caso GKE rileva che il webhook non ha endpoint disponibili e genera un approfondimento K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Per risolvere il problema, puoi eliminare ValidatingWebhookConfiguration per interrompere la dipendenza circolare e consentire il ripristino del cluster.

Disponibilità del control plane del cluster

Quando un webhook è configurato per il fail-close, la disponibilità del control plane Kubernetes dipende dalla disponibilità del webhook. Per migliorare la disponibilità del control plane, valuta quanto segue:

GKE non rileva problemi di disponibilità del control plane del cluster causati dai webhook, pertanto non viene generato alcun insight per questo scenario.

  • Limita l'ambito del webhook:puoi esentare le risorse critiche dalla convalida da parte del webhook per impedire che interferisca con i processi sensibili. Puoi esentare spazi dei nomi o tipi specifici di risorse. Tuttavia, tieni presente le dipendenze non ovvie. Ad esempio, un ConfigMap può essere una risorsa fondamentale per la selezione del leader in Kubernetes.

  • Rafforzare il deployment del webhook:l'esecuzione del webhook in più pod può aumentarne la resilienza e il tempo di attività. Puoi utilizzare i selettori di nodi per distribuire i pod in diversi domini di errore.

Passaggi successivi