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 existentes habilitadas para Red Hat y CoreOS con hosts asociados
- 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 asociar tus hosts a tu ubicación, configura tu proxy de HTTP.
¿Qué tipo de hosts puedo utilizar?
Puedes utilizar RHEL o Red Hat CoreOS como servidores de alojamiento al configurar un proxy de 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 admite conexiones de TCP s de larga duración (túnel TCP ).
-
Opción 3: Puedes crear un proxy secundario en un VSI de la misma red que tus hosts de Satellite que admita conexiones TCP de larga duración.
-
Opción 4: Puede abrir el cortafuegos de salida 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 un túnel c TCP
El proxy debe estar configurado con túneles por TCP. Los siguientes pasos describen la configuración general del túnel de TCP; consulta la documentación de tu proveedor para obtener instrucciones específicas.
-
Configura tu proxy de HTTP para canalizar el tráfico hacia los cuatro puntos de acceso de servicio público de tus ubicaciones. Para buscar los puntos finales,
ibmcloud sat location get --location LOCATION_NAMEEn 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 sonhttps://c131-1.us-south.satellite.cloud.ibm.com:31726,https://c131-2.us-south.satellite.cloud.ibm.com:31726yhttps://c131-3.us-south.satellite.cloud.ibm.com:31726. -
Asegúrate de que el puerto de escucha del proxy de HTTP sea el mismo que el de IBM Cloud.
-
Actualice el
/etc/hostsen 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.
Los detalles de configuración varían según el proveedor. Configure primero su proxy fuera del entorno Satellite para comprobar que la configuración funciona en su infraestructura y, a continuación, configure su proxy en el entorno Satellite.
Para obtener más información sobre cómo instalar y configurar el proxy de HTTP, consulta 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 permitidos del proxy de HTTP, crea un ticket con el servicio de asistencia 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
Una vez que el servicio de asistencia haya tramitado el ticket, recibirás una notificación indicando que tu ubicación se ha actualizado. Si es necesario realizar un cambio, abre un nuevo ticket en el que se indiquen los nuevos parámetros. Para
encontrar tu LOCATIONID, ejecuta 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, consulta Actualización de los hosts del plano de control de una ubicació Satellite.
-
Elige una ubicación de espejo que quieras utilizar como 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.1para RHCOS yNO_PROXY=172.20.0.1,$<REDHAT_PACKAGE_MIRROR_LOCATION>para RHEL. - Para los hosts de Red Hat OpenShift , los hosts de
NO_PROXYpara 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 mandatocluster get.
ibmcloud ks cluster get --cluster <ClusterID> ``` Salida de ejemplo ```sh {: screen} 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. - Para hosts de plano de control, utilice
-
Vaya a
/etc/systemd/system.conf.den el host. Si ese archivo no existe, créalo con el siguiente comando. Especifique<VALUE>paraNO_PROXYen 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 -
Crea el archivo
ibm-proxy.shejecutando el siguiente comando. Especifique<VALUE>paraNO_PROXYen 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.repobajobaseurl- Proveedor de Google Cloud
cds.rhel.updates.googlecloud.com/etc/yum.repos.d/rh-cloud.repobajomirrorlist- Servicio web de Amazon
- comodín:
aws.ce.redhat.com rhui3.REGION.aws.ce.redhat.com/etc/yum.repos.d/redhat-rhui.repobajomirrorlist- IBM Cloud
- comodín:
service.networklayer.com - dal10:
rhncapdal1001.service.networklayer.com /etc/yum.repos.d/redhat.repobajobaseurl