Kmesh v0.4发布！迈向大规模 Sidecarless 服务网格
本文分享自华为云社区《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 控制面，提供了新的服务网格数据面引擎，详细的架构如下：
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20240724163103.35403835269673473529479351390517:50001231000000:2800:28DD4F5E629ED944F6DB8ED46312A0964A5D654ECF0B4731D6B9028F5382DFA9.png
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=kmeshKmesh 通过检查 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 地址为域名。
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20240724163103.82204198575055565566518452656198:50001231000000:2800:224045A14707B2D8AC943E54ADE4514C33D569B5C4D1E1F38475905D9FFE1776.png
eBPF 步伐不能进行 DNS 解析，因此不能根据域名进行 DNAT。在 Kmesh 0.4 版本中，我们新增了 DNS 解析模块，在用户态首先进行 DNS 解析，然后重写 Cluster 将域名替换成IP地址，再刷新给 eBPF 步伐进行 DNAT。典范工作原理如图所示：
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20240724163103.93278415026683064451343970517465:50001231000000:2800:E3B5A7A4208EF585A00284140B68FC8AFF523F00D860D78D4E5B9BD6BA9DD42A.png
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 当前正处于高速发展阶段，我们诚邀广大有志之士参加！
参考链接
Kmesh Website：https://kmesh.net/
Kmesh Release v0.4.0：https://github.com/kmesh-net/kmesh/releases/tag/v0.4.0
可观测性设计：https://github.com/kmesh-net/kmesh/blob/main/docs/proposal/observability.md
点击关注，第一时间相识华为云新鲜技能~
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]