跳到主要内容

19 篇博文 含有标签「iot」

查看所有标签

· 阅读需 9 分钟

北京时间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 分钟

北京时间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 分钟

北京时间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

· 阅读需 10 分钟

This blog introduces how to enable Cilium Container Network Interface with KubeEdge.

Why Cilium for KubeEdge

Cilium is the one of the most advanced and efficient container network interface plugin for Kubernetes, that provides network connectivity and security for containerized applications in Kubernetes clusters. It leverages eBPF (extended Berkeley Packet Filter) technology to implement networking and security policies at the Linux kernel level, allowing for high-performance data plane operations and fine-grained security controls.

And KubeEdge extends the cluster orchestration capability down to edge environments to provide unified cluster management and sophisticated edge specific features.

Enabling Cilium with KubeEdge allows us to take advantage of both benefits even for edge computing environments. We can deploy the application containers where EdgeCore running and bind Cilium to connect with workloads in the cloud infrastructure. This is because Cilium can also enable WireGuard VPN with transparent encryption of traffic between Cilium-managed endpoints.

Further more, we can also rely on Cilium Tetragon Security Observability and Runtime Enforcement to confine security risk and vulnerability in edge environment.

· 阅读需 3 分钟

KubeEdge v1.17 is now available! This latest release introduces several new features and enhancements, including support for edge pods using InClusterConfig to access the Kubernetes API server, video streaming data reporting in Mappers, auto-restarting for EdgeCore modules, and more.

1.17 What's New

Release Highlights

Support Edge Pods Using InClusterConfig to Access Kube-APIServer

The InClusterConfig mechanism enables cloud pods to directly access the Kubernetes API server. With this release, KubeEdge now supports edge pods using the InClusterConfig mechanism to access the Kube-APIServer directly, even when the edge and cloud are in different network environments.

Refer to the link for more details. (#5524, #5541)

Mapper Supports Video Streaming Data Reporting

Previously, Mappers could only process structured device data. In v1.17, video stream data processing features have been added to the Mapper-Framework.

  • Edge Camera Device Management

    v1.17 provides a built-in Mapper based on the Onvif protocol, which can manage Onvif network camera devices into the KubeEdge cluster and obtain the camera's authentication file and RTSP video stream.

  • Video Stream Data Processing

    Video stream data processing capabilities have been introduced to the Mapper-Framework data plane. The video stream reported by edge camera devices can be saved as frame files or video files.

Refer to the link for more details. (#5448, #5514, mappers-go/#127)

Support Auto-Restarting for Edge Modules

EdgeCore modules could previously fail to start due to non-configurable and recoverable matters like process start order issues. In v1.17, the BeeHive framework has been improved to support automatically restarting modules. Users can now configure EdgeCore modules to automatically restart instead of restarting the entire component.

Refer to the link for more details. (#5509, #5513)

Introduce keadm ctl Command to Support Pods Query and Restart at Edge

The new keadm ctl command has been introduced in v1.17, allowing users to query and restart pods on edge nodes when they are offline:

  • Query: keadm ctl get pod [flags]
  • Restart: keadm ctl restart pod [flags]

Refer to the link for more details. (#5504)

Keadm Enhancements

Several enhancements were made to the keadm installation tool:

  • Refactored the keadm init command
  • Changed the command keadm generate to keadm manifest
  • Added image-repository flag to keadm join to support customization
  • Split the keadm reset command into keadm reset cloud and keadm reset edge.

Refer to the link for more details. (#5317)

Add MySQL to Mapper Framework

The Mapper Framework data plane now includes MySQL database support in its pushMethod. When using MySQL, basic configuration parameters for the MySQL client need to be added in the DeviceInstance.

Refer to the link for more details. (#5376)

Upgrade Kubernetes Dependency to v1.28.6

The vendored Kubernetes version has been upgraded to v1.28.6, users are now able to use the latest features on both the cloud and edge side.

Refer to the link for more details. (#5412)

Important Steps before Upgrading

  • To use the InClusterConfig feature for edge pods, you need to enable the metaServer and dynamicController switches, and set featureGates.requireAuthorization=true in the CloudCore and EdgeCore configuration files.

  • To use the Auto-Restarting for Edge Modules feature, you must enable the moduleRestart feature gate in EdgeCore.

Download the v1.17.0 release from the release page and upgrade today to take advantage of these new capabilities!