网络
以前在x信的时候，经常跟小伙伴说要每年至少要出去面试一次，这样可以有效的避免自己困在信息茧房中。这次就面了一个x云的架构师，他们更关注的就是网络，数据库，大数据这些。
于是就碰到了几个比较的问题，我自己也没深入思考过，毕竟这些东西都是平时云厂商给我们做好的。
overlay网络和underlayer网络各自是什么意思？
这个其实有点蒙啊，很少听到这么说的，只听说过存储上有overlay的说法。
于是我又自己查了下，原来underlayer一般就是指物理网络，比如以太网，光纤网络，mpls网络。但是mpls网络我一直以为不算的。于是认真研究了一下mpls。考完ccna也都20多年了，这块内容确实要更新下了。
传统网络我们都是路由表来进行转发的。大部分联网的设备都是有路由表的。比如我现在这个itx电脑。
可以很容易发现我这个网络很简单，就是一条，发给除了10.1.1.0/24网段以外的数据都是走10.1.1.1 这个网关。比如我要去到1.1.1.1 这个地址。traceroute看一下就可以看到当中经过很多hop，但是第一跳就是itx的网关10.1.1.1。在路由协议里比如静态路由，rip, ospf等等这些都是通过线路本身权重和ip地址等等方式来进行路由的。但是这种方式最大的问题点就是性能，在一些核心网络的路由器上，可能会有成千上万条路由记录，那这个就是会很影响性能。
但是mpls的网络是基于标签的，虽然也是使用路由协议，但建立的是标签转发信息库（LFIB）。标签路径由入口路由器决定，后续只需按标签转发，这样的话可以保证路径可靠，当然mpls本身标签转发肯定也是有冗余的，不然就会有单点故障。而传统的网络路由转发是当中每一个路由设备来决定的（下一跳）。
不过mpls的主要优势并不是这些，而是QoS支持的比较好，同时原生支持 MPLS L3VPN 和 L2VPN，就这两点导致一些高网络要求场景下会使用mpls.
那overlay就是基于这种物理网络之上的上层网络。这种网络主要是因为虚拟机和容器化产生的。不然的话我们迁移虚拟机，或者迁移容器实例，那对应的ip可能都会变了。
这个我们在云上会感触很深，在同一个az中迁移虚拟机，它的ip和mac地址都是不会变的。但是如果是跨az迁移的话，因为我们网段是根据az建立的，所以ip地址肯定会变的，不然你这个ip都无法出新的网关。但是mac地址是可以不变的。
这里面不得不提VxLan技术了，解决“跨三层网络构建二层虚拟网段”的问题。根据RFC 7348指引，它本质上是用udp封装mac地址的协议。但是本质上对于云厂商来说VxLan还是为了解决4k vlan不够用的问题。同时虚拟机迁移后保证mac地址继续不变。
而且这个现在各家交换机厂商也都支持了，顺便查到现在这种云机房的交换机的部署架构都是Spine-Leaf的方式。Leaf就是每个机柜的交换机，它会上挂到所有的Spine，而Spine就类似我们原先的核心交换机，只负责 Leaf↔Leaf 转发，不挂任何终端。虽然看上去跟原先的核心交换没有区别，其实还是有区别的，比如以前如果核心交换接口满了，那我们只能找一个更多口的核心交换替换，或者核心交换上面再加一层核核心交换。而Spine-Leaf就是横向扩容就行。这样任何两台服务器互相访问：Leaf → Spine → Leaf。
但是Spine-Leaf都是3层转发的，所以需要2层的隔离就需要使用VxLan了。
当然overlay的协议里不光有VxLan,还有Geneve，这个是兼容了VxLan等其他协议，但是对应支持的设备还不也是很普及，VxLan一般都是支持的，毕竟出来都是10多年的东西了。
说说k8s里各种cni的区别
cni就是容器网络接口的缩写。
下面这个是kimi给整理的几种cni的区别
| 维度 | Cilium | Calico | Flannel | Weave | Kube-OVN |
|---|---|---|---|---|---|
| 核心技术 | eBPF 内核态转发（eBPF） | BGP/VXLAN/IPIP（路由） | VXLAN(host-gw)（overlay） | 自定义 UDP/FastDP（overlay） | OVN逻辑交换/路由，L2/L3/L4一体 |
| 网络策略 | L3-L7 全栈（HTTP/DNS/SNI） | 原生K8s NetworkPolicy + 全局策略 | 本身无，需再装Calico策略引擎 | 支持，但规则丰富度<Calico | 原生，且支持子网级ACL、QoS |
| 转发性能 | 9.2 Gbps/0.3 ms/1.2 Mpps | 9 Gbps/1.2 ms 裸金属BGP近线速；VXLAN模式≈Flannel | 7.5 Gbps/2.3 ms | 7.8 Gbps/2.1 ms | 5.8 ms(→8.9 Gbps with DPDK) 接近Calico BGP，DPDK版本可40 Gbps |
| 资源占用 | CPU 1.2 % / 45 MB | 2.8 % / 85 MB | 3.5 % / 120 MB | 4.2 % / 150 MB | 更高(需 OVS+OVN) |
| 加密 | WireGuard（透明 + 低损耗） | IPsec/WireGuard | ❌ | IPsec（默认） | IPsec |
| 可观测性 | Hubble 实时 L7 拓扑、零开销 | 基础流日志 | ❌ | 拓扑图 | 流表计数 |
| 多集群 | ClusterMesh 原生 | BGP RR/手工 | ❌ | ❌ | EVPN |
| 规模 | 5 k+ 节点无集中瓶颈 | 5 k+ | ≤1 k | ≤1 k | 2 k+（需分片 OVN） |
| 运维门槛 | 内核 5.4+、懂 eBPF | 中等 | 极简 | 低 | 高（要懂 OVS/OVN） |
| 组件 | 需要etcd | 需要K8s CRD | 需要额外DB | 需要内核模块 | 需要用户态守护 | 离线机房备注 |
|---|---|---|---|---|---|---|
| Flannel | ❌ | ✅(Node/Lease) | ❌ | vxlan,wireguard(可选) | flanneld | 只要apiserver通就能跑；无apiserver则无法工作 |
| Calico | ✅或❌(可选K8s-datastore) | ✅(KDD模式) | ❌(BGP模式无DB) | iptables/ipset/bpf(可选) | calico-node/calico-cni | 可切“KDD=off”用etcd，也可全走K8s-CRD；离线场景建议自带etcd |
| Weave | ❌ | ✅(IPAM-lease) | ❌ | weave内核模块(自动编译) | weave-router | 完全gossip，不依赖etcd；但启动时要list-node，所以apiserver必须在线 |
| Kube-OVN | ✅(必须) | ✅ | ovn-nb/sb DB(北向/南向) | openvswitch内核 | ovn-controller/ovs-vswitchd | 必须自备etcd+ovn-db；离线机房需提前起3个容器 |
| Cilium | ✅或❌(可选K8s-CRD) | ✅ | ❌(CRD模式) | eBPF(kprobe,tc) | cilium-agent | 同Calico：可纯CRD，也可外挂etcd；离线推荐自带etcd |
下面这个是deepseek给总结的几种cni的区别
| 特性 | Cilium | Calico | Flannel | Weave | Kube-OVN |
|---|---|---|---|---|---|
| 网络模型 | 基于eBPF的覆盖/路由网络 | BGP路由/覆盖网络 | VXLAN覆盖网络 | VXLAN覆盖网络 | OVN虚拟网络 |
| 安全策略 | 基于eBPF的L3-L7策略 | 基于iptables/BPF的L3-L4策略 | 无内置策略 | 基本加密 | 基于OVN ACL的L2-L4策略 |
| 性能 | 极高(eBPF绕过内核协议栈) | 高(路由直连) | 中等 | 中等 | 中等 |
| 可观测性 | 丰富的可观测性(Hubble) | 基本指标 | 基本 | 基本 | 集成监控 |
| 服务发现 | 内置K8s服务替换kube-proxy | 依赖kube-proxy | 依赖kube-proxy | 依赖kube-proxy | 内置L2/L3/LB |
通过这些对比，我们可以看到基本上cilium是未来趋势，但是有内核版本要求。calico是现在主流生产环境用的，flannel这个就可以自己玩玩的。
那首先我们需要知道为什么需要有cni。按照k8s的说法主要是这些情况：
https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/
- 高度耦合的容器间通信：这个已经被 Pod 和
localhost通信解决了。 - Pod 间通信：这是本文档讲述的重点。
- Pod 与 Service 间通信：涵盖在 Service 中。
- 外部与 Service 间通信：也涵盖在 Service 中。
不过这里主要是以pod之间通信为主了。
完整的列表可以参考：https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons/#networking-and-network-policy 这个列表里居然还有阿里云的terway。阿里云的这个跟阿里云绑定的非常深，但是性能非常好，没有什么隧道这些东西，我司都是用的terway而不是其他的，早期开的网段都是/16这样大的，最后网段都快不够用了，后来为了迁移就做了很多的网段调整。
Calico使用bgp路由协议，那意味着使用calico的话，整个k8s集群内部就是一个单独的as自治域， 同时bgp网络会有eBGP和iBGP。eBGP存放的是对外的网络信息，但是bgp网络是需要有asn的，这个calico默认有一个64512, 但是只能内部使用，如果对外使用，或者2个集群互相通信，那就需要拆分开来。当然不用担心这个asn广播出去，这个定义的时候就是一个private asn。这个在https://datatracker.ietf.org/doc/html/rfc6996 已经定义了64512 - 65534和4200000000 - 4294967294 都是private asn，足够大家用的。
关于通信流程我还得再学习才能写，一个是ip和pod的关系映射，以及各种安全策略和ip转换或路由的问题。