Conceitos de rede para Red Hat OpenShift no Azure

Artigo
06/14/2023

Este guia traz uma visão geral da rede do Red Hat OpenShift no Azure em clusters do OpenShift 4, bem como um diagrama e uma lista de pontos de extremidade importantes. Para obter mais informações sobre os principais conceitos de rede no OpenShift, confira a Documentação de rede do Red Hat OpenShift no Azure 4.

Quando você implanta o Red Hat OpenShift no Azure no OpenShift 4, todo o seu cluster fica contido em uma rede virtual. Dentro dessa rede virtual, os nós do painel de controle e os nós de trabalho ficam, cada um, na própria sub-rede. Cada sub-rede usa um balanceador de carga interno e um balanceador de carga público.

Observação

Para obter informações sobre as alterações mais recentes introduzidas no ARO, confira Novidades no Red Hat OpenShift no Azure.

Componentes de rede

A lista a seguir abrange os componentes de rede importantes em um cluster do Red Hat OpenShift no Azure.

aro-pls
- Esse ponto de extremidade do Link Privado do Azure é usado pelos engenheiros de confiabilidade de site da Microsoft e do Red Hat para gerenciar o cluster.
aro-internal
- Esse ponto de extremidade equilibra o tráfego para o servidor de API e o tráfego de serviço interno. Os nós do painel de controle e os nós de trabalho estão no pool de back-end.
- Esse balanceador de carga não é criado por padrão. Ele é criado depois que você cria um serviço do tipo LoadBalancer com as anotações corretas. Por exemplo: service.beta.kubernetes.io/azure-load-balancer-internal: "true".
aro
- Este ponto de extremidade é usado para qualquer tráfego público. Quando você cria um aplicativo e uma rota, esse ponto de extremidade é o caminho do tráfego de entrada.
- Esse ponto de extremidade também roteia e equilibra o tráfego para o servidor de API (se a API for pública). Este ponto de extremidade atribui um IP de saída público para que os painéis de controle possam acessar o Azure Resource Manager e gerar relatórios sobre a integridade do cluster.
- Esse balanceador de carga também cuida da conectividade de saída da Internet de qualquer pod em execução nos nós de trabalho por meio das regras de saída do Azure Load Balancer.
  - Atualmente, as regras de saída não podem ser configuradas. Eles alocam 1.024 portas TCP a cada nó.
  - O DisableOutboundSnat não está configurado nas regras de LB, portanto, o pods podem receber como IP de saída qualquer IP público configurado neste ALB.
  - Como consequência dos dois tópicos anteriores, a única maneira de adicionar portas SNAT efêmeras é adicionar serviços do tipo balanceador de carga público ao ARO.
aro-nsg
- Quando você expõe um serviço, a API cria uma regra neste grupo de segurança de rede para que o tráfego flua e alcance o painel de controle e os nós através da porta 6443.
- Por padrão, este grupo de segurança de rede permite todo o tráfego de saída. Atualmente, o tráfego de saída só pode ser restrito ao plano de controle do Red Hat OpenShift no Azure.
Registro de Contêiner do Azure
- Esse registro de contêiner é fornecido e usado pela Microsoft internamente. Ele é somente leitura e não deve ser usado pelos usuários do Red Hat OpenShift no Azure.
  - Esse registro fornece imagens de plataforma de host e componentes de cluster. Por exemplo, contêineres de monitoramento ou registro em log.
  - As conexões com este registro ocorrem pelo ponto de extremidade de serviço (conectividade interna entre os serviços do Azure).
  - Por padrão, esse registro interno não fica disponível fora do cluster.
Link privado
- Um Link Privado permite a conectividade de rede do plano de gerenciamento para um cluster. Isso é usado por engenheiros de confiabilidade de site da Microsoft e do Red Hat para ajudar a gerenciar o cluster.

Políticas de rede

Entrada: A política de rede de entrada tem suporte como parte da SDN do OpenShift. Essa política de rede é habilitada por padrão e a imposição é realizada pelos usuários. Embora a política de rede de entrada esteja em conformidade com o NetworkPolicy V1, os Tipos de IPBlock e de Saída não têm suporte.
Saída: As políticas de rede de saída têm suporte usando o recurso de firewall de saída no OpenShift. Há apenas uma política de saída por namespace/projeto. As políticas de saída não têm suporte no namespace "padrão" e são avaliadas em ordem (da primeira à última).

Noções básicas de rede no OpenShift

A SDN (Rede definida pelo software) do OpenShift é usada para configurar uma rede de sobreposição usando o OVS (Open vSwitch), uma implementação do OpenFlow baseada na especificação do CNI (Adaptador de Rede de Contêiner). O SDN dá suporte a plug-ins diferentes. A Política de Rede é o plug-in usado no Red Hat do Azure no OpenShift 4. Toda a comunicação de rede é gerenciada pela SDN, portanto, nenhuma rota extra é necessária em suas redes virtuais para alcançar a comunicação de pod a pod.

Rede do Red Hat OpenShift no Azure

Os seguintes recursos de rede são específicos do Red Hat OpenShift no Azure:

Os usuários podem criar o seu cluster do Red Hat OpenShift no Azure em uma rede virtual existente ou criar uma nova rede virtual ao criar o cluster.
Os CIDRs de rede de serviço e de pod são configuráveis.
Os nós e os painéis de controle estão em sub-redes diferentes.
As sub-redes da rede virtual de nós e painéis de controle devem ser, no mínimo, /27.
O CIDR de pod padrão é 10.128.0.0/14.
O CIDR de serviço padrão é 172.30.0.0/16.
Os CIDRs de rede de serviço e de pod não devem se sobrepor a outros intervalos de endereços em uso na rede. Eles não devem estar dentro do intervalo de endereços IP da rede virtual do cluster.
Os CIDRs de pod deve o tamanho mínimo de /18. (A rede do pod tem IPs não roteáveis e só é usada dentro da SDN do OpenShift).
A cada nó é alocada uma sub-rede /23 (512 IPs) para seu pods. Esse valor não pode ser alterado.
Não é possível anexar um pod a várias redes.
Para clusters ARO privados que usam o plug-in de rede do OVN-Kubernetes, é possível configurar IPs de saída. Para obter informações, confira Como configurar um endereço IP de saída.

Configurações de rede

As seguintes configurações de rede estão disponíveis nos clusters do Red Hat OpenShift no Azure 4:

Visibilidade da API – defina a visibilidade da API ao executar o comando az aro create command.
- "Público" – o Servidor da API é acessível por redes externas.
- "Privado" – o Servidor da API atribuiu um IP privado da sub-rede do painel de controle, acessível somente usando redes conectadas (redes virtuais emparelhadas e outras sub-redes no cluster).
Visibilidade de Entrada – defina a visibilidade da API ao executar o comando az aro create command.
- As rotas "públicas" usam como padrão o Standard Load Balancer público. (Este padrão pode ser alterado.)
- As rotas “privadas” usam como padrão um balanceador de carga interno. (Este padrão pode ser alterado.)

Grupos de segurança de rede

Os grupos de segurança de rede são criados no grupo de recursos dos nós, que é bloqueado para usuários. Os grupos de segurança de rede são atribuídos diretamente às sub-redes que não estão nas NICs do nó. Os grupos de segurança de rede são imutáveis. Os usuários não têm as permissões para alterá-los.

Com um servidor de API publicamente visível, você não pode criar grupos de segurança de rede e atribuí-los aos adaptadores de rede.

Encaminhamento de domínio

O Red Hat OpenShift no Azure usa o CoreDNS. O encaminhamento de domínio pode ser configurado. Você não pode usar um DNS próprio nas suas redes virtuais. Para obter mais informações, confira a documentação sobre como usar o encaminhamento do DNS.

Próximas etapas

Para saber mais sobre o tráfego de saída e a que o Red Hat OpenShift no Azure dá suporte em termos de saída, confira a documentação das políticas de suporte.

Compartilhar via