Configuración de un proxy HTTP para los hosts de Satellite

Puede configurar un proxy HTTP para que todo el tráfico de salida de los hosts de Satellite se direccione a través del proxy.

La configuración de un proxy HTTP sólo está disponible para cuentas permitidas enumeradas.

¿Qué tipo de ubicación necesito para utilizar el proxy HTTP?

Tenga en cuenta los siguientes tipos de ubicaciones.

Ubicaciones basadas en RHEL existentes: Para configurar un proxy, su ubicación debe estar habilitada para Red Hat CoreOS (RHCOS). Si la ubicación existente no está habilitada para RHCOS, no puede configurar un proxy HTTP. Cree una ubicación habilitada para RHCOS y, a continuación, configure el proxy HTTP.
Ubicaciones habilitadas de Red Hat CoreOS existentes con hosts adjuntos: Para configurar un proxy HTTP, primero debe eliminar los hosts desde su ubicación. Después de eliminar los hosts, consulte Configuración del proxy HTTP. Tenga en cuenta que también debe actualizar los hosts que componen el plano de control de ubicación. Consulte Actualización de hosts de plano de control de ubicación Satellite.
Nuevas ubicaciones habilitadas de Red Hat CoreOS: Antes de conectar los hosts a la ubicación, configure el proxy HTTP.

¿Qué tipo de hosts puedo utilizar?

Puede utilizar hosts RHEL o Red Hat CoreOS al configurar un proxy HTTP. Debe editar cada host que esté conectado a su ubicación, incluidos los hosts que componen el plano de control. Recuerde incluir http o https en el archivo proxy.conf.

¿Qué más necesito saber sobre el proxy HTTP?

Para que la ubicación de Satellite y los clústeres funcionen con un proxy, el kubelet en los nodos de infraestructura del plano de control que se despliegan en una ubicación de Satellite deben poder comunicarse con el servidor de API del nodo del plano de control de IBM Cloud. Para habilitar esta comunicación, debe cumplir uno de los requisitos siguientes.

Opción 1: Utilizar el script de conexión de cortafuegos reducido.
Opción 2: El proxy actual puede soportar conexiones TCP de larga duración (túnel TCP).
Opción 3: Puede crear un proxy secundario en una VSI en la misma red que los hosts de Satellite que da soporte a conexiones TCP de larga duración.
Opción 4: Puede abrir la salida del cortafuegos para permitir las conexiones TCP. Para obtener más información, consulte Conectividad de salida necesaria para hosts en todas las regiones y, a continuación, busque los requisitos de red de salida específicos para su región.

No puede configurar un proxy HTTP para el trabajador para que domine las comunicaciones o para conectarse a los duplicados del paquete.

Configuración de túneles TCP

El proxy debe estar configurado con túneles por TCP. Aunque los pasos específicos pueden variar en función del proveedor, siga estos pasos generales para configurar los túneles por TCP.

Configure el proxy HTTP para el tráfico de túnel para los cuatro puntos finales de servicio público de ubicación. Para buscar los puntos finales,
```
ibmcloud sat location get --location LOCATION_NAME
```
En la salida, busque el campo URL de punto final de servicio. Desde ese campo, puede derivar los puntos finales. Por ejemplo, si el valor de campo es https://c131-e.us-south.satellite.cloud.ibm.com:31726, los puntos finales son https://c131-1.us-south.satellite.cloud.ibm.com:31726, https://c131-2.us-south.satellite.cloud.ibm.com:31726 y https://c131-3.us-south.satellite.cloud.ibm.com:31726.
Asegúrese de que el puerto de escucha en el proxy HTTP sea el mismo que en IBM Cloud.
Actualice el /etc/hosts en todos los hosts de Satellite para incluir el tráfico de puntos finales de servicio público de ubicación en el proxy, en lugar de en los puntos finales de IBM Cloud.

La configuración puede variar según el proveedor. Considere la posibilidad de configurar el proxy fuera del entorno de Satellite para asegurarse de que la configuración funciona para la infraestructura. A continuación, configure el proxy en el entorno de Satellite. Para obtener más información sobre cómo configurar el proxy HTTP, consulte el blog Proxying In Cluster Kube-APIServer Traffic in IBM Cloud Satellite.

Solicitud de acceso a la lista de elementos permitidos

Para obtener acceso a la lista de elementos permitidos para el proxy HTTP, cree una incidencia con el soporte de IBM.

Por ejemplo, utilice la siguiente solicitud como plantilla.

Title: Request for addition of HTTP_PROXY config to
       location <LOCATION_ID>

Request Body:
We are requesting the following HTTP_PROXY info be added to
the location_ID listed in the title of this ticket.

Use the following HTTP_PROXY info
BE SURE to include the protocol (http:// or https://)
AND the port (`:PORT_NUMBER`) in the endpoint.


HTTP_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER
HTTPS_PROXY: https://my-proxy-endpoint.com:PORT_NUMBER

Después de que el soporte procese el ticket, recibirá una notificación de que su ubicación se ha actualizado. Si se requiere un cambio, se debe abrir un nuevo ticket que indique los nuevos parámetros. Para encontrar LOCATIONID ejecutando ibmcloud sat locations.

Configuración del proxy HTTP

Para configurar un proxy HTTP, debe editar cada uno de los hosts, incluidos los hosts del plano de control. Si los hosts ya están conectados a una ubicación, incluidos los hosts que componen el plano de control, debe eliminarlos de la ubicación antes de poder editarlos. Después de configurar el proxy, vuelva a conectar los hosts a la ubicación. Para obtener más información sobre cómo actualizar los hosts del plano de control, consulte Actualización de los hosts del plano de control de ubicación de Satellite.

Elija una ubicación de duplicación que desee utilizar para un proxy. Esta ubicación de duplicación se utiliza al configurar el proxy.
Busque el valor de NO_PROXY.
- Para hosts de plano de control, utilice 172.20.0.1 para RHCOS y NO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION> para RHEL.
- Para los hosts de Red Hat OpenShift , los hosts de NO_PROXY para Red Hat OpenShift deben incluir la primera IP de la subred de servicio que se utiliza para el clúster de Red Hat OpenShift. Para encontrar esta IP, ejecute el mandato cluster get.
```
ibmcloud ks cluster get --cluster <ClusterID>
```
  Salida de ejemplo
```
Name:                           hyp-20220306-1-d2   
ID:                             <ClusterID>  
...
Service Subnet:                 172.21.0.0/16
...
```
  En esta salida, tenga en cuenta que la primera IP es 172.21.0.1, que realiza la salida completa para los hosts asociados con este clúster específico en este ejemplo NO_PROXY=172.20.0.1,172.21.0.1,$REDHAT_PACKAGE_MIRROR_LOCATION para los hosts RHEL y NO_PROXY=172.20.0.1,172.21.0.1,.REGION.satellite.appdomain.cloud para los hosts RHCOS. Por ejemplo, NO_PROXY=172.20.0.1,172.21.0.1,.eu-gb.satellite.appdomain.cloud es correcto para una ubicación de duplicación de Londres para hosts RHCOS. Tenga en cuenta que el valor RHCOS incluye . antes de la región.
  
  Cualquier tráfico a los servicios de clúster desde el nodo trabajador debe estar incluido en NO_PROXY. Por ejemplo, para utilizar el servicio de registro de imágenes para almacenar imágenes, añada image-registry.openshift-image-registry.svc a NO_PROXY para cada nodo trabajador; no es necesario incluir este valor para el plano de control.

Vaya a /etc/systemd/system.conf.d en el host. Si ese archivo no existe, créelo con el mandato siguiente. Especifique <VALUE> para NO_PROXY en el paso 2.

mkdir -p /etc/systemd/system.conf.d
cat >"/etc/systemd/system.conf.d/proxy.conf" <<EOF
[Manager]
DefaultEnvironment="HTTP_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "HTTPS_PROXY=https://my-proxy-endpoint.com:PORT_NUMBER" "NO_PROXY=<VALUE>"
EOF
chmod 0644 /etc/systemd/system.conf.d/proxy.conf

Cree el archivo ibm-proxy.sh ejecutando el mandato siguiente. Especifique <VALUE> para NO_PROXY en el paso 2.

mkdir -p /etc/profile.d
cat >"/etc/profile.d/ibm-proxy.sh" <<EOF
#!/usr/bin/env bash
HTTP_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
HTTPS_PROXY="https://my-proxy-endpoint.com:PORT_NUMBER"
NO_PROXY="<VALUE>"
export HTTP_PROXY
export HTTPS_PROXY
export NO_PROXY
EOF
chmod 0755 /etc/profile.d/ibm-proxy.sh

Reinicie el host para recoger este cambio.
Adjuntar o reconectar el host en la ubicación.
Vuelva a asignar el host al plano de control o al servicio donde se asignó anteriormente.
Repita estos pasos para cada host.

El valor de REDHAT_PACKAGE_MIRROR_LOCATION depende de la ubicación de los duplicados del paquete de Red Hat. REDHAT_PACKAGE_MIRROR_LOCATION puede ser un comodín si se utilizan varios duplicadores. Para obtener más información, consulte Cómo aplicar un proxy de todo el sistema.

Ubicaciones de duplicación comunes

La lista siguiente proporciona algunas ubicaciones de duplicación comunes.

Azure: definición por separado: rhui-1.microsoft.com, rhui-2.microsoft.com, rhui-3.microsoft.com; /etc/yum.repos.d/rh-cloud.repo bajo baseurl
Proveedor de Google Cloud: cds.rhel.updates.googlecloud.com; /etc/yum.repos.d/rh-cloud.repo bajo mirrorlist
Servicio web de Amazon: comodín: aws.ce.redhat.com; rhui3.REGION.aws.ce.redhat.com; /etc/yum.repos.d/redhat-rhui.repo bajo mirrorlist
IBM Cloud: comodín: service.networklayer.com; dal10: rhncapdal1001.service.networklayer.com; /etc/yum.repos.d/redhat.repo bajo baseurl