Skip to main content

21 posts tagged with "kubernetes edge computing"

View All Tags

· 3 min read
KubeEdge SIG Release

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​

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!

· 6 min read
KubeEdge SIG Release

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.

· 4 min read
KubeEdge SIG Release

On Mar 7, 2022, KubeEdge released v1.10. The new version introduces several enhancements, significantly improving the installation experience, performance testing, network communication, and Kubernetes version compatibility.

v1.10 What's New​

Release Highlights​

Installation Experience Improvement with Keadm​

Keadm adds some new sub-commands to improve the user experience, including containerized deployment, offline installation, etc. New sub-commands including: beta, config.

beta provides some sub-commands that are still in testing, but have complete functions and can be used in advance. Sub-commands including: beta init, beta manifest generate, beta join, beta reset.

  • beta init: CloudCore Helm Chart is integrated in beta init, which can be used to deploy containerized CloudCore.

  • beta join: Installing edgecore as system service from docker image, no need to download from github release.

  • beta reset: Reset the node, clean up the resources installed on the node by beta init or beta join. It will automatically detect the type of node to clean up.

  • beta manifest generate: Generate all the manifests to deploy the cloudside components.

config is used to configure kubeedge cluster, like cluster upgrade, API conversion, image preloading. Now the image preloading has supported, sub-commands including: config images list, config images pull.

  • config images list: List all images required for kubeedge installation.

  • config images pull: Pull all images required for kubeedge installation.

Refer to the links for more details. (#3517, #3540, #3554, #3534)

Preview version for Next-gen Edged: Suitable for more scenarios​

A new version of the lightweight engine Edged, which is optimized from kubelet and integrated in edgecore, and occupies less resource. Users can customize lightweight optimization according to their needs.

Refer to the links for more details. (Dev-Branch for previewing: feature-new-edged)

Edgemark: Support large-scale KubeEdge cluster performance testing​

Edgemark is a performance testing tool inherited from Kubemark. The primary use case of Edgemark is also scalability testing, it allows users to simulate edge clusters, which can be much bigger than the real ones.

Edgemark consists of two parts: real cloud part components and a set of "Hollow" Edge Nodes. In "Hollow" Edge Nodes, EdgeCore runs in container. The edged module runs with an injected mock CRI part that doesn't do anything. So the hollow edge node doesn't actually start any containers, and also doesn't mount any volumes.

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

EdgeMesh proxy tunnel supports quic​

Users can choose edgemesh's proxy tunnel as quic protocol to transmit data. In edge scenarios, nodes are often in a weak network environment. Compared with the traditional tcp protocol, the quic protocol has better performance and QoS in the weak network environment.

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

EdgeMesh supports proxy for udp applications​

Some users' services use the udp protocol, and now edgemesh can also support the proxy of udp applications.

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

EdgeMesh support SSH login between cloud-edge/edge-edge nodes​

Edge nodes are generally distributed in the Private network environment, but it is often necessary to ssh login and operate the edge node. EdgeMesh provide a socks5proxy based on the tunnel inside EdgeMesh, which supports forwarding ssh requests from cloud/edge nodes to edge nodes.

Refer to the links for more details. (#258, #242)

Kubernetes Dependencies Upgrade​

Upgrade the vendered kubernetes version to v1.22.6, users now can use the feature of new version on the cloud and on the edge side.

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

Important Steps before Upgrading​

If you want to deploy the KubeEdge v1.10.0, please note that the Kubernetes dependency is 1.22.6.

Other Notable Changes​

  • Remove dependency on os/exec and curl in favor of net/http (#3409, @mjlshen)

  • Optimize script when create stream cert (#3412, @gujun4990)

  • Cloudhub: prevent dropping volume messages (#3457, @moolen)

  • Modify the log view command after edgecore is running (#3456, @zc2638)

  • Optimize the iptables manager (#3461, @zhu733756)

  • Add script for build release (#3467, @gy95)

  • Using lateset codes to do keadm_e2e (#3469, @gy95)

  • Change the resourceType of msg issued by synccontroller (#3496, @Rachel-Shao)

  • Add a basic image for building various components of KubeEdge (#3513, @zc2638)

  • Supporting crossbuild all components (#3515, [@fisher

· 3 min read
KubeEdge SIG Release

The KubeEdge community is thrilled to announce the release of KubeEdge v1.12! This release introduces several exciting new features and enhancements, including alpha implementation of the next-generation Cloud Native Device Management Interface (DMI), a new version of the lightweight Edged engine, high-availability mode for EdgeMesh, edge node upgrades from the cloud, authorization for the Edge Kube-API endpoint, and more.

What's New in KubeEdge v1.12​

Alpha Implementation of Next-Gen Cloud Native Device Management Interface (DMI)​

DMI makes KubeEdge's IoT device management more pluggable and modular in a cloud-native way, covering Device Lifecycle Management, Device Operation, and Device Data Management.

  • Device Lifecycle Management: Simplifies IoT device lifecycle management, making it as easy as managing a pod.

  • Device Operation: Provides the ability to operate devices through the Kubernetes API.

  • Device Data Management: Separates device data management from device management, allowing data to be consumed by local applications or synchronized to the cloud through a special tunnel.

Next-Gen Edged Graduates to GA: Suitable for More Scenarios​

The new version of the lightweight Edged engine, optimized from Kubelet and integrated into EdgeCore, has graduated to General Availability (GA) in this release. The new Edged will continue to communicate with the cloud through a reliable transmission tunnel, making it suitable for a wider range of scenarios.

Introducing High-Availability Mode for EdgeMesh​

KubeEdge v1.12 introduces a high-availability mode for EdgeMesh. Unlike the previous centralized relay mode, the EdgeMesh HA mode can set up multiple relay nodes. When some relay nodes fail, other relay nodes can continue to provide relay services, avoiding single points of failure and improving system stability.

Support Edge Node Upgrade from the Cloud​

KubeEdge v1.12 introduces the NodeUpgradeJob v1alpha1 API to upgrade edge nodes from the cloud. With this API and its associated controller, users can upgrade selected edge nodes from the cloud and roll back to the original version if the upgrade fails.

Support Authorization for Edge Kube-API Endpoint​

Authorization for the Edge Kube-API Endpoint is now available in KubeEdge v1.12. Third-party plugins and applications that depend on Kubernetes APIs on edge nodes must use a bearer token to communicate with the kube-apiserver via the HTTPS server in MetaServer.

New GigE Mapper​

KubeEdge v1.12 includes a new GigE Device Mapper with a Golang implementation, which is used to access GigE Vision protocol cameras.

Important Steps Before Upgrading​

  • If you want to upgrade KubeEdge to v1.12, the configuration file in EdgeCore has been upgraded to v1alpha2. You must modify your configuration file for Edged in EdgeCore to adapt to the new Edged.

  • If you want to use authorization for the Edge Kube-API Endpoint, please enable the RequireAuthorization feature through the feature gate in both CloudCore and EdgeCore. If the RequireAuthorization feature is enabled, MetaServer will only serve HTTPS requests.

  • If you want to upgrade EdgeMesh to v1.12, you do not need to deploy the existing EdgeMesh-server, but you need to configure relayNodes.

  • If you want to run EdgeMesh v1.12 on KubeEdge v1.12 and use HTTPS requests to communicate with KubeEdge, you must set kubeAPIConfig.metaServer.security.enable=true.

KubeEdge v1.12 brings exciting new features and improvements to the edge computing ecosystem. We invite you to explore the release and provide feedback to the community. Happy edge computing!