1. 云原生网络概述：从传统网络到云原生网络的演进
大家好，我是你们的老朋友。今天咱们聊聊云原生网络。说实话，这个领域我摸爬滚打了快十年，踩过的坑比吃过的盐还多。但正是这些经历，让我对网络的理解越来越深。
先问大家一个问题：为什么我们要搞云原生网络？传统的网络架构不也挺好的吗？嗯，这个问题我当年也问过自己。直到我在一个项目中，用传统网络去支撑一个每天百万级调用的微服务集群，结果网络成了最大的瓶颈。那一刻我才明白——时代变了。
1.1 传统网络的局限性
传统网络，说白了就是物理设备堆出来的。交换机、路由器、防火墙，一层一层叠上去。你想想看，在物理机时代，一台机器一个IP，网络拓扑基本固定。运维人员手动配配VLAN、写写路由表，日子还算过得去。
但到了容器时代，情况完全不一样了。
- IP是临时的：容器随时创建、销毁，IP地址像流水一样变化。传统网络哪受得了这个？
- 拓扑是动态的：服务A今天在这台机器上，明天可能就跑到另一台去了。网络策略怎么跟？
- 规模是巨大的：一个K8s集群几千个Pod，传统网络设备根本扛不住那么多MAC地址表。
核心矛盾：传统网络是静态的、物理的、手工的；云原生网络需要动态的、虚拟的、自动化的。
我记得有一次，帮一个客户做容器化改造。他们原来的网络架构用了三层交换机加VRRP，稳定运行了五年。结果容器一上来，Pod之间通信频繁断连。查了半天，发现是交换机MAC表项溢出。你说尴尬不尴尬？
1.2 云原生网络的演进路径
云原生网络不是一天建成的。它经历了几个阶段，我给大家捋一捋。
| 阶段 | 代表技术 | 特点 | 我的评价 |
|---|---|---|---|
| 第一阶段 | Docker原生网络（bridge/host） | 单机隔离，跨机靠端口映射 | 能用，但太原始 |
| 第二阶段 | Overlay网络（Flannel VXLAN） | 跨主机通信，封装开销大 | 解决了连通性，性能堪忧 |
| 第三阶段 | 高性能CNI（Calico、Cilium） | 直接路由、eBPF加速 | 这才是云原生的样子 |
| 第四阶段 | Service Mesh + 网络策略 | 精细化管控、可观测性 | 未来方向，但复杂度高 |
我个人习惯把第二阶段叫做「能用但肉疼」的阶段。为什么？因为VXLAN封装带来的性能损耗，在IO密集型的场景下特别明显。我曾经在一个日志采集系统里，用了Flannel，结果网络吞吐直接掉了30%。后来换成Calico的BGP模式，才把性能拉回来。
我的建议：如果你的集群规模小于100节点，Flannel够用。超过这个数，直接上Calico或Cilium，别犹豫。
1.3 云原生网络的核心挑战
好，聊完了演进，咱们说说核心挑战。这三个问题，你搞不定，云原生网络就玩不转。
挑战一：性能
性能是云原生网络的「命门」。为什么这么说？
- Overlay开销：VXLAN、Geneve这些封装技术，每个包要多几十字节的头。对于小包场景（比如Redis、Kafka），影响特别明显。
- 内核瓶颈：传统的iptables/Netfilter，规则一多，性能直线下降。我见过一个集群，iptables规则超过5000条，网络延迟从1ms飙到50ms。
- CPU争抢：网络包处理占用了大量CPU，业务进程反而没资源了。
怎么解决？现在主流方案是eBPF和DPDK。Cilium就是基于eBPF的，它把网络策略、负载均衡都放到了内核的BPF程序中执行，绕过了iptables。我在一个金融项目中测试过，Cilium比Calico的iptables模式，吞吐提升了40%，延迟降低了60%。
注意：eBPF虽然好，但要求内核版本4.19以上。如果你的环境还是CentOS 7（内核3.10），那就别想了。我曾经因为这个原因，被迫在老旧集群上继续用iptables，那叫一个憋屈。
挑战二：隔离性
隔离性，说白了就是「你的流量别跑到我这边来」。在云原生环境里，隔离性有三个层次：
- 网络策略隔离：K8s的NetworkPolicy，基于标签选择器控制Pod之间的流量。但要注意，默认是允许所有流量的，你得显式拒绝。
- 租户隔离：多租户场景下，不同团队的Pod必须严格隔离。常用的方案有：命名空间+网络策略、VPC per tenant、或者Calico的IP池隔离。
- 安全隔离：防止东西向流量攻击。比如一个Pod被攻破了，不能让它横向扩散。
我踩过一个坑：某个客户的多租户集群，A团队的Pod居然能直接访问B团队的数据库。查了半天，发现是NetworkPolicy没写对——只限制了入站，没限制出站。从那以后，我养成了一个习惯：默认拒绝所有流量，再按需放行。
挑战三：可观测性
可观测性，是云原生网络里最容易被忽视、但最要命的问题。你想想看，几百个微服务，几千个Pod，网络出问题了，你怎么定位？
传统网络有ping、traceroute、tcpdump。但在云原生环境里，这些工具不够用了。因为：
- Pod IP是动态的，你没法提前知道该抓哪个IP的包。
- 服务间调用链路复杂，一个请求可能经过5-6个服务，每个服务都可能丢包。
- 网络策略、负载均衡、Sidecar代理，每一层都可能引入问题。
我建议至少做到以下三点：
| 观测维度 | 工具/方法 | 说明 |
|---|---|---|
| 指标监控 | Prometheus + Node Exporter + cAdvisor | 看网络吞吐、丢包率、重传率 |
| 链路追踪 | Jaeger / Zipkin + Istio | 看请求经过哪些服务，每跳耗时 |
| 网络抓包 | kubectl exec + tcpdump / Cilium Hubble | 实时抓取Pod流量，分析问题 |
重点：可观测性不是事后诸葛亮，而是实时预警。我习惯在Prometheus里配一个告警规则：网络重传率超过5%就报警。这个规则帮我提前发现了好几次网卡故障。
1.4 我的个人经验总结
做了这么多年云原生网络，我最大的体会是：没有银弹。每个方案都有取舍，关键看你的场景。
- 小集群、低要求：Flannel + 简单NetworkPolicy，够用。
- 大集群、高性能：Cilium + eBPF，性能好，但学习成本高。
- 多租户、强隔离：Calico + 精细化网络策略，配合命名空间隔离。
- 全链路可观测：Istio + Kiali + Jaeger，但要注意Sidecar带来的额外延迟。
最后说一句：别把云原生网络想得太玄乎。它本质上还是网络，只是换了一种玩法。你只要理解了传统网络的那些原理（路由、交换、NAT、隧道），再学学K8s的CNI接口，就能上手。
下一章，我会带大家深入CNI插件的实现原理，手把手教你写一个简单的CNI插件。敬请期待。
课后思考：你的集群里，网络延迟主要来自哪里？是Overlay封装，还是iptables规则，还是应用层？建议用tcpdump抓个包看看，心里就有数了。