Supporto di proxy HTTP nel servizio Azure Kubernetes

Articolo
10/31/2024

Questo articolo illustra come configurare i cluster del servizio Azure Kubernetes per l'utilizzo di un proxy HTTP per l'accesso a Internet in uscita.

I cluster del servizio Azure Kubernetes distribuiti in reti virtuali gestite o personalizzate hanno determinate dipendenze in uscita necessarie per funzionare correttamente, creando problemi negli ambienti che richiedono l'indirizzamento dell'accesso a Internet tramite proxy HTTP. Non era possibile per i nodi eseguire il bootstrap della configurazione, delle variabili di ambiente e dei certificati necessari per accedere ai servizi Internet.

Questa funzionalità proxy HTTP aggiunge il supporto del proxy HTTP ai cluster del servizio Azure Kubernetes, fornendo un'interfaccia semplice con cui è possibile possono assicurare il traffico di rete richiesto dal servizio Azure Kubernetes in ambienti in cui l'accesso a internet dipende da proxy. Con questa funzionalità, sia i nodi del servizio Azure Kubernetes che i pod sono configurati per l'uso del proxy HTTP. La funzionalità abilita anche l'installazione di un'autorità di certificazione attendibile nei nodi come parte del bootstrap di un cluster. Soluzioni più complesse potrebbero richiedere la creazione di una catena di certificati volta a stabilire comunicazioni sicure nella rete.

Limitazioni e considerazioni

Non sono supportati gli scenari seguenti:

Diverse configurazioni proxy per pool di nodi
Autenticazione Utente/Password
Autorità di certificazione personalizzate (CA) per la comunicazione del server API
La configurazione di cluster del servizio Azure Kubernetes esistenti con un proxy HTTP non è supportata, la funzionalità proxy HTTP deve essere abilitata al momento della creazione del cluster.
Cluster di Windows
Pool di nodi che usano set di disponibilità delle macchine virtuali (VMAS)
Uso di * come carattere jolly collegato a un’estensione di dominio per noProxy

httpProxy, httpsProxy e trustedCa non hanno alcun valore per impostazione predefinita. I pod vengono inseriti con le seguenti variabili di ambiente:

HTTP_PROXY
http_proxy
HTTPS_PROXY
https_proxy
NO_PROXY
no_proxy

Per disabilitare l'inserimento delle variabili di ambiente proxy, è necessario annotare il pod con "kubernetes.azure.com/no-http-proxy-vars":"true".

Operazioni preliminari

È necessaria la versione più recente dell'interfaccia della riga di comando di Azure. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
Per assicurarsi di eseguire la versione più recente del servizio Azure Kubernetes, verificare la disponibilità di aggiornamenti del cluster del servizio Azure Kubernetes. Se è necessario eseguire l'aggiornamento, vedere Aggiornare un cluster del servizio Azure Kubernetes.
I file del sistema operativo necessari per gli aggiornamenti della configurazione proxy possono essere aggiornati solo durante il processo di aggiornamento dell'immagine del nodo. Dopo aver configurato il proxy, è necessario aggiornare l'immagine del nodo per applicare le modifiche. Per maggiori informazioni, vedere Aggiornare le immagini dei nodi del servizio Azure Kubernetes.

Configurare un proxy HTTP tramite l'interfaccia della riga di comando di Azure

È possibile configurare un cluster del servizio Azure Kubernetes con un proxy HTTP durante la creazione del cluster usando il comando az aks create e passando la configurazione come file JSON.

Lo schema per il file di configurazione è simile al seguente:

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}

httpProxy: URL proxy da usare per la creazione di connessioni HTTP all'esterno del cluster. Lo schema URL deve essere http.
httpsProxy: URL proxy da usare per la creazione di connessioni HTTPS all'esterno del cluster. Se non è specificato, httpProxy è usato sia per connessioni HTTP che HTTPS.
noProxy: elenco di nomi di dominio di destinazione, domini, indirizzi IP o altri CIDR di rete per escludere i proxy.
trustedCa: stringa che include il contenuto alternativo del certificato della CA base64 encoded. Attualmente, solo il formato PEM è supportato.

Importante

Per garantire la compatibilità con i componenti basati su Go che fanno parte del sistema Kubernetes, il certificato deve supportare Subject Alternative Names(SANs) anziché i certificati Common Name deprecati.

Le applicazioni differiscono su come rispettare le variabili di ambiente http_proxy, https_proxy e no_proxy. Curl e Python non supportano CIDR in no_proxy, mentre Ruby lo supporta.

Input di esempio:

Nota

Il certificato della CA deve essere la stringa con codifica base64 del contenuto del certificato in formato PEM.

{
  "httpProxy": "http://myproxy.server.com:8080/", 
  "httpsProxy": "https://myproxy.server.com:8080/", 
  "noProxy": [
    "localhost",
    "127.0.0.1"
  ],
  "trustedCA": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0F3SUJB...b3Rpbk15RGszaWFyCkYxMFlscWNPbWVYMXVGbUtiZGkvWG9yR2xrQ29NRjNURHg4cm1wOURCaUIvCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="
}

Creare un file e specificare i valori per httpProxy, httpsProxy e noProxy. Se l'ambiente lo richiede, specificare un valore per trustedCa. Successivamente, è possibile distribuire il cluster usando il comando az aks create con il parametro --http-proxy-config impostato sul file creato. Il cluster deve inizializzarsi con il proxy HTTP configurato nei nodi.

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --http-proxy-config aks-proxy-config.json \
    --generate-ssh-keys

Configurare un proxy HTTP tramite modello di Azure Resource Manager (ARM)

È possibile distribuire un cluster del servizio Azure Kubernetes con un proxy HTTP usando un modello di Resource Manager. Lo stesso schema usato per la distribuzione dell'interfaccia della riga di comando esiste nella definizione Microsoft.ContainerService/managedClusters in "properties", come illustrato nell'esempio seguente:

"properties": {
    ...,
    "httpProxyConfig": {
        "httpProxy": "string",
        "httpsProxy": "string",
        "noProxy": [
            "string"
        ],
        "trustedCa": "string"
    }
}

Nel modello, specificare i valori per httpProxy, httpsProxy e noProxy. Se necessario, specificare un valore per trustedCa. Successivamente, è possibile distribuire il modello. Il cluster deve essere inizializzato con il proxy HTTP configurato nei nodi.

Proxy HTTP del componente aggiuntivo Istio per i servizi esterni

Se si usa il componente aggiuntivo Mesh di servizi basato su Istio per il servizio Azure Kubernetes, è necessario creare una voce di servizio per consentire alle applicazioni nella mesh di accedere a risorse non cluster o esterne tramite il proxy HTTP. Ad esempio:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: proxy
spec:
  hosts:
  - my-company-proxy.com # ignored
  addresses:
  - $PROXY_IP/32
  ports:
  - number: $PROXY_PORT
    name: tcp
    protocol: TCP
  location: MESH_EXTERNAL

Creare un file e specificare i valori per PROXY_IP e PROXY_PORT. È possibile distribuire la voce di servizio usando

kubectl apply -f service_proxy.yaml

Aggiornare la configurazione del proxy

Nota

Se si passa a un nuovo proxy, è necessario che il nuovo proxy sia già esistente affinché l'aggiornamento venga completato correttamente. Al termine dell'aggiornamento, è possibile eliminare il proxy precedente.

Si può aggiornare la configurazione del proxy nel cluster usando il comando az aks update con il parametro --http-proxy-config impostato su un nuovo file JSON con valori aggiornati per httpProxy, httpsProxy, noProxy e trustedCa, se necessario. L'aggiornamento inserisce nuove variabili di ambiente nei pod con i nuovi valori httpProxy, httpsProxy o noProxy. Affinché le app rilevino l'aggiornamento, i pod devono essere ruotati, poiché i valori delle variabili di ambiente vengono inseriti da un webhook di ammissione mutevole. Per componenti di Kubernetes, come contenitori e il nodo stesso, questa operazione non è effettiva fino a quando non verrà eseguito un aggiornamento dell'immagine del nodo.

Si supponga, ad esempio, di aver creato un nuovo file con la stringa con codifica base64 del nuovo certificato CA denominato aks-proxy-config-2.json. È possibile aggiornare la configurazione del proxy nel cluster con il comando seguente:

az aks update --name $clusterName --resource-group $resourceGroup --http-proxy-config aks-proxy-config-2.json

Aggiornare le immagini dei nodi del servizio Azure Kubernetes

Dopo aver configurato il proxy, è necessario aggiornare l'immagine del nodo per applicare le modifiche. Il processo di aggiornamento dell'immagine del nodo è l'unico modo per aggiornare i file del sistema operativo necessari per gli aggiornamenti della configurazione del proxy. Il processo di aggiornamento dell'immagine del nodo è un aggiornamento in sequenza che aggiorna l'immagine del sistema operativo in ciascun nodo del pool di nodi. Il piano di controllo del servizio Azure Kubernetes gestisce il processo di aggiornamento, che non comporta interruzioni per le applicazioni in esecuzione.

Per aggiornare le immagini dei nodi del servizio Azure Kubernetes, vedere Aggiornare le immagini dei nodi del servizio Azure Kubernetes.

Configurazione del componente aggiuntivo di Monitoraggio

Il proxy HTTP con componente aggiuntivo monitoraggio supporta le seguenti configurazioni:

Proxy in uscita senza autenticazione
Proxy in uscita con autenticazione nome utente e password
Proxy in uscita con certificato attendibile per l'endpoint di Log Analytics

Le seguenti configurazioni non sono supportate:

Metriche personalizzate e funzionalità di avviso consigliate quando si usa un proxy con certificati attendibili

Passaggi successivi

Per ulteriori informazioni sui requisiti di rete dei cluster del servizio Azure Kubernetes, consultare Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes.

Condividi tramite