Sobre o Ingress
O Ingress é um serviço que balanceia as cargas de trabalho de tráfego de rede em seu cluster, encaminhando solicitações públicas ou privadas para os seus apps. É possível usar o Ingress para expor diversos serviços de app para a rede pública ou privada usando um domínio público ou privado exclusivo.
Em seu cluster, o controlador de ingresso do Red Hat OpenShift é um balanceador de carga de camada 7 que implementa um controlador de ingresso do HAProxy. Um serviço de camada 4 LoadBalancer
expõe o controlador de ingresso para que
ele possa receber solicitações externas que entram em seu cluster. O controlador de ingresso então encaminha as solicitações para os pods de app em seu cluster com base em características de protocolo de camada 7 diferenciadas, como os cabeçalhos.
Quais são os componentes do Ingress?
Em clusters que executam o Red Hat OpenShift versão 4, o ingresso consiste em três componentes: um operador de ingresso, um controlador de ingresso e os recursos de rota.
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.
Clusters clássicos: Endereços IP do controlador de entrada
Para localizar os endereços IP dos serviços do controlador de ingresso padrão, execute oc get svc -n openshift-ingress
e procure o campo IP EXTERNO. Se você tiver um cluster multizona, note que o serviço do
controlador de ingresso na primeira zona em que você tem nós de trabalhadores será sempre nomeado 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
.
Clusters de VPC: Nomes de host do controlador de entrada
Ao criar um cluster VPC, um balanceador de carga de VPC multizona público e um privado são criados automaticamente fora de seu cluster em seu VPC. O balanceador de carga VPC público cria um nome de host para registrar o controlador de ingresso público, e o balanceador de carga do VPC privado cria um nome de host para registrar o controlador de ingresso privado. Em clusters VPC, um nome do host é designado aos controladores de ingresso porque os endereços IP externos não são estáticos e podem mudar ao longo do tempo. Note que este nome de host do controlador de ingresso é diferente do subdomínio de ingresso padrão para o seu cluster.
O subdomínio do Ingress para seu cluster é vinculado automaticamente ao nome do host do balanceador de carga da VPC para seu controlador de ingresso público. Observe que o subdomínio do Ingress para o cluster, que é semelhante a <cluster_name>.<hash>-0000.<region>.containers.appdomain.cloud
,
é diferente do nome do host designado pelo balanceador de carga da VPC para o controlador de ingresso público, que é semelhante a 01ab23cd-<region>.lb.appdomain.cloud
. O subdomínio do Ingress é a rota pública por meio
da qual os usuários acessam seu app da Internet e pode ser configurado para usar a finalização de TLS. O nome do host designado para o seu controlador de ingresso público é o que o balanceador de carga VPC usa para encaminhar o tráfego
para o serviço de controlador de ingresso.
É possível localizar o nome do host que é designado para o seu controlador de ingresso público e o nome do host que é atribuído ao seu controlador de ingresso privado executando oc get svc -n openshift-ingress
e procurando o
campo IP EXTERNO.
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.
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.
Como uma solicitação chega ao meu app em um cluster clássico?
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.
-
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
. -
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.
-
Com base no endereço IP resolvido, o cliente envia a solicitação para o serviço de controlador de ingresso.
-
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. -
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.
-
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
. -
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.
-
O cliente envia a solicitação para o endereço IP do serviço que expõe o controlador de ingresso.
-
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. -
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.
Como uma solicitação chega ao meu app em um cluster de VPC?
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.
-
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
. -
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.
-
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.
-
Com base no endereço IP resolvido, o balanceador de carga VPC envia a solicitação para um controlador de ingresso.
-
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. -
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.
-
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. -
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.
-
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.
-
Com base no endereço IP resolvido, o balanceador de carga VPC envia a solicitação para um serviço de controlador de ingresso.
-
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. -
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.
Como customizar o roteamento?
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>
.
As anotações do IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>
) e as anotações do 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.
Para começar, consulte Customizando o Ingresso
Como ativar certificados TLS?
Para realizar o balanceamento de carga das conexões HTTPS recebidas para o seu subdomínio, é possível configurar o controlador de ingresso para decriptografar o tráfego de rede e encaminhar a solicitação decriptografada para os apps que estão expostos em seu cluster.
Ao configurar o controlador de ingresso público, você escolhe o domínio por meio do qual seus apps são acessíveis. Se você usar o domínio fornecido pela IBM, como mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp
,
será possível usar o certificado TLS padrão que é criado para o subdomínio do Ingress. Se você configurar um registro do CNAME para mapear um domínio customizado para o domínio fornecido pela IBM, será possível fornecer seu próprio certificado
TLS para o seu domínio customizado.
Para obter mais informações sobre certificados TLS, consulte Gerenciando certificados TLS e segredos.