Skip to main content

· 6 min read

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

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.0
  • Edge 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.

    note

    When 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.

    note

    If 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 compatibility in #5233.

  • In this release, the flag with-mqtt will 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 flag with-mqtt no longer supported.

· 9 min read
Vincent Lin

In July 2022, the KubeEdge community completed a third-party security audit of KubeEdge and released a paper on cloud native edge computing security threat analysis and protection. Based on the security threat model and audit suggestions, the community consistently strengthens the KubeEdge software supply chain. Now, we are excited to announce that KubeEdge v1.13.0 (including both binary and container image artifacts), released on January 18, 2023, achieves SLSA 3 compliance, first of its kind in the CNCF community.

Why Is SLSA 3 Compliance Important to KubeEdge

Software supply chain integrity attacks (unauthorized modification of software packages) have been increasing in the past three years. After KubeEdge reaches SLSA 3, the E2E security (from source code build to release) is hardened, preventing malicious tampering of binary and container image artifacts. Thanks to SLSA, we can enhance the integrity of software artifacts, against tampering or any type of unauthorized modification of the software or software package, and enable software to defend against common supply chain attacks.

· 13 min read
Wack Xu

Abstract

The population of KubeEdge brings in community interests in the scalability and scale of KubeEdge. Now, Kubernetes clusters powered by KubeEdge, as fully tested, can stably support 100,000 concurrent edge nodes and manage more than one million pods. This report introduces the metrics used in the test, the test procedure, and the method to connect to an ocean of edge nodes.

· 2 min read
Vincent Lin

As the first cloud-native edge computing community, KubeEdge provides solutions for cloud-edge synergy and has been widely adopted in industries including Transportation, Energy, Internet, CDN, Manufacturing, Smart campus, etc. With the accelerated deployment of KubeEdge in this area based on cloud-edge synergy, the community will improve the security of KubeEdge continuously in cloud-native edge computing scenarios.

The KubeEdge community attaches great importance to security and has set up Sig Security and Security Team to design KubeEdge system security and quickly respond to and handle security vulnerabilities. To conduct a more comprehensive security assessment of the KubeEdge project, the KubeEdge community cooperates with Ada Logics Ltd. and The Open Source Technology Improvement Fund performed a holistic security audit of KubeEdge and output a security auditing report, including the security threat model and security issues related to the KubeEdge project. Thank you to experts Adam Korczynski and David Korczynski of Ada Logics for their professional and comprehensive evaluation of the KubeEdge project, which has important guiding significance for the security protection of the KubeEdge project. Thank you Amir Montazery and Derek Zimmer of OSTIF and Cloud Native Computing Foundation (CNCF) who helped with this engagement.

The discovered security issues have been fixed and patched to the latest three minor release versions (v1.11.1, v1.10.2, v1.9.4) by KubeEdge maintainers according to the kubeedge security policy. Security advisories have been published here.

For more details of the threat model and the mitigations, Please check KubeEdge Threat Model And Security Protection Analysis: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md.

· 4 min read
Kevin Wang
Fei Xu

KubeEdge is an open source system extending native containerized application orchestration and device management to hosts at the Edge. It is built upon Kubernetes and provides core infrastructure support for networking, application deployment and metadata synchronization between cloud and edge. It also supports MQTT and allows developers to author custom logic and enable resource constrained device communication at the Edge.