当Pod状态为“Pending”，事件中出现“实例调度失败”的信息时，该怎么解决。

9 月 13-14 日，GOSIM HANGZHOU 2025 大会将在杭州隆重启幕。本次大会由 GOSIM 全球开源创新汇主办、CSDN 承办，以国际化、社区化、强互动为特色，深入聚焦开源与 AI 的前沿技术与跨界创新。继中国上海、荷兰代尔夫特、中国北京、法国巴黎之后，GOSIM Hangzhou 2025是该系列活动的第五站，即将在西湖之畔点燃新一轮创新热情。大会汇聚来自全球超过 1500 名一线开源开发者和 100 多位海内外资深专家，带来 100 余场高质量技术分享。华为云云原生开源技术专家将在AI 模型 × 基础设施、端侧 AI 工作坊、互动展区等会场带来议题演讲与技术讲解，深度探讨云原生技术创新和产业实践，欢迎现场交流。     议 题 1   议题：赋能云原生AI：基于Volcano调度器破解大规模语言模型部署难题论坛：AI 模型 × 基础设施时间地点：9月13日 15:00 - 15:20（Room 338，3F）讲师：Zicong Chen，华为云研发工程师, Volcano Reviewer, lws Contributor议题简介：随着大型语言模型（LLM）的规模化，多节点分布式训练与推理已成为必然。然而，这带来了双重挑战：首先，在默认调度器下，由LeaderWorkerSet等工具管理的分布式作业，因无法进行“成组调度”而常陷入资源死锁。其次，现代AI集群复杂的网络拓扑对通用调度器是不可见的，常因任务组被分散调度而导致通信效率低下，影响性能。本次分享将深入介绍基于Volcano的解决方案。我们将演示Volcano如何通过其原生的Gang Scheduling能力解决死锁问题，并通过一个实际案例，展示新版LWS是如何自动创建PodGroup来无缝集成。更进一步，我们将介绍Volcano提出的HyperNode（超节点）统一拓扑抽象。调度器通过HyperNode来理解底层的复杂网络结构，并根据作业提交时指定的约束，将其精准地调度到符合要求的特定网络拓扑性能域中，确保最佳性能。同时，本议题还将介绍实际案例，并探讨子组级别（sub-group level）拓扑感知调度、多集群网络拓扑感知调度，自动化网络拓扑感知等持续发展方向。     议 题 2   议题：边缘 AI：探索 KubeEdge 的可能性与价值论坛：边缘 AI 工作坊时间地点：9月13日 16:30 - 16:55（Room B01，B1）讲师：Yue Bao，华为云高级工程师, KubeEdge Maintainer议题简介：边缘 AI 通过在本地处理数据实现实时、低延迟推理，从而解锁各行各业的变革性应用。随着云原生技术的进步，边缘 AI 正在发展成为强大的云边协同范式，支持在边缘和云之间动态编排 AI 工作负载，从而优化性能、准确性和隐私。KubeEdge 的分布式边云协同 AI 框架 Sedna 支持在边缘和云环境中无缝部署 AI 模型。在本次演讲中，我们将探讨 KubeEdge 如何利用 Sedna 在边缘实现高效的推理和自动化。       云原生展区    同时，华为云云原生开源技术专家也将在展区（杭州市西湖区珊瑚沙东路9号白金汉爵大酒店二楼·云原生展位）与大家面对面交流KubeEdge、Volcano、Karmada、Kmesh、Kuasar等项目技术应用与产品最新实践。添加社区小助手k8s2222，提前关注展区有奖互动。 容器魔方小助手GOSIM HANGZHOU 2025 不仅是技术交流的平台，更是智能时代科技变革的重要契机。全球顶尖技术领袖、前沿企业与开源社区将齐聚一堂，重量级项目集中亮相，前沿思想碰撞迸发，技术与实践成果深度分享，共同呈现一场高规格、高密度、高能量的科技盛会。更多精彩内容及参会方式，请关注大会官网。大会官网：https://hangzhou2025.gosim.org/9 月 13- 14 日，GOSIM HANGZHOU 2025大咖云集，精彩纷呈欢迎亲临现场与全球开源资深大咖面对面交流！

Karmada[1] 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.15 [2] 版本现已发布，本版本包含下列新增特性：多模板工作负载的资源精确感知集群级故障迁移功能增强结构化日志Karmada 控制器和调度器性能显著提升  新特性概览  ▍多模板工作负载的资源精确感知Karmada 利用资源解释器获取工作负载的副本数和资源请求，并据此计算工作负载所需资源总量，从而实现资源感知调度，联邦配额管理等高阶能力。这种机制在传统的单模板工作负载中表现良好。然而，许多AI大数据应用的工作负载  CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包含多个 Pod 模板或组件，每个组件都有独特的资源需求。由于资源解释器仅能处理单个模板的资源请求，无法准确反映不同模板间的差异，导致多模板工作负载的资源计算不够精确。在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 现在可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。假设你部署了一个 FlinkDeployment，其资源相关配置如下:spec:  jobManager:    replicas: 1    resource:      cpu: 1      memory: 1024m  taskManager:    replicas: 1    resource:      cpu: 2      memory: 2048m通过 ResourceBinding，你可以查看资源解释器解析出的 FlinkDeployment 各个模板的副本数以及资源请求。spec:  components:  - name: jobmanager    replicaRequirements:      resourceRequest:        cpu: "1"        memory: "1.024"    replicas: 1  - name: taskmanager    replicaRequirements:      resourceRequest:        cpu: "2"        memory: "2.048"    replicas: 1此时，FederatedResourceQuota 计算的 FlinkDeployment 占用的资源量为： status:     overallUsed:       cpu: "3"       memory: 3072m注意：该特性目前处于 Alpha 阶段，需要启用 MultiplePodTemplatesScheduling 特性开关才能使用。随着多模板工作负载在云原生环境中的广泛应用，Karmada 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步加强对多模板工作负载的调度支持，提供更加细粒度的资源感知调度——敬请期待更多更新！更多有关此功能的资料请参考：多 Pod 模板支持[3]▍集群级故障迁移功能增强在之前的版本中，Karmada 提供了基本的集群级故障迁移能力，能够通过自定义的故障条件触发集群级别的应用迁移。为了满足有状态应用在集群故障迁移过程中保留其运行状态的需求，Karmada 在 v1.15 版本支持了集群故障迁移的应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略 StatePreservation 包含了一系列 StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。当集群发生故障时，Flink 应用可以利用 jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata:  name: foospec:  #...  failover:    cluster:      purgeMode: Directly      statePreservation:        rules:          - aliasLabelName: application.karmada.io/cluster-failover-jobid           jsonPath: "{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如 application.karmada.io/cluster-failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据 jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置 initialSavepointPath 指示从save point 启动。Flink 应用根据 initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现集群级故障迁移的状态中继。注意：该特性目前处于 Alpha 阶段，需要启用 StatefulFailoverInjection 特性开关才能使用。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为 Directly，即需要确保故障应用在旧集群上删除之后再在新集群中恢复应用，确保数据一致性。▍结构化日志日志是系统运行过程中记录事件、状态和行为的关键工具，广泛用于故障排查、性能监控和安全审计。Karmada 组件提供丰富的运行日志，帮助用户快速定位问题并回溯执行场景。在先前版本中，Karmada 仅支持非结构化的文本日志，难以被高效解析与查询，限制了其在现代化观测体系中的集成能力。Karmada 在 1.15 版本引入了结构化日志支持，可通过 --logging-format=json 启动参数配置 JSON 格式输出。结构化日志示例如下：{  "ts":“日志时间戳”,  "logger":"cluster_status_controller",  "level": "info",  "msg":"Syncing cluster status",  "clusterName":"member1"}结构化日志的引入显著提升了日志的可用性与可观测性：高效集成：可无缝对接 Elastic、Loki、Splunk 等主流日志系统，无需依赖复杂的正则表达式或日志解析器。高效查询：结构化字段支持快速检索与分析，显著提升故障排查效率。可观察性增强：关键上下文信息（如集群名、日志级别）以结构化字段呈现，便于跨组件、跨时间关联事件，实现精准问题定位。可维护性提升：结构化日志使开发者和运维人员在系统演进过程中更易于维护、解析和调整日志格式，保障日志体系的长期稳定与一致性。▍Karmada 控制器和调度器性能显著提升在本次版本中，Karmada 性能优化团队继续致力于提升 Karmada 关键组件的性能，在控制器和调度器方面取得了显著进展。控制器方面，通过引入优先级队列，控制器能够在重启或切主后优先响应用户触发的资源变更，从而显著缩短服务重启和故障切换过程中的停机时间。测试环境包含 5,000 个 Deployment、2,500 个 Policy 以及 5,000 个 ResourceBinding。在控制器重启且工作队列中仍有大量待处理事件的情况下，更新 Deployment 和 Policy。测试结果显示，控制器能够立即响应并优先处理这些更新事件，验证了该优化的有效性。注意：该特性目前处于 Alpha 阶段，需要启用 ControllerPriorityQueue 特性开关才能使用。调度器方面，通过减少调度过程中的冗余计算，降低远程调用请求次数，Karmada 调度器的调度效率得到了显著提升。测试记录了在开启精确调度组件 karmada-scheduler-estimator 情况下，调度 5,000 个 ResourceBinding 所用的时间，结果如下：调度器吞吐量 QPS 从约 15 提升至约 22，性能提升达 46%；gRPC 请求次数从约 10,000 次减少至约 5,000 次，降幅达 50%。这些测试证明，在 1.15 版本中，Karmada 控制器和调度器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。相关的详细测试报告，请参考 [Performance] Overview of performance improvements for v1.15[4]   致谢贡献者  Karmada v1.15 版本包含了来自 39 位贡献者的 269 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表： 参考资料[1] Karmada: https://karmada.io/[2] Karmada v1.15: https://github.com/karmada-io/karmada/releases/tag/v1.15.0[3] 多 Pod 模板支持: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-podtemplate-support[4] [Performance] Overview of performance improvements for v1.15: https://github.com/karmada-io/karmada/issues/6516 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：https://github.com/karmada-io/karmadaSlack 地址：https://slack.cncf.io/（#karmada） 添加社区小助手k8s2222回复Karmada进入技术交流群 

华为云CCE智能助手是依托盘古大模型与DeepSeek等领先LLM技术构建的全栈AI驱动的智能服务助手，贯穿智能问答、智能推荐、智能诊断、智能优化等全流程容器使用场景，辅助您提升运维和管理效率。当前已支持智能问答、智能诊断与恢复等能力。  云容器引擎CCE服务意见反馈链接直达：cid:link_0 

云计算BU通用计算服务产品部 2026届应届生招聘➯ 部门介绍在云计算的浪潮中，我们在Kubernetes等云原生技术领域有10余年的技术积累。我们致力于成为技术创新先锋，通过云原生容器化技术，为企业数字化转型提供强大动力。让云无处不在，让智能无所不及，共建智能世界云底座。品牌引领：连续5年云容器软件市场份额国内TOP1，Gartner容器管理魔力象限领导者，Omdia评价产品战略与执行全球第一，业务遍布国内外互联网、金融、政企等多个领域。技术创新：云原生基金会国内唯一初始成员，全球首位CNCF技术监督委员会华人副主席，CNCF基础设施技术负责人，CNCF工作负载技术负责人。主导开源 KubeEdge、Volcano、Karmada、Kuasar、Kmesh等多个云原生开源项目。华为云容器与Serverless团队持续构建AI基础设施，加大在云原生 AI、Serverless架构、多云和混合云战略、云边端协同、函数计算等领域的战略投入，以技术革新为驱动，打造业界领先的云原生解决方案。团队基于云原生技术构建大规模训推一体AI基础设施，助力华为云内外部在汽车、互联网、金融等领域的多个客户实现AI创新。热忱欢迎优秀学子加入我们!  更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

华为云ModelArts Versatile训练营基础实验之AI原生应用开发—零基础秒变大师！快速开发帮你打造爆款AI Agent：出行规划助手  一 基本信息实验类型实验难度：简单实验时长：30分钟实验类型：实操型实验简介本次实验将指导开发者通过零码快速构建复杂任务规划专家AI Agent“出行规划助手”，并在应用生成后体验试用，体验快速创建AI原生应用，轻松完成行业场景的乐趣实验目标完成出行Agent的从0创建自定义出行Agent描述，技能等与出行Agent交互，助手回答用户相关提问实验任务3.配置MCP服务信息4.创建并配置Agent信息2.创建MCP服务1.登录Versatile6.根据Agent返回确认结果5.点击开始体验登录Versatile界面点击创建MCP服务，进入MCP服务创建界面配置MCP服务信息创建并配置Agent信息点击开始体验，并在对话框中输入和出行Agent交互的内容根据Agent返回确认结果：根据出行Agent的返回内容，确认是否完成了用户的指令学前建议1. 了解相关技能2. 了解MCP服务3. 了解Agent知识二 实验实操步骤一：进入Versatile首页，左边菜单栏选择“我的MCP”点击创建MCP服务步骤二：配置MCP服务信息，部署12306和高德MCP服务1. 选择12306-MCP服务模板后点击下一步2. 点击安装MCP点击安装后，等待MCP服务安装完成，显示安装中。3. 选择高德地图MCP模板后点击下一步4. 配置高德api-key后点击安装MCP请填写api-key：API Key创建方式请见：cid:link_05. 等待MCP安装完成步骤三：创建并配置Agent信息1. 左边菜单栏选择“我的Agent”点击创建Agent。2. 选择单Agent(复杂任务规划)，配置Agent信息并添加前面部署的MCP服务，点击发布。经验模板填写：# 工具使用你可以使用12306相关mcp工具查询火车票相关信息。你可以使用高德相关mcp工具查询导航相关信息。3. 填写api-key，点击发布。请填写api-key：API Key创建方式请见：cid:link_0步骤四：旅游出行助手交互体验1. 在agent列表中，选择“旅游出行助手”体验2. 在对话框中输入：6月23日中午坐高铁从深圳到上海，请规划详细的行程路线规划，我早上从深圳华为基地出发，坐地铁到高铁站。最终用网页为我呈现，并等待Agent返回：生成计划后，点击开始任务，也可以进一步修改任务：最终生成网页进行浏览：3. 完成后，可自由提问相关问题。

华为云ModelArts Versatile训练营基础实验之AI原生应用开发—零基础秒变大师！快速开发帮你打造爆款AI Agent：热点新闻助手  一 基本信息实验类型实验难度：简单实验时长：30分钟实验类型：实操型实验简介本次实验将指导开发者通过零码快速构建复杂任务规划专家AI Agent“热点新闻助手”，并在应用生成后体验试用，体验快速创建AI原生应用，轻松完成行业场景的乐趣实验目标完成出行Agent的从0创建自定义出行Agent描述，技能等与出行Agent交互，助手回答用户相关提问实验任务3.配置MCP服务信息4.创建并配置Agent信息2.创建MCP服务1.登录Versatile6.根据Agent返回确认结果5.点击开始体验登录Versatile界面点击创建MCP服务，进入MCP服务创建界面配置MCP服务信息创建并配置Agent信息点击开始体验，并在对话框中输入和出行Agent交互的内容根据Agent返回确认结果：根据出行Agent的返回内容，确认是否完成了用户的指令学前建议1. 了解相关技能2. 了解MCP服务3. 了解Agent知识二 实验实操步骤一：进入Versatile首页，左边菜单栏选择“我的MCP”点击创建MCP服务步骤二：配置MCP服务信息，部署中文趋势聚合服务1. 选择“中文趋势聚合”服务模板后点击下一步2. 点击安装MCP3. 点击安装后，等待MCP服务安装完成，显示安装中步骤三：创建并配置Agent信息1. 左边菜单栏选择“我的Agent”点击创建Agent。2. 选择单Agent(复杂任务规划)，配置Agent信息并添加前面部署的MCP服务，点击发布。经验模板填写：# 工具使用- get-36kr-trending获取 36 氪热榜，提供创业、商业、科技领域的热门资讯，包含投融资动态、新兴产业分析和商业模式创新信息- get-bilibili-rank获取哔哩哔哩视频排行榜，包含全站、动画、音乐、游戏等多个分区的热门视频，反映当下年轻人的内容消费趋势- get-douban-rank获取豆瓣实时热门榜单，提供当前热门的图书、电影、电视剧、综艺等作品信息，包含评分和热度数据- get-douyin-trending获取抖音热搜榜单，展示当下最热门的社会话题、娱乐事件、网络热点和流行趋势- get-ifanr-news获取爱范儿科技快讯，包含最新的科技产品、数码设备、互联网动态等前沿科技资讯- get-netease-news-trending获取网易新闻热点榜，包含时政要闻、社会事件、财经资讯、科技动态及娱乐体育的全方位中文新闻资讯- get-tencent-news-trending获取腾讯新闻热点榜，包含国内外时事、社会热点、财经资讯、娱乐动态及体育赛事的综合性中文新闻资讯- get-toutiao-trending获取今日头条热榜，包含时政要闻、社会事件、国际新闻、科技发展及娱乐八卦等多领域的热门中文资讯3. 填写api-key，点击发布。请填写api-key：API Key创建方式请见：cid:link_0步骤四：热点新闻助手交互体验1. 在agent列表中，选择“热点新闻助手”体验2. 在对话框中输入：最近有哪些热点新闻、热门电影和即将上映的热门电影，请详细列举下，并用图文并茂的网页为我呈现，并等待Agent返回：生成计划后，点击开始任务，也可以进一步修改任务：最终生成网页进行浏览：3. 完成后，可自由提问相关问题。

在 Kubernetes (K8s) 中，ServiceAccount 是一种特殊类型的 账户对象，用于为 Pod 中的容器提供身份标识。它的核心作用是为 Pod 内的进程（如应用程序）授予对集群内资源的访问权限。以下是详细说明及查看方法：一、什么是 ServiceAccount？核心功能：身份标识每个 ServiceAccount 都有一个唯一的名称和一个关联的加密签名密钥对（存放在 Secret 中），用于证明请求来自该账户。权限控制通过与 Role/ClusterRole + RoleBinding/ClusterRoleBinding 的组合，定义此账户能执行的操作（如读写 ConfigMap、调用外部 API 等）。自动挂载凭证当 Pod 使用了某个 ServiceAccount，Kubernetes 会自动将其凭证（包含 CA证书、命名空间、Token）注入到 Pod 的特定挂载点：/var/run/secrets/kubernetes.io/serviceaccount/包括三个文件：ca.crt, namespace, token。关键特点：特性    说明作用域    可作用于单个命名空间（默认）或整个集群（需配合 ClusterRole）默认行为    新创建的 Pod 若未显式指定 SA，则使用命名空间下的 default SA安全性    推荐遵循最小权限原则，仅授予必要权限二、如何查看 ServiceAccount 对象？以下是常用查看方式及命令示例：查看当前命名空间的所有 ServiceAccount# 查看当前命名空间的所有 SA（含简要信息）kubectl get serviceaccounts# 显示完整详细信息（JSON/YAML格式）kubectl get serviceaccounts -o wide          # 表格+额外字段kubectl get serviceaccounts -o json        # JSON格式kubectl get serviceaccounts -o yaml        # YAML格式查看指定命名空间的 ServiceAccount# 查看名为 "my-namespace" 命名空间下的所有 SAkubectl get serviceaccounts --namespace=my-namespace# 查看特定 SA 的详细信息（如名为 "my-sa"）kubectl describe serviceaccount my-sa --namespace=my-namespace跨命名空间搜索 ServiceAccount# 查看所有命名空间下的 SA 列表kubectl get serviceaccounts --all-namespaces1.2.导出 ServiceAccount 的配置为文件# 将名为 "my-sa" 的 SA 配置导出为 YAML 文件kubectl get serviceaccount my-sa -n my-namespace -o yaml > my-sa.yaml三、典型使用场景示例假设你有一个名为 app-pod 的 Pod，它使用了自定义的 app-sa ServiceAccount，并绑定了一个允许读取 ConfigMap 的角色：# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: app-deploymentspec:  replicas: 1  template:    metadata: {}    spec:      serviceAccountName: app-sa # 指定使用的 ServiceAccount      containers:      - name: app-container        image: my-image此时，app-sa 就是该 Pod 的身份标识，其权限由对应的 RoleBinding 决定。四、注意事项不要混淆 IAM 账号Kubernetes 的 ServiceAccount ≠ 云厂商的 IAM 账号，它是集群内部的虚拟身份。避免裸奔权限默认的 default SA 通常没有绑定任何角色，但如果你手动绑定了高权限角色（如 edit），可能导致安全风险。多租户环境隔离在共享集群中，建议为不同团队/应用创建独立的 ServiceAccount 并严格限制权限。五、相关概念扩展对象类型    描述Role / ClusterRole    定义一组权限规则RoleBinding / ClusterRoleBinding    将角色绑定到 ServiceAccountPod    使用 ServiceAccount 的主体Secret    存储 ServiceAccount 的私钥和令牌总结ServiceAccount 是 Pod 的身份卡，用于控制容器对集群资源的访问。查看命令：kubectl get serviceaccounts（基础）、kubectl describe serviceaccount <name>（详情）。最佳实践：为每个应用创建专用 SA，并按需绑定最小权限角色。

**Raft协议**是一种专为分布式系统设计的共识算法，旨在解决多个节点之间的数据一致性问题。以下是对Raft协议的介绍以及核心内容的详细说明：### Raft协议概述1. **目标定位**：作为一种替代传统Paxos协议的新型方案诞生，侧重于提升可理解性与工程实践便利性。2. **核心理念**：采用强领导权模式，将复杂的一致性问题拆解为相互独立的子问题进行处理。3. **适用场景**：适用于构建高可用分布式存储系统、数据库集群等需强一致性的场景。### 核心角色与状态转换1. **三种节点状态**   - **Leader（领导者）**：唯一有权接受客户端请求并协调日志复制的中心节点。   - **Follower（追随者）**：被动响应领导者或候选人的请求，定期接收心跳信号维持状态。   - **Candidate（候选人）**：当追随者超时未收到心跳时触发选举产生的临时角色，参与投票竞争成为新领导者。2. **状态转换逻辑**   - **稳定期**：领导者持续发送心跳消息压制其他节点的选举行为。   - **选举触发**：若超过选举超时时间未收到心跳，追随者转为候选人发起投票。   - **多数决选**：获得集群多数选票的候选人晋升为领导者，开启新的任期。### 关键机制详解1. **领导者选举**   - **任期机制**：每个任期用单调递增的数字标识，确保过期无效的请求不会被处理。   - **随机超时**：每个节点设置随机范围的选举超时时间，减少分裂投票概率。   - **投票规则**：节点按“先到先得”原则投票，且仅支持同一任期内的单一候选者。   - **心跳抑制**：领导者定期发送心跳消息重置追随者的选举定时器，防止不必要的选举。2. **日志复制**   - **指令序列化**：客户端请求被领导者转换为日志条目，按顺序编号后同步至多数追随者。   - **提交条件**：当日志条目被复制到多数节点后，领导者提交该条目并通知所有节点执行。   - **一致性保障**：通过前缀匹配原则确保日志一致性，落后节点会丢弃冲突日志并同步最新条目。3. **安全属性**   - **领导完备性**：领导者必须包含所有已提交的日志条目，保证后续操作基于完整数据。   - **日志匹配原则**：若两个日志条目索引和任期相同，则认定其内容一致。   - **只追加特性**：领导者不会修改或删除已存在的日志条目，仅做增量添加。### 技术优势1. **模块化设计**：将一致性问题分解为领导者选举、日志复制、安全性等独立模块，降低实现复杂度。2. **强领导权简化逻辑**：所有操作由领导者驱动，避免无主状态下的决策冲突。3. **容错能力**：可容忍集群内少数节点故障，只要多数节点存活即可维持服务。4. **易于调试**：清晰的日志结构和状态转换便于排查问题。总的来说，Raft协议通过结构化的领导权设计和严格的日志复制机制，在保证强一致性的同时提供了良好的可扩展性和容错能力。其模块化思想和清晰的状态转换逻辑使其成为分布式系统领域的重要基础组件。

k8s-node02 节点 `NotReady` 状态的详细分析和解决方案### **一、核心问题定位**从 `kubectl describe node` 输出可见，所有关键条件（MemoryPressure/DiskPressure/PIDPressure/Ready）均处于 **Unknown** 状态，且最终错误原因是 **"Kubelet stopped posting node status"**。这表明 **Kubelet 进程未能正常向 API Server 汇报节点状态**，导致节点被标记为 `NotReady`。### **二、分步解决方案**#### **1️⃣ 紧急修复：重启 Kubelet 服务**```bashsystemctl restart kubelet```**目的**：尝试恢复 Kubelet 进程与 API Server 的通信。  **注意**：若重启后仍无法恢复，需进一步排查底层原因。#### **2️⃣ 深度排查：查看 Kubelet 日志**```bashjournalctl -f -u kubelet          # 实时查看日志journalctl -u kubelet --since "1 hour ago"  # 查看历史日志``` **重点关注以下错误类型**：| 错误类型 | 可能原因 | 解决方案 ||||-|| `NetworkPluginNotReady` | CNI 插件（如 Calico）未就绪 | 检查 CNI 组件状态 || `Failed to connect to API Server` | 网络隔离/证书过期 | 检查网络连通性及证书 || `Disk pressure detected` | 磁盘空间不足 | 清理磁盘 || `Container runtime failed` | Docker/Containerd 异常 | 重启容器运行时 |#### **3️⃣ 检查 CNI 网络插件（Calico）**```bashkubectl get pods -n kube-system -l k8s-app=calico-node``` **若发现 Calico Pod 异常**：- 重新部署 Calico 组件：    ```bash  kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml  ```- 确保宿主机网络策略允许 Calico 流量（检查 `iptables` 规则）。#### **4️⃣ 验证容器运行时（Docker）**```bashsystemctl status docker       # 检查服务状态docker info                   # 验证 Docker 功能```**若 Docker 异常**：- 重启 Docker 服务：    ```bash  systemctl restart docker  ```- 检查 Docker 日志：    ```bash  journalctl -u docker.service  ```#### **5️⃣ 检查磁盘空间**```bashdf -h                       # 查看全局磁盘使用率du -sh /var/lib/docker/*    # 检查 Docker 目录占用``` **若磁盘空间不足**：- 清理无用镜像：    ```bash  docker system prune -a  ```- 扩展磁盘配额或迁移数据到更大分区。#### **6️⃣ 校验 Kubelet 配置**检查 `/etc/kubernetes/kubelet.conf` 文件：- 确保 `cgroupDriver` 与集群其他节点一致（如 `systemd` 或 `cgroupfs`）。- 确认 `--container-runtime` 参数指向正确的容器运行时（如 `remote` 对应 containerd）。#### **7️⃣ 升级 Kubelet 版本**当前版本 **v1.20.15** 已过时，建议升级至最新稳定版（如 v1.28+）：```bash# 示例：升级 Kubelet（需匹配控制平面版本）yum install -y kubelet-<new_version> && systemctl restart kubelet``` **注意**：升级前需备份配置文件，并确保控制平面兼容新版本。#### **8️⃣ 清理节点 Taints**当前节点存在两个危险 Taints：```bashTaints:             node.kubernetes.io/unreachable:NoExecute                    node.kubernetes.io/unreachable:NoSchedule``` **清理命令**：```bashkubectl taint nodes k8s-node02 node.kubernetes.io/unreachable:NoExecute-kubectl taint nodes k8s-node02 node.kubernetes.io/unreachable:NoSchedule-```### **三、典型错误场景及处理**| **现象**                          | **可能原因**               | **解决方案**                     ||--||-|| `NetworkPluginNotReady`          | Calico 组件未启动           | 重启 Calico Pod 或重新部署        || `Failed to dial tcp ...`         | API Server 网络不通        | 检查防火墙规则及节点网络配置     || `No space left on device`       | 磁盘空间不足               | 清理磁盘或扩容                    || `Connection refused by API Server` | API Server 未响应          | 检查控制平面健康状态              |### **四、预防措施**1. **监控告警**：部署 Prometheus + Grafana，监控节点 CPU/内存/磁盘使用率及 Kubelet 状态。2. **日志轮转**：定期清理 Kubelet 日志（`/var/log/kubelet.log`），避免磁盘占满。3. **版本管理**：保持 Kubelet 与 API Server 版本同步，避免兼容性问题。4. **CNI 高可用**：确保 Calico 等网络插件的冗余配置，避免单点故障。### **五、最终验证**执行以下命令确认节点状态：```bashkubectl get nodes k8s-node02      # 应显示 Ready 状态kubectl describe node k8s-node02  # 检查 Conditions 均为 True```若问题仍未解决，请提供以下信息进一步分析：1. `kubectl describe node k8s-node02 -o json > node.json`（导出完整 JSON）。2. `journalctl -u kubelet --since "1 hour ago"`（最近 1 小时 Kubelet 日志）。3. `docker ps` 和 `crictl ps`（容器运行时状态）。

8月6日，Gartner正式发布2025《容器管理魔力象限》报告，华为云进入领导者象限。根据Gartner Peer Insight客户评价系统最新数据，华为云容器获得全球客户认可得分4.7分，在参评厂商中排名第一。我们相信，此次入选得益于华为云对云原生2.0的深入践行和战略投入，在业界率先发布CCE Turbo、CCE Autopilot、云容器实例CCI以及分布式云原生服务UCS等多款创新性容器产品，为用户提供可在公有云、分布式云、混合云、边缘运行大规模可扩展容器负载的最佳云原生基础设施。 华为云在新云原生应用、存量应用容器化、AI容器、边缘应用以及混合云应用等所有用例中均具有竞争力，尤其是在AI容器领域表现尤为突出。华为云积极参与开源，引领云原生技术生态，为82个云原生计算基金会（CNCF）项目做出贡献，贡献数量排名第二。华为云参与并捐赠给CNCF的开源项目包括KubeEdge、Volcano、Karmada、Kmesh和Kuasar等，已被全球企业广泛采用。华为云提供业界最完整的容器产品矩阵，覆盖公有云、分布式云、混合云、边缘等场景，已广泛应用到互联网、金融、制造、交通、电力、汽车等行业，释放无处不在的云原生价值。与此同时，华为云容器服务积极全球化布局，云原生算力爆发性增长，受到全球用户广泛认可，持续帮助客户取得商业成功。面向AI时代，云原生2.0全面智能化升级，华为云构建智能驱动的全新一代AI-Native云原生基础设施。Cloud for AI方面，CCE智算集群作为CloudMatrix384 超节点的云原生基础设施，可提供大规模超节点拓扑感知调度、PD分离扩缩容、AI负载感知的弹性伸缩以及容器极速启动等能力，大幅加速AI训练和推理，提升AI任务运行效率。与此同时，AI技术也在重塑云服务体验，华为云践行AI for Cloud，全新发布CCE Doer，以AI Agent方式嵌入容器使用全流程，贯穿智能问答、智能推荐、智能诊断等业务流程，支持200+关键异常场景诊断，根因定位准确率超过80%，实现容器集群管理自动化与智能化。云原生加速向Serverless演进，华为云提供Serverless Kubernetes集群CCE Autopilot和Serverless容器实例CCI两款Serverless容器产品，帮助用户专注于构建应用程序，助力企业加速业务创新。全新发布的通用型（轻享）、鲲鹏通用型两种高性价比Serverless容器算力，性价比最高可提升40%，是企业应对10倍潮汐业务的最优弹性方案。在未来，华为云将继续秉持携手创新、成就共享的理念，深耕云原生领域，帮助全球企业重塑业务模式，加快重塑千行万业，为建设包容、普惠、有韧性的数字世界注入新动力。来源：Gartner, Magic Quadrant for Container Management, 6 August 2025免责声明：Gartner 并未在其研究报告中支持任何供应商、产品或服务，也并未建议科技用户只选择该等获最高评分或其它称号的供应商。Gartner 的研究报告含有 Gartner 研究与顾问组织的意见，且该意见不应被视作事实陈述。就该研究报告而言，Gartner 放弃做出所有明示或默示的保证，包括任何有关适销性或某一特定用途适用性的保证。GARTNER 和MAGIC QUADRANT是 Gartner, Inc. 和/或其关联公司在美国和国际上的商标，并在获得许可的情况下在此使用。保留所有权利。 更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

在 Kubernetes 中，**`Role`**、**`RoleBinding`** 和 **`ServiceAccount`** 三者共同构成了 **基于角色的访问控制（RBAC）机制**的核心框架。它们之间的关系可以理解为一种 **“策略 + 映射 + 主体”** 的组合逻辑。以下是详细解析：--- **核心概念速览**| 对象类型               | 作用                                                                 | 作用域          ||------------------------|--------------------------------------------------------------------|-----------------|| `ServiceAccount`       | **身份载体**：代表 Pod 的身份，用于身份验证                       | 命名空间级     || `Role`                | **权限模板**：定义一组可执行的操作（如 `get`, `list`, `create`） | 命名空间级     || `RoleBinding`         | **绑定关系**：将 `Role` 的权限授予给某个 `ServiceAccount`        | 命名空间级     || `ClusterRole`         | 类似 `Role`，但作用于整个集群                                   | 集群级         || `ClusterRoleBinding`  | 类似 `RoleBinding`，但可将 `ClusterRole` 绑定到任意 `ServiceAccount` | 集群级         |---**三者关系详解**#### 1️⃣ **`ServiceAccount` — “谁”（Who）**- **本质**：一个虚拟用户账号，属于某个命名空间。- **用途**：作为 Pod 的身份标识，其内部的容器可以通过此身份向 API Server 发起请求。- **关键行为**：  - 自动生成 JWT Token 并存入 Secret。  - Token 会被挂载到 Pod 的 `/var/run/secrets/kubernetes.io/serviceaccount/` 目录下。- **示例场景**：一个名为 `webapp-sa` 的 ServiceAccount 被分配给前端 Pod，使其能够拉取镜像或访问特定 Service。#### 2️⃣ **`Role` — “能做什么”（What）**- **本质**：一组预定义的权限规则集合。- **结构**：由多个 **Rule** 组成，每个 Rule 描述对某类资源的操作权限（如 `verbs: ["get", "list"]`, `resources: ["pods"]`）。- **作用域限制**：仅适用于当前命名空间内的资源（若需全局权限，需改用 `ClusterRole`）。- **示例规则**：  ```yaml  rules:  - apiGroups: [""]    resources: ["pods"]    verbs: ["get", "list", "watch"] # 允许查看本命名空间下的 Pod  ```#### 3️⃣ **`RoleBinding` — “关联谁来做”（To Whom）**- **本质**：建立 `Role` 与 `ServiceAccount` 之间的绑定关系。- **关键点**：  - **单向绑定**：一个 `RoleBinding` 只能将一个 `Role` 绑定到一个 `ServiceAccount`。  - **同命名空间生效**：`RoleBinding` 必须创建在目标 `ServiceAccount` 所在的命名空间内。  - **动态生效**：一旦绑定成功，对应 ServiceAccount 的 Pod 立即获得该角色的权限。- **示例绑定**：  ```yaml  apiVersion: rbac.authorization.k8s.io/v1  kind: RoleBinding  metadata:    name: webapp-rolebinding    namespace: frontend # 必须与 ServiceAccount 同命名空间  roleRef:    apiGroup: rbac.authorization.k8s.io    kind: Role    name: pod-reader # 引用已存在的 Role  subjects:  - kind: ServiceAccount    name: webapp-sa # 目标 ServiceAccount    namespace: frontend # 必须与上面一致  ```---**完整流程示例**假设我们要实现以下目标：  > **让 `frontend` 命名空间下的 `webapp-sa` ServiceAccount 能够查看本命名空间的所有 Pod。**#### 步骤 1：创建 ServiceAccount（身份）```bashkubectl create sa webapp-sa -n frontend```现在 `frontend` 命名空间下有了一个叫 `webapp-sa` 的身份。#### 步骤 2：创建 Role（权限模板）```yaml# role-pod-reader.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  namespace: frontend  name: pod-readerrules:- apiGroups: [""]  resources: ["pods"]  verbs: ["get", "list", "watch"]``` 这个角色定义了对 Pod 的读权限。#### 步骤 3：创建 RoleBinding（绑定关系）```bashkubectl apply -f rolebinding-webapp.yaml```其中 `rolebinding-webapp.yaml` 内容如下：```yamlapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: webapp-rolebinding  namespace: frontend # 关键！必须与 SA 同命名空间roleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: pod-reader # 引用上面创建的 Rolesubjects:- kind: ServiceAccount  name: webapp-sa # 目标 SA  namespace: frontend # 必须与上面一致``` 现在 `webapp-sa` 这个身份获得了 `pod-reader` 角色的权限。#### 验证效果部署一个使用 `webapp-sa` 的 Pod：```yaml# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: webapp  namespace: frontendspec:  replicas: 1  template:    spec:      serviceAccountName: webapp-sa # 关键！指定使用的 SA      containers:      - name: webapp-container        image: busybox        command: ["sleep", "3600"] # 保持运行以便测试```进入容器后尝试访问 API：```bash# 进入容器kubectl exec -it <pod-name> -- /bin/sh# 尝试获取 Pod 列表（会成功）curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \     -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \     https://kubernetes.default.svc/api/v1/namespaces/frontend/pods```如果返回 Pod 列表，说明权限生效。--- **权限层级对比表**| 组合                  | 适用场景                                                                 | 权限范围               ||-----------------------|--------------------------------------------------------------------------|------------------------|| `Role` + `RoleBinding` | 本命名空间内的精细化权限控制（推荐）                                   | 当前命名空间           || `ClusterRole` + `ClusterRoleBinding` | 跨命名空间的全局权限（如系统组件）                                 | 整个集群               || `Role` + `ClusterRoleBinding` | &#10060; 不允许：不能用集群级绑定关联命名空间级角色                      | N/A                   || `ClusterRole` + `RoleBinding`    | &#10060; 不允许：不能用命名空间级绑定关联集群级角色                     | N/A                   |---**常见误区 & 最佳实践**1. **避免过度授权**：不要直接使用 `edit` 或 `admin` 这类高风险角色，遵循最小权限原则。2. **命名空间隔离**：优先使用 `Role` + `RoleBinding`，避免不必要的集群级绑定。3. **定期审计**：通过 `kubectl get rolebindings --all-namespaces` 检查现有绑定关系。4. **使用工具可视化**：借助 `kubectl krew` 插件或第三方工具（如 Lens）查看 RBAC 拓扑图。5. **删除旧残留**：清理不再使用的 ServiceAccount、Role 和 Binding，防止僵尸权限。---**总结**| 元素               | 类比                     | 功能                          ||--------------------|--------------------------|-------------------------------|| `ServiceAccount`   | **身份证**               | 证明“你是谁”                  || `Role`             | **菜单清单**             | 规定“你可以吃什么菜”          || `RoleBinding`      | **服务员递菜单**         | 把菜单交给具体的客人（SA）    || `ClusterRole`      | **全国通用菜单**         | 适用于所有餐厅（命名空间）    || `ClusterRoleBinding` | **总部直接派发菜单**     | 跨餐厅（命名空间）分发菜单    |通过这种组合，Kubernetes 实现了灵活且安全的权限管理体系，既保证了多租户环境下的资源隔离，又能满足复杂场景下的权限需求。

在 Kubernetes (K8s) 中，**`ServiceAccount`** 是一种特殊类型的 **账户对象**，用于为 Pod 中的容器提供身份标识。它的核心作用是为 Pod 内的进程（如应用程序）授予对集群内资源的访问权限。以下是详细说明及查看方法：--- **一、什么是 ServiceAccount？**#### 核心功能：1. **身份标识**     每个 `ServiceAccount` 都有一个唯一的名称和一个关联的加密签名密钥对（存放在 Secret 中），用于证明请求来自该账户。   2. **权限控制**     通过与 **Role/ClusterRole** + **RoleBinding/ClusterRoleBinding** 的组合，定义此账户能执行的操作（如读写 ConfigMap、调用外部 API 等）。3. **自动挂载凭证**     当 Pod 使用了某个 `ServiceAccount`，Kubernetes 会自动将其凭证（包含 `CA证书`、`命名空间`、`Token`）注入到 Pod 的特定挂载点：   - `/var/run/secrets/kubernetes.io/serviceaccount/`   - 包括三个文件：`ca.crt`, `namespace`, `token`。 关键特点：| 特性                | 说明                                                                 ||---------------------|--------------------------------------------------------------------|| **作用域**          | 可作用于单个命名空间（默认）或整个集群（需配合 `ClusterRole`）       || **默认行为**        | 新创建的 Pod 若未显式指定 SA，则使用命名空间下的 `default` SA      || **安全性**          | 推荐遵循最小权限原则，仅授予必要权限                               |--- **二、如何查看 ServiceAccount 对象？**以下是常用查看方式及命令示例： 1. 查看当前命名空间的所有 ServiceAccount```bash# 查看当前命名空间的所有 SA（含简要信息）kubectl get serviceaccounts# 显示完整详细信息（JSON/YAML格式）kubectl get serviceaccounts -o wide          # 表格+额外字段kubectl get serviceaccounts -o json        # JSON格式kubectl get serviceaccounts -o yaml        # YAML格式```2. 查看指定命名空间的 ServiceAccount```bash# 查看名为 "my-namespace" 命名空间下的所有 SAkubectl get serviceaccounts --namespace=my-namespace# 查看特定 SA 的详细信息（如名为 "my-sa"）kubectl describe serviceaccount my-sa --namespace=my-namespace```3. 跨命名空间搜索 ServiceAccount```bash# 查看所有命名空间下的 SA 列表kubectl get serviceaccounts --all-namespaces``` 4. 导出 ServiceAccount 的配置为文件```bash# 将名为 "my-sa" 的 SA 配置导出为 YAML 文件kubectl get serviceaccount my-sa -n my-namespace -o yaml > my-sa.yaml```---**三、典型使用场景示例**假设你有一个名为 `app-pod` 的 Pod，它使用了自定义的 `app-sa` ServiceAccount，并绑定了一个允许读取 ConfigMap 的角色：```yaml# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: app-deploymentspec:  replicas: 1  template:    metadata: {}    spec:      serviceAccountName: app-sa # 指定使用的 ServiceAccount      containers:      - name: app-container        image: my-image```此时，`app-sa` 就是该 Pod 的身份标识，其权限由对应的 RoleBinding 决定。---**四、注意事项**1. **不要混淆 IAM 账号**     Kubernetes 的 `ServiceAccount` ≠ 云厂商的 IAM 账号，它是集群内部的虚拟身份。   2. **避免裸奔权限**     默认的 `default` SA 通常没有绑定任何角色，但如果你手动绑定了高权限角色（如 `edit`），可能导致安全风险。3. **多租户环境隔离**     在共享集群中，建议为不同团队/应用创建独立的 `ServiceAccount` 并严格限制权限。--- **五、相关概念扩展**| 对象类型           | 描述                                 ||--------------------|--------------------------------------|| `Role` / `ClusterRole` | 定义一组权限规则                     || `RoleBinding` / `ClusterRoleBinding` | 将角色绑定到 ServiceAccount         || `Pod`              | 使用 ServiceAccount 的主体            || `Secret`           | 存储 ServiceAccount 的私钥和令牌      |---**总结**- **`ServiceAccount` 是 Pod 的身份卡**，用于控制容器对集群资源的访问。- **查看命令**：`kubectl get serviceaccounts`（基础）、`kubectl describe serviceaccount <name>`（详情）。- **最佳实践**：为每个应用创建专用 SA，并按需绑定最小权限角色。

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起1500+课题，毕业超千名实习生，发放超过320万美金报酬。2025年秋季申请时间为 7月31日-8月12日，远程实习将从9月8日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于8月12日前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍  KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2025年8月12日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年秋季活动流程如下：Mentee 注册与项目申请 7月31日-8月12日申请者评审及人事工作 8月13日-8月26日实习启动及任务发放 9月8日中期考核及首次津贴支付 10月14日结项考核、实习生报告提交，最终津贴支付批准 11月25日 活动结束 11月28日申请者需要在8月12日前完成 Mentee 注册和项目申请，流程详见 [3]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在8月27日通知到申请人。主线开发日期为2025年9月8日 – 11月28日，全程线上协作，无需线下参与。结项需要在2025年9月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Deep Integration with AMD Edge Nodes (2025 Term 3)课题描述：AMD 芯片凭借其强大的 x86 架构、卓越的计算性能和先进的 NPU，在工业自动化、车载系统和高性能边缘计算等领域展现出显著潜力。将 AMD 强大的通用和异构计算能力引入 KubeEdge 生态系统，对于处理日益复杂和延迟敏感的边缘 AI 应用至关重要。然而，KubeEdge 与 AMD 高性能边缘平台之间的深度集成、性能优化和最佳实践，特别是它们内置的 NPU 和其他硬件加速单元，仍需系统性的探索和验证。本项目旨在建立 KubeEdge 与 AMD 边缘节点之间的完整链接，从硬件部署到 NPU 加速构建一个综合的边缘计算解决方案，从而极大丰富 KubeEdge 的硬件生态系统。预计输出件：支持 KubeEdge 边缘节点运行在 AMD 芯片上，并成功部署边缘应用通过 KubeEdge 调度和管理 AMD NPU 资源，以实现边缘 AI 推理应用的性能加速实现节点、应用和 NPU 的监控和指标收集使用 KubeEdge 实现从云到 AMD 边缘节点的完整平台设置、配置和管理完成硬件兼容性测试，并输出技术文档或博客前置技能：KubeEdge, Go, Linux, Hardware Integration, AI/ML课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/15043686-0866-4d5a-9016-3a6cbfd448fcGithub Issue：https://github.com/kubeedge/kubeedge/issues/6429▍KubeEdge: Device Anomaly Detection Framework (2025 Term 3)课题描述：当前的 KubeEdge 平台使用三种状态来表示设备状态：期望状态、观察到的期望状态和报告状态。平台上显示的设备状态完全依赖于 Mapper，该组件负责从设备端收集和报告数据。然而，由于 Mapper 实现的局限性、物理设备故障、网络延迟以及潜在的网络攻击，平台上显示的设备状态可能无法准确反映设备的实际状态。在 KubeEdge 平台中，如果应用程序依赖于设备状态进行决策，那么状态表示的不一致可能导致不良后果。因此，本项目旨在为 KubeEdge 设计一个设备状态异常检测框架。通过探索设备状态之间的因果关系，该框架将建立轻量级的异常检测能力，并提供一个全面的工具链，包括数据收集、模型训练、实时异常检测和结果可视化。预计输出件：通用的设备异常检测框架，支持用户自定义的检测算法完整的技术设计文档，包括模型选择、训练流程，以及训练和在线检测组件的详细架构图机器学习模型及相应的异常检测算法，能够捕捉设备状态之间的因果关系，并使用标准框架进行训练和测试集成到 KubeEdge 设备状态报告工作流程中的在线异常检测模块，通过模型推理钩子实现实时分析前置技能：KubeEdge,  IoT，Machine Learning课题导师：Liwei Shen (@meixiezichuan)shenliwei@fudan.edu.cnElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/8cf4ff37-e638-4b73-a5a1-521806ac8db1Github Issue：https://github.com/kubeedge/kubeedge/issues/6312▍KubeEdge: Deploy Small Language Models & OPEA Integration (2025 Term 3)课题描述：KubeEdge 作为一个基于 Kubernetes 生态系统构建的本地边缘计算平台，提供了可靠的云边通信、边缘自治和物联网设备集成等能力。然而，其在边缘支持智能模型的能力尚未在实际场景中得到系统验证和实践。本研究旨在探讨使用 KubeEdge 在边缘节点上部署和运行小语言模型的可行性和性能。预计输出件：验证 KubeEdge 在边缘的模型部署能力。在边缘节点上部署和测试 vLLM 和 llama.cpp 等模型引擎，并提供实际示例和详细文档，以便部署小型语言模型探索 KubeEdge 与 OPEA 平台之间的集成方案。将 KubeEdge 与 OPEA 的模型注册中心和工作流调度器连接，以支持从云到边缘节点的自动化模型分发和部署前置技能：KubeEdge, LLM, Golang, Python课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/2e9d0538-0941-4f10-8c52-9afd6294e16eGithub Issue：https://github.com/kubeedge/kubeedge/issues/6428▍KubeEdge: Comprehensive Example Restoration for Ianvs (2025 Term 3)课题描述：Ianvs 是 KubeEdge SIG AI 的分布式基准测试工具包，随着越来越多的贡献者参与，目前已有 25 个示例，且数量仍在增加。然而，由于依赖关系的演变和验证机制的影响，KubeEdge Ianvs 面临着日益突出的可用性问题。随着合作社区 Python 版本、第三方库和 Ianvs 特性的改进，部分历史示例无法执行。这导致用户报告的问题增多、贡献者时感困惑、未经测试 PR 影响特性功能、过时文档与实际能力不符等。如果不进行干预，这些示例可能会对边缘 AI 开发者，尤其是新手，带来开发阻碍。因此，我们尝试通过优化示例来提升 Ianvs 的可用性。预计输出件：发现和修复示例中的错误，包括依赖清单、License 扫描和运行时配置文档优化，包括重新设计教程，提供可复现的逐步指南，并发布面向开发者的调试手册，以应对常见故障构建一个 CI 流水线，使用 GitHub Actions 测试多个 Python 版本下的示例，关键的 Ianvs/Upstream 更新，并阻止破坏经过验证示例的 PR前置技能：Python, Benchmark, KubeEdge-Ianvs, AI/ML课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/82d71e63-2e1e-48d6-8c93-91c9e8bf8d5dGithub Issue：https://github.com/kubeedge/ianvs/issues/230▍KubeEdge: Industrial Benchmark Dataset for Ianvs (2025 Term 3)课题描述：随着工业制造通过机器人技术、自适应生产线和智能测试系统的进步加速数字化转型，云边协作已成为在复杂操作环境中部署具身智能的关键推动力。现代工业对具身智能的要求不仅限于基本任务执行，还扩展到多模态感知与决策集成、动态环境适应和分布式设备编排。现有的基准测试框架在评估工业环境中固有的场景特定具身属性方面存在局限。本项目利用 KubeEdge-Ianvs 协作 AI 框架，整合领域特定的测试数据集、仿真环境和定量指标，以建立一个认证的工业级评估基础设施，用于具身智能系统。预计输出件：通过对现有资源/示例进行系统分类和重组，开发一个工业级具身智能数据集部署基准算法并引入指标，以在 KubeEdge-Ianvs 中建立性能基准前置技能：Python, Benchmark, Dataset, Embodied Intelligence课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comMengzhuo Chen (@IcyFeather233)icyfeather@foxmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/c066ac53-5435-4057-a84c-0e0be62e8b65Github Issue：https://github.com/kubeedge/ianvs/issues/197 如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群 今年秋季，KubeEdge 社区期待在 LFX Mentorship 见到您！ Reference：[1] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible [2] LFX Mentorship - Program Readme: https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2025/03-Sep-Nov/README.md[3] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：https://connect.huaweicloud.com/courses/learn/course-v1:HuaweiX+CBUCNXNX022+Self-paced/aboutKubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

从LLMs大模型到Agent智能体，是人工智能时代下技术迅猛演进的里程碑之一。当进入2025年，大模型基础能力突破临界点，包括交互与理解能力、创造生成能力、长任务推理能力、工具使用能力等，驱动“AI Agent”成为确定性未来。Agent智能体凭借感知-认知-决策-行动的基本结构、以及在动态的现实环境中具备的自主执行与闭环能力，赋予更多人创建可持续的 AI 原生应用程序的能力，同时也为产业智能化升级注入强大动力。当Agent应用开发逐渐全民化，在各行业的土壤落地发芽，但是当面向更多复杂的行业场景、大型企业的定制化精确化需求，能实现向核心业务延伸并更注重实效的企业级AI Agent的重要性越发凸显。  Part01AI原生应用引擎由1.0全面升级至2.0——ModelArts Versatile，打造面向企业的通用AI智能体 华为云ModelArts Versatile-AI原生应用引擎应运而生，凭借企业级Agent的四个关键价值特征：专业（懂企业流程、懂企业数据）、高产（生成高效、作业高效）、主动（自主制造、智能交互）、安全（隐私保护、合规安全），从技术探索走向场景深耕，基于华为内部丰富的AI实践经验，打造企业专属AI数字生产线。Versatile在AI原生应用“工程平台”的基础上，增加通用AI智能体、场景AI能力、行业经验模板等能力，构筑“构建智能体时代的AgentOS”的全面平台能力。通用Agentic能力，支持开箱即用；垂域Agentic能力，支持扩展开发；构建以华为云为底座的繁茂AI生态；Versatile，从应用视角使能企业选好/用好/管好大模型，支撑智能应用创新。开发态AgentStudio：定位为AI应用工程，Agent的开发工具，一站式构建AI智能体，统一AI数据底座，动态上下文记忆使用态AgentSpace：为用户提供统一Agent入口，Agent统一交互入口，人与AI协同的智能入口，统一的Agent指挥中心运营态AgentGallery：以知识工程助力AI原生应用创新，提供Agent Map/MCPTools MapAgentOps：AI智能体的“运维中枢”， 承载Agent从“构成”到“养成”使命，全链路监控、评估和优化实现智能体的可观测、可管控、可迭代。  Part02ModelArts Versatile-AI原生应用引擎，打造最佳企业级Agent平台 01 元学习&规划智能体——Agent定义模板化，像写文档一样开发智能体，让人人都能构建自己的企业级智能体Versatile聚焦企业级智能体，走深向实，垂直行业，深度适配。基于企业知识底座，整合交互系统、推理系统、执行系统、记忆系统，借助“元学习(意为“学会如何学习”)的能力， 提取企业业务场景经验，如行政办公文档、业务运行文档，形成“文档化”开发Agent的新型极简方式，降低开发门槛，赋能更多企业领域开发者内化成基础技能。并通过Managing Agents的框架能力，完成更为精准的议题理解、记忆上下文、会话管理，最终实现企业经验提取，持续积累企业场景经验模板，动态经验知识库迭代的良性循环式运营，指导Agent输出专业级结果。关键技术剖析基于DeepSeek R1或其他Reasoning SOTA模型，提供通用Reasoning能力；通过预置“经验模板”提升垂域场景任务智能上限及任务效果；支持基于“生产任务”积累“轨迹数据”，叠加RL得到更优推理模型，以及持续积累优秀的任务“经验模板”，支持“经验模板Redo”及经验知识库迭代；   02 支持多智能体协同，实现企业10X+效率专家员工在Versatile平台核心引擎内置Managing Agents框架能力，内嵌多个专家级的智能体，包括Search Agents、Data Agents、Coding Agents、Operator Agents等一系列的Agent，便于开发者快速调用和编排。如围绕企业内“招聘”相关的业务流程，借助Versatile构建的招聘Agent，可基于目标的自主规划及多种工具调用，只需耗费5分钟便可覆盖招聘需求分析、候选人搜索、候选人筛选等繁琐的作业流程，并提供专家级高准确性的工作输出成果，真正做到“智能体分钟级工作输出，达成传统天级工作成果”的理想状态。关键技术剖析Versatile基于MoA架构和MCP协议，实现生态扩展及Multi Agent架构MoA是一种先进的多代理系统，专门为检索增强生成 （RAG）任务而设计。与以前的模型不同，MoA架构利用一组小型、专业的模型，以高度协调的方式协同工作，以更高的精度和更低的成本回答复杂的问题。MCP是一种标准化开放协议，为LLM提供标准化的上下文信息传递方式，简化AI模型与外部工具/数据的集成。MCP作为Agent背后的关键技术，被誉为“AI智能体领域的Type-C”。Versatile拥抱开源Agent协议，支持广泛的MCP生态及工具集成，平台集成了丰富的MCP Server模版资产，可快速复用模版资产快速部署MCP服务，并基于部署的MCP服务能够快速构建出千行百业的AI智能体。   03 支持多种智能交互，件件有着落，事事有回音，成为更加主动和自主的智能体为解决企业语境下，下达任务过程不可控、Agent难以实现精准自主闭环的困境，Versatile提供三方面能力，包括主动问询澄清、动态上下文生成、上帝视角督导。其中，主动问询澄清是当任务下发不够清晰时，智能体进行主动问询，事情交代越清楚，结果输出越准确。动态上下文生成对于执行效果起到非常关键的作用，上下文分成用户上下文、任务上下文和领域知识上下文三方面，通过这三个方面可360度理解用户所提交问题的背景、潜在诉求，让智能体比用户更懂用户自己。同时通过对任务分解，支持用户选择修改，让整个交互过程变得既简单又灵活。   04  AgentOps承载Agent从“构成”到“养成”使命，构建安全治理体系，实现三个“不”企业落地智能体，安全是底线，也是红线。所有没有安全保证的智能体几乎是无法生根落地的。Versatile借助华为公司的安全治理体系，包括安全策略、合规管理、反馈审计等一系列的底座的能力，构建数据清洗、Prompt攻击检测、不良内容检测三个主要能力，保障知识安全、交互安全、应用内容安全，实现学不到（使用敏感词、专家规则、检测模型清除原始预料中的有毒语料）、攻不破（攻击模式分析、恶意意图识别、感知增强能力，防御针对大模型的攻击行为）、生不成（安全围栏和风控检测能力，确保输出内容没有不良内容）关键技术剖析AgentOps关键支柱能力：调用链和重放分析：记录Agent行为、决策过程和交互结果，逐步解构整个任务流程，快速定位错误或问题；成本管理：监控和控制每个AI Agent与LLM和API的交互的费用，避免成本迅速膨胀；评估测试：根据标准化或自定义基准测试评估Agent性能，支持HITL和LLM-as-a-Judge；合规性和安全性：检测潜在的数据泄露、Prompt注入和未授权的API使用； Part03信通院重量级评估：Versatile获得智能体评估的最高等级证书，实力赋能更多企业开发者本年度6月，由中国信通院人工智能研究院向华为颁发智能体评估证书-工具和平台(5级)，华为成为业界首家获得最高等级证书的单位，ModelArts Versatile平台的专业度达到行业领先水平，加速实现“让人人都能构建自己的企业级智能体”的产品愿景。图：中国信通院人工智能研究院主任曹峰向华为云aPaaS产品部副部长杨建颁发智能体评估证书  Part04客户合作与行业实践ModelArts Versatile-AI原生应用引擎面向各类企业场景，加速AI原生应用落地。现已与政务、医疗、制造、电力、差旅、零售等行业客户合作，构建深耕行业的专业Agent助手，通过搭建企业级数字化AI产线，凭借“更专业、更高产、更主动”的产品优势，帮助实现业务效率的飞速提升。如：慧通差旅 X Versatile-AI原生应用引擎打造企业级差旅Agent，实现AI数字生产力跃升，加速差旅智能化：意图识别准确率提升5％：慧通差旅基于数据创新和模型创新联合Versatile智能交互，提升准确率。智能体开发效率提升3倍：通过文档化快速编排智能体，进行任务间有机协同。数据&算法迭代效率提升为天级：通过数据飞轮天级迭代，反哺模型，让慧通差旅构建的专属Agent越来越聪明。   <Versatile-AI原生应用引擎 体验入口> 华为开发者空间--开发平台--AI Agent（ ↑  ↑ 请在PC端点击进入↑  ↑）