Freigeben über

Konfigurieren eines clusterweiten Proxys in einem Azure Red Hat OpenShift-Cluster

In diesem Artikel wird der Prozess zum Aktivieren eines clusterweiten Proxys in einem Azure Red Hat OpenShift-Cluster beschrieben. Mit diesem Feature können Produktionsumgebungen direkten Zugriff auf das Internet verweigern und stattdessen über einen HTTP- oder HTTPS-Proxy verfügen. In diesem Artikel werden die spezifischen Konfigurationsschritte beschrieben, die für einen Azure Red Hat OpenShift-Cluster erforderlich sind. Weitere Informationen zur Funktionsweise des clusterweiten Proxyfeatures für die OpenShift-Containerplattform finden Sie in der Red Hat-Dokumentation.

Beim Konfigurieren eines clusterweiten Proxys ist es wichtig, die folgenden Auswirkungen zu verstehen:

  • Knotenneustart: Das Aktivieren des Proxys bewirkt, dass Knoten in rollierender Weise neu gestartet werden, ähnlich wie bei einem Clusterupdate. Dies ist erforderlich, da neue Computerkonfigurationen angewendet werden.
  • Dienstunterbrechungen: Um Dienstunterbrechungen während dieses Prozesses zu vermeiden, ist es wichtig, die noProxy Liste wie beschrieben vorzubereiten.

Von Bedeutung

Wenn die in diesem Artikel beschriebenen Anweisungen nicht eingehalten werden, kann dies dazu führen, dass der Clusternetzwerkdatenverkehr nicht ordnungsgemäß weitergeleitet wird. Dies kann zu Arbeitslastproblemen führen, wie beispielsweise Fehler beim Abrufen von Images.

Umfang der clusterweiten Proxykonfiguration

  • OpenShift-Workloads: Die Anweisungen in diesem Artikel gelten nur für OpenShift-Workloads. Das Proxying von Anwendungsworkloads ist nicht Gegenstand dieses Artikels.
  • OpenShift Container Platform-Versionen: Clusterweiter Proxy wird in OpenShift Container Platform-Versionen unterstützt, die in der Azure Red Hat OpenShift-Unterstützungsrichtlinie beschrieben sind.

Wenn Sie die Anweisungen in diesem Artikel befolgen und die noProxy Liste vorbereiten, werden Unterbrechungen minimiert und ein reibungsloser Übergang beim Aktivieren des Proxys sichergestellt.

Voraussetzungen und Haftungsausschluss

Überblick

  1. Sammeln Sie die erforderlichen Endpunktwerte für die Verwendung in der noProxy Liste.
  2. Aktivieren Sie den clusterweiten Proxy mithilfe der gesammelten Daten für noProxy.
  3. Stellen Sie sicher, dass die noProxy Liste und der clusterweite Proxy erfolgreich konfiguriert wurden.

Sammeln der erforderlichen Daten für noProxy

  1. Überprüfen Sie den clusterweiten Proxystatus, indem Sie den folgenden Befehl ausführen:

    oc get proxy cluster -o yaml

    Die Felder spec und status sollten leer sein und anzeigen, dass sie nicht aktiviert sind. Wenn sie nicht leer ist, wurde sie möglicherweise zuvor konfiguriert.

    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. Beachten Sie die IMDS-IP: 169.254.169.254

  3. Wenn Sie kein benutzerdefiniertes DNS verwenden, beachten Sie die Azure DNS-IP: 168.63.129.16

  4. Beachten Sie die Localhost- und Dienstdomänen:

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

  5. Rufen Sie den gatewayDomains ab, indem Sie den folgenden Befehl ausführen:

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

    Sehen Sie sich die folgende Beispielausgabe an:

    [
    "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. Rufen Sie Ihre Clusterdomänen-URLs ab.

    Erstellen Sie die clusterspezifischen URLs für die API und Anwendungsdomänen.

    a) Rufen Sie die Anwendungsdomäne ab, indem Sie den folgenden Befehl ausführen:

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

    Sehen Sie sich die folgende Beispielausgabe an:

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

    Behalten Sie nur den Teil .apps.xxxxxxxx für die Verwendung in der Liste noProxy bei. Schließen Sie das nachfolgende "/" nicht ein.

    Sehen Sie sich das folgende Beispiel an:

    .apps.xxxxxxxx.westus2.aroapp.io

    b. Rufen Sie die API-Domänen ab.

    Verwenden Sie die Ausgabe des vorherigen Befehls, um .apps in der URL durch api und api-int zu ersetzen und so die API-Domänen für die noProxy-Liste zu erhalten.

    Sehen Sie sich das folgende Beispiel an:

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

  7. Rufen Sie die CIDR-Bereiche ab.

    a) Rufen Sie die addressPrefix Subnetze des Arbeitsprofils ab, indem Sie den folgenden Befehl ausführen:

    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

    Beispielausgabe:

    10.0.1.0/24

    b. Rufen Sie das addressPrefix Subnetz des Masterprofils ab, indem Sie den folgenden Befehl ausführen:

    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

    Beispielausgabe:

    10.0.0.0/24

    Abschnitt c. Rufen Sie den podCidr ab, indem Sie den folgenden Befehl ausführen:

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

    Beispielausgabe:

    10.128.0.0/14

    d. Rufen Sie den serviceCidr ab, indem Sie den folgenden Befehl ausführen:

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

    Beispielausgabe:

    172.30.0.0/16

  8. Kombinieren Sie die gesammelten Daten in Ihrer noProxy Liste, die zum Aktualisieren des Proxyclusterobjekts im nächsten Abschnitt verwendet werden.

Aktivieren von clusterweitem Proxy

  1. Erstellen Sie die user-ca-bundle Configmap im openshift-config Namespace, um das richtige Zertifikat zu verwenden.

    a) Erstellen Sie eine Datei, die mit dem folgenden Inhalt aufgerufen wird user-ca-bundle.yaml , und stellen Sie die Werte Ihrer PEM-codierten Zertifikate bereit:

    apiVersion: v1
data:
  ca-bundle.crt: |
    <MY_PEM_ENCODED_CERTS>
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
    • data.ca-bundle.crt: Dieser Datenschlüssel muss den Namen "ca-bundle.crt" haben.
    • data.ca-bundle.crt | <MY_PEM_ENCODED_CERTS>: Mindestens ein PEM-codiertes X.509-Zertifikat, das zum Signieren des Identitätszertifikats des Proxys verwendet wird.
    • metadata.name: Der vom Proxyobjekt referenzierte Name der Konfigurationsdatei.
    • metadata.namespace: Die Konfigurationskarte muss sich im openshift-config Namensraum befinden.

    b. Erstellen Sie die ConfigMap, indem Sie den folgenden Befehl ausführen:

    oc create -f user-ca-bundle.yaml

    Abschnitt c. Bestätigen Sie die Erstellung der user-ca-bundle ConfigMap, indem Sie den folgenden Befehl ausführen:

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

    Sehen Sie sich die folgende Beispielausgabe an:

    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. Aktualisieren Sie das Proxyclusterobjekt mit Hilfe von oc edit, und konfigurieren Sie dann das Proxyobjekt mithilfe der zuvor gesammelten Informationen.

    a) Führen Sie den folgenden Befehl aus:

    oc edit proxy/cluster

    Aktualisieren oder Hinzufügen der folgenden Felder:

    • spec.httpProxy: Eine Proxy-URL, die zum Erstellen von HTTP-Verbindungen außerhalb des Clusters verwendet wird. Das URL-Schema muss http sein.
    • spec.httpsProxy: Eine Proxy-URL, die zum Erstellen von HTTPS-Verbindungen außerhalb des Clusters verwendet wird.
    • spec.noProxy: Dies wird die kommagetrennte Liste der Endpunkte sein, die in den obigen Schritten 'Erforderliche Daten für noProxy sammeln' abgerufen wurden.
    • spec.trustedCA: Ein Verweis auf die Konfigurationszuordnung im openshift-config Namespace, die andere für die Proxy-HTTPS-Verbindungen erforderliche CA-Zertifikate enthält. Beachten Sie, dass die ConfigMap bereits vorhanden sein muss, bevor darauf hier verwiesen wird. In diesem Fall ist dies der Name der oben erstellten Config-Map, die benutzer-ca-bundle ist.

    b. Bestätigen Sie die Konfiguration, indem Sie den folgenden Befehl ausführen:

    oc get proxy cluster -o yaml

    Sehen Sie sich die folgende Beispielausgabe an:

    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. Warten Sie, bis die neue Maschinenkonfiguration für alle Knoten eingeführt wird und die Clusteroperatoren eine fehlerfreie Meldung machen.

    a) Bestätigen Sie den Knotenstatus, indem Sie den folgenden Befehl ausführen:

    oc get nodes

    Sehen Sie sich die folgende Beispielausgabe an:

    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. Überprüfen Sie die Integrität des Clusteroperators, indem Sie den folgenden Befehl ausführen:

    oc get co

    Sehen Sie sich die folgende Beispielausgabe an:

    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

    Hinweis

    Wenn Sie das user-ca-bundleVerzeichnis benötigen, befindet es sich im folgenden Verzeichnis (für diesen Prozess ist er jedoch nicht erforderlich):

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

Überprüfen der noProxy Konfiguration

Überprüfen Sie den Integritätsstatus der Clusteroperatoren, um die Proxykonfiguration zu überprüfen. Wenn das noProxy Feld falsch konfiguriert ist, können mehrere Clusteroperatoren einen Degraded: True Zustand eingeben. Dies kann zu verschiedenen Problemen führen, einschließlich, aber nicht beschränkt auf Fehler, ImagePullBack ungültige Zertifikate oder allgemeine Konnektivitätsprobleme. Darüber hinaus können einige Operatoren aufgrund ähnlicher zugrunde liegender Ursachen in einem Progressing: True Zustand verbleiben.

  1. Überprüfen Sie den Status der Clusteroperatoren, indem Sie den folgenden Befehl ausführen:

    oc get co

  2. Interpretieren der Ausgabe (fehlerfreier Zustand): Wenn das noProxy Feld ordnungsgemäß konfiguriert ist, sollte die Ausgabe dem folgenden Beispiel ähneln:

    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

    Hinweis

    Die Anzahl und der Typ der Clusteroperatoren können variieren. Das verkürzte Beispiel wird bereitgestellt, um einen gesunden Zustand für unterstützte Operatoren zu veranschaulichen.

  3. Interpretieren der Ausgabe (falsch konfiguriert): Wenn das noProxy Feld falsch konfiguriert ist, kann die Ausgabe dem folgenden Beispiel ähneln:

    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

    Hinweis

    Es wird nur eine abgeschnittene Beispielausgabe angezeigt. Andere Clusteroperatoren können ebenfalls einen Degraded: True Zustand zusammen mit unterschiedlichen Fehlern melden, die aufgrund der Fehlkonfiguration von noProxy auftreten.

Den clusterweiten Proxy entfernen

Informationen zum Entfernen des clusterweiten Proxys finden Sie in der Dokumentation zu Red Hat OpenShift.

  • Last updated on