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

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

Considerações de design

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

  • Use a sub-rede primária para implantar os nós mestres 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 .
  • Não é possível 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 Azure Red Hat OpenShift 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 sobrepor-se 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 do 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, não é possível usar balanceadores de carga públicos devido ao roteamento assimétrico.

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

  • CoreDNS resolve diretamente domínios internos do cluster.
  • O Azure Red Hat OpenShift também oferece 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 do Azure padrão ou quaisquer servidores DNS personalizados configurados no nível da rede virtual.
  • Você pode personalizar o encaminhamento de DNS no Azure Red Hat OpenShift CoreDNS.
  • Se nenhum servidor DNS personalizado estiver configurado na rede virtual, o Azure Red Hat OpenShift usará o resolvedor de DNS padrão do Azure.

  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 de um cluster de dispositivo virtual de rede.

  • Por padrão, os clusters do Azure Red Hat OpenShift têm acesso irrestrito à Internet de saída.
  • Você pode implantar o Azure Red Hat OpenShift com tráfego de saída restrito adicionando uma rota definida pelo usuário (UDR) que tenha uma 0.0.0.0/0 rota para o Firewall do Azure ou para um dispositivo virtual de rede. O Azure Red Hat OpenShift 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 Azure Red Hat OpenShift:
    • Ponto de extremidade do servidor de API privado e controlador de entrada privado
    • Ponto de extremidade do servidor de API pública e controlador de entrada pública
  • Se você usa acesso de saída irrestrito, deve gerenciar cuidadosamente as portas de saída para ter certeza de que não usa todas as portas de saída disponíveis. Para obter mais informações, consulte Usar a conversão de endereços de rede de origem (SNAT) para conexões de saída.

• Por padrão, todos os pods em um cluster do Azure Red Hat OpenShift podem enviar e receber tráfego sem limitações. Todos os pods em um projeto são acessíveis a partir 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. O Red Hat OpenShift software-defined networking (SDN) suporta o uso da política de rede em seu modo de isolamento de rede padrão.

• Uma malha de serviço fornece recursos 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 Service Mesh e Istio.

• Os mecanismos globais de balanceamento de carga, como o Azure Traffic Manager 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 de cluster do Azure Red Hat OpenShift API pode ser público ou privado. Os clusters privados expõem a API do Azure Red Hat OpenShift sobre um endereço IP privado, mas não sobre um endereço público. A API do Azure Red Hat OpenShift não deve ser acessada por meio de seu endereço IP. Em vez disso, acesse a API do Azure Red Hat OpenShift por meio de seu FQDN (nome de domínio totalmente qualificado). O DNS do Azure resolve o FQDN da API do Azure Red Hat OpenShift para seu endereço IP.

Em linha com as práticas comprovadas da zona de aterrissagem do Azure, a resolução DNS para cargas de trabalho do Azure é oferecida por servidores DNS centralizados que são 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 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 Azure Red Hat OpenShift.

• Os controladores de ingresso fornecem roteamento no nível do aplicativo com apenas um ligeiro aumento na complexidade.
• O Azure Red Hat OpenShift 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 Azure Red Hat OpenShift oferece um controlador de entrada e rotas integrados.
• Você pode usar a entrada do Azure Red Hat OpenShift com o Azure Front Door.
• Alinhe sua configuração com o design de filtragem de saída para evitar roteamento assimétrico. UDRs potencialmente podem causar roteamento assimétrico.
• Se o seu cenário exigir o encerramento do 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 um UDR para forçar todo o tráfego de saída, certifique-se de criar uma regra de Conversão de Endereço de Rede (DNAT) de destino apropriada no Firewall do Azure para permitir corretamente o tráfego de entrada. Usar o Firewall do Azure com um UDR interrompe a configuração de entrada devido ao roteamento assimétrico. O problema ocorre se a sub-rede do Azure Red Hat OpenShift tiver uma rota padrão que vá para o endereço IP privado do firewall, mas você estiver usando um balanceador de carga público (ingress ou serviço Kubernetes do tipo Load Balancer). Nesse caso, o tráfego do balanceador de carga de entrada é 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 tem monitoração de estado, ele descarta o pacote que retorna porque o firewall não deteta uma sessão estabelecida. Para saber como integrar o Firewall do Azure ao seu balanceador de carga de entrada ou serviço, consulte Integrar o Firewall do Azure ao Balanceador de Carga Padrão do Azure.

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

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

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

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 para um dispositivo virtual de rede.
2. O Firewall do Azure ou o dispositivo virtual de rede encaminha o tráfego (DNAT) para o cluster privado do Azure Red Hat OpenShift usando o endereço IP privado do balanceador de carga de rede interno do Azure para acessar o aplicativo no controlador de entrada do Azure Red Hat OpenShift.

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

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

Se estiver a utilizar pontos de extremidade privados do Azure para tráfego back-end, pode utilizar zonas DNS privadas do Azure para resolução de DNS para os serviços do Azure. Como os resolvedores de DNS para 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 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. Esta 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 dos pods do Azure Red Hat OpenShift para os serviços da plataforma Azure como serviço (PaaS) expostos por meio de pontos de extremidade privados segue esta sequência:

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

O tráfego entre os pods do Azure Red Hat OpenShift e os pontos de extremidade privados por padrão 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 Azure Red Hat OpenShift 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 Azure Red Hat OpenShift é implantado.

Recomendações de design

• Se sua política de segurança exigir que você use um endereço IP privado para a API do Azure Red Hat OpenShift, implante um cluster privado do Azure Red Hat OpenShift.
• Use a Proteção contra DDoS do Azure para proteger a rede virtual que você usa para o cluster do Azure Red Hat OpenShift, a menos que você use o Firewall do Azure ou o Firewall de Aplicativo Web em uma assinatura centralizada.
• Use a configuração de DNS vinculada à configuração geral da rede com a WAN Virtual do Azure ou uma arquitetura de hub and spoke, zonas DNS do Azure e sua própria infraestrutura DNS.
• Use o Azure Private Link para proteger conexões de rede e use a conectividade privada baseada em IP para outros serviços gerenciados do Azure que dão suporte ao Private Link, como o Armazenamento do Azure, o Registro de Contêiner do Azure, o Banco de Dados SQL do Azure e o Cofre da Chave do Azure.
• 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 Web Application Firewall para publicar com segurança aplicativos do Azure Red Hat OpenShift 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 Red Hat OpenShift do Azure, proteja o tráfego de rede de saída usando o Firewall do Azure ou um dispositivo virtual de rede de terceiros implantado na rede virtual do hub gerenciado. Para obter mais informações, consulte Controlar o tráfego de saída para um cluster do Azure Red Hat OpenShift.
• Use a camada Padrão do Balanceador de Carga do Azure em vez da camada Básica para aplicativos não Web.

Próximos passos

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