Skip to main content

3 posts tagged with "dashboard"

View All Tags

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

· 3 min read
KubeEdge

In KubeEdge v1.19, we introduced a new version of the KubeEdge Dashboard. This version of KubeEdge Dashboard is built with the Next.js framework and the MUI component library to offer better performance. Meanwhile, we have optimized and enhanced several modules of the KubeEdge Dashboard, including the device management and device model management modules.

In this article, we will introduce how to deploy and use the KubeEdge Dashboard.

Environment Pre-requisites​

We can obtain the source code of KubeEdge Dashboard from the KubeEdge Dashboard GitHub repository. Before building and deploying KubeEdge Dashboard, please ensure the following environment is set up:

  • KubeEdge Cluster: Please refer to the KubeEdge official documentation to set up a KubeEdge cluster. KubeEdge Dashboard requires KubeEdge v1.15 or later versions.
  • Node.js: Install Node.js on your system, it is recommended to use Node.js v18 or later versions.
  • Node.js Package Manager: Install a Node.js package manager, such as npm, yarn, or pnpm.

Building and Deploying​

Once the environment is set up and the KubeEdge Dashboard source code has been downloaded, we can use the Node.js package manager to start the KubeEdge Dashboard. In the following instructions, we will use pnpm as the example to show how to install dependencies and run KubeEdge Dashboard.

First of all, we need to install the dependencies:

pnpm install

KubeEdge Dashboard interacts with KubeEdge resources via the Kubernetes API. Therefore, we need to set the API_SERVER environment variable to specify the API Server address:

pnpm run build
API_SERVER=https://192.168.33.129:6443 pnpm run start

After starting KubeEdge Dashboard, open http://localhost:3000 in your browser to access the dashboard.

For the KubeEdge cluster with self-signed certificates, we need to set the NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable to bypass certificate verification:

NODE_TLS_REJECT_UNAUTHORIZED=0 API_SERVER=<api-server> pnpm run start

Creating a Login Token​

To authenticate with KubeEdge Dashboard, we need to create a token for login. The following instructions show how to create a service account dashboard-user in the kube-system namespace and generate a token for authentication.

First, we need to create a service account in the Kubernetes cluster:

kubectl create serviceaccount dashboard-user -n kube-system

To grant permissions to the service account, we need to create a cluster role binding that associates the service account with a cluster role. Kubernetes provides some built-in cluster roles, such as cluster-admin, which has access to all resources in the cluster. We can also refer to the Kubernetes documentation to create a custom cluster role if needed.

kubectl create clusterrolebinding dashboard-user-binding --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-user -n kube-system

Since Kubernetes v1.24, secrets for service accounts are no longer created automatically. We need to create an associated token by the kubectl create token command. The lifetime of the token will be determined by the server automatically, and we can specify the lifetime of the token by the --duration option.

kubectl create token dashboard-user -n kube-system

For Kubernetes v1.23 and earlier versions, Kubernetes automatically creates a secret for the service account. We can retrieve the secret by the kubectl describe secret command:

kubectl describe secret -n kube-system $(kubectl get secret -n kube-system | grep dashboard-user | awk '{print $1}')

Conclusion​

With KubeEdge Dashboard, we can more easily manage KubeEdge resources such as edge applications and devices. We will continue to enhance and optimize the KubeEdge Dashboard and user experience in future releases. We also welcome feedback and suggestions from the community.

For more information on KubeEdge Dashboard, please refer to the KubeEdge Dashboard GitHub repository.

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