Usar un Secret existente para las variables de proxy en un chart de Helm
Referencie URL de proxy completas desde un Secret en la plantilla de Deployment de Helm 3 en lugar de suponer que una variable de shell se convierte en el entorno del contenedor.
Suponga que el espacio de nombres de la versión ya tiene un Secret llamado app-outbound-proxy. Sus claves http_proxy y https_proxy contienen las URL de proxy completas que necesita la aplicación.
Un chart de Helm 3 puede conservar solo el nombre de ese Secret en values.yaml:
outboundProxy:
existingSecret: app-outbound-proxy
En la plantilla de Deployment del contenedor previsto, haga referencia a las claves:
env:
- name: HTTP_PROXY
valueFrom:
secretKeyRef:
name: {{ .Values.outboundProxy.existingSecret | quote }}
key: http_proxy
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: {{ .Values.outboundProxy.existingSecret | quote }}
key: https_proxy
Esto es un fragmento de la especificación del contenedor. El Secret debe existir en el espacio de nombres del Pod y contener ambas claves referenciadas. Sus valores deben usar el protocolo, el host y el puerto del listener de proxy real. Para las solicitudes públicas de la aplicación a las que se permite usar un proxy público sin autenticación, construya esas URL a partir de un candidato adecuado de la lista de proxies gratuitos; conserve las excepciones directas que sean necesarias.
El valor del chart aporta un nombre; secretKeyRef aporta los valores de entorno del contenedor. Exportar HTTP_PROXY en el shell que ejecuta helm no añade por sí solo esta sección env a una plantilla de Pod.
Cambiar el Secret también es un cambio de ciclo de vida
Un contenedor no actualiza su entorno cuando cambian los datos del Secret. Organice el reinicio o el rollout previsto para que los contenedores recién iniciados reciban los valores actualizados. Cambiar los datos bajo el mismo nombre de Secret no edita por sí mismo la plantilla de Pod del Deployment.
La aplicación debe admitir las variables de entorno de proxy elegidas. El acceso al repositorio de Helm y la descarga de la imagen en el nodo son consumidores separados que se ejecutan antes de que este entorno del contenedor pueda ayudarlos.