我们非常高兴地宣布 Kmesh v0.5.0 的发布。首先，感谢我们的贡献者在过去两个月中的辛勤工作。在 v0.5.0 版本中，我们进行了许多重要的增强，包括命令行工具 kmeshctl、更全面的端到端测试覆盖、底层 eBPF 信息的可视化改进、可观测性增强、完整的重启支持、CNI 安装程序的改进以及 XDP 程序中的 RBAC 支持。此外，在本次发布周期中，我们修复了许多关键的 Bugs，重构了部分关键代码，并增加了更多测试覆盖，使 Kmesh 更加稳定和健壮。

  Kmesh背景回顾  

对于“Kernel-Native”模式，由于 eBPF 技术非常适合四层流量治理，并且结合可编程内核模块，可以实现七层流量编排。Kmesh 最初完全依赖 eBPF 和内核模块来实现 L4-L7 的治理。Kmesh 采用随流治理策略，不会在服务通信过程中增加额外的连接跳数，与 Sidecar 模式相比，服务之间的通信连接数从三条减少至一条。“Kernel-Native”模式的架构图如下：

同时，为了增强七层协议的治理能力，今年 Kmesh 引入了一种新的治理模式——“Dual-Engine”模式，利用 eBPF 将流量转发到 kmesh-waypoint 进行高级的七层协议治理。这是一种更灵活的分层治理模型，能够按需满足不同用户的多样化需求。

  Kmesh 0.5版本关键特性解析  

Kmesh重启时的零停机时间

现在，Kmesh 可以在重启后优雅地重新加载 eBPF Map 和程序，且不需要在重启后重新注册命名空间或特定 Pod。这意味着在重启期间，流量不会中断，这对用户来说是一个巨大的好处。在 kmesh-daemon 重启后，eBPF Map 配置将自动更新为最新状态。

如上图所示通过将 eBPF程序 pin 在内核目录上，kmesh 关闭后 eBPF 依然可以正常对流量进行治理，保证 kmesh 重启过程中服务不中断。

在 kmesh 重启后，将 bpf_map 中存放的 config 与最新获取的 config 作对比，将 bpf_map 中的 config 更新至最新。

在 v0.4.0 版本中，Kmesh 重启后需要重新启动所有由 Kmesh 管理的 Pod，以便重新管理，因为该管理是由 CNI 插件触发的。现在这一过程已在 kmesh-daemon 中完成，因此 Pod 不需要重新启动即可重新管理。

可观测性增强

现在，Kmesh 支持 L4 访问日志，使用户能够清晰地可视化 Kmesh 管理的流量。请注意，访问日志默认未启用。您可以通过修改 Kmesh 中  spec.containers.args 的 --enable-accesslog 参数来启用访问日志功能。我们还将支持使用 kmeshctl 动态启用访问日志。

访问日志的示例如下：

accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC
src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system,
dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms

其中各个字段的含义为：

将授权执行下沉到XDP程序中

在 v0.3.0 版本中，Kmesh 已支持 L4 RBAC，但之前的解决方案是在用户空间中进行 RBAC，这在性能和功能上存在一些问题。现在我们已将其下沉到 XDP eBPF 中，这项功能将真正可用。目前，鉴权规则已转移到 eBPF Map中，这使得能够完全在 eBPF 程序中执行授权。当授权结果为拒绝时，XDP 程序会直接丢弃请求数据包，从而使客户端能够检测到连接失败。

下沉到 XDP 程序的关键是使用了 eBPF 的 tail-call 机制，将不同的匹配规则通过 tail-call 串联起来，遵循了原先在用户空间进行鉴权的逻辑。

如上图所示，集群内配置的鉴权规则通过消息订阅机制，被写入 eBPF Map。Pod 上入方向的流量在建链时，会在 XDP 程序中进行鉴权规则匹配，如果鉴权结果为拒绝，则包被丢弃；如果鉴权结果为允许，则流量将通过协议栈发送到对应的 App 进程。

更好的调试能力

我们新增了命令行工具 kmeshctl！现在，您无需进入相应的 Kmesh 守护进程 Pod 来调整 Kmesh 守护进程的日志级别或转储配置。您可以直接使用 kmeshctl：

# 调整 kmesh-daemon 日志级别（例如，debug | error | info）
kmeshctl log kmesh-6ct4h --set default:debug
# 转储配置
kmeshctl dump kmesh-6ct4h workload

未来将为 kmeshctl 添加更多功能，以便用户更好地管理和调试 Kmesh。

更好的底层BPF Map可视化

之前我们有接口 /debug/config_dump/ads 和 /debug/config_dump/workload 来输出 Kmesh 守护进程中缓存的配置内容。由于各种原因，Kmesh 守护进程缓存中的配置与实际的 eBPF 可能并不完全一致。如果我们能获取阅读友好的 eBPF 信息，将更有助于我们进行故障排查。现在，我们可以通过接口 /debug/bpf/* 获取这些信息。这些信息也将被集成到 kmeshctl 中，方便查看，并且可以进一步扩展，以判断底层 eBPF 是否与 Kmesh 守护进程中的配置同步。

# Get eBPF info in dual-engine mode
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/workload
# Get eBPF info in kernel-native mode
kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/ads

改进CNI安装程序

由于 CNI 安装程序是 Kmesh 守护进程，如果 kmesh-daemon 意外崩溃或机器突然断电，CNI 将无法卸载 CNI 配置。如果 kubeconfig 的 token 过期，则 kmesh-daemon 异常退出后，任何 Pod 都无法成功启动。因此，我们采取了以下两种方法来解决此问题：

• 在 start_kmesh.sh 的末尾清理 CNI 配置。

• 在CNI安装程序中添加一个单独的Go协程，一旦token文件被修改，更新 kubeconfig 文件。这可以确保 kubeconfig 文件不容易过期。

支持HostNetwork工作负载

现在，对于 Kmesh 双引擎模式，我们支持通过 HostNetwork Pods 访问服务。

性能提升

在双引擎模式中，我们通过使用本地缓存来优化工作负载和服务响应处理期间的 BPF Map更新，避免了对 BPF Map的循环遍历。

关键Bug修复

我们还修复了一些重大 Bug：

• 通过不删除前端Map，防止在工作负载资源更新期间失去流量控制。

• 来自命名空间 waypoint 的流量将再次重定向到 waypoint，避免了死循环。现在我们跳过了来自 waypoint 的流量管理。

• 修复了当 waypoint 处理非 HTTP TCP流量时，会意外返回HTTP/1.1 400 Bad Request 的问题。#681

  致谢贡献者  

Kmesh v0.5.0 版本包含了来自14 位贡献者的 567 次代码提交，在此对各位贡献者表示由衷的感谢：

我们始终以开放中立的态度发展 Kmesh，持续打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！

参考链接

Kmesh Release v0.5.0: https://github.com/kmesh-net/kmesh/releases/tag/v0.5.0

Kmesh GitHub: https://github.com/kmesh-net/kmesh