K3s 与 Multus CNI 集成架构决策解析：一项被否决的 ADR 及其背后的技术权衡

K3s 与 Multus CNI 集成架构决策解析一项被否决的 ADR 及其背后的技术权衡【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3sMultus 是 Kubernetes 生态中最常用的 CNI 多网卡复用器CNI multiplexer它允许单个 Pod 拥有多个网络接口从而接入数据面网络、存储网络、独立安全域等第二网络。K3s 官方仓库中有一份针对是否把 Multus 集成进 K3s的架构决策记录Architecture Decision RecordADR最终结论是Denied否决。本文以这份 ADR 为骨架结合仓库中的 e2e 测试与部署清单完整还原 K3s 团队评估 Multus 集成方案的思考过程、备选方案、限制条件与最终否决理由帮助你理解 K3s 的组件边界设计哲学以及在没有内置支持的情况下社区是如何通过 manifests 目录手动部署 Multus 并通过官方 e2e 用例验证其可用性的。一、ADR 背景这份文档记录了什么决策ADR 是 K3s 项目用于记录架构决策的规范文档本仓库的 ADR 存放于 docs/adrs 目录。本文所分析的 multus.md 创建于 2024-04-15其状态明确标注为Denied否决。该文档记录的核心问题是K3s 是否应该提供 Multus 的内置集成能力背景是社区中已有用户在自己的 K3s 集群上自行部署运行 Multus但官方缺少清晰的配置指引尤其缺少 IPAM 或额外 CNI 插件等配套组件的安装说明。K3s 团队考虑通过创建一个官方集成来降低用户的配置门槛而这份 ADR 记录了该提案的设计方案、备选方案、已知限制以及最终被否决的完整理由。值得注意ADR 的结论虽然是否决但它本身是一份非常有价值的技术资料——它明确了 Multus 与 K3s 结合的架构约束尤其是 CNI 二进制目录>apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: multus-crd namespace: kube-system spec: repo: https://rke2-charts.rancher.io chart: rke2-multus-crd targetNamespace: kube-system --- apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: multus namespace: kube-system spec: repo: https://rke2-charts.rancher.io chart: rke2-multus targetNamespace: kube-system valuesContent: |- config: fullnameOverride: multus cni_conf: confDir: /var/lib/rancher/k3s/agent/etc/cni/net.d binDir: /var/lib/rancher/k3s/data/cni/ kubeconfig: /var/lib/rancher/k3s/agent/etc/cni/net.d/multus.d/multus.kubeconfig # Comment the following line when using rke2-multus v4.2.202 multusAutoconfigDir: /var/lib/rancher/k3s/agent/etc/cni/net.d其中binDir: /var/lib/rancher/k3s/data/cni/正是 ADR 所担心的路径依赖点——data目录随 K3s 版本演进可能发生变化一旦节点间版本不一致Multus 在各节点上就找不到一致的 CNI 插件路径。这正是只能用于同构集群这一结论的直接证据。八、仓库中的实际证据社区部署路径与官方 e2e 验证虽然 ADR 否决了内置集成但仓库中保留了完整的 Multus 手动部署验证资产这说明 K3s 官方实际上认可并测试了通过 manifests 目录部署 Multus这条社区路径。8.1 e2e 测试Multus 网络连通性验证tests/e2e/multus/multus_test.go 是一个完整的 Ginkgo e2e 测试套件其验证流程可以视为一份Multus 部署验收清单集群启动通过e2e.CreateCluster拉起集群默认 1 个 server 1 个 agent节点系统默认bento/ubuntu-24.04节点就绪等待全部节点NodesReadyPod 状态等待kube-system命名空间下所有 Pod 就绪节点 IP 校验所有节点 IP 应包含10.10.网段Vagrant 私有网络Pod IP 校验Pod IP 应属于 Vagrant 网段10.10.或 cluster CIDR10.42.Multus DaemonSet 校验kubectl get ds multus -n kube-system的numberReady应为2与节点数一致部署 NetworkAttachmentDefinition 与测试 Pod应用multus_test.yaml跨节点多网卡连通性kubectl exec pod-macvlan -- ping -c 1 -w 2 10.1.1.102必须返回0% packet loss。第 8 步是整个测试的验收核心两个 Pod 分别获得 macvlan 网络的10.1.1.101/24与10.1.1.102/24地址通过 Multus 提供的第二块网卡实现跨节点互通。8.2 部署配置Multus 如何进入集群tests/e2e/multus/Vagrantfile 展示了部署方式在 server-0 节点上先把 multus-config.yaml 复制到/var/lib/rancher/k3s/server/manifests/目录vm.provision file, source: multus-config.yaml, destination: multus-config.yaml vm.provision shell, inline: sudo mkdir -p /var/lib/rancher/k3s/server/manifests/ sudo cp multus-config.yaml /var/lib/rancher/k3s/server/manifests/这正是 K3s 的标准扩展机制放入server/manifests目录的 YAML 会被 pkg/deploy/controller.go 的 watcher 自动 apply 到集群。同时注意flannel-iface: eth1的配置——在部署 Multus 的集群中明确指定 Flannel 使用的物理接口是避免网卡冲突的关键实践。8.3 测试负载macvlan 多网卡示例tests/e2e/amd64_resource_files/multus_test.yaml 提供了可直接复用的示例清单包含两部分NetworkAttachmentDefinitionmacvlan 网络定义apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: macvlan-conf spec: config: { cniVersion: 0.3.1, plugins: [ { type: macvlan, capabilities: { ips: true }, master: eth1, mode: bridge, ipam: { type: static, routes: [ { dst: 0.0.0.0/0, gw: 10.1.1.1 } ] } }, { capabilities: { mac: true }, type: tuning } ] }关键参数说明master: eth1指定绑定的宿主物理接口mode: bridge使用桥接模式IPAM 采用static类型并配置默认路由。第二段tuning插件配合capabilities: { mac: true }允许 Pod 指定自定义 MAC 地址。使用多网卡的 Podannotation 声明附加网络apiVersion: v1 kind: Pod metadata: name: pod-macvlan annotations: k8s.v1.cni.cncf.io/networks: [ { name: macvlan-conf, ips: [ 10.1.1.101/24 ], mac: c2:b0:57:49:47:f1, gateway: [ 10.1.1.1 ] }] spec: containers: - image: rancher/mirrored-library-busybox:1.37.0 command: [sleep, infinity] securityContext: capabilities: add: [NET_ADMIN,NET_RAW]Pod 通过k8s.v1.cni.cncf.io/networks注解声明附加网络为其分配10.1.1.101/24的静态 IP 与固定 MAC。NET_ADMIN、NET_RAW能力是 Pod 内执行 ping 等网络操作所必需的。九、从这份 ADR 得到的启示轻量优先是硬约束任何使默认 K3s 二进制体积显著膨胀10%或引入 CVE 风险的方案都会被否决绝大多数用户不会启用是重要的否决依据。同构性假设的代价依赖 contenteditable="false">【免费下载链接】k3sLightweight Kubernetes项目地址: https://gitcode.com/GitHub_Trending/k3/k3s创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考