惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Threatpost
The Hacker News
The Hacker News
AWS News Blog
AWS News Blog
Spread Privacy
Spread Privacy
T
Tenable Blog
C
CERT Recently Published Vulnerability Notes
Cisco Talos Blog
Cisco Talos Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
S
Securelist
P
Privacy & Cybersecurity Law Blog
Know Your Adversary
Know Your Adversary
T
The Exploit Database - CXSecurity.com
Latest news
Latest news
D
Darknet – Hacking Tools, Hacker News & Cyber Security
I
Intezer
F
Fortinet All Blogs
Engineering at Meta
Engineering at Meta
Simon Willison's Weblog
Simon Willison's Weblog
The Register - Security
The Register - Security
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
L
Lohrmann on Cybersecurity
C
Cyber Attacks, Cyber Crime and Cyber Security
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
H
Help Net Security
T
Threat Research - Cisco Blogs
D
DataBreaches.Net
S
Schneier on Security
Cyberwarzone
Cyberwarzone
Google DeepMind News
Google DeepMind News
P
Privacy International News Feed
S
Secure Thoughts
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recorded Future
Recorded Future
C
Cybersecurity and Infrastructure Security Agency CISA
MyScale Blog
MyScale Blog
M
MIT News - Artificial intelligence
Stack Overflow Blog
Stack Overflow Blog
IT之家
IT之家
人人都是产品经理
人人都是产品经理
NISL@THU
NISL@THU
博客园 - Franky
T
Tor Project blog
G
GRAHAM CLULEY
博客园 - 【当耐特】
Jina AI
Jina AI
Security Archives - TechRepublic
Security Archives - TechRepublic
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
A
About on SuperTechFans
Hacker News - Newest:
Hacker News - Newest: "LLM"

博客园_首页

Linux实操--组管理、权限管理和定时任务 Java + EasyExcel 实现单个接口导出多个Excel Mem0 源码解析系列(二):提示词工程的深度剖析 Openclaw TaskFlow究竟是什么?和普通Skill技能有什么区别 博文阅读密码验证 - 博客园 嘉立创开源:应该是全网MicroPython教程最多的开发板 Hermes Agent 集成实践:从协议到生产 2026年AI编程工具横评:Cursor、Codex、Claude Code、Zed、Windsurf Java程序员必看的RAG入门教程 2026 AI效率神器:Superpowers + Claude Code 保姆级教程 本地大模型部署全攻略:从 0 到 1 玩转 Ollama 【从0到1构建一个ClaudeAgent】内存管理-上下文压缩 .NET 高级开发 | 设计、实现一个事件总线框架 电子小白入门之NE555 3. WorkBuddy:隐藏玩法,一键召唤专家,让 AI 以"专家身份"给你干活 和AI一起搞事情#3:Claude Teammate 游戏开发翻车实录 【OpenClaw】通过 Nanobot 源码学习架构---(7)Memory C# .NET 周刊|2026年3月3期 我在 Debian 11 上把 K8s 单机搭起来了,过程没你想的那么顺(/opt 目录版) 深度学习进阶(七)Data-efficient Image Transformer CLI+Skill搭建浏览器AI自动化框架,告别一切重复枯燥任务 告别Token账单无底洞:OpenClaw本地部署,重塑企业数据主权的唯一解 FastAPI+Vue:文件分片上传+秒传+断点续传,这坑我帮你踩平了! SBTI 爆火后,我做了个程序员版的 CBTI。。已开源 + 附开发过程 多模态检索开始进入工程期:用 Sentence Transformers 搭建可落地的 Multimodal RAG 100多行代码实现一个最简单的Agent(用ReAct) Claude Code 通关手册(八):推荐 5 个 Hooks,代码质量提升 3 倍 老板:“有人截图了!”。安全部门:“收到,马上查暗水印!” - why技术 技术之外,皆是人间 C#/.NET/.NET Core技术前沿周刊 | 第 69 期(2026年4.01-4.12) Snack JSONPath 项目架构分析 Claude Code Buddy 小析:一个非核心功能,如何体现产品的细节完成度 AI新时代下的图床管理方案-Cloudflare图床+MCP+Skills方案指南 化繁为简:顺丰速运App如何通过 HarmonyOS SDK实现专业级空间测量 从零实现富文本编辑器#13-React非编辑节点的内容渲染 AI开发-python-langchain框架(3-23-OpenAI Functions风格Tool Calling智能助手) .NET + AI 进阶实战:基于类的技能开发 - 打造可治理的 Agent 能力模块 【从0到1构建一个ClaudeAgent】规划与协调-技能 上周热点回顾(4.6-4.12) 电子小白的工具三件套:面包板、杜邦线、万能板 单表五亿数据的查询优化 | Mysql、StarRocks 2. WorkBuddy:从“我是谁”到“帮我干活” C# 如何减少代码运行时间:7 个实战技巧 基于HelixToolkit.SharpDX 渲染3D模型 - 笺上知微 从零开始的双臂具身VLA起源及现阶段发展综述 - SkyXZ 记对 xonsh shell 的使用, 脚本编写, 迁移及调优 - pluvium27 受够了Vibe Coding的失控?换个起点,让AI事半功倍 从开始配置漏洞环境到漏洞复现流程 - 難しい 关于10年工作经验的程序员对OpenClaw的实战经验分享以及看法 - 虚无境 Any metadata 的内存布局 C# .NET 周刊|2026年3月2期 - InCerry 我帮你测过了,测试圈排名第二的 Skill 依然很牛逼 Skill Discovery | 无监督技能发现的经典工作总结 - MoonOut PbootCMS 网站内容数量多导致访问慢?这些实用优化方案帮你提速! - 家兴网络技术工作室 上下文工程是什么?过时了么?一文讲明白! - 一枫说码 网站漏洞怎么发现并修复?一篇实用指南(附完整流程) - 家兴网络技术工作室 开了 TUN 模式还是直连?90% 的人都踩过这个坑 Github日报|2026年04月12日 - AI一族 AScript扩展多种脚本语言 - rockey627 AI 学习笔记:Agent 的记忆机制 你能被装进一个文件里吗?——7 万人把同事"蒸馏"成了 AI - 我没有三颗心脏 Claude Code 通关手册(七):给 AI 装上技能包——Skills 完全指南 - 暮色之狐 在浏览器中快速编辑代码:VSCode Web 集成实践 - Newbe36524 蒸馏自己 skill?基于 Deepseek 的蒸馏器,丐版蒸馏方式,简单便捷 - To_Carpe_Diem Spring AI Aliababa和AgentScope,哪个更好? - 苏三说技术 Etsy 把 1000 个 MySQL 分片迁进 Vitess:425TB 数据背后的真正问题不是性能,而是运维规模 MicroPython LVGL基础知识和概念:底层渲染与性能优化 - FreakStudio 数据库草图算法 Python 潮流周刊#146:CPython 引入 Rust 的进展 - 豌豆花下猫 最小生成树 - mofei1116 红日靶场七:从外网入口、容器逃逸到 AD 接管的完整利用链复盘 - YouDiscovered1t 分享四款开源且实用的 Kafka 管理工具 - 追逐时光者 vLLM 权重加载机制全解析:从挑战到理想架构 LCT 学习笔记 - ACehomoxue Avalonia UI 12.0.0 正式发布:架构演进和性能飞跃 - 张善友 当 AI Agent 把调用链拉长,延迟开始成为一门生意 conhost.exe 无法显示 U+2717 - 145a 太秀了,我把自己蒸馏成了 Skill!已开源 - 程序员鱼皮 ASP.NET Core 内存缓存实战:一篇搞懂该怎么配、怎么避坑 基于 Ghostty 带有分割标签页和为 Claude 编程设计的通知终端 - BugShare AI 焊死入口:教育的“操作系统级”重塑 - 郝hai 初级Java开发工程师使用sql脚本编写代码的过程是简单而且不糊涂 - CoderOilStation Claude Code通关手册(六):MCP协议完全指南 - 暮色之狐 边框灯光环绕动画特效实现指南 - Newbe36524 开源:子木蒸馏版的 SEO 审计工具 seo-audit-skill v1.0 我所理解的Python元模型 【从0到1构建一个ClaudeAgent】规划与协调-TodoWrite - 程序员Seven Claude 和 Codex 在审计 Skill 上性能差异探究 - ACai_sec AScript如何实现中文脚本引擎 - rockey627 【渗透测试】HTB Season10 Garfield 全过程wp - dynasty_chenzi Android 开发者为什么必须掌握 AI 能力?端侧视角下的技术变革 树状数组正确性证明 - AC-wyr 你的 AI 焦虑,可能比 AI 本身更危险——ATM 机没有消灭银行柜员,但恐慌消灭了你的判断力 - 我没有三颗心脏 一个拉胯的分库分表方案有多绝望?整个部门都在救火! - 冰河团队 动态规划入门必学之走方格问题 - Ofnoname PostgREST 与 PostgreSQL 角色权限配置全解析(生产级实践) - SheepDog1998 使用 UEFI 图形输出协议 GOP 在屏幕上显示图像的方法 - 阿源- Claude Code通关手册(五):组建你的AI专家团队,子代理系统 - 暮色之狐 一个程序员到架构师的催婚路之感悟(整整10年后的催婚相亲感悟) - MisterLip 用 Agent Skill 自动生成工作周报 - 赵康
Multus 多网卡方案:IPVLAN 模式
怎么还在写代码 · 2026-05-23 · via 博客园_首页

模式介绍

Multus 项目地址:https://github.com/k8snetworkplumbingwg/multus-cni

Whereabouts 项目地址:https://github.com/k8snetworkplumbingwg/whereabouts

CNI(容器网络接口)是云原生计算基金会(CNCF)的一个项目,它包含一套规范及开发库。通过 CNI 编写网络插件用于配置容器网络,同时 CNI 本身也供了一系列现成的插件。CNI 仅专注于容器的网络连通性,以及在容器被删除时清理已分配的网络资源。正是由于这种专注性,它获得了广泛的支持和易于实现的规范。

IPVLAN 就是 CNI 自带的网络插件之一,它也对宿主机的网络接口进行了虚拟化,所有 IPVLAN 设备共享同一个 MAC 地址。

# 在 ns0 与 ns1 两个网络空间中,他们的网卡设备 ipvl0/ipvl1 ip 不一致,但 MAC 地址均与 host1 主机 eth0 相同

+=============================================================+
|  Host: host1                                                |
|                                                             |
|   +----------------------+      +----------------------+    |
|   |   NS:ns0             |      |  NS:ns1              |    |
|   |                      |      |                      |    |
|   |                      |      |                      |    |
|   |        ipvl0         |      |         ipvl1        |    |
|   +----------#-----------+      +-----------#----------+    |
|              #                              #               |
|              ################################               |
|                              #                              |
|                              #                              |
|                              # eth0                         |
+=============================================================+

image

Multus CNI 允许将多个网络接口连接到 K8s Pod 中。在安装他之前,K8s 集群必须安装一个默认的 CNI 插件,例如 Flannel、Calico 等。

部署流程

通过 Kind 快速生成集群并部署 Multus CNI + Whereabouts IPAM

主脚本

#!/bin/bash

set -v

# 1.kind 创建集群时关闭默认 CNI 部署
cat << EOF | HTTP_PROXY= HTTPS_PROXY= http_proxy= https_proxy= kind create cluster --name=cni-multus --image=kindest/node:v1.27.3 --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF

# 2.remove taints
kubectl taint nodes $(kubectl get nodes -o name | grep control-plane) node-role.kubernetes.io/control-plane:NoSchedule-

# 3. install CNI
kubectl apply -f ./k8snetworkplumbingwg

K8snetworkplumbingwg 目录内容

Calico CNI

部署 Calico v3.31.5 示例(IPIP)作为集群默认 CNI:

            # Cluster type to identify the deployment type
            - name: CLUSTER_TYPE 
              value: "k8s,bgp"
            # Auto-detect the BGP IP address.
            - name: IP
              value: "autodetect" 
            # Enable IPIP 
            - name: CALICO_IPV4POOL_IPIP
              value: "Always"
            # Enable or Disable VXLAN on the default IP pool.
            - name: CALICO_IPV4POOL_VXLAN
              value: "Never"
            # Enable or Disable VXLAN on the default IPv6 IP pool.
            - name: CALICO_IPV6POOL_VXLAN
              value: "Never"

Multus

使用"厚插件(Thick)"形式部署 Multus。与薄插件(Thin)两种部署方式对比:

  • 薄插件:每次创建/删除 Pod 时,直接调用 /opt/cni/bin/multus 二进制文件。每次调用都是一个独立进程,日志分散在 kubelet 中,不方便排查问题、且没有 Metrics 指标;
  • 厚插件:拆成了两个进程 shimdaemon。日志集中在 daemon 中统一管理、且通过 daemon 暴露 Metrics 指标。
    • Shim:客户端,k8s 调用 shim 后,会通过绑定挂载到主机文件系统的 Unix 域套接字与 daemon 通信;
    • Daemon:服务端,负责执行所有繁重的拉取操作,读取 CRD、计算配置、调用 delegate 插件等。
┌─────────┐             ┌───────┐           ┌────────┐             ┌──────────┐
│         │ cni ADD/DEL │       │ REST POST │        │ cni ADD/DEL │          │
│ runtime ├────────────►│ shim  │===========│ daemon ├────────────►│ delegate │
│         │<------------│       │           │        │<------------│          │
└─────────┘             └───────┘           └────────┘             └──────────┘

按照上面引用的 GitHub 仓库地址中提供的部署方式部署即可。

Whereabouts

Multus CNI 的 IPAM 地址管理插件。按照 GitHub 仓库中提供的一键部署方式部署即可

查看部署结果

root@network-demo:~# kubectl get node -o wide
NAME                       STATUS   ROLES           AGE     VERSION   INTERNAL-IP
cni-multus-control-plane   Ready    control-plane   4m56s   v1.27.3   172.18.0.4
cni-multus-worker          Ready    <none>          4m31s   v1.27.3   172.18.0.3
cni-multus-worker2         Ready    <none>          4m33s   v1.27.3   172.18.0.2

root@network-demo:~# kubectl get pods -A -o wide
NAMESPACE            NAME                                 READY   STATUS    RESTARTS   AGE     IP               NODE
kube-system          calico-kube-controllers-547c488cf5   1/1     Running   0          4m31s   10.244.226.132   cni-multus-control-plane
kube-system          calico-node-5lgrw                    1/1     Running   0          4m31s   172.18.0.4       cni-multus-control-plane
kube-system          calico-node-7fk72                    1/1     Running   0          4m31s   172.18.0.3       cni-multus-worker
kube-system          calico-node-t67s5                    1/1     Running   0          4m31s   172.18.0.2       cni-multus-worker2
kube-system          coredns-5d78c9869d-p874p             1/1     Running   0          4m40s   10.244.226.131   cni-multus-control-plane
kube-system          coredns-5d78c9869d-z6bcj             1/1     Running   0          4m40s   10.244.226.130   cni-multus-control-plane
kube-system          etcd-cni-multus                      1/1     Running   0          4m55s   172.18.0.4       cni-multus-control-plane
kube-system          kube-apiserver-cni-multus            1/1     Running   0          4m55s   172.18.0.4       cni-multus-control-plane
kube-system          kube-controller-manager-cni-multus   1/1     Running   0          4m56s   172.18.0.4       cni-multus-control-plane
kube-system          kube-multus-ds-6nvfz                 1/1     Running   0          4m31s   172.18.0.2       cni-multus-worker2
kube-system          kube-multus-ds-hn6gj                 1/1     Running   0          4m31s   172.18.0.3       cni-multus-worker
kube-system          kube-multus-ds-r8qfk                 1/1     Running   0          4m31s   172.18.0.4       cni-multus-control-plane
kube-system          kube-proxy-4vfdj                     1/1     Running   0          4m35s   172.18.0.2       cni-multus-worker2
kube-system          kube-proxy-cz8sl                     1/1     Running   0          4m40s   172.18.0.4       cni-multus-control-plane
kube-system          kube-proxy-q9hv5                     1/1     Running   0          4m33s   172.18.0.3       cni-multus-worker
kube-system          kube-scheduler-cni-multus            1/1     Running   0          4m55s   172.18.0.4       cni-multus-control-plane
kube-system          whereabouts-98fn6                    1/1     Running   0          4m31s   172.18.0.3       cni-multus-worker
kube-system          whereabouts-tqnqk                    1/1     Running   0          4m31s   172.18.0.4       cni-multus-control-plane
kube-system          whereabouts-xfbgj                    1/1     Running   0          4m31s   172.18.0.2       cni-multus-worker2

root@network-demo:~# kubectl get crd network-attachment-definitions.k8s.cni.cncf.io
NAME                                             CREATED AT
network-attachment-definitions.k8s.cni.cncf.io   2026-05-23T00:58:25Z

创建测试 Pod

先通过 Multus CNI 使用 NetworkAttachmentDefinition CRD 创建 Pod 附加网络模板后,在生成 Pod 时引用对应模板:

#!/bin/bash

set -v 

controller_node=`kubectl get nodes --no-headers  -o custom-columns=NAME:.metadata.name| grep control-plane`
worker_node=`kubectl get nodes --no-headers  -o custom-columns=NAME:.metadata.name| grep worker2`

cat <<EOF | kubectl apply -f -
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlanl2-whereabouts-conf
spec:
  config: '{
      "cniVersion": "0.3.0",
      "name": "whereaboutsexample",
      "type": "ipvlan",
      "mode": "l2",
      "master": "eth0",
      "ipam": {
        "type": "whereabouts",
        "range": "172.18.0.200-172.18.0.205/24"
      }
    }'
EOF

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ipvlan-pod1
  annotations:
    k8s.v1.cni.cncf.io/networks: ipvlanl2-whereabouts-conf@eth1
spec:
  containers:
  - name: nettool
    image: burlyluo/nettool:latest
    securityContext:
      privileged: false
      capabilities:
        add: ["NET_ADMIN"]
  nodeName: ${controller_node}
EOF

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ipvlan-pod-x
  annotations:
    k8s.v1.cni.cncf.io/networks: ipvlanl2-whereabouts-conf@eth1
spec:
  containers:
  - name: nettool
    image: burlyluo/nettool:latest
    securityContext:
      privileged: false
      capabilities:
        add: ["NET_ADMIN"]
  nodeName: ${controller_node}
EOF

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: ipvlan-pod2
  annotations:
    k8s.v1.cni.cncf.io/networks: ipvlanl2-whereabouts-conf@eth1
spec:
  containers:
  - name: nettool
    image: burlyluo/nettool:latest
    securityContext:
      privileged: false
      capabilities:
        add: ["NET_ADMIN"]
  nodeName: ${worker_node}
EOF

问题解决

创建测试 Pod 后,可能会一直卡在 ContainerCreating 状态,通过 describe pod 发现创建流程中的关键报错 failed to find plugin "ipvlan" in path [/opt/cni/bin],这是因为 kind 创建 k8s 集群时的基础镜像中没有包含 IPVLAN 这个 CNI 插件。在主机上手动拉一下 CNI 包解压到几个 k8s node 容器中即可修复:

root@network-demo:~# kubectl get pods -o wide
NAME           READY   STATUS              RESTARTS   AGE    IP       NODE
ipvlan-pod-x   0/1     ContainerCreating   0          103s   <none>   cni-multus-control-plane
ipvlan-pod1    0/1     ContainerCreating   0          103s   <none>   cni-multus-control-plane
ipvlan-pod2    0/1     ContainerCreating   0          102s   <none>   cni-multus-worker2

root@network-demo:~# kubectl describe pods ipvlan-pod-x | grep -A4 'Events'
Events:
  Type     Reason                  Age   From     Message
  ----     ------                  ----  ----     -------
  Normal   AddedInterface          110s  multus   Add eth0 [10.244.226.134/32] from k8s-pod-network
  Warning  FailedCreatePodSandBox  109s  kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "31265d3618de74e470e1a39c0670a463566a99176cbb3c7774d56589c81ba3a2": plugin type="multus-shim" name="multus-cni-network" failed (add): CmdAdd (shim): CNI request failed with status 400: 'ContainerID:"31265d3618de74e470e1a39c0670a463566a99176cbb3c7774d56589c81ba3a2" Netns:"/var/run/netns/cni-6db962c0-2e51-298e-9cbd-8599f6f18e71" IfName:"eth0" Args:"K8S_POD_NAME=ipvlan-pod-x;K8S_POD_INFRA_CONTAINER_ID=31265d3618de74e470e1a39c0670a463566a99176cbb3c7774d56589c81ba3a2;K8S_POD_UID=e8872b13-c212-4b3b-9158-794adf3a8527;IgnoreUnknown=1;K8S_POD_NAMESPACE=default" Path:"" ERRORED: error configuring pod [default/ipvlan-pod-x] networking: [default/ipvlan-pod-x/e8872b13-c212-4b3b-9158-794adf3a8527:whereaboutsexample]: error adding container to network "whereaboutsexample": failed to find plugin "ipvlan" in path [/opt/cni/bin]
': StdinData: {"capabilities":{"portMappings":true},"clusterNetwork":"/host/etc/cni/net.d/10-calico.conflist","cniVersion":"0.3.1","logLevel":"verbose","logToStderr":true,"name":"multus-cni-network","type":"multus-shim"}
root@network-demo:~# wget https://github.com/containernetworking/plugins/releases/download/v1.9.1/cni-plugins-linux-amd64-v1.9.1.tgz

root@network-demo:~# tar tf cni-plugins-linux-amd64-v1.9.1.tgz
./
./sbr
./tap
./dhcp
./dummy
./bridge
./host-device
./README.md
./LICENSE
./static
./portmap
./host-local
./firewall
./tuning
./vlan
./ptp
./macvlan
./loopback
./ipvlan
./vrf
./bandwidth

root@network-demo:~# for node in $(docker ps --format '{{.Names}}' | grep 'cni-multus'); do
  docker cp cni-plugins-linux-amd64-v1.9.1.tgz ${node}:/
  docker exec ${node} tar -C /opt/cni/bin/ -xzf /cni-plugins-linux-amd64-v1.9.1.tgz --no-same-owner ./ipvlan
  docker exec ${node} rm -rf /cni-plugins-linux-amd64-v1.9.1.tgz
  echo "${node} done"
done

验证效果

查看测试 Pod 创建流程

通过 Pod 事件信息看出,由集群默认 CNI Calico 生成了 eth0 网卡,然后 Multus CNI 通过 NetworkAttachmentDefinition CRD 配置生成了 IPVLAN 模式的 eth1 网卡:

root@network-demo:~# kubectl get pods -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP               NODE
ipvlan-pod-x   1/1     Running   0          18m   10.244.228.174   cni-multus-control-plane
ipvlan-pod1    1/1     Running   0          18m   10.244.228.175   cni-multus-control-plane
ipvlan-pod2    1/1     Running   0          18m   10.244.4.89      cni-multus-worker2


root@network-demo:~# kubectl describe pods ipvlan-pod-x | grep -A8 'Events'
Events:
  Type    Reason          Age   From     Message
  ----    ------          ----  ----     -------
  ## 通过创建流程可以看出,eth0 网卡是通过集群默认 CNI Calico 生成的
  Normal  AddedInterface  10s   multus   Add eth0 [10.244.228.176/32] from k8s-pod-network
  ## 而 eth1 网卡则是通过 IPVLAN 读取 NetworkAttachmentDefinition 配置生成的
  Normal  AddedInterface  9s    multus   Add eth1 [172.18.0.200/24] from default/ipvlanl2-whereabouts-conf
  Normal  Pulling         9s    kubelet  Pulling image "burlyluo/nettool:latest"
  Normal  Pulled          9s    kubelet  Successfully pulled image "burlyluo/nettool:latest" in 205.281392ms (205.292364ms including waiting)
  Normal  Created         9s    kubelet  Created container nettool
  Normal  Started         9s    kubelet  Started container nettool

查看 Pod 子网卡与 Node 父网卡信息

以 control-plane 节点中的父网卡 eth0 与其上两个 Pod 子网卡信息为例,可以发现他们的 MAC 地址是一致的:

## Pod-x 子网卡信息
root@network-demo:~# kubectl exec -it ipvlan-pod-x -- ip address show eth1
4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.200/24 brd 172.18.0.255 scope global eth1
       valid_lft forever preferred_lft forever
root@network-demo:~# kubectl exec -it ipvlan-pod-x -- ip -d link show eth1
4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 minmtu 68 maxmtu 65535 
    ipvlan  mode l2 bridge addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

## Control-plane 节点父网卡信息
root@network-demo:~# docker exec -it cni-multus-control-plane ip address show eth0
3: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.4/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever
root@network-demo:~# docker exec -it cni-multus-control-plane ip -d link show eth0
3: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 minmtu 68 maxmtu 65535 
    veth addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535

## Pod-1 子网卡信息
root@network-demo:~# kubectl exec -it ipvlan-pod1 -- ip address show eth1
4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.202/24 brd 172.18.0.255 scope global eth1
       valid_lft forever preferred_lft forever
root@network-demo:~# kubectl exec -it ipvlan-pod1 -- ip -d link show eth1
4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether a6:7c:81:af:f4:be brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0 minmtu 68 maxmtu 65535 
    ipvlan  mode l2 bridge addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

同节点 Pod 请求抓包

Pod-x(10.244.228.176)请求 Pod-1(10.244.228.175)

1.查询 Pod 路由表、ARP 邻居表

root@network-demo:~# kubectl exec -it ipvlan-pod-x -- ip route show
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
172.18.0.0/24 dev eth1 proto kernel scope link src 172.18.0.200

## ARP 表是请求后看的
root@network-demo:~# kubectl exec -it ipvlan-pod-x -- ip neighbor show
169.254.1.1 dev eth0 lladdr ee:ee:ee:ee:ee:ee STALE
172.18.0.202 dev eth1 lladdr a6:7c:81:af:f4:be STALE
10.244.228.175 dev eth1 lladdr a6:7c:81:af:f4:be STALE
10.244.226.128 dev eth0 lladdr ee:ee:ee:ee:ee:ee STALE
root@network-demo:~#

2.查询 Node 节点路由表、ARP 邻居表

root@network-demo:~# docker exec cni-multus-control-plane ip route show
default via 172.18.0.1 dev eth0
10.244.2.64/26 via 172.18.0.2 dev tunl0 proto bird onlink
10.244.4.64/26 via 172.18.0.2 dev tunl0 proto bird onlink
10.244.171.0/26 via 172.18.0.3 dev tunl0 proto bird onlink
blackhole 10.244.226.128/26 proto bird
10.244.226.129 dev cali65d6a29e132 scope link
10.244.226.130 dev calibbcace8eb36 scope link
10.244.226.131 dev calife013ec3a25 scope link
10.244.226.132 dev cali36b0b7ed002 scope link
blackhole 10.244.228.128/26 proto bird
## 同节点 Pod 之间请求直接走 Pod-1 的 calic903a597e8b veth pair 设备转发了
10.244.228.175 dev calic903a597e8b scope link
10.244.228.176 dev calic46f11b893d scope link
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.4

root@network-demo:~# docker exec cni-multus-control-plane ip neighbor show
10.244.228.176 dev calic46f11b893d lladdr a2:6a:47:6d:d3:15 STALE
10.244.226.132 dev cali36b0b7ed002 lladdr be:9d:a8:51:65:77 REACHABLE
172.18.0.2 dev eth0 lladdr aa:18:7e:65:a2:af REACHABLE
10.244.226.130 dev calibbcace8eb36 lladdr ae:79:98:32:49:98 REACHABLE
10.244.226.129 dev cali65d6a29e132 lladdr f2:c1:bc:28:d4:7f REACHABLE
172.18.0.1 dev eth0 lladdr 46:e0:1c:d1:1e:e0 STALE
10.244.226.131 dev calife013ec3a25 lladdr 0a:35:d1:7b:bc:ba REACHABLE
172.18.0.3 dev eth0 lladdr ae:66:81:13:7d:ee REACHABLE
10.244.228.175 dev calic903a597e8b lladdr 0e:c0:f7:6e:35:63 STALE

3.同节点 Pod 请求

root@network-demo:~# kubectl exec -it ipvlan-pod-x -- ping -I eth1 -c2 10.244.228.175
PING 10.244.228.175 (10.244.228.175): 56 data bytes
64 bytes from 10.244.228.175: seq=0 ttl=64 time=0.137 ms
64 bytes from 10.244.228.175: seq=1 ttl=64 time=0.091 ms

--- 10.244.228.175 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.091/0.114/0.137 ms

这里可能会有疑问:eth1 并没有去 10.244.228.175 的路由,那他是怎么发出去的?

  1. 因为 eth1 是一个子网卡,挂在 Control-Plane 节点 eth0 父网卡下。创建 NetworkAttachmentDefinition 模板时使用 IPVLAN 模式,从子网卡 eth1 发出的包都会由 eth0 父网卡响应;
  2. 从下面抓包可以看出,ARP 广播怎么去 10.244.228.175 时,响应的 MAC 地址是父网卡 MAC。所以请求压根没走默认 CNI 的 eth0 --> calixxx 这条路,在 veth pair 上是抓不到包的;
  3. 请求由父网卡 eth0 进入主机后,再进行路由匹配 10.244.228.175 dev calic903a597e8b lladdr 0e:c0:f7:6e:35:63 STALE 由 Pod-1 的 veth pair 发给 Pod-1。
root@network-demo:~# kubectl exec -it ipvlan-pod-x -- tcpdump -pnei eth1

02:36:14.450486 a6:7c:81:af:f4:be > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.244.228.175 tell 172.18.0.200, length 28
02:36:14.450511 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype ARP (0x0806), length 42: Reply 10.244.228.175 is-at a6:7c:81:af:f4:be, length 28
02:36:14.450513 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 172.18.0.200 > 10.244.228.175: ICMP echo request, id 41, seq 0, length 64
02:36:14.450569 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 10.244.228.175 > 172.18.0.200: ICMP echo reply, id 41, seq 0, length 64
02:36:15.450654 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 172.18.0.200 > 10.244.228.175: ICMP echo request, id 41, seq 1, length 64
02:36:15.450708 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 10.244.228.175 > 172.18.0.200: ICMP echo reply, id 41, seq 1, length 64

如果在父网卡 eth0 抓包,会发现只有 request 没有 response。这是因为请求到了 Pod-1 响应时,直接走了 Pod-1 中的 eth1 网卡,没有再通过主机 eth0 这个父网卡转发

root@network-demo:~# docker exec -it cni-multus-control-plane tcpdump -pnei eth0 icmp

05:33:05.028947 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 172.18.0.200 > 10.244.228.175: ICMP echo request, id 150, seq 0, length 64
05:33:06.029084 a6:7c:81:af:f4:be > a6:7c:81:af:f4:be, ethertype IPv4 (0x0800), length 98: 172.18.0.200 > 10.244.228.175: ICMP echo request, id 150, seq 1, length 64
root@network-demo:~# kubectl exec -it pods/ipvlan-pod1 -- ip route show
default via 169.254.1.1 dev eth0 
169.254.1.1 dev eth0 scope link 
172.18.0.0/24 dev eth1 proto kernel scope link src 172.18.0.202 

root@network-demo:~# kubectl exec -it pods/ipvlan-pod1 -- ip neighbor show
169.254.1.1 dev eth0 lladdr ee:ee:ee:ee:ee:ee STALE
172.18.0.200 dev eth1 lladdr a6:7c:81:af:f4:be STALE
10.244.226.128 dev eth0 lladdr ee:ee:ee:ee:ee:ee STALE