Partager via

Configurer un proxy à l’échelle du cluster dans un cluster Azure Red Hat OpenShift

Cet article décrit le processus d’activation d’un proxy à l’échelle du cluster sur un cluster Azure Red Hat OpenShift. Cette fonctionnalité permet aux environnements de production de refuser l’accès direct à Internet et d’avoir plutôt un proxy HTTP ou HTTPS disponible. Cet article détaille les étapes de configuration spécifiques nécessaires pour un cluster Azure Red Hat OpenShift. Pour plus d’informations sur le fonctionnement de la fonctionnalité proxy à l’échelle du cluster pour OpenShift Container Platform, consultez la documentation Red Hat.

Lors de la configuration d’un proxy à l’échelle du cluster, il est important de comprendre les impacts suivants :

  • Redémarrage du nœud : L’activation du proxy entraîne le redémarrage des nœuds de manière propagée, similaire à une mise à jour de cluster. Cela est nécessaire, car il applique de nouvelles configurations de machine.
  • Interruptions de service : Pour éviter toute interruption de service pendant ce processus, il est essentiel de préparer la noProxy liste comme décrit.

Important

L’échec de l’adhésion aux instructions décrites dans cet article peut entraîner un routage incorrect du trafic réseau du cluster. Cela peut entraîner des problèmes de charge de travail, tels que des échecs d’extraction d’images.

Étendue de la configuration du proxy à l’échelle du cluster

  • Charges de travail OpenShift : Les instructions de cet article s’appliquent uniquement aux charges de travail OpenShift. La mise en proxy des charges de travail d'application n'est pas couverte par cet article.
  • Versions d’OpenShift Container Platform : Le proxy à l’échelle du cluster est pris en charge sur les versions d’OpenShift Container Platform décrites dans la stratégie de prise en charge d’Azure Red Hat OpenShift.

En suivant les instructions de cet article et en préparant la noProxy liste, les interruptions sont réduites et garantissent une transition fluide lors de l’activation du proxy.

Conditions préalables et exclusion de responsabilité

  • Pour plus d’informations, consultez la documentation OpenShift sur la configuration du proxy à l’échelle du cluster .
  • Serveur proxy et certificats : vous êtes censé avoir un serveur proxy et des certificats déjà en place.
  • Azure Red Hat OpenShift SRE ne prend pas en charge votre serveur proxy ou vos certificats.

Aperçu

  1. Rassemblez les valeurs de point de terminaison requises à utiliser dans la noProxy liste.
  2. Activez le proxy à l’échelle du cluster à l’aide des données collectées pour noProxy.
  3. Vérifiez que la noProxy liste et le proxy à l’échelle du cluster ont été correctement configurés.

Collecter les données requises pour noProxy

  1. Vérifiez l’état du proxy à l’échelle du cluster en exécutant la commande suivante :

    oc get proxy cluster -o yaml

    Les champs spec et status doivent être vides, pour indiquer qu’il n’est pas activé. S’il n’est pas vide, il a peut-être été configuré précédemment.

    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. Notez l’adresse IP IMDS : 169.254.169.254

  3. Si vous n’utilisez pas de DNS personnalisé, notez l’adresse IP Azure DNS : 168.63.129.16

  4. Notez les domaines localhost et de service :

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

  5. Exécutez la commande suivante pour récupérer le gatewayDomains :

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

    Consultez l’exemple de sortie suivant :

    [
    "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. Obtenez vos URL de domaine de cluster.

    Créez les URL spécifiques du cluster pour les domaines d’API et d’application.

    a) Obtenez le domaine des applications en exécutant la commande suivante :

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

    Consultez l’exemple de sortie suivant :

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

    Conservez uniquement la partie à partir de .apps.xxxxxxxx pour utilisation dans la liste noProxy. N’incluez pas le « / » de fin.

    Consultez l’exemple suivant :

    .apps.xxxxxxxx.westus2.aroapp.io

    b. Obtenez les domaines d’API.

    À l’aide de la sortie de la commande précédente, remplacez .apps par api et api-int dans l’URL pour obtenir les domaines d’API de la noProxy liste.

    Consultez l’exemple suivant :

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

  7. Obtenez les plages CIDR.

    a) Obtenez les addressPrefix sous-réseaux du profil d'employé en exécutant la commande suivante :

    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

    Exemple de sortie :

    10.0.1.0/24

    b. Obtenez le addressPrefix du sous-réseau du profil maître en exécutant la commande suivante :

    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

    Exemple de sortie :

    10.0.0.0/24

    v. Obtenez la podCidr en exécutant la commande suivante :

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

    Exemple de sortie :

    10.128.0.0/14

    d. Obtenez la serviceCidr en exécutant la commande suivante :

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

    Exemple de sortie :

    172.30.0.0/16

  8. Combinez les données collectées dans votre noProxy liste qui seront utilisées pour mettre à jour l’objet de cluster proxy dans la section suivante.

Activation du proxy à l’échelle du cluster

  1. Créez le user-ca-bundle configmap dans le openshift-config namespace pour utiliser le certificat approprié.

    a) Créez un fichier appelé user-ca-bundle.yaml avec le contenu suivant et fournissez les valeurs de vos certificats encodés 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: cette clé de données doit être nommée ca-bundle.crt.
    • data.ca-bundle.crt | <MY_PEM_ENCODED_CERTS>: un ou plusieurs certificats X.509 codés en PEM utilisés pour signer le certificat d’identité du proxy.
    • metadata.name: nom de carte de configuration référencé à partir de l’objet proxy.
    • metadata.namespace: Le config map doit se trouver dans le namespace openshift-config.

    b. Créez le ConfigMap en exécutant la commande suivante :

    oc create -f user-ca-bundle.yaml

    v. Confirmez la création de user-ca-bundle ConfigMap en exécutant la commande suivante :

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

    Consultez l’exemple de sortie suivant :

    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. Mettez à jour l'objet de cluster proxy en utilisant oc edit, puis configurez l'objet proxy à l'aide des informations collectées précédemment.

    a) Exécutez la commande suivante:

    oc edit proxy/cluster

    Mettez à jour ou ajoutez les champs suivants :

    • spec.httpProxy : URL de proxy à utiliser pour créer des connexions HTTP à l’extérieur du cluster. Le schéma d’URL doit être http.
    • spec.httpsProxy : URL de proxy à utiliser pour créer des connexions HTTPS à l’extérieur du cluster.
    • spec.noProxy: il s’agit de la liste séparée par des virgules des points de terminaison obtenus dans la collection des données requises pour les étapes noProxy ci-dessus.
    • spec.trustedCA: une référence au config map dans l'espace de noms openshift-config qui contient d'autres certificats d'autorité de certification requis pour la mise en proxy des connexions HTTPS. Notez que la carte de configuration doit déjà exister avant de la référencer ici. Dans ce cas, il s’agit du nom de la carte de configuration créée ci-dessus, qui est user-ca-bundle.

    b. Confirmez la configuration en exécutant la commande suivante :

    oc get proxy cluster -o yaml

    Consultez l’exemple de sortie suivant :

    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. Attendez que la nouvelle configuration soit déployée sur tous les nœuds et que les opérateurs du cluster annoncent le bon fonctionnement.

    a) Confirmez l’intégrité des nœuds en exécutant la commande suivante :

    oc get nodes

    Consultez l’exemple de sortie suivant :

    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. Confirmez l’intégrité de l’opérateur de cluster en exécutant la commande suivante :

    oc get co

    Consultez l’exemple de sortie suivant :

    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

    Remarque

    Si vous avez besoin du user-ca-bundlefichier , il se trouve dans le répertoire suivant (mais il n’est pas nécessaire pour ce processus) :

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

Vérifier la noProxy configuration

Pour vérifier la configuration de votre proxy, vérifiez l’état d’intégrité des opérateurs de cluster. Si le noProxy champ est mal configuré, plusieurs opérateurs de cluster peuvent entrer un Degraded: True état. Cela peut résulter de divers problèmes, notamment, mais pas limités à, ImagePullBack aux erreurs, aux certificats non valides ou aux problèmes de connectivité généraux. En outre, certains opérateurs peuvent rester dans un Progressing: True état en raison de causes sous-jacentes similaires.

  1. Vérifiez l’état des opérateurs de cluster en exécutant la commande suivante :

    oc get co

  2. Interprétation de la sortie (état sain) : si le noProxy champ est correctement configuré, la sortie doit ressembler à l’exemple suivant :

    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

    Remarque

    Le nombre et le type d’opérateurs de cluster peuvent varier. L’exemple tronqué présenté est fourni pour illustrer un état sain pour les opérateurs pris en charge.

  3. Interprétation de la sortie (mal configurée) : si le noProxy champ est mal configuré, la sortie peut ressembler à l’exemple suivant :

    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

    Remarque

    Ce qui est montré n’est qu’un exemple tronqué de sortie. D’autres opérateurs de cluster peuvent également signaler un Degraded: True état avec des erreurs différentes résultant de la mauvaise configuration de noProxy.

Supprimer un proxy à l’échelle du cluster

Pour plus d’informations sur la suppression du proxy à l’échelle du cluster, consultez la documentation Red Hat OpenShift.

  • Last updated on