Posso creare i miei controller di ammissione?

Sì, consulta la documentazione Kubernetes e Red Hat OpenShift per ulteriori informazioni.

Come indicato nella documentazione di Kubernetes, puoi utilizzare i controller di ammissione per operazioni gestite altrimenti dal piano di controllo. Pertanto, presta molta attenzione quando configuri un controller di ammissione personalizzato. Sei responsabile di eventuali modifiche che si verificano nel cluster a causa di un controller di ammissione personalizzato.

Quali sono le migliori pratiche per l'utilizzo dei webhook?

Evita di usare i webhook quando puoi. Utilizza invece e MutatingAdmissionPolicyValidatingAdmissionPolicy (quando abilitato per impostazione predefinita) come alternative.

Se devi utilizzare i webhook, tieni presente le seguenti best practice e considerazioni quando configuri un webhook.

• Non utilizzare webhook di mutazione per mutare risorse di proprietà di un altro controllore o operatore. Ciò potrebbe causare un ciclo di riconciliazione infinito tra il proprietario della risorsa e il webhook. I webhook possono determinare la proprietà della risorsa controllando se metadata.ownerReferences è impostato nei dati della risorsa. Ad esempio, una risorsa replicaset Kubernetes è di proprietà di una risorsa di distribuzione Kubernetes e non deve mai essere modificata da un webhook.

• Crea dei pod di replica per il webhook in modo che se un pod si disattiva, il webhook può comunque elaborare le richieste dalle tue risorse. Se possibile, estendi i pod di replica tra le zone.

• Imposta un'opzione failurePolicy appropriata, ad esempio se il tuo webhook ha esito negativo o se ignora gli errori di connessione o i timeout. Puoi impostare il failurePolicy su Ignore se vuoi che il tuo webhook ignori gli errori di connessione e i timeout. Tieni presente che ciò non modifica il modo in cui apiserver si comporta se il webhook rifiuta una richiesta.

• Esaminare l'intervallo timeoutSeconds. I webhook precedenti che utilizzano l'API v1beta1.admissionregistration.k8s.io hanno un valore di timeout predefinito di 30 secondi. L'API v1 utilizza un valore predefinito di 10 secondi. Se la politica di errore webhook è Ignora e il timeoutSeconds corrente è 30, ridurre il timeout a 10 secondi. Per i cluster OpenShift, i componenti del piano di controllo spesso hanno il proprio timeout di 13 secondi.

  Evita di consentire a più webhook mutanti di operare sulle stesse risorse. I webhook mutanti vengono eseguiti in sequenza. Un singolo webhook mutante potrebbe funzionare come previsto dal punto di vista dei timeout e delle politiche di errore, ma se combinato con altri webhook mutanti che operano sulla stessa risorsa, i webhook mutanti potrebbero superare il timeout totale concesso per l'esecuzione di tutti i webhook.

• Imposta richieste e limiti di risorse CPU e memoria appropriati per il tuo webhook.

• Aggiungi dei test di attività e di prontezza per assicurarti che il tuo container webhook sia in esecuzione e pronto a gestire le richieste.

• Imposta le regole di pianificazione di anti-affinità dei pod per preferire che i pod del webhook vengano eseguiti su nodi di lavoro e zone differenti quando possibile. Potresti utilizzare invece la topologia pod. Tuttavia, è bene evitare contaminazioni o affinità forzate che potrebbero limitare i luoghi in cui è possibile pianificare i pod dei webhook.

• Imposta la priorità dei pod su “ system-cluster-critical ” per i pod dei webhook, in modo che gli altri pod non possano sottrarre risorse ai tuoi pod dei webhook.

• Delimita l'ambito del tuo webhook al progetto appropriato. Evita di utilizzare webhook che elaborano risorse in esecuzione all’interno di progetti critici per il sistema configurati di default nel tuo cluster, quali i progetti kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator e openshift-*.

• Esaminare l'opzione namespaceSelector. Puoi aggiungere etichette a determinati spazi dei nomi critici, come kube-system, in modo che il webhook non venga richiamato per questi casi. Questa configurazione è chiamata configurazione di stile "opt out". In alternativa, puoi configurare l'opzione namespaceSelector in modo che il webhook venga richiamato solo per gli spazi dei nomi che hanno una specifica etichetta. Questa configurazione è chiamata configurazione "opt - in". A seconda dello scopo del webhook, potrebbe essere importante che il webhook venga richiamato per tutti gli spazi dei nomi. Esamina le opzioni di configurazione di namespaceSelector nella documentazione diKubernetes e modifica la tua configurazione webhook.

• Assicurati che i nodi di lavoro del tuo cluster abbiano le dimensioni adeguate per l'esecuzione delle tue applicazioni webhook. Ad esempio, se i tuoi pod richiedono più CPU o memoria di quella fornita dal nodo di lavoro, i pod non vengono pianificati.

Quali altri tipi di app utilizzano i controller di accesso?

Molti componenti aggiuntivi per cluster, plug-in e altre estensioni di terze parti utilizzano i controller di ammissione. Alcuni controller più comuni includono:

• Portieris

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

Ho bisogno di aiuto per risolvere un problema con un webhook che non funziona. Quali operazioni posso eseguire?

Per assistenza nella risoluzione dei problemi dei webhook, vedi Debug dei webhook o Il cluster non può eseguire l'aggiornamento a causa di un webhook interrotto.