📖 资源简介
今天分享一套Kubernetes网络训练营4期的课程资源，内容挺系统的，适合想认真学习的同学。
✨ 资源亮点
- 内容扎实：64节视频课程，跟着老师一步步操作，比自学摸索快得多。
📚 课程内容
课程大纲
- 环境准备
- 网络基础
- Cilium CNI
- Calico CNI
- Flannel CNI
资源清单
| 类型 | 数量 |
|---|---|
| 视频教程 | 64 节 |
| 压缩文件 | 0 个 |
| 合计 | 64 |
为什么 K8s 网络值得专门花时间啃
很多人学 K8s 是从 kubectl run、写 Deployment YAML 开始的，业务跑起来就以为掌握了。但真正到了生产环境，七八成的疑难杂症最后都落在网络上：Pod 跨节点不通、Service 访问偶发超时、NodePort 被云厂商 SLB 拦了、CoreDNS 解析慢、NetworkPolicy 不生效、Service Mesh 里 mTLS 把链路打满……
K8s 网络和传统虚拟机网络最大的不同在于它有一套自己的抽象模型。你必须先理解这个模型，再看 CNI 插件是怎么把它”落地”成真实报文的，否则永远只会抄 YAML。
K8s 网络的三条基本规则
K8s 官方对网络模型有三条朴素的约定，理解了这三条，后面所有 CNI 插件都是在回答同一个问题：怎么做到它们。
- 每个 Pod 都有自己的 IP 地址（IP-per-Pod）：Pod 内容器共享网络命名空间，Pod 之间通信时把对方当成一台有独立 IP 的机器，不需要做 NAT。
- Node 上的 Pod 可以直接和任意 Node 上的 Pod 通信，不需要 NAT：跨节点 Pod 互访用的是 Pod IP 本身。
- Node 上的进程（含 kubelet）可以和本 Node 上的所有 Pod 通信，也不需要 NAT。
这三条听起来简单，难的是第二条：你有 100 个节点、几千个 Pod IP，二层交换机根本不知道这些 IP 在哪台机器上，必须有人负责把路由信息”告诉”整个集群。CNI 插件就是干这件事的。
核心概念：从 netns 到 CNI
网络命名空间与 veth pair
每个 Pod 启动时，kubelet 会调用 CNI 插件，给它做这几件事：
- 创建一个新的 network namespace（netns）——这就是 Pod 的”独立网卡世界”。
- 建一对 veth pair（虚拟以太网卡对），一头放在宿主机的
cni0或caliXXXX网桥上，一头塞进 Pod 的 netns 里并改名叫eth0。 - 给 Pod 内的
eth0分配 IP、配置路由和默认网关。
你可以在宿主机上直接验证这个结构：
# 找到某个 Pod 的 netns（假设容器 ID 为 abc123）
sudo ls /var/run/netns/
sudo ip netns exec <pod-netns-name> ip addr show
# 应该能看到 Pod 内的 eth0 和它的 IP
# 看宿主机上的 veth 对
ip -d link show type veth
宿主机和 Pod 之间的所有通信，本质上都是这对 veth 上的二层帧转发。理解了 veth，就理解了”同一个 Node 上两个 Pod 为什么能直接通”——它们的 veth 都挂在同一个网桥上，交换机式学习即可。
CNI 到底是什么
CNI（Container Network Interface） 不是一个软件，而是 Google、CoreOS 等几家公司定的一个接口规范：只要一个二进制程序遵守”ADD/DEL 两个入参、返回 Pod IP 和路由”的约定，就能被 kubelet 调用给 Pod 配网。
// CNI ADD 调用的大致入参（stdin 传入）
{
"cniVersion": "0.4.0",
"name": "k8s-pod-network",
"containerid": "abc123",
"netns": "/var/run/netns/abc123",
"ifname": "eth0",
"args": {},
"plugin": "calico"
}
kubelet 在 /etc/cni/net.d/ 下读 .conf 文件，找到对应的插件二进制（通常在 /opt/cni/bin/），然后调用它。
三大主流 CNI 插件对比
课程依次讲了 Cilium、Calico、Flannel，这三家正好代表了三种技术路线：
| 维度 | Flannel | Calico | Cilium |
|---|---|---|---|
| 数据面 | UDP / VXLAN / Host-GW | IPIP / VXLAN / BGP | eBPF / VXLAN |
| 控制面 | etcd 直写 | BIRD BGP + Typha | kube-apiserver + eBPF |
| 性能 | 一般（隧道封装开销） | 较好（BGP 直连可免封装） | 最好（内核态 eBPF） |
| NetworkPolicy | 不支持 | 支持 | 支持 |
| 推荐场景 | 小规模、入门 | 中大规模、传统机房 BGP | 大规模、可观测性要求高 |
Flannel：最简单的入门款
Flannel 是 CoreOS 出的极简方案，只干一件事：给每个 Node 分一个网段，然后让所有 Node 都知道”哪个 Pod CIDR 在哪台机器上”。它把这些信息写在 etcd 里。
跨节点报文常见两种模式：
- VXLAN 模式：在宿主机上建一个
flannel.1隧道设备，把 Pod 原始 UDP 报文封装在外层 UDP 里，发到对端 Node 解封装。开销在于多了一层封装。 - Host-GW 模式：直接在每个 Node 上加路由，下一跳填对端 Node 的 IP。要求所有 Node 二层连通（同二层网络），否则路由不可达。
# 查看 flannel 配置
cat /run/flannel/subnet.env
# 典型输出：
# FLANNEL_NETWORK=10.244.0.0/16
# FLANNEL_SUBNET=10.244.1.1/24
# FLANNEL_MTU=1450
# 查看宿主机路由，能看到指向其他 Node 的 10.244.x.0/24
ip route
Calico：BGP 路由派
Calico 的思路和 Flannel 完全不同：它不搞隧道，而是在每个 Node 上跑一个 BGP 客户端（BIRD），把”我这个 Node 上有哪些 Pod 网段”通过 BGP 协议广播给其他 Node。节点之间像真实路由器一样交换路由表。
- BGP Fullmesh：节点数少时，每台 BIRD 都和其他所有节点建 BGP 邻居。节点一多，邻居数爆炸（N²）。
- BGP RR（Route Reflector）：选几台节点当路由反射器，其他节点只跟 RR 建邻居，解决规模问题。课程里”44. Calico BGP RR 模式”讲的就是这个。
- IPIP / VXLAN 模式：当物理网络不适合跑 BGP（比如跨三层），Calico 也能退回隧道封装。
Calico 的杀手锏是 NetworkPolicy：基于 iptables（或 eBPF）实现 Pod 级别的入站/出站 ACL。
Cilium：eBPF 时代的新答案
Cilium 把网络逻辑从 iptables 搬到了 eBPF 程序里，在内核态直接做报文处理，绕过 iptables 那条又长又慢的规则链。
eBPF 的价值可以概括成三点：
- 性能：不用再线性匹配成百上千条 iptables 规则。
- 可观测：每个 Pod 的 L3/L4/L7 流量都能在内核态直接观测，这就是 Hubble 服务的来源。
- 安全：NetworkPolicy、L7 策略（HTTP 方法、路径）都能在内核层强制。
课程里”12. eBPF 介绍与网络应用””13. Cilium 及安装模式介绍”是理解后面所有内容的地基，建议反复看。
Service 与 kube-proxy
Pod 是会漂移的（重启、调度、扩容），不能让调用方硬编码 Pod IP。Service 就是一组 Pod 的稳定访问入口。
四种 Service 类型
| 类型 | 作用范围 | 典型用途 |
|---|---|---|
| ClusterIP | 集群内部虚拟 IP | 微服务间调用 |
| NodePort | 每台 Node 上开一个端口 | 测试环境临时暴露 |
| LoadBalancer | 对接云厂商 LB | 生产对外服务 |
| ExternalName | DNS CNAME 别名 | 把集群外部服务映射成集群内域名 |
kube-proxy 的两种模式
kube-proxy 负责把 ClusterIP “翻译”成对真实 Pod 的转发。它有两条路线：
- iptables 模式：为每个 Service 在 nat 表写一堆随机概率规则，报文命中哪条就转给哪个后端 Pod。后端一多，规则数线性膨胀，且是无连接跟踪的随机负载。
- IPVS 模式：基于内核 L4 调度器，支持 rr / lc / sh 等调度算法，规模大时性能和可维护性都更好。
切换到 IPVS：
# kube-proxy 启动参数 --proxy-mode=ipvs
kubectl logs -n kube-system daemonset/kube-proxy | grep -i "proxy mode"
# 安装 IPVS 内核模块
sudo modprobe ip_vs ip_vs_rr ip_vs_wlc ip_vs_sh
ipvsadm -Ln
会话亲和性与 EndpointSlice
Service 的 sessionAffinity: ClientIP 可以让同一个客户端始终落到同一个后端。后端列表则由 Endpoints（旧）或 EndpointSlice（新，按规模切片）维护，kubelet 发现 Pod Ready 后由 controller 自动更新。
Ingress：七层路由
Service 是四层的，基于 IP:Port 转发。要按域名、URL 路径转发到不同 Service，就需要 Ingress：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: blog-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: blog.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-svc
port:
number: 80
tls:
- hosts: ["blog.example.com"]
secretName: blog-tls
注意 ingressClassName: nginx 指向哪个 Ingress Controller，由集群里的 IngressClass 定义决定。TLS 终止由 Ingress Controller 完成，证书放在 Secret 里。
CoreDNS 与服务发现
集群里 Pod 不靠 IP 通信，靠域名。CoreDNS 作为集群内 DNS 服务器，把 <service>.<namespace>.svc.cluster.local 解析成 ClusterIP。
每个 Pod 的 /etc/resolv.conf 由 kubelet 自动写入：
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
排查 DNS 问题的三板斧：
kubectl run -it --rm dnsutils --image=busybox:1.36 -- nslookup kubernetes.default
kubectl logs -n kube-system deploy/coredns
# 看 Corefile
kubectl get configmap -n kube-system coredns -o yaml
NetworkPolicy：给 Pod 装防火墙
默认情况下，所有 Pod 之间互相通。生产环境必须用 NetworkPolicy 做最小权限。最常见的基线是”默认拒绝所有入站，再按需放行”：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: prod
spec:
podSelector: {} # 选中 namespace 下所有 Pod
policyTypes: ["Ingress"]
ingress: [] # 空 = 拒绝一切入站
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-frontend
namespace: prod
spec:
podSelector:
matchLabels: { app: backend }
policyTypes: ["Ingress"]
ingress:
- from:
- podSelector:
matchLabels: { app: frontend }
ports:
- protocol: TCP
port: 8080
注意：NetworkPolicy 必须 CNI 插件支持才生效（Flannel 默认不支持），这也是生产环境选 Calico / Cilium 而不是 Flannel 的重要原因之一。
学习路线导读（按课程章节）
这套课的章节安排非常合理，建议按顺序学：
- 环境准备：先把集群跑起来。VMware 网络模式搞清楚（NAT / 桥接 / 仅主机），再用
kubeadm或KinD起一个多节点集群。Containerlab那节是后面做 VXLAN/BGP 实验的关键工具。 - 网络基础：TCP/IP 协议栈、IP/MAC、VETH、HOST-GW、CNI 模型与工作原理——这是后面所有插件的”公共地基”，不要跳。
- Cilium CNI（章节最大，22 节）：从 eBPF 入门，到 Native Routing、VXLAN、IPSec、Wireguard 加密、SocketLB、DSR、双栈、带宽管理、Ingress、Gateway API、BGP Control Plane、ClusterMesh。这一章节密度极高，建议每节都动手在 Containerlab 里复现一遍。
- Calico CNI：对照着 Cilium 学，重点体会 IPIP vs VXLAN vs BGP Fullmesh vs RR 的取舍。
- Flannel CNI：相对简单，重点是把它和前两家对比，理解”为什么大规模生产不会用 Flannel”。
- 高性能 CNI（Multus）：多网卡场景、IPvLAN / MACVLAN / SR-IOV，这是网卡直通、DPDK、高性能网络的进阶内容。
高频面试与排障要点
排障四件套：
# 1. Pod 之间能不能通？
kubectl exec -it <pod-a> -- ping <pod-b-ip>
kubectl exec -it <pod-a> -- curl -v <svc-name>
# 2. 解析对不对？
kubectl exec -it <pod-a> -- nslookup <svc-name>
# 3. 路由和 iptables 落在哪？
ip route show
iptables-save | grep <service-ip>
ipvsadm -Ln | grep <service-ip>
# 4. 抓包看真实报文
kubectl exec -it <pod> -- tcpdump -nn -i any port 8080
高频面试题：
- Pod 跨 Node 不通，怎么一步步排查？（先同 Node 测 → 跨 Node 测 → 查 CNI 路由 → 查安全组 → 抓包）
- Service ClusterIP 为什么在集群里能 ping / 不能 ping？（ClusterIP 是虚拟 IP，没有对应网卡，TCP 可达但 ICMP 不一定）
- kube-proxy iptables 模式和 IPVS 模式区别？什么场景必须上 IPVS？
- NetworkPolicy 不生效，先查什么？（CNI 是否支持、policyType 是否写对、podSelector 是否选中 Pod）
- Cilium 相比 Calico 的核心优势是什么？（eBPF 性能 + L7 可观测）
总结与建议
K8s 网络是一门”看十遍不如做一遍”的学科。这套课最有价值的地方，是它用 Containerlab + KinD 把 BGP、VXLAN、Wireguard、DSR 这些平时在公司集群里碰不到的底层机制都做成了可复现实验。
学习建议：
- 先有实验环境，再看视频。空看一遍很容易以为自己懂了，动手时 veth 都找不到。
- 三大插件对照着学，每换一个插件就对比一次”路由表、iptables/eBPF 规则、抓包结果”。
- 不要沉迷 CNI 选型。业务稳定比插件新潮更重要；理解原理后，选哪个插件都是工程问题。
📁 目录结构
目录概览
- 📂 1.环境准备
- 📂 2.网络基础
- 📂 3.Cilium CNI
- 📂 4.Calico CNI
- 📂 5.Flannel CNI
- 📂 6.高性能 CNI（Multus / IPvLAN / SR-IOV）
📋 点击展开查看章节大纲
[V2]Kubernetes网络训练营4期/
├── 1.环境准备
│ ├── VMware 网络模式
│ ├── Kubeadm 部署 K8s 集群
│ ├── KinD 部署 K8s 集群
│ └── Containerlab 与 KinD 结合
├── 2.网络基础
│ ├── TCP/IP 协议栈、IP 与 MAC
│ ├── VETH / HOST-GW
│ └── CNI 网络模型与工作原理
├── 3.Cilium CNI（eBPF / Native Routing / VXLAN / IPSec /
│ Wireguard / SocketLB / DSR / 双栈 /
│ LB IPAM / 带宽管理 / Ingress /
│ Gateway API / BGP Control Plane / ClusterMesh）
├── 4.Calico CNI
│ ├── 同节点通信 / Proxy ARP
│ ├── IPIP（CrossSubnet 模式）
│ ├── VXLAN（CrossSubnet 模式）
│ ├── BGP Fullmesh / Route Reflector
│ ├── eBPF with DSR / VPP 模式
│ ├── Service DataPath 与生产实践
│ └── Calico IPAM 高级用法
├── 5.Flannel CNI
│ ├── TUN-TAP / UDP / VXLAN / IPIP / HOST-GW
│ └── IPsec / Wireguard 加密模式
└── 6.高性能 CNI
├── Multus 多网卡
├── IPvLAN（L2 / L3 / SBR）
├── MACVLAN SBR
├── SR-IOV（Kernel / DPDK-VPP）
└── K8s CNI IPAM
资源获取
💡 建议：尽快保存到本地网盘或电脑，避免分享链接后期失效。
整理不易，如果对你有帮助，欢迎分享给更多需要的朋友。
请登录后查看评论内容