Kubernetes网络插件详解 - Calico篇 - 概述

1. 1. 容器网络及策略

Kubernetes本身并没有自己实现容器网络，而是借助CNI标准，通过插件化的方式来集成各种网络插件，实现集群内部网络相互通信。任何人都可以编写CNI插件，只要实现CNI标准中定义的核心接口操作（ADD，将容器添加到网络；DEL，从网络中删除一个容器；CHECK，检查容器的网络是否符合预期等）。CNI插件通常聚焦在容器到容器的网络通信，Kubernetes构造的Services网络服务仍然是由kube-proxy处理，通过主机的IPtables确定Service后端的Pod服务，通过CNI插件将网络报文转发到目标Pod，如下图所示：

CNI的接口并不是指HTTP，gRPC这种接口，CNI接口是指对可执行程序的调用（exec）可执行程序，Kubernetes节点默认的CNI插件路径为/opt/cni/bin。

CNI通过JSON格式的配置文件来描述网络配置，当需要设置容器网络时，由容器运行时负责执行CNI插件，并通过CNI插件的标准输入（stdin）来传递配置文件信息，通过标准输出（stdout）接收插件的执行结果。从网络插件功能可以分为五类：

• Main插件，创建具体网络设备（bridge：网桥设备，连接container和host；ipvlan：为容器增加ipvlan网卡；loopback：IO设备；macvlan：为容器创建一个MAC地址；ptp：创建一对Veth Pair；vlan：分配一个vlan设备；host-device：将已存在的设备移入容器内）。
• IPAM插件：负责分配IP地址（dhcp：容器向DHCP服务器发起请求，给Pod发放或回收IP地址；host-local：使用预先配置的IP地址段来进行分配；static：为容器分配一个静态IPv4/IPv6地址，主要用于debug）。
• META插件：其他功能的插件（tuning：通过sysctl调整网络设备参数；portmap：通过iptables配置端口映射；bandwidth：使用Token Bucket Filter来限流；sbr：为网卡设置source based routing；firewall：通过iptables给容器网络的进出流量进行限制）。
• Windows插件：专门用于Windows平台的CNI插件（win-bridge与win-overlay网络插件）
• 第三方网络插件：第三方开源的网络插件众多，每个组件都有各自的优点及适应的场景，难以形成统一的标准组件，常用有Flannel、Calico、Cilium、OVN网络插件。

大部分的CNI插件功能设计上遵守功能职责单一原则，比如Bridge插件负责网桥的相关配置，Firewall插件负责防火墙相关配置，Portmap插件负责端口映射相关配置。因此，当网络设置比较复杂时，通常通过调用多个插件来完成。CNI通过链式调（NetworkConfigList）用多个插件，将多个插件组合起来按顺序调用，比如前面文章提到的Flannel网络插件CNI插件配置POD网络时的链式调用。

 

Kubernetes底层是通过Linux的Cgroup与Namesapce来实现底层基础资源隔离，每个命名空间（namespace）都有自己网络堆栈，包括接口、路由表、套接字和 IPTABLE 规则等。一个接口只能属于一个网络命名空间，这样多个容器就需要多个接口，一般情况是通过虚拟化技术来实现硬件资源共享，通过将虚拟化设备连接到真实的物理设备上，具体分为三种实现：

• 虚拟网桥（Virtual bridge）：创建一个虚拟网卡对（veth pair），一端在容器内一头端宿主机的root namespace内，并且使用Linux bridge（网桥）或者OpenvSwitch（OVS）来连接两个不同namespace内的网卡对。这样一来，容器内发出的网络数据包，可以通过网桥进入宿主机网络栈，而发往容器的网络数据包也可以经过网桥进入容器。
• 多路复用（Multiplexing）：使用一个中间网络设备，暴露多个虚拟网卡接口，容器网卡都可以接入这个中间设备，并通过mac地址/IP地址来区分packet应该转发给具体的容器设备。
• 硬件交换（Hardware switching）：为每个Pod分配一个虚拟网卡，这样一来Pod与Pod之间的连接关系就会变的非常清晰，因为近乎物理机之间的通信基础。如今大多数网卡都支持SR-IOV功能，该功能将单一的物理网卡虚拟成多个VF接口，每个VF接口都有单独的虚拟PCIe通道，这些虚拟的PCIe通道共用物理网卡的PCIe通道。

 

对于Kubernetes网络，网络策略也是非常重要的能力；网络策略能力比较依赖CNI插件的具体实现，比如Flannel插件，根本不执行策略；但大多数插件都会强制执行策略，为Pod的入口流量和Pod的出口流量设置策略，Kubernetes网络策略是属于命名空间范围的。

1. 1. Calico容器网络插件 

Calico是Tigera开源，基于Apache 2.0协议的网络与网络安全解决方案，适用于容器、虚拟机、以及物理机等场景。Calico支持包含Kubernetes、OpenShift以及OpenStack等主流平台。在Kubernetes云原生容器网络方面，Calico完全遵循CNI的标准，Flannel的简单成为初始用户的首选，Calico则是以性能及灵活性成为另一个不错的选择。当前Flannel与Calico两大插件占据容器网络插件90%以上的份额。相比Flannel插件，Calico的功能更为全面，不仅提供主机和Pod之间的网络连接，还涉及网络安全和管理。从Calico 3.x版本开始，Calico默认的模式从BGP调整为IPIP，一种更加高效的Overlay模式。Calico特点如下：

• 高效的可视化管理：Calico提供完善的可视化管理，包括原生Linux eBPF管理、标准Linux 网络管理、以及Windows HNS管理。Calico通过将基础网络、网络策略和IP地址等功能抽象统一，提供简单易用且操作一致的管理平面。
• 网络安全策略：Calico提供丰富的网络策略模型，可以轻松的实现网络流量治理，同时结合内置的Wireguard加密功能，可以快速实现Pod间的数据传输。还有Calico策略引擎可以在主机网络及服务网络执行相同的策略模型，实现基础设施与上层服务的网络数据风险隔离。
• 高性能及可扩展性：Calico采用前沿的eBPF技术，以及深度调优操作系统内核网络管道，以此来提高网络性能。Calico支持网络配置较多，大部分场景可以不使用Overlay，避免数据包封装/解封的大开销操作。同时Calico遵守云原生设计模式，底层都是采用标准的网络协议，具备出色可扩展性。
• 大规模生产运行实践：Calico有大规模生产环境运行实践，包括SaaS提供商、金融服务公司和制造商；在公有云方面，包含Amazon EKS、Azure AKS、Google GKE 和 IBM IKS，都有集成开箱即用的Calico网络安全能力。
  1. Calico核心组件

Calico灵活的网络模块化架构，包括CNI网络插件，CNI IPAM插件，网络模式，网络策略四个方面：

• CNI网络插件：Calico CNI网络插件通过一对虚拟以太网设备（vethpair），将Pod连接到主机网络命名空间的三层路由上，避免了许多其他Kubernetes网络解决方案中的二层网桥的性能开销。
• CNI IPAM插件：Calico CNI IPAM插件从一个或多个可配置的IP地址范围内为Pod分配IP地址，并根据需要为每个节点动态分配小块IP。与其他CNI IPAM插件相比，Calico CNI IPAM插的IP地址空间使用效率更高。
• 网络模式：Calico支持的网络模式分为Overlay与Non-overlay两种：Overlay模式，Calico提供VXLAN或IP-in-IP网络模式，包括限制跨子网模式（cross-subnet）。Non-overlay模式，Calico提供在L2网络或L3网络之上运行的Non-overlay网络。
• 网络策略：Calico的网络策略执行引擎实现了Kubernetes网络策略的全部功能，并且增加额外的扩展功能。

Calico最优先的网络设置是使用BGP与物理网络对等的Non-overlay网络模式，实现Pod IP可在集群外部路由。如果无法将BGP对等连接到物理网络，但集群位于独立的L2网络中，也可以运行Non-overlay模式，只是在集群中的节点之间对等BGP，应用外部缺少Pod IP的路由，无法在集群外路由。或者设置为Overlay模式下的VXLAN或IP-in-IP，并使用跨子网Overlay模式来优化L2子网内的性能。

上图是一个完整Calico网络及策略架构图，包含了必须与可选的所有组件，包含Calico API server、Felix、BIRD、confd、Dikastes、CNI plugin、Datastore plugin、IPAM plugin、kube-controllers、Typha、calicoctl：

1. Calico API server：支持通过kubectl管理Calico资源。
2. Felix：以守护进程的方式运行在集群的每个节点上，主要提供四个关键能力：接口管理（Interface management）、编程式路由（Route programming），编程式权限（ACL programming），状态报告（State reporting）。
3. BIRD：从Felix获取路由并分发给网络上的BGP对端，用于主机间路由。与Felix一样都是运行在集群的每个节点。主要提供两个关键能力：路由分发（Route distribution）、路由映射配置（BGP route reflector configuration）
4. Confd：开源、轻量级的配置管理工具，存储BGP配置和全局默认值，监听数据变化动态生成BIRD配置文件，会触发BIRD重新加载配置信息。
5. CNI plugin：为 Kubernetes集群提供Calico网络能力。
6. IPAM plugin：是Calico CNI插件之一，使用Calico的IP池资源，来控制IP地址分配给集群内的Pod。
7. kube-controllers：Kubernetes的控制器，包含Policy controller、Namespace controller、Serviceaccount controller、Workloadendpoint controller、Node controller。
8. calicoctl：创建、读取、更新和删除Calico对象的命令行界面。
9. Datastore plugin：通过减少每个节点对数据存储的影响来增加规模，是Calico CNI插件之一。
10. Typha：通过减少每个节点对数据存储的影响来扩大规模。 在数据存储和Felix实例之间作为守护进程运行。
11. Dikastes：增强Istio服务网格的网络策略，作为Istio Envoy的sidecar代理方式运行。
    1. 总结

Kubernetes容器网络比较复杂，需要与底层基础设施及上层业务来确定容器网络方案，同时很多网络插件又支持多种模式，需要大量的网络的基础知识支撑才能了解清楚。选择合适的CNI插件，需要综合考虑底层网络网络拓扑，结合应用需要的网络功能，以及网络路由协议的需求。Calico是比较成熟的容器网络插件，功能上比较丰富，性能上也在不断优化。所以将Calico网络插件规划成一系列文章，从网络网络基础，Calico架构原理，到Calico实战操作总共八篇，抽丝剥茧，将Calico网络插件做深入的理解，从而彻底掌握容器网络相关知识。

 

关注“巨子嘉”，巨子出品，必属精品