Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Red Hat OpenShift no Azure com planos de controle hospedados implanta nós de trabalho em sua rede virtual Azure e usa uma sub-rede dedicada para estabelecer conectividade privada entre o plano de controle hospedado e seus nós de trabalho. Você deve planejar seu layout de rede virtual, sub-redes e intervalos de endereços IP antes de criar o cluster.
Planejar a capacidade de computação
Os conjuntos de nós fornecem capacidade de computação. Um pool de nós é um grupo de nós de trabalho que compartilham o mesmo tamanho de VM, configuração de disco e zona de disponibilidade. Você pode criar vários pools de nós em um único cluster para executar diferentes tipos de carga de trabalho em hardware diferente. Para ver os tamanhos de VM de nó de trabalho com suporte, consulte Tamanhos de máquinas virtuais com suporte. Várias decisões do pool de nós afetam diretamente o layout de rede, portanto, você deve planejar sua capacidade de computação antes de dimensionar sua rede.
Responder às seguintes perguntas ajuda você a planejar as sub-redes e os intervalos de endereços IP para o cluster:
- Quantos pools de nós você executará? O número de pools de nós determina quantas sub-redes você pode precisar. Se todos os pools compartilharem a sub-rede de trabalho padrão do cluster, uma sub-rede será suficiente. Se você atribuir sub-redes separadas a pools diferentes, cada uma delas aumentará seus requisitos de CIDR da rede virtual e das máquinas.
- Você implantará em várias zonas de disponibilidade? Cada pool de nós é implantado em uma única zona de disponibilidade. Para distribuir cargas de trabalho entre zonas para alta disponibilidade, você precisa de um pool de nós separado e, potencialmente, de uma sub-rede separada para cada zona. Mais zonas significa mais sub-redes e um CIDR de computador maior.
- Cada pool de nós usará sua própria sub-rede? Os pools de nós são implantados na sub-rede de trabalho padrão do cluster, a menos que você especifique uma sub-rede diferente. Sub-redes separadas oferecem isolamento de rede entre conjuntos de nós, mas cada sub-rede deve estar dentro do intervalo CIDR das máquinas e do espaço de endereços da rede virtual.
- Quantos nós você executará no pico? A contagem máxima de nós, incluindo os máximos de dimensionamento automático, determina o tamanho de cada sub-rede. O cluster dá suporte a um total máximo de 500 nós em todos os pools.
- Você vai adicionar mais grupos de nós mais tarde? Os intervalos CIDR do cluster não podem ser alterados após a criação. Se você planeja adicionar pools de nós com novas sub-redes no futuro, o CIDR da máquina e a rede virtual devem ter espaço de endereço suficiente para acomodá-los.
Dica
Exemplo de dimensionamento: Um cluster com três zonas de disponibilidade, até 50 nós por zona e uma sub-rede separada por zona precisa de três /26 sub-redes (64 endereços cada, acomodando 50 nós mais Azure endereços reservados) e uma /29 sub-rede de integração de VNet.
Todas as quatro sub-redes cabem dentro de um CIDR da máquina /24 (256 endereços).
Se você planeja adicionar mais pools de nós mais tarde, use uma CIDR de computador maior, como /22 ou /16 para deixar espaço para sub-redes adicionais.
Requisitos de sub-rede
Sua rede virtual deve conter os seguintes componentes:
- Sub-rede de trabalho – a sub-rede padrão em que os nós de trabalho do cluster são implantados. Quando você cria um pool de nós, ele é implantado nessa sub-rede, a menos que você especifique uma sub-rede diferente. Se você planeja implantar pools de nós em várias zonas de disponibilidade, poderá criar uma sub-rede separada para cada zona. Todas as sub-redes do pool de nós devem estar na mesma rede virtual do cluster. Dimensione cada sub-rede de acordo com o número de nós de trabalho que você pretende executar nela.
-
Sub-rede de integração da VNet – uma sub-rede dedicada que permite a conectividade privada entre o plano de controle hospedado (em execução na conta de Azure do Red Hat) e os nós de trabalho em sua assinatura. Ele deve atender aos seguintes requisitos:
- Tamanho mínimo de
/29 - Localizado na mesma rede virtual que a sub-rede de trabalho
- Não compartilhado com a sub-rede de trabalho ou qualquer sub-rede do pool de nós
- Tamanho mínimo de
- Grupos de segurança de rede - Se você associar um grupo de segurança de rede (NSG) a um worker, pool de nós ou sub-rede de integração da VNet, revise as regras dele de acordo com o tráfego necessário descrito em Tráfego necessário do grupo de segurança de rede. Você atribui NSGs diretamente às sub-redes.
Tráfego de grupo de segurança de rede necessário
O NSG (grupo de segurança de rede) associado ao pool de nós e sub-redes de integração de VNet deve permitir o seguinte tráfego:
| Associação NSG | Direction | Fonte | Destination | Portas de destino |
|---|---|---|---|---|
| Sub-rede do pool de nós ou de trabalho | De saída | Sub-rede do pool de nós ou de trabalho | Sub-rede do cluster principal | TCP 443 e 6443 |
| Sub-rede de integração de VNet | Entrada | Sub-rede do pool de nós ou de trabalho | Sub-rede de integração de VNet | TCP 443 e 8443 |
Essas conexões permitem que os nós de trabalho alcancem o kube-apiserver hospedado e o plano de controle hospedado. Se uma regra NSG Deny bloquear o tráfego necessário, você não poderá criar pools de nós.
Para corrigir uma regra de negação que bloqueia um fluxo obrigatório, execute uma das seguintes ações:
- Remova a regra "Deny".
- Restrinja a regra Negar para que ela não se aplique à origem, ao destino e às portas exigidos.
- Adicione uma regra Permitir que corresponda à origem, ao destino e às portas necessárias e tenha uma prioridade maior do que a regra Negar. Em um NSG, uma prioridade numérica mais baixa tem uma prioridade mais alta.
O Red Hat OpenShift no Azure com planos de controle hospedados avalia regras TCP e regras com caractere curinga 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 essa validação. No entanto, essas regras ainda podem bloquear outro tráfego.
Requisitos de CIDR
A tabela a seguir descreve os requisitos de rede virtual e CIDR:
| Requisito de rede | Default | Description |
|---|---|---|
| Intervalo CIDR do computador | 10.0.0.0/16 |
O intervalo de endereços IP para nós de computação. Ele deve abranger todos os intervalos de endereços CIDR para suas sub-redes de rede virtual, incluindo as sub-redes que você planeja usar para pools de nós adicionais. As sub-redes devem ser contíguas. Há suporte para no mínimo 128 endereços (/25) para implantações de zona de disponibilidade única. Há suporte para no mínimo 256 endereços (/24) para várias implantações de zona de disponibilidade. |
| Intervalo CIDR de serviço | 172.30.0.0/16 |
A faixa de endereços IP dos IPs de serviço do Kubernetes. O intervalo deve ser grande o suficiente para acomodar sua carga de trabalho e não deve se sobrepor a nenhum serviço externo acessado de dentro do cluster. |
| Faixa CIDR do pod | 10.128.0.0/14 |
O intervalo de endereços IP para pods. O intervalo deve ser grande o suficiente para acomodar sua carga de trabalho e não deve se sobrepor a nenhum serviço externo acessado de dentro do cluster. |
| Prefixo do host | 23 |
O comprimento do prefixo de sub-rede atribuído a cada nó para seus 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 eles não atendam aos seus requisitos. Se você precisar alterar qualquer um desses valores, siga estas diretrizes:
- Os CIDRs de pod, serviço e computador não devem se sobrepor uns aos outros.
- Os CIDRs de pod e serviço não devem se sobrepor a nenhum intervalo de endereços em uso em sua rede ou a quaisquer serviços externos acessados de dentro do cluster.
- A CIDR do computador deve abranger todas as sub-redes de rede virtual usadas pelo cluster, incluindo a sub-rede de trabalho, quaisquer sub-redes de pool de nós adicionais e a sub-rede de integração da VNet. Se você planeja adicionar pools de nós com sub-redes separadas no futuro, verifique se o CIDR do computador é grande o suficiente para incluí-los. Por exemplo, se sua VNet usa
10.0.0.0/16, o CIDR padrão da máquina de10.0.0.0/16cobre todas as sub-redes. - A rede dos pods usa endereços IP não roteáveis e é usada apenas dentro da rede definida por software do cluster.
Conectividade de cluster privado
Se você escolher um servidor de API privado, uma entrada padrão privada ou ambos, deverá estabelecer conectividade de rede privada entre as redes dos usuários e a rede virtual do cluster antes de implantar o cluster. Sem essa conectividade, os administradores, os pipelines de CI/CD e os usuários finais não podem acessar os endpoints privados.
As opções comuns de conectividade incluem:
- Emparelhamento de VNet do Azure — Conecte duas redes virtuais do Azure para que os recursos em cada rede possam se comunicar entre si.
- Gateway de VPN do Azure - Conecte sua rede local à rede virtual do cluster por meio de um túnel VPN site a site.
- Azure ExpressRoute – estabeleça uma conexão privada e dedicada de sua rede local para Azure por meio de um provedor de conectividade.
Ao planejar a conectividade de rede privada, certifique-se de que os intervalos de endereços IP das redes emparelhadas ou conectadas não se sobreponham aos intervalos de CIDR de máquina, CIDR de pod ou CIDR de serviço do cluster.