Impostare le variabili d'ambiente del proxy in un Pod Kubernetes

Inserite le variabili proxy HTTP supportate nella specifica del container Kubernetes e mantenete le route dirette del cluster separate dalla configurazione del download delle immagini.

Un comando sul nodo Kubernetes può usare un proxy della shell mentre un Pod su quel nodo non ha alcun ambiente proxy. L'ambiente del container è definito dalla sua immagine e dalla configurazione del Pod.

Per un'applicazione che supporta queste variabili, aggiungete un elenco env alla voce del container esistente:

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

In un Deployment questo va sotto il container pertinente in spec.template.spec.containers. Aggiornate il carico di lavoro tramite il suo normale rollout in modo che i nuovi Pod lo ricevano. Fornite anche nomi in minuscolo quando il client reale li richiede.

L'elenco di esclusione è un'illustrazione iniziale, non un inventario di ogni route del cluster. Usate il suffisso DNS reale del cluster e le destinazioni interne. Le applicazioni che usano IP di servizio potrebbero aver bisogno degli intervalli di servizio reali in una sintassi supportata dal loro client.

I container di inizializzazione hanno le proprie specifiche di container. Aggiungete lì la configurazione prevista quando eseguono un download esterno. Per i download HTTP pubblici, un endpoint dalla lista di proxy HTTP è un candidato per questi valori di ambiente del container.

Il download delle immagini avviene prima dell'esecuzione dell'applicazione ed è eseguito dal runtime dei container del nodo. L'ambiente del Pod non può configurare quella precedente connessione al registry.

Infine, le variabili proxy HTTP influenzano solo i client che le utilizzano. Non reindirizzano traffico arbitrario di database, UDP o altri socket dal Pod.

Articoli correlati