Habilite pods com várias interfaces de rede
O Cloud-Native Contrail® Networking™ (CN2) oferece suporte a várias interfaces de rede para um pod dentro do Kubernetes.
O Contrail Networking nativo da nuvem oferece suporte nativo a várias interfaces de rede para um pod.
Você também pode habilitar várias interfaces de rede no Cloud-Native Contrail Networking usando Multus. Multus é um plug-in de interface de rede de contêiner (CNI) para Kubernetes desenvolvido pelo Kubernetes Network Plumbing Working Group. O Contrail nativo da nuvem pode interoperar com o Multus para oferecer suporte a várias interfaces fornecidas por várias CNIs em um pod.
Este documento fornece as etapas para permitir várias interfaces para um pod em ambientes que usam o Release 22.1 ou posterior em ambientes orquestrados por Kubernetes. Ele inclui informações sobre quando e como habilitar várias interfaces de rede.
Múltiplas interfaces de rede em benefícios do Contrail nativo da nuvem
O suporte para várias interfaces de rede é útil ou necessário em muitos ambientes de rede de nuvem. Alguns exemplos comuns:
- Os pods exigem rotineiramente uma interface de dados para transportar tráfego de dados e uma interface separada para o tráfego de gerenciamento.
-
As funções de rede virtualizadas (VNFs) normalmente precisam de três interfaces — uma esquerda, uma direita e uma interface de gerenciamento — para fornecer funções de rede. Muitas vezes, uma VNF não pode fornecer sua função com uma única interface de rede.
-
Topologias de rede de nuvem precisam rotineiramente suportar duas ou mais interfaces de rede para isolar redes de gerenciamento de redes de locatários.
- Em ambientes personalizados ou de rede de nuvem de alta escala, você muitas vezes deve usar um produto de rede de nuvem que ofereça suporte a várias interfaces de rede para atender a uma variedade de requisitos específicos do ambiente.
Um pod em um cluster Kubernetes usando a CNI padrão tem uma única interface de rede para enviar e receber tráfego de rede. O Contrail Networking nativo da nuvem oferece suporte nativo para várias interfaces de rede. O Contrail nativo da nuvem também oferece suporte à integração do Multus, permitindo que ambientes que usam o Contrail nativo de nuvem para redes ofereçam suporte a várias interfaces de rede usando Multus.
Múltiplas interfaces de rede na visão geral do Contrail nativo da nuvem
Você pode habilitar várias interfaces de rede no Cloud-Native Contrail usando Multus e sem usar Multus. Multus é um plug-in de interface de rede de contêiner (CNI) para Kubernetes que permite suporte a várias interfaces de rede em um pod, bem como multihoming entre pods. A Multus pode simultaneamente oferecer suporte a interfaces de várias CNIs de delegados, permitindo a criação de ambientes de rede de nuvem interconectados usando CNIs fornecidos por diferentes fornecedores, incluindo o Cloud-Native Contrail. A Multus é muitas vezes chamada de "meta-plugin" por causa desse suporte a vários fornecedores.
Você deve habilitar várias interfaces de rede usando o suporte nativo do Cloud-Native Contrail Networking para várias interfaces pelos seguintes motivos;
-
Você não quer a sobrecarga de habilitar e manter o Multus em seu ambiente.
-
Você está usando o Contrail Networking nativo da nuvem como sua única interface de rede de contêiner (CNI).
-
Você não quer criar e manter objetos de definição de anexo de rede (NAD) para oferecer suporte a várias interfaces de rede em seu ambiente.
Você deve criar um objeto NAD para habilitar várias interfaces de rede com o Multus. Você não precisa configurar um objeto NAD para habilitar várias interfaces de rede se você não estiver usando Multus.
Cada objeto de NAD, notadamente, cria uma rede virtual e uma sub-rede que precisam ser monitoradas e mantidas.
Você deve habilitar várias interfaces de rede usando o Multus pelos seguintes motivos:
-
Você está usando o Cloud-Native Contrail em um ambiente que já está usando o Multus. Multus é especialmente comum em ambientes que usam a orquestração Openshift.
-
Você precisa dos recursos "meta-plugin" fornecidos pelo Multus. Você está usando o Cloud-Native Contrail em um ambiente onde um pod está usando várias interfaces e as múltiplas interfaces estão sendo gerenciadas pelo Contrail nativo da nuvem e outras CNIs.
-
Você precisa de alguns dos outros recursos do Multus em seu ambiente.
Integração do Contrail nativo da nuvem com visão geral do Multus
Um Contrail vRouter tem reconhecimento nativo de Multus. Nenhuma configuração específica do Contrail Networking nativo da nuvem é necessária para permitir a interoperabilidade do Multus com o Contrail nativo da nuvem.
Esta lista resume as opções de interoperabilidade do Contrail nativo da nuvem com o Multus.
-
O Contrail nativo de nuvem é compatível com a versão 0.3.1 da Multus CNI.
-
O Contrail nativo da nuvem é suportado como um CNI primário com o Multus. Não é suportado com Multus como a CNI secundária.
-
O Contrail nativo da nuvem é apoiado como um delegado CNI para Multus. O Contrail nativo de nuvem deve funcionar como a CNI padrão ou como um dos CNIs delegados quando estiver interoperando em um cluster com Multus.
-
O Contrail nativo de nuvem oferece suporte à interoperabilidade com o Multus quando estiver no modo kernel do vRouter ou no modo DPDK.
Multus é um plug-in de terceiros. Você habilita e configura o Multus dentro do Kubernetes, mas totalmente fora do Contrail nativo da nuvem. Para habilitar o Multus, você pode aplicar os arquivos multus-daemonset.yml fornecidos pelo Kubernetes Network Plumbing Working Group. O Kubernetes Network Plumbing Working Group é o grupo de código aberto que desenvolve o Multus.
Para obter informações detalhadas sobre a Multus, consulte o Guia de uso do CNI da Multus do grupo de trabalho de encanamento de rede Kubernetes.
Crie um objeto de definição de anexo de rede
Você não precisa criar um objeto NetworkAttachmentDefinition (NAD) para habilitar várias interfaces usando o suporte nativo de várias interfaces no Cloud-Native Contrail Networking. Você pode pular esta seção se não estiver usando o Multus para habilitar várias interfaces de rede em seu ambiente. Se você não estiver usando objetos NAD, mas precisar criar uma rede virtual, consulte https://www.juniper.net/documentation/us/en/software/cn-cloud-native22/cn-cloud-native-feature-guide/cn-cloud-native-network-feature/topics/concept/Contrail_Network_Policy_Implementation_in_CN2.html.
Esta seção ilustra como criar um objeto NAD usando um arquivo YAML. Você configura o Cloud-Native Contrail no objeto NAD usando o juniper.net/networks Anotação. Fornecemos um exemplo representativo do arquivo YAML que cria o objeto NAD e uma tabela de descrições de campo mais tarde nesta seção.Certifique-se de incluir a juniper.net/networks anotação ao criar o objeto NetworkAttachmentDefinition . Se você definir o arquivo YAML para criar o objeto NetworkAttachmentDefinition sem usar a juniper.net/networks anotação, o objeto NetworkAttachmentDefinition é tratado como um objeto de terceiros. Nenhum objeto relacionado ao Contrail será criado na rede, incluindo o objeto VirtualNetwork e o objeto Subnet .
Você cria o objeto NetworkAttachmentDefinition em um ambiente Kubernetes usando o controlador de definição de anexo de rede (NAD). O controlador NAD é executado em kube-manager e cria um objeto VirtualNetwork ou atualiza um objeto VirtualNetwork existente quando um NetworkAttachmentDefinition é criado com sucesso. O controlador NAD é habilitado por padrão, mas você pode desabitá-lo; ver desativar o controlador de definição de anexo de rede.
A seguir está um exemplo representante do arquivo YAML usado para criar um objeto NetworkAttachmentDefinition :
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: networkname-1
namespace: nm1
annotations:
juniper.net/networks: '{
"ipamV4Subnet": "172.16.10.0/24",
"ipamV6Subnet": "2001:db8::/64",
"routeTargetList": ["target:23:4561"],
"importRouteTargetList": ["target:10.2.2.2:561"],
"exportRouteTargetList": ["target:10.1.1.1:561"],
"fabricSNAT": true
}'
spec:
config: '{
"cniVersion": "0.3.1",
"name": "juniper-network",
"type": "contrail-k8s-cni"
}'
A tabela NetworkAttachmentDefinition Object Fields oferece detalhes de uso para as variáveis no arquivo de objetos NetworkAttachmentDefinition .
| Uso variável | |
|---|---|
| ipamV4Subnet | (Opcional) Especifica o endereço de sub-rede IPv4 para a rede virtual. |
| ipamV6Subnet | (Opcional) Especifica o endereço de sub-rede IPv6 para a rede virtual. |
| routeTargetList | (Opcional) Oferece uma lista de metas de rota que são usadas como rotas de importação e exportação. |
| Lista de produtos de importação | (Opcional) Oferece uma lista de alvos de rota que são usados como rotas de importação. |
| ExportRouteTargetList | (Opcional) Oferece uma lista de alvos de rota que são usados como rotas de exportação. |
| fabricSNAT | (Opcional) Especifica se você gostaria de alternar a conectividade com a rede underlay usando os recursos de mapeamento de porta fornecidos pelo NAT de origem da malha. Defina este parâmetro como verdadeiro ou falso. Ela é definida como falsa por padrão. |
Você deve observar as seguintes atividades de rede relacionadas ao objeto NetworkAttachmentDefinition :
- O controlador de definição de anexo de rede funciona no kube-manager e lida com o processamento de todos os objetos de definição de anexo de rede.
- Você pode monitorar as atualizações do controlador de definição de anexo de rede em juniper.net/network-status.
- As atualizações de IPAM não podem ser permitidas ao objeto de definição de anexo de rede.
O objeto de definição de anexo de rede cria uma rede virtual. A tabela De definição de anexo de rede Impacto objeto na tabela de redes virtuais fornece uma visão geral de como eventos relacionados à definição de anexo de rede afetam as redes virtuais.
| Se você definir | , então |
|---|---|
| Um namespace para um objeto de definição de anexo de rede em uma única topologia de cluster, |
Uma Rede Virtual é criada no mesmo namespace que a definição de anexo de rede. Esta Rede Virtual terá o mesmo nome do objeto de definição de anexo de rede. O objeto NAD é nomeado usando o nome: campo nos metadados: hierarquia. |
| Um namespace para um objeto de definição de anexo de rede em uma topologia multi cluster, |
O namespace da VirtualNetwork é cluster-name-ns.. |
| Se um namespace não for definido para um objeto de definição de anexo de rede em uma topologia multi cluster, |
O namespace da VirtualNetwork é padrão de nome de cluster. |
| Se você excluir um recurso de definição de anexo de rede, |
O objeto VirtualNetwork associado também é excluído. |
| Se você excluir uma rede virtual que foi criada pelo recurso de definição de anexo de rede, |
O controlador de definição de anexo de rede concilia o problema e recria a rede virtual. |
Configure um pod para usar várias interfaces
Você configura várias interfaces no objeto pod. Se você estiver usando Multus, você também deve configurar o objeto NAD conforme descrito em Criar um objeto de definição de anexo de rede.
No exemplo a seguir, você cria duas interfaces para tráfego de rede no pod juniper-pod-1 ; toque 1 e tap2.
apiVersion: v1
kind: Pod
metadata:
name: juniper-pod-1
namespace: juniper-ns
annotations:
k8s.v1.cni.cncf.io/networks: |-
[
{
"name":"juniper-network1",
"namespace":"juniper-ns",
"cni-args":null,
"ips":["172.16.20.42"],
"mac":"de:ad:00:00:be:ef",
"interface":"tap1"
},
[
{
"name":"juniper-network2",
"namespace":"juniper-ns",
"cni-args":null,
"ips":["172.16.21.42"],
"mac":"de:ad:00:00:be:ee",
"interface":"tap2"
}
]
Desativar o controlador de definição de anexo de rede
O controlador de definição de anexo de rede faz parte do objeto kube-manager. Você habilita e desativa este controlador usando o enableNad: variável dentro do arquivo YAML que define o objeto kubemanager . O controlador de definição de anexo de rede é habilitado por padrão.
Você pode querer desabilitar o controlador de definição de anexo de rede para evitar a aplicação de objetos NetworkAttachmentDefinion .
No exemplo a seguir, o controlador de definição de anexo de rede é desativado:
kind: Kubemanager
metadata:
name: remote-cluster
namespace: contrail
spec:
common:
nodeSelector:
node-role.kubernetes.io/master: ""
enableNad: false