Cilium 1.6引入了多个令人兴奋的新特性，包括无KVStore操作、百分百Kube-proxy替换、基于套接字的负载均衡、通用CNI链等。

我们很高兴地宣布Cilium 1.6发布。社区总共贡献了1408个提交，许多开发人员都是第一次提交。Cilium 1.6引入了多个令人兴奋的新特性，比如：

无KVStore操作：新增基于CRD的后端用于安全标识，现在允许在Kubernetes上下文中完全不使用KVstore来操作Cilium。
百分百Kube-proxy替换：许多用户都希望在不需要运行Kube-proxy的情况下运行Kubernetes集群。这个版本包括在不使用Kube-proxy的情况下运行Kubernetes集群所需的最后两个特性，Cilium完全替换了Kube-proxy。
基于套接字的负载均衡：基于套接字的负载均衡结合了客户端和基于网络的负载均衡的优点，使用Kubernetes服务提供完全透明的负载均衡，在连接建立期间一次性完成从服务IP到端点IP的转换，而不是在连接的整个生命周期中转换每个网络包。
改进策略伸缩性：该版本对整个策略系统进行了改进，将策略和标识定义的处理解耦，并转向一个完全增量的模型。这确保了高Pod调度（churn）环境，例如跨多个集群的数十万个Pod，能够很好地处理不断变化的策略定义。
通用CNI链：1.6版本引入了新的CNI链接框架，允许在其他大多数CNI插件（如Weave、Calico、Flannel、AWS VPC CNI或Lyft CNI插件）上运行Cilium。该特性支持使用高级功能，如基于eBPF的安全策略执行、可见性、多集群、加密和负载均衡，并且可以继续运行任何已经在使用的CNI插件。
本地AWS ENI模式：一种新的datapath和IPAM模式，允许将本地AWS ENI路由的效率与Cilium策略执行、加密和多集群相结合。一种基于操作符的新设计，解决了大型AWS ENI用户使用节点代理时已知的许多问题。

Cilium是什么？

Cilium是一个开源软件，用于透明地提供和保护使用Linux容器管理平台（如Kubernetes、Docker和Mesos）部署的应用程序服务之间的网络和API连接。

Cilium基础是一种新的Linux内核技术eBPF，支持在Linux内部动态植入强大的安全性、可视性和网络控制逻辑。eBPF用于提供多集群路由、替代Kube-proxy的负载均衡功能、透明加密以及网络和服务安全。除了提供传统的网络级安全外，eBPF的灵活性还可为应用程序协议和DNS请求、响应上下文中的安全提供支持。Cilium与Envoy紧密集成，提供了基于Go的扩展框架。因为eBPF运行在Linux内核中，所以不需要更改应用程序代码或容器配置就可以应用所有Cilium功能。

要了解Cilium的更多细节，请查阅Cilium简介。

无KVStore操作（CRD存储）

这是不少开发者期待已久的功能之一，目前已经完成了在没有键值存储的情况下运行Cilium所需的所有工作。从1.6版本开始，开发人员可以在Kubernetes环境中运行完全基于CRD的Cilium。下面是新模式的一个简单介绍。

新缺省值：新的默认模式从标准Kubernetes资源获取所有必需信息，并使用自定义资源定义（CRD）存储所有状态。
托管etcd：托管etcd模式构建在默认模式上，使用etcd-operator在Kubernetes集群中维护etcd集群。这将带来更好的可伸缩性，同时继续以Kubernetes作为所有状态的真相来源。如果etcd集群失败，那么状态传播将回到基于CRD的状态，直到etcd恢复。

这种新的托管etcd模式比1.5版本以前的etcd-operator模式更可靠。由于保持了Kubernetes的真相来源，etcd的失败不再是一个严重的问题。

外部KVStore：对于大规模环境，这仍然是最可靠的模式。它需要维护一个外部KVStore，可以使用Kubernetes etcd或专用etcd、consul集群。

要了解更多信息，请查阅文档中的快速安装部分。

移除Kube-proxy

1.6版带来了移除kube-proxy所需的最后一个缺失部分——支持NodePort类型的服务，以及使Kubernetes服务可用于主机和在主机网络中运行的Pod进程。新特性允许在没有kube-proxy的情况下运行一个功能完整的Kubernetes集群。这意味着不再需要长长的iptables规则列表来启用Kubernetes服务抽象。

为什么这很重要？

下图显示了Kubernetes服务到运行在远程主机上的nginx Pod的每个HTTP GET请求的延迟（越低越好），这是通过ab顺序发送10万个请求测出来的。我们可以看到，eBPF服务实现并不依赖于集群中部署的服务数量，而使用iptables的kube-proxy实现则依赖于此。

基于eBPF的服务实现不仅提高了Kubernetes服务流量的延迟和吞吐量，还减少了处理服务定义更改所需的时间和开销。对于iptables，则必须在datapath中替换整个规则表，而eBPF支持在datapath中应用单个服务更改。

另一个关键的区别是预定义行为。基于iptables的服务实现需要针对每个服务和服务后端使用多个iptables规则。这实际上创建了一个很长的规则列表，这些规则必须逐一遍历。要匹配的服务在列表上越靠下，代价会越高，一些服务的负载均衡代价是只需要遍历几条规则，其他数据包在找到匹配项之前必须遍历数千条规则，行为是非确定性的。使用eBPF，因为使用哈希表实现，所以查找成本接近O(1)，并且行为是确定的，正如上面的基准测试所示。

消除每个节点的iptables规则混乱

任何在较大的规模下运营过Kubernetes（超过几十个服务）的人都会注意到，生成了大量的iptables规则。下面是一个NodePort类型的Kubernetes服务的例子，它有两个端点作为后端。

kube-proxy（iptables）规则

-A KUBE-NODEPORTS -p tcp -m comment --comment "default/nginx:" -m tcp --dport 30905 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/nginx:" -m tcp --dport 30905 -j KUBE-SVC-253L2MOZ6TC5FE7P
-A KUBE-SEP-PCCJCD7AQBIZDZ2N -s 10.217.1.154/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-PCCJCD7AQBIZDZ2N -p tcp -m tcp -j DNAT --to-destination 10.217.1.154:80
-A KUBE-SEP-UFVSO22B5A7KHVMO -s 10.217.1.159/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-UFVSO22B5A7KHVMO -p tcp -m tcp -j DNAT --to-destination 10.217.1.159:80
-A KUBE-SERVICES ! -s 10.217.0.0/16 -d 10.107.41.178/32 -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.107.41.178/32 -p tcp -m comment --comment "default/nginx: cluster IP" -m tcp --dport 80 -j KUBE-SVC-253L2MOZ6TC5FE7P
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j
KUBE-NODEPORTS
-A KUBE-SVC-253L2MOZ6TC5FE7P -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-PCCJCD7AQBIZDZ2N
-A KUBE-SVC-253L2MOZ6TC5FE7P -j KUBE-SEP-UFVSO22B5A7KHVMO

基于eBPF的k8s服务规则

# This snippet is intentionally left blank

本地eBPF NodePort和SNAT实现

在后台，我们将一个NodePort eBPF程序附加到主机上具有默认路由的网络设备上。这使得NodePort服务可以通过设备的IP地址访问。此外，得益于新的主机级服务特性，可以通过loopback或cilium_host IP地址在集群中从主机或Pod访问NodePort服务。

当服务端点在请求的目标主机之外的其他主机上运行时，eBPF程序会在将请求转发到运行端点的主机之前执行SNAT转换。

可以通过将enable-node-port设置为true来启用该特性。有关更多配置选项，请参阅NodePort入门指南。

基于套接字的负载均衡

通常，负载均衡以如下几种方式中的一种实现：

应用程序执行客户端负载均衡并选择目标端点。这样做的好处是，负载均衡的成本是在建立连接时一次性预先支付的，在连接的生命周期内不存在额外开销，这种方法的缺点是对应用程序不透明。
通过将请求转换为特定的服务IP，网络通过中间的方框执行负载均衡。与客户端负载均衡相比，这种方法的优点是透明，不涉及应用程序本身。然而，缺点是每个网络包都需要在请求和响应方向上更改其IP地址。

在Cilium 1.6中，我们引入了基于套接字的负载均衡，它结合了两种方法的优点：

透明：负载均衡对应用程序保持100%透明。服务是使用标准的Kubernetes服务定义定义的。
高效：通过在connect(2)系统调用中转换地址实现套接字层负载均衡，负载均衡的成本在建立连接时预先支付，在连接之后就不需要额外的转换。性能与应用程序直接访问后端的性能相同。

进一步探讨

这种基于套接字的负载均衡实现利用了Linux内核中最新的eBPF cgroup钩子（hook），Cilium将其连接到connect(2)、sendmsg(2)和recvmsg(2)系统调用。eBPF程序然后用服务后端信息重写sockaddr_in{，6}数据。对于UDP服务，我们扩展了内核以使recvmsg(2)（更多细节）可以进行反向sock地址转换。这些钩子的优点是：操作对应用程序透明；以独立于设备的方式操作；后端选择只需要在connect(2)时间执行。后者意味着包头在连接的整个生命周期内不需要NAT。因此，对于内核来说，它看起来就像应用程序直接连接到后端。主机可达的服务同时适应于TCP和UDP，在UDP的情况下，已连接和未连接UDP都是支持的。

可以通过将守护进程配置里的enable-host-reachable-services设置为“true”来启用该特性，然后它会同时暴露TCP和UDP服务。协议公开可以通过守护进程标志host-reachab -services-protos来控制，该标志的默认值为“tcp、udp”，可以将其设置为其中之一，以便可以兼容更早的内核。

通用CNI链

CNI（容器网络接口）是Kubernetes API，面向的是为Kubernetes Pod提供网络的插件。虽然Cilium也直接实现了这个API，但是在某些情况下，我们希望使用另一个CNI插件进行联网，并使用Cilium提供附加功能，比如安全策略实施、多集群、加密或负载均衡。

对于所有这些的用户，我们将介绍通用CNI链。它是一个新的可插拔架构，构建在CNI的标准链特性之上。所有基于veth的CNI插件都可以与一个新的通用veth链接器集成，后者应该为任何使用veth设备连接pod的CNI插件提供开箱即用的支持。其他CNI插件可以通过编写一些Go代码来定义Cilium和CNI插件之间的接口来实现集成。

策略伸缩性

虽然Cilium1.5版本关注的是在具有大量节点的集群中运行Cilium的可伸缩性，但1.6版本改进了这些环境中节点本地操作的可伸缩性，特别是策略计算。

对于节点上运行的每个Pod，每当集群管理员修改全局集群状态或策略时，Cilium的策略计算就会发生，例如当一个新的Pod启动，或与本地策略相关的状态更改，诸如当Cilium得知策略批准了一个对应FQDN的新IP地址。当这些事件发生时，Cilium确定每个本地端点选择了哪些规则，并计算出允许哪些对应的对象（例如，集群中的其他Pod、FQDN、CIDR等）。作为这个计算的一部分，Cilium现在会缓存与适用的策略规则中的每个标签选择器相匹配的标签标识。以下列策略规则为例：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
description: "L3 ingress from env=qa"
metadata:
  name: "l3-ingress-qa"
spec:
  endpointSelector:
    matchLabels:
      app: foo
  ingress:
  - fromEndpoints:
    - matchLabels:
        env: qa

该规则适用于任何以app=foo为标签运行的Pod。在这条规则中，我们可以看到，我们应该允许任何对应于env = qa的远程目标接入。给定一个集群，如果有多个标签为env = qa的端点（例如，{app=foo， env=qa}、{app=bar， env=qa}、{app=baz， env=qa}），那么一个唯一的数字标识符（称为安全标识）会分配给每个标签组，例如：

51718 --> {app=foo， env=qa}
56949 --> {app=bar， env=qa}
61625 --> {app=baz， env=qa}

一旦分配的这些安全标识分发到本地节点，Cilium会将每个本地使用的选择器与新标识相匹配，并缓存这个信息，这样以后就不需要再从头开始执行这个匹配操作。下面是这种缓存实际的样子：

$ cilium policy selectors -o json
[
  {
    "identities": [
      51718，
      56949，
      61625
    ]，
    "selector": "\u0026LabelSelector{MatchLabels:map[string]string{any.env: qa，k8s.io.kubernetes.pod.namespace: default，}，MatchExpressions:[]，}"，
    "users": 2
  }
]

缓存这些信息现在有一个前期成本，然后，选择器的一个简单map查找就可以看到对应的目的地。这允许对大量规则的大量标识进行有效的策略计算。作为新的选择器缓存功能的一部分，当新的Pod在集群中的任何地方启动时，Cilium现在可以更新eBPF策略状态，而不执行完整的策略重算。我们自豪地说，当运行数千个Pod的大型集群中配置了数千条规则时，Cilium可以有效地计算Pod的策略。基准测试结果就是证明：

PASS: resolve_test.go:225: PolicyTestSuite.BenchmarkRegenerateL3IngressPolicyRules	    1000	   2150217 ns/op
PASS: resolve_test.go:235: PolicyTestSuite.BenchmarkRegenerateL3EgressPolicyRules	    1000	   2209893 ns/op

这些基准测试针对大量标识测试了不同类型的规则。上述分析的输出表明，即使1000条规则的入口或出口和3000个标识，当选择器缓存前期已经执行完成时，三层策略计算大概需要2毫秒。

随着这些策略计算的变化，我们也改进了生成端点datapath的其他方面。与大量标识搅动的情况下——即集群中每秒钟创建几十个以上的Pod——它通常花费不到50毫秒就可以更新每个端点的datapath，实现白名单策略，以及如何应用于以集群中的新端点为目标的流量。

本地AWS ENI Datapath

AWS ENI分配器是特定于运行在AWS云中的Cilium部署的，它通过与AWS EC2 API通信，基于AWS弹性网络接口（ENI）的IP进行IP分配。

该架构确保只有一个操作符与EC2服务API通信，以避免大型集群中的速率限制问题。预分配水印允许维护多个IP地址，以便在集群中调度新的Pod时，不用与EC2 API交互就可以在任何时候在节点上使用它们。

新IPAM模式，加上特定的AWS ENI datapath，使AWS ENI IP以兼容多集群、策略执行和负载均衡子系统的直接路由模式连接Pod。

用于透明加密的大规模数据平面

Cilium提供了透明的加密支持，它利用eBPF使用Linux内核加密子系统编排加密。Cilium 1.6版本扩展了这种支持，提供了一种新的子网模式，允许用户指定要应用透明加密的IP子网。Cilium还将管理FIB表，自动调整MTU，并暴露流级加密状态，以确保连接。

节点到节点加密

即使不涉及Pod通信，加密支持也扩展到节点到节点通信。这允许轻松加密所有网络流量，无论源端点是Kubernetes Pod，还是目标端点是Kubernetes Pod。

支持Kubernetes服务类型External IP

继续讨论可伸缩性，我们添加了External IP服务类型支持。借助这种类型的服务，你可以将请求负载均衡到集群外的IP。通过提供与服务对象匹配的Endpoint资源，该功能已经可用。通过添加External IP支持，可以节省Endpoint资源，从而减少在所有节点上传播所需的Kubernetes对象的数量。

apiVersion: v1
kind: Service
metadata:
  name: external-service
  namespace: kube-system
spec:
  ports:
  - name: service-port
    protocol: TCP
    port: 2379
  externalIPs:
  - 10.0.0.1
  - 10.0.0.2
  - 10.0.0.3

Helm Charts

随着支持的datapath和控制平面的数量越来越多，维护预生成的YAML资源部署变得困难。作为其中的一部分，我们已经集成了Helm，现在提供几个可用于模板和部署的Helm图表。所有的指南都已转换为使用Helm。

示例：面向GKE的Cilium配置

helm template cilium \
  --namespace cilium \
  --set nodeinit.enabled=true \
  --set nodeinit.reconfigureKubelet=true \
  --set nodeinit.removeCbrBridge=true \
  --set global.cni.binPath=/home/kubernetes/bin \
  > cilium.yaml
kubectl create namespace cilium
kubectl create -f cilium.yaml

1.6版本重要特性

策略
- 新的选择器缓存可以大大加快基于标签的选择器与标识对象的关联
- 如果所需的策略map大小超过默认的16K，就可以配置
- 在默认情况下，从注解创建的标签现在会被标识忽略
- 为了减少开销，Allow all现在是通过datapath表中的一条记录执行的
- 新垃圾收集器可以移除CiliumNetworkPolcies状态部分中的过时节点
无Kvstore操作
所有需要的状态存储都是基于CRD的
能够在没有配置键值存储的情况下启动Cilium
Kubernetes
简化init容器，移除Cilium状态
不同的用户代理用于区分Cilium与apiserver的通信
使用NetworkUnavailable=false修补Patch Kubernetes Node状态
在启动时跳过CRD创建的新选项
默认情况下，容器运行时集成现在是禁用的。只有当用户需要容器运行时标签和Pod标签来标识服务时，才需要启用它。
Kubernetes 1.15支持
去掉了访问集群DNS的操作符依赖
支持ExternalIP服务
通用CNI链
新的CNI链插件架构
内置面向aws-cni-vpc、Calico、Portmap和Weave-Net的链接支持
通用veth链接插件，可以运行在任何基于veth的CNI插件之上
资源消耗
- 在有大量Pod的环境中，通过大量代码优化来减少内存分配和内存占用。
- 新的最小状态响应，以减少资源消耗
- 禁用CiliumNetworkPolicy状态的新选项，以减少资源大小
基于套接字的负载均衡
- 套接字级的高效Kubernetes服务负载均衡
- 用于主机进程的Kubernetes服务负载均衡
Datapath
- 新的基于TPROXY的L7重定向datapath，不再需要重写任何包头来透明地重定向到代理。
- 使用静态IP 169.254.42.1进行服务重定向环回SNAT，而不是分配IP
- 新的datapath事件聚合现在默认为maximum
- 新的datapath模式（—enable-end -route），到本地端点的包通过每个端点的路由进行路由，而不是通过单独的veth对路由
- 新的本地AWS ENI datapath模式
IPAM
- 新的基于CRD的IPAM机制
- AWS ENI分配方法
NodePort支持
- NodePort服务的原生eBPF实现（–enable-node-port）
透明加密
- 除Pod到Pod加密、Pod到节点加密之外的节点到节点加密
- 计算加密流量和非加密流量的新指标
CLI
- 新的cilium identity list --endpoints命令
- 新的cilium policy selectors，可以列出策略选择器缓存中的内容
文档
所有指南已经重写，转为使用Helm charts
关于如何搭配使用Cilium和Kata容器的新指南
关于在microk8s上简单部署的新指南
新增疑难解答文档
Istio
支持1.2.4

入门

如果你是Cilium的新用户，请查阅入门指南。

升级说明

和往常一样，按照升级指南升级你的Cilium部署就可以了。欢迎随时在Slack上联系我们。

发布

发布说明&二进制文件：1.6.0
容器镜像：docker.io/cilium/cilium:v1.6.0

查看英文原文：Cilium 1.6: KVstore-free operation， 100% kube-proxy replacement， Socket-based load-balancing， Generic CNI Chaining， Native AWS ENI support， …

创作场景

Cilium 1.6：无 KVstore 操作、百分之百 kube-proxy 替换、基于套接字的负载均衡