Kmesh v0.4发布！迈向大规模 Sidecarless 服务网格

关注

原创 2024-07-24 17:37:30 1.5k 阅读 AI 写同款· GEO 优化 ›

本文分享自华为云社区《Kmesh v0.4发布！迈向大规模 Sidecarless 服务网格》，作者：云容器大未来。

近日 Kmesh 发布了 v0.4.0 版本，感谢社区的贡献者在两个多月的时间里做出了巨大的努力，使得 Kmesh 取得功能完整度、稳定性、可靠性的多重提升。当前 Kmesh 相较业界其他方案已经具备显著的资源开销小和低延时等优势，后续我们会继续在核心功能和大规模稳定性等方面重点投入，争取尽快达到 GA（生产可用）。

Kmesh 背景回顾

尽管服务网格已经在过去几年持续曝光，获得了很大的知名度，但是 Sidecar 模式在资源开销、数据链路时延等方面对工作负载产生了很大的影响。所以用户在落地选型时，还是比较谨慎。除此之外，Sidecar 模式还有一个比较大的缺点是 Sidecar 与业务容器生命周期完全绑定，无法做到独立升级。

因此 Kmesh 创新性的提出基于内核的 Sidecarless 的流量治理方案，将流量治理下沉到内核以解决 Sidecar 模式用户关心的一些问题。eBPF 技术非常适合四层的流量治理，加上可编程内核模块可以进行七层的流量编排。Kmesh 最早完全通过 eBPF 和内核模块进行 L4-L7 的治理。Kmesh 采用随流治理的策略，不会额外增加服务通信过程中的连接跳数，相比 Sidecar 模式，服务之间的通信连接数从三条减少到一条。

为了丰富七层协议的治理能力，今年 Kmesh 增加了一种新的治理模式 Workload：远端流量治理，利用 ebpf 将流量转发到 kmesh-waypoint，进行高级的七层协议治理，这是一种更加灵活的分层治理模型，能够按需满足不同用户的需求。

目前 Kmesh 基于 Istio 控制面，提供了新的服务网格数据面引擎，详细的架构如下：

Kmesh v0.4版本关键特性解析

IPv6支持

以前 Kmesh 只支持采用 IPv4 通信的服务治理，但是当前 Kubernetes 集群已经默认支持双栈集群，我们不能假设服务只采用 IPv4 协议通信，因此在 0.4 版本中我们适配了 IPv6 的协议特征，支持了 IPv6 的服务治理。

值得注意的是：即使在 IPv4 集群中，Java 应用在通信时，默认采用 IPv6 地址族进行通信，所以如果需要采用 Kmesh 对 Java 服务进行治理，请一定要升级 Kmesh 0.4 版本。

IPv6 目前只在 Workload 模式下完整支持。请期待下一个版本中，Kmesh 本地模式（流量治理完全下沉内核）也将完全支持 IPv6 协议族。

细粒度的流量治理

v0.4 版本，除了按照 Namespace 进行服务的纳管以外，我们还支持了按照 pod 粒度进行流量的纳管治理。一定程度上增加了灵活性，满足了客户只针对一个命名空间下的特定工作负载进行治理的需求。

特定 Pod 纳管

kubectl label pod <podName> istio.io/dataplane-mode=kmesh -n {namespace}

整个 Namespace 纳管

kubectl label ns <namespace> istio.io/dataplane-mode=kmesh

Kmesh 通过检查 Pod 及 Namespace 上面标签，在不同的组件中进行 Pod 的纳管。

场景一：Pod 创建时已经打上了标签，那么 kmesh 通过 Kmesh-cni 在容器网络初始化的时候通知 kmesh eBPF 程序进行纳管，保证工作负载启动之前完成纳管，不会遗漏任何数据包的治理。
场景二：在 pod 启动之后，再为 Pod 打上 istio.io/dataplane-mode：kmesh标签，那么 Kmesh-daemon 会监听 Pod 事件，检查到标签更新后，通知 kmesh ebpf 程序进行纳管。
场景三：去掉 istio.io/dataplane-mode：kmesh 标签，允许 Pod 不被 Kmesh 纳管。

这种纳管方式更加灵活，也方便了用户在发现服务访问故障之后，快速进行故障隔离，定位定界。

支持集群外部服务治理

在服务网格中，我们可以通过 ServiceEntry 定义网格外部服务，一般为 DNS 类型。

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-svc 
spec:
  hosts:
  - news.google.com
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS

对于这种服务，控制面为其生成 STRICT_DNS 类型的 Cluster, endpoint 地址为域名。

eBPF 程序不能进行 DNS 解析，因此不能根据域名进行 DNAT。在 Kmesh 0.4 版本中，我们新增了 DNS 解析模块，在用户态首先进行 DNS 解析，然后重写 Cluster 将域名替换成IP地址，再刷新给 eBPF 程序进行 DNAT。典型工作原理如图所示：

DNS 类型服务的治理，大大拓展了 Kmesh 服务治理的范畴，由 Kubernets 集群，扩展到外部服务。

基于 eBPF 的轻量化可观测

可观测性是服务网格中很重要的基础能力，对于了解数据面通信的状态具有重大意义，可以基于监控进行告警。Kmesh 采用了分层观测架构，在治理数据面，内核中存在大量可用于观测的指标数据，Kmesh 通过 eBPF 以极低的代价将这些微观、细粒度指标收集起来，并支持链路级、Pod 级等多维度信息采集；并通过 ringbuf map 上报给 kmesh-daemon 组件，daemon 中根据实时订阅的观测数据，再组织加工成用户可理解的可观测信息。

当前 Kmesh 已支持以下四种监控指标，每一种指标都通过标签标识源和目的应用，用户还可以配置 Prometheus 进行采集。

kmesh_tcp_connections_opened_total
kmesh_tcp_connections_closed_total
kmesh_tcp_received_bytes_total
kmesh_tcp_sent_bytes_total

接下来，社区将继续丰富metrics、access log等观测的采集，并完善与Prometheus、Grafana 等观测平台的对接。

在线日志级别调整

动态日志级别调整对于故障诊断具有很大的帮助，早期的版本，如果要分析 bpf 数据面的问题，获取更详细的定位日志，你需要修改代码并重新构建镜像，整个过程非常低效；新版本中被彻底改善，我们支持了在线日志级别调整，用户通过 Kmesh 运维命令，可实时调整用户态 Kmesh-daemon 和 bpf 程序的日志级别。

使用样例如下：

#Adjust kmesh-daemon log level (e.g., debug | error | info)
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set default:debug
#Adjust kmesh eBPF data plane log level
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set bpf:debug

除了新特性的加入，v0.4 版本在可维护性、大规模性能、可测试性等方面也做出了诸多改进。

大规模集群支持

生产环境中，根据部署业务的不同，集群规模可大可小，对于 Kmesh 来说，大规模集群更能展现 Kmesh 架构的优势，经过评估，Kmesh 需要支持 5000 服务，10万 pod 级的集群管理，以满足绝大多数生产使用诉求。

对于远端模式，Kmesh 修改了 bpf map 的创建模式，支持按需申请 bpf map 中的记录，这样我们可以很容易的支持大规模集群，且不引入冗余的内存开销；

对于本地模式， bpf map 更新慢的问题一直困扰着我们，原本刷新一条规则需要几十甚至上百毫秒，0.4 版本，我们优化了 map-in-map 的初始化逻辑，通过空间换时间的策略，消除了 map-in-map 的刷新耗时，将规则的刷新降低到 ms 以内，这为后续支持大规模奠定了坚实的基础。

E2E测试

Kmesh 当前正处于快速膨胀的成长期，新特性正源源不断的加入到 Kmesh 中，如何保障社区的整体质量，确保 Kmesh 平稳有序的向前发展是社区面临的重要挑战；虽然社区已经有 UT test 做功能防护，但我们还缺少黑盒视角、集群级的功能防护；为此社区引入了 E2E 测试框架，并将其部署在 PR 门禁中，这样，每个新 PR 提交时，就可以及时检查新提交对于已有功能的影响，这对于 Kmesh 非常有用，当前 E2E 测试框架已经部署上线，并增加了部分测试用例，后续将不断丰富测试集，也欢迎社区的小伙伴们共同完善Kmesh测试防护网。详细的运行E2E测试请参考Run E2E test | Kmesh