KubeEdge 发布 v1.15.0 版本。新版本新增多个增强功能，在边缘节点管理、边缘应用管理、边缘设备管理等方面均有大幅提升。
KubeEdge v1.15.0 新增特性：
- 支持 Windows 边缘节点
- 基于物模型的新版本设备管理 API v1beta1发布
- 承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布
- 支持边缘节点运行静态 Pod
- 支持更多的Kubernetes原生插件运行在边缘节点
新特性概览
支持 Windows 边缘节点
随着边缘计算应用场景的不断拓展，涉及到的设备类型也越来越多，其中包括很多基于Windows 操作系统的传感器、摄像头和工控设备等，因此新版本的KubeEdge 支持在 Windows 上运行边缘节点，覆盖更多的使用场景。
在v1.15.0 版本中，KubeEdge 支持边缘节点运行在 Windows Server 2019，并且支持 Windows 容器运行在边缘节点上，将 KubeEdge 的使用场景成功拓展到 Windows 生态。
Windows 版本的 EdgeCore 配置新增了 windowsPriorityClass 字段，默认为NORMAL_PRIORITY_CLASS。用户可以在 Windows 边缘主机上下载 Windows 版本的 EdgeCore 安装包[1]，解压后执行如下命令即可完成 Windows 边缘节点的注册与接入，用户可以通过在云端执行 kubectl get nodes 确认边缘节点的状态，并管理边缘 Windows 应用。
edgecore.exe --defaultconfig > edgecore.yaml
edgecore.exe --config edgecore.yaml
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/4914
- https://github.com/kubeedge/kubeedge/pull/4967
基于物模型的新版本设备管理 API v1beta1 发布
v1.15.0 版本中，基于物模型的设备管理 API，包括 Device Model 与 Device Instance，从 v1alpha2 升级到了 v1beta1，新增了边缘设备数据处理相关等的配置，北向设备 API 结合南向的 DMI 接口，实现设备数据处理，API 的主要更新包括：
- Device Model 中按物模型标准新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段。
// ModelProperty describes an individual device property / attribute like temperature / humidity etc.
type ModelProperty struct {
// Required: The device property name.
Name string `json:"name,omitempty"`
// The device property description.
// +optional
Description string `json:"description,omitempty"`
// Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES
Type PropertyType `json:"type,omitempty"`
// Required: Access mode of property, ReadWrite or ReadOnly.
AccessMode PropertyAccessMode `json:"accessMode,omitempty"`
// +optional
Minimum string `json:"minimum,omitempty"`
// +optional
Maximum string `json:"maximum,omitempty"`
// The unit of the property
// +optional
Unit string `json:"unit,omitempty"`
}
- Device Instance 中内置的协议配置全部移除，包括 Modbus、Opc-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置自己的协议，以实现任何协议的设备接入。Modbus、Opc-UA、Bluetooth 等内置协议的 Mapper 不会从 mappers-go 仓库移除，并且会更新到对应的最新版本，且一直维护。
type ProtocolConfig struct {
// Unique protocol name
// Required.
ProtocolName string `json:"protocolName,omitempty"`
// Any config data
// +optional
// +kubebuilder:validation:XPreserveUnknownFields
ConfigData *CustomizedValue `json:"configData,omitempty"`
}
type CustomizedValue struct {
Data map[string]interface{} `json:"-"`
}
- 在 Device Instance 的设备属性中增加了数据处理的相关配置，包括设备上报频率、收集数据频率、属性是否上报云端、推送到边缘数据库等字段，数据的处理将在 Mapper 中进行。
type DeviceProperty struct {
......
// Define how frequent mapper will report the value.
// +optional
ReportCycle int64 `json:"reportCycle,omitempty"`
// Define how frequent mapper will collect from device.
// +optional
CollectCycle int64 `json:"collectCycle,omitempty"`
// whether be reported to the cloud
ReportToCloud bool `json:"reportToCloud,omitempty"`
// PushMethod represents the protocol used to push data,
// please ensure that the mapper can access the destination address.
// +optional
PushMethod *PushMethod `json:"pushMethod,omitempty"`
}
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/4999
- https://github.com/kubeedge/kubeedge/pull/4983
承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布
v1.15.0 版本中，对 DMI 数据面部分提供了支持，主要承载在南向的 Mapper 开发框架 Mapper-Framework中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备数据管理（数据面）能力，允许设备在边缘端或云端处理数据，提升了设备数据管理的灵活性。Mapper-Framework 能够自动生成用户的 Mapper 工程，简化用户设计实现 Mapper 的复杂度，提升 Mapper 的开发效率。
- DMI 设备数据面管理能力支持
v1.15.0 版本 DMI 提供了数据面能力的支持，增强边缘端处理设备数据的能力。设备数据在边缘端可以按配置直接被推送至用户数据库或者用户应用，也可以通过云边通道上报至云端，用户也可以通过 API 主动拉取设备数据。设备数据管理方式更加多样化，解决了 Mapper 频繁向云端上报设备数据，易造成云边通信阻塞的问题，能够减轻云边通信的数据量，降低云边通信阻塞的风险。DMI 数据面系统架构如下图所示：
- Mapper 自动生成框架 Mapper-Framework
v1.15.0 版本提出全新的 Mapper 自动生成框架 Mapper-Framework。框架中已经集成 Mapper 向云端注册、云端向 Mapper 下发 Device Model 与 Device Instance 配置信息、设备数据传输上报等功能，大大简化用户设计实现 Mapper 的开发工作，便于用户体验 KubeEdge 边缘计算平台带来的云原生设备管理体验。
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/5023
支持边缘节点运行 Kubernetes 静态 Pod
新版本的 KubeEdge 支持了 Kubernetes 原生静态 Pod 能力，与 Kubernetes 中操作方式一致，用户可以在边缘主机的指定目录中，以 JSON 或者 YAML 的形式写入 Pod 的 Manifests 文件，Edged 会监控这个目录下的文件来创建/删除边缘静态 Pod，并在集群中创建镜像 Pod。
静态 Pod 默认目录是 /etc/kubeedge/manifests，你也可以通过修改 EdgeCore 配置的 staticPodPath 字段来指定目录。
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/4825
支持更多的 Kubernetes 原生插件运行在边缘节点
v1.15.0 版本的 KubeEdge 支持更多原生插件在边缘节点上运行。KubeEdge 提供了高扩展性的 Kubernetes 原生非资源类 API 透传框架，满足了原生插件对此类 API 的依赖。插件可以从边缘节点的 MetaServer 中获取集群 version 等信息，MetaServer 将对请求进行数据缓存，保证边缘节点网络中断时仍能正常服务。
当前框架下，社区开发者将更容易的开放更多非资源类 API。开发者只需关注插件依赖的 API，而不需要考虑请求如何传递至边缘节点。
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/4904
升级 Kubernetes 依赖到 v1.26
新版本将依赖的 Kubernetes 版本升级到 v1.26.7，你可以在云和边缘使用新版本的特性。
更多信息可参考：
- https://github.com/kubeedge/kubeedge/pull/4929
版本升级注意事项
-
新版本 v1beta1 的 Device API不兼容 v1alpha1 版本，如果你需要在 KubeEdge v1.15.0 中使用设备管理特性，你需要更新 Device API 的 yaml 配置。
-
如果你使用 containerd 作为边缘容器运行时，你需要将 containerd 版本升级到 v1.6.0 或者更高版本，KubeEdge v1.15.0 不再支持 containerd 1.5 以及更早的版本。
参考：https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal
-
在 KubeEdge v1.14 中，EdgeCore 已经移除了对 dockershim 的支持，边缘运行时仅支持 remote 类型，并且使用 containerd 作为默认运行时。如果你想要继续使用 docker 作为边缘运行时，你需要安装 cri-dockerd，并且在启动 EdgeCore 过程中，设置 runtimeType=remote 以及 remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock。
参考：https://github.com/kubeedge/kubeedge/issues/4843