Skip to main content

20 posts tagged with "iot"

View All Tags

· 4 min read
KubeEdge SIG Release

On June 28, 2025, KubeEdge released v1.21.

1.21 What's New​

Release Highlights​

New Generation Node Task API and Implementation​

In v1.21, we redesigned the status structure and operation process of node jobs to track error information and facilitate developers' understanding. In the new design, the node job status includes Phase (Init, InProgress, Completed, Failure) and nodeStatus. The nodeStatus consists of Phase (Pending, InProgress, Successful, Failure, Unknown), actionFlow, nodeName, reason, and business-related fields. A YAML example of the NodeUpgradeJob status is provided below.

status:
  nodeStatus:
    - actionFlow:
        - action: Check
          status: 'True'
          time: '2025-05-28T08:12:01Z'
        - action: WaitingConfirmation
          status: 'True'
          time: '2025-05-28T08:12:01Z'
        - action: Backup
          status: 'True'
          time: '2025-05-28T08:12:01Z'
        - action: Upgrade
          status: 'True'
          time: '2025-05-28T08:13:02Z'
      currentVersion: v1.21.0
      historicVersion: v1.20.0
      nodeName: ubuntu
      phase: Successful
  phase: Completed

Refer to the link for more details.(#6082, #6084)

Support Closed Loop Flow Control​

In v1.21, we have optimized the traffic closed-loop function of node groups. Applications within a node group can only access application services within the same group and unable to access services of other node groups. With this mechanism, users can easily achieve network isolation between multiple edge regions, ensuring that application services in different regions do not interfere with each other.

Refer to the link for more details.(#6097, #6077)

Support Update Edge Configuration from Cloud​

In many cases, cloud-based direct updates to EdgeCore configuration files for edge nodes offer greater convenience than manual updates from edge node, especially for batch operations that boost efficiency by managing multiple nodes simultaneously.

In v1.21.0, ConfigUpdateJob CRD is introduced to allows users to update configuration files for edge nodes in the cloud. The updateFields within the CRD is used to specify the configuration items that need to be updated.

CRD Sample:

apiVersion: operations.kubeedge.io/v1alpha2
kind: ConfigUpdateJob
metadata:
  name: configupdate-test
spec:
  failureTolerate: "0.3"
  concurrency: 1
  timeoutSeconds: 180
  updateFields:
    modules.edgeStream.enable: "true"
  labelSelector:
    matchLabels:
      "node-role.kubernetes.io/edge": ""
      node-role.kubernetes.io/agent: ""
note
  • This feature is disabled by default in v1.21.0. To enable it, please start the ControllerManager and TaskManager at cloud, as well as the TaskManager edge.
  • Updating edge configurations will require a restart of EdgeCore.

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

Support One-Click Deployment of Dashboard and Integration of kubeedge/keink​

In v1.21, the dashboard functionality has been enhanced by designing a BFF (Backend for Frontend) layer to connect the frontend user interface layer with the KubeEdge backend API. Additionally, the dashboard is integrated with the keink project, allowing users to launch a keink cluster in the dashboard environment with just one command to experience KubeEdge features.

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

Important Steps before Upgrading​

  • From v1.21, the v1alpha2 node job enables by default, and the CRD definition will be backward compatible. If you want to continue to use the v1alpha1 version of the NodeUpgradeJob and ImagePrePullJob, please setting the feature gates of ControllerManager and CloudCore.
    • Add a command arg for ControllerManager:
      --feature-gates=disableNodeTaskV1alpha2
    • Modify the CloudCore configuration:
      apiVersion: cloudcore.config.kubeedge.io/v1alpha2
      kind: CloudCore
      featureGates:
        disableNodeTaskV1alpha2: true
      ...
note

The node job v1alpha2 CRDs are compatible with v1alpha1, but they cannot be switched between them. The code logic of v1alpha1 will destroy the data of v1alpha2 node job CR.

The v1alpha1 node jobs will no longer be maintained, and relevant codes will be clean up after v1.23. In addition, the node job has become a default disabled Beehive module in EdgeCore. If you want to use the node jobs, please modify the edgecore.yaml to enable it.

  modules:
    ...
    taskManager:
      enable: true
  • From v1.21, keadm upgrade related commands(backup, upgrade, rollback) at the edge have been adjusted.
    • The upgrade command will not automatically execute the backup. The backup command needs to be triggered manually.
    • The upgrade command hides business-related flags and relevant codes will be cleaned up after v1.23.
    • All upgrade related commands use level 3 commands:
    keadm edge upgrade
    keadm edge backup
    keadm edge rollback

· 6 min read
KubeEdge SIG Release

On January 21, 2025, KubeEdge released v1.20. The new release has enhanced the capabilities of managing and operating edge nodes and applications for large-scale, offline and other edge scenarios. At the same time, it has added support for the multi-language Mapper-Framework.

1.20 What's New​

Release Highlights​

Support Batch Node Process​

Previously, the keadm tool of KubeEdge only supports manual single-node management. However, in edge scenarios, the scale of nodes is often very large, and the management process of a single node can no longer cope with such large-scale scenarios.

In v1.20, we have provided the batch node operation and maintenance capability. With this capability, users only need to use one configuration file to perform batch operation and maintenance on all edge nodes through a control node (which can log in to all edge nodes). The supported operation and maintenance capabilities include join, reset, and upgrade.

# Configuration Requirements
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.`

# Configuration Example
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

# Usage
keadm batch -c config.yaml

Refer to the link for more details.(#5988, #5968)

Multi-language Mapper-Framework Support​

To further reduce the complexity of developing custom Mapper, in this version, KubeEdge provides the Java version of Mapper-Framework. Users can access the KubeEdge feature-multilingual-mapper branch to use Mapper-Framework to generate a Java version of custom Mapper project.

Refer to the link for more details.(#5773, #5900)

Support Pods logs/exec/describe and Devices get/edit/describe Operation at Edge Using keadm ctl​

In v1.17, a new command keadm ctl has been introduced to support pods query and restart at Edge. In this release, keadm ctl supports more functionality including pod logs/exec/describe and device get/edit/describe to help users operate resources at edge, especially in offline scenarios.

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

Refer to the link for more details.(#5752, #5901)

Decouple EdgeApplications from NodeGroups, Support Node Label Selector​

EdgeApplication can be overrides deployment spec(i.e. replicas, image, commands and environments) via the node group, and pod traffics are closed-loop in a node group(Deployments managed by EdgeApplication share a Service). But in the real scenario, the scope of nodes that need batch operations is different from that of nodes that need to collaborate with each other.

We add a new targetNodeLabels field for node label selectors in the EdgeApplication CRD, this field will allow the application to deploy based on node labels and apply overrides specific to those nodes.

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"

Refer to the link for more details.(#5755, #5845)

CloudHub-EdgeHub Supports IPv6​

We provide a configuration guide in the documentation on the official website, which is how KubeEdge enables the cloud-edge hub to support IPv6 in a K8s cluster.

Refer to the document https://kubeedge.io/docs/advanced/support_ipv6

Upgrade Kubernetes Dependency to v1.30.7​

Upgrade the vendered kubernetes version to v1.30.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. (#5997)

Important Steps before Upgrading​

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

· 4 min read
KubeEdge SIG Release

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​

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.

· 2 min read
KubeEdge SIG Release

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​

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.

· 10 min read
Tomoya Fujita

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.