Kubeadm: ¿De dónde toma kubeadm la configuración del proxy?

@erikbgithub ¡ Muchas gracias por este número!
Desde el principio, debo decir que no soy un experto en proxy, ya que no he experimentado mucho en esos entornos.

Así que no puedo comentar sobre las declaraciones exactas anteriores, pero me alegraría mucho si quisiera contribuir a kubeadm para mejorar el comportamiento detrás de un proxy.

Para responder a su pregunta, aquí está el código de go relevante:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/controlplane/manifests.go#L432

func getProxyEnvVars() []v1.EnvVar {
    envs := []v1.EnvVar{}
    for _, env := range os.Environ() {
        pos := strings.Index(env, "=")
        if pos == -1 {
            // malformed environment variable, skip it.
            continue
        }
        name := env[:pos]
        value := env[pos+1:]
        if strings.HasSuffix(strings.ToLower(name), "_proxy") && value != "" {
            envVar := v1.EnvVar{Name: name, Value: value}
            envs = append(envs, envVar)
        }
    }
    return envs
}

https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/preflight/checks.go#L291

// HTTPProxyCheck checks if https connection to specific host is going
// to be done directly or over proxy. If proxy detected, it will return warning.
type HTTPProxyCheck struct {
    Proto string
    Host  string
    Port  int
}

func (hst HTTPProxyCheck) Check() (warnings, errors []error) {

    url := fmt.Sprintf("%s://%s:%d", hst.Proto, hst.Host, hst.Port)

    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return nil, []error{err}
    }

    proxy, err := http.DefaultTransport.(*http.Transport).Proxy(req)
    if err != nil {
        return nil, []error{err}
    }
    if proxy != nil {
        return []error{fmt.Errorf("Connection to %q uses proxy %q. If that is not intended, adjust your proxy settings", url, proxy)}, nil
    }
    return nil, nil
}

En serio, no puedo expresar cuántas horas de trabajo ahorraría a las personas en las redes empresariales.

No podría estar más de acuerdo

cc @kad @timothysc

@luxas Gracias. Trabajaré en eso cuando tenga un tuit redondo. Sin embargo, antes de que pueda suministrar parches, necesito aprender algunos, por lo que agradecería que otros puedan participar por ahora. ;-)

La primera subpregunta que analizaré es lo que realmente obtiene go a través de os.Environ() .

@erikbgithub Avísame si necesitas ayuda para crear parches y te ayudaré

@erikbgithub como autor original de ese cheque, estaré encantado de responder cualquier pregunta.
Primeras respuestas:

• kubeadm obtiene y comprueba el entorno de la sesión que se está ejecutando actualmente. Puede ver lo que tiene si ejecuta $ env | grep -i _proxy= | sort . Por ejemplo, dentro del firewall de nuestra empresa tengo algo como esto:
  !shell $ env | grep -i _proxy= | sort ALL_PROXY=http://proxy-ir.example.com:911 FTP_PROXY=http://proxy-ir.example.com:911 HTTPS_PROXY=http://proxy-ir.example.com:911 HTTP_PROXY=http://proxy-ir.example.com:911 NO_PROXY=.example.com all_proxy=http://proxy-ir.example.com:911 ftp_proxy=http://proxy-ir.example.com:911 http_proxy=http://proxy-ir.example.com:911 https_proxy=http://proxy-ir.example.com:911 no_proxy=.example.com $
• Problema habitual en el que la gente pisa sin darse cuenta, que la variable no_proxy NO admite rangos de red. por lo que poner algo como NO_PROXY=10.0.0.0/8, 192.168.0.0/16 no tendrá ningún efecto y seguirá produciendo una advertencia en la verificación previa al vuelo.
• La diferencia de contenido entre las variables * _proxy mayúsculas / minúsculas no importa. El código de Go que maneja las variables de entorno de proxy tiene su lógica interna en el orden en que lo procesa (como recuerdo, primero en mayúsculas, luego en minúsculas, pero eso no debería importar, no puede garantizar en qué orden cada aplicación las procesa)
• archivos como / etc / environment son específicos de la distribución y no los lee cada binario individual. se leen e inyectan en las variables de entorno del proceso mediante scripts de inicio de sesión, módulos PAM, etc. Las variables de entorno también pueden provenir de, por ejemplo, sesiones SSH o de herramientas de gestión externas (como ansible) mientras se llaman a otros binarios, como kubeadm. Por lo tanto, depender de un entorno / etc / particular o similar no es factible ni lógico.
• Para 8 puntos, la verificación previa al vuelo se trata específicamente de eso. Da una advertencia si kubeadm detecta que está pasando del proxy al servidor API. Si bien inicialmente se discutió sobre esta verificación previa al vuelo, se acordó que esos casos podrían ser legítimos, por lo que solo advierte , no produce errores.
• para 10: también hubo objeciones sobre la manipulación de esas variables de varias personas. (Mi idea inicial era eliminar todas las configuraciones de * _proxy para forzar conexiones directas, pero fue rechazada, ya que podrían ser razones legítimas para conectarse a través de proxies).

"Solucioné" este problema al incluir todas las direcciones IP de los nodos de mi clúster en NO_PROXY y usar el mismo NO_PROXY en todos los minions al unirme al clúster.

$ export NO_PROXY = 'ip, ip, ip, ip, .example.com'
[maestro] $ kubeadm init
[minion] $ kubeadm unirse --token = {token} abcd: 6443

Para ser honesto, no estoy seguro de si fueron todas las direcciones IP enumeradas o el .example.com lo que solucionó el problema.

si PR kubernetes / kubernetes # 52788 se fusionará, será posible especificar en los rangos de IP NO_PROXY para sus nodos. simplificará mucho las cosas.

Un poco cansado. si miro el código "checks.go".
siempre devuelve un mensaje de error si hay valor en el proxy.

if proxy! = nil {
return [] error {fmt.Errorf ("La conexión a% q usa el proxy% q. Si no es así, ajusta la configuración del proxy", url, proxy)}, nil
}
retorno nulo, nulo

En la empresa ... hay necesariamente tres opciones de proxy. (http_proxy, https_proxy, no_proxy)
http_ * es una opción obligatoria para extraer imágenes para la conexión a Internet.
si se establece la opción no_proxy ... entonces debería devolver un mensaje de error.

"pl, configure la opción (no_proxy) para que no se enrute al proxy para la conexión interna"

Quiero preguntar si kubeadm join es compatible con http_proxy.

Me las arreglo para que kubeadm init funcione con http_proxy y no_proxy, pero parece que kubeadm join produce errores como

kubelet.go:2105] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

remote_runtime.go:92] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed pulling image "gcr.io/google_containers/pause-amd64:3.0": Get https://gcr.io/v1/_ping: read tcp <my-ip>:58742->74.125.68.82:443: read: connection reset by peer

y también
/ etc / environment está vacío en lugar de estar lleno de configuración como en el maestro.

lo que me permite creer que tal vez http_proxy y no_proxy aún no sean compatibles con kubeadm join.

Me encontré con este problema una vez más. Todavía usa el proxy incorrectamente y parece que no puedo modificar la configuración del proxy y no_proxy.

ver # 687, # 182, o desbordamiento de pila: https://stackoverflow.com/questions/45580788/how-to-install-kubernetes-cluster-behind-proxy-with-kubeadm

Desde mi experiencia, kubeadm usa el proxy definido en / etc / environment

Desde mi experiencia, kubeadm usa el proxy definido en / etc / environment

Sí, en mi caso también es / etc / environment