Accesso al master del cluster con i controllori di ammissione e i webhook
I controller di ammissione intercettano le richieste API autorizzate da diverse risorse Kubernetes prima che le richieste raggiungano il server API che viene eseguito nel tuo master cluster IBM Cloud Kubernetes Service. I webhook di ammissione di variazione potrebbero modificare la richiesta e i webhook di ammissione di convalida controllano la richiesta. Se uno dei webhook rifiuta una richiesta, l'intera richiesta ha esito negativo. Le funzioni avanzate, siano esse integrate o aggiunte, spesso richiedono dei controller di ammissione come precauzione di sicurezza e per controllare quali richieste vengono inviate al server API. Per ulteriori informazioni, vedere Using Admission Controllers e Dynamic Admission Control nella documentazione di Kubernetes.
Quali sono i controllori di ammissione predefiniti nel mio cluster?
Riesamina l'ordine dei controller di ammissione predefiniti per versione cluster nelle informazioni di riferimento del componente kube-apiserver
.
Posso creare i miei controllori di ammissione?
Sì, vedere la documentazione di Kubernetes per maggiori 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?
Quando si configura un webhook, tenere presente le seguenti best practice e considerazioni.
- 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 smette di funzionare, il webhook può comunque elaborare le richieste da altre 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 ilfailurePolicy
suIgnore
se vuoi che il tuo webhook ignori gli errori di connessione e i timeout. Tieni presente che ciò non modifica il modo in cuiapiserver
si comporta se il webhook rifiuta una richiesta. - Esaminare l'intervallo
timeoutSeconds
. I webhook precedenti che utilizzano l'APIv1beta1.admissionregistration.k8s.io
hanno un valore di timeout predefinito di 30 secondi. L'APIv1
utilizza un valore predefinito di 10 secondi. Se la politica di errore webhook è Ignora e iltimeoutSeconds
corrente è 30, ridurre il timeout a 10 secondi. - Imposta limiti o richieste di risorsa di CPU e memoria per il tuo webhook.
- Aggiungi analisi di attività e disponibilità per poter verificare più agevolmente che il tuo contenitore webhook sia in esecuzione e pronto a soddisfare le richieste.
- Imposta le regole di pianificazione dell'anti-affinità del pod per preferire che i tuoi pod webhook vengano eseguiti su nodi di lavoro e zone differenti, quando possibile. Potresti utilizzare invece la topologia pod. Tuttavia, evitare taints o affinità forzate che potrebbero limitare la pianificazione dei pod webhook.
- Impostare la priorità dei pod a
system-cluster-critical
per i pod webhook, in modo che altri pod non possano prendere risorse dai pod webhook. - Definisci l'ambito del tuo webhook allo spazio dei nomi appropriato. Evitare webhook che elaborano risorse che girano in spazi dei nomi critici per il sistema che sono impostati nel cluster per impostazione predefinita, come gli spazi dei
nomi
kube-system
,ibm-system
,ibm-operators
,calico-apiserver
,calico-system
,tigera-operator
eopenshift-*
. - Esaminare l'opzione
namespaceSelector
. Puoi aggiungere etichette a determinati spazi dei nomi critici, comekube-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'opzionenamespaceSelector
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 dinamespaceSelector
nella documentazione diKubernetes e modifica la tua configurazione webhook. - Assicurarsi che i nodi worker del cluster siano delle dimensioni corrette per l'esecuzione delle 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 applicazioni utilizzano i controllori di ammissione?
Molti componenti aggiuntivi del cluster, plug-in e altre estensioni di terze parti utilizzano i controllori di ammissione. Alcuni controller più comuni includono:
Impostazione dei webhook del controller di ammissione
Nelle versioni cluster 1.21 e successive, Konnectivity ha sostituito la soluzione OpenVPN. Se si dispone della versione del cluster 1.21 e successive e il webhook utilizza il servizio ClusterIP, è necessario aggiornare il webhook per utilizzare invece un servizio Kubernetes.
Puoi configurare un webhook facendo riferimento all'applicazione webhook come un servizio Kubernetes o facendo riferimento all'applicazione webhook come un indirizzo IP o un nome DNS registrato pubblicamente.
Configurazione di esempio per il riferimento all'applicazione webhook come un servizio Kubernetes
clientConfig:
caBundle: #CA_BUNDLE_BASE64#
service:
name: admission-webhook
namespace: default
path: /validate
port: 443
Configurazione di esempio per fare riferimento all'applicazione webhook come un indirizzo IP o un nome DNS registrato pubblicamente
clientConfig:
caBundle: #CA_BUNDLE_BASE64#
url: https://#WEBHOOK_URL#:443/validate
Tieni presente le seguenti limitazioni per il riferimento all'applicazione webhook come un indirizzo IP o un nome DNS:
- Se l'URL è un DNS, questo DNS deve essere un nome DNS registrato pubblicamente. Le configurazioni DNS private non sono supportate.
- Se l'URL è un indirizzo IP esterno, il che significa che il servizio webhook è esterno al cluster, la rete del piano di controllo viene utilizzata per connettersi al servizio. Il piano di controllo deve essere in grado di raggiungere l'indirizzo IP. Se, ad esempio, l'indirizzo IP proviene da una rete installata in loco e il piano di controllo non può raggiungere l'indirizzo IP, il servizio webhook non funziona.
- Se l'URL è un indirizzo IP del cluster, il che significa che il servizio webhook si trova all'interno del cluster, l'API Kubernetes deve connettersi alla rete del cluster. Se disponi di un cluster versione 1.21 e successive e il tuo webhook utilizza l'indirizzo IP del cluster, devi aggiornare il tuo webhook per utilizzare invece un servizio Kubernetes.
Ho bisogno di aiuto per un webhook non funzionante. 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.