IBM Cloud Docs
Expondo apps com rotas no Red Hat OpenShift 4

Expondo apps com rotas no Red Hat OpenShift 4

Exponha os serviços em seu cluster do Red Hat® OpenShift® on IBM Cloud® no endereço IP externo do roteador usando uma rota.

Essas informações são para clusters que executam o Red Hat OpenShift versão 4.

Não tem certeza se deve usar as rotas ou o Ingress do Red Hat OpenShift? Confira Escolhendo entre soluções de balanceamento de carga.

Visão geral

Por padrão, um controlador Red Hat OpenShift Ingress é implantado em seu cluster e funciona como o ponto de extremidade de entrada para o tráfego de rede externo.

Você pode usar o controlador Red Hat OpenShift Ingress para criar rotas para seus aplicativos. As rotas são designadas um nome de host publicamente ou privadamente acessível por meio do subdomínio do controlador de ingresso que os clientes externos podem usar para enviar solicitações para o seu app. É possível optar por criar rotas não seguras ou seguras usando o certificado TLS do controlador de ingresso para proteger seu nome de host. Quando a solicitação externa atinge seu nome de host, o controlador de ingresso submete sua solicitação a proxy e a encaminha para o endereço IP privado no qual seu app atende.

O tipo de controlador de ingresso que é criado por padrão varia dependendo do provedor de infraestrutura do seu cluster e da configuração do seu terminal em serviço.

  • Clusters clássicos / clusters VPC com endpoint de serviço de nuvem pública: seu cluster é criado com um controlador Ingress público por padrão. O controlador de ingresso designa rotas publicamente acessíveis para seus apps e atende a solicitações aos seus apps na interface de rede de host público. Quando uma solicitação é recebida, o controlador de ingresso direciona a solicitação para o endereço IP privado no qual o app atende. Se você quiser expor privadamente seus apps em vez disso, deverá primeiro criar um controlador de ingresso privado e, em seguida, criar rotas privadas.
  • Clusters de VPC somente com endpoint de serviço de nuvem privada: seu cluster é criado com um controlador Ingress privado por padrão. O controlador de ingresso designa rotas privadamente acessíveis para seus apps e atende na interface de rede de host privada. Apenas clientes que estiverem conectados à sua rede privada de VPC podem acessar apps que são expostos por uma rota privada. Se você quiser expor publicamente seus apps em vez disso, deverá primeiro criar um controlador de ingresso público e, em seguida, criar rotas públicas.

Se você tiver um cluster multizona, um controlador de ingresso de alta disponibilidade será implementado em seu cluster, e um serviço de controlador de ingresso será criado em cada zona. Dois nós do trabalhador são necessários por zona para que as duas réplicas do controlador de ingresso possam ser implementadas e atualizadas corretamente. Note que o serviço do controlador de ingresso na primeira zona em que você tem nós de trabalhadores é sempre nomeado router-default, e os serviços do controlador de ingresso em zonas que você incluiu posteriormente em seu cluster têm nomes como router-dal12.

  • Para ver os serviços do controlador de ingresso em cada zona do seu cluster, execute oc get svc -n openshift-ingress.
  • Para ver o subdomínio do controlador de ingresso para o seu cluster e os endereços IP para o serviço do controlador de ingresso em cada zona, execute ibmcloud oc nlb-dns ls -c <cluster_name_or_ID> e procure o subdomínio formatado como <cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.

Em seu painel de infraestrutura VPC, o balanceador de carga VPC relata como funcionais apenas os dois nós do trabalhador que executam os pods de réplica do controlador de ingresso, pois esses nós do trabalhador são configurados como os listeners para o balanceador de carga VPC. Mesmo que apenas os nós do trabalhador do listener sejam relatados como funcionais, o conjunto de back-end dos listeners dos nós do trabalhador é mantido atualizado pelo Red Hat OpenShift on IBM Cloud para que todos os nós do trabalhador em seu cluster ainda possam receber solicitações do balanceador de carga da VPC.

Fluxo de tráfego em um cluster clássico de zona única

O diagrama a seguir mostra como um roteador direciona o tráfego de rede da Internet para um aplicativo em um cluster clássico de zona única.

Exponha um aplicativo em um cluster de zona única Red Hat OpenShift usando um
um aplicativo em um cluster de zona única usando um

  1. Uma solicitação para o seu app usa o nome do host da rota que você configurou para o seu app.

  2. Um serviço DNS resolve o subdomínio para o endereço IP público móvel do serviço de roteador.

  3. O roteador recebe a solicitação e a encaminha para o endereço IP privado do pod do aplicativo pela rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP público do nó do trabalhador no qual o pod do roteador é executado. Se várias instâncias do app forem implementadas no cluster, o roteador enviará as solicitações entre os pods do app.

  4. Quando o app retorna um pacote de resposta, ele usa o endereço IP do nó do trabalhador no qual o roteador que encaminhou a solicitação do cliente existe. O roteador envia, então, o pacote de resposta por meio do serviço de balanceador de carga para o cliente.

Fluxo de tráfego em um cluster clássico multizona

O diagrama a seguir mostra como um roteador direciona o tráfego de rede da Internet para um aplicativo em um cluster clássico multizona.

Exponha um aplicativo em um cluster de várias zonas Red Hat OpenShift usando um
um aplicativo em um cluster de várias zonas usando um

  1. Uma solicitação para o seu app usa o nome do host da rota que você configurou para o seu app.

  2. Um serviço DNS resolve o subdomínio da rota para o endereço IP público móvel de um serviço de roteador que foi reportado como em bom funcionamento pelo balanceador de carga multizona (MZLB). O MZLB verifica continuamente os endereços IP públicos móveis dos serviços que expõem o roteador em cada zona do seu cluster. As solicitações são tratadas pelos serviços de roteador em várias zonas em um ciclo de round-robin.

  3. Com base no endereço IP resolvido do serviço de roteador, o roteador recebe a solicitação.

  4. O roteador encaminha a solicitação para o endereço IP privado do pod do aplicativo pela rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP público do nó do trabalhador no qual o pod do roteador é executado. Cada roteador envia solicitações para as instâncias do app em sua própria zona e para as instâncias do app em outras zonas. Além disso, se várias instâncias do app forem implementadas em uma zona, o roteador alternará solicitações entre os pods do app.

  5. Quando o app retorna um pacote de resposta, ele usa o endereço IP do nó do trabalhador no qual o roteador que encaminhou a solicitação do cliente existe. O roteador envia, então, o pacote de resposta por meio do serviço de balanceador de carga para o cliente.

Fluxo de tráfego em um cluster de VPC multizona com um terminal em serviço de nuvem pública

Quando você cria um cluster de VPC multizona com o terminal em serviço de nuvem pública ativado, um controlador de ingresso público é criado por padrão. O controlador de ingresso designa rotas publicamente acessíveis para seus apps e atende a solicitações aos seus apps na interface de rede de host público.

O diagrama a seguir mostra como um controlador de ingresso direciona o tráfego de rede da Internet para um app em um cluster VPC multizona.

Expor um aplicativo em um cluster VPC multizona usando um
um aplicativo em um cluster VPC multizona usando um controlador

  1. Uma solicitação para o seu app usa o nome do host da rota que você configurou para o seu app.

  2. Um serviço DNS resolve o subdomínio da rota para o nome do host do balanceador de carga VPC que é atribuído aos serviços para o controlador de ingresso. Em clusters VPC, seus endereços IP externos dos serviços do controlador de ingresso são flutuantes e mantidos atrás de um nome do host designado pelo VPC.

  3. O balanceador de carga VPC resolve o nome do host do VPC para um endereço IP externo disponível de um serviço de controlador de ingresso que foi relatado como funcional. O balanceador de carga VPC verifica continuamente os endereços IP dos serviços que expõem o controlador de ingresso em cada zona do seu cluster.

  4. Com base no endereço IP resolvido, o balanceador de carga VPC envia a solicitação para um serviço de controlador de ingresso.

  5. O controlador de ingresso encaminha a solicitação para o endereço IP privado da pod do app sobre a rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Cada controlador de ingresso envia solicitações para as instâncias do app em sua própria zona e para instâncias de app em outras zonas. Além disso, se várias instâncias do app forem implementadas em uma zona, o controlador de ingresso alternará as solicitações entre pods do app.

  6. Quando o app retorna um pacote de respostas, ele usa o endereço IP do nó do trabalhador no qual o controlador de ingresso que encaminhou a solicitação do cliente existe. O controlador de ingresso então envia o pacote de resposta por meio do balanceador de carga VPC para o cliente.

Fluxo de tráfego em um cluster de VPC multizona com um terminal em serviço de nuvem privada apenas

Ao criar um cluster VPC multizona somente com o terminal em serviço de nuvem privada, um controlador de ingresso privado é criado por padrão. O controlador de ingresso designa rotas privadamente acessíveis para seus apps e atende na interface de rede de host privada. Apenas clientes que estiverem conectados à sua rede privada de VPC podem acessar apps que são expostos por uma rota privada.

O diagrama a seguir mostra como um controlador de ingresso direciona o tráfego de rede de redes privadas para um app em um cluster VPC multizona.

Exponha um aplicativo em um cluster VPC privado, com várias zonas, usando um
um aplicativo em um cluster VPC privado, com várias zonas, usando um controlador

  1. Um cliente que está conectado à sua rede privada VPC envia uma solicitação para o seu app usando a rota privada do app. Por exemplo, é possível usar a VPN da Nuvem privada virtual, o IBM Cloud Transit Gateway ou o IBM Cloud Direct Link para permitir solicitações de uma rede no local, de outra VPC ou da infraestrutura clássica da IBM Cloud a apps que são executados no seu cluster.

  2. Um serviço DNS resolve o subdomínio da rota para o nome do host do balanceador de carga VPC que é atribuído aos serviços para o controlador de ingresso. Em clusters VPC, seus endereços IP de serviços do controlador de ingresso são flutuantes e são mantidos atrás de um nome do host designado por VPC. Observe que, embora o registro de DNS para o subdomínio da rota seja registrado no sistema DNS público, os servidores de resolução de DNS são acessíveis por meio da VPC.

  3. O balanceador de carga VPC privado resolve o nome do host VPC para um endereço IP privado disponível de um serviço de controlador de ingresso que foi relatado como funcional. O balanceador de carga VPC verifica continuamente os endereços IP dos serviços que expõem o controlador de ingresso em cada zona do seu cluster.

  4. Com base no endereço IP resolvido, o balanceador de carga VPC envia a solicitação para um serviço de controlador de ingresso.

  5. O controlador de ingresso encaminha a solicitação para o endereço IP privado da pod do app sobre a rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Cada controlador de ingresso envia solicitações para as instâncias do app em sua própria zona e para instâncias de app em outras zonas. Além disso, se várias instâncias do app forem implementadas em uma zona, o controlador de ingresso alternará as solicitações entre pods do app.

  6. Quando o app retorna um pacote de respostas, ele usa o endereço IP do nó do trabalhador no qual o controlador de ingresso que encaminhou a solicitação do cliente existe. O controlador de ingresso então envia o pacote de resposta por meio do balanceador de carga VPC e por meio do IBM Cloud VPC VPN, Transit Gateway ou Direct Link para o cliente.

Tipos de rota e finalização do TLS

O Red Hat OpenShift oferece quatro tipos de rotas com base no tipo da finalização TLS que seu app requer. Cada tipo de rota é suportado para rotas públicas e privadas.

Tipos de rotas com base na finalização do TLS
Tipo de rota Caso de uso
Simples Se você não precisa de criptografia TLS, crie uma rota simples para manipular o tráfego HTTP não criptografado.
Passthrough Quando desejar que conexões TLS passem ininterruptamente do cliente para o seu pod de aplicativo, crie uma rota de passagem. O roteador não está envolvido na finalização do TLS para tráfego HTTPS criptografado, portanto, o pod do app deve finalizar a conexão TLS. Esse tipo também pode ser usado para HTTP/2 e para terminais TLS não HTTP.
Edge Quando o pod do app for exposto em um terminal HTTP não criptografado, mas o tráfego HTTPS criptografado precisar ser manipulado, crie uma rota de borda. A conexão TLS entre o cliente e o serviço do roteador é finalizada e a conexão entre o serviço do roteador e o seu pod do app é decriptografada. Para obter mais informações, consulte a documentação da rota de borda Red Hat OpenShift.
Criptografar novamente Quando o pod do app estiver exposto em um terminal HTTPS criptografado e o tráfego HTTPS precisar ser manipulado, crie uma rota de nova criptografia. A conexão TLS entre o cliente e o serviço do roteador é finalizada e uma nova conexão TLS entre o serviço do roteador e o seu pod do app é criada. Para obter mais informações, consulte a documentação Red Hat OpenShift re-encrypt route.

Se você não precisar usar um domínio customizado, poderá usar um nome do host de rota fornecido pela IBM no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.

Verificações de funcionamento do controlador de ingresso

Permita o acesso por meio de políticas de rede ou outras regras de firewall para que seus serviços de controlador de ingresso sejam alcançáveis pela verificação de funcionamento do controlador de ingresso.

Clássico: se você usar as políticas de rede pré-DNAT do site Calico ou outro firewall personalizado para bloquear o tráfego de entrada para o cluster, deverá permitir o acesso de entrada na porta 443 dos endereços IP de origem do monitor de integridade do domínio Ingress para os endereços IP dos serviços do Controlador Ingress, para que o provedor de domínio possa monitorar a integridade dos endereços registrados e retornar somente os pontos de extremidade íntegros.

VPC: se você configurar grupos de segurança de VPC ou listas de controle de acesso(ACLs)de VPC para proteger sua rede de cluster, certifique-se de permitir o acesso de entrada na porta 443 dos endereços IP de origem do monitor de integridade do domínio Ingress para os endereços IP dos serviços do Controlador Ingress, para que o provedor de domínio possa monitorar a integridade dos endereços registrados e retornar apenas endpoints íntegros.

Configurando rotas públicas

Use um controlador de ingresso público para expor apps em seu cluster.

O método para configuração de rotas públicas varia dependendo do provedor de infraestrutura do seu cluster e da configuração do seu terminal em serviço.

Configurando rotas públicas em clusters clássicos ou em clusters de VPC com um terminal em serviço de nuvem pública

Se o seu cluster for criado em uma infraestrutura clássica ou se for criado em uma infraestrutura VPC e você tiver ativado o ponto de extremidade do serviço de nuvem pública durante a criação do cluster, o cluster será criado com um controlador Ingress público por padrão. É possível usar este controlador de ingresso para criar rotas públicas para o seu app.

  1. Crie um serviço ClusterIP do Kubernetes para a implementação do seu app. O serviço fornece um endereço IP interno para o app ao qual o controlador de ingresso pode enviar tráfego.

    oc expose deploy <app_deployment_name> --name my-app-svc
    
  2. Escolha um domínio para o seu app. Observe que os URLs de rota devem ter 130 caracteres ou menos. Domínio fornecido pela IBM: se você não precisar usar um domínio personalizado, um nome de host de rota será gerado para você no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Domínio customizado: para especificar um domínio customizado, trabalhe com o seu provedor de DNS ou IBM Cloud® Internet Services.

    1. Obter o endereço IP público para o serviço de controlador de ingresso público em cada zona na coluna IP EXTERNO. Note que o serviço do controlador de ingresso na primeira zona em que você tem nós de trabalhadores é sempre nomeado router-default, e os serviços do controlador de ingresso em zonas que você incluiu posteriormente em seu cluster têm nomes como router-dal12.

      oc get svc -n openshift-ingress
      
    2. Crie um domínio customizado com seu provedor DNS. Se você deseja usar o mesmo subdomínio para diversos serviços em seu cluster, você pode registrar um subdomínio curinga, como *.example.com.

    3. Mapeie seu domínio customizado para os endereços IP do controlador de ingresso, incluindo os endereços IP como um registro A.

  3. Configure uma rota que se baseie no tipo de finalização TLS requerida por seu app. Se você não tiver um domínio personalizado, não inclua a opção --hostname. Um nome do host de rota é gerado para você no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Se você tiver registrado um subdomínio curinga, especifique um subdomínio exclusivo em cada rota que for criada. Por exemplo, é possível especificar --hostname svc1.example.com nessa rota e --hostname svc2.example.com em outra rota.

    • Simples:
      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Passagem:
      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      
      É necessário manipular conexões HTTP/2? Depois de criar a rota, execute oc edit route <app_service_name> e mude o valor de targetPort da rota para https. É possível testar a rota executando curl -I --http2 https://<route> --insecure.
    • Borda: se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação do Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Re-criptografar: Se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação da rota Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  4. Verifique se a rota para o seu serviço de app é criada.

    oc get routes
    
  5. Opcional: Personalize as regras de roteamento padrão com configurações opcionais. Por exemplo, você pode usar anotações HAProxy específicas da rota.

Configurando rotas públicas em clusters de VPC com um terminal em serviço de nuvem privada apenas

Se o seu cluster for criado em infraestrutura de VPC e você ativou apenas o terminal em serviço de nuvem privada durante a criação do cluster, seu cluster será criado com apenas um roteador privado por padrão. Para expor publicamente seus apps, deve-se primeiro criar um recurso IngressController público e configurá-lo com um subdomínio. O operador de ingresso é criado automaticamente e configura um novo controlador de ingresso público com base no IngressController, que você pode utilizar para criar rotas públicas para seus apps.

Observe que mesmo que você crie um recurso IngressController nas etapas a seguir, o IngressController só será necessário para criar e configurar o controlador de ingresso necessário para você. Depois que o controlador de ingresso for criado, use-o diretamente para criar rotas.

  1. Prepare o domínio que você deseja utilizar para o seu controlador de ingresso.

    • Domínio customizado: para registrar um domínio customizado, trabalhe com o seu provedor de Domain Name Service (DNS) ou DNS do IBM Cloud. Se você deseja usar o mesmo subdomínio para diversos serviços em seu cluster, você pode registrar um subdomínio curinga, como *.example.com. Se você usar um domínio customizado, também deverá especificar o certificado de domínio em sua especificação IngressController. Para obter mais informações, consulte Configurando um certificado padrão customizado
    • Domínio fornecido pela IBM:
      1. Liste os subdomínios existentes em seu cluster. Na coluna Subdomínio da saída, copie o subdomínio que tem o valor de 000<n> mais alto.
        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        
        Nesta saída de exemplo, o subdomínio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud tem o valor 000<n> mais alto de 0002.
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        
      2. No subdomínio que você copiou, mude o valor 000<n> no subdomínio para 000<n+1>. Por exemplo, o subdomínio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud é alterado para mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Você registra este subdomínio nas etapas posteriores.
  2. Crie um arquivo YAML que configura um controlador do Ingress público com o domínio da etapa 1.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: public
      namespace: openshift-ingress-operator
    spec:
      # defaultCertificate: If you are using a custom domain, specify the domain certificate
        # name: custom-certs-default
      replicas: 2
      domain: <domain>
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
        type: LoadBalancerService
    
  3. Crie o recurso IngressController no namespace openshift-ingress-operator do seu cluster. Ao criar o IngressController, um controlador de ingresso público é automaticamente criado e implementado no namespace openshift-ingress baseado nas configurações do IngressController. Além disso, um serviço de controlador de ingresso é criado para expor o controlador de ingresso.

    oc create -f public.yaml -n openshift-ingress-operator
    
  4. Obtenha o nome do host de VPC no campo IP EXTERNO do serviço router-public. Em clusters de VPC, os endereços IP externos dos serviços do seu roteador são flutuantes e são mantidos atrás de um nome do host designado por VPC como alternativa.

    oc get svc router-public -n openshift-ingress
    

    Saída de exemplo

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
    router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
    
  5. Registre o nome do host do VPC do serviço com o domínio que você escolheu na etapa 1. Esta etapa garante que seus endereços IP de serviços do controlador de ingresso, que são mantidos por trás do hostname do VPC, sejam registrados com o domínio que você escolheu para o controlador de ingresso.

    • Domínio customizado: trabalhe com seu provedor de DNS para incluir o nome do host de VPC do serviço como um CNAME que é mapeado para o seu domínio customizado.

    • Domínio fornecido pela IBM: crie uma entrada DNS para o nome do host dó VPC do serviço. Ao executar o comando a seguir, o subdomínio que você especificou na etapa 2 é gerado automaticamente e é registrado com o serviço de controlador de ingresso.

      ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
      
  6. Opcional: se você deseja usar o shard do controlador de ingresso para que rotas específicas sejam manipuladas por um controlador de ingresso específico, por exemplo, rotas privadas admitidas apenas para um roteador privado, você poderá usar rótulos de rota ou de namespace para especificar o método de shard. Para incluir o seletor durante o tempo de criação, inclua-o no yaml ingresscontroller sob spec. Por exemplo, para permitir que um controlador de ingresso apenas manipule o ingresso/rotas com rótulo type=sharded, poderá incluir um routeSelector. Para obter mais informações, consulte Ingress controller sharding.

      routeSelector:
        matchLabels:
          type: sharded
    
    1. Para incluir seletores em um controlador de ingresso existente, obtenha uma lista de controladores de ingresso.

      oc get ingresscontroller -n openshift-ingress-operator
      
    2. Inclua os seletores em controladores de ingresso em que você deseja usar o shard.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      
    3. Note que nenhum seletor é incluído no IngressController padrão, assim, todas as rotas ainda são admitidas no controlador de ingresso padrão no cluster. É possível usar a rota relevante ou um seletor de rótulo de namespace para mudar este comportamento. Por exemplo, para ajustar o roteador padrão para ignorar ingresso/rotas com rótulo type=sharded, execute o comando de correção a seguir.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

      Várias rotas e ingressos no cluster dependem do controlador de ingresso público padrão. Certifique-se de que as alterações estejam corretas antes de editar o controlador Ingress padrão. Para obter mais informações sobre, consulte Ingress controller sharding.

  7. Crie um serviço ClusterIP do Kubernetes para a implementação do seu app. O serviço fornece um endereço IP interno para o app ao qual o controlador de ingresso pode enviar tráfego.

    oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
    
  8. Configure uma rota que se baseie no tipo de finalização TLS requerida por seu app. Se você não incluir a opção --hostname, o nome do host da rota será gerado para você no formato <app_service_name>-<app_project>.<router-subdomain>.

    • Simples:
      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Passagem:
      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      
      É necessário manipular conexões HTTP/2? Depois de criar a rota, execute oc edit route <app_service_name> e mude o valor de targetPort da rota para https. É possível testar a rota executando curl -I --http2 https://<route> --insecure.
    • Borda: se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação do Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Re-criptografar: Se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação da rota Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  9. Verifique se a rota para o seu app está criada.

    oc get routes
    
  10. Opcional: Personalize as regras de roteamento do controlador do Ingresso Público com configurações opcionais. Por exemplo, você pode usar anotações HAProxy específicas da rota.

  11. Para criar rotas para mais apps usando o mesmo subdomínio, é possível repetir as etapas 7 a 10 para que a rota seja gerada pelo mesmo controlador de ingresso público. Se você deseja criar rotas para mais apps usando um subdomínio diferente, repita todas as etapas desta seção para criar um novo controlador de ingresso público com um domínio diferente.

Configurando rotas privadas

Use um controlador de ingresso privado para expor apps em seu cluster na rede privada.

O método para configuração de rotas privadas varia dependendo do provedor de infraestrutura do seu cluster e da configuração do seu terminal em serviço.

Configurando rotas privadas em clusters clássicos ou em clusters de VPC com um terminal em serviço de nuvem pública

Se o seu cluster for criado em uma infraestrutura clássica ou se for criado em uma infraestrutura VPC e você tiver ativado o ponto de extremidade do serviço de nuvem pública durante a criação do cluster, o cluster será criado com apenas um controlador Ingress público por padrão. Para expor privadamente seus apps, deve-se primeiro criar um recurso IngressController privado e configurar o controlador com um subdomínio. O operador de ingresso cria automaticamente e configura um novo controlador de ingresso privado que você pode usar para criar rotas privadas para seus apps.

Observe que mesmo que você crie um recurso IngressController nas etapas a seguir, o IngressController só será necessário para criar e configurar o controlador de ingresso necessário para você. Depois que o controlador de ingresso for criado, use o roteador diretamente para criar rotas.

  1. Prepare o domínio que você deseja utilizar para o seu controlador de ingresso.

    • Domínio customizado, clusters clássicos ou de VPC: para registrar um domínio customizado, trabalhe com o seu provedor de Domain Name Service (DNS) ou DNS do IBM Cloud. Se você deseja usar o mesmo subdomínio para diversos serviços em seu cluster, você pode registrar um subdomínio curinga, como *.example.com.
    • Domínio fornecido pela IBM, clusters de VPC apenas:
      1. Liste os subdomínios existentes em seu cluster. Na coluna Subdomínio da saída, copie o subdomínio que tem o valor de 000<n> mais alto.
        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        
        Nesta saída de exemplo, o subdomínio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud tem o valor 000<n> mais alto de 0002.
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        
      2. No subdomínio que você copiou, mude o valor 000<n> no subdomínio para 000<n+1>. Por exemplo, o subdomínio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud é alterado para mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Você registra este subdomínio nas etapas posteriores.
  2. Crie um arquivo de configuração que configure um controlador do Ingress privado com o domínio da etapa 1.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: private
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      domain: <domain>
      endpointPublishingStrategy:
        loadBalancer:
          scope: Internal
        type: LoadBalancerService
    
  3. Crie o recurso IngressController no namespace openshift-ingress-operator do seu cluster. Ao criar o recurso IngressController, um controlador de ingresso privado é automaticamente criado e implementado no namespace openshift-ingress baseado nas configurações do IngressController. Adicionalmente, um serviço de controlador de ingresso é criado para expor o controlador de ingresso com um endereço IP (clusters clássicos) ou um nome do host de VPC (clusters VPC).

    oc create -f private.yaml -n openshift-ingress-operator
    
  4. Obtenha o endereço IP ou o nome do host da VPC no campo IP EXTERNO do serviço router-private.

    oc get svc router-private -n openshift-ingress
    

    Saída de exemplo para clusters clássicos:

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
    router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
    

    Saída de exemplo para clusters VPC:

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
    router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
    
  5. Registre o endereço IP externo do serviço ou do nome do host da VPC com o domínio que você escolheu na etapa 1.

    • Domínio customizado, clusters clássicos ou VPC: trabalhe com o seu provedor de DNS para incluir o endereço IP externo do serviço como um registro A (clusters clássicos) ou o nome do host de VPC como um CNAME (clusters VPC) que é mapeado para o seu domínio customizado.
    • Domínio fornecido pela IBM, clusters VPC apenas: crie uma entrada de DNS para o nome do host VPC do serviço. Ao executar o comando a seguir, o subdomínio que você especificou na etapa 2 é gerado automaticamente e é registrado com o serviço de controlador de ingresso.
      ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
      
  6. Opcional: se você deseja usar o shard do controlador de ingresso para que rotas específicas sejam manipuladas por um controlador de ingresso específico, por exemplo, rotas privadas admitidas apenas para um roteador privado, você poderá usar rótulos de rota ou de namespace para especificar o método de shard. Para incluir o seletor durante o tempo de criação, inclua-o no yaml ingresscontroller sob spec. Por exemplo, para permitir que um controlador de ingresso apenas manipule o ingresso/rotas com rótulo type=sharded, poderá incluir um routeSelector. Para obter mais informações, consulte Ingress controller sharding.

      routeSelector:
        matchLabels:
          type: sharded
    
    1. Para incluir seletores em um controlador de ingresso existente, obtenha uma lista de controladores de ingresso.

      oc get ingresscontroller -n openshift-ingress-operator
      
    2. Inclua os seletores em controladores de ingresso em que você deseja usar o shard.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      
    3. Note que nenhum seletor é incluído no IngressController padrão, assim, todas as rotas ainda são admitidas no controlador de ingresso padrão no cluster. É possível usar a rota relevante ou um seletor de rótulo de namespace para mudar este comportamento. Por exemplo, para ajustar o roteador padrão para ignorar ingresso/rotas com rótulo type=sharded, execute o comando de correção a seguir.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      
  7. Crie um serviço ClusterIP do Kubernetes para a implementação do seu app. O serviço fornece um endereço IP interno para o app ao qual o controlador de ingresso pode enviar tráfego.

    oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
    
  8. Configure uma rota que se baseie no tipo de finalização TLS requerida por seu app. Especifique o nome do host que você configurou na etapa 5.

    • Simples:
      oc expose service <app_service_name> --hostname <subdomain>
      
    • Passagem:
      oc create route passthrough --service <app_service_name> --hostname <subdomain>
      
      É necessário manipular conexões HTTP/2? Depois de criar a rota, execute oc edit route <app_service_name> e mude o valor de targetPort da rota para https. É possível testar a rota executando curl -I --http2 https://<route> --insecure.
    • Borda: se você usar um domínio personalizado, inclua as opções --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação do Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Re-criptografar: Se você usar um domínio personalizado, inclua as opções --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação da rota Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  9. Verifique se a rota para o seu app está criada.

    oc get routes
    
  10. Opcional: Personalize as regras de roteamento do controlador Ingresso privado com configurações opcionais. Por exemplo, você pode usar anotações HAProxy específicas da rota.

  11. Para criar rotas para mais apps usando o mesmo subdomínio, é possível repetir as etapas 7 a 10 para que a rota seja gerada pelo mesmo controlador de ingresso privado. Se você deseja criar rotas para mais apps usando um subdomínio diferente, repita todas as etapas desta seção para criar um novo controlador de ingresso privado.

Configurando rotas privadas em clusters de VPC com um terminal em serviço de nuvem privada apenas

Se o seu cluster for criado em infraestrutura VPC e você ativou o único terminal em serviço de nuvem privada durante a criação de cluster, seu cluster será criado com um controlador de ingresso privado por padrão. É possível usar este controlador de ingresso para criar rotas privadas para o seu app.

  1. Crie um serviço ClusterIP do Kubernetes para a implementação do seu app. O serviço fornece um endereço IP interno para o app ao qual o controlador de ingresso pode enviar tráfego.

    oc expose deploy <app_deployment_name> --name my-app-svc
    
  2. Escolha um domínio para o seu app.

    • Domínio fornecido pela IBM: se você não precisar usar um domínio customizado, um nome de host de rota será gerado para você no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.
    • Domínio customizado: para especificar um domínio customizado, trabalhe com o seu provedor de DNS ou IBM Cloud® Internet Services.
      1. Obter o endereço IP público para o serviço de controlador de ingresso público em cada zona na coluna IP EXTERNO. Note que o serviço do controlador de ingresso na primeira zona em que você tem nós de trabalhadores é sempre nomeado router-default, e os serviços do controlador de ingresso em zonas que você incluiu posteriormente em seu cluster têm nomes como router-dal12.

        oc get svc -n openshift-ingress
        
      2. Crie um domínio customizado com seu provedor DNS. Se você deseja usar o mesmo subdomínio para diversos serviços em seu cluster, você pode registrar um subdomínio curinga, como *.example.com.

      3. Mapeie seu domínio customizado para o endereço IP privado do controlador de ingresso, incluindo os endereços IP como registros A.

  3. Configure uma rota com base no tipo de terminação TLS que seu app requer. Se você não tiver um domínio personalizado, não inclua a opção --hostname. Um subdomínio de rota é gerado para você no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Se você tiver registrado um subdomínio curinga, especifique um subdomínio exclusivo em cada rota que for criada. Por exemplo, é possível especificar --hostname svc1.example.com nessa rota e --hostname svc2.example.com em outra rota.

    • Simples:

      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Passagem:

      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      

      É necessário manipular conexões HTTP/2? Depois de criar a rota, execute oc edit route <app_service_name> e mude o valor de targetPort da rota para https. É possível testar a rota executando curl -I --http2 https://<route> --insecure.

    • Borda: se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação do Red Hat OpenShift edge route.

      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Re-criptografar: Se você usar um domínio personalizado, inclua as opções --hostname, --cert e --key e, opcionalmente, a opção --ca-cert. Para obter mais informações sobre os requisitos do certificado TLS, consulte a documentação da rota Red Hat OpenShift re-encrypt.

      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  4. Verifique se a rota para o seu serviço de app é criada.

    oc get routes
    
  5. Opcional: Personalize as regras de roteamento padrão com configurações opcionais. Por exemplo, você pode usar anotações HAProxy específicas da rota.

Movimentando serviços do controlador de ingresso em VLANs em clusters clássicos

Quando você altera as conexões de VLAN do nó de trabalho, os nós de trabalho são conectados à nova VLAN e recebem novos endereços IP públicos ou privados. No entanto, os serviços do controlador de ingresso não podem migrar automaticamente para a nova VLAN porque eles recebem a designação de um endereço IP público ou privado móvel estável de uma sub-rede que pertence à antiga VLAN. Quando seus nós do trabalhador e controladores de ingresso estão conectados a VLANs diferentes, os controladores de ingresso não podem encaminhar tráfego de rede de entrada para pods de app em seus nós do trabalhador. Para mover seus serviços do controlador de ingresso para uma VLAN diferente, deve-se criar o serviço de controlador de ingresso na nova VLAN e excluir o serviço de controlador de ingresso na VLAN antiga.

  1. Crie um serviço de controlador de ingresso na nova VLAN.

    1. Crie um arquivo de configuração YAML para um novo serviço de controlador de ingresso. Especificar a zona que o serviço do controlador de ingresso implementa. Salve o arquivo como router-new-<zone>.yaml.
      • Serviço do controlador de ingresso público:
        apiVersion: v1
        kind: Service
        metadata:
          annotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
          finalizers:
          - service.kubernetes.io/load-balancer-cleanup
          labels:
            app: router
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
            router: router-default
          name: router-new-<zone>
          namespace: openshift-ingress
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: http
          - name: https
            port: 443
            protocol: TCP
            targetPort: https
          selector:
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
          sessionAffinity: None
          type: LoadBalancer
        
      • Serviço do controlador de ingresso privado:
        apiVersion: v1
        kind: Service
        metadata:
          annotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
          finalizers:
          - service.kubernetes.io/load-balancer-cleanup
          labels:
            app: router
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
            router: router-private
          name: router-new-<zone>
          namespace: openshift-ingress
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: http
          - name: https
            port: 443
            protocol: TCP
            targetPort: https
          selector:
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
          sessionAffinity: None
          type: LoadBalancer
        
    2. Crie o novo serviço de controlador de ingresso.
      oc apply -f router-new-<zone>.yaml -n openshift-ingress
      
    3. Obtenha o endereço IP EXTERNO do novo serviço de controlador de ingresso. Esse endereço IP é de uma sub-rede na nova VLAN.
      oc get svc router-new -n openshift-ingress
      
      Saída de exemplo para um serviço de controlador de ingresso público:
      NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                     AGE
      router-new                   LoadBalancer   172.21.XX.XX     169.XX.XXX.XX   80:31049/TCP,443:30219/TCP                  2m
      
    4. Clusters multizona: se você mudou as VLANs para nós do trabalhador em várias zonas, repita essas etapas para criar um serviço de controlador de ingresso nas novas VLANs em cada zona.
  2. Observe o Nome do host do controlador de ingresso. Na saída, procure o nome do host formatado como <cluster_name>-<random_hash>-0001.<region>.containers.appdomain.cloud.

    ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
    

    Saída de exemplo

    Hostname                                                                             IP(s)           Health Monitor   SSL Cert Status   SSL Cert Secret Name                            Secret Namespace
    mycluster-35366fb2d3d90fd50548180f69e7d12a-0001.us-east.containers.appdomain.cloud   169.XX.XXX.XX   None             created           roks-ga-35366fb2d3d90fd50548180f69e7d12a-0001   default
    ...
    
  3. Inclua o endereço IP do novo serviço do controlador de ingresso que você encontrou na etapa 1 para o nome do host do controlador de ingresso. Se você criou serviços para várias zonas na etapa 1, inclua cada endereço IP separadamente nas opções repetidas de --ip.

    ibmcloud oc nlb-dns add -c <cluster_name_or_ID> --ip <new_IP> --nlb-host <subdomain>
    

    Seu serviço de controlador de ingresso na nova VLAN agora está registrado com o domínio para o controlador de ingresso padrão em seu cluster, e pode encaminhar solicitações de entrada para apps.

  4. Obtenha o endereço IP do antigo serviço de controlador de ingresso na VLAN antiga. Clusters multizona: se você mudou as VLANs para nós do trabalhador em várias zonas, obtenha o endereço IP para o serviço de controlador de ingresso em cada zona em que as VLANs mudaram. Note que o serviço do controlador de ingresso na primeira zona onde você tem nós de trabalhador é sempre nomeada router-default, e os serviços do controlador de ingresso nas zonas que você posteriormente incluir em seu cluster terão nomes como router-dal12.

    oc get svc -n openshift-ingress
    

    Saída de exemplo para um cluster multizona:

    NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
    router-dal12                  LoadBalancer   172.21.190.62    169.XX.XX.XX     80:32318/TCP,443:30915/TCP   51d
    router-default                LoadBalancer   172.21.47.119    169.XX.XX.XX     80:31311/TCP,443:32561/TCP   78d
    router-internal-default       ClusterIP      172.21.51.30     <none>           80/TCP,443/TCP,1936/TCP      78d
    
  5. Remova o endereço IP do antigo serviço do controlador de ingresso que você encontrou na etapa 2 do nome do host do controlador de ingresso. Clusters de várias zonas: Inclua cada endereço IP separadamente nas opções repetidas de --ip.

    ibmcloud oc nlb-dns rm classic -c <cluster_name_or_ID> --ip <old_IP> --nlb-host <hostname>
    
  6. Verifique se o nome do host para o seu controlador de ingresso está agora registrado com o novo endereço IP. Após o seu nome do host do controlador de ingresso ser atualizado com o endereço IP do novo serviço, não serão necessárias novas mudanças em seu controlador de ingresso ou rotas.

    ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
    
  7. Exclua o serviço de controlador de ingresso na VLAN antiga.

    oc delete svc <old_router_svc> -n openshift-ingress
    
  8. Opcional: se você não precisar mais das sub-redes nas VLANs antigas, será possível removê-las.