Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi relativi ai webhook Google Distributed Cloud

Questa pagina mostra come risolvere i problemi relativi a webhook problematici o non sicuri in Google Distributed Cloud.

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 Google Distributed Cloud 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 che funzionano, ma senza endpoint disponibili. Segui le istruzioni per controllare i webhook senza endpoint disponibili.
Webhook che sono considerati non sicuri poiché operano su risorse critiche del sistema e spazi dei nomi.

I seguenti webhook sono considerati non sicuri:
- Webhook che intercettano pod e lease nello spazio dei nomi kube-system.
- Webhook che intercettano i lease nello spazio dei nomi kube-node-lease.
- Webhook che intercettano le risorse Nodes, TokenReviews, SubjectAccessReviews e CertificateSigningRequests.
Segui le istruzioni per controllare i webhook considerati non sicuri.

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:

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.
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.

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.
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