Compreendendo opções para expor apps

Para expor de forma segura seus apps ao tráfego externo, é possível escolher entre os serviços a seguir.

Controlador de ingresso do Red Hat OpenShift

Exponha vários aplicativos em um cluster configurando o roteamento com o controlador Red Hat OpenShift Ingress. O controlador de Ingress usa o subdomínio de Ingress como um ponto de entrada público ou privado seguro e exclusivo para rotear solicitações recebidas. É possível usar um subdomínio para expor diversos apps em seu cluster como serviços. A Solução do controlador de ingresso usa três componentes.

• O oerador de ingresso que gerencia os controladores de ingresso em seu cluster.
• O controlador do Ingress é um serviço do Kubernetes baseado em HAProxy que gerencia todo o tráfego recebido para os apps em seu cluster, implementando regras de roteamento para os apps. Esse controlador é gerenciado pelo operador do Ingress. O controlador de ingresso atende a solicitações de serviços HTTP, ou HTTPS recebidas e, em seguida, encaminha solicitações para os pods para esse app apenas de acordo com as regras definidas no recurso de ingresso e implementadas pelo controlador de ingresso.
• O recurso de rota define as regras para como rotear e carregar solicitações recebidas de balanceamento para um app.

Uma rota expõe um serviço como um nome de host no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Um controlador de ingresso é implementado por padrão em seu cluster, que possibilita que as rotas sejam usadas por clientes externos. O controlador de ingresso utiliza o seletor de serviço para encontrar o serviço e os terminais que apoiam o serviço. É possível configurar o seletor de serviço para direcionar o tráfego por meio de uma rota para diversos serviços. Também é possível criar rotas não seguras ou seguras usando o certificado TLS que é atribuído pelo controlador de ingresso para o seu nome de host. Observe que o controlador de ingresso suporta apenas os protocolos HTTP e HTTPS.

NodePort

Quando você expõe apps com um serviço NodePort, um NodePort no intervalo de 30000 a 32767 e um endereço IP interno do cluster são designados ao serviço. Para acessar o serviço de fora do cluster, use o endereço IP público ou privado de qualquer nó do trabalhador e o NodePort no formato <IP_address>:<nodeport>. No entanto, os endereços IP públicos e privados do nó do trabalhador não são permanentes. Quando um nó do trabalhador é removido ou recriado, um novo endereço IP público e um privado são designados ao nó do trabalhador. NodePorts são ideais para testar o acesso público ou privado ou fornecer acesso apenas por um curto período de tempo.

LoadBalancer

O tipo de serviço LoadBalancer é implementado de forma diferente, dependendo do provedor de infraestrutura de seu cluster.

• Clusters clássicos: Balanceador de carga em rede (NLB). Cada cluster padrão é provisionado com quatro endereços IP públicos e privados móveis que podem ser usados para criar um balanceador de carga de rede TCP/UDP (NLB) de camada 4 para seu app. É possível customizar seu NLB expondo qualquer porta necessária ao seu app. Os endereços IP público e privado móveis que são designados ao NLB são permanentes e não mudam quando um nó do trabalhador é recriado no cluster. Se você criar NLBs públicos, será possível criar um subdomínio para seu app que registre os endereços IP de NLB públicos com uma entrada de DNS. Também é possível ativar monitores de verificação de funcionamento nos IPs do NLB para cada subdomínio.
• Clusters VPC: Balanceador de carga para VPC. Ao criar um serviço LoadBalancer do Kubernetes para um app em seu cluster, um balanceador de carga do VPC de camada 7 é criado automaticamente em seu VPC fora de seu cluster. O balanceador de carga do VPC é multizonal e roteia solicitações para seu app por meio dos NodePorts privados que são abertos automaticamente em seus nós do trabalhador. Por padrão, o balanceador de carga também é criado com um hostname que você pode usar para acessar o seu app, mas também é possível criar um subdomínio para o seu app que cria uma entrada DNS.

Ingresso

É possível usar o Ingresso para expor seu app ao tráfego externo por meio do controlador do Ingresso Red Hat OpenShift. O Red Hat OpenShift Controller Manager converte seus recursos de ingresso em recursos de rota e o controlador de ingresso do Red Hat OpenShift processa essas rotas.

Escolhendo entre soluções de balanceamento de carga

Agora que você entende quais opções você tem para expor apps em seu cluster Red Hat OpenShift, escolha a melhor solução para a sua carga de trabalho.

A tabela a seguir compara os recursos de cada método de exposição de app.

* A finalização de SSL é fornecida pelos comandos ibmcloud oc nlb-dns. Em clusters clássicos, esses comandos são suportados apenas para NLBs públicos.

Planejando o balanceamento de carga externa pública

Exponha publicamente um app em seu cluster para a Internet.

Em clusters clássicos, seus nós do trabalhador estão conectados a uma VLAN pública. A VLAN pública determina o endereço IP público que é designado a cada nó do trabalhador, que fornece a cada nó do trabalhador uma interface de rede pública. Os serviços de rede pública se conectam a essa interface de rede pública, fornecendo ao seu app um endereço IP público e, opcionalmente, uma URL pública.

Em clusters VPC, os nós do trabalhador são conectados somente a sub-redes privadas do VPC. No entanto, ao criar serviços de rede pública, um balanceador de carga do VPC é criado automaticamente. O balanceador de carga do VPC pode rotear solicitações públicas para seu app fornecendo a ele uma URL pública. Quando um app é exposto publicamente, qualquer um que tenha a URL pública pode enviar uma solicitação para o app.

Quando um app é publicamente exposto, qualquer pessoa que tenha o endereço IP de serviço público ou a URL configurada para ele pode enviar uma solicitação para seu app. Por essa razão, exponha o mínimo de apps possível. Somente exponha um app para o público quando ele estiver pronto para aceitar o tráfego de clientes ou usuários externos da web.

A interface de rede pública para os nós do trabalhador é protegida por configurações de política de rede do Calico predefinidas que são configuradas em cada nó do trabalhador durante a criação do cluster. Por padrão, todo o tráfego de rede de saída é permitido para todos os nós do trabalhador. O tráfego de rede de entrada está bloqueado, exceto para algumas portas. Essas portas são abertas para que a IBM possa monitorar o tráfego de rede e instalar automaticamente atualizações de segurança para o mestre do Kubernetes e para que as conexões possam ser estabelecidas para serviços de rede pública. Para obter mais informações sobre essas políticas, incluindo como modificá-las, veja Políticas de rede.

Planejando o balanceamento de carga externa privado

Exponha de forma privada um app em seu cluster somente para a rede privada.

Quando você implementa um app em um cluster Kubernetes no IBM Cloud Kubernetes Service, é possível que você deseje torná-lo acessível somente para usuários e serviços na mesma rede privada que seu cluster. O balanceamento de carga privado é ideal para tornar seu app disponível para solicitações de fora do cluster sem o expor ao público em geral. Também é possível usar o balanceamento de carga privado para testar o acesso, o roteamento de solicitação e outras configurações para seu app antes de ele ser exposto posteriormente para o público com serviços de rede pública.

Como exemplo, suponha que você criou um balanceador de carga privado para seu app. Esse balanceador de carga privado pode ser acessado por:

• Qualquer pod no mesmo cluster.
• Qualquer pod em qualquer cluster na mesma conta do IBM Cloud.
• Se você não estiver na conta do IBM Cloud, mas ainda estiver atrás do firewall da empresa, qualquer sistema por meio de uma conexão VPN com a sub-rede na qual o IP do balanceador de carga está.
• Se você estiver em uma conta IBM Cloud diferente, qualquer sistema por meio de uma conexão VPN com a sub-rede na qual o IP do balanceador de carga estiver.
• Em clusters clássicos, se você tiver o VRF ou o VLAN Spanning ativado, qualquer sistema que esteja conectado a qualquer uma das VLANs privadas na mesma conta do IBM Cloud.
• Em clusters VPC:
  • Se o tráfego for permitido entre as sub-redes do VPC, qualquer sistema no mesmo VPC.
  • Se o tráfego for permitido entre VPCs, qualquer sistema que tenha acesso ao VPC no qual o cluster está.