云原生计算基金会（CNCF）多云容器编排引擎 Karmada 宣布，彭博（Bloomberg）[1]正式加入 Karmada 用户组[2]。Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。Bloomberg 的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着 Karmada 在社区发展和多样化生产环境中采用的又一个重要里程碑。   关于 Bloomberg  彭博（Bloomberg）是全球商业与金融信息领域的领军者，提供值得信赖的数据、新闻与深度洞察，为市场注入透明度、提升效率并维护公平性。Bloomberg 借助可靠的技术解决方案，助力全球金融生态系统中具有影响力的各方建立连接，帮助客户做出更明智的决策，并促进更高效的协作。Bloomberg 采用 Karmada 管理本地训练集群，并调度 GPU/CPU 工作负载，更多技术细节请参考 KubeCon + CloudNativeCon 演讲分享：Bloomberg’s Journey to Improve Resource Utilization in a Multi-Cluster Platform- Yao Weng, Leon Zhou[3]Bloomberg's Journey to Manage a Multi-Cluster Training Application with Karmada - Y. Zhang, W. Lai[4]Flink on Karmada: Building Resilient Data Pipelines on Multi-Cluster K8s - Michas Szacillo & Wang Li[5]AI Workload Preemption in a Multi-Cluster Scheduling System at Bloomberg - Leon Zhou & Wei-Cheng Lai[6]Multi-cluster Orchestration System: Karmada Updates and Use Cases - Hongcai Ren & Joe Nathan Abellard[7]  关于 Karmada 用户组  Karmada 用户组是一个由在其环境中成功采用 Karmada 的组织和用户组成的社区。成员分享他们的经验、最佳实践和反馈，以帮助改进 Karmada 并培育一个充满活力的协作生态系统。成为 Karmada 用户组成员具有以下几个优势：社区认可：作为云原生多集群管理领域的领导者来展示您的组织，在 CNCF 和 Karmada 社区中获得知名度。促进协作：与其他采用者建立联系，分享最佳实践，并在实际用例和解决方案上进行协作。保持信息同步：及时接收重要更新通知，包括关键功能、错误修复和安全建议。技术影响力构建：受邀参与 Karmada 相关活动，包括 KubeCon + CloudNativeCon、网络研讨会和聚会。职位发布：有机会在 Karmada 社区支持的职位公告板上发布与 Karmada 相关的职位空缺（目前暂不可用）。扩展商业机会：与 Karmada 生态系统的其他成员建立潜在的商业联系和合作。截至目前，Karmada 用户组已吸纳来自全球的40+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters  欢迎加入用户组  Karmada 用户组对当前正在生产环境中使用 Karmada 的最终用户和供应商开放。这包括：最终用户：在其生产环境中运行 Karmada 的组织。供应商：提供基于 Karmada 的产品或服务，并有客户在生产环境中使用这些产品或服务的公司。当前，加入 Karmada 用户组对社区贡献没有硬性要求，Karmada 鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [8]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组Karmada（https://karmada.io/）是CNCF首个跨云跨集群容器编排引擎，由华为云、工商银行、小红书、中国一汽等八家企业联合发起。该项目于2021年4月正式开源，同年9月正式成为CNCF官方项目。Karmada的贡献企业与贡献者遍布全球22个国家和地区的100多个组织，包括华为、道客、浙江大学、腾讯、滴滴、Bloomberg、Yunhorn、携程等。截至目前，该项目在GitHub上已获得5.1k+Star。如需了解更多关于 Karmada Adopter Group 的信息，请联系: Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io更多信息，请访问：[1] 彭博（Bloomberg）: https://www.techatbloomberg.com/opensource/[2] Karmada 用户组: https://github.com/karmada-io/community/tree/main/adopter-group[3] Bloomberg’s Journey to Improve Resource Utilization in a Multi-Cluster Platform- Yao Weng, Leon Zhou: https://www.youtube.com/watch?v=lMtCSaHI9Uk[4] Bloomberg's Journey to Manage a Multi-Cluster Training Application with Karmada - Y. Zhang, W. Lai: https://www.youtube.com/watch?v=PmaiEKpM1-Q[5] Flink on Karmada: Building Resilient Data Pipelines on Multi-Cluster K8s - Michas Szacillo & Wang Li: https://www.youtube.com/watch?v=mqXZ2T-jWuU[6] AI Workload Preemption in a Multi-Cluster Scheduling System at Bloomberg - Leon Zhou & Wei-Cheng Lai: https://www.youtube.com/watch?v=LrL5AcS2d5g[7] Multi-cluster Orchestration System: Karmada Updates and Use Cases - Hongcai Ren & Joe Nathan Abellard: https://www.youtube.com/watch?v=rbVV8WIJYww[8] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yaml 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 Autopilot 集群是一款兼容 Kubernetes 并支持客户免运维的 Serverless 版集群。客户无需购买和管理节点，只需关注应用业务逻辑的实现，大幅降低运维成本，提升应用可靠性与扩展性。CCE Autopilot 适用于敏态业务快速创新、潮汐业务弹性伸缩、批量计算等多种场景，助力企业应对多样化需求。 链接访问体验：cid:link_0 

实例一直处于创建中，事件中存在“添加存储失败”的告警，事件信息如下所示：

节点上的工作负载一直处于创建中，该怎么解决此问题

工作负载详情中，若事件中提示“启动容器失败”，该怎么解决此问题

当工作负载状态显示“实例未就绪：Back-off pulling image "xxxxx"”，该状态下工作负载实例K8s事件名称为“实例拉取镜像失败”或“重新拉取镜像失败”。

当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协议通过结构化的领导权设计和严格的日志复制机制，在保证强一致性的同时提供了良好的可扩展性和容错能力。其模块化思想和清晰的状态转换逻辑使其成为分布式系统领域的重要基础组件。