Entendendo a rede de cluster VPC

Comunicação de trabalhador para trabalhador usando sub-redes VPC

Antes de criar um cluster VPC pela primeira vez, deve-se criar uma sub-rede VPC em cada zona em que deseja implementar nós do trabalhador. Uma sub-rede de VPC é um intervalo de endereço IP privado especificado (bloco CIDR) e que configura um grupo de nós do trabalhador e pods como se eles fossem anexados ao mesmo fio físico.

Quando você cria um cluster, você especifica uma sub-rede VPC existente para cada zona. Cada nó do trabalhador incluído em um cluster é implementado com um endereço IP privado da sub-rede do VPC nessa zona. Após o provisionamento do nó do trabalhador, o endereço IP dele persiste após uma operação reboot, mas é mudado após operações replace e update.

As sub-redes fornecem um canal de conectividade entre os nós do trabalhador no cluster. Além disso, qualquer sistema conectado a qualquer uma das sub-redes privadas no mesmo VPC pode se comunicar com os trabalhadores. Por exemplo, todas as sub-redes em uma VPC podem se comunicar por meio do roteamento privado de camada 3 com um roteador integrado da VPC. Se tiver diversos clusters que devam se comunicar uns com os outros, será possível criá-los na mesma VPC. No entanto, se os clusters não precisarem se comunicar, será possível conseguir uma melhor segmentação de rede criando os clusters em VPCs separadas. Também é possível criar listas de controle de acesso (ACLs) para suas sub-redes do VPC mediarem o tráfego na rede privada. As ACLs consistem em regras de entrada e saída que definem qual entrada e saída é permitida para cada sub-rede do VPC.

Ao criar um cluster VPC e ativar os terminais em serviço de nuvem pública e privada durante a criação do cluster, o terminal em serviço de nuvem pública é usado por padrão para acesso aos componentes, como o console da web do Red Hat OpenShift para o seu cluster. Para que os pods do console estabeleçam uma conexão pública segura na Internet por meio do terminal em serviço público, deve-se ativar um gateway público em cada sub-rede VPC na qual seus nós do trabalhador estão implementados.

Ao criar um cluster VPC e ativar apenas o terminal em serviço de nuvem privada durante a criação do cluster, o terminal em serviço de nuvem privada é usado por padrão para acessar componentes do Red Hat OpenShift, como o console da web do Red Hat OpenShift ou o OperatorHub. Deve-se estar conectado à rede privada do VPC, por exemplo, por meio de uma conexão VPN, para acessar esses componentes ou executar comandos kubectl em seu cluster.

O intervalo de endereço IP padrão para sub-redes VPC 10.0.0.0 a 10.255.255.255. Para obter uma lista de intervalos de endereços IP por zona de VPC, consulte os prefixos de endereço padrão do VPC.

Se você ativar o acesso clássico ao criar sua VPC, os prefixos de endereço padrão de acesso clássico determinarão automaticamente os intervalos de IP de todas as sub-redes criadas. No entanto, os intervalos de IP padrão para sub-redes VPC de acesso clássico entram em conflito com as sub-redes do plano de controle do Red Hat OpenShift on IBM Cloud. Em vez disso, você deve criar a VPC sem os prefixos de endereço padrão automáticos e, em seguida, criar seus próprios prefixos de endereço e sub-redes dentro desses intervalos para seu cluster.

É necessário criar seu cluster usando sub-redes de intervalo customizado? Consulte essa orientação sobre Prefixos de endereço customizados. Se usar sub-redes customizadas para nós do trabalhador, você deverá assegurar que as sub-redes do nó do trabalhador não se sobreponham à sub-rede de pod do cluster.

Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Ao criar sub-redes do VPC para seus clusters, tenha em mente os recursos e as limitações a seguir. Para obter mais informações sobre as sub-redes do VPC, consulte Características de sub-redes no VPC.

• O tamanho padrão do CIDR de cada sub-rede do VPC é /24 e pode suportar até 253 nós do trabalhador. Se planejar implementar mais de 250 nós do trabalhador por zona em um cluster, considere criar uma sub-rede de um tamanho maior.
• Depois de criar uma sub-rede VPC, você não pode redimensioná-lo ou alterar seu intervalo IP.
• Diversos clusters em um mesmo VPC podem compartilhar sub-redes.
• As sub-redes VPC são vinculadas a uma única região de zona e não podem abranger várias zonas ou regiões.
• Depois de criar uma sub-rede, você não pode movê-la para uma zona, região ou VPC diferente.
• No caso de nós do trabalhador conectados a uma sub-rede existente em uma zona, não é possível mudar a sub-rede para essa zona no cluster.
• Os intervalos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16 são proibidos.

Comunicação de trabalhador para principal e de usuário para principal usando terminais privados virtuais ou terminais em serviço em nuvem

Red Hat OpenShift on IBM Cloud usa diferentes tipos de pontos de extremidade de serviço para estabelecer uma conexão de usuários autorizados do cluster e nós de trabalho com o Kubernetes master. Os usuários de cluster autorizados se comunicam com o principal do Kubernetes por meio de terminais em serviço de nuvem. Dependendo da versão de seu cluster, os nós do trabalhador se comunicam com o principal do Kubernetes por meio de terminais em serviço de nuvem ou terminais privados virtuais VPC.

Antes de criar um cluster, deve-se ativar sua conta para usar terminais em serviço. Para ativar os terminais em serviço, execute ibmcloud account update --service-endpoint-enable true.

Em clusters de VPC no Red Hat OpenShift on IBM Cloud, não é possível desativar o terminal em serviço em nuvem privada ou configurar um cluster apenas com o terminal em serviço de nuvem pública.

Seu cluster de VPC é criado com um terminal em serviço de nuvem pública e privada por padrão. Para criar clusters com nós do trabalhador que estão conectados somente à rede privada, deve-se ativar apenas o terminal em serviço privado durante a criação do cluster. Não ative o terminal em serviço público. Por exemplo, para criar um cluster VPC com apenas um ponto de extremidade de serviço de nuvem privada na CLI, inclua a opção --disable-public-service-endpoint. Se você incluir essa opção, seu cluster será criado com roteadores e controladores Ingress que expõem seus aplicativos somente na rede privada por padrão. Se posteriormente você quiser expor aplicativos para uma rede pública, deverá criar manualmente roteadores públicos e controladores do Ingress.

Comunicação de trabalhador para principal em clusters de VPC

A comunicação do nó do trabalhador com o principal do Kubernetes é estabelecida de forma diferente, com base na versão de seu cluster.

• A comunicação do nó do trabalhador com o Kubernetes principal é estabelecida sobre o VPC virtual private endpoint(VPE). Se o terminal em serviço de nuvem pública também estiver ativado, o tráfego do trabalhador para o principal será estabelecido metade por meio do terminal público e metade por meio do VPE para proteção contra potenciais indisponibilidades da rede pública ou privada.

Para proteger a comunicação entre endpoints de serviços de nuvem pública e privada ou VPEs, o Red Hat OpenShift on IBM Cloud configura automaticamente uma conexão Konnectivity entre o mestre Kubernetes e os nós de trabalho quando o cluster é criado. Os nós de trabalho se comunicam com segurança com o mestre por meio de certificados TLS, e o mestre se comunica com os trabalhadores por meio da conexão Konnectivity.

Comunicação de usuário para principal em clusters de VPC

É possível permitir que usuários de cluster autorizados se comuniquem com o principal do Kubernetes ativando os terminais em serviço de nuvem pública e privada ou somente o terminal em serviço de nuvem privada.

• Terminais em serviço de nuvem pública e privada: por padrão, todas as chamadas para o principal que são iniciadas por usuários de cluster autorizados são roteadas por meio do terminal em serviço de nuvem pública. Se os usuários de cluster autorizados estiverem em sua rede VPC ou forem conectados por meio de uma conexão VPN de VPC, o principal será acessível de forma privada por meio terminal em serviço de nuvem privada.
• Somente terminal em serviço de nuvem privada: para acessar o principal por meio do terminal em serviço de nuvem privada, os usuários de cluster autorizados devem estar em sua rede VPC ou ser conectados por meio de uma conexão VPN de VPC.

Você pode proteger o acesso à rede aos endpoints de serviço do cluster usando restrições baseadas em contexto. Somente solicitações autorizadas ao mestre do cluster originadas de sub-redes na lista de permissões são permitidas por meio dos endpoints de serviço do cluster. O uso de restrições baseadas em contexto ajuda a evitar atividades de varredura não autorizadas. Para obter mais informações, consulte Uso de restrições baseadas em contexto.

Comunicação do trabalhador com outros serviços ou redes

Permita que seus nós do trabalhador se comuniquem com segurança com outros serviços do IBM Cloud, com redes locais, com outros VPCs e com recursos da infraestrutura clássica do IBM Cloud.

Comunicação com outros serviços da IBM Cloud por meio da rede privada ou pública

Os nós do trabalhador podem se comunicar de forma automática e segura com outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada, como o IBM Cloud® Container Registry, por meio da rede privada. Se um serviço da IBM Cloud não suportar terminais em serviço de nuvem privada, os nós do trabalhador poderão se comunicar com segurança com os serviços pela rede pública por meio do gateway público da sub-rede.

Observe que, ao usar listas de controle de acesso (ACLs) para as sub-redes do VPC, deve-se criar regras de entrada ou saída para permitir que os nós do trabalhador se comuniquem com esses serviços.

Comunicação com recursos em data centers no local

Para conectar o seu cluster ao seu data center no local, é possível usar a VPN do IBM Cloud® Virtual Private Cloud ou o IBM Cloud® Direct Link.

• Para começar com a VPN da Nuvem Privada Virtual, consulte Configurar um gateway VPN no local e Criar um gateway VPN em sua VPC e criar a conexão entre o gateway VPN da VPC e o seu gateway VPN local. Se você tiver um cluster multizona, um gateway de VPC deverá ser criado em uma sub-rede em cada zona na qual você tem nós do trabalhador.
• Para começar com o Direct Link, consulte Pedindo o IBM Cloud Direct Link Dedicated. Na etapa 8, é possível criar uma conexão de rede com o seu VPC para ser conectado ao gateway do Direct Link.

Se você planeja conectar seu cluster a redes no local, confira as informações úteis a seguir:

• Você pode ter conflitos de sub-rede com o intervalo padrão fornecido pela IBM 172.30.0.0/16 para pods e o intervalo 172.21.0.0/16 para serviços. Você pode evitar conflitos de sub-rede ao criar um cluster a partir da CLI especificando um CIDR de sub-rede personalizado para pods na opção --pod-subnet e um CIDR de sub-rede personalizado para serviços na opção --service-subnet.
• Se a sua solução VPN preserva os endereços IP de origem de solicitações, é possível criar rotas estáticas customizadas para garantir que seus nós do trabalhador possam rotear respostas do seu cluster de volta para a sua rede no local.
• Observe que os intervalos de sub-rede 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16e 172.20.0.0/16 são proibidos por serem reservados para a funcionalidade do plano de controle do Red Hat OpenShift on IBM Cloud.

Comunicação externa para apps que são executados em nós do trabalhador

Permita solicitações de tráfego privado ou público de fora do cluster para seus apps executados em nós do trabalhador.

Tráfego privado para apps de cluster

Ao implementar um app no cluster, talvez você queira tornar o app acessível apenas para usuários e serviços que estão na mesma rede privada do cluster. O balanceamento de carga privado é ideal para tornar seu app disponível para solicitações de fora do cluster sem o expor ao público em geral. Também é possível usar o balanceamento de carga privado para testar o acesso, o roteamento de solicitação e outras configurações para seu app antes de ele ser exposto posteriormente para o público com serviços de rede pública.

Para permitir solicitações de tráfego de rede privada de fora do cluster para seus aplicativos, use serviços de rede privada do Kubernetes, como a criação de serviços LoadBalancer. Por exemplo, ao criar um serviço LoadBalancer do Kubernetes no cluster, um balanceador de carga para VPC é criado automaticamente na VPC fora do cluster. O balanceador de carga do VPC é multizonal e roteia solicitações para seu app por meio dos NodePorts privados que são abertos automaticamente em seus nós do trabalhador. Para VPC ALBs e NLBs, um grupo de segurança, nomeado na forma de kube-lbaas-<cluster-id>, é automaticamente anexado a seus balanceadores de carga.

Para obter mais informações, consulte Planejando o balanceamento de carga externa privada.

Tráfego público para apps de cluster

Para deixar os apps acessíveis na Internet pública, é possível usar os serviços de rede pública. Mesmo que seus nós do trabalhador estejam conectados somente às sub-redes do VPC privadas, o balanceador de carga do VPC que é criado para serviços de rede pública pode rotear solicitações públicas para o seu app na rede privada fornecendo ao seu app uma URL pública. Quando um app é exposto publicamente, qualquer um que tenha a URL pública pode enviar uma solicitação para o app.

É possível usar os serviços de rede pública do Kubernetes, como a criação de serviços LoadBalancer. Por exemplo, ao criar um serviço LoadBalancer do Kubernetes no cluster, um balanceador de carga para VPC é criado automaticamente na VPC fora do cluster. O balanceador de carga do VPC é multizonal e roteia solicitações para seu app por meio dos NodePorts privados que são abertos automaticamente em seus nós do trabalhador. Para VPC ALBs e NLBs, um grupo de segurança, nomeado na forma de kube-lbaas-<cluster-id>, é automaticamente anexado a seus balanceadores de carga.

Cenários de exemplo para configurações de rede de cluster de VPC

Agora que você entende os conceitos básicos da rede de cluster, consulte alguns cenários de exemplo nos quais diversas configurações de rede de cluster do VPC podem atender às suas necessidades de carga de trabalho.

Cenário: execute cargas de trabalho de app voltadas à Internet em um cluster de VPC

Nesse cenário, você executa cargas de trabalho em um cluster VPC que são acessíveis às solicitações da Internet. O acesso público é controlado por grupos de segurança para que os usuários finais possam acessar seus apps enquanto as solicitações públicas indesejadas para seus apps são negadas. Além disso, seus trabalhadores têm acesso automático a quaisquer serviços da IBM Cloud que suportam terminais em serviço de nuvem privada.

Estenda o data center no local para um cluster de VPC

Nesse cenário, você executa cargas de trabalho em um cluster VPC. No entanto, você deseja que elas sejam acessíveis apenas para serviços, bancos de dados ou outros recursos em suas redes privadas de um data center local. Suas cargas de trabalho de cluster podem precisar acessar alguns outros serviços do IBM Cloud que suportam a comunicação por meio da rede privada.

Próximas etapas

Para continuar o processo de planejamento, aprenda sobre a proteção de informações confidenciais em seu cluster, tomando decisões sobre o nível de criptografia que você deve configurar. Se você estiver pronto para começar a configurar a rede, vá para Entendendo a rede VPC de cluster segura por padrão.