跳到主要内容

3 篇博文 含有标签「dashboard」

查看所有标签

· 阅读需 9 分钟

北京时间2025年1月21日,KubeEdge发布1.20.0版本。新版本针对大规模、离线等边缘场景对边缘节点和应用的管理、运维等能力进行了增强,同时新增了多语言Mapper-Framework的支持。

KubeEdge v1.20 新增特性:

新特性概览

支持批量节点操作

在之前的版本中,keadm工具仅支持单个节点的安装与管理,然而在边缘场景中,节点数量通常比较庞大,单个节点的管理难以满足大规模场景的需求。

在1.20版本中,我们提供了批量节点操作和运维的能力。基于这个能力,用户仅需要使用一个配置文件,即可通过一个控制节点(控制节点可以登录所有边缘节点)对所有边缘节点进行批量操作和维护。keadm当前版本支持的批量能力包括join, reset和upgrade。

# 配置文件配置要求参考如下
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.`

# 配置文件参考用例 (各字段具体值请根据实际环境进行配置)
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

# 用法 (保存以上文件,例如保存为 config.yaml)
# 在控制节点下载最新版本 keadm, 执行以下命令进行使用
keadm batch -c config.yaml

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5988 https://github.com/kubeedge/kubeedge/pull/5968 https://github.com/kubeedge/website/pull/657

多语言Mapper-Framework支持

由于边缘IoT设备通信协议的多样性,用户可能需要使用Mapper-Framework生成自定义Mapper插件来纳管边缘设备。当前Mapper-Framework只能生成go语言版本的Mapper工程,对于部分不熟悉go语言的开发者来说使用门槛仍然较高。因此在新版本中,KubeEdge提供了Java版本的Mapper-Framework,用户可以访问 KubeEdge主仓库 的 feature-multilingual-mapper 分支,利用 Mapper-Framework 生成 Java 版的自定义 Mapper 工程。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5773 https://github.com/kubeedge/kubeedge/pull/5900

边缘keadm ctl新增 pods logs/exec/describe 和 Devices get/edit/describe 能力

在v1.17.0版本中,我们新增了keadm ctl子命令,支持在离线场景下对边缘pod进行查询和重启。在v1.20中我们对该命令做了进一步增强,支持pod的logs/exec/describe等功能,用户在边缘可对pod进行日志查询、pod资源详细信息查询、进入容器内部等操作。同时还新增了对device的操作,支持device的get/edit/describe的功能,可以在边缘获取device列表、device的详细信息查询、在边缘离线场景下对device进行编辑操作。

如下所示,新增的keadm ctl子命令功能均在MetaServer中开放了Restful接口,并与K8s ApiServer对应的接口完全兼容。

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

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5752 https://github.com/kubeedge/kubeedge/pull/5901

解耦边缘应用与节点组,支持使用Node LabelSelector

EdgeApplication 可以通过节点组覆盖部署定义(如副本、镜像、命令和环境),Pod 流量在节点组内闭环(EdgeApplication 管理的 Deployment 共用一个 Service)。但在实际场景中,需要批量操作的节点范围与需要相互协作的节点范围并不相同。例如在智慧园区的场景中,每个城市都有很多个智慧园区,我们需要应用的流量在一个智慧园区内闭环,但应用批量管理的范围可能是城市级,也可能是省级。

我们在 EdgeApplication CRD 中为节点标签选择器添加了一个新的 targetNodeLabels 字段,该字段将允许应用程序根据节点标签进行部署,并且覆盖特定的字段,YAML定义如下:

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"

更多信息可参考:

Issue: https://github.com/kubeedge/kubeedge/issues/5755

Pull Request: https://github.com/kubeedge/kubeedge/pull/5845

边云通道支持IPv6

我们在官网的文档中提供了一份配置指南,介绍了KubeEdge如何在Kubernetes集群中让云边 hub 隧道支持IPv6。文档地址:https://kubeedge.io/docs/advanced/support_ipv6

升级K8s依赖到v1.30

新版本将依赖的Kubernetes版本升级到v1.30.7,您可以在云和边缘使用新版本的特性。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5997

版本升级注意事项

  • 从v1.20.0版本开始,EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet,如果您需要继续使用原有路径,可以在使用keadm安装EdgeCore时设置--set edged.rootDirectory=/var/lib/edged

· 阅读需 5 分钟

在KubeEdge v1.19版本中,我们引入了重构后的全新版本KubeEdge Dashboard,该版本的KubeEdge Dashboard采用了Next.js框架及MUI组件库,具有更好的性能和用户体验。同时,我们还对KubeEdge Dashboard的功能进行了优化和增强,包括对仪表盘设备管理以及设备模型管理等功能进行了优化。

在本文中,我们将介绍KubeEdge Dashboard的部署和使用。

环境准备

首先,我们需要获取KubeEdge Dashboard的源代码并进行运行环境的准备。最新的KubeEdge Dashboard源代码可以从KubeEdge Dashboard代码仓库获取。

在部署KubeEdge Dashboard之前,我们需要准备以下环境:

  • KubeEdge集群:请参考KubeEdge官方文档部署KubeEdge集群,KubeEdge Dashboard依赖于KubeEdge v1.15及以上版本。
  • Node.js:请确保系统中已经安装了Node.js,建议使用Node.js v18及以上版本。
  • Node.js包管理工具:请确保系统中已经安装了Node.js包管理工具,例如npm、yarn或者pnpm。

安装与运行

下面我们以pnpm为例,介绍如何在本地环境中安装和运行KubeEdge Dashboard。首先,我们需要在项目根目录中通过包管理工具安装KubeEdge Dashboard所需的依赖:

pnpm install

由于KubeEdge Dashboard需要连接到KubeEdge后端API,我们需要在启动KubeEdge Dashboard时设置API_SERVER环境变量,以指定KubeEdge集群的API Server地址。以Kubernetes API Server地址为192.168.33.129:6443为例,我们可以通过下面的命令编译并启动KubeEdge Dashboard:

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

在启动KubeEdge Dashboard后,我们可以通过浏览器访问http://localhost:3000查看KubeEdge Dashboard的界面。

对于使用自签名证书的KubeEdge集群,我们需要在启动KubeEdge Dashboard时指定NODE_TLS_REJECT_UNAUTHORIZED=0环境变量,以忽略证书验证。

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

创建登录Token

为了通过KubeEdge Dashboard管理KubeEdge集群,我们需要创建一个Token用于登录。下面以通过kubectlkube-system命名空间中创建一个名为dashboard-user的ServiceAccount为例,创建一个用于KubeEdge Dashboard身份验证的Token。

首先,我们需要在Kubernetes集群中创建一个ServiceAccount。

kubectl create serviceaccount dashboard-user -n kube-system

在创建ServiceAccount后,我们需要将ServiceAccount与ClusterRole绑定,以授予相应的权限。Kubernetes提供了一些内置的角色,例如cluster-admin角色,它拥有集群中所有资源的访问权限。另外,也可以参考Kubernetes文档根据需要创建自定义的ClusterRole。

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

对于Kubernetes v1.24及以上版本,Kubernetes将不再自动为ServiceAccount创建Secret,我们需要通过kubectl create token命令创建token。默认情况下,该token的有效期根据服务器配置确定,也可以通过--duration参数指定token的有效期。

kubectl create token dashboard-user -n kube-system

对于Kubernetes v1.23及以下版本,Kubernetes会自动为ServiceAccount创建Secret。我们可以使用kubelet describe secret命令获取,或使用下面的命令快速获取对应的Secret。

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

结论

通过KubeEdge Dashboard,我们可以更方便地管理KubeEdge集群中的EdgeApplication及设备等资源。我们也将在后续版本中继续增强和优化KubeEdge Dashboard的功能和用户体验,也欢迎社区用户提出宝贵的意见和建议。

对于KubeEdge Dashboard的更多信息,请参考KubeEdge Dashboard GitHub仓库

· 阅读需 7 分钟

北京时间2024年10月28日,KubeEdge发布1.19.0版本。新版本在节点和设备方面引入了多个新特性,同时带来了全新版本的 Dashboard。

KubeEdge v1.19 新增特性:

新特性概览

支持边缘节点上报Event

Kubernetes Event作为集群中事件的报告,可以反馈节点、Pods等集群资源的状态变化。在1.19版本中,EdgeCore支持了边缘Event的上报,用户可以直接在云端通过 kubectl get events 或者kubectl describe {resource_type} {resource_name}获取边缘节点或者pods等状态。

该特性在1.19版本中默认关闭,使用EdgeCore时执行 --set modules.edged.reportEvent=true 或者如下修改EdgeCore配置参数并重启EdgeCore。

apiVersion: edgecore.config.kubeedge.io/v1alpha2
kind: EdgeCore
featureGates:
requireAuthorization: true
modules:
...
edged:
reportEvent: true
...

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5722 https://github.com/kubeedge/kubeedge/pull/5811

支持边缘节点OTA升级

新版本在节点升级NodeUpgradeJob基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后,在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的kubeedge/installation-pacakge镜像是安全可靠的。

在1.19版本中,我们可以通过YAML配置NodeUpgradeJob的imageDigestGatter来定义镜像摘要,value用于直接定义摘要的值,registryAPI用于通过registry v2接口获取镜像摘要,两者互斥,如果都没有配置则在升级时不进行镜像摘要的校验,样例:

spec:
...
imageDigestGatter:
value: ""
registryAPI:
host: ""
token: ""

我们还可以通过YAML配置NodeUpgradeJob的requireConfirmation来定义是否要在边端进行确认操作,样例:

spec:
...
requireConfirmation: true

当requireConfirmation设置为true时,在边端节点升级任务下发到边端后,任务状态会更新为confirmation状态等待边端发起确认命令后再继续进行升级。

我们可以通过执行keadm ctl confirm指令进行确认,或者调用Metaserver接口进行确认,以继续升级任务:

POST http(s)://localhost:<metaserver_port>/confirm

更多信息可参考:

https://github.com/kubeedge/kubeedge/issues/5589 https://github.com/kubeedge/kubeedge/pull/5761 https://github.com/kubeedge/kubeedge/pull/5863

Mapper支持设备数据写入

Mapper当前能够采集设备数据并上报,但在设备数据写入方面仍不完善。1.19版本在Mapper-Framework中增加了设备数据写入的能力,允许用户通过Mapper提供的API调用device method,对device property完成数据写入

  • Device method API

目前基于物模型的v1beta1版本的设备管理API包含device property的定义,在1.19版本中,新增device method的定义。Device method指设备能够被外部调用的能力或方法,一个device method能够控制多个device property值。用户能在device-instance文件中定义device method,通过device method完成device property的控制、写入。

spec:
...
methods:
- name: ""
description: ""
propertyNames:
- ""
  • 设备数据写入

在1.19中改进Mapper API能力,新增device method调用接口。用户能够调用相关的接口获取某个设备包含的所有device method,以及device method的调用命令,通过返回的调用命令发起设备写入请求。device method的具体功能实现需要用户自行在Mapper的设备驱动层中完成。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5662 https://github.com/kubeedge/kubeedge/pull/5902

Mapper框架新增支持OpenTelemetry

当前Mapper向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式,但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架,能够封装设备数据并向多类应用或数据库推送数据,例如GreptimeDB、 Prometheus等,增强Mapper数据面推送设备数据的能力。

spec:
...
properties:
- name: ""
pushMethod:
otel:
endpointURL: ""

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5574 https://github.com/kubeedge/kubeedge/pull/5564

全新版本Dashboard

之前发布的KubeEdge Dashboard,新版本使用主流的Next.js框架以及MUI样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件,基于KubeEdge最新版本的后端API,我们完善并增加了Device等相关功能页面,并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中,我们整理完善了Kubernetes以及KubeEdge后端接口的Typescript类型定义,并将依赖的后端接口更新至最新版本,确保其与最新的KubeEdge兼容。

更多信息可参考:

https://github.com/kubeedge/dashboard/pull/29

版本升级注意事项

  • 下个版本(v1.20),EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet,如果您需要继续使用原有路径,可以在使用keadm安装EdgeCore时设置--set edged.rootDirectory=/var/lib/edged

  • 从1.19版本开始,请在使用keadm安装KubeEdge时,使用--kubeedge-version指定版本,--profile version已废弃。