NESTA PÁGINA
Visão geral dos casos de uso e configuração do JCNR
RESUMO Leia este capítulo para revisar exemplos de configuração para vários casos de uso de roteador nativo de nuvem da Juniper quando implantado no modo de interface de rede de contêiner (CNI).
O roteador nativo de nuvem da Juniper pode ser implantado como um switch virtual ou um roteador de trânsito, seja como uma função de rede de contêiner puro (CNF) ou como uma interface de rede de contêiner (CNI). No modo CNF, não há pods de aplicativo em execução no nó e o roteador só realiza comutação ou encaminhamento de pacotes por meio de várias interfaces no sistema. No modo CNI, os pods de aplicativo que usam interfaces de rede baseadas em software, como veth-pairs ou interfaces baseadas em usuário DPDK vhost, são anexados ao roteador nativo da nuvem. Este capítulo fornece exemplos de configuração para anexar diferentes tipos de interface de carga de trabalho à instância CNI do roteador nativo da nuvem.
Exemplo de configuração
A CNI do JCNR é implantada como uma CNI secundária, juntamente com Multus como uma CNI primária, para criar diferentes tipos de interfaces secundárias para o pod de aplicativo. A Multus usa um arquivo de definição de anexo de rede (NAD) para configurar uma interface secundária para o pod do aplicativo. O NAD especifica como criar uma interface secundária, alocação de endereço IP, instância de rede e muito mais. Um pod pode ter um ou mais NADs, normalmente um por interface de pod. Oconfig: campo no arquivo NAD define a configuração da CNI do JCNR. Aqui está um formato genérico do NAD:
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: <vrf-name>
spec:
config: '{
"cniVersion":"0.4.0",
"name": "<vrf-name>",
"plugins": [
{
"type": "jcnr",
"args": {
"key1":"value1",
"key2","value2",
....
},
"ipam": {
"type": "<ipam-type>",
....
},
"kubeConfig":"/etc/kubernetes/kubelet.conf"
}
]
}'
| Descrição da chave | |
|---|---|
| Instancename | O nome da instância de roteamento |
| instânciasPoquétimos | Um de: roteador virtual — para aplicativos não relacionados a VPN vrf — implementações de VPN de camada 3 switch virtual — implementações de Camada 2 |
| Interfacetype | Ou "veth" ou "virtio" |
| vlanId | Uma id vlan válida "1-4095" |
| bridgeVlanId | Uma id vlan válida "1-4095" |
| vlanIdList | Uma lista de comandos separada vlan-id, por exemplo: "1, 5, 7, 10-20" |
| parentInterface | Nome de interface válido conforme deve aparecer no pod. As sub-interfaces/crianças têminterface parental como prefixo seguido de "." Se a interface parental for especificada, a sub interface deve ser explicitamente especificada. |
| vrfTarget | O alvo de rota para a instância de roteamento vrf |
| bridgeDomain | Domínio bridge sob qual interface de pod deve ser anexada na instância do switch virtual. |
| tipo (ipam) | estático — atribui o mesmo IP a todos os pods, para atribuir um IP único por pod definir um NAD exclusivo por pod por interface host local — endereço IP exclusivo por interface de pod no mesmo host. Os endereços IP não são exclusivos em dois nós diferentes descasos — endereço IP exclusivo por pod em todos os nós |
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: vswitch-pod1-bd100
spec:
config: '{
"cniVersion":"0.4.0",
"name": "vswitch-pod1-bd100",
"plugins": [
{
"type": "jcnr",
"args": {
"instanceName": "vswitch",
"instanceType": "virtual-switch",
"interfaceType": "veth",
"bridgeDomain": "bd100",
"bridgeVlanId": "100"
},
"ipam": {
"type": "static",
"addresses":[
{
"address":"99.61.0.2/16",
"gateway":"99.61.0.1"
},
{
"address":"1234::99.61.0.2/120",
"gateway":"1234::99.61.0.1"
}
]
},
"kubeConfig":"/etc/kubernetes/kubelet.conf"
}
]
}'
k8s.v1.cni.cncf.io/networks Anotação. Por exemplo:
apiVersion: v1
kind: Pod
metadata:
name: pod1
annotations:
k8s.v1.cni.cncf.io/networks: vswitch-pod1-bd100
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- kind-worker
containers:
- name: pod1
image: ubuntu:latest
imagePullPolicy: IfNotPresent
securityContext:
privileged: false
env:
- name: KUBERNETES_POD_UID
valueFrom:
fieldRef:
fieldPath: metadata.uid
volumeMounts:
- name: dpdk
mountPath: /dpdk
subPathExpr: $(KUBERNETES_POD_UID)
volumes:
- name: dpdk
hostPath:
path: /var/run/jcnr/containers
/dpdk/dpdk-interfaces.json dentro do contêiner de aplicativos para o aplicativo DPDK consumir. Também é exportado para o pod como uma anotação de pod.
Quando você cria um pod para uso no roteador nativo de nuvem, o componente Kubernetes conhecido como kubelet chama a CNI da Multus para configurar redes e interfaces de pod. Multus lê a seção de anotações do arquivo pod.yaml para consultar o NAD correspondente. Se um NAD aponta como jcnr o plug-in da CNI, Multus chama o JCNR-CNI para configurar a interface do pod. O JCNR-CNI cria a interface conforme especificado no NAD. A JCNR-CNI então gera e empurra uma configuração para o cRPD.
Solucionando problemas
Os pods principais não surgem por várias razões:
-
Imagem não encontrada
-
A CNI falhou em adicionar interfaces
-
A CNI falhou em empurrar a configuração para o cRPD
-
A CNI não invocou as APIs REST do vRouter
-
O NAD é inválido ou indefinido
Os comandos a seguir serão úteis para solucionar problemas de pod:
# Check the Pod status kubectl get pods –A
# Check pod state and CNI logs kubectl describe pod <pod-name>
# Check the pod logs kubectl logs pod <pod-name>
# Check the net-attach-def kubectl get net-attach-def <net-attach-def-name> -o yaml
# Check CNI logs tail –f /var/log/jcnr/jcnr-cni.log
# Check the cRPD config added by CNI (on the cRPD CLI) cli> show configuration groups cni