Este documento descreve como configurar o Google Distributed Cloud para fornecer várias interfaces de rede (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 várias NICs para agrupamentos são suportadas para clusters de utilizadores, clusters híbridos e clusters autónomos. Não é permitido para clusters do tipo 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 gestão e de dados separados, enquanto são executados como contentores.
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. Os clusters podem conter uma combinação de tipos de nós. Quando agrupa máquinas de elevado desempenho num único conjunto de nós, pode adicionar interfaces adicionais ao conjunto de nós para 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 seu cluster com o campo
multipleNetworkInterfacesno recurso personalizado do cluster.Especifique interfaces de rede com recursos personalizados
NetworkAttachmentDefinition.Atribua interfaces de rede a pods com a anotação
k8s.v1.cni.cncf.io/networks.
São fornecidas informações adicionais para ajudar a configurar e usar a funcionalidade de várias NICs da forma mais adequada aos seus requisitos de rede.
Ative a funcionalidade multi-NIC
Ative a funcionalidade de várias NICs para os seus pods adicionando o campo multipleNetworkInterfaces à secção clusterNetwork do recurso personalizado do cluster e definindo-o como true.
...
clusterNetwork:
multipleNetworkInterfaces: true
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
Especifique interfaces de rede
Use NetworkAttachmentDefinitionrecursos personalizados para especificar interfaces de rede adicionais. Os recursos personalizados NetworkAttachmentDefinition correspondem às redes que estão disponíveis para os seus pods. Pode especificar os recursos personalizados na configuração do cluster, conforme mostrado no exemplo seguinte, ou pode criar os recursos personalizados diretamente.NetworkAttachmentDefinition
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: my-cluster
namespace: cluster-my-cluster
spec:
type: user
clusterNetwork:
multipleNetworkInterfaces: true
...
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-1
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "ipvlan",
"master": "enp2342", # defines the node interface that this pod interface would
map to.
"mode": "l2",
"ipam": {
"type": "whereabouts",
"range": "172.120.0.0/24"
}
}'
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-2
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "macvlan",
"mode": "bridge",
"master": "vlan102",
"ipam": {
"type": "static",
"addresses": [
{
"address": "10.10.0.1/24",
"gateway": "10.10.0.254"
}
],
"routes": [
{ "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
]
}
}'
Quando especifica o recurso personalizado NetworkAttachmentDefinition no ficheiro de configuração do cluster, o Google Distributed Cloud usa este nome para controlar o recurso personalizado NetworkAttachmentDefinition após a criação do cluster.
O Google Distributed Cloud trata este recurso personalizado no espaço de nomes do cluster como a fonte de verdade e reconcilia-o com o espaço de nomes default do cluster de destino.
O diagrama seguinte ilustra como o Google Distributed Cloud reconcilia os recursos personalizados do espaço de nomes específico do cluster com o espaço de nomes default.NetworkAttachmentDefinition
Embora seja opcional, recomendamos que especifique
NetworkAttachmentDefinition recursos personalizados desta forma durante a criação do cluster. Os clusters de utilizadores beneficiam mais quando especifica os recursos personalizados durante a criação do cluster, porque pode controlar os recursos personalizados a partir do cluster de administrador.NetworkAttachmentDefinition
Se optar por não especificar NetworkAttachmentDefinitionrecursos personalizados
durante a criação do cluster, pode adicionar NetworkAttachmentDefinitionrecursos
personalizados diretamente a um cluster de destino existente. O Google Distributed Cloud
concilia os NetworkAttachmentDefinitionrecursos personalizados definidos no espaço de nomes do cluster. A conciliação também ocorre após a eliminação. Quando um recurso personalizado é removido de um espaço de nomes do cluster, o Google Distributed Cloud remove o recurso personalizado do cluster de destino.NetworkAttachmentDefinition
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 recurso personalizado NetworkAttachmentDefinition, separados por uma barra (/).
---
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
containers:
...
Substitua o seguinte:
NAMESPACE: o espaço de nomes. Usedefaultpara o espaço de nomes predefinido, que é padrão. Consulte a secção Preocupações de segurança para ver uma exceção.NAD_NAME: o nome do recurso personalizadoNetworkAttachmentDefinition.
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 recursos personalizados NetworkAttachmentDefinition, gke-network-1 e gke-network-2 no espaço de nomes predefinido do cluster de destino.
---
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 NodePool
Use a anotação k8s.v1.cni.cncf.io/nodeSelector para especificar o conjunto de nós para os quais um recurso personalizado NetworkAttachmentDefinition é válido.
O Google Distributed Cloud força a implementação de todos os pods que referenciam este recurso personalizado nesses nós específicos. No exemplo seguinte, o Google Distributed Cloud força a implementação de todos os pods aos quais a interface de rede gke-network-1multinicNP está atribuída ao NodePool.
O Google Distributed Cloud etiqueta um NodePool com a etiqueta baremetal.cluster.gke.io/node-pool em conformidade.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
annotations:
k8s.v1.cni.cncf.io/nodeSelector: baremetal.cluster.gke.io/node-pool=multinicNP
name: gke-network-1
spec:
...
Não tem de usar as etiquetas padrão. Pode criar os seus próprios conjuntos personalizados a partir dos nós do cluster aplicando uma etiqueta personalizada a esses nós.
Use o comando kubectl label nodes para aplicar uma etiqueta personalizada:
kubectl 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 nome da etiqueta.
Depois de etiquetar o nó, aplique a anotação baremetal.cluster.gke.io/label-taint-no-sync nesse nó para impedir que o Google Distributed Cloud reconcilie as etiquetas. Use o comando kubectl get nodes --show-labels para verificar se um nó está etiquetado.
Preocupações de segurança.
Um recurso personalizado oferece 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.NetworkAttachmentDefinition Se um determinado recurso personalizado tiver de ser isolado, pode ser colocado num espaço de nomes não predefinido, onde apenas os pods desse espaço de nomes podem aceder ao mesmo.NetworkAttachmentDefinition Para conciliar os recursos personalizados NetworkAttachmentDefinition especificados no ficheiro de configuração do cluster, estes são sempre colocados no espaço de nomes predefinido.
No diagrama seguinte, os pods do espaço de nomes default não podem 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 recurso personalizado.NetworkAttachmentDefinition
Criação de interface:
ipvlanmacvlanbridgesriov
Plug-ins da Meta:
portmapsbrtuning
Plugins de IPAM:
host-localstaticwhereabouts
Configuração do trajeto
Um pod com um ou mais NetworkAttachmentDefinitionrecursos personalizados atribuídos tem várias interfaces de rede. Por predefinição, a tabela de encaminhamento nesta situação é expandida com as interfaces adicionais disponíveis localmente dos recursos personalizados atribuídos apenas.NetworkAttachmentDefinition O gateway predefinido continua configurado para usar a interface principal/predefinida do pod, eth0.
Pode modificar este comportamento através dos seguintes plug-ins CNI:
sbrstaticwhereabouts
Por exemplo, pode querer que todo o tráfego passe pelo gateway predefinido, a interface predefinida. No entanto, algum tráfego específico passa 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 recurso personalizado NetworkAttachmentDefinition para o respetivo IP de origem, sbr os pacotes são encaminhados para a tabela de encaminhamento adicional que configurou. A tabela de sbrencaminhamentoNetworkAttachmentDefinition estabelece a interface do recurso personalizado NetworkAttachmentDefinition como o gateway predefinido. O IP do gateway predefinido nessa tabela é controlado com o campo gateway nos plug-ins whereabouts ou static. Forneça o plugin sbr 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 uma rota 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 recurso personalizado 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 de podcasts
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 os registos do Whereabouts e do Multus nas seguintes localizações:
/var/log/whereabouts.log/var/log/multus.log
Reveja as interfaces de agrupamentos
Use o comando kubectl exec para verificar as interfaces do pod. Assim que os recursos personalizados
NetworkAttachmentDefinition forem aplicados com êxito, as interfaces do pod
apresentam o seguinte resultado:
$ 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