diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/bpf.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/bpf.jpg new file mode 100644 index 00000000..278eb5ca Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/bpf.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns1.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns1.jpg new file mode 100644 index 00000000..439599c3 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns1.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns2.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns2.jpg new file mode 100644 index 00000000..b494a2dd Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/images/dns2.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/index.md b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/index.md new file mode 100644 index 00000000..638511ab --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.1-release/index.md @@ -0,0 +1,102 @@ +--- +title: Kmesh V1.1.0 正式发布！ +authors: + - Kmesh +slug: kmesh-1.1-release +date: 2025-05-23 +sidebar_position: 1 +--- + +我们很高兴地宣布发布 Kmesh v1.1.0，这是过去三个月全球社区共同努力实现的里程碑。特别感谢 LXF Project 的贡献者，他们的奉献对于推动此次发布至关重要。 + +在 v1.0.0 的基础上，本次发布对 Kmesh 的架构、可观测性和生态系统集成进行了重大增强。Kmesh 官方网站经过了全面重新设计，提供了直观的界面和简化的文档，以增强用户和开发者的体验。在底层，我们重构了 DNS 模块并添加了长连接指标，从而为更多流量模式提供更深入的洞察。 + +在内核原生（Kernel-Native）模式下，我们减少了侵入性的内核修改。此外，我们使用全局变量替换 BPF 配置映射（config map）以简化底层复杂性。与 Istio 1.25 的兼容性已通过严格验证，确保证与最新 Istio 版本的无缝互操作性。值得注意的是，长期存在的 TestKmeshRestart E2E 测试用例不稳定性问题已通过长期调查和底层 BPF 程序的重构得到解决，标志着运行时可靠性的飞跃。 + +## 主要特性 + +### 网站改版 + +Kmesh 官方网站经历了彻底的重新设计，提供了直观的用户体验、改进的文档、重新组织的内容层次结构和简化的导航。在解决上一版本的反馈时，我们专注于可以增强用户体验的关键领域。最初的界面存在一些可用性挑战，偶尔会导致导航困难。我们的博客模块尤其需要关注，因为其内容组织和视觉层次结构影响了内容的发现和可读性。从工程角度来看，我们认识到通过更好的组件组织和更系统的样式方法来改进代码结构的机会，因为现有的实现在维护上已变得复杂。 + +为了解决这些问题，我们转向了使用 Docusaurus 的 React，这是一个对开发者更友好的现代文档框架。这使我们能够创建模块化组件，通过复用性消除冗余代码。Docusaurus 提供了专门为文档和博客设计的内置导航系统，以及版本控制文档功能。我们实现了英语和中文文档的多语言支持，添加了高级搜索功能，并完全重新组织了内容结构。结果是极大地改善了体验，使 Kmesh 网站对所有用户更易访问且更有价值。 + +### 长连接指标 + +在此发布之前，Kmesh 在 TCP 连接终止和建立期间提供访问日志，其中包含有关连接的详细信息，例如发送字节数、接收字节数、丢包数、RTT 和重传数。Kmesh 还提供特定于工作负载和服务的指标，例如 Pod 打开和关闭的总连接数、发送和接收的字节数、丢包数、最小 RTT。这些指标仅在连接关闭后更新。 + +在此版本中，我们实现了 TCP 长连接的访问日志和指标，开发了一种持续监控和报告机制，可在长生存期 TCP 连接的整个生命周期内捕获详细的实时数据。访问日志定期报告信息，例如报告时间、连接建立时间、发送字节数、接收字节数、丢包数、RTT、重传数和状态。发送和接收的字节数、丢包数、重传数等指标也会针对长连接定期报告。 + +### DNS 重构 + +当前的 DNS 流程包括 CDS 刷新流程。因此，DNS 与内核原生模式深度耦合，无法在双引擎模式下使用。 + +![image](images/dns1.jpg) + +在 1.1 版本中，我们重构了 Kmesh 的 DNS 模块。数据在 Dns 中循环通过刷新队列的结构不再是包含 cds 的结构，而是一个域，因此 Dns 模块不再关心 Kmesh 模式，只提供要解析的主机名。 + +![image](./images/dns2.jpg) + +### BPF 配置映射优化 + +Kmesh 取消了专用的 kmesh_config_map BPF 映射，该映射以前存储全局运行时配置，例如 BPF 日志级别和监控开关。这些设置现在通过全局变量进行管理。利用全局变量简化了 BPF 配置管理，提高了运行时效率和可维护性。 + +### 优化内核原生模式以减少对内核的侵入性修改 + +内核原生模式需要大量的侵入性内核重构来实现基于 HTTP 的流量控制。其中一些修改可能对内核产生重大影响，这使得内核原生模式难以在实际生产环境中部署和使用。 +为了解决这个问题，我们同步修改了内核原生模式下的内核以及涉及的 ko 和 eBPF。通过此版本的优化，在内核 5.10 中，内核修改限制为四个，在内核 6.6 中，内核修改减少到仅一个。这最后一个也将尽可能消除，目标是最终在原生版本 6.6 及以上的内核上运行内核原生模式。 + +![image](./images/bpf.jpg) + +### 适配 Istio 1.25 + +Kmesh 已验证与 Istio 1.25 的兼容性，并在 CI 中添加了相应的 E2E 测试。Kmesh 社区在 CI 中维护三个 Istio 版本的验证，因此 Istio 1.22 的 E2E 测试已从 CI 中移除。 + +## 关键错误修复 + +**kmeshctl install waypoint error ([#1287](https://github.com/kmesh-net/kmesh/issues/1287))** + +_根本原因分析：_ + +_在构建 waypoint 镜像时移除了版本号前多余的 v。_ + +**TestKmeshRestart flaky ([#1192](https://github.com/kmesh-net/kmesh/issues/1192))** + +_根本原因分析：_ + +_这个问题实际上与 Kmesh 重启无关，在非重启场景下也可能产生。_ + +_根本原因是不适合使用 [sk](https://github.com/kmesh-net/kmesh/blob/main/bpf/kmesh/workload/cgroup_sock.c#L64) 作为映射 [map_of_orig_dst](https://github.com/kmesh-net/kmesh/blob/main/bpf/kmesh/workload/cgroup_sock.c#L80) 的键，因为它是被重用的，映射的值会被错误地覆盖，导致元数据在应该被编码到发送给 waypoint 的连接中时没有被编码，从而导致此问题中的重置错误。_ + +**TestServiceEntrySelectsWorkloadEntry flaky ([#1352](https://github.com/kmesh-net/kmesh/issues/1352))** + +_根本原因分析：_ + +_在此测试用例之前，有一个测试 `TestServiceEntryInlinedWorkloadEntry` 会生成两个工作负载对象，例如 `Kubernetes/networking.istio.io/ServiceEntry/echo-1-21618/test-se-v4/10.244.1.103` 和 `ServiceEntry/echo-1-21618/test-se-v6/10.244.1.103`。_ + +_在当前用例中，WorkloadEntry 会生成工作负载对象 `Kubernetes/networking.istio.io/WorkloadEntry/echo-1-21618/test-we`。_ + +_如果测试用例运行得足够快，前两个工作负载对象的移除操作将与后一个对象的创建操作聚合在一起。_ + +_Kmesh 会先处理新对象，然后再移除旧资源，[参考](https://github.com/kmesh-net/kmesh/blob/main/pkg/controller/workload/workload_processor.go#L841)。_ + +_这三个对象的 IP 地址相同，最终会导致在 Kmesh 工作负载缓存中找不到 IP 地址，从而导致认证失败和连接超时。_ + +## 致谢 + +Kmesh v1.1.0 包含来自 14 位贡献者的 118 次提交。我们要向所有贡献者表示衷心的感谢： + +| | | | | +| -------------- | ---------------- | ------------ | ----------- | +| @hzxuzhonghu | @LiZhenCheng9527 | @YaoZengzeng | @silenceper | +| @weli-l | @sancppp | @Kuromesi | @yp969803 | +| @lec-bit | @ravjot07 | @jayesh9747 | @harish2773 | +| @Dhiren-Mhatre | @Murdock9803 | | | + +我们一直以开放中立的态度发展 Kmesh，并继续打造 Sidecarless 服务网格行业的标杆解决方案，服务千行百业，推动服务网格健康有序发展。Kmesh 正处于快速发展阶段，诚邀有志之士加入我们！ + +## 参考链接 + +- [Kmesh Release v1.1.0](https://github.com/kmesh-net/kmesh/releases/tag/v1.1.0) +- [Kmesh GitHub](https://github.com/kmesh-net/kmesh) +- [Kmesh Website](https://kmesh.net/) diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/bpf.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/bpf.jpg new file mode 100644 index 00000000..278eb5ca Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/bpf.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns1.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns1.jpg new file mode 100644 index 00000000..439599c3 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns1.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns2.jpg b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns2.jpg new file mode 100644 index 00000000..b494a2dd Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/images/dns2.jpg differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/index.md b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/index.md new file mode 100644 index 00000000..bf52001e --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/kmesh-1.2-release/index.md @@ -0,0 +1,108 @@ +--- +title: Kmesh V1.2.0 正式发布！ +authors: + - Kmesh +date: 2025-12-09 +sidebar_position: 1 +--- + +我们很高兴地宣布发布 Kmesh v1.2.0，延续了项目向生产就绪、内核原生服务网格的稳步演进。 + +在 v1.1 建立的坚实基础上，本次发布专注于加强可靠性、提高升级安全性以及通过 targeted 增强和改进加深与 Istio 生态系统的兼容性。在过去的发布周期中，社区紧密合作，识别现实世界的运营挑战，并通过有针对性的增强和改进来解决这些问题。 + +Kmesh v1.2.0 是开源社区持续合作的成果，汇聚了来自全球开发者和用户的宝贵贡献，包括 LXF 项目的持续支持。此版本并未引入破坏性更改，而是强调使现有功能更加健壮、可预测，并为长期运行的生产工作负载做好准备。 + +除了这些增强功能外，Kmesh 网站和文档也在不断发展，保持对新老用户的清晰度和可访问性。 + +## v1.2 核心增强功能 + +### DNS 与 dnsProxy + +基于 v1.1 中引入的 DNS 重构，v1.2 添加了 dnsProxy 功能，允许 Kmesh 拦截托管服务的 DNS 解析请求。 +![DNS Proxy Flow](./images/dns1.jpg) + +专用的域名到 IP 映射表提高了主机名解析的可靠性，并简化了与非 Kubernetes 原生服务的集成。这些增强功能确保了所有操作模式下服务发现的一致性，并在复杂的部署场景中提高了整体 DNS 性能。 +![DNS Proxy Mapping](./images/dns2.jpg) + +### IPsec 增强 + +Kmesh v1.2 通过增强的 IPsec 支持加强了安全性和运行稳定性。通过重新设计的 eBPF 解密逻辑和优化的 xfrm 状态及策略配置，解决了 Kmesh 管理节点与未管理节点之间的关键互操作性问题。 +![BPF decryption](./images/bpf.jpg) +此外，kmeshctl 工具现在提供加密密钥的秘钥管理，简化了安全通信的秘钥创建和生命周期管理。 + +### ServiceEntry 改进 + +v1.2 中全面扩展了 ServiceEntry 支持。用户现在可以利用 dnsProxy 无缝集成各种外部服务，包括非 Kubernetes 原生工作负载。这一改进拓宽了服务网格集成的范围，并简化了混合环境中的连接。 + +### 零停机升级 + +基于 v0.5.0 的成就，v1.2 引入了在 BPF 映射结构保持不变的情况下升级 Kmesh 守护进程而不中断已建立连接的能力。目前处于 alpha 阶段，此功能显着减少了维护操作期间的服务停机时间，并增强了生产部署的整体可靠性。 + +### 双引擎模式增强 + +双引擎模式现在支持熔断和本地限流，从而提供对服务间通信的更精细控制。这些功能提高了弹性，防止服务故障和流量激增，并增强了不同负载条件下的系统稳定性。 + +### Istio 兼容性更新 + +Kmesh v1.2 确保与 Istio 1.26 的完全兼容性，允许用户利用最新的功能和安全改进。CI 测试中已弃用对 Istio 1.23 的支持，鼓励升级到较新版本以获得更好的性能和功能可用性。 + +## 关键错误修复与稳定性改进 + +Kmesh v1.2 包含大量修复和改进，增强了稳定性、可靠性和操作安全性。我们的团队和贡献者致力于解决关键问题，提高安全性，并确保服务网格各层的生产就绪性。 + +### IPsec 与安全增强 + +解决了启用 IPsec 的 Pod 之间的通信问题，kmeshctl 现在支持自动生成秘钥，简化了安全通信设置。添加了额外的 E2E 测试以验证正确性并防止回退。这些更改提高了可用性和集群安全性。 +参见 GitHub PRs #1496, #1487 + +### Kmeshctl 与工作流修复 + +对 kmeshctl 和开发工作流进行了多项增强，包括新命令、准备脚本 (prepare-dev) 和文档同步工作流。修正了轻微的可用性问题，简化了开发人员与 CLI 的交互，并减少了设置和维护期间的摩擦。 +参见 PRs #1426, #1498 + +### eBPF 与内核原生修复 + +修复了与跨命名空间通信和连接指标相关的不稳定测试用例，并添加了 cgroup_skb eBPF 程序以改善网络数据包处理。这些修复增强了内核原生模式的可靠性，并减少了生产环境中的错误。 +参见 PRs #1452, #1474 + +### CI、依赖项与文档更新 + +升级依赖项以解决漏洞，优化 CI 工作流，并应用了包括 markdown linting 和中文语法检查在内的文档改进。这些更改确保了安全、可靠的构建，并提高了贡献者的可用性。 +参见 PRs #1434, #1484 + +### Istio 适配与升级安全 + +Kmesh v1.2 完全适配 Istio 1.26，在 CI 测试中弃用了旧版本。启用零停机升级的提案和功能确保 Kmesh 可以在不中断现有连接的情况下进行更新，从而增强生产就绪性。 +参见 PRs #1513, #1503, #1441 + +总之，这些修复和增强使 Kmesh v1.2 更加健壮、稳定和安全，为生产部署提供了信心，并为未来的功能开发奠定了坚实的基础。 + +## 致谢 + +Kmesh v1.2.0 建立在 v1.1 的坚实基础之上，反映了快速增长的社区的贡献。我们非常高兴地欢迎以下在此版本中首次做出贡献的新贡献者： + +- @Flying-Tom +- @zrggw +- @yashisrani +- @AkarshSahlot +- @mdimado +- @Vinnu124 +- @wxnzb +- @072020127 +- @xiaojiangao123 +- @Copilot + +此外，Kmesh v1.2.0 包含了我们整个贡献者社区的贡献，包括： + +- @YaoZengzeng @hzxuzhonghu @dependabot +- @Flying-Tom @zrggw @sancppp +- @Kuromesi @072020127 @yashisrani +- @yp969803 @AkarshSahlot @mdimado +- @xiaojiangao123 @lec-bit @Vinnu124 +- @LiZhenCheng9527 @wxnzb 以及其他许多人。 + +## 参考链接 + +- [Kmesh Release v1.2.0](https://github.com/kmesh-net/kmesh/releases/tag/v1.2.0) +- [Kmesh GitHub](https://github.com/kmesh-net/kmesh) +- [Kmesh Website](https://kmesh.net/) diff --git a/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/acceptance-email.png b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/acceptance-email.png new file mode 100644 index 00000000..e35526f3 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/acceptance-email.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/tcp_long_conn_design.png b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/tcp_long_conn_design.png new file mode 100644 index 00000000..069f0298 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/images/tcp_long_conn_design.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/index.md b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/index.md new file mode 100644 index 00000000..9ca14830 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/lfx_2025_tcp_long_conn/index.md @@ -0,0 +1,55 @@ +--- +title: LFX 导师计划体验 - Kmesh TCP 长连接指标 +summary: 入选 Kmesh LFX 2025 学员，致力于长连接指标采集工作。 +authors: + - yp969803 +tags: [LFX-2025] +date: 2025-05-28T11:11:23+00:00 +last_update: + date: 2025-05-28T11:11:23+00:00 +sidebar_label: "LFX-2025 TCP 长连接指标" +--- + +## 介绍 + +读者好，我是 Yash，来自印度的一名应届毕业生。我喜欢构建很酷的东西并解决现实世界的问题。过去三年我一直在云原生领域工作，探索 Kubernetes、Cilium、Istio 等技术。 + +我有幸完成了 LFX 2025 第一期 Kmesh 的指导计划，这是一次丰富且宝贵的经历。在过去的三个月里，我在为项目做贡献的同时，获得了大量的知识和实践经验。在这篇博客中，我记录了我的指导旅程以及我作为学员所完成的工作。 + +## LFX 导师计划 – 概述 + +由 Linux 基金会运营的 LFX 导师计划旨在帮助学生和早期职业专业人士通过在经验丰富的导师指导下参与实际项目，获得开源开发的实践经验。 + +参与者为 CNCF、LF AI、LF Edge 等基金会托管的高影响力项目做出贡献。该计划通常全年分 3 期通过，每期持续约三个月。 + +[更多信息](https://mentorship.lfx.linuxfoundation.org/#projects_all) + +## 我的录取 + +我是一名活跃的开源贡献者，热爱为开源做贡献。我的兴趣与云原生技术高度一致。我熟悉 LFX 和 GSoC 等流行的指导计划，这些计划旨在帮助学生开启开源世界的大门。 +基于我的工作，Kmesh 社区也提拔我成为 Kmesh 的成员。 +我下定决心申请 LFX 2025 第一期，并于 2 月初开始探索项目。LFX 下 CNCF 的项目列在 [cncf/mentoring](https://github.com/cncf/mentoring) GitHub 仓库中。我遇到了 [Kmesh](https://github.com/kmesh-net/kmesh) 项目，这是一个新加入 CNCF 沙箱并在 LFX 首次参与的项目。 +我发现 Kmesh 项目特别令人兴奋，因为它解决的问题是提供无 Sidecar 的服务网格数据平面。这种方法可以通过提高性能和减少开销极大地造福社区。 + +Kmesh 在第一期提出了 4 个项目，我选择了 [long-connection-metrics](https://github.com/kmesh-net/kmesh/issues/1211) 项目，因为它允许我使用 eBPF，而我已经有了使用 eBPF 的相关经验。 + +我通过阅读文档和为 Good First Issues 做贡献开始了 Kmesh 项目的探索。随着我参与度的加深，导师们开始注意到我。我还为长连接指标项目提交了一份 [提案](https://github.com/kmesh-net/kmesh/blob/main/docs/proposal/tcp_long_connection_metrics.md)。 + +2 月下旬，我收到了 LFX 的邮件，通知我也被选中了。 +![email](./images/acceptance-email.png) + +## 项目演练 + +`tcp long connection metrics` 项目旨在实现 TCP 长连接的访问日志和指标，开发一种持续监控和报告机制，以便在长生存期 TCP 连接的整个生命周期内捕获详细的实时数据。 + +使用 eBPF 钩子收集连接统计信息，如发送/接收字节数、丢包数、重传数等。 + +![design](./images/tcp_long_conn_design.png) + +[更多信息](https://kmesh.net/docs/transport-layer/l4-metrics) + +## 导师体验 + +Kmesh 维护者总是随时准备帮助我解决任何疑问，无论是在 Slack 还是 GitHub 上。此外，每周四定期举行社区会议，我可以在会上提问并讨论各种话题。在过去的三个月里，我从他们身上学到了很多，包括如何有效地解决问题以及在开发过程中考虑边缘情况。 + +基于我的贡献和积极参与，Kmesh 社区认可了我的努力，并提拔我为组织成员。这种认可确实令人鼓舞，并激励我继续为 Kmesh 做贡献并帮助项目成长。 diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/acceptance-email.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/acceptance-email.png new file mode 100644 index 00000000..51662794 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/acceptance-email.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/conversation.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/conversation.png new file mode 100644 index 00000000..f0b8166d Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/images/conversation.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/index.md b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/index.md new file mode 100644 index 00000000..bb06175e --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_automation_workflow/index.md @@ -0,0 +1,122 @@ +--- +title: "OSPP-2025 为 Kmesh 自动化文档和发布工作流" +summary: "作为 OSPP 2025 的一部分，我与 Kmesh 合作，使用 GitHub Actions 自动化文档同步、版本控制和中文文档语法检查。" +date: 2025-09-30 +authors: + - yashisrani +tags: [OSPP, OSPP-2025, automation, GitHub-Actions, documentation, kmesh] +sidebar_label: "OSPP-2025 文档自动化" +--- + +# OSPP 2025 | 为 Kmesh 自动化文档和发布工作流 + +## 介绍 + +大家好！我是 **Yash Israni**，一名开源爱好者，热衷于自动化、DevOps 实践以及构建消除重复性手动工作的工具。 + +今年夏天，我有幸参加了 **2025 开源促进计划 (OSPP)**，在那里我与 [Kmesh](https://github.com/kmesh-net/kmesh) 社区合作，自动化文档和发布工作流。在三个月的时间里，我设计并实施了 GitHub Actions 流水线，使 Kmesh 网站始终保持最新、正确版本化并进行语言质量审查。 + +在这篇博客中，我将分享我的旅程——从最初被录取到项目执行，我所做的技术决策以及在此过程中学到的经验教训。 + + + +## OSPP 计划 – 概述 + +由中国科学院软件研究所 (ISCAS) 组织的 **开源促进计划 (OSPP)** 为学生和早期职业贡献者提供了机会，通过在导师指导下参与有影响力的开源项目来获得实践经验。 + +每期持续约 **三个月**（就我而言是 7 月 1 日至 9 月 30 日）。贡献者不仅交付现实世界的功能，而且还学习大型开源社区的运作方式。 + +--- + +## 我的录取 + +我一直喜欢为开源做出贡献，我的兴趣自然与自动化和云原生工具相一致。当我看到 **Kmesh** 在 OSPP 2025 下提供项目时，我立即被他们关于自动化文档工作流的提议所吸引。 + +该项目解决了一个明显的痛点：文档更新和版本控制以前是手动完成的，通常滞后于发布。用可靠的自动化取代重复性任务的机会既有影响力又充满挑战。 + +我在 **2025 年 6 月 28 日收到了录取通知书**，该计划正式从 **7 月 1 日运行到 9 月 30 日**。 + +![email](./images/acceptance-email.png) + +有趣的是，我能够在 **中期评估之前** 完成大部分项目工作，因此跳过了该检查点，给了我额外的时间来完善工作流并编写正确的使用指南。 + +![slack](./images/conversation.png) + +--- + +## 项目演练 + +### 1. 文档同步工作流 + +- **触发器：** 每次推送到主分支时 +- **动作：** 在网站仓库中打开一个包含最新文档更新的拉取请求 +- **增强功能：** 自动标记 PR 以便分类，并运行网站的 CI 流水线以验证更改 + +### 2. 发布版本控制工作流 + +- **触发器：** 当推送新的 Git 标签（发布事件）时 +- **动作：** 在网站仓库中生成文档的带版本快照 +- **增强功能：** 自动为任何与版本控制相关的更改打开 PR + +### 3. 中文语法检查器工作流 + +- **触发器：** 在修改中文文档的拉取请求上 +- **动作：** 使用 **LanguageTool API** 检测语法和样式问题 +- **增强功能：** 发布行级审查评论作为 **警告（非阻塞）**，以便贡献者在不被阻止合并的情况下收到建议 + +--- + +## 结果 + +| 指标 | 以前 (手动) | 以后 (自动化) | 改进 | +| ---------------- | ---------------- | ---------------- | -------------------- | +| 发布后更新文档 | 3–5 天 | < 1 分钟 | **>99% 更快** 🚀 | +| 网站版本控制更新 | 延迟 / 不一致 | 每次发布即时更新 | **100% 可靠** ✅ | +| 中文文档审查时间 | 每次 PR ~20 分钟 | 每次 PR ~1 分钟 | **节省 95% 时间** ⏱️ | + +这些工作流有效地 **消除了延误和手动错误**，确保 Kmesh 文档保持准确和最新。 + +所有三个工作流现在都在 Kmesh 主仓库和网站仓库的 `.github/workflows` 下上线。 + +--- + +## 关键技术决策 + +- 采用 **repository dispatch** 进行安全的跨仓库通信，消除了对长期存在的个人令牌的需求 +- 仅在必要时授予 GitHub Actions 令牌 **读写权限**，同时将其他操作委托给范围受限的机器人账户以提高安全性 +- 通过动态生成 `versions.json` 实现了 **Docusaurus 兼容的版本控制**，使导航与发布保持同步 +- 在文档同步工作流中添加了 **强大的错误处理**，以优雅地管理丢失的文件夹或文件，防止工作流崩溃 + +--- + +## 导师体验 + +我的导师 **Li Zhencheng** 和 **Zhonghu Xu**，以及 Kmesh 维护者，一直给予我支持——无论是通过 GitHub 审查还是 Slack 上的快速澄清。尽管我提前交付了主要工作流，但他们的反馈帮助我完善了边缘情况并提高了整体可靠性。 + +为了表彰我的贡献和积极参与，Kmesh 社区欢迎我成为 **组织成员**。这种认可既令人谦卑又充满动力，它加强了我继续为 Kmesh 做贡献并支持其成长的承诺。 + +--- + +## 经验教训 + +1. **自动化赋能于人** – 目标不是取代贡献者，而是将他们从重复性任务中解放出来，以便他们能够专注于有意义的审查和设计。 +2. **小步快跑，持续迭代** – 以增量、可测试的步骤构建工作流，使得调试和维护比一次性部署所有内容要容易得多。 +3. **安全性至关重要** – 对令牌和权限应用最小特权原则，在保持自动化安全的同时降低了风险。 +4. **预见边缘情况** – 工作流在不同环境中的行为不同；在分叉和多个平台上进行测试可防止生产中的意外。 +5. **文档是代码的一部分** – 编写清晰的工作流描述和 PR 评论可确保维护者信任并理解自动化正在做什么。 + +--- + +## 致谢 + +我要衷心感谢我的导师 **Li Zhencheng** 和 **Zhonghu Xu** 的指导、快速审查和鼓励。同时也感谢 **OSPP 计划工作人员** 确保整个学期的顺利运行。 + +--- + +## 链接 + +- [项目问题与拉取请求](https://github.com/kmesh-net/kmesh/issues/1412) +- [OSPP 网站](https://summer-ospp.ac.cn) +- [Yash Israni's github](https://github.com/yashisrani) + +--- diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/acceptance-email.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/acceptance-email.png new file mode 100644 index 00000000..80ba305c Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/acceptance-email.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation1.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation1.png new file mode 100644 index 00000000..6c962036 Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation1.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation2.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation2.png new file mode 100644 index 00000000..98ea167b Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation2.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation3.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation3.png new file mode 100644 index 00000000..c2b891cb Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation3.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation4.png b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation4.png new file mode 100644 index 00000000..878fe42f Binary files /dev/null and b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/images/conversation4.png differ diff --git a/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/index.md b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/index.md new file mode 100644 index 00000000..94e8f96e --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/ospp_2025_ut_test/index.md @@ -0,0 +1,128 @@ +--- +title: "OSPP-2025 为 Kmesh 完成 eBPF 单元测试" +summary: "在 OSPP 2025 中，我与 Kmesh 社区合作，通过 unitTest_BUILD_CONTEXT 框架补充 eBPF 测试，重点改进了 sendmsg 和 cgroup 相关组件的单元测试。" +date: 2025-09-30 +authors: + - wxnzb +tags: [OSPP, OSPP-2025, eBPF, Unit Testing, kmesh] +sidebar_label: "OSPP-2025 eBPF 程序 UT 增强" +--- + +# OSPP 2025 | 为 Kmesh 完成 eBPF 单元测试 + +## 介绍 + +大家好！我是 **Wu Xi**，一名对内核网络、eBPF 和测试工程有浓厚兴趣的开源爱好者。 + +今年夏天，我有幸参加了 **2025 开源促进计划 (OSPP)** 并与 [Kmesh](https://github.com/kmesh-net/kmesh) 社区合作，专注于 eBPF 程序 UT 增强。在三个月的时间里，我主要完成了 Kmesh eBPF 程序的单元测试工作。我为 sendMsg 和 cgroup 程序编写并成功运行了 UT 测试代码，并在此基础上补充了测试文档。现在，Kmesh 社区开发者无需依赖实际内核挂载和流量模拟即可验证 eBPF 程序逻辑，显着提高了开发效率。 +在这篇博客中，我将分享我的完整经历——从录取到项目执行、技术选择以及沿途学到的经验教训。 + + + +## OSPP 项目概述 + +**开源促进计划 (OSPP)** 由 **中国科学院软件研究所 (ISCAS)** 组织，为学生和早期职业开发者提供了在经验丰富的导师指导下合作开展实际开源项目的机会。 + +每期持续约 **三个月**（我的项目周期是 7 月 1 日至 9 月 30 日）。参与者不仅交付功能特性，而且还能亲身体验大型开源社区的运作方式。 + +--- + +## 我的录取经历 + +我一直喜欢参与开源，而且我的兴趣点恰好集中在网络内核及云原生工具上。当我在 OSPP 2025 看到 **Kmesh** 提供的“eBPF”和“单元测试”相关课题时，我立刻被吸引了。 + +这个项目要解决的痛点非常清晰：长期以来 eBPF 程序的验证依赖黑盒测试，不仅效率低，而且覆盖率依赖测试人员的经验。引入单元测试框架并补充关键用例，能在不需要实际内核挂载的情况下完成功能验证，这既有价值也充满挑战。 + +我在 **2025 年 6 月 28 日** 收到了中选邮件，项目正式周期从 **7 月 1 日到 9 月 30 日**。 + +![email](./images/acceptance-email.png) + +有趣的是，我在 **中期考核前** 就完成了项目的主要工作，因此跳过了这个阶段。这给了我更多时间去打磨工作流和编写使用文档。 + +![slack](./images/conversation1.png) + +![slack](./images/conversation2.png) + +![slack](./images/conversation3.png) + +![slack](./images/conversation4.png) + +--- + +## 项目工作内容 + +### 1. eBPF 单元测试框架构建 + +- **核心技术：** 基于 #define mock 宏替换的 eBPF 内核函数模拟 +- **测试覆盖：** 覆盖 sendmsg TLV 编码、cgroup sock 连接管理、cgroup skb 流量处理 +- **创新点：** 通过条件编译 #ifdef KMESH_UNIT_TEST 将测试基础设施嵌入生产代码 + +### 2. sendmsg TLV 编码验证 + +- **测试目标：** 验证 waypoint 场景下 TLV 元数据编码的正确性 +- **测试数据：** IPv4 (8.8.8.8:53) 和 IPv6 (fc00:dead:beef:1234::abcd:53) 模拟数据 +- **验证机制：** 实时解析 TLV 报文格式，校验 type、length、IP 及端口的完整性 + +### 3. cgroup 生命周期管理测试 + +- **Hook 覆盖：** cgroup/connect4, cgroup/connect6, cgroup/sendmsg4, cgroup/recvmsg4 +- **测试场景：** kmesh 管理进程注册/注销、后端无 waypoint 连接、尾调用机制 +- **验证方式：** 通过 km_manage map 状态变化验证 netns cookie 管理的正确性 + +--- + +## 项目成果 + +| 指标 | 以前 (手动) | 以后 (自动化) | 改进 | +| -------------------- | -------------------------- | -------------------- | -------------------- | +| TLV 编码验证耗时 | 30-60 分钟/场景 | < 5 秒/场景 | **>99% 更快** 🚀 | +| cgroup hook 回归测试 | 半天手动部署验证 | 自动化并行执行 | **节省 95% 时间** ⏱️ | +| 测试环境依赖 | 需要完整的 Kubernetes 集群 | 纯 eBPF 程序单元测试 | **零依赖** 🎯 | + +这些测试框架有效地 **消除了 eBPF 程序测试的盲区**，保障了 Kmesh 数据平面的稳定性和正确性。 + +目前，测试框架已集成到 CI/CD 流水线中，通过 make run 命令即可执行完整的 eBPF 单元测试套件，覆盖了 workload、XDP、sockops、sendmsg、cgroup_skb、cgroup_sock 等核心组件。 + +--- + +## 关键技术决策 + +- 使用 **define mock** 进行函数置换，通过 #define bpf_sk_storage_get mock_bpf_sk_storage_get 等宏定义在编译时替换 eBPF 内核函数，实现单元测试的依赖隔离 +- 采用 **条件编译** 测试基础设施，通过 #ifdef KMESH_UNIT_TEST 宏将测试专用的 map 定义和数据结构嵌入生产代码，确保测试代码与生产代码的一致性 +- 使用 **Go + eBPF** 混合测试框架，结合 C 语言 eBPF 程序编译与 Go 语言测试执行，通过 go test -v ./... 实现自动化测试工作流 + +--- + +## 导师指导体验 + +我的导师 **Li Zhencheng** 和 **Xu Zhonghu**，以及其他 Kmesh 维护者，在整个 UT 测试框架开发过程中给予了极大的支持。 + +他们不仅在 GitHub review 中耐心地指出测试设计的改进点，还在 Slack 上迅速解答了我关于 bpf helper mock 和 map 验证的疑问。 + +虽然我较早完成了 `sendMsg` 和 `cgroup` 程序的核心 UT，但导师的反馈让我注意到更多边界情况 (edge cases)，并推动我进一步完善了测试覆盖率和文档。 + +最后，Kmesh 社区邀请我成为 **组织成员 (Organization Member)** 以表彰我的贡献和积极参与。这不仅让我感到受宠若惊，更加定了我继续参与并支持 Kmesh 发展的决心。 + +--- + +## 经验教训 + +1. **单元测试是提升开发效率的工具** — 它不代替黑盒测试，而是补充和解放开发者，让他们能更快地专注功能实现和优化。 +2. **从小处着手，逐步迭代** — 先补充核心 eBPF 程序（如 sendMsg, cgroup_skb）的 UT，再逐渐扩展到更多场景，这比一次性覆盖所有逻辑更稳健。 +3. **预见边界情况** — eBPF 程序在不同内核版本或环境下的行为可能不同；提前在 UT 中模拟各种输入和异常，有助于避免生产环境的意外。 +4. **交流能加速学习进度** — 每次提交 PR，导师们都会在评论中给出更好的解法或疑问，这让我在短时间内学到了很多。 +5. **直面困难是进步的不二法门** — 在学习自己感兴趣但接触不深的领域时，受挫在所难免。哪怕就在这种时候也别放弃，相信自己并坚持尝试，终能找到问题的解法。 + +--- + +## 致谢 + +我要衷心感谢我的导师 **Li Zhencheng** 和 **Xu Zhonghu** 在全过程中的指导。在每次社区例会中，他们都会积极解决我当下的问题并了解我的进度。每当我提交 PR，他们都会在评论中分享见解，让我的思路变得更清晰，也提升了我的解题能力。我也要感谢 **OSPP 组委会** 为我们提供了一个顺利运行的环境。这次开源参与对我来说是一次非凡的经历，我将继续致力于开源并热爱开源！ + +--- + +## 相关链接 + +- [项目 Issue 与 Pull Request](https://github.com/kmesh-net/kmesh/issues/1411) +- [OSPP 官网](https://summer-ospp.ac.cn) +- [Wu Xi's GitHub](https://github.com/wxnzb)