Compartilhar via

Configurar um proxy em todo o cluster em um cluster do Red Hat OpenShift no Azure

Este artigo descreve o processo para habilitar um proxy em todo o cluster em um cluster do Red Hat OpenShift do Azure. Esse recurso permite que os ambientes de produção neguem o acesso direto à Internet e, em vez disso, tenham um proxy HTTP ou HTTPS disponível. Este artigo detalha as etapas de configuração específicas necessárias para um cluster do Red Hat OpenShift no Azure. Para obter mais informações sobre como o recurso de proxy em todo o cluster funciona para a Plataforma de Contêiner do OpenShift, consulte a documentação do Red Hat.

Ao configurar um proxy em todo o cluster, é importante entender os seguintes impactos:

  • Reinicialização do nó: Habilitar o proxy faz com que os nós reinicializem de forma sem interrupção, semelhante a uma atualização de cluster. Isso é necessário à medida que aplica novas configurações de computador.
  • Interrupções de serviço: Para evitar interrupções de serviço durante esse processo, é crucial preparar a noProxy lista, conforme descrito.

Importante

A falha ao seguir as instruções descritas neste artigo pode resultar em roteamento inadequado do tráfego de rede do cluster. Isso pode levar a problemas de carga de trabalho, como falhas ao obter imagens.

Escopo da configuração de proxy em todo o cluster

  • Cargas de trabalho do OpenShift: As instruções neste artigo se aplicam somente a cargas de trabalho do OpenShift. As cargas de trabalho do aplicativo de proxy estão fora do escopo deste artigo.
  • Versões da Plataforma de Contêiner do OpenShift: Há suporte para proxy em todo o cluster nas versões da Plataforma de Contêiner do OpenShift descritas na política de suporte do Red Hat OpenShift no Azure.

Seguir as instruções neste artigo e preparar a lista minimizará as noProxy interrupções e garantirá uma transição suave ao habilitar o proxy.

Pré-requisitos e isenção de responsabilidade

  • Examine a documentação do OpenShift para configurar o proxy em todo o cluster para obter mais informações.
  • Servidor proxy e certificados: espera-se que você tenha um servidor proxy e certificados já em vigor.
  • O SRE do Red Hat OpenShift do Azure não oferece suporte para seu servidor proxy ou certificados.

Visão geral

  1. Reúna os valores de ponto de extremidade necessários para uso na lista noProxy.
  2. Habilite o proxy em todo o cluster usando os dados coletados para noProxy.
  3. Verifique se a lista noProxy e o proxy em nível de cluster foram configurados com êxito.

Coletar os dados necessários para noProxy

  1. Verifique o status do proxy em todo o cluster executando o seguinte comando:

    oc get proxy cluster -o yaml

    O spec campo e o campo status devem estar vazios, mostrando que ele não está habilitado. Se não estiver vazio, talvez ele tenha sido configurado anteriormente.

    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. Observe o IP do IMDS: 169.254.169.254

  3. Se você não estiver usando o DNS personalizado, observe o IP DNS do Azure: 168.63.129.16

  4. Observe o localhost e os domínios de serviço:

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

  5. Recupere o gatewayDomains executando o seguinte comando:

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

    Confira a seguinte saída de exemplo:

    [
    "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. Obtenha suas URLs de domínio do cluster.

    Crie as URLs específicas do cluster para os domínios da API e do aplicativo.

    um. Obtenha o domínio de aplicativos executando o seguinte comando:

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

    Confira a seguinte saída de exemplo:

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

    Mantenha apenas a parte começando com .apps.xxxxxxxx para uso na lista noProxy. Não inclua o "/" à direita.

    Consulte o seguinte exemplo:

    .apps.xxxxxxxx.westus2.aroapp.io

    b. Obtenha os domínios da API.

    Usando a saída do comando anterior, substitua .apps por api e api-int na URL para obter os domínios de API para a lista noProxy.

    Consulte o seguinte exemplo:

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

  7. Obtenha os intervalos CIDR.

    um. Obtenha as addressPrefix sub-redes do perfil de trabalho executando o seguinte 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

    Exemplo de saída:

    10.0.1.0/24

    b. Obtenha a sub-rede addressPrefix do perfil principal executando o seguinte comando:

    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

    Exemplo de saída:

    10.0.0.0/24

    c. Obtenha o podCidr comando executando o seguinte comando:

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

    Exemplo de saída:

    10.128.0.0/14

    d. Obtenha o serviceCidr comando executando o seguinte comando:

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

    Exemplo de saída:

    172.30.0.0/16

  8. Combine os dados coletados em sua noProxy lista que serão usados para atualizar o objeto de cluster proxy na próxima seção.

Habilitando o proxy em todo o cluster

  1. Crie o user-ca-bundle configmap no openshift-config namespace para usar o certificado correto.

    um. Crie um arquivo chamado user-ca-bundle.yaml com o seguinte conteúdo e forneça os valores dos certificados codificados em 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: essa chave de dados deve ser nomeada ca-bundle.crt.
    • data.ca-bundle.crt | <MY_PEM_ENCODED_CERTS>: um ou mais certificados X.509 codificados em PEM usados para assinar o certificado de identidade do proxy.
    • metadata.name: o nome do mapa de configuração referenciado pelo objeto proxy.
    • metadata.namespace: o mapa de configuração deve estar no openshift-config namespace.

    b. Crie o ConfigMap executando o seguinte comando:

    oc create -f user-ca-bundle.yaml

    c. Confirme a criação do user-ca-bundle ConfigMap executando o seguinte comando:

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

    Confira a seguinte saída de exemplo:

    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. Atualize o objeto de cluster proxy usando oc edite configure o objeto proxy usando as informações coletadas anteriormente.

    um. Execute o comando a seguir:

    oc edit proxy/cluster

    Atualize ou adicione os seguintes campos:

    • spec.httpProxy: uma URL de proxy a ser usada para criar conexões HTTP fora do cluster. O esquema de URL deve ser http.
    • spec.httpsProxy: uma URL de proxy a ser usada para criar conexões HTTPS fora do cluster.
    • spec.noProxy: Esta será a lista separada por vírgulas de pontos de extremidade obtidos na coleta dos dados necessários para noProxy acima.
    • spec.trustedCA: uma referência ao mapa de configuração no openshift-config namespace que contém outros certificados de AC necessários para proxy de conexões HTTPS. Observe que o mapa de configuração já deve existir antes de referenciá-lo aqui. Nesse caso, esse é o nome do mapa de configuração criado acima, que é user-ca-bundle.

    b. Confirme a configuração executando o seguinte comando:

    oc get proxy cluster -o yaml

    Confira a seguinte saída de exemplo:

    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. Aguarde até que a nova configuração da máquina seja distribuída para todos os nós e para que os operadores de cluster relatem que o estado do sistema está saudável.

    um. Confirme a integridade do nó executando o seguinte comando:

    oc get nodes

    Confira a seguinte saída de exemplo:

    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 a integridade do operador de cluster executando o seguinte comando:

    oc get co

    Confira a seguinte saída de exemplo:

    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

    Observação

    Se precisar do user-ca-bundle, ele estará localizado no diretório a seguir (mas não é necessário para este processo):

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

Verificar a noProxy configuração

Para verificar a configuração do proxy, verifique o status de integridade dos operadores de cluster. Se o noProxy campo estiver configurado incorretamente, vários operadores de cluster poderão entrar em um Degraded: True estado. Isso pode resultar de vários problemas, incluindo, mas não se limitando a erros, ImagePullBack certificados inválidos ou problemas gerais de conectividade. Além disso, alguns operadores podem permanecer em estado Progressing: True devido a causas subjacentes semelhantes.

  1. Verifique o status dos operadores de cluster executando o seguinte comando:

    oc get co

  2. Interpretando a saída (estado íntegro): se o noProxy campo estiver configurado corretamente, a saída deverá ser semelhante ao exemplo a seguir:

    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

    Observação

    O número e o tipo de operadores de cluster podem variar. O exemplo truncado apresentado é fornecido para ilustrar um estado saudável para operadores suportados.

  3. Interpretando a saída (configurada incorretamente): se o noProxy campo estiver configurado incorretamente, a saída poderá ser semelhante ao exemplo a seguir:

    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

    Observação

    Apenas uma saída de exemplo truncada é mostrada. Outros operadores de cluster também podem relatar um Degraded: True estado com erros diferentes resultantes da configuração incorreta de noProxy.

Remover proxy em todo o cluster

Para obter informações sobre como remover o proxy em todo o cluster, consulte a documentação do Red Hat OpenShift.

  • Last updated on