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.2. 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.3. 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：

• Calico API server：
  支持通过kubectl管理Calico资源。

• Felix：
  以守护进程的方式运行在集群的每个节点上，主要提供四个关键能力：接口管理（Interface management）、编程式路由（Route programming），编程式权限（ACL programming），状态报告（State reporting）。

• BIRD：
  从Felix获取路由并分发给网络上的BGP对端，用于主机间路由。与Felix一样都是运行在集群的每个节点。主要提供两个关键能力：路由分发（Route distribution）、路由映射配置（BGP route reflector configuration）

• Confd：
  开源、轻量级的配置管理工具，存储BGP配置和全局默认值，监听数据变化动态生成BIRD配置文件，会触发BIRD重新加载配置信息。

• CNI plugin：
  为Kubernetes集群提供Calico网络能力。

• IPAM plugin：
  是Calico CNI插件之一，使用Calico的IP池资源，来控制IP地址分配给集群内的Pod。

• kube-controllers：
  Kubernetes的控制器，包含Policy controller、Namespace controller、Serviceaccount controller、Workloadendpoint controller、Node controller。

• calicoctl：
  创建、读取、更新和删除Calico对象的命令行界面。

• Datastore plugin：
  通过减少每个节点对数据存储的影响来增加规模，是Calico CNI插件之一。

• Typha：
  通过减少每个节点对数据存储的影响来扩大规模。在数据存储和Felix实例之间作为守护进程运行。

• Dikastes：
  增强Istio服务网格的网络策略，作为Istio Envoy的sidecar代理方式运行。

1.4. 总结

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

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