k8s CNI Calico 网络模式总结

calico架构图

IPIP模式下的架构图

calico 核心组件

Overlay

网络模式：

Pod IP对外暴露

不对外暴露：

实现对外暴露的方法：

overlay模式下的网络MTU

Iptables & ipvs

overlay的主要缺点：

Full-mesh

Unoverlay

Reflect route （Full-mesh + RR）

TOR （禁用Full-mesh）

underlay

calico架构图

下图显示了 Kubernetes、具有网络和网络策略的本地部署所需和可选的 Calico 组件。

组件名称	功能
Felix	将其主机上的端点路由到 Linux 内核 FIB（转发信息库）中对路由和 ACL 以及主机上所需的任何其他内容进行编程，以便为该主机上的端点提供所需的连接
BIRD	从 Felix 获取路由并分发给网络上的 BGP 对等体，以实现主机间路由。在托管 Felix 代理的每个节点上运行
Confd	监视 Calico 数据存储中 BGP 配置和全局默认值（例如 AS 编号、日志记录级别和 IPAM 信息）的更改。
Typha	通过减少每个节点对数据存储的影响来增加规模。作为数据存储和 Felix 实例之间的守护进程运行。由于一个 Typha 实例可以支持数百个 Felix 实例，因此它大大减少了数据存储上的负载。由于Typha可以过滤掉与Felix无关的更新，因此也减少了Felix的CPU使用率。在大规模（100+节点）Kubernetes集群中，这是至关重要的，因为API服务器生成的更新数量随着节点数量的增加而变化。备注： etcd v3 已经针对处理许多客户端进行了优化，因此使用它是多余的，不建议使用。操作员安装始终安装 Typha。

总结：在一些小型网络或简单网络拓扑中，IPIP 可能具有更好的性能和简单性；而在大规模网络或需要多租户支持和网络隔离的环境中，VXLAN 则可能更适合。

优点：

避免出站连接的 SNAT 对于集成现有的更广泛的安全要求可能至关重要。它还可以简化调试和操作日志的理解。
如果您有专门的工作负载，这意味着需要直接访问某些 pod，而无需通过 Kubernetes 服务或 Kubernetes 入口，那么可路由 pod IP 在操作上可能比使用主机联网 pod 的替代方案更简单。

缺点：

优点：

Kubernetes 将使用一种称为 SNAT（源网络地址转换）的技术来更改源 IP地址从 Pod 的 IP 地址到托管 Pod 的节点的 IP 地址。连接上的任何返回数据包都会自动映射回 pod IP 地址。因此，Pod 不知道 SNAT 正在发生，连接的目的地将该节点视为连接的源，而底层更广泛的网络永远不会看到 Pod IP 地址。安全
只能通过 Kubernetes 服务或 Kubernetes 入口来完成。集群外部的任何内容都无法直接连接到 Pod IP 地址，因为更广泛的网络不知道如何将数据包路由到 Pod IP 地址

IP in IP 使用 20 字节标头，IPv4 VXLAN 使用 50 字节标头，IPv6 VXLAN 使用 70 字节标头，IPv4 WireGuard 使用60 字节标头，IPv6 WireGuard 使用 80 字节标头

如果您要扩展超过 1,000 个服务，则值得考虑使用 kube-proxy IPVS 模式潜在的性能改进。Comparing kube-proxy modes: iptables or IPVS?

对性能有轻微影响。封装数据包的过程需要占用少量 CPU，并且数据包中需要额外的字节来对封装进行编码（VXLAN 或 IP-in-IP header），从而减少了可发送的内部数据包的最大大小，从而可以减少内部数据包的大小。意味着需要为相同数量的总数据发送更多数据包。
Pod IP 地址在集群外部不可路由