Convalidare i controller di ammissione

Questo articolo fa parte di una serie. Iniziare con la panoramica.

I controller di ammissione raramente causano problemi, ma è fondamentale garantire la propria funzionalità. Questo articolo illustra come i controller di ammissione possono influire sugli altri componenti quando non funzionano correttamente. Descrive anche i comandi che è possibile usare per convalidare le prestazioni del controller di ammissione.

Controller di ammissione

Un controller di ammissione è un frammento di codice che intercetta le richieste a un server API Kubernetes prima della persistenza di un oggetto, ma dopo l'autenticazione e l'autorizzazione di una richiesta.

I controller di ammissione possono convalidare, modificare o una combinazione di entrambi. I controller di modifica possono modificare gli oggetti correlati prima di ammettere una richiesta. La convalida dei controller garantisce esclusivamente che le richieste soddisfino criteri predefiniti specifici.

Una delle funzioni principali dei controller di ammissione consiste nel regolare le richieste di creazione, eliminazione e modifica di oggetti. Inoltre, i controller di ammissione possono limitare verbi personalizzati, ad esempio la richiesta di una connessione a un pod tramite un proxy del server API. Tuttavia, i controller di ammissione non possono bloccare le richieste di lettura di oggetti, incluse operazioni come get, watcho list.

Alcuni componenti possono influire sui controller di ammissione, ad esempio la modifica e la convalida dei webhook. Quando si incorporano la modifica e la convalida dei webhook nel cluster Kubernetes, è fondamentale garantire la disponibilità elevata. I nodi non integri non devono bloccare le richieste del server API. È fondamentale monitorare la pipeline di controllo di ammissione in modo che le richieste al server API non vengano bloccate. I controller di ammissione non integri possono influire sulla modifica e sulla convalida dei webhook. I controller di ammissione basati su webhook da monitorare includono:

• Componente aggiuntivo Criteri di Azure per i cluster servizio Azure Kubernetes (AKS), che estende Gatekeeper. Gatekeeper è un webhook del controller di ammissione per Open Policy Agent.

• Kyverno, che viene eseguito come controller di ammissione dinamico in un cluster Kubernetes. Kyverno riceve la convalida e la modifica dei callback HTTP del webhook di ammissione dal server API Kubernetes e applica i criteri di corrispondenza per restituire risultati che applicano criteri di ammissione o rifiutano le richieste. Per informazioni di riferimento sulla risoluzione dei problemi (ad esempio , chiamate webhook non riuscite di APIServer), vedere la documentazione sulla risoluzione dei problemi di Kyverno.

In alternativa, i controller di ammissione che non funzionano correttamente possono influire su vari componenti, ad esempio mesh di servizi. Le mesh di servizi, ad esempio Istio e Linkerd, usano i controller di ammissione per automatizzare l'inserimento di contenitori sidecar all'interno di un pod, tra le altre funzionalità. È importante valutare e verificare che i controller di ammissione funzionino correttamente per garantire il funzionamento trasparente di una mesh di servizi.

Controllare lo stato del componente aggiuntivo Criteri di Azure per i cluster del servizio Azure Kubernetes

Se si installa il componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes, è possibile usare i comandi kubectl seguenti per convalidare l'installazione e la funzionalità di Criteri di Azure controller di ammissione nel cluster:

# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system

# Sample output
...
NAME                                     READY   STATUS    RESTARTS   AGE
gatekeeper-audit-65844778cb-rkflg        1/1     Running   0          163m
gatekeeper-controller-78797d4687-4pf6w   1/1     Running   0          163m
gatekeeper-controller-78797d4687-splzh   1/1     Running   0          163m
...

Eseguire il comando precedente per verificare la disponibilità dei pod dell'agente Criteri di Azure nello spazio dei nomi gatekeeper-system. Se l'output non è quello previsto, potrebbe indicare un problema con un controller di ammissione, un servizio API o una definizione di risorsa personalizzata.If the output isn't what you expect, it might indicate an issue with an admission controller, API service, or custom resource definition (CRD).

# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources

# Sample output
...
NAME                                     SHORTNAMES    APIGROUP                       NAMESPACED   KIND
bindings                                                                              true         Binding
componentstatuses                        cs                                           false        ComponentStatus
configmaps                               cm                                           true         ConfigMap
...

Il comando precedente consente di verificare che tutte le risorse API funzionino correttamente. Assicurarsi che l'output includa le risorse previste senza errori o componenti mancanti. Usare i kubectl get pod comandi e kubectl api-resources per controllare lo stato del componente aggiuntivo Criteri di Azure per il servizio Azure Kubernetes e convalidare la funzionalità dei controller di ammissione nel cluster Kubernetes. Monitorare regolarmente i controller di ammissione per assicurarsi che funzionino correttamente in modo da poter mantenere l'integrità e la stabilità complessive del cluster.

Usare il comando seguente kubectl get per verificare che le assegnazioni di criteri vengano applicate al cluster:

kubectl get constrainttemplates

Nota

Le assegnazioni di criteri possono richiedere fino a 20 minuti per la sincronizzazione con ogni cluster.

L'output dovrebbe essere simile all'esempio seguente:

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Per ulteriori informazioni, vedi le seguenti risorse:

• Proteggere i cluster del servizio Azure Kubernetes con Criteri di Azure
• Criteri di Azure definizioni predefinite per il servizio Azure Kubernetes

Convalidare i webhook

Per assicurarsi che la convalida e la modifica dei webhook funzionino come previsto nel cluster Kubernetes, seguire questa procedura.

1. Eseguire il comando seguente per elencare i webhook di convalida nel cluster:

   kubectl get ValidatingWebhookConfiguration -o wide
   

   L'output dovrebbe essere simile all'esempio seguente:

   NAME                         WEBHOOKS   AGE
   aks-node-validating-webhook   1          249d
   azure-policy-validating-webhook-configuration   1          249d
   gatekeeper-validating-webhook-configuration     1          249d
   

   Esaminare l'output per verificare che i webhook di convalida siano presenti e che le relative configurazioni siano come previsto. L'output include il nome di ogni webhook di convalida, il numero di webhook e l'età di ogni webhook.

2. Eseguire il comando seguente per elencare i webhook mutevoli nel cluster:

   kubectl get MutatingWebhookConfiguration -o wide
   

   L'output dovrebbe essere simile all'esempio seguente:

   NAME                         WEBHOOKS   AGE
   aks-node-mutating-webhook    1          249d
   azure-policy-mutating-webhook-configuration    1          249d
   gatekeeper-mutating-webhook-configuration      1          249d
   

   Controllare l'output per assicurarsi che i webhook mutevoli siano elencati correttamente e che le relative configurazioni siano quelle desiderate. L'output include il nome di ogni webhook modificante, il numero di webhook e l'età di ogni webhook.

3. Eseguire il comando seguente per recuperare dettagli specifici per un particolare controller di ammissione:

   kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml
   

   Sostituire <mutating-webhook-name> con il nome del webhook di modifica per cui si desidera recuperare i dettagli. L'output di questo comando visualizza la rappresentazione YAML della configurazione del webhook modificante specificata.

Eseguire i comandi in questa sezione ed esaminare l'output in modo da poter verificare che i webhook di convalida e modifica nel cluster Kubernetes siano presenti e configurati come previsto. Questa convalida è essenziale per garantire il corretto funzionamento. È anche importante assicurarsi che i webhook rispettino i criteri per la convalida e la modifica delle risorse nel cluster.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Paolo Salvatori | Principal Customer Engineer

Altri contributori:

• Francesco Simy Nazareth | Senior Technical Specialist

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Risorse correlate

Verificare la connessione al registro contenitori