跳到主要内容

21 篇博文 含有标签「iiot」

查看所有标签

· 阅读需 6 分钟
KubeEdge SIG Release

北京时间2025年11月4日，KubeEdge 发布1.22.0版本。新版本对 Beehive 框架以及 Device Model做了优化升级，同时对边缘资源管理能力做了提升。

KubeEdge v1.22 新增特性：​

新特性概览​

新增 hold/release 机制控制边缘资源更新​

在自动驾驶、无人机和机器人等应用场景中，我们希望在边缘能够控制对边缘资源的更新，以确保在未得到边缘设备管理员的许可下，这些资源无法被更新。在1.22.0版本中，我们引入了 hold/release 机制来管理边缘资源的更新。

在云端，用户可以通过对 Deployment、StatefulSet 和 DaemonSet 等资源添加 edge.kubeedge.io/hold-upgrade: "true" 的 annotation，表示对应的 Pod 在边缘更新需要被hold。

在边缘，被标记了 edge.kubeedge.io/hold-upgrade: "true" 的Pod会被暂缓被处理。边缘管理员可以通过执行以下命令来释放对该Pod的锁，完成资源更新。

keadm ctl unhold-upgrade pod <pod-name>

也可以执行以下命令解锁边缘节点上所有被hold的边缘资源。

keadm ctl unhold-upgrade node
备注

使用 keadm ctl 命令需要启动 DynamicController 和 MetaServer 开关。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/6348 https://github.com/kubeedge/kubeedge/pull/6418

Beehive框架升级，支持配置子模块重启策略​

在1.17版本中，我们实现了 EdgeCore 模块的自重启，可以通过全局配置来设置边缘模块的重启。在1.22版本中，我们对 Beehive 框架进行了升级优化，支持边缘子模块级别的重启策略配置。同时我们统一了 Beehive 各子模块启动的错误处理方式，对子模块能力标准化。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/6444 https://github.com/kubeedge/kubeedge/pull/6445

基于物模型与产品概念的设备模型能力升级​

目前的 Device Model 基于物模型概念设计，而在传统IoT中，设备通常采用物模型、产品和设备实例三层结构进行设计，可能导致用户在实际使用中产生困惑。

在 1.22.0 版本中，我们结合物模型与实际产品的概念，对设备模型的设计进行了升级。从现有的设备实例中提取了protocolConfigData, visitors 字段到设备模型中，设备实例可以共享这些模型配置。同时，为了降低模型分离的成本，设备实例可以重写覆盖以上配置。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/6457 https://github.com/kubeedge/kubeedge/pull/6458

边缘轻量化Kubelet新增 Pod Resources Server 和 CSI Plugin 特性开关​

在之前的版本中，我们在 EdgeCore 集成的轻量化 Kubelet 中移除了Pod Resources Server能力，但在一些使用场景中，用户希望恢复该能力以实现对Pod的监控等。同时，由于 Kubelet 默认启动CSI Plugin，离线环境下启动 EdgeCore 会由于 CSINode 创建失败而导致失败。

在 1.22.0 版本中，我们在轻量化 Kubelet 中新增了 Pod Resources Server 和 CSI Plugin 特性开关，如果您需要启用 Pod Resources Server 或关闭 CSI Plugin，您可以在 EdgeCore 配置中添加如下特性开关：

apiVersion: edgecore.config.kubeedge.io/v1alpha2
kind: EdgeCore
modules:
     edged:
         tailoredKubeletConfig:
            featureGates:
               KubeletPodResources: true
               DisableCSIVolumePlugin: true
...

更多信息可参考：

https://github.com/kubeedge/kubernetes/pull/12 https://github.com/kubeedge/kubernetes/pull/13 https://github.com/kubeedge/kubeedge/pull/6452

C语言版本Mapper-Framework支持​

在1.20.0版本中，我们在原有的go语言版本Mapper工程基础上，新增了Java版本的Mapper-Framework。由于边缘IoT设备通信协议的多样性，很多边缘设备驱动协议都是基于C语言实现的，因此在新版本中，KubeEdge提供了C语言版本的Mapper-Framework，用户可以访问KubeEdge主仓库的feature-multilingual-mapper-c分支，利用Mapper-Framework生成C语言版本的自定义Mapper工程。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/6405 https://github.com/kubeedge/kubeedge/pull/6455

升级K8s依赖到1.31​

新版本将依赖的Kubernetes版本升级到v1.31.12，您可以在云和边缘使用新版本的特性。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/6443

· 阅读需 11 分钟
KubeEdge SIG Release

北京时间2025年6月28日，KubeEdge发布1.21.0版本。新版本对节点任务框架（节点升级、镜像预下载）做了全面更新，并新增云端更新边缘配置的能力，同时Dashboard新增对keink的集成，支持一键部署，在易用性、管理运维能力上做了全面增强。

KubeEdge v1.21 新增特性：​

新特性概览​

全新节点任务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总是单实例运行的。具体流程如下：

  • 当节点任务CR被创建后，ControllerManager会初始化匹配的节点的状态；
  • CloudCore只会处理ControllerManager处理过的节点任务资源，通过执行器（Executor）和下行控制器（DownstreamController）将节点任务下发给节点；
  • EdgeCore接收到节点任务后，通过运行器（Runner）执行动作，并将每个动作的执行结果上报给CloudCore；
  • CloudCore通过上行控制器（UpstreamController）接收动作运行的结果并将结果更新到节点任务的状态中；
  • ControllerManager监听节点任务资源的变化计算整个节点任务的状态进行更新。

在整个处理流程中，我们将流程中可能产生的错误都记录并更新到了节点任务资源状态的原因字段中。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/6082 https://github.com/kubeedge/kubeedge/pull/6084

节点组流量闭环优化​

在 KubeEdge 1.21.0 中，我们对节点组的流量闭环功能进行了全面优化，使其功能更完善、使用更灵活。这一功能的核心能力是：通过一个 Service 实现“节点组内应用只能访问同组内应用服务，无法访问其他节点组的服务。借助该机制，用户可以轻松实现边缘多区域间的网络隔离，确保不同区域的应用服务之间互不干扰。

应用场景举例：

以连锁门店为例，企业可将全国各地的门店按区域划分为多个节点组（如华东、华北、西南等），每个区域的门店部署相同类型的应用（如库存管理、收银系统），但业务数据互相隔离。通过流量闭环功能，系统可自动限制服务访问范围，仅在节点组内互通，避免跨区域访问，无需额外配置网络策略。 流量闭环功能为可选项。如果用户不希望开启节点组间的流量隔离，只需在 EdgeApplication 中不配置 Service 模板，系统则不会启用该能力，应用依然可以按原有方式进行通信。

使用样例

apiVersion: apps.kubeedge.io/v1alpha1
kind: NodeGroup
metadata:
  name: beijing
spec:
  nodes:
    - node-1
    - node-2
---
apiVersion: apps.kubeedge.io/v1alpha1
kind: NodeGroup
metadata:
  name: shanghai
spec:
  nodes:
    - node-3
    - node-4
---
apiVersion: apps.kubeedge.io/v1alpha1
kind: EdgeApplication
metadata:
  name: test-service
  namespace: default
spec:
  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

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/6097 https://github.com/kubeedge/kubeedge/pull/6077

支持在云端更新边缘配置​

相较于登录每个边缘节点手动更新EdgeCore的配置文件edgecore.yaml，能够直接从云端更新edgecorer.yaml要更便利。尤其是对于批量节点操作，同时更新多个边缘节点的配置文件，能够提高管理效率，节约很多运维成本。

在v1.21.0中，我们引入了ConfigUpdateJob CRD，允许用户在云端更新边缘节点的配置文件。CRD中的updateFields用于指定需要更新的配置项。

CRD示例：

apiVersion: operations.kubeedge.io/v1alpha2
kind: ConfigUpdateJob
metadata:
  name: configupdate-test
spec:
  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重启

更多信息可参考:

https://github.com/kubeedge/kubeedge/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=disableNodeTaskV1alpha2

CloudCore 修改配置文件

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边缘节点升级的相关命令（备份、升级、回滚）做了调整：

  • 升级命令不会自动执行备份命令，备份命令需要手动触发；
  • 升级命令隐藏了业务相关的参数，v1.23版本后会清理废弃的代码；
  • 升级的相关命令都使用三级命令：
 keadm edge upgrade
 keadm edge backup
 keadm edge rollback

· 阅读需 9 分钟
KubeEdge SIG Release

北京时间2025年1月21日，KubeEdge发布1.20.0版本。新版本针对大规模、离线等边缘场景对边缘节点和应用的管理、运维等能力进行了增强，同时新增了多语言Mapper-Framework的支持。

KubeEdge v1.20 新增特性：​

新特性概览​

支持批量节点操作​

在之前的版本中，keadm工具仅支持单个节点的安装与管理，然而在边缘场景中，节点数量通常比较庞大，单个节点的管理难以满足大规模场景的需求。

在1.20版本中，我们提供了批量节点操作和运维的能力。基于这个能力，用户仅需要使用一个配置文件，即可通过一个控制节点（控制节点可以登录所有边缘节点）对所有边缘节点进行批量操作和维护。keadm当前版本支持的批量能力包括join, reset和upgrade。

# 配置文件配置要求参考如下
keadm:
  download:
    enable: true              # <Optional> Whether to download the keadm package, which can be left unconfigured, default is true. if it is false, the 'offlinePackageDir' will be used.
    url: ""                   # <Optional> The download address of the keadm package, which can be left unconfigured. If this parameter is not configured, the official github repository will be used by default.
  keadmVersion: ""            # <Required> The version of keadm to be installed. for example: v1.19.0
  archGroup:                  # <Required> This parameter can configure one or more of amd64/arm64/arm.
    - amd64
  offlinePackageDir: ""       # <Optional> The path of the offline package. When download.enable is true, this parameter can be left unconfigured.
  cmdTplArgs:                 # <Optional> This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd.
    cmd: ""                   # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd.
    token: ""                 # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd.
nodes:
  - nodeName: edge-node       # <Required> Unique name, used to identify the node
    arch: amd64               # <Required> The architecture of the node, which can be configured as amd64/arm64/arm
    keadmCmd: ""              # <Required> The command to be executed on the node, can used in conjunction with keadm.cmdTplArgs. for example: "{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}"
    copyFrom: ""              # <Optional> The path of the file to be copied from the local machine to the node, which can be left unconfigured.
    ssh:
      ip: ""                  # <Required> The IP address of the node.
      username: root          # <Required> The username of the node, need administrator permissions.
      port: 22                # <Optional> The port number of the node, the default is 22.
      auth:                   # Log in to the node with a private key or password, only one of them can be configured.
        type: password        # <Required> The value can be configured as 'password' or 'privateKey'.
        passwordAuth:         # It can be configured as 'passwordAuth' or 'privateKeyAuth'.
          password: ""        # <Required> The key can be configured as 'password' or 'privateKeyPath'.
maxRunNum: 5                  # <Optional> The maximum number of concurrent executions, which can be left unconfigured. The default is 5.`

# 配置文件参考用例 (各字段具体值请根据实际环境进行配置)
keadm:
  download:
    enable: true
    url: https://github.com/kubeedge/kubeedge/releases/download/v1.20.0 # If this parameter is not configured, the official github repository will be used by default
  keadmVersion: v1.20.0
  archGroup: # This parameter can configure one or more of amd64\arm64\arm
    - amd64
  offlinePackageDir: /tmp/kubeedge/keadm/package/amd64  # When download.enable is true, this parameter can be left unconfigured
  cmdTplArgs: # This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd
    cmd: join --cgroupdriver=cgroupfs --cloudcore-ipport=192.168.1.102:10000 --hub-protocol=websocket --certport=10002 --image-repository=docker.m.daocloud.io/kubeedge --kubeedge-version=v1.20.0 --remote-runtime-endpoint=unix:///run/containerd/containerd.sock
    token: xxx
nodes:
  - nodeName: ubuntu1   # Unique name
    arch: amd64
    keadmCmd: '{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}' # Used in conjunction with keadm.cmdTplArgs
    copyFrom: /root/test-keadm-batchjoin  # The file directory that needs to be remotely accessed to the joining node
    ssh:
      ip: 192.168.1.103
      username: root
      auth:
        type: privateKey   # Log in to the node using a private key
        privateKeyAuth:
          privateKeyPath: /root/ssh/id_rsa
  - nodeName: ubuntu2
    arch: amd64
    keadmCmd: join --edgenode-name=containerd-node2 --cgroupdriver=cgroupfs --cloudcore-ipport=192.168.1.102:10000 --hub-protocol=websocket --certport=10002 --image-repository=docker.m.daocloud.io/kubeedge --kubeedge-version=v1.20.0 --remote-runtime-endpoint=unix:///run/containerd/containerd.sock  # Used alone
    copyFrom: /root/test-keadm-batchjoin
    ssh:
      ip: 192.168.1.104
      username: root
      auth:
        type: password
        passwordAuth:
          password: *****
maxRunNum: 5

# 用法 (保存以上文件，例如保存为 config.yaml)
# 在控制节点下载最新版本 keadm, 执行以下命令进行使用
keadm batch -c config.yaml

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5988 https://github.com/kubeedge/kubeedge/pull/5968 https://github.com/kubeedge/website/pull/657

多语言Mapper-Framework支持​

由于边缘IoT设备通信协议的多样性，用户可能需要使用Mapper-Framework生成自定义Mapper插件来纳管边缘设备。当前Mapper-Framework只能生成go语言版本的Mapper工程，对于部分不熟悉go语言的开发者来说使用门槛仍然较高。因此在新版本中，KubeEdge提供了Java版本的Mapper-Framework，用户可以访问 KubeEdge主仓库 的 feature-multilingual-mapper 分支，利用 Mapper-Framework 生成 Java 版的自定义 Mapper 工程。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5773 https://github.com/kubeedge/kubeedge/pull/5900

边缘keadm ctl新增 pods logs/exec/describe 和 Devices get/edit/describe 能力​

在v1.17.0版本中，我们新增了keadm ctl子命令，支持在离线场景下对边缘pod进行查询和重启。在v1.20中我们对该命令做了进一步增强，支持pod的logs/exec/describe等功能，用户在边缘可对pod进行日志查询、pod资源详细信息查询、进入容器内部等操作。同时还新增了对device的操作，支持device的get/edit/describe的功能，可以在边缘获取device列表、device的详细信息查询、在边缘离线场景下对device进行编辑操作。

如下所示，新增的keadm ctl子命令功能均在MetaServer中开放了Restful接口，并与K8s ApiServer对应的接口完全兼容。

[root@edgenode1 ~]# keadm ctl -h
Commands operating on the data plane at edge

Usage:
  keadm ctl [command]

Available Commands:
...
  describe    Show details of a specific resource
  edit        Edit a specific resource
  exec        Execute command in edge pod
  get         Get resources in edge node
  logs        Get pod logs in edge node
...

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5752 https://github.com/kubeedge/kubeedge/pull/5901

解耦边缘应用与节点组，支持使用Node LabelSelector​

EdgeApplication 可以通过节点组覆盖部署定义（如副本、镜像、命令和环境），Pod 流量在节点组内闭环（EdgeApplication 管理的 Deployment 共用一个 Service）。但在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不相同。例如在智慧园区的场景中，每个城市都有很多个智慧园区，我们需要应用的流量在一个智慧园区内闭环，但应用批量管理的范围可能是城市级，也可能是省级。

我们在 EdgeApplication CRD 中为节点标签选择器添加了一个新的 targetNodeLabels 字段，该字段将允许应用程序根据节点标签进行部署，并且覆盖特定的字段，YAML定义如下：

apiVersion: apps.kubeedge.io/v1alpha1
kind: EdgeApplication
metadata:
  name: edge-app
  namespace: default
spec:
  replicas: 3
  image: my-app-image:latest
  # New field: targetNodeLabels
  targetNodeLabels:
    - labelSelector:
        - matchExpressions:
            - key: "region"
              operator: In
              values:
                - "HangZhou"
    overriders:
      containerImage:
        name: new-image:latest
      resources:
        limits:
          cpu: "500m"
          memory: "128Mi"

更多信息可参考：

Issue: https://github.com/kubeedge/kubeedge/issues/5755

Pull Request: https://github.com/kubeedge/kubeedge/pull/5845

边云通道支持IPv6​

我们在官网的文档中提供了一份配置指南，介绍了KubeEdge如何在Kubernetes集群中让云边 hub 隧道支持IPv6。文档地址：https://kubeedge.io/docs/advanced/support_ipv6

升级K8s依赖到v1.30​

新版本将依赖的Kubernetes版本升级到v1.30.7，您可以在云和边缘使用新版本的特性。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5997

版本升级注意事项​

  • 从v1.20.0版本开始，EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm安装EdgeCore时设置--set edged.rootDirectory=/var/lib/edged。

· 阅读需 7 分钟
KubeEdge SIG Release

北京时间2024年10月28日，KubeEdge发布1.19.0版本。新版本在节点和设备方面引入了多个新特性，同时带来了全新版本的 Dashboard。

KubeEdge v1.19 新增特性：​

新特性概览​

支持边缘节点上报Event​

Kubernetes Event作为集群中事件的报告，可以反馈节点、Pods等集群资源的状态变化。在1.19版本中，EdgeCore支持了边缘Event的上报，用户可以直接在云端通过 kubectl get events 或者kubectl describe {resource_type} {resource_name}获取边缘节点或者pods等状态。

该特性在1.19版本中默认关闭，使用EdgeCore时执行 --set modules.edged.reportEvent=true 或者如下修改EdgeCore配置参数并重启EdgeCore。

apiVersion: edgecore.config.kubeedge.io/v1alpha2
kind: EdgeCore
featureGates:
  requireAuthorization: true
modules:
  ...
  edged:
    reportEvent: true
...

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5722 https://github.com/kubeedge/kubeedge/pull/5811

支持边缘节点OTA升级​

新版本在节点升级NodeUpgradeJob基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后，在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的kubeedge/installation-pacakge镜像是安全可靠的。

在1.19版本中，我们可以通过YAML配置NodeUpgradeJob的imageDigestGatter来定义镜像摘要，value用于直接定义摘要的值，registryAPI用于通过registry v2接口获取镜像摘要，两者互斥，如果都没有配置则在升级时不进行镜像摘要的校验，样例：

spec:
  ...
  imageDigestGatter:
    value: ""
    registryAPI:
      host: ""
      token: ""

我们还可以通过YAML配置NodeUpgradeJob的requireConfirmation来定义是否要在边端进行确认操作，样例：

spec:
  ...
  requireConfirmation: true

当requireConfirmation设置为true时，在边端节点升级任务下发到边端后，任务状态会更新为confirmation状态等待边端发起确认命令后再继续进行升级。

我们可以通过执行keadm ctl confirm指令进行确认，或者调用Metaserver接口进行确认，以继续升级任务：

POST http(s)://localhost:<metaserver_port>/confirm

更多信息可参考:

https://github.com/kubeedge/kubeedge/issues/5589 https://github.com/kubeedge/kubeedge/pull/5761 https://github.com/kubeedge/kubeedge/pull/5863

Mapper支持设备数据写入​

Mapper当前能够采集设备数据并上报，但在设备数据写入方面仍不完善。1.19版本在Mapper-Framework中增加了设备数据写入的能力，允许用户通过Mapper提供的API调用device method，对device property完成数据写入

  • Device method API

目前基于物模型的v1beta1版本的设备管理API包含device property的定义，在1.19版本中，新增device method的定义。Device method指设备能够被外部调用的能力或方法，一个device method能够控制多个device property值。用户能在device-instance文件中定义device method，通过device method完成device property的控制、写入。

spec:
  ...
  methods:
    - name: ""
      description: ""
      propertyNames:
      - ""
  • 设备数据写入

在1.19中改进Mapper API能力，新增device method调用接口。用户能够调用相关的接口获取某个设备包含的所有device method，以及device method的调用命令，通过返回的调用命令发起设备写入请求。device method的具体功能实现需要用户自行在Mapper的设备驱动层中完成。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5662 https://github.com/kubeedge/kubeedge/pull/5902

Mapper框架新增支持OpenTelemetry​

当前Mapper向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式，但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架，能够封装设备数据并向多类应用或数据库推送数据，例如GreptimeDB、 Prometheus等，增强Mapper数据面推送设备数据的能力。

spec:
  ...
  properties:
    - name: ""
      pushMethod:
        otel：
          endpointURL: ""

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5574 https://github.com/kubeedge/kubeedge/pull/5564

全新版本Dashboard​

之前发布的KubeEdge Dashboard，新版本使用主流的Next.js框架以及MUI样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件，基于KubeEdge最新版本的后端API，我们完善并增加了Device等相关功能页面，并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中，我们整理完善了Kubernetes以及KubeEdge后端接口的Typescript类型定义，并将依赖的后端接口更新至最新版本，确保其与最新的KubeEdge兼容。

更多信息可参考：

https://github.com/kubeedge/dashboard/pull/29

版本升级注意事项​

  • 下个版本（v1.20），EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm安装EdgeCore时设置--set edged.rootDirectory=/var/lib/edged。

  • 从1.19版本开始，请在使用keadm安装KubeEdge时，使用--kubeedge-version指定版本，--profile version已废弃。

· 阅读需 6 分钟
KubeEdge SIG Release

北京时间2024年7月26日，KubeEdge发布1.18.0版本。新版本在稳定性、安全性等方面有了显著的提升，同时持续在易用性等方面做了增强。

KubeEdge v1.18 新增特性：​

新特性概览​

RouterManager支持高可用​

针对CloudCore采用高可用部署时，RouterManager无法准确路由的问题，在新版本中，对RouterManager在高可用部署时做了优化与增强，云端发往边缘的自定义消息将会被路由到对应EdgeNode所连接的CloudCore中，并正确下发到对应的EdgeNode。同时考虑了边界情况，在转发过程中，如果EdgeNode重连到其他CloudCore时，消息将会被重新转发到正确的CloudCore中。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5635 https://github.com/kubeedge/kubeedge/pull/5619

CloudCore云边通道鉴权增强​

CloudCore 作为连接边缘节点和Kube-APIServer的桥梁，需要限制边缘节点对集群资源的访问权限。在新版本中，我们对云边通道的安全性进行了增强，CloudHub会识别消息发送方并校验其是否有足够的权限，从而限制边缘节点操作其他节点的资源。 v1.18.0目前已支持node authorization模式。该特性引入了如下配置参数，在新版本中默认关闭，开启如下开关即可启用该特性。

apiVersion: v1
data:
  cloudcore.yaml:
  ...
  modules：
    cloudhub:
      authorization:
        // optional, default false, toggle authoration
        enable: true
        // optional, default to false, do authorization but always allow all the requests
        debug: false
        // required, an authorizer chain
        authorizers:
          // node authorization mode
          - node:
          ebable：true
  ...

为了安全启用此特性，可以先开启debug。当鉴权失败时，CloudCore只记录日志，但请求仍会正常处理。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5512 https://github.com/kubeedge/kubeedge/pull/5585

支持设备状态上报​

设备有其自身的状态，比如在线、离线、异常等。1.18.0版本支持了设备状态上报的能力。该特性在Mapper-Framework已经默认实现，用户基于Mapper-Framework生成自己需要的mapper，即可使用。状态上报成功后，可通过device的资源查看结果：

apiVersion: devices.kubeedge.io/v1beta1
kind: Device
...
spec:
  status:
    lastOnlineTime: "2024-07-30T17:55:49Z"
    state: ok
    twins:
    - observedDesired:
    ...

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5650 https://github.com/kubeedge/kubeedge/pull/5649 https://github.com/kubeedge/kubeedge/pull/5651

Keadm能力增强​

在旧版本中，使用keadm join安装EdgeCore只能指定部分参数的配置。在最新版本中，我们对EdgeCore的配置流程进行了显著优化。现在，您无需等待节点接入完成,手动编辑edgecore.yaml配置文件，再重启EdgeCore。通过在keadm join命令中使用新增的--set参数，您可以在节点加入时直接设置配置，就像使用Helm配置values.yaml一样便捷。这一改进大大简化了配置管理过程，提高了效率。下列指令是一个开启MetaServer的样例：

keadm join --set modules.metaManager.enable=true,modules.metaManager.metaServer.enable=true,modules.metaManager.remoteQueryTimeout=32

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5574 https://github.com/kubeedge/kubeedge/pull/5564

封装Token，CA和证书操作，提高扩展性​

在本版本中，我们对Token和Certificate的处理进行了彻底的整理和优化。原先分散在代码各处的处理逻辑现在已被集中管理，显著降低了维护成本。Token处理已被集成到一个统一的工具包中，而Certificate的处理则通过接口抽象化，不仅支持自建CA流程，还适配了通过Kubernetes CSR申请Certificate的流程。此外，我们的设计允许未来轻松扩展以支持更多类型的私钥和客户自定义的Certificate。此次重构不仅提升了Token和Certificate业务代码的可读性和可维护性，而且保持了对外接口的完全向下兼容性，确保了现有系统的无缝升级。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5502 https://github.com/kubeedge/kubeedge/pull/5544

升级K8s依赖到v1.29​

新版本将依赖的Kubernetes版本升级到v1.29.6，您可以在云和边缘使用新版本的特性。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5656