Considerações sobre topologia de rede e conectividade para o Red Hat OpenShift no Azure

Examine as considerações e recomendações de design para topologia de rede e conectividade ao usar o acelerador de zona de destino do Red Hat OpenShift no Azure.

Considerações sobre o design

• O Red Hat OpenShift no Azure requer uma sub-rede primária e uma sub-rede secundária.

  • Use a sub-rede primária para implantar os nós principais do cluster.
  • Use a sub-rede secundária para implantar os nós de trabalho do cluster.
  • A sub-rede secundária e a sub-rede primária devem ser uma rota mínima /27 .
  • Você não pode alterar a sub-rede secundária ou a sub-rede primária depois de implantar o cluster.
  • A sub-rede primária e a sub-rede secundária não podem ter um grupo de segurança de rede associado a elas. O cluster do Red Hat OpenShift no Azure cria e gerencia automaticamente um grupo de segurança de rede.
  • A sub-rede secundária e a sub-rede primária não podem se sobrepor a redes locais ou a qualquer outra rede no Azure.

• Planeje cuidadosamente os endereços IP e o tamanho da sub-rede da rede virtual para dar suporte ao dimensionamento do cluster. Talvez seja necessário adicionar nós.

• Você pode expor os serviços e rotas do Red Hat OpenShift no Azure usando balanceadores de carga públicos ou internos. Configure balanceadores de carga internos na mesma sub-rede que os nós secundários. Em um cluster de saída restrito, você não pode usar balanceadores de carga públicos devido ao roteamento assimétrico.

• O Red Hat OpenShift no Azure usa o CoreDNS para fornecer resolução de nomes para pods em execução no cluster.

  • O CoreDNS resolve diretamente domínios internos do cluster.
  • O Red Hat OpenShift no Azure também dá suporte a servidores DNS personalizados na rede virtual.
  • Outros domínios são encaminhados para os servidores DNS configurados na Rede Virtual do Azure. Os servidores DNS serão o resolvedor de DNS padrão do Azure ou todos os servidores DNS personalizados configurados no nível da rede virtual.
  • Você pode personalizar o encaminhamento de DNS no Red Hat OpenShift CoreDNS no Azure.
  • Se nenhum servidor DNS personalizado estiver configurado na rede virtual, o Red Hat OpenShift no Azure usará o resolvedor de DNS do Azure padrão.

  Para obter mais informações sobre DNS, consulte Configuração de DNS do Ponto de Extremidade Privado do Azure.

• Você pode enviar tráfego de rede de saída (saída) por meio do Firewall do Azure ou por meio de um cluster de solução de virtualização de rede.

  • Por padrão, os clusters do Red Hat OpenShift no Azure têm acesso irrestrito à Internet de saída.
  • Você pode implantar o Red Hat OpenShift no Azure com tráfego de saída restrito adicionando uma UDR (rota definida pelo usuário) que tenha uma 0.0.0.0/0 rota para o Firewall do Azure ou para uma solução de virtualização de rede. O Red Hat OpenShift no Azure tem uma função de bloqueio de saída que garante o acesso, mesmo que o tráfego de saída seja restrito por um dispositivo de firewall ou por outros meios.
  • Você pode escolher entre dois modelos de implantação do Red Hat OpenShift no Azure:
    • Ponto de extremidade do servidor de API privada e controlador de entrada privado
    • Ponto de extremidade do servidor de API pública e controlador de entrada pública
  • Se você usar o acesso de saída irrestrito, deverá gerenciar cuidadosamente as portas de saída para garantir que não use todas as portas de saída disponíveis. Para obter mais informações, consulte Usar SNAT (Conversão de Endereços de Rede de Origem) para conexões de saída.

• Por padrão, todos os pods em um cluster do Red Hat OpenShift no Azure podem enviar e receber tráfego sem limitações. Todos os pods em um projeto podem ser acessados de outros pods e pontos de extremidade de rede. Para isolar um ou mais pods em um projeto, você pode criar NetworkPolicy objetos no projeto para indicar as conexões de entrada permitidas. A rede definida por software (SDN) do Red Hat OpenShift oferece suporte ao uso da política de rede em seu modo de isolamento de rede padrão.

• A malha de serviço fornece funcionalidades, como gerenciamento de tráfego, resiliência, política, segurança, identidade forte e observabilidade. Para obter mais informações sobre o Red Hat OpenShift Service Mesh, consulte Diferenças entre o Service Mesh e o Istio.

• Mecanismos globais de balanceamento de carga, como o Gerenciador de Tráfego do Azure e o Azure Front Door , aumentam a resiliência roteando o tráfego entre vários clusters, potencialmente em diferentes regiões do Azure.

Clusters privados

Um endereço IP do cluster da API do Red Hat OpenShift no Azure pode ser público ou privado. Os clusters privados expõem a API do Red Hat OpenShift no Azure por meio de um endereço IP privado, mas não por meio de um público. A API do Red Hat OpenShift no Azure não deve ser acessada por meio de seu endereço IP. Em vez disso, acesse a API do Red Hat OpenShift no Azure por meio de seu FQDN (nome de domínio totalmente qualificado). O DNS do Azure resolve o FQDN da API do Red Hat OpenShift no Azure para seu endereço IP.

De acordo com as práticas comprovadas da zona de destino do Azure, a resolução DNS para cargas de trabalho do Azure é oferecida por servidores DNS centralizados implantados na assinatura de conectividade. Os servidores DNS do Azure estão em uma rede virtual de hub ou em uma rede virtual de serviços compartilhados conectada a uma instância da WAN Virtual do Azure. Os servidores DNS resolvem condicionalmente nomes públicos e específicos do Azure usando o DNS do Azure (endereço 168.63.129.16IP). Os servidores resolvem nomes privados usando servidores DNS corporativos. Esse modelo de conectividade é comum e é importante permitir o acesso privado a outros recursos do Azure se você usar pontos de extremidade privados.

Tráfego de usuários do aplicativo para o cluster

Use controladores de entrada (entrada) para expor aplicativos em execução nos clusters do Red Hat OpenShift no Azure.

• Os controladores de entrada fornecem roteamento no nível do aplicativo com apenas um ligeiro aumento na complexidade.
• O Red Hat OpenShift no Azure cria uma entrada DNS genérica que simplifica o acesso a aplicativos expostos no cluster. Um exemplo de entrada DNS é *.apps.<cluster-ID>.<region>.aroapp.io. É útil para um cluster privado rotear o tráfego para o aplicativo.
• O Red Hat OpenShift no Azure oferece um controlador de entrada e rotas internos.
• Você pode usar a entrada do Red Hat OpenShift no Azure com o Azure Front Door.
• Alinhe sua configuração com o design de filtragem de saída para evitar roteamento assimétrico. As UDRs podem causar roteamento assimétrico.
• Se o cenário exigir a terminação TLS, considere como você gerenciará os certificados TLS.

Importante

Se você usar o Firewall do Azure para restringir o tráfego de saída e criar uma UDR para forçar todo o tráfego de saída, certifique-se de criar uma regra DNAT (Conversão de Endereços de Rede de Destino) apropriada no Firewall do Azure para permitir corretamente o tráfego de entrada. Usar o Firewall do Azure com uma UDR interrompe a configuração de entrada devido ao roteamento assimétrico. O problema ocorrerá se a sub-rede do Red Hat OpenShift no Azure tiver uma rota padrão que vai para o endereço IP privado do firewall, mas você estiver usando um balanceador de carga público (entrada ou serviço Kubernetes do tipo Load Balancer). Nesse caso, o tráfego de entrada do balanceador de carga é recebido por meio de seu endereço IP público, mas o caminho de retorno passa pelo endereço IP privado do firewall. Como o firewall é stateful, ele descarta o pacote de retorno porque o firewall não detecta uma sessão estabelecida. Para saber como integrar o Firewall do Azure com o balanceador de carga de serviço ou de entrada, confira Integrar o Firewall do Azure com o Azure Standard Load Balancer.

As etapas a seguir descrevem o fluxo se você usar o Azure Front Door com um cluster privado do Red Hat OpenShift no Azure e um controlador de entrada:

1. Os clientes da Internet pública resolvem o nome DNS do aplicativo que aponta para o Azure Front Door.
2. O Azure Front Door usa o serviço Link Privado do Azure para acessar o endereço IP privado do balanceador de carga de rede interna do Azure e acessar um aplicativo no controlador de entrada do Red Hat OpenShift no Azure.

Estas etapas descrevem o fluxo de um aplicativo não Web que acessa um cluster privado do Red Hat OpenShift no Azure:

1. Os clientes da Internet pública resolvem o nome DNS do aplicativo que aponta para o endereço IP público do Firewall do Azure ou de uma solução de virtualização de rede.
2. O Firewall do Azure ou a solução de virtualização de rede encaminha o tráfego (DNAT) para o cluster privado do Red Hat OpenShift no Azure usando o endereço IP privado do balanceador de carga de rede interna do Azure para acessar o aplicativo no controlador de entrada do Red Hat OpenShift no Azure.

Tráfego dos pods do Red Hat OpenShift no Azure para serviços de back-end

Os pods em execução no cluster do Red Hat OpenShift no Azure podem precisar acessar serviços de back-end, como Armazenamento do Azure, Azure Key Vault, Banco de Dados SQL do Azure e Azure Cosmos DB. Você pode usar pontos de extremidade de serviço de rede virtual e Link Privado do Azure para proteger a conectividade com esses serviços gerenciados pelo Azure.

Se você estiver usando pontos de extremidade privados do Azure para tráfego de back-end, poderá usar zonas DNS privadas do Azure para resolução de DNS para os serviços do Azure. Como os resolvedores DNS de todo o ambiente estão na rede virtual do hub (ou na rede virtual de serviços compartilhados, se você usar o modelo de conectividade da WAN Virtual), crie essas zonas privadas na assinatura de conectividade. Para criar o registro A necessário para resolver o FQDN do serviço privado, você pode associar a zona DNS privada na assinatura de conectividade ao ponto de extremidade privado na assinatura do aplicativo. Essa operação requer permissões específicas nessas assinaturas.

Você pode criar manualmente os registros A, mas associar a zona DNS privada ao ponto de extremidade privado resulta em uma configuração menos propensa a configurações incorretas.

A conectividade de back-end de pods do Red Hat OpenShift no Azure para serviços de PaaS (plataforma como serviço) do Azure expostos por meio de pontos de extremidade privados segue esta sequência:

1. Os pods do Red Hat OpenShift no Azure resolvem o FQDN do PaaS do Azure usando os servidores DNS centrais na assinatura de conectividade, que são definidos como servidores DNS personalizados na rede virtual Red Hat OpenShift no Azure.
2. O endereço IP resolvido é o endereço IP privado dos pontos de extremidade privados, que são acessados diretamente dos pods do Red Hat OpenShift no Azure.

Por padrão, o tráfego entre os pods do Red Hat OpenShift no Azure e os pontos de extremidade privados não passa pela instância do Firewall do Azure na rede virtual do hub (ou pelo hub virtual seguro, se você estiver usando uma WAN Virtual), mesmo que o cluster do Red Hat OpenShift no Azure esteja configurado para filtragem de saída com o Firewall do Azure. O ponto de extremidade privado cria uma /32 rota nas sub-redes da rede virtual do aplicativo na qual o Red Hat OpenShift do Azure é implantado.

Recomendações sobre design

• Se sua política de segurança exigir que você use um endereço IP privado para a API do Red Hat OpenShift no Azure, implante um cluster privado do Red Hat OpenShift no Azure.
• Use a Proteção contra DDoS do Azure para proteger a rede virtual que você usa para o cluster do Red Hat OpenShift no Azure, a menos que você use o Firewall do Azure ou o Firewall de Aplicativo Web em uma assinatura centralizada.
• Use a configuração DNS vinculada à configuração geral da rede com a WAN Virtual do Azure ou uma arquitetura hub and spoke, zonas DNS do Azure e sua própria infraestrutura DNS.
• Use o Link Privado do Azure para proteger conexões de rede e use a conectividade baseada em IP privado com outros serviços gerenciados do Azure que dão suporte ao Link Privado, como o Armazenamento do Azure, o Registro de Contêiner do Azure, o Banco de Dados SQL do Azure e o Azure Key Vault.
• Use um controlador de entrada para fornecer roteamento HTTP avançado e segurança e para oferecer um único ponto de extremidade para aplicativos.
• Todos os aplicativos Web configurados para usar uma entrada devem usar criptografia TLS e não devem permitir acesso por HTTP não criptografado.
• Use o Azure Front Door com o Firewall de Aplicativo Web para publicar com segurança aplicativos Red Hat OpenShift no Azure na Internet.
• Se sua política de segurança exigir que você inspecione todo o tráfego de saída da Internet gerado no cluster do Red Hat OpenShift no Azure, proteja o tráfego de rede de saída usando o Firewall do Azure ou uma solução de virtualização de rede de terceiros implantada na rede virtual do hub gerenciado. Para obter mais informações, consulte Controlar o tráfego de saída para um cluster do Red Hat OpenShift no Azure.
• Use a camada Standard do Azure Load Balancer em vez da camada Básica para aplicativos não Web.

Próximas etapas

• Planeje sua organização de recursos para o Red Hat OpenShift no Azure.