Implantar Aplicativos de Contêiner de Interfaces de Rede Ativadas por SR-IOV no OKE Usando o Plug-in CNI Multus

Introdução

Neste tutorial, exploraremos como implantar aplicativos em contêineres em nós de trabalho de instância virtual no Oracle Cloud Infrastructure Kubernetes Engine (OKE), aproveitando os recursos avançados de rede. Especificamente, ativaremos a SR-IOV (Single Root I/O Virtualization) para interfaces de rede de contêineres e configurar o plug-in Multus CNI para ativar a rede de hospedagem múltipla para seus contêineres.

Combinando SR-IOV com Multus, você pode obter uma rede de alto desempenho e baixa latência para cargas de trabalho especializadas, como IA, machine learning e processamento de dados em tempo real. Este tutorial fornecerá instruções passo a passo para configurar seu ambiente OKE, implantar nós de trabalho com interfaces ativadas para SR-IOV e usar o Multus CNI para gerenciar várias interfaces de rede em seus pods. Se você está visando o processamento de pacotes de alta velocidade ou precisa ajustar sua rede do Kubernetes, este tutorial irá equipá-lo com as ferramentas e o conhecimento para começar.

Observação:

No momento da publicação deste tutorial, o SR-IOV CNI não pode ser usado por pods ou contêineres em uma instância virtual que faz parte de um cluster do OKE junto com o plug-in Multus CNI.

Neste tutorial, mostraremos como você pode usar uma interface ativada por SR-IOV dentro de um pod em execução em pods ou contêineres em uma instância virtual que faz parte de um cluster do OKE movendo o VNIC (Virtual Network Interface Cards) (que está em uma instância virtual) em um pod e é utilizável com a ajuda do plug-in Multus CNI (onde o plug-in SR-IOV CNI não é usado).

O plug-in SR-IOV CNI é suportado em uma Instância Bare Metal que faz parte de um cluster do OKE junto com o plug-in Multus CNI. Este tutorial está fora do escopo.

Objetivos

Implante aplicativos de contêiner em nós de trabalho de instância virtual no OKE com interfaces de rede ativadas por SR-IOV usando o plug-in Multus CNI.

Tarefa 1: Implantar o OKE com um Bastion, um Operador, Três Nós de Trabalho de VM e o Plug-in Flannel CNI

Certifique-se de que o OKE esteja implantado com a seguinte configuração:

Bastion
Operador
3 Nós de Trabalho da VM
Plug-in CNI Flannel

Essa configuração é detalhada no tutorial aqui: Implante um Cluster do Kubernetes com o Terraform usando o Oracle Cloud Infrastructure Kubernetes Engine.

A imagem a seguir mostra uma visão geral dos componentes com os quais trabalharemos ao longo deste tutorial.

Tarefa 2: Ativar a Rede SR-IOV (Assistida por Hardware) em Cada Nó de Trabalho

Observação: as seguintes etapas precisam ser executadas em todos os nós de trabalho que fazem parte do cluster do OKE.

A imagem a seguir mostra uma visão geral visual de nossos nós de trabalho dentro do cluster do OKE com o qual trabalharemos ao longo deste tutorial.

Ativar SR-IOV na Instância

Faça log-in com SSH na instância ou no nó de trabalho.
1. Execute o comando lspci para verificar qual driver de rede está sendo usado no momento em todas as VNICs.
2. Observe que o driver de rede Virtio é usado.
1. Vá para a página Detalhes da Instância na Console do OCI.
2. Role para baixo.
3. Observe que o tipo de anexo de NIC agora é PARAVIRTUALIZED.
1. Vá para a página Detalhes da Instância na Console do OCI.
2. Clique em Mais Ações.
3. Clique em Editar.
Clique em Mostrar opções avançadas.
1. Clique em Opções de inicialização e selecione Rede assistida por hardware (SR-IOV) como Tipo de rede.
2. Clique em Salvar alterações.
Clique em Reinicializar instância para confirmar a reinicialização da instância.
Observe que o status da instância foi alterado para STOPPING.
Observe que o status da instância foi alterado para STARTING.
Observe que o status da instância foi alterado para RUNNING.
1. Role para baixo.
2. Observe que o tipo de anexo de NIC agora é VFIO.
A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 3: Criar uma Nova Sub-rede para as VNICs Ativadas por SR-IOV

Criaremos uma sub-rede dedicada que nossas interfaces ativadas para SR-IOV usarão.

Tarefa 3.1: Criar uma Lista de Segurança

Como já estamos usando listas de segurança para as outras sub-redes, também precisamos de uma lista de segurança dedicada para a sub-rede SR-IOV recém-criada.

Vá para a Console do OCI.
1. Navegue até Redes Virtuais na Nuvem.
2. Clique na VCN existente.
1. Clique em Listas de Segurança.
2. Clique em Criar Lista de Segurança.
Para a Regra de Entrada 1, especifique as informações a seguir.
1. Informe um Nome.
2. Selecione CIDR como Tipo de Origem.
3. Informe 0.0.0.0/0 como CIDR de Origem.
4. Selecione Todos os Protocolos como Protocolo IP.
5. Role para baixo.
1. Para a Regra de Saída 1, especifique as informações a seguir.
2. Selecione CIDR como Tipo de Origem.
3. Informe 0.0.0.0/0 como CIDR de Origem.
4. Selecione Todos os Protocolos como Protocolo IP.
5. Clique em Criar Lista de Segurança.
Observe que a nova lista de segurança é criada.

Tarefa 3.2: Criar uma Sub-rede

Vá para a página Detalhes da Rede Virtual em Nuvem.
1. Clique em Sub-redes.
2. Observe as sub-redes existentes que já foram criadas para o ambiente do OKE.
3. Clique em Criar Sub-rede.
1. Informe um Nome.
2. Informe o Bloco IPv4 CIDR.
3. Role para baixo.
1. Selecione Sub-rede Privada.
2. Role para baixo.
1. Selecione Opções DHCP Padrão para Opções DHCP.
2. Selecione Lista de Segurança criada na Tarefa 3.1.
3. Clique em Criar Sub-rede.
Observe que a sub-rede de rede é criada.
Observação:
- A sub-rede em si não tem nenhum componente técnico ativado por SR-IOV.
- Neste tutorial, estamos usando uma sub-rede OCI padrão para permitir o transporte de tráfego usando a tecnologia SR-IOV.
A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 4: Adicionar um Segundo Anexo de VNIC

A imagem a seguir mostra uma visão geral visual de como os nós de trabalho têm uma única VNIC conectada à sub-rede dos nós de trabalho antes de adicionarmos uma segunda VNIC.

Antes de adicionarmos um segundo anexo de VNIC aos nós de trabalho, crie um Grupo de Segurança de Rede.

Tarefa 4.1: Criar um NSG (Network Security Group)

Já estamos usando o NSG para as outras VNICs, mas também precisamos de um NSG dedicado para a VNIC recém-criada que adicionaremos a uma instância virtual existente que faça parte do cluster do OKE e que faça sua parte como um nó de trabalho do Kubernetes. Essa interface será uma VNIC na qual temos o SR-IOV ativado.

Vá para a página Detalhes da Rede Virtual em Nuvem.
1. Navegue até Grupos de Segurança de Rede.
2. Clique em Criar Grupo de Segurança de Rede.
Adicione as regras a seguir.
1. Entrada:
  - Permitir Tipo de Origem: Selecione CIDR.
  - Origem: Informe 0.0.0.0/0.
  - Destino: Deixe o destino em branco.
  - Protocolo: Permitir todos os protocolos.
2. Saída:
  - Tipo de Origem de Permissão: Selecione CIDR
  - Origem: Deixe a origem em branco.
  - Destino: Digite 0.0.0.0/0.
  - Protocolo: Permitir todos os protocolos.
Observe que o NSG é criado. Nós a aplicaremos à nova VNIC (secundária) que criaremos (em cada nó de trabalho no cluster do OKE).

Tarefa 4.2: Adicionar a VNIC

Navegue até cada instância de nó de trabalho virtual e adicione uma segunda VNIC a cada nó de trabalho.
1. Navegue até cada instância de nó de trabalho virtual e clique em VNICs Anexadas.
2. Observe que já existe uma VNIC.
3. Clique em Criar VNIC para adicionar uma segunda VNIC.
1. Informe um Nome.
2. Selecione a VCN.
3. Selecione a Sub-rede criada na Tarefa 3.2.
4. Selecione Usar Grupos de Segurança de Rede para controlar o tráfego.
5. Selecione o NSG criado na Tarefa 4.1.
6. Role para baixo.
1. Selecione Designar automaticamente o endereço IPv4 privado.
2. Clique em Salvar alterações.
Observe que a segunda VNIC é criada e anexada à instância do nó de trabalho virtual e também anexada à nossa sub-rede.
Faça log-in com SSH na instância ou no nó de trabalho.
1. Execute o comando lspci para verificar qual driver de rede está sendo usado no momento em todas as VNICs.
2. Observe que o driver de rede Mellanox Technologies ConnectX Family mlx5Gen Virtual Function é usado.
O driver de rede de Funções Virtuais da Família ConnectX Mellanox Technologies mlx5Gen é o driver de Funções Virtuais (VF) usado pelo SR-IOV. Portanto, a VNIC é ativada para SR-IOV com um VF.
A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 5: Designar um Endereço IP à Nova Segunda VNIC com um Gateway Padrão

Agora que a segunda VNIC foi criada na Tarefa 4 e anexada, precisamos designar um endereço IP a ela. Quando você adiciona uma segunda interface a uma instância, pode designá-la à mesma sub-rede da primeira interface ou pode escolher uma nova sub-rede.

O DHCP não está ativado para a segunda interface, portanto, o endereço IP precisa ser atribuído manualmente.

Existem diferentes métodos de atribuição do endereço IP para a segunda interface.

Método 1: Use a CLI do OCI (Oracle Cloud Infrastructure Command Line Interface) (pacote oci-utils) para designar um endereço IP à segunda interface de uma instância do OCI Compute usando o comando OCI-network-config.
Método 2: Use a CLI do OCI (pacote oci-utils) para designar um endereço IP à segunda interface de uma instância do OCI Compute usando o daemon id.
Método 3: Use o script OCI_Multi_VNIC_Setup.
Método 4: Crie o arquivo de configuração da interface manualmente para a nova VNIC na pasta /etc/sysconfig/network-scripts/.

Para todos os nós de trabalho, designamos um endereço IP à vNIC secundária (ens5). Usamos o Método 3 para designar um endereço IP à vNIC secundária (ens5). Para obter mais informações sobre a designação de um endereço IP à segunda VNIC, consulte Designar um Endereço IP a uma Segunda Interface em uma Instância do Oracle Linux.

Depois que o endereço IP for designado a uma VNIC, precisaremos verificar se o endereço IP nas segundas VNICs está configurado corretamente. Também podemos verificar se ativamos o SR-IOV em todos os nós de trabalho do pool de nós.

Nosso cluster do OKE consiste em:

Pool de Nós
NP1	1 x Nó de Trabalho
NP2	3 x Nós de Trabalho

Verificaremos todos os nós de trabalho em todos os pools de nós.

Tarefa 5.1: Verificar todos os Nós no Pool de Nós 1 (`np1`)

No cluster do OKE, clique em Nós.
Clique no primeiro pool de nós (np1).
Clique no nó de trabalho que faz parte deste pool de nós.
1. Observe que o tipo de anexo de NIC é VFIO (isso significa que o SR-IOV está ativado para este nó de trabalho de instância virtual).
2. Observe que a segunda VNIC é criada e anexada a este nó de trabalho.

Tarefa 5.2: Verificar todos os Nós no Pool de Nós 2 (`np2`)

Clique nos nós um a um e inicie a verificação.
1. Observe que o tipo de anexo de NIC é VFIO (isso significa que o SR-IOV está ativado para este nó de trabalho de instância virtual).
2. Observe que a segunda VNIC é criada e anexada a este nó de trabalho.
Vá para a página de resumo do pool de nós 2 (np2). Clique no segundo nó de trabalho no pool de nós.
1. Observe que o tipo de anexo de NIC é VFIO (isso significa que o SR-IOV está ativado para este nó de trabalho de instância virtual).
2. Observe que a segunda VNIC é criada e anexada a este nó de trabalho.
Vá para a página de resumo do pool de nós 2 (np2). Clique no terceiro nó de trabalho no pool de nós.
1. Observe que o tipo de anexo de NIC é VFIO (isso significa que o SR-IOV está ativado para este nó de trabalho de instância virtual).
2. Observe que a segunda VNIC é criada e anexada a este nó de trabalho.

Faça log-in usando SSH para o Operador do Kubernetes.

Execute o comando kubectl get nodes para recuperar uma lista e endereços IP de todos os nós de trabalho.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Para facilitar o uso do SSH em todos os nós de trabalho, criamos a tabela a seguir.

Nome do Nó de Trabalho	IP ens3	Workernode de comando SSH
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

Para que você possa usar o SSH em todos os nós de trabalho virtuais, certifique-se de ter a chave privada correta disponível.
Execute o comando ssh -i <private key> opc@<ip-address> para SSH em todos os nós de trabalho.

Execute o comando ip a no nó de trabalho cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0.

Observe que quando o endereço IP foi configurado com sucesso, o ens5 (segunda VNIC) tem um endereço IP na faixa da sub-rede criada na Tarefa 3.2 para as interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

Execute o comando ip a no nó de trabalho cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1.

Observe que quando o endereço IP foi configurado com sucesso, o ens5 (segunda VNIC) tem um endereço IP na faixa da sub-rede criada na Tarefa 3.2 para as interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

Execute o comando ip a no nó de trabalho cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0.

Observe que quando o endereço IP foi configurado com sucesso, o ens5 (segunda VNIC) tem um endereço IP na faixa da sub-rede criada na Tarefa 3.2 para as interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

Execute o comando ip a no nó de trabalho cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2.

Observe que quando o endereço IP foi configurado com sucesso, o ens5 (segunda VNIC) tem um endereço IP na faixa da sub-rede criada na Tarefa 3.2 para as interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

Verificamos que todos os endereços IP estão configurados na segunda VNIC (ens5), podemos criar a tabela a seguir com as informações.

IP ens3	ens3 GW	IP ens5	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 6: Instalar um CNI de Meta-Plugin (Multus CNI) no Nó de Trabalho

O Multus CNI é um plug-in da Interface de Rede de Contêiner (CNI) do Kubernetes que permite anexar várias interfaces de rede a um pod.

Como funciona o Multus CNI

Atua como um metaplugin: O Multus não fornece rede em si, mas chama outros plug-ins CNI.
Cria várias interfaces de rede: cada pod pode ter mais de uma interface de rede combinando vários plug-ins CNI (por exemplo, Flannel, Calico, SR-IOV).
Usa um arquivo de configuração: A rede principal é configurada usando o CNI padrão, e redes adicionais são anexadas com base em uma Definição de Recurso Personalizado (CRD).

Por que precisamos do Multus CNI

Isolamento de Várias Redes: Útil para cargas de trabalho que exigem gerenciamento e planos de dados separados.
Rede de Alto Desempenho: Permite o acesso direto ao hardware usando SR-IOV ou DPDK.
Multi-Homing para Pods: Suporta casos de uso de NFV (Network Function Virtualization) e Telco em que várias interfaces de rede são essenciais.

Tarefa 6.1: Instalar Multus CNI usando o Método de Instalação Fina

SSH no Operador do Kubernetes.
1. Execute o comando a seguir para clonar a biblioteca Multus Git.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Execute o comando a seguir para instalar o conjunto de daemon Multus usando o método de instalação thin.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

O que o conjunto de daemon Multus faz

Inicia um conjunto de daemon Multus, isso executa um pod em cada nó que coloca um binário Multus em cada nó em /opt/cni/bin.
Lê o primeiro arquivo de configuração lexicograficamente (alfabeticamente) em /etc/cni/net.d e cria um novo arquivo de configuração para Multus em cada nó como /etc/cni/net.d/00-multus.conf. Essa configuração é gerada automaticamente e se baseia na configuração de rede padrão (que é assumida como a primeira configuração alfabeticamente).
Cria um diretório chamado /etc/cni/net.d/multus.d em cada nó com informações de autenticação para o Multus para acessar a API do Kubernetes.

Tarefa 6.2: Validar a instalação do Multus

Execute o seguinte comando (no Operador do Kubernetes) para validar se o conjunto de daemon Multus está instalado em todos os nós de trabalho.
```
kubectl get pods --all-namespaces | grep -i multus
```
Também é possível verificar se o conjunto de daemon Multus está instalado nos próprios nós de trabalho.
1. Execute o comando ssh -i id_rsa opc@10.0.112.134 para SSH no nó de trabalho com o comando a seguir.
2. Execute o comando cd /etc/cni/net.d/ para alterar o diretório com o comando a seguir.
3. Execute o comando ls -l para listar a saída do diretório com o comando a seguir.
4. Observe que os arquivos 00-multus.conf e multus.d são listados.
1. Execute o comando sudo more 00-multus.conf para exibir o conteúdo do arquivo 00-multus.conf.
2. Observe o conteúdo do arquivo 00-multus.conf.

Tarefa 7: Anexar Interfaces de Rede a Pods

Nesta tarefa, mapearemos ou anexaremos uma interface de contêiner a essa VNIC.

Para anexar interfaces adicionais aos pods, precisamos de uma configuração para a interface a ser anexada.

Isso é encapsulado no recurso personalizado do tipo NetworkAttachmentDefinition.
Esta configuração é essencialmente uma configuração CNI empacotada como um recurso personalizado.

Existem vários plugins CNI que podem ser usados ao lado do Multus para conseguir isso. Para obter mais informações, consulte Visão Geral de Plug-ins.

Na abordagem descrita aqui, o objetivo é fornecer uma função virtual (VF) SR-IOV exclusivamente para um único pod, para que o pod possa aproveitar os recursos sem interferência ou quaisquer camadas no meio.
Para conceder a um pod acesso exclusivo ao VF, podemos aproveitar o plug-in host-device que permite mover a interface para o namespace do pod para que ele tenha acesso exclusivo a ele. Para obter mais informações, consulte host-device.

O exemplo a seguir mostra objetos NetworkAttachmentDefinition que configuram a interface ens5 secundária que foi adicionada aos nós.

A configuração do plug-in ipam determina como os endereços IP são gerenciados para essas interfaces.
Neste exemplo, como queremos usar os mesmos endereços IP que foram designados às interfaces secundárias pelo OCI, usamos a configuração ipam estática com as rotas apropriadas.
A configuração ipam também suporta outros métodos como host-local ou dhcp para configurações mais flexíveis.

Tarefa 7.1: Criar Definição de Anexo de Rede

O NetworkAttachmentDefinition é usado para configurar o anexo de rede, por exemplo, a interface secundária do pod.

Há duas maneiras de configurar o NetworkAttachmentDefinition:

NetworkAttachmentDefinition com configuração JSON CNI.
NetworkAttachmentDefinition com arquivo de configuração CNI.

Observação: Neste tutorial, usaremos o método usando o arquivo de configuração CNI.

Temos 4 nós de trabalho x e cada nó de trabalho tem uma segunda VNIC que vamos mapear para uma interface em um contêiner (pod).

Execute os comandos a seguir para criar os arquivos de configuração CNI para todos os nós de trabalho e VNICs correspondentes.

ens3	ens5	name	pública	comando nano
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Execute as etapas a seguir no Operador do Kubernetes. Crie um novo arquivo YAML para o primeiro nó de trabalho usando o comando sudo nano sriov-vnic-1.yaml.
- Certifique-se de que o nome seja exclusivo e descritivo. Neste exemplo, estamos usando sriov-vnic-1.
- Utilize o endereço IP do segundo adaptador que acabou de adicionar (ens5).
- Verifique se o dst network também está correto. Ele é igual à sub-rede criada na Tarefa 3.2.
sriov-vnic-1.yaml:
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-1
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

Crie um novo arquivo YAML para o segundo nó de trabalho usando o comando sudo nano sriov-vnic-2.yaml.

sriov-vnic-2.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Crie um novo arquivo YAML para o terceiro nó de trabalho usando o comando sudo nano sriov-vnic-3.yaml.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Crie um novo arquivo YAML para o quarto nó de trabalho usando o comando sudo nano sriov-vnic-4.yaml.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Aplique o NetworkAttachmentDefinition aos nós de trabalho.

Execute o comando kubectl apply -f sriov-vnic-1.yaml para o primeiro nó.
Execute o comando kubectl apply -f sriov-vnic-2.yaml para o segundo nó.
Execute o comando kubectl apply -f sriov-vnic-3.yaml para o terceiro nó.
Execute o comando kubectl apply -f sriov-vnic-4.yaml para o quarto nó.

Se o NetworkAttachmentDefinition for aplicado corretamente, você verá algo semelhante à saída.

[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$

Execute o comando kubectl get network-attachment-definitions.k8s.cni.cncf.io para verificar se o NetworkAttachmentDefinitions foi aplicado corretamente.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

Execute o comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml para obter a NetworkAttachmentDefinition aplicada para o primeiro nó de trabalho.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Execute o comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml para obter o NetworkAttachmentDefinition aplicado para o segundo nó de trabalho.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Execute o comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml para obter o NetworkAttachmentDefinition aplicado para o terceiro nó de trabalho.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Execute o comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml para obter a NetworkAttachmentDefinition aplicada para o quarto nó de trabalho.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 7.2: Criar Pods com o `NetworkDefinitionAttachment` Anexado

Nesta tarefa, vincularemos o NetworkAttachmentDefinitions a um contêiner ou pod real.

Na tabela a seguir, criamos um mapeamento sobre qual pod queremos hospedar em qual nó de trabalho.

IP do Nó do Colaborador (Principal)	ens5	name	nome do pod	finalizado
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	SIM
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	SIM
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	SIM
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	SIM

Tarefa 7.3: Criar Pods com Afinidade de Nó

Por padrão, o Kubernetes decidirá onde os pods serão colocados (nó do colaborador). Neste exemplo, isso não é possível porque uma NetworkAttachmentDefinition está vinculada a um endereço IP e esse endereço IP está vinculado a uma VNIC e essa VNIC está vinculada a um nó de trabalho específico. Portanto, precisamos ter certeza de que os pods que criamos terminarão no nó de trabalho desejado e isso é necessário quando anexamos o NetworkAttachmentDefinition a um pod.

Se não fizermos isso, pode acontecer que um pod acabe em um local diferente onde o endereço IP está disponível para o pod. Portanto, o pod não poderá se comunicar usando a interface ativada por SR-IOV.

Obtenha todos os nós disponíveis usando o comando kubectl get nodes.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Atribua um label ao nó de trabalho 1 usando o comando kubectl label node 10.0.112.134 node_type=testpod1.
Atribua um label ao nó de trabalho 2 usando o comando kubectl label node 10.0.66.97 node_type=testpod2.
Atribua um label ao nó de trabalho 3 usando o comando kubectl label node 10.0.73.242 node_type=testpod3.
Atribua um label ao nó de trabalho 4 usando o comando kubectl label node 10.0.89.50 node_type=testpod4.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Crie um arquivo YAML para o testpod1 usando o comando sudo nano testpod1-v2.yaml.

Observe a seção annotations na qual associamos o NetworkAttachmentDefinition que criamos anteriormente (sriov-vnic-1) a esse pod de teste.
Observe a seção spec:affinity:nodeAffinity na qual vinculamos o pod de teste a um nó de trabalho específico com o label testpod1.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Crie um arquivo YAML para o testpod2 usando o comando sudo nano testpod2-v2.yaml.

Observe a seção annotations na qual associamos o NetworkAttachmentDefinition que criamos anteriormente (sriov-vnic-2) a esse pod de teste.
Observe a seção spec:affinity:nodeAffinity na qual vinculamos o pod de teste a um nó de trabalho específico com o label testpod2.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Crie um arquivo YAML para o testpod3 usando o comando sudo nano testpod3-v2.yaml.

Observe a seção annotations na qual associamos o NetworkAttachmentDefinition que criamos anteriormente (sriov-vnic-3) a esse pod de teste.
Observe a seção spec:affinity:nodeAffinity na qual vinculamos o pod de teste a um nó de trabalho específico com o label testpod3.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Crie um arquivo YAML para o testpod4 usando o comando sudo nano testpod4-v2.yaml.

Observe a seção annotations na qual associamos o NetworkAttachmentDefinition que criamos anteriormente (sriov-vnic-4) a esse pod de teste.
Observe a seção spec:affinity:nodeAffinity na qual vinculamos o pod de teste a um nó de trabalho específico com o label testpod4

sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Crie o testpod1 aplicando o arquivo YAML usando o comando kubectl apply -f testpod1-v2.yaml.
Crie o testpod2 aplicando o arquivo YAML usando o comando kubectl apply -f testpod2-v2.yaml.
Crie o testpod3 aplicando o arquivo YAML usando o comando kubectl apply -f testpod3-v2.yaml.
Crie o testpod4 aplicando o arquivo YAML usando o comando kubectl apply -f testpod4-v2.yaml.

[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$

Verifique se os pods de teste foram criados usando o comando kubectl get pod. Observe que todos os pods de teste são criados e têm o Running STATUS.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

Verifique se o testpod1 está em execução no nó de trabalho 10.0.112.134 com o label testpod1 usando o comando kubectl get pod testpod1 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

Verifique se o testpod2 está em execução no nó de trabalho 10.0.66.97 com o label testpod2 usando o comando kubectl get pod testpod2 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

Verifique se o testpod3 está em execução no nó de trabalho 10.0.73.242 com o label testpod3 usando o comando kubectl get pod testpod3 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

Verifique se o testpod4 está em execução no nó de trabalho 10.0.89.50 com o label testpod4 usando o comando kubectl get pod testpod4 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 7.4: Verificar o Endereço IP nos Pods de Teste

Verifique o endereço IP de testpod1 para a interface de pod net1 usando o comando kubectl exec -it testpod1 -- ip addr show.

Observe que o endereço IP da interface net1 é 10.0.3.30/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

Verifique o endereço IP de testpod2 para a interface de pod net1 usando o comando kubectl exec -it testpod2 -- ip addr show.

Observe que o endereço IP da interface net1 é 10.0.3.15/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

Verifique o endereço IP de testpod3 para a interface de pod net1 usando o comando kubectl exec -it testpod3 -- ip addr show.

Observe que o endereço IP da interface net1 é 10.0.3.14/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

Verifique o endereço IP de testpod4 para a interface de pod net1 usando o comando kubectl exec -it testpod4 -- ip addr show.

Observe que o endereço IP da interface net1 é 10.0.3.16/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

A tabela a seguir mostra uma visão geral de todos os endereços IP das interfaces net1 para todos os pods de teste.

nome do pod	IP net1
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

Observação: Esses endereços IP estão na mesma faixa da sub-rede do OCI que foi criada na Tarefa 3 para colocar nossas VNICs ativadas por SR-IOV.

Tarefa 7.5: Verificar o Endereço IP nos Nós de Trabalho

Agora que as interfaces net1 dos pods de teste têm um endereço IP, observe que esse endereço IP costumava ser o endereço IP da interface ens5 nos nós de trabalho. Esse endereço IP agora é movido da interface do nó de trabalho ens5 para a interface do pod de teste net1.

Estabeleça conexão via SSH no primeiro nó de trabalho usando o comando ssh -i id_rsa opc@10.0.112.134.

Obtenha os endereços IP de todas as interfaces usando o comando ip a.
Observe que a interface ens5 foi removida do nó de trabalho.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

Estabeleça conexão via SSH no segundo nó de trabalho usando o comando ssh -i id_rsa opc@10.0.66.97.

Obtenha os endereços IP de todas as interfaces usando o comando ip a.
Observe que a interface ens5 foi removida do nó de trabalho.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

Estabeleça conexão via SSH no terceiro nó de trabalho usando o comando ssh -i id_rsa opc@10.0.73.242.

Obtenha os endereços IP de todas as interfaces usando o comando ip a.
Observe que a interface ens5 foi removida do nó de trabalho.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

Estabeleça conexão via SSH no quarto nó de trabalho usando o comando ssh -i id_rsa opc@10.0.89.50.

Obtenha os endereços IP de todas as interfaces usando o comando ip a.
Observe que a interface ens5 foi removida do nó de trabalho.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 8: Executar Testes de Ping entre Vários Pods

Todos os pods têm um endereço IP da sub-rede do OCI em que as VNICs ativadas por SR-IOV estão anexadas. Podemos fazer alguns testes de ping para verificar se a conectividade de rede está funcionando corretamente.

A tabela a seguir fornece os comandos para estabelecer conexão com os pods de teste do Kubernetes Operator.

Precisamos disso para exec em cada pod para executar um teste de ping ou para observar a tabela de roteamento.

ens3	net1	name	nome do pod	comando
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

Execute o comando kubectl exec -it testpod1 -- route -n para verificar a tabela de roteamento diretamente no terminal do Operador do Kubernetes para testpod1.

Observe que a tabela de roteamento de testpod1 tem um gateway padrão para eth0 e para net1, que é nossa interface ativada por SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Execute o comando kubectl exec -it testpod2 -- route -n para verificar a tabela de roteamento diretamente no terminal do Operador do Kubernetes para testpod2.

Observe que a tabela de roteamento de testpod2 tem um gateway padrão para eth0 e para net1, que é nossa interface ativada por SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Execute o comando kubectl exec -it testpod3 -- route -n para verificar a tabela de roteamento diretamente no terminal do Operador do Kubernetes para testpod3.

Observe que a tabela de roteamento de testpod3 tem um gateway padrão para eth0 e para net1, que é nossa interface ativada por SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

Execute o comando kubectl exec -it testpod4 -- route -n para verificar a tabela de roteamento diretamente no terminal do Operador do Kubernetes para testpod4.

Observe que a tabela de roteamento de testpod4 tem um gateway padrão para eth0 e para net1, que é nossa interface ativada por SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Para executar o teste de ping do Operador do Kubernetes diretamente dos pods de teste, precisamos do comando de ping.

Na tabela a seguir, fornecemos todos os comandos de ping para todos os pods de teste. O comando fará ping de um pod de teste específico para todos os outros pods de teste, incluindo seu endereço IP net1.

Nome do pod de origem	comando
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

Observação: Neste exemplo, estamos usando testpod1 para fazer ping em todos os outros endereços IP net1 dos pods de teste.

Execute o comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 para fazer ping de testpod1 para testpod1.

Observe que o ping tem 4 packets transmitted, 4 received, 0% packet loss. Então o ping é bem sucedido.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

Execute o comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 para fazer ping de testpod1 para testpod2.

Observe que o ping tem 4 packets transmitted, 4 received, 0% packet loss. Então o ping é bem sucedido.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

Execute o comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 para fazer ping de testpod1 para testpod3.

Observe que o ping tem 4 packets transmitted, 4 received, 0% packet loss. Então o ping é bem sucedido.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

Execute o comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 para fazer ping de testpod1 para testpod4.

Observe que o ping tem 4 packets transmitted, 4 received, 0% packet loss. Então o ping é bem sucedido.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

Observação: Não incluímos todas as outras saídas de ping para todos os outros pods de teste, mas você tem a ideia.

A imagem a seguir mostra uma visão geral do que configuramos até agora.

Tarefa 9: (Opcional) Implantar Pods com Várias Interfaces

Até agora, só preparamos uma VNIC (que suporta SR-IOV) e movemos essa VNIC para um pod. Fizemos isso por quatro pods de teste diferentes.

E se quisermos adicionar ou mover mais VNICs para um pod específico? Você deve repetir estas etapas:

Criar uma nova sub-rede do OCI.
Crie uma nova VNIC e designe o endereço IP.
Crie uma nova NetworkAttachmentDefinitions.
Atualize o arquivo YAML do pod de teste adicionando novas anotações.

Nesta tarefa, você encontrará um exemplo em que criaremos uma sub-rede adicional, uma VNIC, designaremos o endereço IP, a NetworkAttachmentDefinition e adicionaremos isso ao arquivo YAML de criação de pod para testpod1.

Esta é a NetworkAttachmentDefinition para uma nova interface ens6 com um endereço IP 10.0.4.29/27 na rede 10.0.4.0/27.

Observe que essa é outra NetworkAttachmentDefinition que tínhamos antes para a interface ens5 com um endereço IP 10.0.3.30/27 na rede 10.0.3.0/27.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

Este é o arquivo YAML (atualizado) para testpod1.

Observe a linha adicional no annotations em que a nova NetworkAttachmentDefinition; sriov-vnic-2-new é referenciada.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Tarefa 10: Remover Todas as Implantações de Pod e `NetworkAttachmentDefinitions`

Se quiser recomeçar ou limpar os contêineres com o NetworkAttachmentDefinitions, siga as etapas:

Obtenha todos os pods usando o comando kubectl get pod.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

Exclua os pods de teste usando os comandos a seguir.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

Obtenha todos os NetworkAttachmentDefinitions usando o comando kubectl get network-attachment-definitions.k8s.cni.cncf.io.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

Exclua o NetworkAttachmentDefinitions com os comandos a seguir.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

Configurar interfaces SR-IOV para pods usando o Multus para nós baseados em VM do Oracle Container Engine for Kubernetes

Confirmações

Autor - Iwan Hoogendoorn (Especialista em Rede da OCI)

Mais Recursos de Aprendizado

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28060-02

Implantar Aplicativos de Contêiner de Interfaces de Rede Ativadas por SR-IOV no OKE Usando o Plug-in CNI Multus

Introdução

Objetivos

Tarefa 1: Implantar o OKE com um Bastion, um Operador, Três Nós de Trabalho de VM e o Plug-in Flannel CNI

Tarefa 2: Ativar a Rede SR-IOV (Assistida por Hardware) em Cada Nó de Trabalho

Tarefa 3: Criar uma Nova Sub-rede para as VNICs Ativadas por SR-IOV

Tarefa 3.1: Criar uma Lista de Segurança

Tarefa 3.2: Criar uma Sub-rede

Tarefa 4: Adicionar um Segundo Anexo de VNIC

Tarefa 4.1: Criar um NSG (Network Security Group)

Tarefa 4.2: Adicionar a VNIC

Tarefa 5: Designar um Endereço IP à Nova Segunda VNIC com um Gateway Padrão

Tarefa 5.1: Verificar todos os Nós no Pool de Nós 1 (np1)

Tarefa 5.2: Verificar todos os Nós no Pool de Nós 2 (np2)

Tarefa 6: Instalar um CNI de Meta-Plugin (Multus CNI) no Nó de Trabalho

Tarefa 6.1: Instalar Multus CNI usando o Método de Instalação Fina

Tarefa 6.2: Validar a instalação do Multus

Tarefa 7: Anexar Interfaces de Rede a Pods

Tarefa 7.1: Criar Definição de Anexo de Rede

Tarefa 7.2: Criar Pods com o NetworkDefinitionAttachment Anexado

Tarefa 7.3: Criar Pods com Afinidade de Nó

Tarefa 7.4: Verificar o Endereço IP nos Pods de Teste

Tarefa 7.5: Verificar o Endereço IP nos Nós de Trabalho

Tarefa 8: Executar Testes de Ping entre Vários Pods

Tarefa 9: (Opcional) Implantar Pods com Várias Interfaces

Tarefa 10: Remover Todas as Implantações de Pod e NetworkAttachmentDefinitions

Links Relacionados

Confirmações

Mais Recursos de Aprendizado

Tarefa 5.1: Verificar todos os Nós no Pool de Nós 1 (`np1`)

Tarefa 5.2: Verificar todos os Nós no Pool de Nós 2 (`np2`)

Tarefa 7.2: Criar Pods com o `NetworkDefinitionAttachment` Anexado

Tarefa 10: Remover Todas as Implantações de Pod e `NetworkAttachmentDefinitions`