27 posts tagged with "kubeedge"

On Oct 28, 2024, KubeEdge released v1.19. The new release introduces several new features for edge nodes and devices, along with a completely revamped Dashboard.

1.19 What's New​

• Support Edge Nodes Report Event
• Support OTA(Over-The-Air) Upgrades for Edge Nodes
• Mapper Supports Device Data Writing
• Add OpenTelemetry to Mapper-framework
• A New Release of KubeEdge Dashboard

Release Highlights​

Support Edge Nodes Report Event​

Kubernetes Event serve as a report of an event somewhere in the cluster, reflecting status changes of cluster resources such as Nodes and Pods. In v1.19, EdgeCore supports reporting events to cloud, allowing users to directly access the status of edge nodes or Pods in the cloud via kubectl get events or kubectl describe {resource_type} {resource_name}.

This feature is disabled by default in v1.19. To enable it, execute --set modules.edged.reportEvent=true when install EdgeCore with keadm or modify the EdgeCore configuration file and then restart EdgeCore.

Refer to the link for more details.(#5722, #5811)

Support OTA(Over-The-Air) Upgrades for Edge Nodes​

On the basis of NodeUpgradeJob upgrade, we add the edge node confirmation card point and the validation of the image digest. The card point confirmation allows the node upgrade to be delivered to the edge side, and the upgrade can be performed only after the user is confirmed. Image digest validation can ensure that the kubeedge/installation-pacakge image to be upgraded is secure and reliable at the edge side.

In v1.19, we can use spec.imageDigestGatter in NodeUpgradeJob to define how to get the image digest. The value to directly define the digest, The registryAPI to get the mirror digest via registry v2 API, both are mutually exclusive. If none is configured, the image digest is not verified during the upgrade.

We can also use spec.requireConfirmation to configure requireConfirmation for NodeUpgradeJob to determine whether we want to confirm at the edge side.

Refer to the link for more details.(#5589, #5761, #5863)

Mapper Supports Device Data Writing​

In v1.19, we add the ability to write device data in Mapper-Framework. User can use device methods through the API provided by Mapper and complete data writing to device properties.

• Device method API

A new definition of device methods is added in new release. Users can define device methods in the device-instance file that can be called by the outside world in device. Through device methods, users can control and write data to device properties.

• Device data writing

In v1.19, the Mapper API capability is improved and a new device method interface is added. The user can use the relevant interface to obtain all the device methods contained in a device, as well as the calling command of the device method. Through the returned calling command, user can create a device write request to write data to device.

Refer to the link for more details.(#5662, #5902)

Add OpenTelemetry to Mapper-framework​

In v1.19, we add the OpenTelemetry observability framework to mapper data plane, which can encapsulate device data and push data to multiple types of applications or databases. This feature can enhance the mapper data plane's ability to push device data.

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

A New Release of KubeEdge Dashboard​

Based on previous Dashboard release, we have refactored the KubeEdge Dashboard using the more popular frameworks Next.js and MUI. In the new release, we rewrote and optimized around 60 pages and components, reducing about 70% of redundant code. We also upgraded the KubeEdge and native Kubernetes APIs to the latest version to maintain compatibility and added TypeScript definitions for the APIs.

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

Important Steps before Upgrading​

• In the next release (v1.20), the default value for the EdgeCore configuration option edged.rootDirectory will change from /var/lib/edged to /var/lib/kubelet. If you wish to continue using the original path, you can set --set edged.rootDirectory=/var/lib/edged when installing EdgeCore with keadm.

• In v1.19, please use --kubeedge-version to specify the version when installing KubeEdge with keadm, --profile version is no longer supported.

On July 26, 2024, KubeEdge released v1.18. The new release features significant improvements in stability and security, while also enhancing usability.

1.18 What's New​

• Router Manager Support High Availability
• Authorization Enhancement for CloudCore Websocket API
• Support Device Status Reporting
• Keadm Tool Enhancement
• Encapsulate Token, CA and Certificate operations
• Upgrade Kubernetes Dependency to v1.29.6

Release Highlights​

Router Manager Support High Availability(HA)​

When CloudCore adopts high availability deployment, RouterManager needs to determine whether to route messages to the correct CloudCore. This feature is already supported in v1.18.0, and RouterManager supports high availability.

Refer to the link for more details.(#5619, #5635)

Authorization Enhancement for CloudCore Websocket API​

CloudCore need restrict the access to cluster resources for edge nodes. In this release，CloudCore supports node authorization mode. CloudHub identify the sender of messages and check whether the sender has sufficient permissions, so that CloudCore can restrict an edge node from operating the resources owned by other edge nodes.

Refer to the link for more details.(#5512, #5585)

Support Device Status Reporting​

Device status reporting is a capability required for device management. It was previously planned but not implemented. In version 1.18, we support this feature. Device status reporting can be easily implemented based on the community mapper template.

Refer to the link for more details.(#5649, #5650)

Keadm Tool Enhancement​

Before this release, keadm(KubeEdge Installation Tool) is only supported to configure a subset of parameters before EdgeCore was installed. Now we can use the '--set' flag to configure the parameters of the full configuration edgecore.yaml file, so that users can customize the parameters at installation time, without having to modify the configuration and restart the service after installation.

Refer to the link for more details.(#5564, #5574)

Encapsulate Token, CA and Certificate operations​

We refactor the token and certificate-related codes, summarize the same businesses, and abstract the ability of certificates to improve scalability, maintainability, and readability.

Refer to the link for more details.(#5502, #5544)

Upgrade Kubernetes Dependency to v1.29.6​

Upgrade the vendered kubernetes version to v1.29.6, 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. (#5656)

Important Steps before Upgrading​

• The CloudCore Authorization feature is disabled by default in release 1.18. If you need to use this feature, please set cloudhub.authorization.enable=true.

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.

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​

• Support Edge Pods Using InClusterConfig to Access Kube-APIServer
• Mapper Supports Video Streaming Data Reporting
• Support Auto-Restarting for Edge Modules
• Introduce keadm ctl Command to Support Pods Query and Restart at Edge
• Keadm Enhancements
• Add MySQL to Mapper Framework
• Upgrade Kubernetes Dependency to v1.28.6

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!

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