Partilhar via

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

Este artigo descreve o processo para habilitar um proxy em todo o cluster em um cluster do Azure Red Hat OpenShift. Esse recurso permite que os ambientes de produção neguem 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 Azure Red Hat OpenShift. Para obter mais informações sobre como o recurso de proxy em todo o cluster funciona para o OpenShift Container Platform, consulte a documentação da 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 sejam reinicializados de forma contínua, semelhante a uma atualização de cluster. Isso é necessário, pois aplica novas configurações de máquina.
  • Interrupções do serviço: Para evitar interrupções de serviço durante esse processo, é crucial preparar a noProxy lista conforme descrito.

Importante

A não adesão às 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 de extração de imagem.

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

  • Cargas de trabalho OpenShift: As instruções neste artigo aplicam-se apenas a cargas de trabalho OpenShift. O proxy de cargas de trabalho de aplicativos está fora do escopo deste artigo.
  • Versões do OpenShift Container Platform: O proxy em todo o cluster é suportado nas versões do OpenShift Container Platform descritas na política de suporte do Azure Red Hat OpenShift.

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

Pré-requisitos e isenção de responsabilidade

  • Consulte 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ê já tenha um servidor proxy e certificados instalados.
  • O Azure Red Hat OpenShift SRE não fornece suporte para seu servidor proxy ou certificados.

Visão geral

  1. Reúna os valores de endpoint 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 noProxy lista e o proxy de todo o cluster foram configurados com êxito.

Reúna 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

    Os spec campos e status devem estar vazios, mostrando que não estão ativados. Se não estiver vazio, pode ter 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 do DNS do Azure: 168.63.129.16

  4. Observe os domínios localhost e service:

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

  5. Recupere o gatewayDomains executando o seguinte comando:

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

    Veja o exemplo de saída a seguir:

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

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

    a) 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

    Veja o exemplo de saída a seguir:

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

    Mantenha apenas a parte que começa com .apps.xxxxxxxx para uso na lista noProxy. Não inclua o "/" no final.

    Veja 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 da API para a noProxy lista.

    Veja o seguinte exemplo:

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

  7. Obtenha os intervalos CIDR.

    a) Obtenha as addressPrefix sub-redes do perfil de trabalhador 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 o addressPrefix da sub-rede do perfil mestre 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 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 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á usada para atualizar o objeto de cluster proxy na próxima seção.

Habilitando proxy em todo o cluster

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

    a) Crie um arquivo chamado user-ca-bundle.yaml com o seguinte conteúdo e forneça os valores de seus 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: Esta chave de dados deve ser denominada 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 a partir do 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

    Veja o exemplo de saída a seguir:

    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 edit, e depois configure o objeto proxy usando as informações coletadas anteriormente.

    a) Execute o seguinte comando:

    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 dos pontos de extremidade obtidos nas etapas Reunir os 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 CA necessários para proxy de conexões HTTPS. Observe que o mapa de configuração já deve existir antes de fazer referência aqui. Neste caso, este é 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

    Veja o exemplo de saída a seguir:

    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 implementada em todos os nós e que os operadores de cluster relatem que estão saudáveis.

    a) Confirme a integridade do nó executando o seguinte comando:

    oc get nodes

    Veja o exemplo de saída a seguir:

    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

    Veja o exemplo de saída a seguir:

    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 você precisar do user-ca-bundle, ele está localizado no seguinte diretório (mas não é necessário para este processo):

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

Verificar configuração de noProxy

Para verificar sua configuração de 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 limitado a, ImagePullBack erros, 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 mostrado é fornecido para ilustrar um estado saudável para operadores suportados.

  3. Interpretando a saída (mal configurada): Se o noProxy campo estiver configurado incorretamente, a saída pode 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

    Mostrada é apenas uma saída de amostra truncada. Outros operadores de cluster também podem relatar um Degraded: True estado com erros diferentes resultantes da configuração incorreta do 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