Cilium服务网格的哪些特性最重要？

上个月，我们开始了 Cilium 的 beta 测试，作为服务网格的高效数据平面实现[1]。以下是我们到目前为止所了解到的最新情况，以及对下一步的一些想法。如果你已经试用过测试版，如果你已经试用了测试版，我们希望你能在这个简短的调查中提供反馈[2]。

到目前为止谁加入了测试？

到目前为止，我们已经收到了超过 300 个 Cilium Service Mesh Beta 的响应，其中 65%的参与者已经在使用 Cilium。（如果你是生产环境的用户，而你的组织很高兴分享这个作为公共知识，我们希望看到你拉个 PR，把自己添加到Cilium 用户的名单[3]！）

哪些特性是最重要的？

“服务网格”涵盖了许多不同的特性，对于把自己称为服务网格的东西，哪个特性是绝对必要的，并没有真正的行业共识——询问任何供应商，他们都会告诉你，这是他们的产品提供的一组特性！所以我们询问了测试版用户他们最感兴趣的特性是什么。

根据这项调查，可见性无疑是最重要的功能，97%的人说这是“必须拥有的”，没有一个人回答说这是不必要的。

第二个最受欢迎的功能是流量加密，超过三分之二的人认为这是必不可少的。在服务网格世界中，通常假设这是通过服务之间的 mTLS（相互 TLS）实现的，但是 mTLS 不仅提供加密，还提供服务身份验证。在我们的测试用户中，不到一半的人认为身份验证是必不可少的。为什么每个需要加密的人都不需要在服务级别进行身份验证呢？嗯，如果你对流量加密的要求是确保设法破坏你的网络的恶意参与者无法理解它，那么可以使用透明加密（IPSec 或 WireGuard）来实现这一点。但是，如果你有合法的服务，这些服务并没有被授权相互通信，那么使用 mTLS 方法是有意义的。mTLS 要求在代理上终止 L7 协议，而透明加密则发生在网络层，因此可能会有性能上的权衡——我们希望在未来几个月为你带来这方面的可测量基准。

下一个最受欢迎的特性集是我们在调查中所描述的“灰度（金丝雀）发布/A/B 测试”。这些也可以称为“流量分流”或“负载均衡”。目前在 service mesh beta 中，我们有一个配置示例，它在两个后端服务实例之间分割流量[4]。这是使用 CiliumEnvoyConfig CRD 实现的，该 CRD 暴露 Envoy 代理实例的原始配置。用户很有可能需要对这种配置进行更友好、更高级别的抽象。我们可以扩展 Cilium，以接受和理解已经存在的控制平面配置，如 SMI、Istio 或 Linkerd CRD——事实上，实现对其中一个的支持并不排除将来实现其他配置的可能性。在#service-mesh-beta Slack 频道[5]的初步讨论表明，SMI 将是一个受欢迎的选择——你的观点是什么？

Kubernetes 的 Ingress 功能需要将外部流量引入到你的服务中，尽管你把它们看作是服务网格的固有部分还是一个独立的实体，这是一个有争议的话题。我们有 HTTP 和 gRPC 流量入口的例子，包括 TLS 支持，作为测试的一部分[6]。

人们对服务网感兴趣的最后一组功能包括限速、重试和断路，有三分之一到一半的测试者认为这些功能是“必须具备的”。同样，我们很想听听你关于配置这些特性的最佳方式的想法，特别是在 SMI 规范中没有包含这些特性的情况下。你更喜欢用什么方式来控制这些特性呢？

我们还提供了自由格式的文本，让人们告诉我们他们希望在服务网格实现中看到的其他特性，其中有几个建议很受欢迎。

• 多集群支持是一个流行的响应。Cilium 已经通过 Cilium Clustermesh 支持跨多个集群的服务路由，因此 Cilium service Mesh 的发展应该很简单，可以很容易地配置为跨多个集群运行。
• 一些人提出对网络策略的支持。这是在网络数据平面内支持服务网格功能的另一个好处——在设计服务网格应该如何操作时，考虑服务级别的网络策略是很自然的。

Cilium Service Mesh 测试的下一步是什么？

Cilium Service Mesh 面临的最大问题是控制平面应该是什么样子。到目前为止，我们通过 CiliumEnvoyConfig CRD 暴露了原始的 Envoy 配置，但我们需要更友好的方法，而且（如上所述）有几个现有的事实标准，我们可能会采用并兼容这些标准。

Envoy 已经支持了几个特性，包括相互 TLS 支持，以及额外的流量管理特性（如断路），我们希望这些特性配置起来更简单。

除了与预先存在的控制平面配置保持一致之外，还需要做一些工作来确保服务网格配置的 RBAC 控制。

我们的近期目标还包括：

• 早期出现的一个技术问题是，一些例子需要 Cilium 支持隧道模式[7]，所以现在正在研究。
• Cilium 和 Hubble 已经向 Prometheus 和 Grafana 输出了很多强大的指标[8]，但我们想要的是服务网格的具体例子。例如，它应该很容易回答有关服务延迟的问题，并提供 beta 用户强烈表示他们需要的可见性。
• Helm chart 配置——Cilium CLI 是配置 Cilium 的一个很好的方法，但是我们想要给出一些 Helm chart 的例子
• 性能基准测试——Isovalent 团队已经分享了一些移除边车（sidecar）所带来的初步结果[9]，但为了证明这一点，我们希望设计出能够独立验证的良好测试。
• 将 TLS 终止与自动证书管理集成

要你参与！

我们很乐意在接下来的几个月里听到你认为应该添加到 Cilium Service Mesh 的内容。最简单的参与方式就是回答我们最新的调查[10]。

我们欢迎在 beta 仓库中有更多的示例配置，所以如果你已经尝试了一些额外的功能，或者使用了有趣的示例应用程序，为什么不打开一个 PR 与社区共享呢？

如果你想参与代码本身的工作，我们有一个开发人员指南[11]，我们欢迎你参加每周开发人员会议[12]。当然，Cilium & eBPF Slack 频道[13]24/7 在线开放给你的问题和评论！加入#service-mesh-beta 频道讨论这些特性。

参考资料

[1]服务网格的高效数据平面实现: https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta

[2]反馈: https://docs.google.com/forms/d/e/1FAIpQLScp2TRX63V1Pz0yk4Ec7kN0LnTse6LPDrhBxBV9x2p1IGnDqg/viewform？usp=sf_link

[3]Cilium 用户的名单: https://github.com/cilium/cilium/blob/master/USERS.md

[4]分割流量: https://github.com/cilium/cilium-service-mesh-beta/tree/main/l7-traffic-management

[5]#service-mesh-beta Slack 频道: https://cilium.slack.com/archives/C02QKQDTVDX

[6]测试的一部分: https://github.com/cilium/cilium-service-mesh-beta/tree/main/kubernetes-ingress

[7]隧道模式: https://github.com/cilium/cilium-service-mesh-beta/issues/9

[8]强大的指标: https://docs.cilium.io/en/stable/operations/metrics/#hubble-exported-metrics

[9]初步结果: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

[10]回答我们最新的调查: https://docs.google.com/forms/d/e/1FAIpQLScp2TRX63V1Pz0yk4Ec7kN0LnTse6LPDrhBxBV9x2p1IGnDqg/viewform?usp=sf_link

[11]开发人员指南: https://docs.cilium.io/en/stable/contributing/development/

[12]每周开发人员会议: https://docs.cilium.io/en/stable/contributing/development/

[13]Cilium & eBPF Slack 频道: http://slack.cilium.io/