Un comando no nodo de Kubernetes pode usar un proxy de shell mentres que un Pod nese nodo non ten ningún contorno de proxy. O contorno do contedor defíneno a súa imaxe e a configuración do Pod.

Para unha aplicación que admite estas variables, engada unha lista env á súa entrada de contedor existente:

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

Nun Deployment, isto vai baixo o contedor correspondente en spec.template.spec.containers. Actualice a carga de traballo mediante o seu despregamento habitual para que os Pods novos o reciban. Proporcione tamén nomes en minúsculas cando o cliente real os requira.

A lista de omisión é unha ilustración inicial, non un inventario de todas as rutas do clúster. Use o sufixo DNS real do clúster e os destinos internos. As aplicacións que usan IP de servizo poden necesitar os rangos de servizo reais nunha sintaxe que admita o seu cliente.

Os contedores de inicialización teñen as súas propias especificacións de contedor. Engada alí a configuración prevista cando realicen unha descarga externa. Para descargas HTTP públicas, un punto de conexión da lista de proxies HTTP é un candidato para estes valores de contorno do contedor.

A descarga de imaxes ocorre antes de que se execute a aplicación e realízaa o runtime de contedores do nodo. O contorno do Pod non pode configurar esa conexión anterior co rexistro.

Por último, as variables de proxy HTTP só afectan os clientes que as consomen. Non redirixen o tráfico arbitrario de bases de datos, UDP ou outros sockets desde o Pod.

Artigos relacionados