尧图网站建设 
KubeEdge RPM 打包指南从 rpmbuild 工作流到四个子包的构建原理剖析【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge本文基于 KubeEdge 仓库中的 RPM 打包指南 展开系统讲解如何为 KubeEdge 构建 RPM 软件包从环境准备、rpmdev-setuptree/rpmbuild的完整编译流程到kubeedge-cloudcore、kubeedge-edgecore、kubeedge-edgesite、kubeedge-keadm四个子包各自提供的内容与适用场景。读完后你将能够独立完成 KubeEdge 的 RPM 编译、安装并理解 kubeedge.spec 中构建脚本的每一步在做什么。一、为什么要用 RPM 打包 KubeEdge从源码编译安装 KubeEdge 需要开发者自行处理 Go 依赖、编译各组件二进制再手动拷贝配置文件与 systemd 单元文件。相比之下RPM 包将二进制、配置文件样例、systemd 服务单元、CRD 清单、证书工具等一次性打包配合yum等包管理器即可实现便捷的编译、安装与卸载对 Fedora、CentOS、openEuler 等发行版的运维场景更加友好。参考本仓库同时提供中文版指南内容一致可对照阅读。二、构建环境准备编译 KubeEdge RPM 包需要满足以下四个前提条件引自 README.md 的 Preparation 一节使用yum作为包管理器的 Linux 发行版如 Fedora、CentOS、openEulerKubeEdge 的 release 源码包例如v1.8.0对应的 release tarball该 spec 文件的Source0即声明从源码标签归档获取见 kubeedge.spec#L16安装rpmbuild与rpmdev-setuptree命令yum install rpmbuild rpmdevtoolskubeedge.spec文件位于 build/rpm/kubeedge.spec。此外从 spec 文件的头部声明还能确认两个隐含的构建约束%ifarch x86_64 %global gohostarch amd64 %endif %ifarch aarch64 %global gohostarch arm64 %endif即该 spec 同时支持x86_64与aarch64架构并将 Go 的宿主架构名映射为amd64/arm64。同时构建与运行依赖也在 spec 中显式声明kubeedge.spec#L17-L18BuildRequires: golang glibc-static make tar systemd git—— 构建期依赖其中glibc-static用于静态链接、git用于在构建时打 tag源码 tarball 不含 git 信息Requires: mosquitto—— 运行期依赖安装 RPM 包前系统需已具备 mosquittoKubeEdge 的 MQTT 通信依赖。三、编译 RPM 包rpmbuild 工作流完整的编译流程共四步对应 README.md 的 Compilation 一节1. 用rpmdev-setuptree创建工作目录rpmdev-setuptree执行后会在用户家目录下生成标准 RPM 构建目录树/root/rpmbuild/ ├── BUILD # 源码解压与编译工作区 ├── RPMS # 构建完成的二进制 RPM 输出 ├── SOURCES # 存放源码 tarball ├── SPECS # 存放 spec 文件 └── SRPMS # 源码包SRPM输出2. 放置源码包与 spec 文件将 KubeEdge 源码 tarball如v1.8.0.tar.gz放入/root/rpmbuild/SOURCES将 build/rpm/kubeedge.spec 复制到/root/rpmbuild/SPECS。3. 执行rpmbuild构建rpmbuild -ba /root/rpmbuild/SPECS/kubeedge.spec-ba表示同时构建二进制包-b与源码包-a即--buildsrpm。构建成功后产物会出现在RPMS目录中。3.1 深入 specrpmbuild 到底做了什么rpmbuild会依次执行 spec 中的%prep、%build、%install段。结合 kubeedge.spec 的源码可以梳理出完整的内部流程1%prep 阶段 —— 解压源码%prep %autosetup -Sgit -n %{name}-%{version} -p1将 SOURCES 中的源码 tarball 解压到 BUILD 目录。2%build 阶段 —— 编译全部二进制%build # add git tag since tarball did not contain any git info git tag -a v%{version} -m %{version} # setup GOPATH export GOPATH%{_builddir} ... export GOLDFLAGS-buildidnone -buildmodepie -extldflags-ftrapv -extldflags-zrelro -extldflags-znow -linkmodeexternal -extldflags-static # build binaries make all # build csidriver go build -v -o _output/local/bin/csidriver -ldflags${GOLDFLAGS} github.com/kubeedge/kubeedge/cloud/cmd/csidriver见 kubeedge.spec#L70-L86要点因为 release tarball 不含 git 元信息需要先git tag -a vversion否则基于 go module 的构建会因缺少版本信息而失败通过符号链接把源码放入GOPATH/src/github.com/kubeedge/kubeedge的规范位置统一使用-static等GOLDFLAGS参数含-buildmodepie、-zrelro -znow产出静态链接的二进制降低对目标机 glibc 的依赖先执行make all构建 keadm、cloudcore、edgecore、admission、edgesite-agent/server 等主二进制再单独补建csidriverspec 中注明该补建是过渡性处理对应 cloud/cmd/csidriver 入口注意 spec 顶部%define debug_package %{nil}关闭了 debuginfo 包生成减小产物体积。3%install 阶段 —— 组织安装布局这一段是 spec 的核心kubeedge.spec#L88-L132完成了四件事安装全部二进制到/usr/local/bin/keadm、cloudcore、edgecore、admission、csidriver、edgesite-agent、edgesite-server权限0755自动生成配置样例直接调用刚编译出的二进制导出默认配置保证样例与当前版本严格一致./_output/local/bin/cloudcore --defaultconfig cloudcore.example.yaml ./_output/local/bin/edgecore --defaultconfig edgecore.example.yaml安装到/etc/kubeedge/config/下。--defaultconfig的实现在云端入口 server.go 中通过PrintDefaultConfigAndExitIfRequested(v1alpha1.NewDefaultCloudCoreConfig())打印默认配置后退出安装 systemd 单元与工具cloudcore.service、edgecore.service既安装到系统 unit 目录%{_unitdir}即/usr/lib/systemd/system也复制一份到/etc/kubeedge/下——后者是为 keadm 准备的使 keadm 部署集群时无需联网下载服务文件spec 第 111 行注释明确说明了这一意图同时安装 certgen.sh 证书生成工具到/etc/kubeedge/tools/并把build/crds/下的全部 CRD 清单安装到/etc/kubeedge/crds/构造 keadm 专用 tarball 并计算校验和%global tarball_name %{name}-v%{version}-linux-%{gohostarch} install -Dpm0755 ./_output/local/bin/cloudcore %{tarball_name}/cloud/cloudcore/cloudcore ... tar zcf %{tarball_name}.tar.gz %{tarball_name} sha512sum %{tarball_name}.tar.gz | awk {print $1} checksum_%{tarball_name}.tar.gz.txt即按cloud/cloudcore、cloud/admission、cloud/csidriver、edge/edgecore、crds的目录约定打包二进制与 CRD写入version文件再产出 SHA-512 校验和文件——这正是 keadm 在目标机上分发、校验安装包的来源。4systemd 单元文件内容RPM 携带的两个服务单元定义非常简洁以 cloudcore.service 为例[Unit] Descriptioncloudcore.service [Service] Typesimple ExecStart/usr/local/bin/cloudcore Restartalways RestartSec10 [Install] WantedBymulti-user.targetedgecore.service 结构相同仅ExecStart指向/usr/local/bin/edgecore。RestartalwaysRestartSec10意味着进程异常退出后 10 秒自动拉起WantedBymulti-user.target表示随多用户系统启动而自启。5%files 段 —— 四个子包的文件清单spec 通过%package声明了keadm、cloudcore、edgecore、edgesite四个子包kubeedge.spec#L26-L65每个子包还通过Provides:声明了二进制名称级的版本化依赖如Provides: cloudcore %{version}便于其他 RPM 以二进制名为 key 声明依赖。%files段kubeedge.spec#L134-L161中两份配置样例均使用%config(noreplace)标记意味着升级 RPM 时若用户已修改过配置文件系统不会用新包覆盖而是保留旧文件并生成.rpmsave备份。四、编译产物与安装编译结束后RPM 包出现在RPMS目录x86_64 架构下/root/rpmbuild/RPMS/ └── x86_64 ├── kubeedge-cloudcore-1.8.0-1.x86_64.rpm ├── kubeedge-edgecore-1.8.0-1.x86_64.rpm ├── kubeedge-edgesite-1.8.0-1.x86_64.rpm └── kubeedge-keadm-1.8.0-1.x86_64.rpm安装对应组件rpm -ivh kubeedge-cloudcore-1.8.0-1.x86_64.rpm五、四个子包分别提供什么kubeedge-cloudcore云端组件包含云端侧所需的全部资源对应 README.md 的 Note 一节及 spec%files cloudcore段cloudcore、admission、csidriver三个二进制安装于/usr/local/bin/cloudcore.servicesystemd 单元文件同时存在于/etc/kubeedge/供 keadm 使用crdsKubernetes CRD 清单来源于 build/crds/ 目录含 devices、reliablesyncs、router 等资源的 yamlcertgen.sh证书生成工具安装于/etc/kubeedge/tools/cloudcore.example.yamlcloudcore 配置样例安装于/etc/kubeedge/config/由编译出的二进制经--defaultconfig现场导出。kubeedge-edgecore边缘端组件edgecore二进制edgecore.servicesystemd 单元文件edgecore.example.yamledgecore 配置样例/etc/kubeedge/config/。kubeedge-edgesitegRPC 代理组件edgesite-agentgRPC agent连接代理后允许流量转发edgesite-servergRPC 代理服务端接收 API server 请求并转发到 agent。kubeedge-keadm集群部署工具一站式keadm二进制cloudcore.service、edgecore.service两份 systemd 单元文件位于/etc/kubeedge/下供 keadm 直接取用无需联网kubeedge-v{version}-linux-{arch}.tar.gzkeadm 安装所需的全部文件内部结构为kubeedge-v1.8.0-linux-amd64 ├── cloud │ ├── admission │ │ └── admission │ ├── cloudcore │ │ └── cloudcore │ └── csidriver │ └── csidriver ├── crds │ ├── devices │ │ ├── devices_v1alpha1_devicemodel.yaml │ │ ├── devices_v1alpha1_device.yaml │ │ ├── devices_v1alpha2_devicemodel.yaml │ │ └── devices_v1alpha2_device.yaml │ ├── reliablesyncs │ │ ├── cluster_objectsync_v1alpha1.yaml │ │ └── objectsync_v1alpha1.yaml │ └── router │ ├── router_v1_ruleEndpoint.yaml │ └── router_v1_rule.yaml ├── edge │ └── edgecore └── versionchecksum_kubeedge-v{version}-linux-{arch}.tar.gz上述 tarball 的 SHA-512 校验和文件供 keadm 在目标机上验证包完整性。注意README 中 tarball 树以 v1.8.0 版本 CRD 为例当前仓库 build/crds/ 目录已包含更多 CRD如devices_v1beta1_*、operations 系列的 nodeupgradejob/imageprepulljob/configupdatejob 等以你所构建版本 spec 中Version字段对应的 release 源码为准。六、按部署方式选择要安装的包RPM 指南的 Additional 一节给出了两条选型建议与 KubeEdge 的两种部署方式直接对应keadm 方式部署只需安装kubeedge-keadm一个包即可。因为该包已经内嵌了 keadm 所需的全部二进制、CRD、systemd 单元与校验和keadm 会自动完成云端与边缘端的组件分发二进制方式部署需要在云端主机安装kubeedge-cloudcore包、在边缘节点安装kubeedge-edgecore包二者各自独立kubeedge-edgesite包则按需用于启用 edgesite gRPC 代理能力。安装后可用rpm -ql kubeedge-cloudcore类命令核对上述文件清单并通过systemctl status cloudcore检查由 cloudcore.service 拉起的服务状态。七、适用前提与注意事项版本锁定当前 spec 中Version: 1.8.0kubeedge.spec#L11构建出的包即为1.8.0-1构建其他版本需同步修改Version字段及对应 release tarball架构spec 仅处理x86_64→amd64、aarch64→arm64两种映射其他架构不在支持范围内运行期依赖RPM 声明Requires: mosquittoyum/rpm 安装时会检查依赖满足情况配置文件目录安装后配置位于/etc/kubeedge/config/这与源码中默认配置目录常量一致见 default_others.go 中的DefaultConfigDir /etc/kubeedge/config/Windows 下为C:\etc\kubeedge\config\修改配置时以*.example.yaml为模板复制为正式配置即可升级行为由于配置样例声明为%config(noreplace)跨版本升级时本地已修改的配置文件不会被覆盖需要人工比对新版本的默认配置差异。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KubeEdge RPM 打包指南：从 rpmbuild 工作流到四个子包的构建原理剖析
KubeEdge RPM 打包指南从 rpmbuild 工作流到四个子包的构建原理剖析【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge本文基于 KubeEdge 仓库中的 RPM 打包指南 展开系统讲解如何为 KubeEdge 构建 RPM 软件包从环境准备、rpmdev-setuptree/rpmbuild的完整编译流程到kubeedge-cloudcore、kubeedge-edgecore、kubeedge-edgesite、kubeedge-keadm四个子包各自提供的内容与适用场景。读完后你将能够独立完成 KubeEdge 的 RPM 编译、安装并理解 kubeedge.spec 中构建脚本的每一步在做什么。一、为什么要用 RPM 打包 KubeEdge从源码编译安装 KubeEdge 需要开发者自行处理 Go 依赖、编译各组件二进制再手动拷贝配置文件与 systemd 单元文件。相比之下RPM 包将二进制、配置文件样例、systemd 服务单元、CRD 清单、证书工具等一次性打包配合yum等包管理器即可实现便捷的编译、安装与卸载对 Fedora、CentOS、openEuler 等发行版的运维场景更加友好。参考本仓库同时提供中文版指南内容一致可对照阅读。二、构建环境准备编译 KubeEdge RPM 包需要满足以下四个前提条件引自 README.md 的 Preparation 一节使用yum作为包管理器的 Linux 发行版如 Fedora、CentOS、openEulerKubeEdge 的 release 源码包例如v1.8.0对应的 release tarball该 spec 文件的Source0即声明从源码标签归档获取见 kubeedge.spec#L16安装rpmbuild与rpmdev-setuptree命令yum install rpmbuild rpmdevtoolskubeedge.spec文件位于 build/rpm/kubeedge.spec。此外从 spec 文件的头部声明还能确认两个隐含的构建约束%ifarch x86_64 %global gohostarch amd64 %endif %ifarch aarch64 %global gohostarch arm64 %endif即该 spec 同时支持x86_64与aarch64架构并将 Go 的宿主架构名映射为amd64/arm64。同时构建与运行依赖也在 spec 中显式声明kubeedge.spec#L17-L18BuildRequires: golang glibc-static make tar systemd git—— 构建期依赖其中glibc-static用于静态链接、git用于在构建时打 tag源码 tarball 不含 git 信息Requires: mosquitto—— 运行期依赖安装 RPM 包前系统需已具备 mosquittoKubeEdge 的 MQTT 通信依赖。三、编译 RPM 包rpmbuild 工作流完整的编译流程共四步对应 README.md 的 Compilation 一节1. 用rpmdev-setuptree创建工作目录rpmdev-setuptree执行后会在用户家目录下生成标准 RPM 构建目录树/root/rpmbuild/ ├── BUILD # 源码解压与编译工作区 ├── RPMS # 构建完成的二进制 RPM 输出 ├── SOURCES # 存放源码 tarball ├── SPECS # 存放 spec 文件 └── SRPMS # 源码包SRPM输出2. 放置源码包与 spec 文件将 KubeEdge 源码 tarball如v1.8.0.tar.gz放入/root/rpmbuild/SOURCES将 build/rpm/kubeedge.spec 复制到/root/rpmbuild/SPECS。3. 执行rpmbuild构建rpmbuild -ba /root/rpmbuild/SPECS/kubeedge.spec-ba表示同时构建二进制包-b与源码包-a即--buildsrpm。构建成功后产物会出现在RPMS目录中。3.1 深入 specrpmbuild 到底做了什么rpmbuild会依次执行 spec 中的%prep、%build、%install段。结合 kubeedge.spec 的源码可以梳理出完整的内部流程1%prep 阶段 —— 解压源码%prep %autosetup -Sgit -n %{name}-%{version} -p1将 SOURCES 中的源码 tarball 解压到 BUILD 目录。2%build 阶段 —— 编译全部二进制%build # add git tag since tarball did not contain any git info git tag -a v%{version} -m %{version} # setup GOPATH export GOPATH%{_builddir} ... export GOLDFLAGS-buildidnone -buildmodepie -extldflags-ftrapv -extldflags-zrelro -extldflags-znow -linkmodeexternal -extldflags-static # build binaries make all # build csidriver go build -v -o _output/local/bin/csidriver -ldflags${GOLDFLAGS} github.com/kubeedge/kubeedge/cloud/cmd/csidriver见 kubeedge.spec#L70-L86要点因为 release tarball 不含 git 元信息需要先git tag -a vversion否则基于 go module 的构建会因缺少版本信息而失败通过符号链接把源码放入GOPATH/src/github.com/kubeedge/kubeedge的规范位置统一使用-static等GOLDFLAGS参数含-buildmodepie、-zrelro -znow产出静态链接的二进制降低对目标机 glibc 的依赖先执行make all构建 keadm、cloudcore、edgecore、admission、edgesite-agent/server 等主二进制再单独补建csidriverspec 中注明该补建是过渡性处理对应 cloud/cmd/csidriver 入口注意 spec 顶部%define debug_package %{nil}关闭了 debuginfo 包生成减小产物体积。3%install 阶段 —— 组织安装布局这一段是 spec 的核心kubeedge.spec#L88-L132完成了四件事安装全部二进制到/usr/local/bin/keadm、cloudcore、edgecore、admission、csidriver、edgesite-agent、edgesite-server权限0755自动生成配置样例直接调用刚编译出的二进制导出默认配置保证样例与当前版本严格一致./_output/local/bin/cloudcore --defaultconfig cloudcore.example.yaml ./_output/local/bin/edgecore --defaultconfig edgecore.example.yaml安装到/etc/kubeedge/config/下。--defaultconfig的实现在云端入口 server.go 中通过PrintDefaultConfigAndExitIfRequested(v1alpha1.NewDefaultCloudCoreConfig())打印默认配置后退出安装 systemd 单元与工具cloudcore.service、edgecore.service既安装到系统 unit 目录%{_unitdir}即/usr/lib/systemd/system也复制一份到/etc/kubeedge/下——后者是为 keadm 准备的使 keadm 部署集群时无需联网下载服务文件spec 第 111 行注释明确说明了这一意图同时安装 certgen.sh 证书生成工具到/etc/kubeedge/tools/并把build/crds/下的全部 CRD 清单安装到/etc/kubeedge/crds/构造 keadm 专用 tarball 并计算校验和%global tarball_name %{name}-v%{version}-linux-%{gohostarch} install -Dpm0755 ./_output/local/bin/cloudcore %{tarball_name}/cloud/cloudcore/cloudcore ... tar zcf %{tarball_name}.tar.gz %{tarball_name} sha512sum %{tarball_name}.tar.gz | awk {print $1} checksum_%{tarball_name}.tar.gz.txt即按cloud/cloudcore、cloud/admission、cloud/csidriver、edge/edgecore、crds的目录约定打包二进制与 CRD写入version文件再产出 SHA-512 校验和文件——这正是 keadm 在目标机上分发、校验安装包的来源。4systemd 单元文件内容RPM 携带的两个服务单元定义非常简洁以 cloudcore.service 为例[Unit] Descriptioncloudcore.service [Service] Typesimple ExecStart/usr/local/bin/cloudcore Restartalways RestartSec10 [Install] WantedBymulti-user.targetedgecore.service 结构相同仅ExecStart指向/usr/local/bin/edgecore。RestartalwaysRestartSec10意味着进程异常退出后 10 秒自动拉起WantedBymulti-user.target表示随多用户系统启动而自启。5%files 段 —— 四个子包的文件清单spec 通过%package声明了keadm、cloudcore、edgecore、edgesite四个子包kubeedge.spec#L26-L65每个子包还通过Provides:声明了二进制名称级的版本化依赖如Provides: cloudcore %{version}便于其他 RPM 以二进制名为 key 声明依赖。%files段kubeedge.spec#L134-L161中两份配置样例均使用%config(noreplace)标记意味着升级 RPM 时若用户已修改过配置文件系统不会用新包覆盖而是保留旧文件并生成.rpmsave备份。四、编译产物与安装编译结束后RPM 包出现在RPMS目录x86_64 架构下/root/rpmbuild/RPMS/ └── x86_64 ├── kubeedge-cloudcore-1.8.0-1.x86_64.rpm ├── kubeedge-edgecore-1.8.0-1.x86_64.rpm ├── kubeedge-edgesite-1.8.0-1.x86_64.rpm └── kubeedge-keadm-1.8.0-1.x86_64.rpm安装对应组件rpm -ivh kubeedge-cloudcore-1.8.0-1.x86_64.rpm五、四个子包分别提供什么kubeedge-cloudcore云端组件包含云端侧所需的全部资源对应 README.md 的 Note 一节及 spec%files cloudcore段cloudcore、admission、csidriver三个二进制安装于/usr/local/bin/cloudcore.servicesystemd 单元文件同时存在于/etc/kubeedge/供 keadm 使用crdsKubernetes CRD 清单来源于 build/crds/ 目录含 devices、reliablesyncs、router 等资源的 yamlcertgen.sh证书生成工具安装于/etc/kubeedge/tools/cloudcore.example.yamlcloudcore 配置样例安装于/etc/kubeedge/config/由编译出的二进制经--defaultconfig现场导出。kubeedge-edgecore边缘端组件edgecore二进制edgecore.servicesystemd 单元文件edgecore.example.yamledgecore 配置样例/etc/kubeedge/config/。kubeedge-edgesitegRPC 代理组件edgesite-agentgRPC agent连接代理后允许流量转发edgesite-servergRPC 代理服务端接收 API server 请求并转发到 agent。kubeedge-keadm集群部署工具一站式keadm二进制cloudcore.service、edgecore.service两份 systemd 单元文件位于/etc/kubeedge/下供 keadm 直接取用无需联网kubeedge-v{version}-linux-{arch}.tar.gzkeadm 安装所需的全部文件内部结构为kubeedge-v1.8.0-linux-amd64 ├── cloud │ ├── admission │ │ └── admission │ ├── cloudcore │ │ └── cloudcore │ └── csidriver │ └── csidriver ├── crds │ ├── devices │ │ ├── devices_v1alpha1_devicemodel.yaml │ │ ├── devices_v1alpha1_device.yaml │ │ ├── devices_v1alpha2_devicemodel.yaml │ │ └── devices_v1alpha2_device.yaml │ ├── reliablesyncs │ │ ├── cluster_objectsync_v1alpha1.yaml │ │ └── objectsync_v1alpha1.yaml │ └── router │ ├── router_v1_ruleEndpoint.yaml │ └── router_v1_rule.yaml ├── edge │ └── edgecore └── versionchecksum_kubeedge-v{version}-linux-{arch}.tar.gz上述 tarball 的 SHA-512 校验和文件供 keadm 在目标机上验证包完整性。注意README 中 tarball 树以 v1.8.0 版本 CRD 为例当前仓库 build/crds/ 目录已包含更多 CRD如devices_v1beta1_*、operations 系列的 nodeupgradejob/imageprepulljob/configupdatejob 等以你所构建版本 spec 中Version字段对应的 release 源码为准。六、按部署方式选择要安装的包RPM 指南的 Additional 一节给出了两条选型建议与 KubeEdge 的两种部署方式直接对应keadm 方式部署只需安装kubeedge-keadm一个包即可。因为该包已经内嵌了 keadm 所需的全部二进制、CRD、systemd 单元与校验和keadm 会自动完成云端与边缘端的组件分发二进制方式部署需要在云端主机安装kubeedge-cloudcore包、在边缘节点安装kubeedge-edgecore包二者各自独立kubeedge-edgesite包则按需用于启用 edgesite gRPC 代理能力。安装后可用rpm -ql kubeedge-cloudcore类命令核对上述文件清单并通过systemctl status cloudcore检查由 cloudcore.service 拉起的服务状态。七、适用前提与注意事项版本锁定当前 spec 中Version: 1.8.0kubeedge.spec#L11构建出的包即为1.8.0-1构建其他版本需同步修改Version字段及对应 release tarball架构spec 仅处理x86_64→amd64、aarch64→arm64两种映射其他架构不在支持范围内运行期依赖RPM 声明Requires: mosquittoyum/rpm 安装时会检查依赖满足情况配置文件目录安装后配置位于/etc/kubeedge/config/这与源码中默认配置目录常量一致见 default_others.go 中的DefaultConfigDir /etc/kubeedge/config/Windows 下为C:\etc\kubeedge\config\修改配置时以*.example.yaml为模板复制为正式配置即可升级行为由于配置样例声明为%config(noreplace)跨版本升级时本地已修改的配置文件不会被覆盖需要人工比对新版本的默认配置差异。【免费下载链接】kubeedgeKubernetes Native Edge Computing Framework (project under CNCF)项目地址: https://gitcode.com/GitHub_Trending/ku/kubeedge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考