关于云计算:Cilium-111-发布带来内核级服务网格拓扑感知路由

原文链接：https://isovalent.com/blog/po…

作者：Cilium 母公司 Isovalent 团队
译者：范彬，狄卫华，米开朗基杨

注：本文已获得作者自己的翻译受权！

Cilium 我的项目已逐步成为万众瞩目之星，咱们很骄傲可能成为该项目标外围人员。几天前，咱们公布了具备诸多新性能的 Cilium 1.11 版本，这是一个令人兴奋的版本。诸多新性能中也包含了万众期待的 Cilium Service Mesh 的 Beta 版本。在本篇文章中，咱们将深入探讨其中的局部新性能。

Service Mesh 测试版本（Beta）

在探讨 1.11 版本之前，让咱们先理解一下 Cilium 社区发表的 Service Mesh 的新性能。

• 基于 eBPF 技术的 Service Mesh（Beta）版本：定义了新的服务网格能力，这包含 L7 流量治理和负载平衡、TLS 终止、金丝雀公布、追踪等诸多能力。
• 集成了 Kubernetes Ingress (Beta) 性能：通过将 eBPF 和 Envoy 的强势联结，实现了对 Kubernetes Ingress 的反对。

Cilium 网站的一篇文章具体介绍了 Service Mesh Beta 版本，其中也包含了如何参加到该性能的开发。以后，这些 Beta 性能是 Cilium 我的项目中的一部分，在独自分支进行开发，可独立进行测试、反馈和批改，咱们期待在 2022 年初 Cilium 1.12 版本公布之前合入到 Cilium 主分支。

Cilium 1.11

Cilium 1.11 版本包含了 Kubernetes 额定性能，及独立部署的负载均衡器。

• OpenTelemetry 反对：Hubble L3-L7 可观测性数据反对 OpenTelemetry 跟踪和度量（Metrics）格局的导出。(更多详情)
• Kubernetes APIServer 策略匹配：新的策略实体用于简略不便地创立进出 Kubernetes API Server 流量的策略模型。(更多详情)
• 拓扑感知的路由：加强负载平衡能力，基于拓扑感知将流量路由到最近的端点，或放弃在同一个地区（Region）内。(更多详情)
• BGP 宣告 Pod CIDR：应用 BGP 在网络中宣告 Pod CIDR 的 IP 路由。（更多详情)
• 服务后端流量的优雅终止：反对优雅的连贯终止，通过负载平衡向终止的 Pod 发送的流量能够失常解决后终止。(更多详情)
• 主机防火墙稳定版：主机防火墙性能已降级为生产可用的稳固版本。（更多详情）
• 进步负载均衡器扩展性：Cilium 负载平衡反对超过 64K 的后端端点。(更多详情)
• 进步负载均衡器设施反对：负载平衡的减速 XDP 疾速门路当初反对 bond 设施（更多详情) 同时，可更广泛地用于多设施设置。(更多详情)。
• Kube-Proxy-replacement 反对 istio：Cilium 的 kube-proxy 代替模式与 Istio sidecar 部署模式兼容。(更多详情)
• Egress 进口网关的优化：Egress 网关能力加强，反对其余数据门路模式。(更多详情)
• 托管 IPv4/IPv6 街坊发现：对 Linux 内核和 Cilium 负载均衡器进行了扩大，删除了其外部 ARP 库，将 IPv4 的下一跳发现以及当初的 IPv6 节点委托给内核治理。(更多详情)
• 基于路由的设施检测：内部网络设备基于路由的自动检测，以进步 Cilium 多设施设置的用户体验。(更多详情)
• Kubernetes Cgroup 加强：在 cgroup v2 模式下集成了 Cilium 的 kube-proxy-replacement 性能，同时，对 cgroup v1/v2 混合模式下的 Linux 内核进行了加强。(更多详情)
• Cilium Endpoint Slices：Cilium 基于 CRD 模式可能更加高效地与 Kubernetes 的管制立体交互，并且不须要专有 ETCD 实例，节点也可扩大到 1000+。(更多详情)
• 集成 Mirantis Kubernetes 引擎：反对 Mirantis Kubernetes 引擎。(更多详情)

什么是 Cilium？

Cilium 是一个开源软件，为基于 Kubernetes 的 Linux 容器治理平台上部署的服务，通明地提供服务间的网络和 API 连贯及平安。

Cilium 底层是基于 Linux 内核的新技术 eBPF，能够在 Linux 零碎中动静注入弱小的安全性、可见性和网络管制逻辑。Cilium 基于 eBPF 提供了多集群路由、代替 kube-proxy 实现负载平衡、通明加密以及网络和服务平安等诸多性能。除了提供传统的网络安全之外，eBPF 的灵活性还反对利用协定和 DNS 申请 / 响应平安。同时，Cilium 与 Envoy 严密集成，提供了基于 Go 的扩大框架。因为 eBPF 运行在 Linux 内核中，所以利用所有 Cilium 性能，无需对利用程序代码或容器配置进行任何更改。

请参阅 [Cilium 简介] 局部，理解 Cilium 更具体的介绍。

OpenTelemetry 反对

新版本减少了对 OpenTelemetry 的反对。

OpenTelemetry 是一个 CNCF 我的项目，定义了遥测协定和数据格式，涵盖了分布式跟踪、指标和日志。该我的项目提供了 SDK 和运行在 Kubernetes 上的收集器。通常，应用程序间接检测裸露 OpenTelemetry 数据，这种检测最常应用 OpenTelemetry SDK 在应用程序内实现。OpenTelemetry 收集器用于从集群中的各种应用程序收集数据，并将其发送到一个或多个后端。CNCF 我的项目 Jaeger 是可用于存储和出现跟踪数据的后端之一。

反对 OpenTelemetry 的 Hubble 适配器是一个附加组件，能够部署到运行 Cilium 的集群上（Cilium 版本最好是 1.11，当然也应该实用于旧版本）。该适配器是一个嵌入了 Hubble 接收器的 OpenTelemetry 收集器，咱们举荐应用 OpenTelemetry Operator 进行部署（详见用户指南）。Hubble 适配器从 Hubble 读取流量数据，并将其转换为跟踪和日志数据。

Hubble 适配器增加到反对 OpenTelemetry 的集群中，可对网络事件和利用级别遥测提供有价值的可观测性。以后版本通过 OpenTelemetry SDK 提供了 HTTP 流量和 spans 的关联。

感知拓扑的负载平衡

Kubernetes 集群在跨多数据中心或可用区部署是很常见的。这不仅带来了高可用性益处，而且也带来了一些操作上的复杂性。

目前为止，Kubernetes 还没有一个内置的构造，能够基于拓扑级别形容 Kubernetes service 端点的地位。这意味着，Kubernetes 节点基于服务负载平衡决策抉择的 service 端点，可能与申请服务的客户在不同的可用区。这种场景下会带来诸多副作用，可能是云服务费用减少，通常因为流量逾越多个可用区，云提供商会额定收取费用，或申请提早减少。更宽泛地说，咱们须要依据拓扑构造定义 service 端点的地位，例如，服务流量应该在同一节点（node）、同一机架（rack）、同一故障分区（zone）、同一故障地区（region）、同云提供商的端点之间进行负载平衡。

Kubernetes v1.21 引入了一个称为拓扑感知路由的性能来解决这个限度。通过将 service.kubernetes.io/topology-aware-hints 注解被设置为 auto，在 service 的 EndpointSlice 对象中设置端点提醒，提醒端点运行的分区。分区名从节点的 topology.kubernetes.io/zone 标签获取。如果两个节点的分区标签值雷同，则被认为处于同一拓扑级别。

该提醒会被 Cilium 的 kube-proxy 代替来解决，并会依据 EndpointSlice 控制器设置的提醒来过滤路由的端点，让负载均衡器优先选择同一分区的端点。

该 Kubernetes 性能目前处于 Alpha 阶段，因而须要应用 –feature-gate 启用。更多信息请参考官网文档。

Kubernetes APIServer 策略匹配

托管 Kubernetes 环境，如 GKE、EKS 和 AKS 上，kube-apiserver 的 IP 地址是不通明的。在以前的 Cilium 版本中，没有提供正规的形式来编写 Cilium 网络策略，定义对 kube-apiserver 的访问控制。这波及一些实现细节，如：Cilium 平安身份调配，kube-apiserver 是部署在集群内，还是部署在集群外。

为了解决这个问题，Cilium 1.11 减少了新性能，为用户提供一种办法，容许应用专用策略对象定义进出 apiserver 流量的访问控制。该性能的底层是实体选择器，可能解析预留的 kube-apiserver 标签含意，并可主动利用在与 kube-apiserver 关联的 IP 地址上。

平安团队将对这个新性能特地感兴趣，因为它提供了一个简略的办法来定义对 pod 的 Cilium 网络策略，容许或禁止拜访 kube-apiserver。上面 CiliumNetworkPolicy 策略片段定义了 kube-system 命名空间内的所有 Cilium 端点容许拜访 kube-apiserver，除此之外的所有 Cilium 端点禁止拜访 kube-apiserver。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-to-apiserver
  namespace: kube-system
spec:
  endpointSelector: {}
  egress:
  - toEntities:
    - kube-apiserver

BGP 宣告 Pod CIDR

随着公有 Kubernetes 环境的日益关注，咱们心愿与现存的数据中心网络基础设施很好地集成，它们通常是基于 BGP 协定进行路由散发的。在上一个版本中，Cilium agent 曾经开始集成了 BGP 协定, 能够通过 BGP 向 BGP 路由器公布负载均衡器的 service 的 VIP。

当初，Cilium 1.11 版本还引入了通过 BGP 宣告 Kubernetes Pod 子网的能力。Cilium 可与任何上游互联的 BGP 基础设施创立一个 BGP 对等体，并通告调配的 Pod IP 地址的子网。这样上游基础设施就能够依照适合形式来散发这些路由，以使数据中心可能通过各种公有 / 公共下一跳路由到 Pod 子网。

要开始应用此性能，运行 Cilium 的 Kubernetes 节点须要读取 BGP 的 ConfigMap 设置：

apiVersion: v1
kind: ConfigMap
metadata:
  name: bgp-config
  namespace: kube-system
data:
  config.yaml: |
    peers:
      - peer-address: 192.168.1.11
        peer-asn: 64512
        my-asn: 64512

同时，Cilium 应该应用以下参数进行装置：

$ cilium install \
    --config="bgp-announce-pod-cidr=true"

Cilium 装置完后，它将会向 BGP 路由器公布 Pod CIDR 范畴，即 192.168.1.11。

上面是最近的 Cilium eCHO episode 残缺演示视频。

• https://www.youtube.com/watch…

如果想理解更多，如：如何为 Kubernetes service 配置 LoadBalancer IP 宣告，如何通过 BGP 公布节点的 Pod CIDR 范畴，请参见 docs.cilium.io。

托管 IPv4/IPv6 街坊发现

当 Cilium 启用 eBPF 代替 kube-proxy 时，Cilium 会执行集群节点的街坊发现，以收集网络中间接街坊或下一跳的 L2 地址。这是服务负载平衡所必须的，eXpress Data Path (XDP) 疾速门路反对每秒数百万数据包的牢靠高流量速率。在这种模式下，在技术上按需动静解析是不可能的，因为它须要期待相邻的后端被解析。

在 Cilium 1.10 及更早版本中，cilium agent 自身蕴含一个 ARP 解析库，其控制器触发发现和定期刷新新增集群节点。手动解析的街坊条目被推送到内核并刷新为 PERMANENT 条目，eBPF 负载均衡器检索这些条目，将流量定向到后端。cilium agent 的 ARP 解析库不足对 IPv6 街坊解析反对，并且，PERMANENT 街坊条目还有许多问题：举个例子，条目可能变得古老，内核回绝学习地址更新，因为它们实质上是动态的，在某些状况下导致数据包在节点间被抛弃。此外，将街坊解析严密耦合到 cilium agent 也有一个毛病，在 agent 启停周期时，不会产生地址更新的学习。

在 Cilium 1.11 中，街坊发现性能已被齐全从新设计，Cilium 外部的 ARP 解析库已从 agent 中齐全移除。当初 agent 依赖于 Linux 内核来发现下一跳或同一 L2 域中的主机。Cilium 当初可同时反对 IPv4 和 IPv6 街坊发现。对于 v5.16 或更新的内核，咱们曾经将往年 Linux Plumbers 会议期间独特组织的 BPF & Networking Summit 上，提出的“治理”街坊条目工作提交到上游（part1, part2, part3）。在这种状况下，agent 将新增集群节点的 L3 地址下推，并触发内核定期主动解析它们对应的 L2 地址。

这些街坊条目作为“内部学习”和“治理”街坊属性，基于 netlink 被推送到内核中。尽管旧属性确保在压力下这些街坊条目不会被内核的垃圾收集器解决，然而 “ 治理 ” 街坊属性会，在可行的状况下, 内核须要主动将这些街坊属性放弃在 REACHABLE 状态。这意思是，如果节点的下层堆栈没有被动向后端节点发送或接管流量，内核能够重新学习，将街坊属性放弃在 REACHABLE 状态，而后通过外部内核工作队列定期触发显式街坊解析。对于没有 “ 治理 ” 街坊属性性能的旧内核，如果须要，agent controller 将定期督促内核触发新的解决方案。因而，Cilium 不再有 PERMANENT 街坊条目，并且在降级时，agent 将主动将旧条目迁徙到动静街坊条目中，以使内核可能在其中学习地址更新。

此外，在多路径路由的状况下，agent 会做负载平衡，它当初能够在路由查找中查看失败的下一跳。这意味着，不是代替所有的路由，而是通过查看相邻子系统信息来防止失败的门路。总的来说，对于 Cilium agent 来说，这项修改工作显著促成了街坊治理，并且在网络中的节点或下一跳的街坊地址发生变化时，数据门路更易变动。

XDP 多设施负载均衡器

在此版本前，基于 XDP 的负载均衡器减速只能在单个网络设备上启用，以发夹形式（hair-pinning）运行，即数据包转发来到的设施与数据包达到的设施雷同。这个最后的限度是在基于 XDP 层的 kube-proxy 代替减速中退出的，起因是在 XDP（XDP_REDIRECT）下对多设施转发的驱动反对无限，而同设施转发（XDP_TX）是 Linux 内核中每个驱动的 XDP 都反对的。

这意味着多网络设备的环境下，咱们须要应用 tc eBPF 机制，所以必须应用 Cilium 的惯例 kube-proxy 代替。这种环境的一个典型例子是有两个网络设备的主机，其中一个是公网，承受来自内部对 Kubernetes service 的申请，而另一个是公有网络，用于 Kubernetes 节点之间的集群内通信。

因为在古代 LTS Linux 内核上，绝大多数 40G 和 100G 以上的上游网卡驱动都反对开箱即用的 XDP_REDIRECT，这种限度终于能够解除，因而，这个版本在 Cilium 的 kube-proxy 代替，及 Cilium 的独立负载均衡器上，实现了 XDP 层的多网络设备的负载平衡，这使得在更简单的环境中也能放弃数据包解决性能。

XDP 通明反对 bond 设施

在很多企业外部或云环境中，节点通常应用 bond 设施，设置内部流量的双端口网卡。随着最近 Cilium 版本的优化，如在 XDP 层的 kube-proxy 代替 或独立负载均衡器，咱们从用户那里常常收到的一个问题是 XDP 减速是否能够与 bond 网络设备联合应用。尽管 Linux 内核绝大多数 10/40/100Gbit/s 网络驱动程序反对 XDP，但它不足在 bond（和 802.3ad）模式下通明操作 XDP 的能力。

其中的一个抉择是在用户空间实现 802.3ad，并在 XDP 程序实现 bond 负载平衡，但这对 bond 设施治理是一个相当颇为繁琐致力，例如：对 netlink 链路事件的观测，另外还须要为编排器的本地和 bond 别离提供独自的程序。相同，本地内核实现解决了这些问题，提供了更多的灵活性，并且可能解决 eBPF 程序，而不须要扭转或从新编译它们。内核负责管理 bond 设备组，能够主动流传 eBPF 程序。对于 v5.15 或更新的内核，咱们曾经在上游（part1, part2）实现了 XDP 对 bond 设施的反对。

当 XDP 程序连贯到 bond 设施时，XDP_TX 的语义等同于 tc eBPF 程序附加到 bond 设施，这意味着从 bond 设施传输数据包应用 bond 配置的传输办法来抉择隶属设施。故障转移和链路聚合模式均能够在 XDP 操作下应用。对于通过 XDP_TX 将数据包从 bond 设施上回传，咱们实现了轮循、被动备份、802.3ad 以及哈希设施抉择。这种状况对于像 Cilium 这样的发夹式负载均衡器来说特地有意义。

基于路由的设施检测

1.11 版本显著的晋升了设施的自动检测，可用于 应用 eBPF 代替 kube-proxy、带宽管理器和主机防火墙。

在晚期版本中，Cilium 自动检测的设施须要有默认路由的设施，和有 Kubernetes NodeIP 的设施。展望未来，当初设施检测是依据主机命名空间的所有路由表的条目来进行的。也就是说，所有非桥接的、非 bond 的和有全局单播路由的非虚构的设施，当初都能被检测到。

通过这项改良，Cilium 当初应该可能在更简单的网络设置中自动检测正确的设施，而无需应用 devices 选项手动指定设施。应用后一个选项时，无奈对设施名称进行一致性的命名标准，例如：无奈应用独特前缀正则表达式对设施命名。

服务后端流量的优雅终止

Kubernetes 能够出于多种起因终止 Pod，如滚动更新、缩容或用户发动的删除。在这种状况下，重要的是要优雅地终止与 Pod 的沉闷连贯，让应用程序有工夫实现申请以最大水平地缩小中断。异样连贯终止会导致数据失落，或提早应用程序的复原。

Cilium agent 通过 “EndpointSlice” API 监听 service 端点更新。当一个 service 端点被终止时，Kubernetes 为该端点设置 terminating 状态。而后，Cilium agent 删除该端点的数据门路状态，这样端点就不会被抉择用于新的申请，但该端点正在服务的以后连贯，能够在用户定义的宽限期内被终止。

同时，Kubernetes 告知容器运行时向服务的 Pod 容器发送 SIGTERM 信号，并期待终止宽限期的到来。而后，容器应用程序能够启动沉闷连贯的优雅终止，例如，敞开 TCP 套接字。一旦宽限期完结，Kubernetes 最终通过 SIGKILL 信号对仍在 Pod 容器中运行的过程触发强制敞开。这时，agent 也会收到端点的删除事件，而后齐全删除端点的数据门路状态。然而，如果利用 Pod 在宽限期完结前退出，Kubernetes 将立刻发送删除事件，而不论宽限期设置。

更多细节请关注 docs.cilium.io 中的指南。

Egress 进口网关的优化

简略的场景中，Kubernetes 利用只与其余 Kubernetes 利用进行通信，因而流量可通过网络策略等机制进行管制。但事实世界状况并非总是如此，例如：公有部署的一些应用程序没有被容器化，Kubernetes 应用程序须要与集群外的服务进行通信。这些传统服务通常配置的是动态 IP，并受到防火墙规定的爱护。那么在此种状况下，应该如何对流量管制和审计呢？

Egress 进口 IP 网关性能在 Cilium 1.10 中被引入，通过 Kubernetes 节点充当网关用于集群进口流量来解决这类问题。用户应用策略来指定哪些流量应该被转发到网关节点，以及如何转发流量。这种状况下，网关节点将应用动态进口 IP 对流量进行假装，因而能够在传统防火墙建设规定。

apiVersion: cilium.io/v2alpha1
kind: CiliumEgressNATPolicy
metadata:
  name: egress-sample
spec:
  egress:
    - podSelector:
      matchLabels:
        app: test-app
  destinationCIDRs:
    - 1.2.3.0/24
  egressSourceIP: 20.0.0.1

在下面的示例策略中，带有 app: test-app 标签的 Pod 和指标 CIDR 为 1.2.3.0/24 的流量，须要通过 20.0.0.1 网关节点的进口 IP（SNAT）与集群内部通信。

在 Cilium 1.11 开发周期中，咱们投入了大量精力来稳固进口网关性能，使其可投入生产。当初，
进口网关当初能够工作在间接路由，辨别外部流量（即 Kubernetes 重叠地址的 CIDR 的进口策略）及在不同策略中应用雷同进口 IP 下。一些问题，如回复被谬误形容为进口流量和其余等曾经修复，同时测试也失去了改良，以便及早发现潜在的问题。

Kubernetes Cgroup 加强

Cilium 应用 eBPF 代替 kube-proxy 作为独立负载均衡器的劣势之一是可能将 eBPF 程序附加到 socket hooks 上，例如 connect(2)、bind(2)、sendmsg(2) 以及其余各种相干的零碎调用，以便通明地将本地的应用程序连贯到后端服务。然而这些程序只能被附加到 cgroup v2。尽管 Kubernetes 正在致力迁徙到 cgroup v2，但目前绝大多数用户的环境都是 cgroup v1 和 v2 混合应用。

Linux 在内核的 socket 对象中标记了 socket 与 cgroup 的关系，并且因为 6 年前的一个设定，cgroup v1 和 v2 的 socket 标签是互斥的。这就意味着，如果一个 socket 是以 cgroup v2 成员身份创立的，但起初通过具备 cgroup v1 成员身份的 net_prio 或 net_cls 控制器进行了标记，那么 cgroup v2 就不会执行附加在 Pod 子门路上的程序，而是回退执行附加到 cgroup v2 层次结构 (hierarchy) 根部的 eBPF 程序。这样就会导致一个很重大的结果，如果连 cgroup v2 根部都没有附加程序，那么整个 cgroup v2 层次结构 (hierarchy) 都会被绕过。

现如今，cgroup v1 和 v2 不能并行运行的假如不再成立，具体可参考往年早些时候的 Linux Plumbers 会议演讲。只有在极少数状况下，当被标记为 cgroup v2 成员身份的 eBPF 程序附加到 cgroup v2 层次结构的子系统时，Kubernetes 集群中的 cgroup v1 网络控制器才会绕过该 eBPF 程序。为了在数据包解决门路上的尽量后面（early）的地位解决这个问题，Cilium 团队最近对 Linux 内核进行了修复，实现了在所有场景下容许两种 cgroup 版本 (part1, part2) 之间互相平安操作。这个修复不仅使 Cilium 的 cgroup 操作齐全强壮牢靠，而且也造福了 Kubernetes 中所有其余 eBPF cgroup 用户。

此外，Kubernetes 和 Docker 等容器运行时最近开始陆续发表反对 cgroup v2。在 cgroup v2 模式下，Docker 默认会切换到公有 cgroup 命名空间，即每个容器（包含 Cilium）都在本人的公有 cgroup 命名空间中运行。Cilium 通过确保 eBPF 程序附加到正确的 cgroup 层次结构的 socket hooks 上，使 Cilium 基于套接字的负载平衡在 cgroup v2 环境中能失常工作。

加强负载均衡器的可扩展性

次要内部贡献者：Weilong Cui (Google)

最近的测试表明，对于运行着 Cilium 且 Kubernetes Endpoints 超过 6.4 万的大型 Kubernetes 环境，Service 负载均衡器会受到限制。有两个限度因素：

• Cilium 应用 eBPF 代替 kube-proxy 的独立负载均衡器的本地后端 ID 分配器仍被限度在 16 位 ID 空间内。
• Cilium 用于 IPv4 和 IPv6 的 eBPF datapath 后端映射所应用的密钥类型被限度在 16 位 ID 空间内。

为了使 Kubernetes 集群可能扩大到超过 6.4 万 Endpoints，Cilium 的 ID 分配器以及相干的 datapath 构造已被转换为应用 32 位 ID 空间。

Cilium Endpoint Slices

次要内部贡献者：Weilong Cui (Google), Gobinath Krishnamoorthy (Google)

在 1.11 版本中，Cilium 减少了对新操作模式的反对，该模式通过更无效的 Pod 信息播送形式大大提高了 Cilium 的扩大能力。

之前，Cilium 通过 watch CiliumEndpoint (CEP) 对象来播送 Pod 的 IP 地址和平安身份信息，这种做法在可扩展性方面会带来肯定的挑战。每个 CEP 对象的创立 / 更新 / 删除都会触发 watch 事件的组播，其规模与集群中 Cilium-agent 的数量呈线性关系，而每个 Cilium-agent 都能够触发这样的扇出动作。如果集群中有 N 个节点，总 watch 事件和流量可能会以 N^2 的速率二次扩大。

Cilium 1.11 引入了一个新的 CRD CiliumEndpointSlice (CES)，来自同一命名空间下的 CEPs 切片会被 Operator 组合成 CES 对象。在这种模式下，Cilium-agents 不再 watch CEP，而是 watch CES，大大减少了须要经由 kube-apiserver 播送的 watch 事件和流量，进而加重 kube-apiserver 的压力，加强 Cilium 的可扩展性。

因为 CEP 大大加重了 kube-apiserver 的压力，Cilium 当初曾经不再依赖专用的 ETCD 实例（KVStore 模式）。对于 Pod 数量激烈变动的集群，咱们依然倡议应用 KVStore，以便将 kube-apiserver 中的解决工作卸载到 ETCD 实例中。

这种模式衡量了“更快地流传 Endpoint 信息”和“扩展性更强的管制立体”这两个方面，并力求雨露均沾。留神，与 CEP 模式相比，在规模较大时，如果 Pod 数量激烈变动（例如大规模扩缩容），可能会产生较高的 Endpoint 信息流传提早，从而影响到近程节点。

GKE 最早采纳了 CES，咱们在 GKE 上进行了一系列“最坏状况”规模测试，发现 Cilium 在 CES 模式下的扩展性要比 CEP 模式强很多。从 1000 节点规模的负载测试来看，启用 CES 后，watch 事件的峰值从 CEP 的 18k/s 升高到 CES 的 8k/s，watch 流量峰值从 CEP 的 36.6Mbps 升高到 CES 的 18.1Mbps。在控制器节点资源应用方面，它将 CPU 的峰值使用量从 28 核 / 秒缩小到 10.5 核 / 秒。

详情请参考 Cilium 官网文档。

Kube-Proxy-Replacement 反对 Istio

许多用户在 Kubernetes 中应用 eBPF 自带的负载均衡器来代替 kube-proxy，享受基于 eBPF 的 datapath 带来的高效解决形式，防止了 kube-proxy 随着集群规模线性增长的 iptables 规定链条。

eBPF 对 Kubernetes Service 负载平衡的解决在架构上分为两个局部：

• 解决进入集群的内部服务流量（南北方向）
• 解决来自集群外部的服务流量（货色方向）

在 eBPF 的加持下，Cilium 在南北方向曾经实现了尽可能凑近驱动层（例如通过 XDP）实现对每个数据包的解决；货色流量的解决则尽可能凑近 eBPF 应用层，解决形式是将应用程序的申请（例如 TCP connect(2)）从 Service 虚构 IP 间接“连贯”到后端 IP 之一，以防止每个数据包的 NAT 转换老本。

Cilium 的这种解决形式实用于大多数场景，但还是有一些例外，比方常见的服务网格解决方案（Istio 等）。Istio 依赖 iptables 在 Pod 的网络命名空间中插入额定的重定向规定，以便利用流量在来到 Pod 进入主机命名空间之前首先达到代理 Sidecar（例如 Envoy），而后通过 SO_ORIGINAL_DST 从其外部 socket 间接查问 Netfilter 连贯跟踪器，以收集原始服务目标地址。

所以在 Istio 等服务网格场景下，Cilium 改良了对 Pod 之间（货色方向）流量的解决形式，改成基于 eBPF 的 DNAT 实现对每个数据包的解决，而主机命名空间内的利用依然能够应用基于 socket 的负载均衡器，以防止每个数据包的 NAT 转换老本。

要想开启这个个性，只需在新版 Cilium agent 的 Helm Chart 中设置 bpf-lb-sock-hostns-only: true 即可。具体步骤请参考 Cilium 官网文档。

个性加强与弃用

以下个性失去了进一步加强：

• 主机防火墙 (Host Firewall) 从测试版 (beta) 转为稳定版 (stable)。主机防火墙通过容许 CiliumClusterwideNetworkPolicies 抉择集群节点来爱护主机网络命名空间。自从引入主机防火墙性能以来，咱们曾经大大增加了测试覆盖率，并修复了局部谬误。咱们还收到了局部社区用户的反馈，他们对这个性能很称心，并筹备用于生产环境。

以下个性曾经被弃用：

• Consul 之前能够作为 Cilium 的 KVStore 后端，现已被弃用，举荐应用更经得起考验的 Etcd 和 Kubernetes 作为 KVStore 后端。之前 Cilium 的开发者次要应用 Consul 进行本地端到端测试，但在最近的开发周期中，曾经能够间接应用 Kubernetes 作为后端来测试了，Consul 能够退休了。
• IPVLAN 之前用来作为 veth 的代替计划，用于提供跨节点 Pod 网络通信。在 Cilium 社区的推动下，大大改良了 Linux 内核的性能，目前 veth 曾经和 IPVLAN 性能相当。具体可参考这篇文章：eBPF 主机路由。

• 策略追踪 (Policy Tracing) 在晚期 Cilium 版本中被很多 Cilium 用户应用，能够通过 Pod 中的命令行工具 cilium policy trace 来执行。然而随着工夫的推移，它没有跟上 Cilium 策略引擎的性能停顿。Cilium 当初提供了更好的工具来追踪 Cilium 的策略，例如网络策略编辑器和 Policy Verdicts。

  本文由博客一文多发平台 OpenWrite 公布！