CNCF 布道师 Donald Liu

CNCF 布道师 Donald Liu 进行了开场致辞，Donald 对今年的 KCD 其他城市站的概况进行了总结，对组织、参与和努力传播云原生技术的开发者们进行了感谢，随后 Donald 带领大家通过「CNCF Landscape 2.0」了解目前 CNCF 的现状，让大家看到云原生开源社区正不断壮大，新兴项目层出不穷，云原生生态十分庞大，Kubernetes 只是社区中的冰山一角，云原生正以惊人的速度无处不在地扩展。

CNCF Landscape 2.0：

https://cncf.landscape2.io/

话不多说让我们来看主论坛的内容回顾：

一、云原生微服务的下一站，蚂蚁 SOFAServerless 新架构的探索与实践

赵真灵(蚂蚁集团)

在微服务研发痛点中，协作与资源成本方面存在以下具体问题：

1. 多人协作阻塞，变更影响面大，风险高

2. 大型应用过大，资源成本与长期维护成本高

3. 小型应用过多，增加了资源管理和维护的成本

这些问题导致了协作与资源成本的增加，对微服务系统的开发和维护带来了挑战。

SOFAServerless 作为一种基于云原生微服务架构的开源框架，它提供了一种无服务器的计算模型，使开发人员能够以函数为中心构建和部署应用程序。其方案的优势包括以下内容：

1. 基于函数计算的无服务器架构，提高了开发效率和资源利用率

2. 基于服务网格的微服务治理，提高了服务的可观测性和可靠性

3. 基于云原生技术的自动化运维，提高了系统的稳定性和可维护性

通过使用 SOFAServerless 的效果，最终可实现：提高开发效率，缩短上线时间；降低资源成本，提高资源利用率；并且可提高系统的可观测性和可靠性，降低故障率；增加系统的稳定性和可维护性，降低运维成本。

二、探索 Kubernetes 管理 OceanBase 数据库的优势与策略

孙宏鑫(OceanBase)

OceanBase 是基于 Paxos 算法实现的高可用、高性能的分布式关系型数据库系统，具有分布式事务、分布式索引、分布式查询等功能。将 Kubernetes 与 OceanBase 数据库结合使用，可以带来许多优势，同时也有很多优化策略。

Kubernetes 管理 OceanBase 数据库的优势包括：

1. 标准化：容器化提供了标准的环境，解决了环境依赖的问题。

2. 隔离性：Namespace 隔离，不同 namespace 下的进程不可见，资源隔离，限制容器能够使用的资源。

3. 资源弹性：资源池化，可以动态的扩缩容，结合业务的峰谷，提升资源使用效率。

4. 可编排：结合 Kubernetes 技术，可以实现复杂的应用部署形态。

此外，Kubernetes 还可以通过 StatefulSet 模式和 Operator 模式来部署和管理 OceanBase 数据库应用，提供了稳定的网络标识和持久化存储，以及更高级的运维能力。 

Kubernetes 管理 OceanBase 数据库的策略包括：

1. 使用 StatefulSet 模式来部署 OceanBase 数据库，提供稳定的网络标识和持久化存储。

2. 利用自定义的 Operator 来简化 OceanBase 数据库的部署、配置和管理，提供更高级的运维能力。

3. 通过 ob-operator 实现对 OceanBase 相关资源的定义，自定义运维逻辑。

4. 标准化的资源调谐流程，根据有限的状态来生成任务流。

这些策略可以帮助实现更可靠、更 open 和更易用的 OceanBase 数据库管理

三：eBPF的上层应用：让 Logging、Metrics 和 Tracing 联动起来

朱杰坤(趣丸科技(TT 语音))

朱杰坤介绍了 OpenTelemetry Collector 中 Span Metrics Connector 的数据处理思路，将 eBPF 采集的 Trace Span 展开为网络请求黄金指标（R.E.D）和日志，使得 Trace、Log 和 Metric 可以联动展示。分享者同时也讲解了在数据展开实践中遇到的问题，包括日志数据采样、指标数据使用 Native Histogram 自动调整精度，以及在没有插装的前提下 Trace 数据是如何被串联的。

eBPF（extendedBerkeley Packet Filter）作为一种强大的内核技术，可以在不修改内核源代码的情况下，通过加载和执行特定的 eBPF 程序来扩展内核功能。通过将 eBPF 跟 Logging、Metrics 和 Tracing 联动起来，可以实现更全面和深入的系统监控和分析。例如，可以使用 eBPF 程序捕获特定类型的日志事件，并将其转换为指标数据，然后使用指标监控系统进行实时监控和报警。同时，可以使用 eBPF 程序追踪和分析系统和应用程序的执行流程，帮助开发人员定位和解决性能问题。

四、Kubernetes 集群升级和恢复

张世明(DaoCloud 道客)

众所周知，Kubernetes 集群升级和恢复是一个复杂的过程，其中存在一些挑战和难点，比如版本兼容性问题、数据迁移和持久化存储问题、网络和服务中断问题、故障恢复和回滚问题、升级过程的复杂性问题。

通过 LTS（Long-Term Support，长期支持版本）可以一定程度的解决以上问题，但 LTS  版本目前也存在很多困难和要抉择的地方：

1、升级路径的复杂性：即使有了 LTS 版本，例如 1.29 和 1.32 是 LTS 版本，但是从 1.29 升级到 1.32 仍然需要经过 1.30 和 1.31，这会让升级路径变得很复杂。

2、依赖：其他 Kubernetes 生态是否会使用 LTS 版本，也决定了 LTS 版本的可维护时间。

3、LTS 包含内容的界定：CVE、重要 Bug、稳定性优化？范围越大，需要参与这部分工作的人力资源就会越多，由于维护的是老版本，开发者成就感会降低，版本差异带来的 Merge Conflicts 也会是阻碍。

4、Infra 费用问题：支持 LTS 版本带了 CI 开销是可预测的高投入，对于目前的 Kubernetes 社区也是很大挑战。

这些问题在 Kubernetes 社区中也被广泛讨论，是接下来需要面对和解决的问题。

最后张世明探讨了有状态应用是否应该运行在 Kubernetes 上，这个问题并没有明确的定论，虽然已经有很多用户把有状态应用放到云上了，但是这显然是有一些难点的，其中包括：

-存储：分布式存储与性能

-有状态应用迁移：数据和应用镜像是否能够快速在新节点拉起

-有状态应用的控制器：StatefulSet 是否满足需求，是否需要额外的 Operator

-单点故障的解决方案

-高可用有状态 Pod 是否可以对共享数据同时进行读写操作

-还是只有一个工作并提供服务

-故障时能否快速切换

-集群故障，你的服务是否会被影响

-能否快速迁移到别的集群

-是否有成熟的 Multi-Cluster Operator 解决方案

上面提到的不管是什么方案，都需要定期对 ETCD 做好备份，一旦出现问题，能够较快的通过备份数据快速还原集群的状态。对于有状态应用可能需要做好自己的恢复方案。

五：使用kubean管理集群生命周期

江波(DaoCloud 道客)

在管理集群生命周期时，会遇到很多棘手的问题：

1、难以支持国产信创及异构环境
2、复杂的运维流程，操作易出错
3、集群组件较多，参数管理混乱
4、弱版本管理，集群升级难度高
5、操作无记录，难以排障溯源
6、无法应对离线化的部署场景

Kubespray 从众多集群生命周期管理社区方案中脱颖而出，因为它具备以下优势：

• 支持 10 余种主流 linux 发行版的部署
• 支持丰富的网络、存储、运行时组件扩展
• 支持扩容异构节点
• 支持完整的生命周期管理，且操作灵活
• 基于 ansible, 对于运维交付友好
• 良好的开源社区活跃度

通过使用基于 kubespray 开发的  Kubean  管理集群生命周期可以大大简化流程操作，降低风险。Kubean  作为  DaoCloud  自主开源的项目，目前成功入选了 CNCF 全景图，它提供了一个  Web UI  界面，支持集群的创建、更新、删除、升级、证书管理等操作，采用云原生的方式简化集群的部署及生命周期管理，相比于 Kubespray 它有一些更令人兴奋的优势：

• 提供声明式 API 的云原生操作模式
• 提供离线场景的完备部署能力
• 允许操作任务编排的灵活扩展
• 支持国产信创系统及多架构场景
• 允许留存集群管理操作记录

六：多网卡容器网络加速离线训练的实践

张荣(vivo)&欧锡培(vivo)

多网卡容器网络加速离线训练是一种常见的实践方法，可以提高离线训练任务的性能和效率。

离线任务依赖 RDMA 通信来提高训练速度。Vivo 主要通过 Infiniband 和 TCP 网络构建离线训练集群，其中 Infiniband 网络的集群中 pod 使用 host 网络，导致一个节点只能运行一个 pod; 同时也存在大量的训练使用 tcp 网络，训练效率较低的情况。为了构建统一的网络架构，使用基于 K8s、calico 和 RoCEv2 网络构建多网卡容器， calico 网络用于远端数据获取，RoCEv2 网络用于 pod 之间通过 RDMA 数据通信，这给 K8s 集群的维护和使用带来了新的挑战。

总的来说张荣&欧锡培通过分享一些常用的容器编排工具和网络插件，如 Volcano、SpiderPool、Macvlan 和 MultusCNI 等，和涵盖容器网络拓扑、路由、负载平衡、安全性、监控和其他方面的技术，帮助听众更好地理解了容器多网卡技术的应用。

七：KubeEdge 边云协同实践:基于大模型边云协同的实时物联网感知系统

胡时京(复旦大学)

在边缘计算的浪潮中，AI 是边缘云乃至分布式云中最重要的应用。随着边缘设备的广泛使用和性能提升，将人工智能相关的部分任务部署到边缘设备已经成为必然趋势。

KubeEdge-lanvs 子项目，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同 AI 基准测试，以研发、衡量和优化分布式协同 AI 系统。

然而在边缘设备中部署静态的 AI 模型往往不足以应对复杂多变的真实世界环境，因此终身学习能力对于边缘AI模型来说变得越来越重要。为了方便边缘AI算法研究者开发及测试终身学习算法在真实世界环境中的效果，KubeEdge-lanvs 在新版本的更新中发布了支持终身学习范式的相关算法的研发与测试功能。

云边协同是个很有意思的分布式统一管理场景。KubeEdge 作为一个开源的边缘计算平台，它将云原生能力延伸至边缘，实现边缘节点的管理、应用部署和数据处理。KubeEdge 边云协同可以应用于实时物联网感知系统，通过将大模型部署到边缘节点，实现对物联网设备的实时感知和数据处理，这在能源和工业等行业都有很好的应用场景。

八：KCL+ KusionStack 打造云原生时代的开发者自服务平台

李大元&宗喆(蚂蚁集团)

平台工程的概念在两年前应运而生，我们总结了实践平台工程的三个原则：

1.降低用户认知负担，实现研发自服务

2.提高平台的扩展性，基础设施可快速接入，释放平台生产力

3.平台即产品，以用户为中心，产品化的方式构建平台

基于以上原则孵化并开源了 KusionStack 这套平台工程技术栈。我们不认为存在一个 IDP（Internal Developer Platform）可以满足所有的使用场景，反而对于平台类的产品，每个组织的需求差别非常大，我们提供的是一套技术栈，目的是为了可以让大家基于这套技术栈更方便的构建自己的开发者平台。

同时，随着云原生技术的发展，基础设施代码化（IaC）已成为自动化和管理云资源的关键，IaC 也成为了开发者体验的核心部分，Kubernetes 和 Terraform 等基础设施即代码 (IaC) 工具已成为越来越流行的管理和部署基于云 API 的应用程序的工具，带来了便利和效率的同时也带来了一系列问题与挑战。因此，我们尝试设计了一种新的配置语言 KCL ，KCL 语言围绕动态配置管理， 配置可靠性的验证与测试和降低开发者认知负担三个方面，提出三个主要的设计理念，Mutation， Validation 和 Abstraction ，来解决 IaC 过程中遇到的问题。

九：万能数据收集器--OpenTelemetry Collector

李艳红(阿里云)

随着应用程序部署在 Kubernetes 集群中，系统复杂性增加，确保稳定性和性能需要完善的可观测工具。实现可观测性对于应用程序的稳定性和性能至关重要，但也带来很多挑战。如架构复杂、维护成本大和可扩展性差。OpenTelemetry（OTel）作为目前云原生可观测性的标准，可以灵活地收集、转换、过滤、聚合和转发各种类型的数据，使得数据收集和分析变得更加简单和高效。

李艳红通过具体案例探讨 OTel (OpenTelemetry) Collector 在企业 ARMS 中的实践及优化，以及 Span 转 Metric 落地中发现的问题，带领大家找到解决方案，最终达到效能提升，在 20w/s 的 Span 数的情况下，开源的方案内存一直增长，且到 4G+ 时开始频繁OOM。对比看来方案稳定性和性能均有较大提升。内存占用由 4G+ 降低至 200M，内存占用降低 95%。

十：Distributed tracing - maximizing ROl for OpenTelemetry integration

ILYA MOCHALOV 伊利亚·莫恰洛夫

在本次演讲中，伊利亚分享了他在为公司构建 OpenTelemetry 分布式追踪系统期间所积累的经验。其中的三个问题可以给我们带来很大启发：

1、分布式跟踪在 OpenTelemetry 集成中的重要性是什么？

分布式跟踪在 OpenTelemetry 集成中的重要性在于它能够提供上下文，显示整个请求，并提供以事件为中心的上下文元数据。它还有助于关联数据和分析，这可以为应用程序执行提供有价值的见解。

2、在使用分布式跟踪时，我们如何避免常见错误？

为了避免在使用分布式跟踪时出现常见错误，重要的是将跟踪收集到单个后端，强制执行标准，构建内部使用的蓝图、库、文档和最佳实践，并让多个团队按顺序作业而不是聚集到一起

4、可观察性的三大支柱是什么？如何将它们整合起来，将它们之间的事件联系起来？

可观察性的三个支柱是度量、日志和跟踪。集成这三种数据类型有助于将它们之间的事件关联起来。例如，度量可以提供有关系统的高级信息，日志可以提供有关特定事件的详细信息，跟踪可以提供上下文并显示整个请求。通过集成这三种数据类型，可以更全面地了解系统及其运行方式。

十一：KubeBlocks RSM：如何让数据库更好的跑在 K8s 上