用户使用自定义 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插件模板
kubectl edit cm cce-network-v2-config -n kube-system -o yaml
apiVersion: v1
data:
cced: |
……
ext-cni-plugins:
- portmap
- endpoint-probe
……
- 清理cni配置文件
需要在修改后重启
daemonset cce-network-agent
kubectl rollout restart daemonset -n kube-system cce-network-agent
- 验证
进入任意机器,执行 cat /etc/cni/net.d/00-cce-cni.conflist
验证是否包含用户自定义的cni配置文件。
cat /etc/cni/net.d/00-cce-cni.conflist
{
"cniVersion": "0.4.0",
"name": "generic-veth",
"ipam": {},
"dns": {},
"plugins": [
{
"ipam": {
"type": "cipam"
},
"mtu": 1500,
"type": "cptp"
},
{
"capabilities": {
"portMappings": true
},
"externalSetMarkChain": "KUBE-MARK-MASQ",
"type": "portmap"
},
{
"type": "endpoint-probe"
}
]
3 自定义 CNI 插件
CCE 也支持保留用户自定义的 CNI 插件,用户可以通过修改主机配置文件 /etc/cni/net.d/00-cce-cni.conflist
自行进行部署CNI 配置文件。CCE 在更新时,会使用用户自定义的 CNI 插件。
{
"name":"generic-veth",
"cniVersion":"0.4.0",
"plugins":[
{
"type":"cptp",
"ipam":{
"type":"cipam",
},
"mtu": 1500
}
,{
"type": "endpoint-probe"
},
{
"type": "user-cni"
}
]
}
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 配置将会更新。
修改完的样例如下:
cce-cni-secondary-ip-veth: |
{
"name":"{{ .NetworkName }}",
"cniVersion":"0.3.1",
"plugins":[
{
"type":"ptp",
"enableARPProxy":true,
"vethPrefix":"veth",
"mtu": {{ .VethMTU }},
"ipam":{
"type":"eni-ipam",
"endpoint":"{{ .IPAMEndPoint }}",
"instanceType":"{{ .InstanceType }}",
"deleteENIScopeLinkRoute":true
}
},
{
"type":"sysctl",
"kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig"
}
]
}
3 集群粒度的配置(可选)
在步骤 2 中的配置里,可以继续添加 sysctl
字段,指明需要配置的参数。
如下的配置生效后,集群内所有新建的容器都会将 /proc/sys/net/core/somaxconn
设置为 500。
{
"type":"sysctl",
"kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig",
"sysctl":{
"net.core.somaxconn":"8192"
}
}
4 应用粒度的配置(可选)
在完成步骤 2 后,用户可以通过指定 Pod 的 annotations,传递 sysctl 参数的配置。
采用如下的 yaml 的创建的 nginx 容器,将会设置 /proc/sys/net/core/somaxconn
为 8192 以及 /proc/sys/net/ipv4/tcp_tw_reuse
为 1。
kind: Deployment
apiVersion: apps/v1
metadata:
name: nginx-example
spec:
replicas: 1
selector:
matchLabels:
app: nginx-example
template:
metadata:
labels:
app: nginx-example
annotations:
net.sysctl.cce.io/net.core.somaxconn: "8192"
net.sysctl.cce.io/net.ipv4.tcp_tw_reuse: "1"
spec:
containers:
- name: nginx-example
image: nginx:alpine
imagePullPolicy: IfNotPresent
注意事项
用户自定义的 CNI 插件,必须满足以下条件:
- 确保 CNI 插件的 type 字段不为空且不要与已有插件重复;
- 确保 CNI 插件的可执行程序/opt/cni/bin/{user-cni} 存在且可执行,否则 kubelet 无法正常创建 Pod;
- 确保 CNI 插件完整的遵循了 CNI 规范,确保 CNI DEL 操作可以正常执行。防止 CNI 插件异常导致 Pod 无法删除重建,持续在故障中无法恢复。
- 确保 CNI 配置是一个合法的 JSON 格式文件
- 不同版本内核中 netns 可配置的 sysctl 参数不同,请小心配置否则容器可能无法启动