On January 23, 2024, KubeEdge released v1.16. The new version introduces several enhanced features, significantly improving cluster upgrades, cluster usability, and edge device management.
v1.16 What's New
- Support Cloud and Edge Components Upgrade
- Alpha Implementation of Images PrePull on Edge Nodes
- Support Installing Windows-based Edge Nodes with Keadm
- Add Compatibility Tests for Multiple Runtimes
- Support More Deployment Fields to the EdgeApplication Overrides
- Support Mapper Upgrade
- Integrate Redis and TDengine Database in DMI Data Plane
- New USB Camera Mapper
- Keadm’s Enhancement
- Upgrade Kubernetes Dependency to v1.27.7
Release Highlights
Support Cloud and Edge Components Upgrade
The Cloud side and Edge side Upgrade capability is comprehensively enhanced in v1.16. Users can upgrade the cloud side components with Keadm tool, and upgrade edge nodes with the API through Kubernetes API-Server.
Cloud upgrade
Keadm supports the Cloud Upgrade command, and users can easily upgrade cloud components.
Example:
keadm upgrade cloud --advertise-address={advertise-address} --kubeedge-version=v1.16.0Edge upgrade
In KubeEdge v1.16, the node upgrade API was implemented. Users can remotely upgrade edge nodes in batches. The cloud-edge task architecture handles upgrade task flow and supports unified timeout processing, concurrency control, and subtask management, among other capabilities.
Upgrade API Example:
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 version compatibility testing
KubeEdge v1.16 provides KubeEdge version compatibility testing, which avoids problems caused by incompatible cloud-edge versions during the upgrading process.
Refer to the link for more details. (#5330, #5229, #5289)
Alpha Implementation of Images PrePull on Edge Nodes
In scenarios with unstable network or limited edge bandwidth, deploying or updating edge applications often results in high failure rates or reduced efficiency, especially with large-scale edge nodes.
Images PrePull feature has been introduced in v1.16. Users can perform batch images prepull on large-scale edge nodes with ImagePrePullJob API when the network is stable, to improve the success rate and efficiency of batch edge applications deploying and updating.
ImagePrePull API Example:
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
Refer to the link for more details. (#5310, #5331)
Support Installing Windows-based Edge Nodes with Keadm
KubeEdge has supported the edge node running on Windows Server 2019 in v1.15, extending KubeEdge to the Windows ecosystem and expanding its use cases and ecosystem.
In this release, Windows-based Edge Nodes can be installed and registered to cloud with the installation tool Keadm, providing convenience for the application of KubeEdge in Windows OS.
Refer to the link for more details. (#4968)
Add Compatibility Tests for Multiple Runtimes
The e2e test of KubeEdge v1.16 has integrated compatibility tests for multiple container runtimes. Currently, four container runtime compatibility tests have been added, including containerd, docker, cri-o, and isulad.
Refer to the link for more details.(#5321)
Support More Deployment Fields to the EdgeApplication Overrides
In previous versions, only replicas and image of the EdgeApplication could be overridden. In this release, we support overriding more Deployment fields: env, command, args and resources.
Refer to the link for more details.(#5038)
Support Mapper Upgrade
Build mapper upgrade framework. Users can upgrade the mapper by changing the referenced mapper-framework package version.
Mapper-framework code decouple
The code in mapper-framework was decoupled into user-layer code and business-layer code, and create the kubeedge/mapper-framework repo to store the business layer code.
Mapper upgrade framework
Update the way mapper-framework generates mapper projects. The current execution script will only generate user-level code through dependent references. When the mapper project needs to be upgraded, it can be directly made by changing the version of mapper-framework package.
Refer to the link for more details.(#5308, #5326)
Integrate Redis and TDengine Database in DMI Data Plane
Integrate redis and tdengine database in DMI data plane. The mapper project generated by mapper-framework has build-in ability to push data to redis and tdengine database. Users can push data directly through configuring device instance files.
Database Field Definition:
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"`
}
Refer to the link for more details.(#5064)
New USB Camera Mapper
Based on the mapper and dmi framework in KubeEdge v1.15.0, a mapper for USB cameras has been developed, which supports data push to Influxdb, mqtt, and http. It has been successfully applied in practice.
Refer to the link for more details.(#122)
Keadm’s Enhancement
When using Keadm join in kubeEdge v1.16, it supports the selection of communication protocols for edge nodes and cloud center nodes. The cloud edge communication protocol is configured through the parameter --hub-protocol, and currently supports two communication protocols: websocket and quic.
noteWhen the --hub-protocol parameter is configured as quic, it is necessary to set the port of the parameter --cloudcore-ipport to 10001 and modify configmap in cloudcore to open the quic protocol.
Refer to the link for more details.(#5156)
In KubeEdge v1.16, it is already supported for Keadm to complete edgecore deployment through Keadm join without installing the CNI plugin, decoupling the deployment of edge nodes from the CNI plugin. At the same time, this feature has been synchronized to v1.12 and later versions.
noteIf the application deployed on edge nodes needs to use container networks, it is still necessary to install the CNI plugin after deploying edgecore.
Refer to the link for more details.(#5196)
Upgrade Kubernetes Dependency to v1.27.7
Upgrade the vendered kubernetes version to v1.27.7, users are now able to use the feature of new version on the cloud and on the edge side.
Refer to the link for more details. (#5121)
Important Steps before Upgrading
Now we use DaemonSet to manage the mqtt broker mosquitto. You need to consider whether to use the static pod managed mqtt broker in the edge node or use the DaemonSet managed mqtt broker in the cloud, they cannot coexist and there will be port conflicts. You can read the guide
For edge node low version compatibilityin #5233.In this release, the flag
with-mqttwill be set to deprecated and default to false, but will not be removed. After v1.18, the code related to static pod management will be removed in the edge, and the flagwith-mqttno longer supported.
