Recursos-chave

VNIs estáticos por nó de trabalho

Quando você cria um cluster Red Hat OpenShift on IBM Cloud baseado em bare metal ou um novo pool de trabalho em IBM Cloud VPC, dois VNIs são automaticamente criados e anexados estaticamente a cada nó de trabalho bare metal. Uma VNI lida com o tráfego regular de trabalhadores (rede de pods, UDNs de sobreposição e comunicação principal). O segundo VNI atua como um portador para anexos dinâmicos de VNI que você gerencia.

Anexos dinâmicos do VNI

Você pode criar e gerenciar VNIs sob demanda após a criação do cluster. As VNIs dinâmicas podem ser anexadas a trabalhadores específicos ou configuradas para flutuar entre trabalhadores na mesma zona, seguindo as cargas de trabalho do VM durante a migração em tempo real.

Suporte à migração em tempo real

Com VNIs conectados a nós de trabalho bare metal, as migrações em tempo real de VMs baseadas em virtualização OpenShift podem preservar as conexões de rede. O VNI flutua implicitamente e segue a carga de trabalho entre as instâncias de trabalho bare metal dentro da mesma zona.

Para obter limitações e considerações importantes sobre VNIs, consulte Limitações e considerações.

Anexo entre contas

Em Red Hat OpenShift on IBM Cloud, os nós de trabalho não são provisionados em sua conta, o que significa que o gerenciamento do ciclo de vida das VNIs é ligeiramente diferente das instâncias bare metal de VPCs autônomas. O administrador do cluster Red Hat OpenShift on IBM Cloud tem visibilidade diferente dos anexos dos VNIs porque eles são anexados a cargas de trabalho que não são visíveis na conta. As diferenças no gerenciamento do VNI são abordadas nesta documentação.

Para obter mais informações sobre VNIs em instâncias bare metal de VPC autônomas, consulte Sobre interfaces de rede virtual.

Criação de uma UDN primária

Para usar uma rede primária definida pelo usuário para pods ou carga de trabalho VM, primeiro crie a própria UDN.

Exemplo de uma rede definida pelo usuário do cluster que pode ser usada em todos os namespaces:

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

Em seguida, crie o(s) namespace(s) que o(s) utilizará(ão). O espaço de nome deve conter um rótulo específico (chamado k8s.ovn.org/primary-user-defined-network) na criação para uso da UDN primária.

Exemplo:

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

Quando a (C)UDN e os namespaces estiverem em vigor, qualquer carga de trabalho criada nesse namespace acessará a UDN com a rota padrão.

Criação de uma UDN secundária

A configuração da UDN secundária é semelhante à da UDN primária, mas com a função definida como Secondary. Para obter informações detalhadas, consulte a documentação sobre Red Hat OpenShift multiple networks.

Instalação do operador NMState

OpenShift Serviço de virtualização Os clusters têm o operador NMState pré-instalado e são gerenciados pelo complemento openshift-virtualization. Pule esta etapa se estiver usando o Serviço de Virtualização.

1. Implante o NMState Operator a partir do site OperatorHub no console Red Hat OpenShift on IBM Cloud ou usando a CLI.

2. Crie uma instância do NMState com a configuração padrão.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

Criação da ponte OVS

OpenShift Serviço de virtualização Os clusters têm os recursos NNCP necessários pré-configurados. Você só precisa criar esses recursos manualmente para clusters padrão do OpenShift com instalação manual do OpenShift Virtualization.

1. Crie uma ponte OVS dedicada com eth1 anexado a ela implantando o seguinte recurso personalizado NMState.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. Verifique o status do recurso personalizado e aguarde até que todos os nós do cluster aplicáveis reconciliem a solicitação de criação da ponte.

3. Faça o patch da nova ponte OVS para a ponte padrão criando o seguinte recurso personalizado NMState. Substitua vpc-vlans pelo nome de rede desejado.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. Verifique o status do recurso personalizado e aguarde até que todos os nós do cluster aplicáveis reconciliem a solicitação de mapeamento de ponte.

Criação de uma rede definida pelo usuário localnet

Crie uma UDN ou ClusterUserDefinedNetwork (CUDN) que disponibilize o tráfego de VNIs usando a VLAN selecionada.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

Substitua os seguintes valores:

• vlan250: O nome de seu CUDN
• default: O namespace em que você deseja usar o CUDN
• vpc-vlans: O nome da rede física que você definiu no mapeamento da ponte
• 250: Sua VLAN ID desejada (intervalo: 1-500)

Isso conclui o encanamento de rede de uma VLAN específica. Você pode definir vários CUDNs usando VLAN IDs diferentes e reutilizando os mapeamentos de ponte.

Após concluir a configuração da UDN localnet, é possível anexar VNIs ao cluster usando o console IBM Cloud ou o comando IBM Cloud CLI ks vni. Veja os exemplos nas seções a seguir.

Antes de Iniciar

1. Crie VNIs em sua VPC com a configuração apropriada de sub-rede e endereço IP.

2. Certifique-se de que você tenha as permissões necessárias para gerenciar o cluster e as VNIs.

Exemplo

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

Exemplo de saída

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

Exemplo de saída

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

Exemplo

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

Por que não posso anexar pods regulares a UDNs de rede local?

As UDNs de rede local têm o gerenciamento de endereços IP (IPAM) desativado no lado da OVN, o que significa que a atribuição de endereços IP estáticos a pods não ocorre na OVN. Essa configuração foi projetada para cargas de trabalho do VM que usam DHCP ou definem IPs estáticos dentro do sistema operacional convidado. Essas opções não estão disponíveis para cargas de trabalho de pod.

Por que a migração em tempo real está pendente nos pools de trabalhadores?

Diferentes pools de trabalho podem ter diferentes tipos de trabalho com CPUs de diferentes gerações e recursos. Se o conjunto completo de recursos da CPU estiver visível de forma transparente para a carga de trabalho do VM, você não poderá migrar o VM para outro trabalhador que não ofereça suporte a todos os recursos da CPU. Você pode limitar os recursos visíveis da CPU do sistema operacional convidado no início para obter mais compatibilidade entre os tipos de trabalho.

Por que os VNIs com conexão dinâmica não estão funcionando?

Verifique os seguintes itens:

• Verifique se a ID da VLAN na CUDN corresponde à ID da VLAN no anexo da VNI. O DHCP da VPC ainda poderá funcionar sem tráfego adicional se a VLAN for incompatível.
• Se a flutuação não estiver ativada, verifique se a carga de trabalho está programada no trabalhador ao qual a VNI está conectada.
• Verifique se a ponte OVS dedicada e o mapeamento estão presentes nos trabalhadores. Verifique o status do recurso NodeNetworkConfigurationPolicy.