用户使用自定义 CNI 插件方法
背景
为了更好地满足用户对于高度定制化网络配置的需求，cce-network 不仅允许用户使用默认的 CNI 插件，更提供了一种机制，使用户能够自定义 CNI 插件。这种自定义能力极大地增强了网络配置的灵活性，从而使得用户可以根据自己的具体需求，进行详细的网络设计和配置。
自定义 CNI 插件的方法包括了对官方支持的插件的选择配置，以及通过修改配置文件直接部署用户自定义的插件。
本文描述了如何使用和配置 CCE CNI，从而实现用户自定义 CNI 插件的配置。
V2版本使用说明
前提条件：
- 已安装 cce-network-v2 组件，版本不小于 2.10.0。
- 确保 CNI 插件使用的规范版本 >= 0.4.0。
1 确认容器网络模式
执行 kubectl get cm -n kube-system cce-network-v2-config -o yaml，查看 ipam 字段。
vpc-route开头表示基于 VPC 路由的网络方案vpc-eni, 开头表示基于弹性网卡的网络方案
2 自定义 CCE 官方支持的插件
下面提供 CCE 官方支持的插件列表，用户可以通过安装 cce-network-v2 时通过 ccedConfig.ext-cni-plugins 配置文件进行选择。
| 插件名称 | 提供者 | 插件描述 | 插件版本 |
|---|---|---|---|
| portmap | 社区 | 社区的 CNI 插件，支持Pod 上配置端口直通能力。当开启 ebpf 加速时，该插件会自动失效。 | v1.0.0 及以上版本 |
| cilium-cni | CCE | Cilium CNI 插件，支持网络策略、service加速等。 | v1.12.5-baidu 及以上版本 |
| endpoint-probe | CCE | CCE 提供的 CNI 插件，用于支持 Pod Qos 等能力。 | v2.9.0 及以上版本 |
| cptp | CCE | CCE 提供的默认 CNI 插件，支持Pod基础网络通信能力。 | v1.0.0 及以上版本 |
| exclusive-device | CCE | CCE 提供的 CNI 插件，支持Pod独占网卡能力。 | v2.6.0 及以上版本 |
| sbr-eip | CCE | CCE 提供的 CNI 插件，支持Pod 直通 EIP 功能。 | v2.6.0 及以上版本 |
例如需要开启 portmap 插件，则可以通过如下配置文件进行重新部署。
- 修改cni插件模板
1kubectl edit cm cce-network-v2-config -n kube-system -o yaml
2
3apiVersion: v1
4data:
5 cced: |
6 ……
7 ext-cni-plugins:
8 - portmap
9 - endpoint-probe
10 ……- 清理cni配置文件
需要在修改后重启
daemonset cce-network-agent
1kubectl rollout restart daemonset -n kube-system cce-network-agent- 验证
进入任意机器，执行 cat /etc/cni/net.d/00-cce-cni.conflist 验证是否包含用户自定义的cni配置文件。
1cat /etc/cni/net.d/00-cce-cni.conflist
2{
3 "cniVersion": "0.4.0",
4 "name": "generic-veth",
5 "ipam": {},
6 "dns": {},
7 "plugins": [
8 {
9 "ipam": {
10 "type": "cipam"
11 },
12 "mtu": 1500,
13 "type": "cptp"
14 },
15 {
16 "capabilities": {
17 "portMappings": true
18 },
19 "externalSetMarkChain": "KUBE-MARK-MASQ",
20 "type": "portmap"
21 },
22 {
23 "type": "endpoint-probe"
24 }
25 ]3 自定义 CNI 插件
CCE 也支持保留用户自定义的 CNI 插件，用户可以通过修改主机配置文件 /etc/cni/net.d/00-cce-cni.conflist 自行进行部署CNI 配置文件。CCE 在更新时，会使用用户自定义的 CNI 插件。
1{
2 "name":"generic-veth",
3 "cniVersion":"0.4.0",
4 "plugins":[
5 {
6 "type":"cptp",
7 "ipam":{
8 "type":"cipam",
9 },
10 "mtu": 1500
11 }
12 ,{
13 "type": "endpoint-probe"
14 },
15 {
16 "type": "user-cni"
17 }
18 ]
19}CCE 容器网络在启动时会自动读取该配置文件，如果发现了用户的自定义 CNI 插件，则在更新 CNI 配置时，会把用户自定义 CNI 插件自动插入到插件链的尾端。
V1 版本使用说明
1 确认容器网络模式
执行 kubectl get cm -n kube-system cce-cni-node-agent -o yaml，查看 cniMode 字段。
vpc-route-开头表示基于 VPC 实例路由的网络方案vpc-secondary-ip-, 开头表示基于弹性网卡的网络方案
2 修改 CNI 配置文件模板
根据步骤 1 中获取的网络模式，执行 kubectl edit cm -n kube-system cce-cni-config-template, 修改对应模式的 CNI 配置文模板。
手动编辑 plugins 列表, 在最后加上 sysctl 的配置文件，等待 1 分钟后所有节点的 CNI 配置将会更新。
修改完的样例如下:
1 cce-cni-secondary-ip-veth: |
2 {
3 "name":"{{ .NetworkName }}",
4 "cniVersion":"0.3.1",
5 "plugins":[
6 {
7 "type":"ptp",
8 "enableARPProxy":true,
9 "vethPrefix":"veth",
10 "mtu": {{ .VethMTU }},
11 "ipam":{
12 "type":"eni-ipam",
13 "endpoint":"{{ .IPAMEndPoint }}",
14 "instanceType":"{{ .InstanceType }}",
15 "deleteENIScopeLinkRoute":true
16 }
17 },
18 {
19 "type":"sysctl",
20 "kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig"
21 }
22 ]
23 }3 集群粒度的配置（可选）
在步骤 2 中的配置里，可以继续添加 sysctl 字段，指明需要配置的参数。
如下的配置生效后，集群内所有新建的容器都会将 /proc/sys/net/core/somaxconn 设置为 500。
1{
2 "type":"sysctl",
3 "kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig",
4 "sysctl":{
5 "net.core.somaxconn":"8192"
6 }
7}4 应用粒度的配置（可选）
在完成步骤 2 后，用户可以通过指定 Pod 的 annotations，传递 sysctl 参数的配置。
采用如下的 yaml 的创建的 nginx 容器，将会设置 /proc/sys/net/core/somaxconn 为 8192 以及 /proc/sys/net/ipv4/tcp_tw_reuse 为 1。
1kind: Deployment
2apiVersion: apps/v1
3metadata:
4 name: nginx-example
5spec:
6 replicas: 1
7 selector:
8 matchLabels:
9 app: nginx-example
10 template:
11 metadata:
12 labels:
13 app: nginx-example
14 annotations:
15 net.sysctl.cce.io/net.core.somaxconn: "8192"
16 net.sysctl.cce.io/net.ipv4.tcp_tw_reuse: "1"
17 spec:
18 containers:
19 - name: nginx-example
20 image: nginx:alpine
21 imagePullPolicy: IfNotPresent注意事项
用户自定义的 CNI 插件，必须满足以下条件：
- 确保 CNI 插件的 type 字段不为空且不要与已有插件重复；
- 确保 CNI 插件的可执行程序/opt/cni/bin/{user-cni} 存在且可执行，否则 kubelet 无法正常创建 Pod；
- 确保 CNI 插件完整的遵循了 CNI 规范，确保 CNI DEL 操作可以正常执行。防止 CNI 插件异常导致 Pod 无法删除重建，持续在故障中无法恢复。
- 确保 CNI 配置是一个合法的 JSON 格式文件
- 不同版本内核中 netns 可配置的 sysctl 参数不同，请小心配置否则容器可能无法启动