Partekatu honen bidez:

Compatibilidad del proxy HTTP en Azure Kubernetes Service (AKS)

  • Artikulua

En este artículo, aprenderá a configurar clústeres de Azure Kubernetes Service (AKS) para usar un proxy HTTP para el acceso saliente a Internet.

Los clústeres de AKS implementados en redes virtuales administradas o personalizadas tienen determinadas dependencias salientes necesarias para funcionar correctamente, lo que creaba problemas en entornos que requieren acceso a Internet para enrutarse a través de proxies HTTP. Los nodos no tenían ninguna manera de arrancar la configuración, las variables de entorno y los certificados necesarios para acceder a los servicios de Internet.

La característica proxy HTTP agrega compatibilidad con el proxy HTTP a los clústeres de AKS y expone una interfaz sencilla que puede usar para proteger el tráfico de red requerido por AKS en entornos dependientes del proxy. Con esta característica, los nodos y pods de AKS están configurados para usar el proxy HTTP. La característica también permite la instalación de una entidad de certificación de confianza en los nodos como parte del arranque de un clúster. Es posible que las soluciones más complejas requieran la creación de una cadena de confianza para establecer comunicaciones protegidas a través de la red.

Limitaciones y consideraciones

Los siguientes escenarios no son compatibles:

  • Diferentes configuraciones de proxy por grupo de nodos
  • Autenticación de contraseña/usuario
  • Entidades de certificación (CA) personalizadas para la comunicación del servidor de API
  • No se admite la configuración de clústeres de AKS existentes con un proxy HTTP; la característica de proxy HTTP debe estar habilitada en el momento de crear el clúster.
  • Clústeres basados en Windows
  • Grupos de nodos que usan conjuntos de disponibilidad de máquinas virtuales (VMAS)
  • Uso de * como carácter comodín adjunto a un sufijo de dominio para noProxy

httpProxy, httpsProxy y trustedCa no tienen ningún valor de forma predeterminada. Los pods se insertan con las siguientes variables de entorno:

  • HTTP_PROXY
  • http_proxy
  • HTTPS_PROXY
  • https_proxy
  • NO_PROXY
  • no_proxy

Para deshabilitar la inserción de las variables de entorno de proxy, debe anotar el pod con "kubernetes.azure.com/no-http-proxy-vars":"true".

Antes de empezar

Configurar un proxy HTTP mediante la CLI de Azure

Puede configurar un clúster de AKS con un proxy HTTP durante la creación del clúster mediante el comando az aks create y pasar la configuración como un archivo JSON.

El esquema del archivo de configuración tiene el siguiente aspecto:

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}
  • httpProxy: dirección URL de proxy que se usará para crear conexiones HTTP fuera del clúster. El esquema de dirección URL debe ser http.
  • httpsProxy: dirección URL de proxy que se usará para crear conexiones HTTPS fuera del clúster. Si no se especifica, se usa httpProxy para las conexiones HTTP y HTTPS.
  • noProxy: lista de nombres de dominio de destino, dominios, direcciones IP u otros CIDR de red para excluir el proxy.
  • trustedCa: cadena que contiene el contenido del certificado de entidad de certificación alternativo base64 encoded. Actualmente solo se admite el formato PEM.

Importante

Para lograr compatibilidad con los componentes basados en Go que forman parte del sistema Kubernetes, el certificado debe admitir Subject Alternative Names(SANs), en lugar de los certificados de nombre común en desuso.

Hay diferencias en las aplicaciones sobre cómo cumplir con la variable de entorno http_proxy, https_proxy y no_proxy. Curl y Python no admiten CIDR en no_proxy, pero Ruby sí.

Entrada de ejemplo:

Nota

El certificado de CA debe ser la cadena codificada en Base64 del contenido del certificado de formato PEM.

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

Cree un archivo y proporcione valores para httpProxy, httpsProxy y noProxy. Si el entorno lo requiere, especifique un valor para trustedCa. A continuación, puede implementar el clúster mediante el comando az aks create con el parámetro --http-proxy-config establecido en el archivo que creó. El clúster debe inicializarse con el proxy HTTP configurado en los nodos.

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

Configurar un proxy HTTP mediante una plantilla de Azure Resource Manager (ARM)

Puede implementar un clúster de AKS con un proxy HTTP mediante una plantilla de ARM. El mismo esquema usado para la implementación de la CLI existe en la definición Microsoft.ContainerService/managedClusters en "properties", como se muestra en el ejemplo siguiente:

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

En la plantilla, proporcione valores para httpProxy, httpsProxy y noProxy. Si fuera necesario, especifique también un valor para trustedCa. A continuación, puede implementar la plantilla. El clúster debe inicializarse con el proxy HTTP configurado en los nodos.

Proxy HTTP del complemento Istio para servicios externos

Si usa el complemento de malla de servicio basado en Istio para AKS, debe crear una entrada de servicio para permitir que las aplicaciones de la malla accedan a recursos ajenos al clúster o externos a través del proxy HTTP. Por ejemplo:

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

Cree un archivo y proporcione valores para PROXY_IP y PROXY_PORT. Puede implementar la entrada de servicio mediante

kubectl apply -f service_proxy.yaml

Actualizar configuración del proxy

Nota:

Si cambia a un nuevo proxy, el nuevo proxy ya debe existir para que la actualización se realice correctamente. Una vez completada la actualización, puede eliminar el proxy anterior.

Puede actualizar la configuración de proxy en el clúster mediante el comando az aks update con el parámetro --http-proxy-config establecido en un nuevo archivo JSON con valores actualizados para httpProxy, httpsProxy, noProxy y trustedCa si es necesario. La actualización inserta nuevas variables de entorno en pods con los nuevos valores httpProxy, httpsProxy o noProxy. Los pods deben girarse para que las aplicaciones lo detecten, porque los valores de las variables de entorno los inyecta un webhook de admisión mutante. En el caso de los componentes de Kubernetes, como containerd y el propio nodo, esto no tiene efecto hasta que se realice una actualización de la imagen del nodo.

Por ejemplo, supongamos que ha creado un nuevo archivo con la cadena codificada en base64 del nuevo certificado de CA llamado aks-proxy-config-2.json. Puede actualizar la configuración del proxy en el clúster con el siguiente comando:

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

Actualización de imágenes del nodo AKS

Después de configurar el proxy, debe actualizar la imagen del nodo para aplicar los cambios. El proceso de actualización de la imagen del nodo es la única manera de actualizar los archivos del sistema operativo necesarios para las actualizaciones de configuración del proxy. El proceso de actualización de la imagen del nodo es una actualización gradual que actualiza la imagen del sistema operativo en cada nodo del grupo de nodos. El plano de control de AKS controla el proceso de actualización, que no interrumpe la ejecución de las aplicaciones.

Para actualizar las imágenes de nodo de AKS, consulte Actualizar imágenes de nodo de Azure Kubernetes Service (AKS).

Configuración del complemento de supervisión

El proxy HTTP con el complemento de supervisión admite las siguientes configuraciones:

  • Proxy de salida sin autenticación
  • Proxy de salida con autenticación de nombre de usuario y contraseña
  • Proxy de salida con certificado de confianza para el punto de conexión de Log Analytics

Las configuraciones que aparecen a continuación no son compatibles:

  • Métricas personalizadas y características de alertas recomendadas al usar un proxy con certificados de confianza

Pasos siguientes

Para más información sobre los requisitos de red de los clústeres de AKS, consulte Control del tráfico de salida de los nodos de clúster en AKS.