31 篇博文 含有标签「KubeEdge」

在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用于登录。下面以通过kubectl在kube-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仓库。

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

KubeEdge v1.19 新增特性：​

• 支持边缘节点上报Event
• 支持边缘节点OTA升级
• Mapper支持设备数据写入
• Mapper框架新增支持OpenTelemetry
• 全新版本Dashboard

新特性概览​

支持边缘节点上报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已废弃。

加利福尼亚州旧金山 – 2024 年 10 月 15 日 – 云原生计算基金会（CNCF）宣布 KubeEdge正式毕业。

感谢我们的 CNCF TOC 赞助人（Sponsor） Cathy Zhang和Lin Sun，以及过去6年中在KubeEdge的开发、治理、落地实践和布道上合作的所有人。

KubeEdge 是一个基于 Kubernetes 的开源边缘计算项目，扩展了云原生生态系统，覆盖数据中心以外的场景和行业。它将 Kubernetes 的原生容器编排和调度功能拓展到边缘，提供边缘应用管理、云边元数据同步以及边缘 IoT 设备管理等能力。

最具影响力的云原生边缘计算社区​

KubeEdge 于 2018 年 11 月由华为云开源。2019 年，它作为第一个云原生边缘项目被接受为 CNCF Sandbox 项目，并在 2020 年 9 月晋升为孵化项目。

自加入 CNCF 以来，项目团队已经扩展到包括来自 15 个组织的维护者，并吸引了来自 35 个国家和 110 个组织的 1600 多名贡献者。参与的组织包括华为云、道客、谐云、中国联通、Inovex、ARM、青云科技、博云、中国移动、浪潮、索尼、中国电信、浙江实验室、浙江大学 SEL 实验室、北京邮电大学和电子科技大学。

“尽管 Kubernetes 起源于大型数据中心的使用，但它已经演变，像 Linux 一样适应新环境，成为边缘计算的领先平台，”CNCF CTO Chris Aniszczyk 说。“KubeEdge 一直处于这一转型的前沿，将 Kubernetes 引入从电动汽车到外太空的新领域。我们期待看到 KubeEdge 项目作为毕业项目的下一个发展方向。”

“KubeEdge 的愿景是将云原生技术扩展到边缘，促进强大的边缘云计算生态系统。今天，它已在许多创新和意想不到的领域得到了应用。这一成就是我们贡献者非凡创造力和奉献精神的体现，他们的努力推动了项目的成功，”KubeEdge TSC 成员 Kevin Wang 和 Yin Ding 说。“毕业标志着一个新的开始，我们期待为整个云原生生态系统探索更大的可能性。”

多行业、多场景广泛的落地实践​

KubeEdge将云原生生态扩展到了数据中心之外的更多场景和行业，当前已广泛应用于CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于在云原生边缘计算领域的独特优势，KubeEdge得到了伙伴和用户的高度认可。

支持引言​

华为云

华为云 CTO 张宇昕表示：“KubeEdge 自开源以来，获得了业界伙伴、用户的关注支持，在智慧交通、金融、能源、网联汽车、机器人、物流等行业领域都取得了突破性的创新实践，KubeEdge 的毕业也将进一步推动企业的云原生数字化转型，释放更大的产业价值。华为云作为云原生技术的先行者与普及者，未来将继续与 CNCF 和社区合作，共同推动云原生产业的发展。”

道客

道客首席运营官张红兵表示：“KubeEdge 的毕业是云原生边缘计算领域的一个重要里程碑。作为 CNCF 官方首个边缘计算项目，KubeEdge 为资源受限的边缘设备提供了强大的计算和管理支持，它的毕业标志着云原生边缘计算的技术成熟和行业认可。自 KubeEdge 项目启动以来，DaoCloud 积极参与其中，从项目规划与治理、核心代码开发以及在制造和零售行业推广贡献了广泛经验。未来，我们也将继续和 KubeEdge 一起，为全球企业和开发者提供更加灵活、安全和高效的解决方案，塑造智能边缘新纪元。”

谐云

谐云资深技术总监、边缘计算负责人魏欢：“祝贺 KubeEdge 开源项目顺利毕业！作为 KubeEdge 开源项目技术指导委员会（TSC）团队成员之一，很高兴亲历 KubeEdge 从孵化到毕业的发展旅程。从发现、试错、提 Issue、提 PR、提 Feature、应用、推广，KubeEdge 是谐云边缘计算团队为客户提供边缘计算产品化交付的核心技术框架中的重要组件，我们在通信、金融、交通、能源、桥梁、物流等领域均有边缘计算落地案例。未来谐云也将持续参与 KubeEdge 社区，共同推进云原生边缘计算产业的发展，释放无处不在的云原生价值！”

青云科技

青云科技可观测性与边缘计算负责人霍秉杰：“KubeEdge 自开源之日起就以其独特的架构引领了云原生边缘计算的潮流，产生了巨大的影响力和示范效应，在推动云原生技术应用的同时也推动了边缘计算的发展。随着越来越多重量级行业用户的采用，以及世界范围内众多社区贡献者的参与，有幸作为 KubeEdge 技术指导委员会(TSC) 的成员见证了 KubeEdge 从孵化到毕业的整个过程，祝贺 KubeEdge 项目成为首个从 CNCF 毕业的边缘计算项目！作为 KubeSphere 的核心维护者，青云科技在深度参与 KubeEdge 项目的同时，也一直在积极推动 KubeEdge 在各行业的落地，青云科技推出的 EdgeWize 3.0 就是以 KubeEdge 为核心构建的边缘计算平台。我们希望与众多国内外的同行和社区用户一起，推动边缘计算的发展！”

ByteDance

KubeEdge 技术指导委员会（TSC）成员 Tina Tsou 表示：“很高兴见证 KubeEdge 从 CNCF 毕业。这一里程碑不仅体现了社区的共同努力，也标志着云原生边缘计算进入了成熟的新阶段。未来，我们将继续与全球的开发者和伙伴紧密合作，推动边缘计算技术的创新与应用，加速各行业的数字化转型。”

博云

博云副总裁崔骥：“KubeEdge 是中国边缘计算架构类软件持续最久，最活跃的项目，在行业中的影响极为深刻，其在工业、交通、装备制造等行业的智能化改造中得到了广泛的采用，为智能制造计划的推进做出了积极的贡献。KubeEdge 社区以积极开放的态度吸引了众多的开源贡献者和合作项目，博云开源的 FabEdge，Carina 等边缘网络、存储组件得到了良好的兼容和项目应用，并落地了多个云边端 AI 模型流转、模型转换和加载项目实践。KubeEdge 的毕业，说明边缘计算技术成熟与产业高速发展期的到来，相信项目在未来一定能够得到更多的落地应用，博云愿与项目社区一起共同推进产业化的发展，支持更多场景的落地实践。”

蔚来汽车

蔚来汽车战略新业务数字系统架构师蒋旭辉：“KubeEdge 作为专为云边协同开发的平台，可以有效解决汽车领域应用云原生技术栈面临的算力稀缺、海量边缘节点、运行环境差异等挑战。我们经过大量调研和选型工作后，以 KubeEdge 为核心构建蔚来整套车云协同平台，并首次用于量产车型，带来开发交付效率、团队协作等方面的显著提升，并将实现超大规模的边缘汽车管理。在此祝贺 KubeEdge 毕业，也期待与社区有更深远的合作，继续推动 KubeEdge 社区的发展，持续构建云原生解决方案在革新 EV 领域中的创新应用。”

顺丰科技

顺丰科技边缘云容器负责人程庞钢：“KubeEdge 开源项目的毕业令人振奋，这是云原生边缘计算领域的新星。顺丰科技在物流领域深耕多年，KubeEdge 如同我们迈向智能化的得力助手。从物流分拣的高效运作到运输环节的全生命周期处理，KubeEdge 所提供的边缘计算能力助力我们打造更智慧、更高效的物流体系。在其发展历程中，我们见证了它的成长与蜕变，也积极将其融入我们的业务场景之中。顺丰科技期待与 KubeEdge 携手同行，在未来不断探索新的可能，将物流行业的智能化推向新的高度，让边缘计算在每一个包裹的流转中发挥更大的价值。”

索尼

索尼美国公司软件工程师 Tomoya Fujita：“看到 KubeEdge 在 CNCF 毕业是最令人兴奋的消息，表明生产就绪的 Kubernetes 边缘解决方案的到来。KubeEdge 将编排能力扩展到边缘环境，提供统一的集群管理和复杂的边缘特定功能。我们相信 KubeEdge 将在不久的将来应用于更多用例，特别是在机器人分布式系统和边缘 AI/ML 应用部署方面。开发、社区参与和增长对于基于开源的活动至关重要。KubeEdge 也在积极鼓励开发者和用户参与社区，这帮助设计出能够支持广泛用例和业务逻辑的 KubeEdge。我们将继续参与和支持 KubeEdge 的开发和社区。”

Zeblok

Zeblok Computational Inc. 平台工程负责人 Vikarna Tathe：“随着 KubeEdge 在 CNCF 毕业，边缘计算领域达到了新的前沿。在 Zeblok Computational Inc.，我们很高兴将 KubeEdge 纳入我们的 Ai-MicroCloud，将尖端 AI 能力直接带到边缘。这种协同推动了在实时智能至关重要的地方的创新。”

OEHI

OEHI 主席 Dirk Pleiter：“KubeEdge 正式在 CNCF 达到下一个成熟阶段，是对其发展成果的强有力认可。开放边缘和 HPC 倡议（OEHI）坚信 KubeEdge 是未来计算连续体基础设施的关键元素。为了为这一新计算基础设施设计范式培养人才，OEHI 在 2024 ISC HPC 会议上共同组织了一场教程，让参与者亲身体验 KubeEdge。未来，我们将继续推动这一技术。”

未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。同时，KubeEdge 将继续探索新领域，如云边协作 AI、云边协作机器人和边缘集群管理。

了解更多关于 KubeEdge 的信息，访问：

• KubeEdge: https://kubeedge.io/
• 网站: https://kubeedge.io/
• GitHub 仓库: https://github.com/kubeedge/kubeedge
• 文档: https://kubeedge.io/docs/
• Slack: https://kubeedge.io/docs/community/slack
• X: https://x.com/kubeedge

北京时间2024年7月26日，KubeEdge发布1.18.0版本。新版本在稳定性、安全性等方面有了显著的提升，同时持续在易用性等方面做了增强。

KubeEdge v1.18 新增特性：​

• RouterManager支持高可用
• CloudCore云边通道鉴权增强
• 支持设备状态上报
• Keadm能力增强
• 封装Token，CA和证书操作，提高扩展性
• 升级K8s依赖到v1.29

新特性概览​

RouterManager支持高可用​

针对CloudCore采用高可用部署时，RouterManager无法准确路由的问题，在新版本中，对RouterManager在高可用部署时做了优化与增强，云端发往边缘的自定义消息将会被路由到对应EdgeNode所连接的CloudCore中，并正确下发到对应的EdgeNode。同时考虑了边界情况，在转发过程中，如果EdgeNode重连到其他CloudCore时，消息将会被重新转发到正确的CloudCore中。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5635 https://github.com/kubeedge/kubeedge/pull/5619

CloudCore云边通道鉴权增强​

CloudCore 作为连接边缘节点和Kube-APIServer的桥梁，需要限制边缘节点对集群资源的访问权限。在新版本中，我们对云边通道的安全性进行了增强，CloudHub会识别消息发送方并校验其是否有足够的权限，从而限制边缘节点操作其他节点的资源。 v1.18.0目前已支持node authorization模式。该特性引入了如下配置参数，在新版本中默认关闭，开启如下开关即可启用该特性。

apiVersion: v1
data:
  cloudcore.yaml:
  ...
  modules：
    cloudhub:
      authorization:
        // optional, default false, toggle authoration
        enable: true
        // optional, default to false, do authorization but always allow all the requests
        debug: false
        // required, an authorizer chain
        authorizers:
          // node authorization mode
          - node:
          ebable：true
  ...

为了安全启用此特性，可以先开启debug。当鉴权失败时，CloudCore只记录日志，但请求仍会正常处理。

更多信息可参考:

https://github.com/kubeedge/kubeedge/pull/5512 https://github.com/kubeedge/kubeedge/pull/5585

支持设备状态上报​

设备有其自身的状态，比如在线、离线、异常等。1.18.0版本支持了设备状态上报的能力。该特性在Mapper-Framework已经默认实现，用户基于Mapper-Framework生成自己需要的mapper，即可使用。状态上报成功后，可通过device的资源查看结果：

apiVersion: devices.kubeedge.io/v1beta1
kind: Device
...
spec:
  status:
    lastOnlineTime: "2024-07-30T17:55:49Z"
    state: ok
    twins:
    - observedDesired:
    ...

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5650 https://github.com/kubeedge/kubeedge/pull/5649 https://github.com/kubeedge/kubeedge/pull/5651

Keadm能力增强​

在旧版本中，使用keadm join安装EdgeCore只能指定部分参数的配置。在最新版本中，我们对EdgeCore的配置流程进行了显著优化。现在，您无需等待节点接入完成,手动编辑edgecore.yaml配置文件，再重启EdgeCore。通过在keadm join命令中使用新增的--set参数，您可以在节点加入时直接设置配置，就像使用Helm配置values.yaml一样便捷。这一改进大大简化了配置管理过程，提高了效率。下列指令是一个开启MetaServer的样例：

keadm join --set modules.metaManager.enable=true,modules.metaManager.metaServer.enable=true,modules.metaManager.remoteQueryTimeout=32

更多信息可参考：

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

封装Token，CA和证书操作，提高扩展性​

在本版本中，我们对Token和Certificate的处理进行了彻底的整理和优化。原先分散在代码各处的处理逻辑现在已被集中管理，显著降低了维护成本。Token处理已被集成到一个统一的工具包中，而Certificate的处理则通过接口抽象化，不仅支持自建CA流程，还适配了通过Kubernetes CSR申请Certificate的流程。此外，我们的设计允许未来轻松扩展以支持更多类型的私钥和客户自定义的Certificate。此次重构不仅提升了Token和Certificate业务代码的可读性和可维护性，而且保持了对外接口的完全向下兼容性，确保了现有系统的无缝升级。

更多信息可参考：

https://github.com/kubeedge/kubeedge/pull/5502 https://github.com/kubeedge/kubeedge/pull/5544

升级K8s依赖到v1.29​

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

更多信息可参考：

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

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.