Operador de ingresso

O operador Red Hat OpenShift Ingress implementa regras de roteamento que são aplicadas a todo o tráfego de entrada para os aplicativos em seu cluster.

Os controladores do Ingress são gerenciados pelo operador do Ingress. Durante a criação do cluster, o controlador de ingresso padrão é registrado com o subdomínio de ingresso padrão para o seu cluster no formato <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. Ao registrar o seu app com este subdomínio criando um recurso de rota, o controlador de ingresso garante que as solicitações ao seu app por meio deste subdomínio sejam devidamente submetidas a proxy em seus pods de app. Para ver o controlador do Ingress padrão em seu cluster, execute oc describe ingresscontroller/default -n openshift-ingress-operator.

Se você desejar registrar seu app com um domínio diferente, será possível criar um controlador do Ingress customizado que implemente regras de roteamento para um domínio customizado.

Controlador de Ingresso

Um controlador de ingresso Red Hat OpenShift baseado em HAProxy é criado para cada IngressController, e um serviço de controlador de ingresso é criado em cada zona em que você tem nós de trabalhador.

O operador de ingresso configura o controlador de ingresso com o mesmo domínio que é especificado no IngressController. O controlador de ingresso atende às solicitações de serviços HTTP, HTTPS ou TCP recebidas por meio desse domínio. O componente de serviço de balanceador de carga do controlador de ingresso então encaminha solicitações para os pods para esse app apenas de acordo com as regras definidas no recurso de rota e implementadas pelo controlador de ingresso.

Se você tiver um cluster multizona, um controlador de ingresso de alta disponibilidade é implementado em seu cluster e é configurado com um balanceador de carga VPC multizona. 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.

Se você criar manualmente um controlador de ingresso, ele não será registrado automaticamente com o subdomínio de ingresso ou um app em seu cluster.

Recurso de rota

Para expor um app usando a rota, deve-se criar um serviço de Kubernetes para o seu app e registrar este serviço com o controlador de ingresso definindo um recurso de rota. O recurso de ingresso é um recurso Red Hat OpenShift que define as regras para como rotear as solicitações de entrada para apps.

O recurso de rota também especifica o caminho para os serviços do seu app. Os caminhos para os seus serviços de app são anexados ao subdomínio do Ingress do seu cluster para formar uma URL de app exclusiva, como mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1.

One recurso de rota é necessário para cada projeto em que você tem apps que deseja expor.

• Se os apps em seu cluster estiverem todos no mesmo projeto, você deverá criar um recurso de rota para definir as regras de roteamento para os apps que você deseja expor. Observe que, se você desejar usar domínios diferentes para os apps dentro do mesmo projeto, será possível criar um recurso por domínio.
• Se os apps em seu cluster estiverem em projetos diferentes, você deverá criar um recurso de rota para cada projeto para definir as regras de roteamento do app.

Para obter mais informações, consulte Planejando a rede para projetos únicos ou diversos.

Para customizar regras de roteamento para o seu app, é possível usar anotações HAProxy específicas de rota que gerenciam o tráfego para ele. Essas anotações suportadas estão no formato haproxy.router.openshift.io/<annotation> ou router.openshift.io/<annotation>. Observe que as anotações IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) e as anotações NGINX (nginx.ingress.kubernetes.io/<annotation>) não são suportadas para o controlador de ingresso ou o recurso de rota no Red Hat OpenShift versão 4.

Cluster de zona única

O diagrama a seguir mostra como o Ingress direciona a comunicação da Internet para um app em um cluster de zona única clássico.

1. Um usuário envia uma solicitação para seu app acessando a URL do app. Essa URL é o subdomínio do Ingress para o cluster anexado com o caminho de recursos do Ingress para o app exposto, como mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Um serviço de sistema DNS resolve o subdomínio na URL para o endereço IP público móvel do balanceador de carga que expõe o controlador de ingresso em seu cluster.

3. Com base no endereço IP resolvido, o cliente envia a solicitação para o serviço de controlador de ingresso.

4. O controlador de ingresso verifica as regras de roteamento que são implementadas pelo controlador de ingresso para uma regra de roteamento para o caminho myapp. Se uma regra de correspondência for encontrada, a solicitação será submetida a proxy de acordo com as regras que você definiu no controlador de ingresso e o recurso de rota para o pod em que o app é implementado. O endereço IP de origem do pacote é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Se várias instâncias do app forem implementadas no cluster, a carga do controlador de ingresso balanceará as 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 em que o controlador de ingresso que encaminhou a solicitação existe. O controlador de ingresso então envia o pacote de resposta para o cliente.

Cluster multizona

O diagrama a seguir mostra como o Ingress direciona a comunicação da Internet para um aplicativo em um cluster multizona clássico.

1. Um usuário envia uma solicitação para seu app acessando a URL do app. Essa URL é o subdomínio do Ingress para o cluster anexado com o caminho de recursos do Ingress para o app exposto, como mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Um serviço de sistema DNS resolve o subdomínio da rota para o endereço IP público flutuante de um serviço de controlador de ingresso que foi relatado como funcional pelo MZLB. O MZLB verifica continuamente os endereços IP públicos móveis dos serviços que expõem o controlador de ingresso em cada zona do seu cluster. As solicitações são tratados pelos serviços do controlador de ingresso em várias zonas em um ciclo de round-robin.

3. O cliente envia a solicitação para o endereço IP do serviço que expõe o controlador de ingresso.

4. O controlador de ingresso verifica as regras de roteamento que são implementadas pelo controlador de ingresso para o caminho myapp. Se uma regra de correspondência for encontrada, a solicitação será submetida a proxy de acordo com as regras que você definiu no controlador de ingresso e no recurso de rota para o pod em que o app é implementado. O endereço IP de origem do pacote é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Se várias instâncias do app forem implementadas no cluster, o serviço de controlador de ingresso enviará as solicitações entre os pods do app em todas as zonas.

5. Quando o app retorna um pacote de resposta, ele usa o endereço IP do nó do trabalhador em que o serviço de controlador de ingresso que encaminhou a solicitação existe. O controlador de ingresso então envia o pacote de resposta para o cliente.

Cluster de VPC 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 diagrama a seguir mostra como o Ingress direciona a comunicação da Internet para um aplicativo em um cluster multizona do VPC.

1. Um usuário envia uma solicitação para seu app acessando a URL do app. Essa URL é o subdomínio do Ingress para o cluster para o app exposto anexado com o caminho de recursos do Ingress, como mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

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

3. O balanceador de carga VPC resolve o nome do host VPC para um endereço IP disponível em uma zona para o controlador de ingresso que foi relatado como funcional. O balanceador de carga VPC verifica continuamente os endereços IP externos para 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 controlador de ingresso.

5. O controlador de ingresso verifica as regras de roteamento que são implementadas pelo controlador de ingresso para o caminho myapp. Se uma regra de correspondência for encontrada, a solicitação será submetida a proxy de acordo com as regras que você definiu no controlador de ingresso e no recurso de rota para o pod em que o app é implementado. O endereço IP de origem do pacote é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Se várias instâncias do app forem implementadas no cluster, a carga do controlador de ingresso balanceará s solicitações entre os pods do app em todas as zonas.

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

Cluster de VPC 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. Somente os clientes conectados à sua rede VPC privada podem acessar apps que são expostos por um controlador do Ingress privado. O diagrama a seguir mostra como o Ingress direciona a comunicação de redes privadas para um app em um cluster multizona VPC.

1. Um cliente conectado à sua rede VPC privada envia uma solicitação para o seu app usando a URL do seu app. Essa URL é o subdomínio do Ingress para o cluster para o app exposto anexado com o caminho de recursos do Ingress, como mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp. 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 privados dos seus serviços de 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 verifica as regras de roteamento que são implementadas pelo controlador de ingresso para o caminho myapp. Se uma regra de correspondência for encontrada, a solicitação será submetida a proxy de acordo com as regras que você definiu no controlador de ingresso e no recurso de rota para o pod em que o app é implementado. O endereço IP de origem do pacote é mudado para o endereço IP do nó do trabalhador em que o pod do controlador de ingresso é executado. Se várias instâncias do app forem implementadas no cluster, a carga do controlador de ingresso balanceará s solicitações entre os pods do app em todas as zonas.

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.