Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei 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 sia persistente. È comune per le applicazioni di terze parti utilizzare 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 risorse nello spazio dei nomi kube-system gestito, con conseguente peggioramento della funzionalità del cluster.

I webhook problematici includono i seguenti tipi:

Webhook che funzionano, ma non hanno endpoint disponibili. Segui le istruzioni per verificare i webhook senza endpoint disponibili.
I webhook considerati non sicuri perché operano su risorse e spazi dei nomi critici del sistema.

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 che non hanno endpoint disponibili

Se un webhook non ha endpoint disponibili, il servizio che esegue il backup dell'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 dei pod del servizio su cui si basa questo endpoint webhook:

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 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 correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione del webhook in modo che corrisponda all'oggetto di servizio corretto.
Esaminare i pod di gestione per questo servizio. Identifica quali pod non sono in esecuzione elencando 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
```
Nel caso di pod non in esecuzione, controlla i log dei pod per capire perché non è in esecuzione.

Webhook considerati non sicuri

Se un webhook intercetta risorse negli spazi dei nomi gestiti dal sistema, ti consigliamo di aggiornare i webhook 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 del 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 sono 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 nella sezione Risorse sono elencati nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests, 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