Risolvere i problemi relativi ai webhook di GKE su Azure

Questa pagina mostra come risolvere i problemi relativi a webhook problematici o non sicuri in GKE su Azure.

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

Tipi di webhook problematici

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 su Azure di creare e modificare le risorse nello spazio dei nomi kube-system gestito, il che potrebbe ridurre la funzionalità del cluster.

I webhook problematici includono i seguenti tipi:

Webhook senza endpoint disponibili

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

  1. Trova i pod di gestione per il servizio associato al webhook. Esegui questo comando per descrivere il servizio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
    

    Sostituisci quanto segue:

    • SERVICE_NAME con il nome del Servizio.
    • SERVICE_NAMESPACE con il nome dello spazio dei nomi.

    Se non riesci a trovare il nome del servizio in elenco 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 correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione webhook in modo che corrisponda all'oggetto Service corretto.

  2. Esaminare i pod di gestione per questo servizio. Identifica quali pod non sono in esecuzione indicando il deployment:

    kubectl get deployment -n SERVICE_NAMESPACE
    

    In alternativa, esegui questo comando per elencare i pod:

    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.

Webhook considerati non sicuri

Se un webhook intercetta le risorse negli spazi dei nomi gestiti dal sistema, ti consigliamo di aggiornarli per evitare di intercettare queste risorse.

  1. Esamina la configurazione del webhook. Esegui questo comando kubectl per ottenere la configurazione del webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
    

    Sostituisci CONFIGURATION_NAME con il nome della configurazione webhook.

    Se il comando non restituisce nulla, eseguilo di nuovo, sostituendo validatingwebhookconfigurations con mutatingwebhookconfigurations.

    Nella sezione webhooks dell'output sono elencati uno o più webhook.

  2. Modifica la configurazione, a seconda del motivo per cui il webhook è considerato non sicuro:

    Escludi gli spazi dei nomi kube-system e kube-node-lease

    Un webhook è considerato non sicuro se scope è * o 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 # add 'kube-system' and 'kube-node-lease' if `NotIn`
        objectSelector: {}
        rules:
        - apiGroups:
          ...
          scope: '*' # 'Namespaced'
        sideEffects: None
        timeoutSeconds: 3
      

      Assicurati che scope sia impostato su Namespaced, non su *, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati che se operator è NotIn, kube-system e kube-node-lease siano inclusi in values.

    • 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 # remove as operator is `In`
            - kube-node-lease # remove as operator is `In`
      

      Assicurati che scope sia impostato su Namespaced, non su *, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati che se operator è In, kube-system e kube-node-lease non siano inclusi in values.

    Escludi risorse corrispondenti

    Un webhook è considerato non sicuro anche se nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests sono elencati nelle risorse, come nell'esempio seguente:

    - admissionReviewVersions:
    ...
        resources:
        - 'pods' # keep, remove everything else
        - 'nodes'
        - 'tokenreviews'
        - 'subjectacessreviews'
        - 'certificatesigningrequests'
        scope: '*'
      sideEffects: None
      timeoutSeconds: 3
    

    Rimuovi nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests dalla sezione delle risorse.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.