Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Azure Red Hat OpenShift com planos de controlo alojados implementa nós de trabalho na sua rede virtual do Azure e utiliza uma sub-rede dedicada para estabelecer uma ligação privada entre o plano de controlo alojado e os nós de trabalho. Deve planear o layout da sua rede virtual, sub-redes e intervalos de endereços IP antes de criar o cluster.
Capacidade computacional do plano
Os conjuntos de nós fornecem capacidade de computação. Um conjunto de nós é um grupo de nós de trabalho que partilham o mesmo tamanho de VM, configuração de disco e zona de disponibilidade. Pode criar múltiplos pools de nós num único cluster para executar diferentes tipos de carga de trabalho em hardware distinto. Para conhecer os tamanhos das VM suportados para os nós de trabalho, consulte Tamanhos de máquinas virtuais suportados. Várias decisões relativas ao conjunto de nós afetam diretamente a configuração da sua rede, por isso deve planear a sua capacidade de computação antes de dimensionar a sua rede.
Responder às seguintes perguntas ajuda-o a planear as subredes e os intervalos de endereços IP do seu cluster:
- Quantos pools de nós irá utilizar? O número de pools de nós determina quantas sub-redes poderá precisar. Se todos os pools partilharem a sub-rede worker padrão do cluster, uma sub-rede é suficiente. Se atribuíres sub-redes separadas a diferentes conjuntos, cada uma delas aumenta os requisitos de CIDR da tua rede virtual e das máquinas.
- Vão deslocar-se entre zonas de disponibilidade? Cada pool de nós é implementado numa única zona de disponibilidade. Para distribuir cargas de trabalho entre zonas para alta disponibilidade, é necessário um pool de nós separado e, potencialmente, uma sub-rede separada para cada zona. Mais zonas significam mais sub-redes e um CIDR de máquina maior.
- Cada pool de nós vai usar a sua própria sub-rede? Os pools de nós são implementados na sub-rede predefinida dos nós de trabalho do cluster, a menos que especifique uma sub-rede diferente. Sub-redes separadas proporcionam isolamento de rede entre grupos de nós, mas cada sub-rede tem de estar contida no intervalo CIDR das máquinas e no espaço de endereçamento da rede virtual.
- Quantos nós vais usar no pico? O número máximo de nós, incluindo os limites máximos do escalonamento automático, determina a dimensão necessária de cada sub-rede. O cluster suporta um máximo de 500 nós em todos os pools.
- Vais adicionar mais pools de nós mais tarde? Os intervalos CIDR do cluster não podem ser alterados após a criação. Se planeia adicionar pools de nós com novas sub-redes no futuro, o CIDR da sua máquina e a rede virtual devem ter espaço de endereçamento suficiente para os acomodar.
Gorjeta
Exemplo de dimensionamento: Um cluster com 3 zonas de disponibilidade, até 50 nós por zona, e uma sub-rede separada por zona, necessita de três /26 subredes (64 endereços cada, acomodando 50 nós mais endereços reservados no Azure) e uma /29 sub-rede de integração VNet.
As quatro subredes cabem numa /24 máquina CIDR (256 endereços).
Se planeia adicionar mais pools de nós mais tarde, use um CIDR de máquina maior, como /22 ou /16 para deixar espaço para sub-redes adicionais.
Requisitos de sub-rede
A sua rede virtual deve conter os seguintes componentes:
- Sub-rede de trabalhadores - A sub-rede padrão onde os nós de trabalho do cluster são implantados. Quando crias um pool de nós, ele é implementado nesta sub-rede, a menos que especifiques uma sub-rede diferente. Se planeias implementar pools de nós em várias zonas de disponibilidade, podes criar uma sub-rede separada para cada zona. Todas as subredes do pool de nós devem estar na mesma rede virtual do cluster. Dimensione cada sub-rede com base no número de nós de trabalho que planeia ter em execução nela.
-
Sub-rede de integração VNet - Uma sub-rede dedicada que permite conectividade privada entre o plano de controlo alojado (a correr na conta Azure da Red Hat) e os nós de trabalho na sua subscrição. Deve cumprir os seguintes requisitos:
- Tamanho mínimo de
/29 - Localizado na mesma rede virtual da sub-rede de trabalhadores
- Não partilhada com a sub-rede dos nós de trabalho nem com qualquer sub-rede do conjunto de nós
- Tamanho mínimo de
- Grupos de segurança de rede - Se associar um grupo de segurança de rede (NSG) a um nó de trabalho, conjunto de nós ou sub-rede de integração da VNet, reveja as respetivas regras em função do tráfego necessário descrito em Tráfego necessário para grupos de segurança de rede. Atribuis NSGs diretamente às sub-redes.
Tráfego obrigatório de grupos de segurança de rede
O grupo de segurança de rede (NSG) associado ao pool de nós e às sub-redes de integração VNet deve permitir o seguinte tráfego:
| Associação NSG | Direção | Fonte | Destination | Portas de destino |
|---|---|---|---|---|
| Sub-rede de trabalhadores ou pool de nós | Direção exterior | Sub-rede de trabalhadores ou pool de nós | Sub-rede do cluster principal | TCP 443 e 6443 |
| Sub-rede de integração VNet | Inbound | Sub-rede de trabalhadores ou pool de nós | Sub-rede de integração VNet | TCP 443 e 8443 |
Estas ligações permitem aos nós de trabalho aceder ao kube-apiserver alojado e ao plano de controlo alojado. Se uma regra NSG de Negação bloqueia tráfego necessário, não pode criar pools de nós.
Para corrigir uma regra de Negação que bloqueia um fluxo necessário, tome uma das seguintes ações:
- Remova a regra de Negar.
- Restringa a regra de Negar para que não corresponda à fonte, destino e portas necessárias.
- Adicione uma regra de Permitir que corresponda à origem, destino e portas necessárias e que tenha uma prioridade superior à regra de Rejeitação. Num NSG, uma prioridade numérica mais baixa tem uma prioridade maior.
O Azure Red Hat OpenShift, com planos de controlo alojados, avalia as regras TCP e as regras wildcard que incluem as portas necessárias. As regras de negação para portas não relacionadas, tráfego UDP ou destinos não relacionados não afetam esta validação. No entanto, essas regras ainda podem bloquear outro trânsito.
Requisitos do CIDR
A tabela seguinte descreve os requisitos da rede virtual e do CIDR:
| Requisito de rede | Predefinição | Description |
|---|---|---|
| Gama CIDR de máquinas | 10.0.0.0/16 |
Intervalo de endereços IP dos nós de computação. Deve abranger todos os intervalos de endereços CIDR das suas sub-redes da rede virtual, incluindo quaisquer sub-redes que planeie utilizar para conjuntos adicionais de nós. As sub-redes devem ser contíguas. É suportado um mínimo de 128 endereços (/25) para implantações numa única zona de disponibilidade. É suportado um mínimo de 256 endereços (/24) para implementações em múltiplas zonas de disponibilidade. |
| Campo CIDR de serviço | 172.30.0.0/16 |
O intervalo de endereços IP para os IPs dos serviços Kubernetes. O intervalo deve ser suficientemente grande para acomodar a sua carga de trabalho e não deve sobrepor-se a qualquer serviço externo acedido dentro do cluster. |
| Gama CIDR de pod | 10.128.0.0/14 |
O intervalo de endereços IP para pods. O intervalo deve ser suficientemente grande para acomodar a sua carga de trabalho e não deve sobrepor-se a qualquer serviço externo acedido dentro do cluster. |
| Prefixo de host | 23 |
O comprimento do prefixo de sub-rede atribuído a cada nó para os respetivos pods. Um valor de 23 atribui uma /23 sub-rede (512 endereços IP) por nó do intervalo CIDR do pod. |
Use os valores padrão, a menos que não cumpram os seus requisitos. Se precisar de alterar algum destes valores, siga estas orientações:
- Os CIDRs do pod, do serviço e da máquina não se devem sobrepor uns aos outros.
- Os CIDRs dos pods e dos serviços não se devem sobrepor a nenhum intervalo de endereços utilizado na sua rede nem a quaisquer serviços externos acedidos a partir do cluster.
- O CIDR da máquina deve abranger todas as sub-redes virtuais usadas pelo cluster, incluindo a sub-rede de trabalho, quaisquer sub-redes adicionais de pool de nós e a sub-rede de integração VNet. Se planeia adicionar pools de nós com sub-redes separadas no futuro, certifique-se de que o CIDR da máquina é suficientemente grande para os incluir. Por exemplo, se a sua VNet utilizar
10.0.0.0/16, o CIDR predefinido da máquina de10.0.0.0/16abrange todas as sub-redes. - A rede pod utiliza endereços IP não roteáveis e é usada apenas dentro da rede definida por software do cluster.
Conectividade de cluster privado
Se escolher um servidor API privado, uma entrada privada por predefinição, ou ambos, deve estabelecer conectividade de rede privada entre as redes dos seus utilizadores e a rede virtual do cluster antes de implementar o cluster. Sem esta conectividade, administradores, pipelines CI/CD e utilizadores finais não conseguem aceder aos endpoints privados.
Opções comuns de conectividade incluem:
- Azure VNet peering - Ligue duas redes virtuais Azure para que os recursos em cada rede possam comunicar entre si.
- Gateway de VPN do Azure - Ligue a sua rede local à rede virtual do cluster através de um túnel VPN site-to-site.
- Azure ExpressRoute - Estabeleça uma ligação privada e dedicada da sua rede local para o Azure através de um fornecedor de conectividade.
Ao planear a conectividade de rede privada, certifique-se de que os intervalos de endereços IP das redes em emparelhamento ou ligadas não se sobrepõem aos intervalos CIDR de máquinas do cluster, de pods ou de serviços.