Compartir a través de

Configuración de un proxy de todo el clúster en un clúster de Red Hat OpenShift (ARO) de Azure

En este artículo se describe el proceso para habilitar un proxy de todo el clúster en un clúster de Red Hat OpenShift en Azure. Esta característica permite a los entornos de producción denegar el acceso directo a Internet y, en su lugar, tener disponible un proxy HTTP o HTTPS. En este artículo se detallan los pasos de configuración específicos necesarios para un clúster de Red Hat OpenShift de Azure. Para obtener más información sobre cómo funciona la característica de proxy de todo el clúster para OpenShift Container Platform, consulte la documentación de Red Hat.

Al configurar un proxy de todo el clúster, es importante comprender los siguientes impactos:

  • Reinicio del nodo: La habilitación del proxy hace que los nodos se reinicien de forma gradual, de forma similar a una actualización del clúster. Esto es necesario, ya que aplica nuevas configuraciones de máquina.
  • Interrupciones del servicio: Para evitar interrupciones del servicio durante este proceso, es fundamental preparar la noProxy lista como se describe.

Importante

Si no se cumplen las instrucciones descritas en este artículo, podría producirse un enrutamiento incorrecto del tráfico de red del clúster. Esto podría provocar problemas de carga de trabajo, como errores de extracción de imágenes.

Ámbito de la configuración de proxy en todo el clúster

  • Cargas de trabajo de OpenShift: Las instrucciones de este artículo solo se aplican a las cargas de trabajo de OpenShift. Las cargas de trabajo de aplicaciones mediante proxys están fuera del alcance de este artículo.
  • Versiones de OpenShift Container Platform: Se admite un proxy para todo el clúster en las versiones de OpenShift Container Platform que se describen en la política de soporte de Azure Red Hat OpenShift.

Siguiendo las instrucciones de este artículo y preparando la lista noProxy minimizará las interrupciones y garantizará una transición sin problemas al habilitar el proxy.

Requisitos previos y declinación de responsabilidades

  • Revise la documentación de OpenShift para configurar el proxy de todo el clúster para obtener más información.
  • Servidor proxy y certificados: se espera que tenga un servidor proxy y certificados ya implementados.
  • Azure Red Hat OpenShift SRE no proporciona soporte para su servidor proxy ni para sus certificados.

Información general

  1. Recoja los valores necesarios de punto de conexión para su uso en la lista noProxy.
  2. Habilite el proxy de todo el clúster mediante los datos recopilados para noProxy.
  3. Compruebe que la noProxy lista y el proxy de todo el clúster se han configurado correctamente.

Recopilación de los datos necesarios para noProxy

  1. Para comprobar el estado del proxy en todo el clúster, ejecute el siguiente comando:

    oc get proxy cluster -o yaml

    Los spec campos y status deben estar vacíos, lo que muestra que no está habilitado. Si no está vacío, es posible que se haya configurado previamente.

    apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  creationTimestamp: "xxxx-xx-xxTxx:xx:xxZ"
  generation:
  name: cluster
  resourceVersion:
  uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
spec:
  trustedCA:
    name: ""
status: {}

  2. Tenga en cuenta la dirección IP de IMDS: 169.254.169.254

  3. Si no usa DNS personalizado, tenga en cuenta la dirección IP de Azure DNS: 168.63.129.16

  4. Tenga en cuenta los dominios localhost y de servicio:

    • localhost
    • 127.0.0.1
    • .svc
    • .cluster.local

  5. Recupere el gatewayDomains ejecutando el siguiente comando.

    oc get cluster cluster -o jsonpath='{.spec.gatewayDomains}'

    Consulte la salida del ejemplo siguiente:

    [
    "agentimagestorews01.blob.core.windows.net",
    "agentimagestorecus01.blob.core.windows.net",
    "agentimagestoreeus01.blob.core.windows.net",
    "agentimagestoreeus01.blob.core.windows.net",
    "agentimagestoreeas01.blob.core.windows.net",
    "eastus-shared.prod.warm.ingest.monitor.core.windows.net",
    "...", // Many other endpoints
]

  6. Obtenga las direcciones URL del dominio del clúster.

    Cree las direcciones URL específicas del clúster para la API y los dominios de aplicación.

    a) Para obtener el dominio de aplicaciones, ejecute el comando siguiente:

    az aro show -n <CLUSTER_NAME> -g <RESOURCE_GROUP_NAME> --query "consoleProfile.url" -o tsv

    Consulte la salida del ejemplo siguiente:

    https://console-openshift-console.apps.xxxxxxxx.westus2.aroapp.io/

    Mantenga solo la parte que comienza con .apps.xxxxxxxx para usar en la lista noProxy. No incluya el final "/".

    Vea el ejemplo siguiente:

    .apps.xxxxxxxx.westus2.aroapp.io

    b. Obtenga los dominios de API.

    Con la salida del comando anterior, reemplace .apps con api y api-int en la dirección URL para obtener los dominios de API de la lista noProxy.

    Vea el ejemplo siguiente:

    api.xxxxxxxx.westus2.aroapp.io
api-int.xxxxxxxx.westus2.aroapp.io

  7. Obtenga los rangos CIDR.

    a) Para obtener las subredes de perfil de trabajo desde addressPrefix, ejecute el siguiente comando:

    SUBNET_ID=$(az aro show -n <CLUSTER_NAME> -g <RESOURCE_GROUP_NAME> --query "workerProfiles[].subnetId" -o tsv)
az network vnet subnet show --ids "$SUBNET_ID" --query "addressPrefix || [].addressPrefix" -o tsv

    Ejemplo de resultado:

    10.0.1.0/24

    b. Para obtener desde addressPrefix la subred del perfil maestro, ejecute el comando siguiente:

    SUBNET_ID=$(az aro show -n <CLUSTER_NAME> -g <RESOURCE_GROUP_NAME> --query "masterProfile.subnetId" -o tsv)
az network vnet subnet show --ids "$SUBNET_ID" --query "addressPrefix" -o tsv

    Ejemplo de resultado:

    10.0.0.0/24

    c. Ejecute el siguiente comando para obtener el podCidr.

    az aro show -n <CLUSTER_NAME> -g <RESOURCE_GROUP_NAME> --query "networkProfile.podCidr" -o tsv

    Ejemplo de resultado:

    10.128.0.0/14

    d. Obtenga el serviceCidr ejecutando el siguiente comando:

    az aro show -n <CLUSTER_NAME> -g <RESOURCE_GROUP_NAME> --query "networkProfile.serviceCidr" -o tsv

    Ejemplo de resultado:

    172.30.0.0/16

  8. Combine los datos recopilados en la lista noProxy que se usará para actualizar el objeto de clúster de proxy en la sección siguiente.

Habilitación del proxy en todo el clúster

  1. Cree el configmap user-ca-bundle en el namespace openshift-config para utilizar el certificado correcto.

    a) Cree un archivo llamado user-ca-bundle.yaml con el siguiente contenido y proporcione los valores de los certificados codificados en PEM:

    apiVersion: v1
data:
  ca-bundle.crt: |
    <MY_PEM_ENCODED_CERTS>
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
    • data.ca-bundle.crt: esta clave de datos debe denominarse ca-bundle.crt.
    • data.ca-bundle.crt | <MY_PEM_ENCODED_CERTS>: uno o varios certificados X.509 codificados en PEM que se usan para firmar el certificado de identidad del proxy.
    • metadata.name: nombre del mapa de configuración al que se hace referencia desde el objeto proxy.
    • metadata.namespace: El mapa de configuración debe estar en el openshift-config espacio de nombres.

    b. Cree configMap mediante la ejecución del comando siguiente:

    oc create -f user-ca-bundle.yaml

    c. Para confirmar la creación de ConfigMap user-ca-bundle , ejecute el siguiente comando:

    oc get cm -n openshift-config user-ca-bundle -o yaml

    Consulte la salida del ejemplo siguiente:

    apiVersion: v1
data:
  ca-bundle.crt: |
     -----BEGIN CERTIFICATE-----
     <CERTIFICATE_DATA>
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  creationTimestamp: "xxxx-xx-xxTxx:xx:xxZ"
  name: user-ca-bundle
  namespace: openshift-config
  resourceVersion: "xxxxxx"
  uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

  2. Actualice el objeto de clúster de proxy mediante oc edity, a continuación, configure el objeto proxy mediante la información recopilada anteriormente.

    a) Ejecute el siguiente comando:

    oc edit proxy/cluster

    Actualice o agregue los siguientes campos:

    • spec.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.
    • spec.httpsProxy: dirección URL de proxy que se usará para crear conexiones HTTPS fuera del clúster.
    • spec.noProxy: esta será la lista separada por comas de puntos de conexión obtenidos en la recopilación de los datos necesarios para los pasos noProxy anteriores.
    • spec.trustedCA: referencia al mapa de configuración en el openshift-config espacio de nombres que contiene otros certificados de CA necesarios para la proxiación de conexiones HTTPS. Tenga en cuenta que el mapa de configuración ya debe existir antes de hacer referencia a él aquí. En este caso, este es el nombre del mapa de configuración creado anteriormente, que es user-ca-bundle.

    b. Para confirmar la configuración, ejecute el comando siguiente:

    oc get proxy cluster -o yaml

    Consulte la salida del ejemplo siguiente:

    apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"config.openshift.io/v1","kind":"Proxy","metadata":{"annotations":{},"name":"cluster"},"spec":{"httpProxy":"http://10.0.0.15:3128","httpsProxy":"https://10.0.0.15:3129","noProxy":"agentimagestorecus01.blob.core.windows.net,agentimagestoreeus01.blob.core.windows.net,agentimagestorewus01.blob.core.windows.net,agentimagestoreweu01.blob.core.windows.net,agentimagestoreeas01.blob.core.windows.net,australiaeast-shared.prod.warm.ingest.monitor.core.windows.net,gcs.prod.monitoring.core.windows.net,gsm1130809042eh.servicebus.windows.net,gsm1130809042xt.blob.core.windows.net,gsm119650579eh.servicebus.windows.net,gsm119650579xt.blob.core.windows.net,gsm810972145eh.servicebus.windows.net,gsm810972145xt.blob.core.windows.net,maupdateaccount.blob.core.windows.net,maupdateaccount2.blob.core.windows.net,maupdateaccount3.blob.core.windows.net,maupdateaccount4.blob.core.windows.net,production.diagnostics.monitoring.core.windows.net,qos.prod.warm.ingest.monitor.core.windows.net,login.microsoftonline.com,management.azure.com,arosvc.azurecr.io,arosvc.australiaeast.data.azurecr.io,imageregistryvmxx7.blob.core.windows.net,.cluster.local,.svc,api-int.vlsi41ah.australiaeast.aroapp.io,localhost,10.0.0.0/8","trustedCA":{"name":"user-ca-bundle"}}}
  creationTimestamp: "xxxx-xx-xxTxx:xx:xxZ"
  generation: 17
  name: cluster
  resourceVersion: "xxxxxxx"
  uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
spec:
  httpProxy: http://10.0.0.15:3128
  httpsProxy: https://10.0.0.15:3129
  noProxy: agentimagestorecus01.blob.core.windows.net,agentimagestoreeus01.blob.core.windows.net,agentimagestorewus01.blob.core.windows.net,agentimagestoreweu01.blob.core.windows.net,agentimagestoreeas01.blob.core.windows.net,australiaeast-shared.prod.warm.ingest.monitor.core.windows.net,gcs.prod.monitoring.core.windows.net,gsm1130809042eh.servicebus.windows.net,gsm1130809042xt.blob.core.windows.net,gsm119650579eh.servicebus.windows.net,gsm119650579xt.blob.core.windows.net,gsm810972145eh.servicebus.windows.net,gsm810972145xt.blob.core.windows.net,maupdateaccount.blob.core.windows.net,maupdateaccount2.blob.core.windows.net,maupdateaccount3.blob.core.windows.net,maupdateaccount4.blob.core.windows.net,production.diagnostics.monitoring.core.windows.net,qos.prod.warm.ingest.monitor.core.windows.net,login.microsoftonline.com,management.azure.com,arosvc.azurecr.io,arosvc.australiaeast.data.azurecr.io,imageregistryvmxx7.blob.core.windows.net,.cluster.local,.svc,api-int.vlsi41ah.australiaeast.aroapp.io,localhost,10.0.0.0/8
  trustedCA:
    name: user-ca-bundle
status:
  httpProxy: http://10.0.0.15:3128
  httpsProxy: https://10.0.0.15:3129
  noProxy: .cluster.local,.svc,10.0.0.0/8,10.128.0.0/14,127.0.0.0/8,127.0.0.1,169.254.169.254,172.30.0.0/16,agentimagestorecus01.blob.core.windows.net,agentimagestoreeas01.blob.core.windows.net,agentimagestoreeus01.blob.core.windows.net,agentimagestoreweu01.blob.core.windows.net,agentimagestorewus01.blob.core.windows.net,api-int.vlsi41ah.australiaeast.aroapp.io,arosvc.australiaeast.data.azurecr.io,arosvc.azurecr.io,australiaeast-shared.prod.warm.ingest.monitor.core.windows.net,gcs.prod.monitoring.core.windows.net,gsm1130809042eh.servicebus.windows.net,gsm1130809042xt.blob.core.windows.net,gsm119650579eh.servicebus.windows.net,gsm119650579xt.blob.core.windows.net,gsm810972145eh.servicebus.windows.net,gsm810972145xt.blob.core.windows.net,imageregistryvmxx7.blob.core.windows.net,localhost,login.microsoftonline.com,management.azure.com,maupdateaccount.blob.core.windows.net,maupdateaccount2.blob.core.windows.net,maupdateaccount3.blob.core.windows.net,maupdateaccount4.blob.core.windows.net,production.diagnostics.monitoring.core.windows.net,qos.prod.warm.ingest.monitor.core.windows.net

  3. Espere a que la nueva configuración de máquina quede implementada en todos los nodos y que los operadores del clúster informen estar en buen estado.

    a) Para confirmar el estado del nodo, ejecute el comando siguiente:

    oc get nodes

    Consulte la salida del ejemplo siguiente:

    NAME                                         STATUS   ROLES    AGE   VERSION
mycluster-master-0                           Ready    master   10d   v1.xx.xx+xxxxxxx
mycluster-master-1                           Ready    master   10d   v1.xx.xx+xxxxxxx
mycluster-master-2                           Ready    master   10d   v1.xx.xx+xxxxxxx
mycluster-worker-australiaeast1-mvzqr        Ready    worker   10d   v1.xx.xx+xxxxxxx
mycluster-worker-australiaeast2-l9fgj        Ready    worker   10d   v1.xx.xx+xxxxxxx
mycluster-worker-australiaeast3-pz9rw        Ready    worker   10d   v1.xx.xx+xxxxxxx

    b. Confirme el estado del operador de clúster mediante la ejecución del comando siguiente:

    oc get co

    Consulte la salida del ejemplo siguiente:

    NAME                                VERSION        AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
aro                                 vxxxxxxxx      True        False         False      10d
authentication                      4.xx.xx        True        False         False      8m25s
cloud-controller-manager            4.xx.xx        True        False         False      10d
cloud-credential                    4.xx.xx        True        False         False      10d
cluster-autoscaler                  4.xx.xx        True        False         False      10d
... (Many other components) ...
storage                             4.xx.xx        True        False         False      10d

    Nota:

    Si necesita user-ca-bundle, se encuentra en el directorio siguiente (pero no es necesario para este proceso):

    /etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt

Verificar noProxy la configuración

Para comprobar la configuración del proxy, compruebe el estado de salud de los operadores de clúster. Si el noProxy campo está mal configurado, es posible que varios operadores de clúster escriban un Degraded: True estado. Esto puede deberse a varios problemas, incluidos, entre otros, errores, ImagePullBack certificados no válidos o problemas generales de conectividad. Además, algunos operadores pueden permanecer en estado Progressing: True debido a causas subyacentes similares.

  1. Ejecute el comando siguiente para comprobar el estado de los operadores de clúster:

    oc get co

  2. Interpretación de la salida (estado correcto): si el noProxy campo está configurado correctamente, la salida debe ser similar al ejemplo siguiente:

    NAME                                       VERSION        AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
aro                                        vxxxxxxxx.xx   True        False         False      15d
authentication                             4.xx.xx        True        False         False      15d
cloud-controller-manager                   4.xx.xx        True        False         False      15d
cloud-credential                           4.xx.xx        True        False         False      15d

    Nota:

    El número y el tipo de operadores de clúster pueden variar. El ejemplo truncado que se muestra se proporciona para ilustrar un estado óptimo para los operadores compatibles con ARO.

  3. Interpretación de la salida (mal configurado): si el noProxy campo está mal configurado, la salida podría parecerse al ejemplo siguiente:

    NAME                         VERSION        AVAILABLE  PROGRESSING  DEGRADED  SINCE    MESSAGE
aro                          vxxxxxxxx.xx   True       False        False     45h
authentication               4.xx.xx        False      True         True      24h      OAuthServerRouteEndpointAccessibleControllerAvailable: Get "https://oauth-openshift.apps.mm6osebam6b03b9df3.eastus2euap.aroapp.io/healthz": Not Found
control-plane-machine-set    4.xx.xx        True       False        False     46h      SyncLoopRefreshProgressing: Working toward version 4.15.35, 1 replicas available
image-registry               4.xx.xx        True       True         False     45h      NodeCADaemonProgressing: The daemon set node-ca is deployed Progressing: The deployment has not completed
ingress                      4.xx.xx        True       True         True      83m      The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
machine-config               4.xx.xx        False      False        True      43h      Cluster not available for [{operator 4.15.35}]: error during waitForControllerConfigToBeCompleted: [context deadline exceeded, controllerconfig is not completed: status for ControllerConfig machine-config-controller is being reported for 6, expecting it for 13]
storage                      4.xx.xx        True       True         False     45h      AzureFileCSIDriverOperatorCRProgressing: AzureFileDriverControllerServiceControllerProgressing: Waiting for Deployment to deploy pods AzureFileCSIDriverOperatorCRProgressing: AzureFileDriverNodeServiceControllerProgressing: Waiting for DaemonSet to deploy node pods

    Nota:

    Solo se muestra un resultado de muestra truncado. Otros operadores de clúster también pueden notificar un Degraded: True estado con errores diferentes resultantes de la configuración incorrecta de noProxy.

Eliminar el proxy de todo el clúster

Para obtener información sobre cómo quitar el proxy de todo el clúster, consulte la documentación de Red Hat OpenShift.