Este documento descreve como configurar o Google Distributed Cloud (apenas software) para o VMware de modo a fornecer várias interfaces de rede, ou multi-NIC, para os seus pods. A funcionalidade de várias NICs para pods pode ajudar a separar o tráfego do plano de controlo do tráfego do plano de dados, criando isolamento entre planos. As interfaces de rede adicionais também ativam a capacidade de multicast para os seus pods. As placas de rede múltiplas para pods são suportadas para clusters de utilizadores, mas não são permitidas para clusters de administrador.
Esta página destina-se a especialistas de redes que instalam, configuram e oferecem apoio técnico para equipamento de rede. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE. Google Cloud
O isolamento do plano de rede é importante para os sistemas que usam virtualizações de funções de rede (NFVs), como redes definidas por software numa rede de área alargada (SD-WAN), um agente de segurança de acesso à nuvem (CASB) e firewalls de nova geração (NG-FWs). Estes tipos de NFVs baseiam-se no acesso a várias interfaces para manter os planos de controlo e de dados separados.
A configuração de várias interfaces de rede suporta a associação de interfaces de rede a conjuntos de nós, o que pode oferecer vantagens de desempenho. Por exemplo, um cluster pode conter uma combinação de tipos de nós. Quando agrupa máquinas de elevado desempenho num único conjunto de nós, pode criar interfaces adicionais para o conjunto de nós de modo a melhorar o fluxo de tráfego.
Configure várias interfaces de rede
Geralmente, existem três passos para configurar várias interfaces de rede para os seus pods:
Ative a funcionalidade multi-NIC para o cluster de utilizadores através dos campos
multipleNetworkInterfaceseenableDataplaneV2no ficheiro de configuração do cluster.Especifique interfaces de rede com a secção
additionalNodeInterfacesno ficheiro de configuração do cluster e crie um ou mais recursos personalizadosNetworkAttachmentDefinition.Atribua interfaces de rede a pods com a anotação
k8s.v1.cni.cncf.io/networks.
Ative a funcionalidade multi-NIC
Ative a funcionalidade de várias NICs para os seus pods definindo os campos multipleNetworkInterfaces e enableDataplaneV2 no ficheiro de configuração do cluster de utilizadores como true.
apiVersion: v1 multipleNetworkInterfaces: true enableDataplaneV2: true ...
Especifique interfaces de rede
No ficheiro de configuração do cluster, especifique interfaces de rede de nós adicionais na secção additionalNodeInterfaces.
Por exemplo, segue-se uma parte de um ficheiro de configuração de cluster de utilizadores que mostra uma interface de rede de nós adicional:
apiVersion: v1
multipleNetworkInterfaces: true
enableDataplaneV2: true
network:
serviceCIDR: "10.96.0.0/20"
podCIDR: "192.168.0.0/16"
vCenter:
networkName: network-private310
...
# New multiple network configs
additionalNodeInterfaces:
- networkName: "gke-network-1"
ipBlockFilePath: "my-block-yaml"
type: static
Depois de criar um cluster com a configuração anterior, tem de criar um ou mais recursos personalizados NetworkAttachmentDefinition (NAD) no cluster de utilizadores onde especifica interfaces de rede adicionais. Os NetworkAttachmentDefinitions correspondem às redes disponíveis para os seus Pods. O exemplo seguinte mostra um manifesto para um NetworkAttachmentDefinition:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-1
namespace: default
spec:
config: '{
"cniVersion":"0.3.0",
"type": "ipvlan",
"master": "ens224", # defines the node interface that this Pod interface would map to
"mode": "l2",
"ipam": {
"type": "whereabouts",
"range": "172.16.0.0/24"
}
}'
Guarde o manifesto como um ficheiro YAML, por exemplo, my-nad.yaml, e crie o NetworkAttachmentDefinition:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f my-nad.yaml
Atribua interfaces de rede a um pod
Use a anotação k8s.v1.cni.cncf.io/networks para atribuir uma ou mais interfaces de rede a um pod. Cada interface de rede é especificada com um espaço de nomes e o nome de um NetworkAttachmentDefinition, separados por uma barra (/). Use uma lista separada por vírgulas para especificar várias interfaces de rede.
No exemplo seguinte, são atribuídas duas interfaces de rede ao samplepod Pod. As interfaces de rede são especificadas pelos nomes de dois NetworkAttachmentDefinitions, gke-network-1 e gke-network-2, que foram criados no espaço de nomes default.
---
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2
spec:
containers:
...
Restrinja as interfaces de rede a um conjunto de nós
Se não quiser que um NetworkAttachmentDefinition seja aplicável a um cluster inteiro, pode limitar a respetiva funcionalidade a um conjunto de nós.
Pode agrupar nós de cluster usando a etiqueta padrão atribuída ao nó ou a sua própria etiqueta personalizada. Em seguida, pode especificar a etiqueta do nó no manifesto NetworkAttachmentDefinition através da anotação k8s.v1.cni.cncf.io/nodeSelector. O Google Distributed Cloud força a implementação de todos os pods que referenciam este recurso personalizado nos nós que têm esta etiqueta.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
annotations:
k8s.v1.cni.cncf.io/nodeSelector: LABEL_KEY=LABEL_VALUE
name: gke-network-1
spec:
...
O exemplo seguinte mostra a etiqueta my-label=multinicNP indicada no NetworkAttachmentDefinition e força a implementação de todos os pods aos quais a rede gke-network-1 está atribuída aos nós que têm esta etiqueta.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
annotations:
k8s.v1.cni.cncf.io/nodeSelector: my-label=multinicNP
name: gke-network-1
spec:
...
Para aplicar uma etiqueta personalizada a um nó, use o comando kubectl label nodes:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
Substitua o seguinte:
NODE_NAME: o nome do nó que está a etiquetar.LABEL_KEY: a chave a usar para a sua etiqueta.LABEL_VALUE: o valor da etiqueta.
Neste exemplo, o nó my-node recebe a etiqueta environment=production:
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes my-node environment=production
Preocupações de segurança.
Um NetworkAttachmentDefinition fornece acesso total a uma rede, pelo que os administradores do cluster têm de ter cuidado ao conceder acesso de criação, atualização ou eliminação a outros utilizadores. Se um determinado NetworkAttachmentDefinition tiver de ser isolado, pode especificar um espaço de nomes não predefinido quando o criar, em que apenas os pods desse espaço de nomes podem aceder ao mesmo.
No diagrama seguinte, os pods do espaço de nomes default não conseguem aceder à interface de rede no espaço de nomes privileged.
Plug-ins CNI suportados
Esta secção apresenta uma lista dos plug-ins CNI suportados pela funcionalidade de várias NICs para o Google Distributed Cloud. Use apenas os seguintes plug-ins quando especificar um NetworkAttachmentDefinition.
Criação de interface:
ipvlanmacvlanbridge
Plug-ins da Meta:
portmapsbrtuning
Plugins de IPAM:
host-localstaticwhereabouts
Configuração do trajeto
Um pod com um ou mais NetworkAttachmentDefinitions atribuídos tem várias interfaces de rede. Por predefinição, a tabela de encaminhamento do pod nesta situação é expandida com as interfaces adicionais disponíveis localmente apenas a partir do NetworkAttachmentDefinitions atribuído. Os pacotes destinados ao gateway predefinido continuam configurados para usar a interface predefinida do Pod, eth0.
Pode modificar este comportamento através dos seguintes plug-ins CNI:
sbrstaticwhereabouts
Por exemplo, pode querer que a maioria do tráfego passe pelo gateway predefinido, o que significa que o tráfego passa pela interface de rede predefinida. No entanto, quer que algum tráfego específico passe por uma das interfaces não predefinidas. Pode ser difícil desambiguar o tráfego com base no IP de destino (encaminhamento normal), porque o mesmo ponto final está disponível nos dois tipos de interface. Neste caso, o encaminhamento baseado na origem (SBR) pode ajudar.
Plugin SBR
O plug-in sbr dá à aplicação o controlo sobre as decisões de encaminhamento. A aplicação controla o que é usado como o endereço IP de origem da ligação que estabelece. Quando a aplicação opta por usar o endereço IP do NetworkAttachmentDefinition como IP de origem, os pacotes são encaminhados para a tabela de encaminhamento adicional que o sbr configurou. A tabela de encaminhamento do sbr envia tráfego através do seu próprio gateway predefinido, que passa pela interface do NetworkAttachmentDefinition. O IP do gateway predefinido nessa tabela é controlado com o campo gateway nos plug-ins whereabouts ou static. O plugin sbr é executado como um plugin encadeado. Para mais informações sobre o plug-in sbr, incluindo informações de utilização, consulte o artigo Plug-in de encaminhamento baseado na origem.
O exemplo seguinte mostra "gateway":"21.0.111.254" definido em whereabouts e sbr definido como plug-in encadeado após ipvlan:
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
Plug-ins estáticos e de localização
O plug-in whereabouts é basicamente uma extensão do plug-in static e estes dois partilham a configuração de encaminhamento. Para ver um exemplo de configuração, consulte o
plug-in de gestão de endereços IP estáticos.
Pode definir um gateway e um trajeto para adicionar à tabela de encaminhamento do pod. No entanto, não pode modificar o gateway predefinido do Pod desta forma.
O exemplo seguinte mostra a adição de "routes": [{ "dst": "172.31.0.0/16" }] no elemento NetworkAttachmentDefinition:
# ip route
default via 192.168.0.64 dev eth0 mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link
Exemplos de configuração
Esta secção ilustra algumas das configurações de rede comuns suportadas pela funcionalidade de várias NICs.
Anexo de rede único usado por vários pods:
Vários anexos de rede usados por um único agrupamento:
Vários anexos de rede que apontam para a mesma interface usada por um único agrupamento:
O mesmo anexo de rede é usado várias vezes por um único agrupamento:
Resolver problemas
Se as interfaces de rede adicionais estiverem configuradas incorretamente, os pods aos quais estão atribuídas não são iniciados. Esta secção realça como encontrar informações para resolver problemas com a funcionalidade de várias NICs.
Verifique os eventos do Pod
O Multus comunica falhas através de eventos de pods do Kubernetes. Use o seguinte comando kubectl describe para ver eventos de um determinado Pod:
kubectl describe pod POD_NAME
Verifique os registos
Para cada nó, pode encontrar registos de Whereabouts e Multus nas seguintes localizações:
/var/log/whereabouts.log/var/log/multus.log
Reveja as interfaces do Pod
Use o comando kubectl exec para verificar as interfaces do pod. Depois de aplicar os NetworkAttachmentDefinitions com êxito, as interfaces do pod têm o seguinte aspeto:
user@node1:~$ kubectl exec samplepod-5c6df74f66-5jgxs -- 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
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
inet 21.0.103.112/21 scope global net1
valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.2.191/32 scope global eth0
valid_lft forever preferred_lft forever
Obtenha o estado do agrupamento
Use o comando kubectl get para obter o estado da rede de um determinado pod:
kubectl get pods POD_NAME -oyaml
Segue-se um exemplo de saída que mostra o estado de um Pod com várias redes:
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/network-status: |-
[{
"name": "",
"interface": "eth0",
"ips": [
"192.168.1.88"
],
"mac": "36:0e:29:e7:42:ad",
"default": true,
"dns": {}
},{
"name": "default/gke-network-1",
"interface": "net1",
"ips": [
"21.0.111.1"
],
"mac": "00:50:56:82:a7:ab",
"dns": {}
}]
k8s.v1.cni.cncf.io/networks: gke-network-1