Projetando sua rede para a virtualização d Red Hat OpenShift s em IBM Cloud VPC
Projete a rede para a virtualização “ Red Hat OpenShift ” no site IBM Cloud VPC, abrangendo redes VPC, redes definidas por software (SDN) do OpenShift e redes definidas pelo usuário do Open Virtual Networking (OVN).
O design da rede na Red Hat OpenShift Virtualization em IBM Cloud VPC tem as seguintes camadas distintas.
- Rede VPC
- Red Hat OpenShift networking
- Rede OVN
Os principais elementos da arquitetura de rede são mostrados no diagrama a seguir.
IBM Cloud VPC networking
Você usa a rede IBM Cloud VPC para implementar e gerenciar recursos de nuvem. Ele fornece a base para suas cargas de trabalho, incluindo servidores virtuais, contêineres e implementações bare metal, que podem ajudar a garantir a segmentação, a segurança e o dimensionamento da rede.
É necessário criar uma VPC para provisionar um Red Hat® OpenShift® Kubernetes Service cluster.
Rede privada padrão com sub-redes
Você precisa criar uma sub-rede VPC em pelo menos uma zona de disponibilidade para provisionar um cluster Red Hat OpenShift Kubernetes Service. Para obter mais informações, consulte Rede privada padrão com sub-redes.
Balanceadores de carga.
Um controlador de entrada Red Hat OpenShift é implantado em seu cluster Red Hat OpenShift Kubernetes Service que funciona como ponto de extremidade de entrada para o tráfego de rede externo. Em um cluster Red Hat OpenShift Kubernetes Service, um balanceador de carga de aplicativo VPC é criado automaticamente por cluster para expor o controlador de entrada. Para obter mais informações, consulte Balanceadores de carga.
Red Hat OpenShift Kubernetes Service executa as seguintes funções.
- O serviço DNS resolve o subdomínio da rota para o nome do host do balanceador de carga da VPC.
- O balanceador de carga da VPC mapeia o nome de host da VPC para um endereço IP externo disponível de um serviço de controlador de entrada que foi identificado como estando operando corretamente.
- O balanceador de carga da VPC envia a solicitação a um serviço de controlador de entrada.
- O controlador de ingresso encaminha a solicitação para o endereço IP privado da pod do app sobre a rede privada.
Terminais privados virtuais
Os Virtual Private Endpoints (VPE) em ambientes Red Hat OpenShift Kubernetes Service são usados principalmente para permitir a conectividade privada entre o cluster Red Hat OpenShift e os serviços da plataforma IBM Cloud sem tráfego de rede que atravesse a Internet pública.
A tabela a seguir lista todos os pontos de extremidade privados virtuais que são provisionados automaticamente pelo site IBM Cloud para operações essenciais de cluster.
| Terminal privado virtual | Gerenciado por | Descrição |
|---|---|---|
| iks-api | Kubernetes Service API |
|
| iks-riaas | Serviços de infraestrutura de VPC |
|
| registro de iks | Registro de contêiner |
|
| iks-<cluster_id> | Instância específica do cluster |
|
| iks-cos-config | Cloud Object Storage (Configuração) |
|
| iks-cos | Cloud Object Storage (Dados) |
|
Red Hat OpenShift Redes de virtualização
Red Hat OpenShift A virtualização usa os recursos de rede do Red Hat OpenShift para fornecer uma rede flexível e definida por software para servidores virtuais que são executados juntamente com cargas de trabalho em contêineres. É importante
entender a diferença entre a rede de servidores virtuais e a rede de pods. Cada servidor virtual é executado em um pod virt-launcher que está sempre conectado à rede padrão do pod.
┌────────────────────────────────┐
│ Worker Node │
│ ┌──────────────────────────┐ │
│ │ virt-launcher │ │ ← Kubernetes Pod Security Context
│ │ pod │ │
│ │ ┌────────────────────┐ │ │
│ │ │ virtual server │ │ │ ← KVM/QEMU Hypervisor Isolation
│ │ │ (QEMU) │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────┘ │
└────────────────────────────────┘
Dependendo de como você provisiona e configura seu servidor virtual, ele compartilha uma rede de pod (ou pode se conectar a diferentes redes usando multus).
O exemplo a seguir descreve a rede de pods padrão em Red Hat OpenShift que você pode modificar com a rede OVN- Kubernetes.
Redes de pods (rede de clusters)
- Cada pod recebe um endereço IP privado da rede do cluster, de acordo com o padrão Classless Inter-Domain Routing (CIDR)
- Fornece comunicação pod-to-pod entre os nós
- Os pods se comunicam diretamente usando seus IPs privados dentro do cluster
- As políticas de rede controlam o tráfego de pod para pod na camada 3/4
- Modelo de rede plana - todos os pods podem se comunicar por padrão
- Sem NAT entre pods (comunicação direta entre pods)
- As políticas de rede fornecem segmentação e segurança
- Descoberta de serviços baseados em DNS dentro do cluster
- Quando um servidor virtual é executado dentro do pod do virt-launcher, o endereço IP passa por tradução de endereços de rede (NAT) para o endereço IP do pod do virt-launcher
Mascaramento de IP (NAT de origem (SNAT))
- Quando os pods iniciam conexões de saída para redes externas, o IP de origem é mascarado
- O endereço IP de origem do pacote de solicitação é alterado para o endereço IP do nó de trabalho no qual o pod é executado
- O mascaramento de IP é necessário porque os IPs do pod não são roteáveis fora do cluster
- O tráfego de retorno é desmascarado de volta para o IP do pod original
- Os serviços externos veem solicitações provenientes de IPs de nós de trabalho, não de IPs de pods
ClusterIP serviço
Os serviços fornecem endpoints estáveis e balanceamento de carga para pods. Eles abstraem IPs de pods e fornecem pontos de acesso consistentes para aplicativos. O serviço ClusterIP oferece as seguintes funções.
- Cria um IP virtual ( ClusterIP ) acessível somente dentro do cluster
- ClusterIP é o tipo de serviço padrão se não for especificado
- Fornece balanceamento de carga interna entre os pods de back-end
- Usa kube-proxy ou OVN- Kubernetes para distribuição de tráfego
Os casos de uso a seguir são um exemplo de como o ClusterIP é usado.
- Comunicação interna dos microsserviços
- Serviços de back-end que não requerem acesso externo
- Serviços de banco de dados que são acessados apenas por cargas de trabalho de cluster
- Descoberta de serviços entre pódulos
Serviço NodePort
Os serviços fornecem endpoints estáveis e balanceamento de carga para pods. Eles abstraem IPs de pods e fornecem pontos de acesso consistentes para aplicativos. O serviço NodePort oferece as seguintes funções.
- Expõe o serviço em uma porta estática (intervalo 30000-32767) em cada nó de trabalho
- Torna o serviço acessível por meio de
<NodeIP>:<NodePort> - Cria automaticamente o serviço ClusterIP
- O tráfego para qualquer NodePort é encaminhado para o serviço
O exemplo a seguir mostra o fluxo de tráfego NodePort.
- O cliente externo se conecta a
<WorkerNodeIP>:<NodePort> - Os nós encaminham o tráfego para o serviço ClusterIP
- O serviço equilibra a carga para os pods de back-end
- A resposta segue o caminho inverso com SNAT (tradução de endereços de rede de origem)
Os casos de uso a seguir são um exemplo de como o NodePorts é usado.
- Ambientes de desenvolvimento e teste
- Acesso externo rápido sem balanceador de carga
- Integração com balanceadores de carga externos
- Soluções personalizadas de balanceamento de carga
Serviço de balanceador de carga
Em IBM Cloud Red Hat OpenShift Kubernetes Service, o serviço de balanceador de carga provisiona automaticamente um balanceador de carga de rede VPC ou um balanceador de carga de aplicativo. O serviço de balanceador de carga oferece as seguintes funções.
- Provisiona automaticamente um balanceador de carga externo
- Atribui IP externo ou nome de host ao serviço
- Cria automaticamente os serviços NodePort e ClusterIP
- Fornece balanceamento de carga de camada 4 para back-ends de serviço
O exemplo a seguir mostra o fluxo de tráfego em uma VPC.
- O cliente externo se conecta ao IP ou nome de host do balanceador de carga da VPC
- O balanceador de carga VPC distribui para o nó de trabalho NodePorts
- Node para o serviço ClusterIP
- O serviço equilibra a carga para os pods de back-end
Os casos de uso a seguir são um exemplo de como os balanceadores de carga são usados.
- Aplicativos de produção que exigem acesso externo dedicado
- Protocolos não relacionados a HTTP (serviços TCP ou UDP )
- Aplicativos que precisam de IPs externos estáveis
- Serviços que ignoram a camada de entrada ou de rota
Red Hat OpenShift rotas
Red Hat OpenShift As rotas expõem os serviços ao tráfego de rede externo por meio do mapeamento de nomes de domínio totalmente qualificados (FQDNs) para serviços de back-end, o que torna as aplicações acessíveis fora do cluster. A lista a seguir mostra os principais recursos do Red Hat OpenShift Routes.
- Roteamento da camada 7 - HTTP / HTTPS tráfego com roteamento baseado no nome do host
- DNS automático - as rotas usam o subdomínio do cluster:
<route-name>-<namespace>.apps.<cluster-domain> - Rotas não seguras ( HTTP )
- Finalização TLS
- Rotas com terminação na borda ( TLS no roteador)
- Rotas de passagem ( TLS em Pod)
- Criptografar novamente as rotas ( TLS no roteador e no Pod)
- HAProxy-baseado é implementado pelo controlador de entrada (roteador) Red Hat OpenShift
- Gerenciamento de tráfego - roteamento baseado em caminhos, divisão de tráfego e afinidade de sessão
Rede virtual aberta (OVN)
O plug-in OVN- Kubernetes, da Container Network Interface (CNI), é a opção de rede recomendada para a virtualização do Red Hat OpenShift, que oferece suporte a casos de uso de rede de servidores virtuais que operam em paralelo à rede tradicional de pods. O OVN- Kubernetes, baseia-se no Open Virtual Networking (OVN) e utiliza o Open vSwitch (OVS) em todos os nós de trabalho. Ele oferece suporte a multitenancy, NetworkPolicies, e servidor virtual híbrido e rede de pods. Red Hat OpenShift on IBM Cloud O VPC oferece suporte ao OVN- Kubernetes como o plug-in de rede padrão.
Para administradores familiarizados com o VMware vSphere e o NSX-T, consulte a seção sobre redes OVN em OpenShift, destinada a administradores do vSphere, para obter uma correspondência entre os conceitos do OVN e seus equivalentes no vSphere.
Em Red Hat OpenShift com OVN, as três topologias de rede a seguir fornecem conectividade de rede secundária para pods e servidores virtuais.
- Camada 2 ( L2 )- domínios de transmissão L2 definidos por software usando o encapsulamento Geneve
- Camada 3 ( L3 )- segmentos de rede roteados com sub-redes IP personalizadas. Uma rede do tipo “ L3 ” possui um CIDR (Classless Inter-Domain Routing) distinto para cada nó.
- Localnet - Acesso direto às VLANs da rede física subjacente
Em Red Hat OpenShift Virtualization on IBM Cloud, OVN camada 2 e OVN localnet são as duas principais topologias usadas com redes definidas pelo usuário (UDN).
- A camada 2 do OVN fornece uma rede de sobreposição semelhante aos segmentos de sobreposição do NSX, usando o encapsulamento Geneve para criar domínios de transmissão L2 definidos por software em todo o cluster. Essas redes são isoladas das sub-redes da VPC. Eles exigem um pod de gateway ou servidor virtual que esteja conectado a uma rede local OVN para fornecer entrada e saída para a sub-rede VPC e uma rota VPC.
- O OVN Localnet fornece acesso VLAN à rede VPC subjacente e é semelhante aos segmentos apoiados por VLAN do NSX. Em IBM Cloud VPC, essa conectividade direta permite que servidores e pods virtuais se conectem diretamente a sub-redes VPC usando uma interface de rede virtual (VNI) e anexos de VLAN.
O diagrama a seguir apresenta uma visão geral da rede de servidores virtuais com OVN e multus. Por padrão, Kubernetes (e Red Hat OpenShift ) atribui uma única interface de rede a cada pod usando um plug-in CNI primário (como OVN-
Kubernetes ). O Multus em Red Hat OpenShift é um plug-in da CNI que permite várias interfaces de rede para pods e servidores virtuais.
Inicialmente, apenas a rede de camada 2 da OVN está disponível.
Redes definidas pelo usuário OVN
Red Hat OpenShift Virtualização
Uma rede definida pelo usuário (UDN) em Red Hat OpenShift é uma rede personalizada fornecida pela OVN- Kubernetes. Uma UDN substitui a rede de cluster padrão (também conhecida como rede de pods padrão) UDNs que você usa para criar redes com suas próprias sub-redes IP, gateways e domínios de roteamento. As UDNs são independentes da rede primária do pod e são comumente usadas quando as cargas de trabalho exigem as seguintes funções.
- Isolamento da rede de outros aplicativos no cluster
- Intervalos de endereços IP personalizados ou sub-redes sobrepostas
- Controle direto sobre o tráfego leste-oeste entre namespaces ou cargas de trabalho selecionadas
- Integração com servidores virtuais (virtualização Red Hat OpenShift ) que exigem várias interfaces de rede
- Segmentos de rede dedicados para requisitos de segurança ou conformidade
Ao contrário da rede de pods padrão, as UDNs são explicitamente anexadas aos namespaces. Cada UDN cria um switch lógico extra na OVN. Quando uma UDN é rotulada como a rede primária definida pelo usuário do namespace, todos os pods e servidores virtuais nesse namespace a utilizam como rede principal em vez do padrão do cluster.
A CUDN (Cluster User-Defined Network) expande o conceito de UDN fornecendo um recurso com escopo de cluster que não pertence a nenhum namespace específico. Um CUDN é criado e está associado a um ou mais namespaces. Ao contrário dos recursos
NetworkAttachmentDefinition (NAD) com escopo de espaço de nome que exigem um por espaço de nome, uma CUDN cria automaticamente NADs em espaços de nome quando esses espaços de nome são adicionados à definição da CUDN.
As UDNs oferecem opções flexíveis de rede com base no escopo, no método de conexão e na topologia:
Escopo da rede
- UDN com escopo de namespace - Definição de rede que se limita a um único namespace, exigindo um NetworkAttachmentDefinitions separado por namespace
- CUDN com escopo de cluster - Definição de rede disponível em todo o cluster, criando automaticamente NetworkAttachmentDefinitions em namespaces selecionados
Método de fixação
- Rede primária - atua como a rede padrão para todos os pods/servidores virtuais no namespace, substituindo a rede padrão do cluster
- Rede secundária - conectada por meio do Multus CNI para fornecer interfaces de rede adicionais a pods/servidores virtuais juntamente com a rede primária
Topologia de rede
- Camada 2 — Domínio de difusão de endereços de rede ( L2 ) definido por software, utilizando encapsulamento Geneve, que permite a descoberta baseada no Protocolo de Resolução de Endereços (ARP) e a comunicação MAC-a-MAC
- Camada 3 - segmentos de rede roteados com sub-redes IP e gateways personalizados
- Localnet - Acesso direto de VLAN a sub-redes VPC subjacentes usando anexos de interface de rede virtual (VNI)
Você pode combinar essas características para criar soluções de rede personalizadas. Por exemplo, uma CUDN com escopo de cluster que usa topologia de rede local pode fornecer vários namespaces com acesso direto à sub-rede VPC como rede primária ou secundária.
Redes OVN de camada 2
Uma rede de camada 2 OVN é um domínio de transmissão de camada 2 definido por software, semelhante a um segmento de sobreposição do NSX ou a uma VLAN tradicional. A camada 2 é implementada inteiramente na OVN usando o encapsulamento Geneve sobre a infraestrutura de rede existente do cluster. Uma rede de camada 2 permite que os pods e os servidores virtuais se comuniquem como se estivessem no mesmo segmento Ethernet, com suporte para descoberta de ARP, broadcast, multicast e comunicação direta MAC a MAC.
Um cluster Red Hat OpenShift tem uma rede de cluster primária em que os pods e os servidores virtuais recebem IPs do CIDR padrão do cluster que é roteado por meio do OVN. Você define uma rede secundária de Camada 2 por meio de um ClusterUserDefinedNetwork (CUDN) ou UDN com escopo de namespace. Uma rede secundária de Camada 2 é qualquer rede extra que você cria além da rede padrão do pod.
Os itens a seguir são as principais características das redes de Camada 2.
- Fornecer domínios de transmissão de camada 2 criados pela OVN com IPAM, atribuição de MAC e conectividade
- Não há resolução de DNS integrada para nomes de pods em redes secundárias
- O tráfego proveniente da rede primária de Camada 2 passa por tradução de endereços de rede de origem (NAT) ao sair do servidor virtual e também é roteado para a rede de Camada 2, cujo acesso pode ser configurado por meio de endereços de
rede de origem (
FRR-K8s) e rotas da VPC - As redes secundárias de Camada 2 são isoladas por padrão, sem acesso direto à Internet, a menos que sejam configuradas explicitamente
- Adequado para comunicação de servidor virtual para servidor virtual dentro do cluster e aplicativos dependentes de multicast
Redes OVN Localnet
Uma rede OVN Localnet fornece aos servidores e pods virtuais acesso direto de VLAN à infraestrutura de rede VPC subjacente. O OVN Localnet permite que servidores e pods virtuais se conectem a sub-redes VPC usando uma interface de rede virtual (VNI) e anexos de VLAN.
Com os anexos de VLAN, você pode anexar diretamente servidores virtuais executados na Red Hat OpenShift Virtualization a sub-redes VPC. Você pode usar essa abordagem para usar seu projeto de sub-rede VPC existente para servidores virtuais novos ou migrados, fornecendo uma rede consistente em suas cargas de trabalho.
A rede de rede local exige que cada NIC de servidor virtual conectada a uma sub-rede VPC atenda aos seguintes requisitos:
- Um recurso de interface de rede virtual (VNI) que define um endereço IP reservado na sub-rede da VPC e um ou mais grupos de segurança que controlam o tráfego de entrada e saída para a VNI.
- Um anexo de VLAN de servidor bare metal. A capacidade de flutuação dessa conexão de VLAN, que determina se a conexão pode ser transferida entre nós de trabalho, deve estar habilitada para que o servidor virtual possa ser migrado dinamicamente para outro nó de trabalho.
- UMA VLAN ID. A tag VLAN associa a interface PCI nos nós de trabalho. Normalmente, essa associação é um mapeamento de um para um entre a VLAN ID e a sub-rede VPC.
Ao projetar regras de grupo de segurança para redes localnet, considere que parte da comutação de rede ocorre dentro do OVS no nó de trabalho e nunca chega à infraestrutura da VPC. As regras do grupo de segurança são aplicadas somente ao tráfego que atravessa a malha de rede da VPC. O tráfego entre servidores virtuais no mesmo nó de trabalho pode contornar os controles de segurança da VPC.
Os exemplos a seguir são casos de uso do Localnet.
- Servidores virtuais migrados que exigem endereços IP de sub-rede VPC existentes
- Integração com grupos de segurança VPC e políticas de rede existentes
- Conectividade direta com outros recursos da VPC
- Requisitos de conformidade para segmentação de rede usando sub-redes VPC
- Arquiteturas híbridas que exigem endereçamento IP consistente em VPC e Red Hat OpenShift Virtualização
Próximas etapas
Agora que você entende o projeto de rede para a virtualização Red Hat OpenShift, explore estes tópicos relacionados:
- Segurança: Revisar as considerações do projeto de segurança, incluindo políticas de rede e SCCs
- Computação: Explorar opções de design de computação para nós de trabalho
- Armazenamento: Saiba mais sobre os padrões de design de armazenamento para volumes persistentes
- Observabilidade: Entenda as soluções de observabilidade para monitoramento de rede