热门搜索:
您现在的位置是：首页 > 文章详情

KubeEdge v1.16.0 版本发布！10 项新增特性

日期：2024-02-05点击：183

本文分享自华为云社区《KubeEdge v1.16.0 版本发布！集群升级部署易用性大幅提升》，作者： 容器大未来。

北京时间2024年1月23日，KubeEdge 发布 1.16.0 版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。

KubeEdge v1.16.0 新增特性：

  • 集群升级：支持云边组件自动化升级
  • 支持边缘节点的镜像预下载
  • 支持使用 Keadm 安装 Windows 边缘节点
  • 增加多种容器运行时的兼容性测试
  • EdgeApplication 中支持更多 Deployment 对象字段的 Override
  • 支持基于 Mapper-Framework 的 Mapper 升级
  • DMI 数据面内置集成 Redis 与 TDEngine 数据库
  • 基于 Mapper-Framework 的 USB-Camera Mapper 实现
  • 易用性提升：基于 Keadm 的部署能力增强
  • 升级 K8s 依赖到 v1.27
kubeedge.jpeg

新特性概览

 
 
 

集群升级：支持云边组件自动化升级

随着 KubeEdge 社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0 版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过 Keadm 工具一键化升级云端，并且可以通过创建相应的 Kubernetes API，批量升级边缘节点。

  • 云端升级

云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的 KubeEdge 组件进行升级。当前版本升级完成后会打印 ConfigMap 历史配置，如果用户手动修改过 ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过 help 参数查看指令的指导信息：

keadm upgrade cloud --help Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components Usage: keadm upgrade cloud [flags] Flags: --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79 -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode --external-helm-root string Add external helm root path to keadm --force Forced upgrading the cloud components without waiting -h, --help help for cloud --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") --kubeedge-version string Use this key to set the upgrade image tag --print-final-values Print the final values configuration for debuging --profile string Sets profile on the command line. If '--values' is specified, this is ignored --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f. --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --values stringArray specify values in a YAML file (can specify multiple)

升级指令样例：

keadm upgrade cloud --advertise-address=<init时设置的值> --kubeedge-version=v1.16.0
  • 边端升级

v1.16.0版本的KubeEdge支持通过 NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。

升级 API 样例：

apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.16.0" checkItems: - "cpu" - "mem" - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""
  • 兼容测试

KubeEdge 社区提供了完备的版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过 2 个版本，就可以避免升级期间云边版本不一致带来的问题。

更多信息可参考：

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

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

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

支持边缘节点的镜像预下载

新版本引入了镜像预下载新特性，用户可以通过 ImagePrePullJob的 Kubernetes API 提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。

镜像预下载API示例：

apiVersion: operations.kubeedge.io/v1alpha1 kind: ImagePrePullJob metadata: name: imageprepull-example labels: description:ImagePrePullLabel spec: imagePrePullTemplate： images: - image1 - image2 nodes： - edgenode1 - edgenode2 checkItems: - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 retryTimes: 1

更多信息可参考：

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

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

支持使用 Keadm 安装 Windows 边缘节点

KubeEdge 1.15.0 版本实现了在 Windows 上运行边缘节点，在新版本中，我们支持使用安装工具 Keadm 直接安装 Windows 边缘节点，操作命令与 Linux 边缘节点相同，简化了边缘节点的安装步骤。

更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4968

增加多种容器运行时的兼容性测试

新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad 和 cri-o 4种主流容器运行时，保障 KubeEdge 版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。

更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5321

EdgeApplication 中支持更多 Deployment 对象字段的 Override

在新版本中，我们扩展了 EdgeApplication 中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。

更多信息可参考：

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

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

支持基于Mapper-Framework的 Mapper 升级

1.16.0 版本中，基于 Mapper 开发框架 Mapper-Framework 构建了 Mapper 组件的升级能力。新框架生成的 Mapper 工程以依赖引用的方式导入原有 Mapper-Framework 的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化 Mapper 升级流程。

  • Mapper-Framework 代码解耦:
1.16.0 版本中将 Mapper-Framework 中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随 Mapper-Framework 生成在用户 Mapper 工程中，用户可根据实际情况修改。业务层功能包括 Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework 子库中。
  • Mapper 升级框架:

1.16.0 版本 Mapper-Framework 生成的用户 Mapper 工程通过依赖引用的方式使用 kubeedge/mapper-framework 子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级 Mapper 的目的，不再需要手动修改大范围代码。

更多信息可参考：

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

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

DMI 数据面内置集成 Redis 与TDEngine数据库

1.16.0 版本中进一步增强 DMI 数据面中向用户数据库推送数据的能力，增加 Redis 与 TDengine 数据库作为内置数据库。用户能够直接在 device-instance 配置文件中定义相关字段，实现 Mapper 自动向 Redis 与 TDengine 数据库推送设备数据的功能，相关数据库字段定义为：

type DBMethodRedis struct { // RedisClientConfig of redis database // +optional RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"` } type RedisClientConfig struct { // Addr of Redis database // +optional Addr string `json:"addr,omitempty"` // Db of Redis database // +optional DB int `json:"db,omitempty"` // Poolsize of Redis database // +optional Poolsize int `json:"poo lsize,omitempty"` // MinIdleConns of Redis database // +optional MinIdleConns int `json:"minIdleConns,omitempty"` }
type DBMethodTDEngine struct { // tdengineClientConfig of tdengine database // +optional TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"` } type TDEngineClientConfig struct { // addr of tdEngine database // +optional Addr string `json:"addr,omitempty"` // dbname of tdEngine database // +optional DBName string `json:"dbName,omitempty"` }

更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5064

基于Mapper-Framework的USB-Camera Mapper实现

基于KubeEdge 的 Mapper-Framework，新版本提供了 USB-Camera 的 Mapper 样例，该 Mapper 根据 USB 协议的 Camera 开发，用户可根据该样例和 Mapper-Framework 更轻松地开发具体业务相关的 Mapper。

在样例中提供了 helm chart 包，用户可以通过修改 usbmapper-chart/values.yaml 部署 UBS-Camera Mapper，主要添加 USB-Camera 的设备文件, nodeName, USB-Camera 的副本数，其余配置修改可根据具体情况而定，通过样例目录中的 Dockerfile 制作 Mapper 镜像。

global: replicaCounts: ...... cameraUsbMapper: replicaCount: 2 #USB-Camera的副本数 namespace: default ...... nodeSelectorAndDevPath: mapper: - edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName devPath: "/dev/video0" #USB-Camera的设备文件 - edgeNode: "edgenode1" devPath: "/dev/video17" ......

USB-Camera Mapper 的部署命令如下：

helm install usbmapper-chart ./usbmapper-chart
更多信息可参考：https://github.com/kubeedge/mappers-go/pull/122

易用性提升：基于 Keadm 的部署能力增强

  • 添加云边通信协议配置参数

在 KubeEdge v1.16.0 中，使用keadm join边缘节点时，支持使用--hub-protocol 配置云边通信协议。目前 KubeEdge 支持 websocket 和 quic 两种通信协议，默认为 websocket 协议。

命令示例：

keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx

说明：当--hub-protocol设置为 quic 时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。

操作示例：使用 kubectl edit cm -n kubeedge cloudcore，将 quic 的 enable 属性设置成 true，保存修改后重启 CloudCore的pod。

modules： ...... quic: address: 0.0.0.0 enable: true #quic协议开关 maxIncomingStreams: 10000 port: 10001 ......

更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5156

  • keadm join 与 CNI 插件解耦

在新版本中，keadm join边缘节点时，不需要再提前安装 CNI 插件，已将边缘节点的部署与 CNI 插件解耦。同时该功能已同步到 v1.12 及更高版本，欢迎用户使用新版本或升级老版本。

说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完 EdgeCore 后仍然需要安装 CNI 插件。

更多信息可参考：

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

升级 K8s 依赖到 v1.27

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

更多信息可参考：

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

版本升级注意事项

 
 
 

新版本我们使用 DaemonSet 来管理边端的 MQTT 服务 Eclipse Mosquitto 了，我们能够通过云端 Helm Values 配置来设置是否要开启 MQTT 服务。使用 DaemonSet 管理 MQTT 后，我们可以方便的对边端 MQTT 进行统一管理，比如我们可以通过修改 DaemonSet 的配置将边端 MQTT 替换成 EMQX。

但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态 Pod 管理的 MQTT 和使用新的 DaemonSet 管理的 MQTT 会产生端口冲突。兼容操作步骤参考：

1、您可以在云端执行命令，将旧的边缘节点都打上自定义标签 
kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""
2、您可以修改 MQTT DaemonSet 的节点亲和性 
nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - ... - key: without-mqtt-daemonset operator: Exists
3、将节点 MQTT 改为由 DaemonSet 管理 
# ------ 边端 ------ # 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false # 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了 sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service # 停止EdgeCore systemctl daemon-reload && systemctl stop edgecore # 删除MQTT容器，Containerd可以使用nerdctl替换docker docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f # 启动EdgeCore systemctl start edgecore # ------ 云端 ------ # 删除节点标签 kubectl label nodes <NODE_NAME> without-mqtt-daemonset
新版本的 keadm join 命令会隐藏 with-mqtt 参数，并且将默认值设置成 false，如果您还想使用静态 Pod 管理 MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt 参数在 v1.18 版本中将会被移除。

致谢

 

感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.16.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！

相关链接

Release Notes：https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG/CHANGELOG-1.16.md

 

点击关注，第一时间了解华为云新鲜技术~

 

原文链接：https://my.oschina.net/u/4526289/blog/11030176
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

相关文章

    文章评论

    共有0条评论来说两句吧...

    文章二维码

    扫描即可查看该文章

    点击排行

    推荐阅读

    最新文章