Udostępnij przez

Konfigurowanie serwera proxy w całym klastrze w klastrze usługi Azure Red Hat OpenShift

W tym artykule opisano proces włączania serwera proxy całego klastra w klastrze Usługi Azure Red Hat OpenShift. Ta funkcja umożliwia środowiskom produkcyjnym odmowę bezpośredniego dostępu do Internetu i zamiast tego ma dostępny serwer proxy HTTP lub HTTPS. W tym artykule szczegółowo opisano konkretne kroki konfiguracji niezbędne dla klastra usługi Azure Red Hat OpenShift. Aby uzyskać więcej informacji na temat działania funkcji serwera proxy całego klastra dla platformy kontenera OpenShift, zobacz dokumentację oprogramowania Red Hat.

Podczas konfigurowania serwera proxy całego klastra ważne jest, aby zrozumieć następujące skutki:

  • Ponowne uruchomienie węzła: Włączenie serwera proxy powoduje ponowne uruchomienie węzłów w sposób kroczący, podobnie jak w przypadku aktualizacji klastra. Jest to konieczne, ponieważ stosuje nowe konfiguracje maszyn.
  • Przerwy w działaniu usługi: Aby uniknąć zakłóceń w działaniu usługi podczas tego procesu, należy przygotować noProxy listę zgodnie z opisem.

Ważne

Brak przestrzegania instrukcji opisanych w tym artykule może spowodować niewłaściwy routing ruchu sieciowego klastra. Może to prowadzić do problemów z obciążeniem, takich jak błędy ściągania obrazu.

Zakres konfiguracji serwera proxy całego klastra

  • Obciążenia OpenShift: Instrukcje w tym artykule dotyczą tylko obciążeń OpenShift. Obciążenia aplikacji proxying są poza zakresem tego artykułu.
  • Wersje platformy kontenera OpenShift: Serwer proxy obejmujący cały klaster jest obsługiwany w wersjach platformy kontenerów OpenShift opisanych w zasadach pomocy technicznej usługi Azure Red Hat OpenShift.

Postępując zgodnie z instrukcjami zawartymi w tym artykule i przygotowując listę noProxy, zminimalizujesz zakłócenia i zapewnisz bezproblemowe przejście podczas włączania proxy.

Wymagania wstępne i zastrzeżenie

  • Aby uzyskać więcej informacji, zapoznaj się z dokumentacją platformy OpenShift dotyczącą konfigurowania serwera proxy w całym klastrze .
  • Serwer proxy i certyfikaty: oczekuje się, że masz już serwer proxy i certyfikaty.
  • Usługa Azure Red Hat OpenShift SRE nie zapewnia obsługi serwera proxy ani certyfikatów.

Przegląd

  1. Zbierz wymagane wartości punktu końcowego do użycia w liście noProxy.
  2. Włącz serwer proxy obejmujący cały klaster przy użyciu zebranych danych dla programu noProxy.
  3. Sprawdź listę noProxy i serwer pośredniczący w całym klastrze, aby upewnić się, że zostały pomyślnie skonfigurowane.

Zbierz wymagane dane dla noProxy

  1. Sprawdź stan serwera proxy całego klastra, uruchamiając następujące polecenie:

    oc get proxy cluster -o yaml

    Pola spec i status powinny być puste, pokazujące, że nie jest włączone. Jeśli nie jest ona pusta, być może została ona wcześniej skonfigurowana.

    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. Zanotuj adres IP IMDS: 169.254.169.254

  3. Jeśli nie używasz niestandardowego systemu DNS, zanotuj adres IP usługi Azure DNS: 168.63.129.16

  4. Zanotuj domeny hosta lokalnego i usługi:

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

  5. Pobierz element gatewayDomains uruchamiając następujące polecenie:

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

    Zobacz następujące przykładowe dane wyjściowe:

    [
    "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. Pobierz adresy URL domeny klastra.

    Utwórz adresy URL specyficzne dla klastra dla interfejsu API i domen aplikacji.

    a. Uzyskaj domenę aplikacji, uruchamiając następujące polecenie:

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

    Zobacz następujące przykładowe dane wyjściowe:

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

    Zachowaj tylko część zaczynającą się od .apps.xxxxxxxx do użycia na liście noProxy. Nie dołączaj końcowego ciągu "/".

    Zobacz następujący przykład:

    .apps.xxxxxxxx.westus2.aroapp.io

    b. Uzyskaj domeny interfejsu API.

    Używając danych wyjściowych poprzedniego polecenia, zastąp .apps zarówno api, jak i api-int w adresie URL, aby uzyskać domeny API dla listy noProxy.

    Zobacz następujący przykład:

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

  7. Pobierz zakresy CIDR.

    a. Aby pobrać addressPrefix z podsieci profilu pracownika, użyj następującego polecenia:

    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

    Przykładowy wynik:

    10.0.1.0/24

    b. Pobierz element addressPrefix z podsieci profilu głównego, uruchamiając następujące polecenie:

    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

    Przykładowy wynik:

    10.0.0.0/24

    c. Uzyskaj podCidr poprzez uruchomienie następującego polecenia:

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

    Przykładowy wynik:

    10.128.0.0/14

    d. Uzyskaj serviceCidr poprzez uruchomienie następującego polecenia:

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

    Przykładowy wynik:

    172.30.0.0/16

  8. Połącz zebrane dane z listą noProxy, która będzie używana do aktualizowania obiektu klastra proxy w następnej sekcji.

Włączanie serwera proxy w całym klastrze

  1. user-ca-bundle Utwórz configmap w openshift-config przestrzeni nazw, aby użyć poprawnego certyfikatu.

    a. Utwórz plik o nazwie user-ca-bundle.yaml z następującą zawartością i podaj wartości certyfikatów zakodowanych w standardzie 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: ten klucz danych musi mieć nazwę ca-bundle.crt.
    • data.ca-bundle.crt | <MY_PEM_ENCODED_CERTS>: Jeden lub więcej certyfikatów X.509 w formacie PEM używanych do podpisywania certyfikatu tożsamości proxy.
    • metadata.name: nazwa mapy konfiguracji, do której odwołuje się obiekt proxy.
    • metadata.namespace: Mapa konfiguracji musi znajdować się w openshift-config przestrzeni nazw.

    b. Utwórz ConfigMap, uruchamiając następujące polecenie:

    oc create -f user-ca-bundle.yaml

    c. Potwierdź utworzenie obiektu user-ca-bundle ConfigMap, uruchamiając następujące polecenie:

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

    Zobacz następujące przykładowe dane wyjściowe:

    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. Zaktualizuj obiekt klastra proxy przy użyciu polecenia oc edit, a następnie skonfiguruj obiekt serwera proxy przy użyciu wcześniej zebranych informacji.

    a. Uruchom następujące polecenie:

    oc edit proxy/cluster

    Zaktualizuj lub dodaj następujące pola:

    • spec.httpProxy: adres URL serwera proxy używany do tworzenia połączeń HTTP poza klastrem. Schemat adresu URL musi mieć wartość http.
    • spec.httpsProxy: adres URL serwera proxy używany do tworzenia połączeń HTTPS poza klastrem.
    • spec.noProxy: Będzie to rozdzielana przecinkami lista punktów końcowych uzyskanych w sekcji Zbieranie wymaganych danych dla kroków noProxy powyżej.
    • spec.trustedCA: odwołanie do mapy konfiguracji w openshift-config przestrzeni nazw zawierającej inne certyfikaty urzędu certyfikacji wymagane do obsługi połączeń HTTPS. Pamiętaj, że mapa konfiguracji musi już istnieć przed odwoływaniem się do niej tutaj. W takim przypadku jest to nazwa mapy konfiguracji utworzonej powyżej, czyli user-ca-bundle.

    b. Potwierdź konfigurację, uruchamiając następujące polecenie:

    oc get proxy cluster -o yaml

    Zobacz następujące przykładowe dane wyjściowe:

    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. Poczekaj, aż nowa konfiguracja maszyny zostanie wdrożona na wszystkich węzłach, a operatorzy klastra będą zgłaszać dobrą kondycję.

    a. Potwierdź kondycję węzła, uruchamiając następujące polecenie:

    oc get nodes

    Zobacz następujące przykładowe dane wyjściowe:

    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. Potwierdź kondycję operatora klastra, uruchamiając następujące polecenie:

    oc get co

    Zobacz następujące przykładowe dane wyjściowe:

    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

    Uwaga / Notatka

    Jeśli potrzebujesz user-ca-bundle zasobu, znajduje się w katalogu wskazanym poniżej (ale nie jest to niezbędne do tego procesu).

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

Weryfikowanie noProxy konfiguracji

Aby zweryfikować konfigurację serwera proxy, sprawdź stan kondycji operatorów klastra. Jeśli pole noProxy jest nieprawidłowo skonfigurowane, wielu operatorów klastra może znaleźć się w stanie Degraded: True. Może to wynikać z różnych problemów, w tym błędów, ImagePullBack nieprawidłowych certyfikatów lub ogólnych problemów z łącznością. Ponadto niektóre operatory mogą pozostać w Progressing: True stanie ze względu na podobne przyczyny bazowe.

  1. Sprawdź stan operatorów klastra, uruchamiając następujące polecenie:

    oc get co

  2. Interpretowanie danych wyjściowych (stan dobrej kondycji): jeśli noProxy pole jest poprawnie skonfigurowane, dane wyjściowe powinny przypominać następujący przykład:

    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

    Uwaga / Notatka

    Liczba i typ operatorów klastra mogą się różnić. Pokazano przykład obcięty, aby zilustrować stan dobrej kondycji dla obsługiwanych operatorów.

  3. Interpretowanie danych wyjściowych (nieprawidłowo skonfigurowanych): jeśli noProxy pole jest nieprawidłowo skonfigurowane, dane wyjściowe mogą przypominać następujący przykład:

    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

    Uwaga / Notatka

    Pokazano tylko obcięte przykładowe dane wyjściowe. Inni operatorzy klastra mogą również zgłaszać stan Degraded: True z różnymi błędami wynikającymi z niewłaściwej konfiguracji noProxy.

Usuwanie serwera proxy całego klastra

Aby uzyskać informacje na temat usuwania serwera proxy całego klastra, zobacz dokumentację oprogramowania Red Hat OpenShift.

  • Last updated on