Kubernetes ——Calico网络插件

Calico网络插件

  Calico 是一个开源网络和网络安全解决方案，适用于容器、虚拟机和基于本地主机的工作负载。Calico 支持广泛的平台，包括 Kubernetes、OpenShift、Mirantis Kubernetes Engine (MKE)、OpenStack 和裸机服务。（官网翻译：https://projectcalico.docs.tigera.io/about/about-calico）

  无论您选择使用 Calico 的 eBPF 数据平面还是 Linux 的标准网络管道，Calico 都能提供超快的性能和真正的云原生可扩展性。Calico 为开发人员和集群运营商提供一致的体验和一组功能，无论是在公共云或本地、单个节点上还是跨数千个节点的集群上运行。（官网翻译：https://projectcalico.docs.tigera.io/about/about-calico）

  Calico本身是一个三层的虚拟网络方案，它将每个节点都当作路由器（router），将每个节点的容器都当作是“节点路由器”的一个终端并为其分配一个IP地址，各节点路由器通过BGP（Border Gateway Protocol）学习生成路由规则，从而将不同节点上的容器连接起来。因此，Calico方案其实是一个纯三层的解决方案，通过每个节点协议栈的三层（网络层）确保容器之间的连通性，这摆脱了flannel host-gw类型的所有节点必须位于同一二层网络的限制，从而极大地扩展了网络规模和网络边界。

一、Calico工作特性

  Calico 利用 Linux 内核在每一个计算节点上实现了一个高效的 vRouter（虚拟路由器）进行报文转发，而每个 vRouter(虚拟路由器) 都通过 BGP 负责把自身所属的节点上运行的 Pod 资源的 IP 地址信息基于节点的 agent 程序（Felix）直接由 vRouter 生成路由规则向整个 Calico 网络内进行传播。小规模部署可以直接互联，大规模建议使用 BPP 路由反射器（router reflector）来完成。Felix 也支持在每个节点上按需生成 ACL(Access Control List)从而实现安全策略，如隔离不同的租户或项目的网络通信。vRouter 利用 BGP 通告本节点上现有的地址分配信息，每个 vRouter 均接入 BGP 路由反射器以实现控制平面扩展。

  Calico承载的各Pod资源直接通过vRouter经由基础网络进行互联，它非叠加、无隧道、不使用VRF表，也不依赖于NAT，因此每个工作负载都可以直接配置使用公网IP接入互联网，当然，也可以按需使用网络策略控制它的网络连通性。

1.1）经过 IP 路由直连

  Calico 中，Pod 收发的 IP 报文由所在节点的 Linux 内核路由表负责转发，并通过 iptables 规则实现其安全功能。

  某 Pod 对象发送报文时，Calico 应确保节点总是作为下一跳 MAC 地址返回，不管工作负载本身可能配置什么路由，而发往某 Pod 对象的报文，其最后一个 IP 跃点就是 Pod 所在的节点。也就是说，报文的最后一程即由节点发网目标 Pod 对象，如下图所示：

  需为某 Pod 对象提供连接时，系统上的专用插件（如 Kubernetes 的 CNI）负责将需求通知给 Calico Agent。收到消息后，Calico Agent 会为每个工作负载添加直接路径信息到工作负载的 TAP 设备（如 veth）。而运行于当前节点的 BGP 客户端监控到此类消息后会调用路由 reflector 向工作于其他节点的 BGP 客户端进行通告。

1.2）简单、高效、易扩展

  Calico未使用额外的报文封装和解封装，从而简化了网络拓扑，这也是Calico高性能、易扩展的关键因素。毕竟，小的报文减少了报文分片的可能性，而且较少的封装和解封装操作也降低了对CPU的占用。此外，较少的封装也易于实现报文分析，易于进行故障排查。

  创建、移动或删除Pod对象时，相关路由信息的通告速度也是影响其扩展性的一个重要因素。Calico出色的扩展性缘于与互联网架构设计原则别无二致的方式，它们都使用了BGP作为控制平面。BGP以高效管理百万级的路由设备而闻名于世，Calico自然可以游刃有余地适配大型IDC网络规模。另外，由于Calico各工作负载使用基IP直接进行互联，因此它还支持多个跨地域的IDC之间进行协同。

1.3）较好的安全性

  原则上，Calico 网络允许 IDC 中的任何工作负载与其他任意目标进行通信，但管理员或用户却未必期望如此，在多租户 IDC 中隔离租户挽留过几乎是必需之需。于是，Calico 操纵节点上的 iptables 规则以管控工作负载的互联许可。此种 iptables 规则操纵功能是节点间的警戒哨，负责阻挡任何非许可流量，并防止通过工作负载危及自身。

• • 严格的域间流量分隔: 运行于某个租户虚拟网络内的应用应严禁访问其他租户的应用，这种流量分隔是由久经考验的 Linux 内核中的 ACL 子系统予以实现的。
  • 精细的策略规则: 实现了租户间隔离的网络方案大多并没有额外实现细粒度的安全策略，而 Calico 通过使用 Linux 内建的 ACL 扩展来支持一众安全规则，任何可由 ACL 支持的功能均能通过 Calico 实现。
  • 简洁而不简单: Calico 直接使用个 IP 网络，无须任何地址转换或隧道承载的机制实现了一个简洁的 "WYSIWYG"(what you see is what you get)网络模型，它可以清晰地标识出每个报文从哪儿来，到哪儿去。于是，管理员可因此而清晰地理解流量的来去。

二、Calico 系统架构

  概括来说，Calico 主要由 Felix、Orchestrator Plugin、etcd、BIRD 和 BGP Router Reflector 等组件组成，其组件架构如下图所示：

• • Felix: Calico Agen，运行于每个节点。主要负责网络接口管理和监听、路由、ARP 管理、ACL管理和同步、状态上报等。
  • Orchestrator Plugin: 编排系统（如 k8s、openstack等）以将 Calico 整合进系统中的插件，例如 k8s 的 CNI。
  • etcd：持久存储 Calico 数据的存储管理系统。分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性，可以与 Kubernetes 共用。
  • BIRD：用于分发路由信息的 BGP 客户端。Calico 可以为每一台节点部署一个 BGP Client，使用 BIRD 实现，BIRD 是一个单独的持续发展项目，实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 节点上由 Felix 注入的路由信息 ，然后通过 BGP 协议广播告诉剩余节点，从而实现网络互通。
  • BGP Route Reflector：BGP 路由反射器，可选组件，用于较大规模的网络场景。在大型网络规模中，如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制，因为所有节点之间俩俩互联，需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有 BGP Client 仅与特定 RR 节点互联并做路由同步，从而大大减少连接数。

2.1）Felix

  Felix 运行于各节点的用于支持端点（VM或Container）构建的守护进程，它负责生成路由和ACL，以及其他任何由节点用到的信息，从而为各端点构建连接机制。Felix在各编排系统中主要负责以下任务:

1. 1. 首先是接口管理（Interface Management）功能，负责为接口生成必要的信息并送往内核，以确保内核能够正确处理各端点的流量，尤其是要确保各节点能够响应目标MAC为当前节点上各工作负载的MAC地址的ARP请求，以及为其管理的接口打开转发功能。另外，它还要监控各接口的变动以确保规则能够得到正确的应用。
   2. 其次是路由规划（Route Programming）功能，其负责为当前节点运行的各端点在内核FIB（Forwarding Information Base）中生成路由信息，以保证到达当前节点的报文可正确转发给端点。
   3. 再次是ACL规划（ACL Programming）功能，负责在Linux内核中生成ACL，用于实现仅放行端点间的合法流量，并确保流量不能绕过Calico的安全措施。
   4. 最后是状态报告（State Reporting）功能，负责提供网络健康状态的相关数据，尤其是报告由其管理的节点上的错误和问题。这些报告数据会存储于etcd，供其他组件或网络管理员使用。

2.2）容器系统插件

  编排系统插件（Orchestrator Plugin）依赖于编排系统自身的实现，故此并不存在一个固定的插件以代表此组件。编排系统插件的主要功能是将Calico整合进系统中，并让管理员和用户能够使用Calico的网络功能。它主要负责完成API的转换和反馈输出。

  编排系统通常有其自身的网络管理API，网络插件需要负责将对这些API的调用转为Calico的数据模型并存储于Calico的存储系统中。如果有必要，网络插件还要将Calico系统的信息反馈给编排系统，如Felix的存活状态，网络发生错误时设定相应的端点为故障等。

2.3）etcd 存储系统

  Calico 使用 etcd 完成组件间的通信，并以之作为一个持久数据存储系统。根据编排系统的不同，etcd 所扮演角色的重要性也因之而异，但它贯穿了整个 Calico 部署全程，并被分为两类主机：

• • • 核心集群
    • 代理（proxy）

  在每个运行着 Felix 或编排系统插件的主机上都应该运行一个 etcd 代理以降低 etcd 集群和集群边缘节点的压力。此模式中，每个运行着插件的节点都会运行着 etcd 集群的一个成员节点。

  etcd 是一个分布式、强一致、具有容错功能的存储系统，这一点有助于将Calico网络实现为一个状态确切的系统：要么正常，要么发生故障。另外，分布式存储易于通过扩展应对访问压力的提升，而避免成为系统瓶颈。另外，etcd也是Calico各组件的通信总线，可用于确保让非etcd组件在键空间（keyspace）中监控某些特定的键，以确保它们能够看到所做的任何更改，从而使它们能够及时地响应这些更改。

2.4）BGP客户端（BIRD）

  Calico 要求在每个运行着 Felix 的节点上同时还要运行一个 BGP 客户端，负责将 Felix 生成的路由信息载入内核并通告到整个IDC。在 Calico 语境中，此组件是通用的 BIRD，因此任何 BGP 客户端（如GoBGP等）都可以从内核中提取路由并对其分发对于它们来说都适合的角色。

  BGP 客户端的核心功能就是路由分发，在 Felix 插入路由信息至内核 FIB 中时，BGP 客户端会捕获这些信息并将其分发至其他节点，从而确保了流量的高效路由。

2.5）BGP路由反射器（BIRD）

  在大规模的部署场景中，简易版的BGP客户端易于成为性能瓶颈，因为它要求每个BGP客户端都必须连接至其同一网络中的其他所有BGP客户端以传递路由信息，一个有着N个节点的部署环境中，其存在网络连接的数量为N的二次方，随着N值的逐渐增大，其连接复杂度会急剧上升。因而在较大规模的部署场景中，Calico应该选择部署一个BGP路由反射器，它是由BGP客户端连接的中心点，BGP的点到点通信也就因此转化为与中心点的单路通信模型。出于冗余之需，生产实践中应该部署多个BGP路由反射器。对于Calico来说，BGP客户端程序除了作为客户端使用之外，还可以配置成路由反射器。

 三、Calico 部署要点

  安装 Calico 需要事先有运行中的 Kubernetes 1.1 及以上版本的集群，如果要用到网络策略，则 Kubernetes 版本需要 1.3.0 及以上才可以。另外，还需要一个可由 Kubernetes 集群各节点访问到的 etcd 集群。虽然可以让 Calico 和 Kubernetes 共同使用一个 etcd 集群，然而有些场景中推荐为 etcd 使用集群，如需要获得较好的性能时：

  与 Kubernetes 集群进行整合时，Calico 需要提供三个组件，具体如下