Share via

Conceitos de rede do Azure Red Hat OpenShift

  • Artigo

Este guia abrange uma descrição geral das redes do Azure Red Hat OpenShift em clusters do OpenShift 4, juntamente com um diagrama e uma lista de pontos finais importantes. Para obter mais informações sobre os principais conceitos de rede do OpenShift, veja a documentação de rede do Azure Red Hat OpenShift 4.

Diagrama da rede do Azure Red Hat OpenShift.

Quando implementa o Azure Red Hat OpenShift no OpenShift 4, todo o cluster está contido numa rede virtual. Nesta rede virtual, os nós do plano de controlo e os nós de trabalho residem cada um na sua própria sub-rede. Cada sub-rede utiliza um balanceador de carga interno e um balanceador de carga público.

Nota

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

Componentes de rede

A lista seguinte abrange componentes de rede importantes num cluster do Azure Red Hat OpenShift.

  • aro-pls

    • Este Azure Private Link ponto final é utilizado pelos engenheiros de fiabilidade do site Microsoft e Red Hat para gerir o cluster.

  • aro-interno

    • Este ponto final equilibra o tráfego para o servidor de API e para o tráfego de serviço interno. Os nós do plano de controlo e os nós de trabalho estão no conjunto de back-end.
    • Este balanceador de carga não é criado por predefinição. É criado depois de criar 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 final é utilizado para qualquer tráfego público. Quando cria uma aplicação e uma rota, este ponto final é o caminho para o tráfego de entrada.
    • Este ponto final também encaminha e equilibra o tráfego para o servidor de API (se a API for pública). Este ponto final atribui um IP de saída público para que os planos de controlo possam aceder ao Azure Resource Manager e comunicar novamente o estado de funcionamento do cluster.
    • Este balanceador de carga também abrange a conectividade internet de saída a partir de qualquer pod em execução nos nós de trabalho através Balanceador de Carga do Azure regras de saída.
      • Atualmente, as regras de saída não são configuráveis. Atribuem 1024 portas TCP a cada nó.
      • DisableOutboundSnat não está configurado nas regras do LB, pelo que os pods podem obter como IP de saída qualquer IP público configurado neste ALB.
      • Como consequência dos dois pontos anteriores, a única forma de adicionar portas SNAT efémeras é adicionar serviços públicos do tipo LoadBalancer à ARO.

  • aro-nsg

    • Quando expõe um serviço, a API cria uma regra neste grupo de segurança de rede para que o tráfego flua e chegue ao plano de controlo e aos nós através da porta 6443.
    • Por predefiniçã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 restringido ao plano de controlo do Azure Red Hat OpenShift.

  • Azure Container Registry

    • Este registo de contentor é fornecido e utilizado internamente pela Microsoft. É só de leitura e não se destina a ser utilizado por utilizadores do Azure Red Hat OpenShift.
      • Este registo fornece imagens da plataforma anfitriã e componentes de cluster. Por exemplo, monitorizar ou registar contentores.
      • As ligações a este registo ocorrem através do ponto final de serviço (conectividade interna entre serviços do Azure).
      • Por predefinição, este registo interno não está disponível fora do cluster.

  • Ligação Privada

    • Uma Private Link permite a conectividade de rede do plano de gestão para um cluster. Isto é utilizado pelos engenheiros de fiabilidade do site da Microsoft e da Red Hat para ajudar a gerir o cluster.

Políticas de rede

  • Entrada: a política de rede de entrada é suportada como parte da SDN do OpenShift. Esta política de rede está ativada por predefinição e a imposição é efetuada pelos utilizadores. Embora a política de rede de entrada seja compatível com NetworkPolicy V1, os Tipos de Saída e IPBlock não são suportados.

  • Saída: as políticas de rede de saída são suportadas através da funcionalidade de firewall de saída no OpenShift. Existe apenas uma política de saída por espaço de nomes/projeto. As políticas de saída não são suportadas no espaço de nomes "predefinido" e são avaliadas por ordem (do primeiro ao último).

Noções básicas sobre redes no OpenShift

O OpenShift Software Defined Networking (SDN) é utilizado para configurar uma rede de sobreposição com o Open vSwitch (OVS), uma implementação OpenFlow baseada na especificação da Interface de Rede de Contentor (CNI). A SDN suporta plug-ins diferentes. A Política de Rede é o plug-in utilizado no Azure Red Hat no OpenShift 4. Todas as comunicações de rede são geridas pelo SDN, pelo que não são necessárias rotas adicionais nas suas redes virtuais para alcançar a comunicação de pods.

Rede para o Azure Red Hat OpenShift

As seguintes funcionalidades de rede são específicas do Azure Red Hat OpenShift:

  • Os utilizadores podem criar o cluster do Azure Red Hat OpenShift numa rede virtual existente ou criar uma nova rede virtual ao criar o cluster.
  • Os CIDRs do Pod e da Rede de Serviço são configuráveis.
  • Os nós e os planos de controlo estão em sub-redes diferentes.
  • Os nós e as sub-redes de rede virtual do plano de controlo devem ser mínimas /27.
  • O CIDR do Pod predefinido é 10.128.0.0/14.
  • O CIDR de Serviço predefinido é 172.30.0.0/16.
  • Os CIDRs do Pod e da Rede de Serviços não devem sobrepor-se a outros intervalos de endereços em utilização na sua rede. Não podem estar dentro do intervalo de endereços IP da rede virtual do cluster.
  • Os CIDRs do pod devem ter um tamanho mínimo de /18. (A rede de pods não é encaminhável para IPs e só é utilizada dentro do SDN do OpenShift.)
  • Cada nó é alocado a /23 sub-rede (512 IPs) para os respetivos pods. Este valor não pode ser alterado.
  • Não pode anexar um pod a várias redes.
  • Não pode configurar um IP estático de saída. (Esta restrição é uma funcionalidade do OpenShift. Para obter informações, veja Configurar IPs de saída).

Definições de rede

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

  • Visibilidade da API – defina a visibilidade da API ao executar o comando az aro create.
    • "Público" – o Servidor de API é acessível por redes externas.
    • "Privado" – o Servidor de API atribuiu um IP privado a partir da sub-rede do plano de controlo, acessível apenas através de redes ligadas (redes virtuais em modo de peering e outras sub-redes no cluster).
  • Visibilidade da Entrada – defina a visibilidade da API ao executar o comando az aro create.
    • As rotas "Públicas" são predefinidas para uma Balanceador de Carga Standard pública. (A predefinição pode ser alterada.)
    • As rotas "Privadas" são encaminhadas por predefinição para um balanceador de carga interno. (A predefinição pode ser alterada.)

Grupos de segurança de rede

Os grupos de segurança de rede são criados no grupo de recursos do nó, que está bloqueado para os utilizadores. Os grupos de segurança de rede são atribuídos diretamente às sub-redes e não aos NICs do nó. Os grupos de segurança de rede são imutáveis. Os utilizadores não têm permissões para alterá-las.

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

Reencaminhamento de domínios

O Azure Red Hat OpenShift utiliza o CoreDNS. O reencaminhamento de domínios pode ser configurado. Não pode trazer o seu próprio DNS para as suas redes virtuais. Para obter mais informações, veja a documentação sobre como utilizar o reencaminhamento DNS.

Passos seguintes

Para obter mais informações sobre o tráfego de saída e o que o Azure Red Hat OpenShift suporta para saída, veja a documentação de políticas de suporte .