KubeEdge 边缘节点 Windows 支持EdgeCore 移植方案与实现解析【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge导读本文基于 KubeEdge 官方提案docs/proposals/sig-node/edge-on-windows.md系统讲解如何在 Windows Server 上运行 KubeEdge 边缘节点。文章首先剖析 EdgeCore 各模块对操作系统能力的依赖指出问题核心在 Edged随后给出完整的改造思路通过补齐 Kubelet Windows 相关配置字段、使 containerd 在 Windows 上运行、配合 CloudCore 与 Keadm 完成一整套可落地的实施任务清单。读完本文你将掌握 KubeEdge 从 Linux 扩展至 Windows 生态的技术原理、代码改造点WindowsService与WindowsPriorityClass以及分阶段验证方案。背景为什么需要 Windows 边缘节点KubeEdge 将 Kubernetes 的容器化编排能力延伸到边缘主机基于 Kubernetes 构建为云与边缘之间提供网络、应用部署和元数据同步等基础能力已在工业边缘计算场景中被广泛采用。尽管 KubeEdge 已支持 Linux、Android 等操作系统并拥有大量成功案例但它目前不支持 Windows Server这限制了它在部分潜在边缘计算场景中的能力。边缘计算涉及传感器、摄像头、工业控制设备等多种设备其中一些可能运行 Windows 操作系统同时许多企业的 IT 基础设施中部署了 Windows 服务器并已运行部分应用和服务。要让边缘计算与既有基础设施融合、推动边缘计算生态发展KubeEdge 就必须能在 Windows Server 节点上运行。从技术可行性上看当前 KubeEdge 的云端节点可以以 Kubernetes Pod 方式运行而边缘侧节点需要在支持 Docker、containerd 等容器技术的系统上运行无需运行 Kubernetes。微软已经提供了基于**进程隔离Process Isolation**和Hyper-V 隔离的容器化方案两者都能成功运行 containerd这为 KubeEdge 在 Windows 上运行创造了条件。目标本项目旨在让 KubeEdge 的边缘节点运行在 Windows Server 上从而将 KubeEdge 扩展到 Windows 生态系统扩大其在物联网领域的用例与生态。现状分析EdgeCore 为什么无法在 Windows 上运行KubeEdge 是一个在边缘计算节点上运行本地化 Kubernetes 集群的开源系统。它由 Cloud 与 Edge 两大部分组成Cloud 组件运行在云服务器的 Kubernetes 环境中Edge 组件运行在边缘设备上。两者都必须在受支持的操作系统上运行。CloudCore云端组件CloudCore 是运行在云端的核心组件负责管理边缘节点与应用并与边缘节点通信包含以下模块CloudHub负责与 EdgeHub 建立 WebSocket 连接并转发来自边缘节点的消息EdgeController负责将云端的资源状态节点、Pod、ConfigMap、Secret 等同步到边缘节点DeviceController负责管理边缘设备的生命周期并同步设备状态与设备模型。EdgeCore边缘侧核心组件EdgeCore 是运行在边缘节点上的核心组件负责运行容器与设备、与云端通信包含以下重要模块DeviceTwin负责存储边缘设备的状态与属性并与 DeviceController 同步Edged负责管理边缘节点上的容器包括创建、启动、停止、删除等操作功能与 kubelet 类似但更轻量EdgeHub负责与 CloudHub 建立 WebSocket 连接并转发来自云端的消息EventBus负责与 MQTT 服务器通信提供发布/订阅pub/sub能力MetaManager负责管理边缘节点上的元数据包括 Pod、ConfigMap、Secret 等ServiceBus一个 HTTP 客户端与 HTTP 服务器REST交互为云组件访问边缘侧 HTTP 服务器提供 HTTP 客户端功能。这些模块由 EdgeCore 启动时统一注册。下图展示了registerModules函数见 edge/cmd/edgecore/app/server.go如何按顺序注册上述核心模块主要难点Edged 模块在 Windows 上运行边缘节点的最大挑战在于运行 EdgeCore。EdgeCore 的六个组件以 Goroutine 方式运行但即便如此它们仍依赖其他外部组件。例如 EventBus 依赖外部 Mosquitto 服务器——如果 Mosquitto 不支持在 Windows 上运行则启用 EventBus 的 EdgeCore 就无法运行。要让 EdgeCore 在 Windows 上运行需要先分析其无法运行的原因并逐一解决。首先可以尝试编译 Windows 版本的 EdgeCore——它能启动但会因内部错误退出。逐模块分析如下DeviceTwin依赖 SqliteSqlite 不应因系统差异出现问题Edged它是 kubelet 的轻量版本需要与系统中的 CRI 和 RuntimeCgroups 交互。如果系统中没有容器运行时和相关的 Cgroups该模块将无法运行EdgeHub与云端通信不应有问题EventBus依赖 Mosquitto 服务通过 MQTT 协议交互与操作系统无关MetaManager依赖 Sqlite不应有问题ServiceBus不依赖外部组件只需具备发送 HTTP 请求的能力Edgestream一个 WebSocket SecureWSS隧道只需连接到 CloudstreamTest一个测试 HTTP 服务器依赖 Edged 等组件。整体来看问题集中在 Edged 模块。在 kubelet 中Linux 与 Windows 的配置文件存在差异主要体现在 CRI 地址和资源隔离工具上。解决方案向 Edged 补齐 Kubelet 的 Windows 配置Edged 是 kubelet 的裁剪版本。Kubernetes 本身支持以 Windows 作为节点甚至在 1.27 版本中增加了对 Windows Server 2019 的支持这意味着 Kubelet 可以在 Windows 侧运行因此 Edged 理论上也应该可以。下图描述了目标架构Windows Server 边缘节点上基于进程隔离运行 EdgeCore通过 CloudHub/EdgeHub 通道与云端的 CloudCoreEdge Controller、Device Controller及 K8s API Server 通信EdgeCore 内部的 Edged 通过 CRI 与容器运行时交互EventBus 与本地 MQTT Broker 通信对比 Edged 与 Kubelet 的代码后发现Edged 没有考虑到 Kubelet 中与 Windows 支持相关的配置实际上 Kubelet 中存在这些字段只是在传递给 Kubelet 的过程中被忽略了。具体来说Edged 的 KubeletFlags 结构体中缺少WindowsService和WindowsPriorityClass两个字段。因此理论上只要修改 Edged 代码、补充对 Windows 配置的支持再交给k8s.io/kubernetes/cmd/kubelet/app完成其余工作就可以运行 Edged。下图展示了从 KubeEdge 的TailoredKubeletFlag转换到 KubernetesKubeletFlags的代码红色高亮即为新增的WindowsService与WindowsPriorityClass字段需要说明的是这只是一个理论方案。实际实现中可能涉及更多细节和依赖实现过程中需要深入阅读 Kubelet 与 Edged 的代码确保对其整体架构和实现有充分理解同时必须对修改后的 Edged 代码进行测试和验证确保在实际环境中的稳定性和正确性。源码验证Windows 配置字段已落地从当前仓库源码看这一提案中的关键字段与转换逻辑已经得到实现1. 配置结构体字段定义在 staging/src/github.com/kubeedge/api/apis/componentconfig/edgecore/v1alpha2/types.go 中TailoredKubeletFlag结构体定义了WindowsService bool当 kubelet 作为 Windows 服务运行时应设为 true该标志仅在 Windows 构建中注册WindowsPriorityClass string设置与 Kubelet 进程关联的优先级类该标志仅在 Windows 构建中注册。Windows 中与任何进程关联的默认优先级类是NORMAL_PRIORITY_CLASS为保持向后兼容而保留此默认值。2. 按平台区分的默认值default_windows.go//go:build windowsDefaultWindowsService true、DefaultWindowsPriorityClass NORMAL_PRIORITY_CLASS数据库路径为C:\var\lib\kubeedge\edgecore.db默认 CgroupDriver 为空default_others.go//go:build !windowsDefaultWindowsService false、DefaultWindowsPriorityClass 数据库路径为/var/lib/kubeedge/edgecore.db。这种构建标签 平台默认值的做法正是 Windows 与 Linux 差异CRI 地址、资源隔离工具等在配置层面的体现。3. 字段转换逻辑在 edge/pkg/edged/config/config.go 的ConvertConfigEdgedFlagToConfigKubeletFlag函数中WindowsPriorityClass与WindowsService被从 KubeEdge 配置显式映射到kubeletoptions.KubeletFlags同时完成RuntimeCgroups、PodSandboxImage等容器运行时特定选项的转换。4. Windows 专属构建文件仓库中还存在多个仅针对 Windows 构建的文件如 edge/cmd/edgecore/app/init_windows.go、edge/cmd/edgecore/app/options/options_windows.go、edge/pkg/common/util/network_windows.go进一步印证了 Windows 支持已进入工程实现层面。设计细节分阶段实施任务以下任务清单来自提案是完整落地 Windows 边缘节点支持的分步方案Task 1在 Windows Server 上运行 Containerd准备硬件环境Windows Server 2019。也可以是 Windows 10 或 Windows 11但必须是专业版/企业版并启用 Hyper-V。由于 Kubernetes 官方文档目前推荐 Windows Server因此将 Windows Server 2019 作为首选准备容器运行时在 Windows 操作系统上安装容器运行时 containerd测试容器运行时验证 containerd 运行正常并启动任意 Hello-world 容器如 nginx。Task 2搭建 CloudCore 环境为便于调试并获得完整环境在另一台服务器上部署云端节点安装 Kubernetes使用 Kubeadm 部署单节点集群安装 CloudCore使用 Keadm 在装有 Kubernetes 的机器上部署 CloudCore并妥善保存 token。Task 3在 Windows Server 上运行 EdgeCore 核心组件修改 Edged 源码使其支持与 Windows 相关的容器运行时配置并修改相关的传输代码编译为二进制文件测试 Edged 组件的运行。Task 4集成测试启用所有边缘节点组件测试云到边的通信是否正常工作使用 Kubernetes 将服务调度到边缘节点运行边缘应用以测试其可用性。Task 5更新 Keadm 代码以支持 Windows Server修改 Keadm 的部分代码支持在 Windows Server 上一键启动边缘节点。Task 6更新 GitHub Action 发布 Windows 版本keadm、edgecore修改发布脚本支持 Windows 平台的 release 产物。Task 7进一步支持尝试使用 Windows Server 2022探索 KubeEdge 在 Windows 生态中更多的可能性。Roadmap提案时间规划提案给出了明确的里程碑式时间规划可作为实施参考7.1-7.31 准备阶段评审并提交提案部署 KubeEdge 服务搭建一主一从集群一个 master 一个 Linux 边缘节点以熟悉 KubeEdge 操作熟悉 Edged 源码准备 Windows Server 2019 资源并搭建远程开发与调试环境8.1-8.31 开发阶段在 Windows Server 上开发并修改 KubeEdge 代码使 Edged 成功运行调试云到边通信确保 Windows 节点顺利接入集群开发 Keadm支持在 Windows 节点上启动 KubeEdge9.1-9.11 代码清理整理和优化代码、补充必要注释、删除调试代码9.11-9.30 总结阶段确保 EdgeCore 在 Windows Server 2019 上平稳运行编写项目文档、演示材料并提交代码。总结与展望将 KubeEdge 边缘节点迁移到 Windows Server 的核心路径可以概括为三点问题定位EdgeCore 各模块中EventBus依赖 Mosquitto、Edged依赖 CRI 与 Cgroups是最可能出问题的环节其中 Edged 是核心难点改造思路Kubelet 本身支持 WindowsEdged 作为其裁剪版本只需补齐WindowsService与WindowsPriorityClass等 Windows 配置字段再交由 kubelet 相关代码完成剩余工作。该改造在当前仓库源码中已落地从配置默认值按平台构建标签区分到字段转换逻辑edge/pkg/edged/config/config.go均有完整实现实施验证遵循containerd on Windows → CloudCore 环境 → Edged 改造 → 集成测试 → Keadm 一键启动 → 发布脚本 → Windows Server 2022 扩展的分阶段任务逐步验证并沉淀为可复用的边缘节点接入能力。随着 Windows 容器生态的成熟与 Keadm 一键部署能力的完善KubeEdge 有望进一步覆盖企业级 Windows 基础设施为物联网与工业边缘场景提供更广泛的落地选择。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 0:45:00 · 阅读 1.2k KubeEdge 边缘节点 Windows 支持：EdgeCore 移植方案与实现解析
KubeEdge 边缘节点 Windows 支持EdgeCore 移植方案与实现解析【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge导读本文基于 KubeEdge 官方提案docs/proposals/sig-node/edge-on-windows.md系统讲解如何在 Windows Server 上运行 KubeEdge 边缘节点。文章首先剖析 EdgeCore 各模块对操作系统能力的依赖指出问题核心在 Edged随后给出完整的改造思路通过补齐 Kubelet Windows 相关配置字段、使 containerd 在 Windows 上运行、配合 CloudCore 与 Keadm 完成一整套可落地的实施任务清单。读完本文你将掌握 KubeEdge 从 Linux 扩展至 Windows 生态的技术原理、代码改造点WindowsService与WindowsPriorityClass以及分阶段验证方案。背景为什么需要 Windows 边缘节点KubeEdge 将 Kubernetes 的容器化编排能力延伸到边缘主机基于 Kubernetes 构建为云与边缘之间提供网络、应用部署和元数据同步等基础能力已在工业边缘计算场景中被广泛采用。尽管 KubeEdge 已支持 Linux、Android 等操作系统并拥有大量成功案例但它目前不支持 Windows Server这限制了它在部分潜在边缘计算场景中的能力。边缘计算涉及传感器、摄像头、工业控制设备等多种设备其中一些可能运行 Windows 操作系统同时许多企业的 IT 基础设施中部署了 Windows 服务器并已运行部分应用和服务。要让边缘计算与既有基础设施融合、推动边缘计算生态发展KubeEdge 就必须能在 Windows Server 节点上运行。从技术可行性上看当前 KubeEdge 的云端节点可以以 Kubernetes Pod 方式运行而边缘侧节点需要在支持 Docker、containerd 等容器技术的系统上运行无需运行 Kubernetes。微软已经提供了基于**进程隔离Process Isolation**和Hyper-V 隔离的容器化方案两者都能成功运行 containerd这为 KubeEdge 在 Windows 上运行创造了条件。目标本项目旨在让 KubeEdge 的边缘节点运行在 Windows Server 上从而将 KubeEdge 扩展到 Windows 生态系统扩大其在物联网领域的用例与生态。现状分析EdgeCore 为什么无法在 Windows 上运行KubeEdge 是一个在边缘计算节点上运行本地化 Kubernetes 集群的开源系统。它由 Cloud 与 Edge 两大部分组成Cloud 组件运行在云服务器的 Kubernetes 环境中Edge 组件运行在边缘设备上。两者都必须在受支持的操作系统上运行。CloudCore云端组件CloudCore 是运行在云端的核心组件负责管理边缘节点与应用并与边缘节点通信包含以下模块CloudHub负责与 EdgeHub 建立 WebSocket 连接并转发来自边缘节点的消息EdgeController负责将云端的资源状态节点、Pod、ConfigMap、Secret 等同步到边缘节点DeviceController负责管理边缘设备的生命周期并同步设备状态与设备模型。EdgeCore边缘侧核心组件EdgeCore 是运行在边缘节点上的核心组件负责运行容器与设备、与云端通信包含以下重要模块DeviceTwin负责存储边缘设备的状态与属性并与 DeviceController 同步Edged负责管理边缘节点上的容器包括创建、启动、停止、删除等操作功能与 kubelet 类似但更轻量EdgeHub负责与 CloudHub 建立 WebSocket 连接并转发来自云端的消息EventBus负责与 MQTT 服务器通信提供发布/订阅pub/sub能力MetaManager负责管理边缘节点上的元数据包括 Pod、ConfigMap、Secret 等ServiceBus一个 HTTP 客户端与 HTTP 服务器REST交互为云组件访问边缘侧 HTTP 服务器提供 HTTP 客户端功能。这些模块由 EdgeCore 启动时统一注册。下图展示了registerModules函数见 edge/cmd/edgecore/app/server.go如何按顺序注册上述核心模块主要难点Edged 模块在 Windows 上运行边缘节点的最大挑战在于运行 EdgeCore。EdgeCore 的六个组件以 Goroutine 方式运行但即便如此它们仍依赖其他外部组件。例如 EventBus 依赖外部 Mosquitto 服务器——如果 Mosquitto 不支持在 Windows 上运行则启用 EventBus 的 EdgeCore 就无法运行。要让 EdgeCore 在 Windows 上运行需要先分析其无法运行的原因并逐一解决。首先可以尝试编译 Windows 版本的 EdgeCore——它能启动但会因内部错误退出。逐模块分析如下DeviceTwin依赖 SqliteSqlite 不应因系统差异出现问题Edged它是 kubelet 的轻量版本需要与系统中的 CRI 和 RuntimeCgroups 交互。如果系统中没有容器运行时和相关的 Cgroups该模块将无法运行EdgeHub与云端通信不应有问题EventBus依赖 Mosquitto 服务通过 MQTT 协议交互与操作系统无关MetaManager依赖 Sqlite不应有问题ServiceBus不依赖外部组件只需具备发送 HTTP 请求的能力Edgestream一个 WebSocket SecureWSS隧道只需连接到 CloudstreamTest一个测试 HTTP 服务器依赖 Edged 等组件。整体来看问题集中在 Edged 模块。在 kubelet 中Linux 与 Windows 的配置文件存在差异主要体现在 CRI 地址和资源隔离工具上。解决方案向 Edged 补齐 Kubelet 的 Windows 配置Edged 是 kubelet 的裁剪版本。Kubernetes 本身支持以 Windows 作为节点甚至在 1.27 版本中增加了对 Windows Server 2019 的支持这意味着 Kubelet 可以在 Windows 侧运行因此 Edged 理论上也应该可以。下图描述了目标架构Windows Server 边缘节点上基于进程隔离运行 EdgeCore通过 CloudHub/EdgeHub 通道与云端的 CloudCoreEdge Controller、Device Controller及 K8s API Server 通信EdgeCore 内部的 Edged 通过 CRI 与容器运行时交互EventBus 与本地 MQTT Broker 通信对比 Edged 与 Kubelet 的代码后发现Edged 没有考虑到 Kubelet 中与 Windows 支持相关的配置实际上 Kubelet 中存在这些字段只是在传递给 Kubelet 的过程中被忽略了。具体来说Edged 的 KubeletFlags 结构体中缺少WindowsService和WindowsPriorityClass两个字段。因此理论上只要修改 Edged 代码、补充对 Windows 配置的支持再交给k8s.io/kubernetes/cmd/kubelet/app完成其余工作就可以运行 Edged。下图展示了从 KubeEdge 的TailoredKubeletFlag转换到 KubernetesKubeletFlags的代码红色高亮即为新增的WindowsService与WindowsPriorityClass字段需要说明的是这只是一个理论方案。实际实现中可能涉及更多细节和依赖实现过程中需要深入阅读 Kubelet 与 Edged 的代码确保对其整体架构和实现有充分理解同时必须对修改后的 Edged 代码进行测试和验证确保在实际环境中的稳定性和正确性。源码验证Windows 配置字段已落地从当前仓库源码看这一提案中的关键字段与转换逻辑已经得到实现1. 配置结构体字段定义在 staging/src/github.com/kubeedge/api/apis/componentconfig/edgecore/v1alpha2/types.go 中TailoredKubeletFlag结构体定义了WindowsService bool当 kubelet 作为 Windows 服务运行时应设为 true该标志仅在 Windows 构建中注册WindowsPriorityClass string设置与 Kubelet 进程关联的优先级类该标志仅在 Windows 构建中注册。Windows 中与任何进程关联的默认优先级类是NORMAL_PRIORITY_CLASS为保持向后兼容而保留此默认值。2. 按平台区分的默认值default_windows.go//go:build windowsDefaultWindowsService true、DefaultWindowsPriorityClass NORMAL_PRIORITY_CLASS数据库路径为C:\var\lib\kubeedge\edgecore.db默认 CgroupDriver 为空default_others.go//go:build !windowsDefaultWindowsService false、DefaultWindowsPriorityClass 数据库路径为/var/lib/kubeedge/edgecore.db。这种构建标签 平台默认值的做法正是 Windows 与 Linux 差异CRI 地址、资源隔离工具等在配置层面的体现。3. 字段转换逻辑在 edge/pkg/edged/config/config.go 的ConvertConfigEdgedFlagToConfigKubeletFlag函数中WindowsPriorityClass与WindowsService被从 KubeEdge 配置显式映射到kubeletoptions.KubeletFlags同时完成RuntimeCgroups、PodSandboxImage等容器运行时特定选项的转换。4. Windows 专属构建文件仓库中还存在多个仅针对 Windows 构建的文件如 edge/cmd/edgecore/app/init_windows.go、edge/cmd/edgecore/app/options/options_windows.go、edge/pkg/common/util/network_windows.go进一步印证了 Windows 支持已进入工程实现层面。设计细节分阶段实施任务以下任务清单来自提案是完整落地 Windows 边缘节点支持的分步方案Task 1在 Windows Server 上运行 Containerd准备硬件环境Windows Server 2019。也可以是 Windows 10 或 Windows 11但必须是专业版/企业版并启用 Hyper-V。由于 Kubernetes 官方文档目前推荐 Windows Server因此将 Windows Server 2019 作为首选准备容器运行时在 Windows 操作系统上安装容器运行时 containerd测试容器运行时验证 containerd 运行正常并启动任意 Hello-world 容器如 nginx。Task 2搭建 CloudCore 环境为便于调试并获得完整环境在另一台服务器上部署云端节点安装 Kubernetes使用 Kubeadm 部署单节点集群安装 CloudCore使用 Keadm 在装有 Kubernetes 的机器上部署 CloudCore并妥善保存 token。Task 3在 Windows Server 上运行 EdgeCore 核心组件修改 Edged 源码使其支持与 Windows 相关的容器运行时配置并修改相关的传输代码编译为二进制文件测试 Edged 组件的运行。Task 4集成测试启用所有边缘节点组件测试云到边的通信是否正常工作使用 Kubernetes 将服务调度到边缘节点运行边缘应用以测试其可用性。Task 5更新 Keadm 代码以支持 Windows Server修改 Keadm 的部分代码支持在 Windows Server 上一键启动边缘节点。Task 6更新 GitHub Action 发布 Windows 版本keadm、edgecore修改发布脚本支持 Windows 平台的 release 产物。Task 7进一步支持尝试使用 Windows Server 2022探索 KubeEdge 在 Windows 生态中更多的可能性。Roadmap提案时间规划提案给出了明确的里程碑式时间规划可作为实施参考7.1-7.31 准备阶段评审并提交提案部署 KubeEdge 服务搭建一主一从集群一个 master 一个 Linux 边缘节点以熟悉 KubeEdge 操作熟悉 Edged 源码准备 Windows Server 2019 资源并搭建远程开发与调试环境8.1-8.31 开发阶段在 Windows Server 上开发并修改 KubeEdge 代码使 Edged 成功运行调试云到边通信确保 Windows 节点顺利接入集群开发 Keadm支持在 Windows 节点上启动 KubeEdge9.1-9.11 代码清理整理和优化代码、补充必要注释、删除调试代码9.11-9.30 总结阶段确保 EdgeCore 在 Windows Server 2019 上平稳运行编写项目文档、演示材料并提交代码。总结与展望将 KubeEdge 边缘节点迁移到 Windows Server 的核心路径可以概括为三点问题定位EdgeCore 各模块中EventBus依赖 Mosquitto、Edged依赖 CRI 与 Cgroups是最可能出问题的环节其中 Edged 是核心难点改造思路Kubelet 本身支持 WindowsEdged 作为其裁剪版本只需补齐WindowsService与WindowsPriorityClass等 Windows 配置字段再交由 kubelet 相关代码完成剩余工作。该改造在当前仓库源码中已落地从配置默认值按平台构建标签区分到字段转换逻辑edge/pkg/edged/config/config.go均有完整实现实施验证遵循containerd on Windows → CloudCore 环境 → Edged 改造 → 集成测试 → Keadm 一键启动 → 发布脚本 → Windows Server 2022 扩展的分阶段任务逐步验证并沉淀为可复用的边缘节点接入能力。随着 Windows 容器生态的成熟与 Keadm 一键部署能力的完善KubeEdge 有望进一步覆盖企业级 Windows 基础设施为物联网与工业边缘场景提供更广泛的落地选择。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考