华为云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端点击进入↑  ↑）

Karmada 社区非常高兴地宣布中科类脑正式加入Karmada 用户组[1]（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。中科类脑的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。  关 于 中 科 类 脑 合肥中科类脑智能技术有限公司[2]成立于2017年，是一家专注于类脑智能技术研发与应用的国家高新技术企业、国家级专精特新“小巨人”企业。公司在机器视觉大模型、小样本学习、因果视觉与因果推理、稳定学习、类脑博弈优化决策等多个人工智能前沿技术领域处于行业先进地位，广泛应用于算力基础设施、智慧能源和算电碳协同发展三大业务领域。中科类脑秉承“推动前沿智能技术落地，助力产业数智升级”的使命，持续推出创新的智能化产品及解决方案，力求打造垂直领域人工智能应用的深度闭环。公司致力于成为全球领先的能源智能服务企业，致力于成为全球AI生态建设者。  关于Karmada用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的35+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters    欢迎加入用户组   任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会，Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [3]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组 更多信息，请访问：[1] Karmada Adopter Group 详细信息，请查阅: https://github.com/karmada-io/community/tree/main/adopter-group[2] 中科类脑: http://www.leinao.ai/[3] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yaml Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系:Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io 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进入技术交流群

近期，全球领先的IT市场研究和咨询公司IDC发布了《中国软件定义计算软件市场跟踪，2024H2》报告。报告显示，华为云在2024年中国容器软件市场的份额及增速均位居第一，展现了华为云在云原生领域的领先地位，也体现了客户对华为云的高度认可与信赖。IDC在报告中指出：2024年，容器基础设施软件（CIS）成为整体市场的增长驱动力，预计到2027年将占据SDC软件市场的三分之一。在AI领域，由于其开放性和现代化的功能集，Kubernetes目前已成为AI应用的默认底座。2024年层出不穷的智算中心，大模型平台建设，生成式AI应用构建的项目为容器基础架构软件市场带来新机会。华为云在云原生领域持续创新，在业界率先发布CCE（Cloud Container Engine) （含CCE Turbo/CCE Autopilot）、CCI（Cloud Container Instance）以及UCS（Ubiquitous Cloud Native Service）等多款创新性容器产品，持续引领云原生产业发展。面向AI时代，云原生2.0全面智能化，构建智能驱动的全新一代AI-Native云原生基础设施。CCE智算集群作为CloudMatrix384 超节点的容器底座，提供超节点拓扑感知调度、PD分离扩缩容、AI负载感知的弹性扩缩容及容器极速启动等能力，大幅加速AI训练和推理，提升AI任务运行效率。与此同时，AI技术也在重塑云服务体验，华为云全新发布CCE智能助手，以AI Agent方式嵌入容器使用全流程，贯穿智能问答、智能推荐、智能诊断、智能托管等业务流程，实现容器集群管理的自动化与智能化，助力企业加速创新。 基于前沿技术积累，华为云携手伙伴，以云原生技术为核心驱动力，加速云、AI等前沿技术在各行业的深度融合与落地应用，广泛服务金融、政务、能源、制造等行业客户，助力企业高效构建现代化云原生架构，加速数字化转型进程和智能化升级，释放数字经济新动能。▍在金融领域华为云云原生技术凭借其卓越的性能和创新力，已成为金融行业数字化转型的核心引擎，为金融分布式新核心系统提供了坚实的底座，全方位引领行业智能化升级的潮流，定义了金融领域云原生技术的新高度。目前，华为云已为中国六大银行、12家股份制商业银行及众多保险证券客户提供全方位服务，全球服务金融机构超500家。光大银行基于华为云Stack启动全栈云建设，凭借CCE Turbo和鲲鹏算力两大性能引擎，实现大规模容器集群管理，极大提升资源利用率，彰显了华为云在金融领域的卓越实力。▍在政务云领域华为云自2012年起持续深耕，凭借领先的技术与服务，累计服务超过800个政务云项目，为政府机构数字化转型提供强大动力，显著提升服务民生效率。国家统计局为响应“推动现代化信息技术与统计工作深度融合”的要求，基于华为云Stack打造全新统计云，并首次采用云原生架构。以CCE Turbo为核心的云原生基础设施，凭借其极致弹性，灵活应对全国经济普查、联网直报、住户调查、价格调查等大规模及周期性查询需求。在第五次全国经济普查中，统计云成功完成首次大规模查询实战，成为统计信息化建设的里程碑，彰显华为云在政务云领域的卓越表现和领先地位。▍在制造领域华为以“深耕制造，让智能生根”为价值主张，致力于依托5G、云计算、大数据、人工智能等新ICT技术，赋能传统制造企业，助力制造企业实现研发、生产、供应等业务的智能化，重塑制造行业价值链。长安汽车数智工厂以CCE为底座，打造集团+工厂的云边端协同架构，通过云原生基础设施的弹性、敏捷全面提升C2M模式柔性生产力，支持1万多种整车配置的个性化生产，订单交付周期缩短20%。长安汽车数智工厂的数字化转型先行先试，推动长安汽车率先驶入智造快车道，为汽车行业迈向智能制造提供了重要参考。未来，华为云将持续聚焦云原生技术创新、产品升级以及生态繁荣，继续携手全球客户，将领先的技术与行业知识相结合，助力企业数智化转型，成就卓越企业，共赴智能未来。 更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

7月1日起，开源之夏2025为期三个月的项目开发正式拉开序幕。历经导师、社区、组委会三轮审核，共有18位海内外高校同学在激烈的竞争中脱颖而出，成功中选KubeEdge社区任务，中选学生将在社区导师的指导下，完成项目开发。KubeEdge 社区期待和计算机领域新生力量一起薪火相传，共启云原生边缘计算无限可能。中选名单公示重要时间节点一览学生指南：https://blog.summer-ospp.ac.cn/help/student%20guide# 关于开源之夏“开源之夏（英文简称 OSPP）”是中国科学院软件研究所“开源软件供应链点亮计划”指导下的系列暑期活动，由中国科学院软件研究所和华为技术有限公司共同主办，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。  社区小助手k8s2222回复KubeEdge进入技术交流群 【更多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地址 : cid:link_0Slack地址 : 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/ 

7月1日，开源之夏2025为期三个月的项目开发正式拉开序幕。历经导师、社区、组委会三轮审核，共有6位海内外高校同学在激烈的竞争中脱颖而出，欢迎同学们的加入！成功中选Karmada社区任务的同学，将在社区导师的指导下，开启云原生多云多集群前沿课题共创。# 中选名单公示（Karmada）# 重要时间节点一览 学生指南：https://blog.summer-ospp.ac.cn/help/student%20guide# 关于开源之夏“开源之夏（英文简称 OSPP）”是中国科学院软件研究所“开源软件供应链点亮计划”指导下的系列暑期活动，由中国科学院软件研究所和华为技术有限公司共同主办，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。 添加社区小助手k8s2222回复Karmada进入技术交流群 Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

Karmada是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.14 版本[1] 现已发布，本版本包含下列新增特性：新增联邦资源配额管理能力，用于多租户场景下资源治理新增定制化污点管理能力，消除隐式集群故障迁移Karmada Operator 功能持续演进Karmada 控制器性能显著提升 新 特 性 概 览 ▍联邦资源配额管理在多租户的云基础设施中，配额管理是确保资源公平分配和防止超额使用的关键。尤其在多云多集群环境下，分散的配额系统往往导致资源监控困难和管理割裂，因此实现跨集群的联邦配额管理成为提升资源治理效率的核心要素。此前，Karmada 通过 FederatedResourceQuota 将全局配额分配至成员集群，由各集群本地实施配额管控。本次版本升级增强了联邦配额管理能力，新增控制平面全局配额检查机制，支持直接在控制平面进行全局资源配额校验。该功能特别适用于以下场景：您需要从统一位置跟踪资源消耗和限制，而无需关注集群级别的分配情况。您希望通过验证配额限制来避免超额的任务提交。注意：该特性目前处于 Alpha 阶段，需要启用 FederatedQuotaEnforcement Feature Gate 才能使用。假设您想设置总体 CPU 限制为 100，您可以按照如下配置进行定义：apiVersion: policy.karmada.io/v1alpha1kind: FederatedResourceQuotametadata: name: team-foo namespace: team-foospec: overall: cpu: 100一旦应用，Karmada 将开始监控和执行 test 命名空间的 CPU 资源限制。假设您应用了一个需要 20 个 CPU 的新 Deployment。联邦资源配额的状态将更新为如下所示：spec: overall: cpu: 100status: overall: cpu: 100 overallUsed: cpu: 20如果您应用的资源超过 100 个CPU的限制，该资源将不会被调度到您的成员集群。有关此功能的详细用法，可以参考特性使用文档：Federated ResourceQuota[2]。▍定制化污点管理在 v1.14 之前的版本中，当用户启用故障转移功能时，系统在检测到健康状态异常后会自动向集群添加一个 NoExecute effect 污点，从而触发目标集群上所有资源的迁移。在这个版本中，我们对系统中潜在的迁移触发因素进行了全面审查。所有隐含的集群故障转移行为已被消除，并且引入了针对集群故障机制的明确约束条件。这使得因集群故障而引发的资源迁移能够得到统一管理，进一步增强了系统的稳定性和可预测性。集群故障条件是通过评估出现故障的集群对象的状态条件来确定的，以便应用污点，这一过程可以称为“Taint Cluster By Conditions”。此版本引入了一个新的 API - ClusterTaintPolicy，它允许用户自定义规则，以便在预定义的集群状态条件得到满足时，为目标集群添加特定的污点。对于更复杂的集群故障判断场景，用户可以直接实现一个自定义的“集群污点控制器”，以控制如何向集群对象添加或移除污点。ClusterTaintPolicy 是一种 Cluster scope 资源，下面我们给一个简单的例子来说明它的用法：apiVersion: policy.karmada.io/v1alpha1kind: ClusterTaintPolicymetadata: name: detect-cluster-notreadyspec: targetClusters: clusterNames: - member1 - member2 addOnConditions: - conditionType: Ready operator: NotIn statusValues: - "True" - conditionType: NetworkAvailable operator: NotIn statusValues: - "True" removeOnConditions: - conditionType: Ready operator: In statusValues: - "True" - conditionType: NetworkAvailable operator: In statusValues: - "True" taints: - key: not-ready effect: NoSchedule - key: not-ready effect: NoExecute上面的例子描述了一个针对 member1 和 member2 集群的 ClusterTaintPolicy 资源，当集群的状态条件同时满足 Type 为 Ready 和 NetworkAvailable 的 condition value 不等于 True 时，会为目标集群添加污点 {not-ready:NoSchedule} 与 {not-ready:NoExecute}；当集群的状态条件同时满足 Type 为 Ready 和 NetworkAvailable 的 condition value 等于 True 时，会移除目标集群上的污点 {not-ready:NoSchedule} 和 {not-ready:NoExecute}。有关此功能的详细用法，可以参考特性使用文档：集群污点管理[3]。▍Karmada Operator 功能持续演进本版本持续增强 Karmada Operator，新增以下功能：支持配置 Leaf 证书有效期。支持 Karmada 控制平面暂停调谐。支持为 karmada-webhook 组件配置 feature gates。支持为 karmada-apiserver 组件执行 loadBalancerClass 以选择特定的负载均衡实现。引入 karmada_build_info 指标来展示构建信息，以及一组运行时指标。这些改进使得karmada-operator更加灵活且可定制，提高了整个Karmada系统的可靠性和稳定性。▍Karmada 控制器性能显著提升自 1.13 版本发布以来，Karmada adopters 自发组织起来对 Karmada 性能进行优化。如今，一个稳定且持续运作的性能优化团队 SIG-Scalability 已经组建，致力于提升 Karmada 的性能与稳定性。感谢所有参与者付出的努力。如果大家有兴趣，随时欢迎大家加入。在本次版本中，Karmada 实现了显著的性能提升，尤其是在 karmada-controller-manager 组件中。为验证这些改进，实施了以下测试设置：测试设置包括 5000 个 Deployment，每个 Deployment 都与一个相应的 PropagationPolicy 配对，该策略将其调度到两个成员集群。每个 Deployment 还依赖一个唯一的 ConfigMap，它会与Deployment 一起分发到相同的集群。这些资源是在 karmada-controller-manager 组件离线时创建的，这意味着在测试期间 Karmada 首次对它们进行同步。测试结果如下：冷启动时间（清空工作队列）从约 7 分钟缩短至约 4 分钟，提升了 45%。资源检测器：平均处理时间的最大值从 391 毫秒降至 180 毫秒（提升了 54%）。依赖分发器：平均处理时间的最大值从 378 毫秒降至 216 毫秒（提升了 43%）。执行控制器：平均处理时间的最大值从 505 毫秒降至 248 毫秒（提升了 50%）。除了更快的处理速度，资源消耗也显著降低：CPU使用率从 4 - 7.5 核降至 1.8 - 2.4 核（降幅 40% - 65%）。内存峰值使用量从 1.9 GB 降至 1.47 GB（降幅 22%）。这些数据证明，在 1.14 版本中，Karmada 控制器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。相关的详细测试报告，请参考 [Performance] Overview of performance improvements for v1.14[4] 。 致 谢 贡 献 者 Karmada v1.14 版本包含了来自 30 位贡献者的 271 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：相关链接[1] Karmada v1.14 版本: https://github.com/karmada-io/karmada/releases/tag/v1.14.0[2] Federated ResourceQuota: https://karmada.io/zh/docs/userguide/bestpractices/federated-resource-quota/[3] 集群污点管理: https://karmada.io/docs/next/userguide/failover/cluster-taint-management/[4] [Performance] Overview of performance improvements for v1.14: https://github.com/karmada-io/karmada/issues/6394Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。添加社区小助手k8s2222回复Karmada进入技术交流群Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

北京时间2025年6月18日，KubeEdge 发布1.21.0版本。新版本对节点任务框架（节点升级、镜像预下载）做了全面更新，并新增云端更新边缘配置的能力，同时 Dashboard 新增对 keink 的集成，支持一键部署，在易用性、管理运维能力上做了全面增强。KubeEdge v1.21.0 新增特性：全新节点任务 API 以及实现节点组流量闭环优化 支持在云端更新边缘配置集成 kubeedge/keink，支持一键部署 Dashboard  新特性概览  ▍全新节点任务API以及实现 当前 KubeEdge 中的节点任务资源（节点升级、镜像预下载）的状态设计较为复杂，可读性较差。此外，在执行节点任务的过程中，一些错误不会被记录到状态中导致无法定位任务失败的原因。因此我们对节点状态和运行流程进行了重新设计，设计目标如下：定义一个新的节点任务的状态结构，使其更易于用户和开发者理解跟踪整个流程的错误信息，将其写入状态中展示开发一个更合理的节点任务流程框架在新的设计中，节点任务的状态由总阶段（phase）和各节点执行任务的状态（nodeStatus）组成。节点任务的阶段（phase）有四个枚举值分别为：Init、InProgress、Completed 或 Failure，该值通过每个节点的执行状态计算所得。节点执行任务的状态由阶段（phase）、节点执行的动作流（actionFlow）、节点名称（nodeName）、执行动作流以外的错误原因（reason）以及业务相关的一些字段（如镜像预下载任务的每个镜像下载状态）组成。节点执行任务的阶段（phase）有五个枚举值分别为：Pending、InProgress、Successful、Failure 和 Unknown。动作流是一个数组结构，记录了每个动作（action）的执行结果，状态（Status）复用了 Kubernetes 的 ConditionStatus，用 True 和 False 表示动作的成功或失败，并且记录了动作的失败原因（reason）和执行时间（time）。👇🏻 节点升级任务的状态 YAML 样例如下：status: nodeStatus: - actionFlow: - action: Check status: 'True' time: '2025-05-28T08:12:01Z' - action: WaitingConfirmation status: 'True' time: '2025-05-28T08:12:01Z' - action: Backup status: 'True' time: '2025-05-28T08:12:01Z' - action: Upgrade status: 'True' time: '2025-05-28T08:13:02Z' currentVersion: v1.21.0 historicVersion: v1.20.0 nodeName: ubuntu phase: Successful phase: Completed我们对节点任务的云边协作流程也进行了重新设计。为了避免 CloudCore 多实例导致的节点任务更新产生并发冲突，我们将节点任务的初始化和节点任务的状态计算放在 ControllerManager 中处理，因为 ControllerManager 总是单实例运行的。👇🏻 具体流程如下：1. 当节点任务 CR 被创建后，ControllerManager 会初始化匹配的节点的状态；2. CloudCore 只会处理 ControllerManager 处理过的节点任务资源，通过执行器（Executor）和下行控制器（DownstreamController）将节点任务下发给节点；3. EdgeCore 接收到节点任务后，通过运行器（Runner）执行动作，并将每个动作的执行结果上报给 CloudCore；4. CloudCore 通过上行控制器（UpstreamController）接收动作运行的结果并将结果更新到节点任务的状态中；5. ControllerManager 监听节点任务资源的变化计算整个节点任务的状态进行更新。在整个处理流程中，我们将流程中可能产生的错误都记录并更新到了节点任务资源状态的原因字段中。更多信息可参考：cid:link_0/blob/master/docs/proposals/edge-node-tasks-status-enhancement.mdcid:link_0/issues/5999cid:link_0/issues/6211cid:link_0/issues/6273▍节点组流量闭环优化 在 KubeEdge 1.21.0 中，我们对节点组的流量闭环功能进行了全面优化，使其功能更完善、使用更灵活。这一功能的核心能力是：通过一个 Service 实现“节点组内应用只能访问同组内应用服务，无法访问其他节点组的服务。借助该机制，用户可以轻松实现边缘多区域间的网络隔离，确保不同区域的应用服务之间互不干扰。➤ 应用场景举例：以连锁门店为例，企业可将全国各地的门店按区域划分为多个节点组（如华东、华北、西南等），每个区域的门店部署相同类型的应用（如库存管理、收银系统），但业务数据互相隔离。通过流量闭环功能，系统可自动限制服务访问范围，仅在节点组内互通，避免跨区域访问，无需额外配置网络策略。流量闭环功能为可选项。如果用户不希望开启节点组间的流量隔离，只需在 EdgeApplication 中不配置 Service 模板，系统则不会启用该能力，应用依然可以按原有方式进行通信。👇🏻 使用样例：apiVersion: apps.kubeedge.io/v1alpha1kind: NodeGroupmetadata: name: beijingspec: nodes: - node-1 - node-2---apiVersion: apps.kubeedge.io/v1alpha1kind: NodeGroupmetadata: name: shanghaispec: nodes: - node-3 - node-4---apiVersion: apps.kubeedge.io/v1alpha1kind: EdgeApplicationmetadata: name: test-service namespace: defaultspec: workloadScope: targetNodeGroups: - name: beijing overriders: resourcesOverriders: - containerName: container-1 value: {} - name: shanghai overriders: resourcesOverriders: - containerName: container-1 value: {} workloadTemplate: manifests: - apiVersion: v1 kind: Service metadata: name: test-service namespace: default spec: ipFamilies: - IPv4 ports: - name: tcp port: 80 protocol: TCP targetPort: 80 selector: app: test-service sessionAffinity: None type: ClusterIP - apiVersion: apps/v1 kind: Deployment metadata: labels: kant.io/app: '' name: test-service namespace: default spec: replicas: 1 selector: matchLabels: app: test-service template: metadata: labels: app: test-service spec: containers: - name: container-1 ... terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: node-role.kubernetes.io/edge operator: Exists使用样例更多信息可参考：cid:link_0/pull/6097cid:link_0/pull/6077▍支持在云端更新边缘配置 相较于登录每个边缘节点手动更新 EdgeCore 的配置文件 edgecore.yaml，能够直接从云端更新 edgecorer.yaml 要更便利。尤其是对于批量节点操作，同时更新多个边缘节点的配置文件，能够提高管理效率，节约很多运维成本。在v1.21.0中，我们引入了ConfigUpdateJob CRD，允许用户在云端更新边缘节点的配置文件。CRD 中的 updateFields 用于指定需要更新的配置项。👇🏻 CRD 示例：apiVersion: operations.kubeedge.io/v1alpha2kind: ConfigUpdateJobmetadata: name: configupdate-testspec: failureTolerate: "0.3" concurrency: 1 timeoutSeconds: 180 updateFields: modules.edgeStream.enable: "true" labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""💭 注意：该特性在1.21中默认关闭，如需使用，请启动云端的 controllermamager 和 taskmanager 以及边缘端的 taskmanager 模块 更新边缘配置会涉及 EdgeCore 重启更多信息可参考：cid:link_0/pull/6024cid:link_0/pull/6338▍集成kubeedge/keink，支持一键部署Dashboard新版本对 Dashboard 进行了增强，为 KubeEdge 控制面板设计了一个 BFF（Backend for Frontend）层，以连接前端用户界面层和 KubeEdge 后端 API。它作为数据传输和处理中心，提供专用的后端服务，简化了前端的数据检索逻辑，提高了性能和安全性。此外，为了让开发人员快速体验和部署 kubeedge，我们与 kubeedge/keink 项目深度集成。只需一条命令，在 dashboard 上就能快速启动 kubeedge 环境，对其功能进行完整的演示和验证。更多信息可参考：https://github.com/kubeedge/dashboard/pull/50 版本升级注意事项 ▍节点任务新版本默认开启 v1alpha2 版本的节点任务，CRD 定义会向下兼容，如果想继续使用 v1alpha1 版本的 NodeUpgradeJob 和 ImagePrePullJob，可以通过设置ControllerManager 和 CloudCore 的特性门切换。ControllerManager 添加启动参数--feature-gates=disableNodeTaskV1alpha2CloudCore 修改配置文件kubectl edit configmap -n kubeedge cloudcore修改配置内容：apiVersion: cloudcore.config.kubeedge.io/v1alpha2 kind: CloudCore+ featureGates:+ disableNodeTaskV1alpha2: true ...💭 注意：v1alpha2 版本节点任务的 CRD 能兼容 v1alpha1，但是它们不能相互切换，v1alpha1 的代码逻辑会破坏 v1alpha2 节点任务 CR 的数据。v1alpha1 的节点任务基本不会再进行维护，v1.23 版本后将删除 v1alpha1 版本节点任务的相关代码。另外，节点任务在边端已成为一个默认关闭的 Beehive 模块，如果要正常使用节点任务功能的话，需要修改边端 edgecore.yaml 配置文件开启： modules: ...+ taskManager:+ enbale: true▍边缘节点升级我们对 Keadm 边缘节点升级的相关命令（备份、升级、回滚）做了调整：1. 升级命令不会自动执行备份命令，备份命令需要手动触发；2. 升级命令隐藏了业务相关的参数，v1.23 版本后会清理废弃的代码；3. 升级的相关命令都使用三级命令： keadm edge upgrade keadm edge backup keadm edge rollback▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.21 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0/blob/master/CHANGELOG/CHANGELOG-1.21.md【更多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地址 : cid:link_0Slack地址 : 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/