企业官网建设流程全解析

KubeEdge v1.15 版本发布解读：Windows 边缘节点、Device API v1beta1、DMI 数据面与升级注意事项

【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge

本文以 KubeEdge 官方发布记录 CHANGELOG-1.15 为主体，完整梳理 v1.15.0 至 v1.15.4 五个版本的更新内容：v1.15.0 首次支持 Windows Server 边缘节点、发布 v1beta1 版 Device API 并引入 DMI 数据面与 Mapper-Framework（均为 Alpha），同时支持边缘节点上的原生 Static Pod 与 Kubernetes 非资源请求；文中还逐项说明升级前的关键约束（设备 API 不兼容、containerd 最低版本、dockershim 移除），并结合仓库源码验证了 Static Pod 路径、v1beta1 设备 CRD、Mapper-Framework 子项目等关键结论，帮助你在规划边缘集群版本升级时快速掌握每个版本的能力边界与风险点。

版本总览：v1.15.0 与四个补丁版本

CHANGELOG 文件 CHANGELOG-1.15.md 覆盖 KubeEdge v1.15 系列的五个版本。v1.15.0 是该系列的功能特性版本，v1.15.1 至 v1.15.4 为修复型补丁版本。各版本定位如下：

每个版本的具体下载方式见 CHANGELOG 中各版本的 "Downloads" 小节，指向对应 release 页面（各小节分别对应 v1.15.0 至 v1.15.4 五个 tag）。

v1.15.0 What's New：六大特性逐项解析

1. 支持基于 Windows 的边缘节点

边缘计算场景涵盖传感器、摄像头、工控设备等多种硬件，其中一部分运行 Windows 操作系统。v1.15 中 KubeEdge 支持边缘节点运行在Windows Server 2019上，并支持在边缘节点上运行Windows 容器，从而把 KubeEdge 扩展到 Windows 生态。

这一特性的技术背景可以结合仓库中的设计提案 edge-on-windows.md 理解：

• 该提案分析了 EdgeCore 各模块对操作系统的要求：DeviceTwin、MetaManager 依赖 SQLite，EventBus 依赖 MQTT 协议，这些均与操作系统无关；真正的问题点在Edged——它是裁剪版 kubelet，需要与 CRI 和系统资源隔离机制交互，而 Windows 下必须提供 containerd 等容器运行时；
• 方案是参照 kubelet 的 Windows 支持，补齐 Edged 缺失的 Windows 相关配置（如WindowsService与WindowsPriorityClass字段），然后交由 kubelet 的 app 框架完成其余工作；
• 实施任务包括：在 Windows Server 2019 上安装并验证 containerd、部署云端 CloudCore 环境、修改 Edged 源码支持 Windows 容器运行时配置、集成测试、更新 Keadm 支持 Windows 一键部署，以及修改发布脚本产出 Windows 版本二进制。

v1.15.1 的 changelog 中也印证了该特性的落地过程——"Support building Windows-amd64 release for EdgeCore and Keadm"（#5187）即为 Windows 版 EdgeCore 与 Keadm 的发布构建支持。

2. 全新 v1beta1 版本 Device API

设备 API 从v1alpha2升级到v1beta1，更新要点包括：

• 设备实例中内置的 Modbus、Opc-UA、Bluetooth 协议被移除；这些协议对应的内置 mapper 仍然存在，并会继续维护和更新到最新版本；
• 用户必须通过ProtocolConfig中的CustomizedValue定义协议配置；
• 新增 DMI 数据面相关字段：用户可以配置设备数据的采集与上报频率，以及数据推送的目标（如数据库、httpserver 等）；
• 新增控制设备数据是否上报云端的开关。

这一变更在仓库中有直接佐证：CloudCore 的 Helm Chart CRD 目录下，设备相关资源已经是 v1beta1 版本，见 devices_v1beta1_device.yaml、devices_v1beta1_devicemodel.yaml 和 devices_v1beta1_devicestatus.yaml。

3. DMI 数据面与 Mapper-Framework（Alpha）

v1.15 支持Alpha 版本的 DMI 数据面。DMI 数据面主要实现在 mapper 侧，提供推送数据、拉取数据和将数据存储到数据库三类接口。

同时，为了降低 mapper 开发门槛，本版本提供了 mapper 开发框架子项目Mapper-Framework：它提供 mapper 运行时库，以及用于脚手架和代码生成的工具，用户只需运行make generate命令生成一个 mapper 工程，然后只需补充协议相关代码即可。

从当前仓库结构看，Mapper-Framework 以子项目形式内嵌在 staging 目录中，例如 staging/src/github.com/kubeedge/mapper-framework，其中包含_template（脚手架模板，如 device.go）与公共配置解析（如 configmaptype.go）。mapper 的整体设计（twin value / data / device status 三类数据的处理流程）可进一步参考 mapper-design-v2.md。

4. 边缘节点支持 Kubernetes 原生 Static Pod

v1.15 在边缘节点上支持了 Kubernetes 原生Static Pod：用户只需将 Pod 清单文件放置到/etc/kubeedge/manifests目录，即可在边缘节点上创建 Pod，与 Kubernetes 节点上的用法一致。

源码中可以看到对应实现：edged 模块在构建 kubelet 配置后，会确保 Static Pod 目录存在——edge/pkg/edged/edged.go 中当kubeletConfig.StaticPodPath非空时执行os.MkdirAll创建该目录，失败则返回错误；路径本身通过 edge/pkg/edged/config/config.go 从 EdgeCore 配置透传。此外，Keadm 的重置流程也会清理该目录，见 keadm/cmd/keadm/app/cmd/reset_others.go：读取config.Modules.Edged.TailoredKubeletConfig.StaticPodPath并调用phases.CleanDir删除其中的静态 Pod 清单。

值得注意的是，v1.15.2 修复了 "Fix default staticPodPath in windows"（#5271），说明 Static Pod 能力在 Windows 边缘节点上也有落地，且默认路径经过专门适配。

5. 边缘节点支持更多 Kubernetes 原生插件运行

v1.15 支持从边缘节点发起 Kubernetes非资源类型请求/version：用户现在可以在边缘节点上通过 metaserver 发起/version请求。基于当前框架，还可以较容易地支持/healthz等其他非资源类型请求。许多依赖这类请求的 Kubernetes 插件（如 cilium/calico）因此可以在边缘节点上运行。

6. Kubernetes 依赖升级至 v1.26.7

v1.15 将 vendor 的 Kubernetes 版本升级到v1.26.7，用户可以在云端和边缘端使用新版本的特性。后续的补丁版本继续跟进 K8s 补丁升级：v1.15.1 升级到 1.26.10，v1.15.3 升级到 1.26.15。

升级前的重要步骤（Important Steps before Upgrading）

CHANGELOG 在 v1.15 部分明确列出了三条升级前必须处理的约束，这是本文档中实操价值最高的部分：

1. 设备 API 不兼容：KubeEdge v1.15 的 v1beta1 设备 API 与早期版本的 v1alpha1 不兼容。如果要使用 v1.15，需要将设备 API 的 yaml 更新为 v1beta1。对应地，仓库中 CloudCore CRD 已经全部切换为devices_v1beta1_*系列文件（见上文 CRD 目录列表）。
2. containerd 版本要求：v1.15 要求将 containerd 升级到v1.6.0 或更高版本，1.5 及更早的 containerd 小版本在 v1.15 中不受支持。该要求源于 Kubernetes 1.26 移除旧 CRI API 的变化（CHANGELOG 引用了 Kubernetes 官方博客中 "upcoming changes in kubernetes 1.26" 关于 CRI API removal 的说明）。
3. dockershim 已被移除：自 KubeEdge v1.14 起 EdgeCore 已移除 dockershim 支持，用户只能使用remote类型运行时，默认使用containerd。如果希望在 v1.15 中使用docker运行时，需要先设置edged.containerRuntime=remote，并在 EdgeCore 中配置RemoteRuntimeEndpoint与RemoteImageEndpoint等 docker 相关配置，然后按官方 issue #4843 中的文档安装 cri-dockerd 工具。

v1.15.1：13 项修复与改进明细

v1.15.1 相对 v1.15.0 的完整更新清单（继承自 CHANGELOG 原文）：

其中 "使用 ReportToCloud 判断是否将 mapper 设备数据推送到 EdgeCore"（#5116）与上文 v1beta1 API 新增的 "控制设备数据是否上报云端" 字段直接对应——Mapper-Framework 的脚手架模板中同样包含基于该开关的数据处理逻辑（参见 mapper-framework 模板）。

v1.15.2 至 v1.15.4：补丁版本的修复内容

v1.15.2（相对 v1.15.1）

• 修复 Windows 下的 default staticPodPath（#5271）；
• 修复 featuregates 在 edged 中未生效的问题（#5295）；
• 修复设备状态问题（#5336）；
• 支持不安装 CNI 插件的情况下安装 edgecore（#5367），降低了边缘节点部署的网络插件前置依赖。

v1.15.3（相对 v1.15.2）

• K8s 依赖升级至最新补丁版本 v1.26.15（#5706）；
• 修复边缘节点无法获取 IP 地址时 edgecore 不会重启的问题（#5717）——这是一个影响节点自愈能力的关键修复：断网/重新分配 IP 后 edgecore 能够重新建立与云端的连接。

v1.15.4（相对 v1.15.3）

• 修复NewErrorMessage函数中 parentID 的设置问题（#5735），涉及消息层的错误信息构造；
• 修复存储在边缘端的 PersistentVolumes 数据被异常删除的问题（#5888），该修复保护了边缘端本地持久化存储的可靠性。

小结：如何基于 v1.15 系列做版本选择

• 全新部署：直接选用最新的 v1.15.4，可获得全部 v1.15 特性与所有后续修复（尤其是边缘端 PV 数据异常删除的修复）；
• 从 v1.14 及更早版本升级：先完成"升级前重要步骤"中的三项检查——设备 yaml 迁移到 v1beta1、containerd 升级到 v1.6.0+、确认运行时为remote类型（默认 containerd）；如需 docker 运行时则按 cri-dockerd 方案配置；
• 使用设备类功能：v1.15 系列是 v1beta1 Device API 的起点，同时提供 DMI 数据面（Alpha）与make generate一键脚手架的 Mapper-Framework，适合规划设备接入方案的团队从 v1.15.4 起步。

如需进一步深入某个特性，建议结合本仓库中的对应资料：Windows 边缘节点设计见 docs/proposals/sig-node/edge-on-windows.md，设备模型与 mapper 设计见 docs/proposals/sig-device-iot/ 目录，设备 CRD 定义见 manifests/charts/cloudcore/crds/ 目录。

【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge