【摘要】 Kmesh发布v0.4.0版本，感谢社区的贡献者在两个多月的时间里做出了巨大的努力，使得Kmesh取得功能完整度、稳定性、可靠性的多重提升。

近日我们很高兴的宣布 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 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

• 场景一：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

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测试请参考https://kmesh.net/en/docs/developer/e2e-guide/

▍加入社区贡献

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

参考链接

[1] Kmesh Website：https://kmesh.net/

[3] 可观测性设计：https://github.com/kmesh-net/kmesh/blob/main/docs/proposal/observability.md