Kubeedge 1.13.1 部署实践：CentOS 7.9 + K8s 1.22.17 + MetalLB 全流程

简介面向 Kubeedge 初学者的完整部署资源包聚焦 Centos7.9 系统上基于 kubeadm 搭建的 Kubernetes v1.22.17 集群安装 Kubeedge v1.13.1 并借助 MetalLB 负载均衡器实现组件对外访问。资源共 15 个文件压缩包约 474.64MB核心内容包括 7 个 yaml 配置清单涉及 calico、metallb-native、nginx-loadbalancer 及 IP 地址池等、6 个 tar 镜像文件如 metrics-server、coreedge、kubeedge 等、1 份 kubeedge 部署 md 文档以及 keadm-v1.13.1-linux-amd64.tar.gz 工具包各类型文件按部署流程归置便于对照操作。已有 242 人学习适合想要快速复现云边协同环境、理解 LoadBalancer 网络模式并完成 Kubeedge 边缘节点接入的运维或开发人员。通过该包可获得从环境准备、集群搭建到负载均衡器配置、测试实例验证的完整落地方案有效减少手动搜集组件和排错的时间。1. 从零打通 KubeedgeCentOS 7.9 K8s 1.22.17 Kubeedge 1.13.1 这套教程包能省掉你一周的试错先交代一下背景Kubeedge 是 CNCF 里把 Kubernetes 延伸到边缘计算场景的框架云端跑 CloudCore边缘节点跑 EdgeCore两边通过 WebSocket/QUIC 通信。听起来不算复杂真正动手装的时候才发现坑都在版本匹配和网络暴露上K8s 版本差一个小版本keadm init 就报证书错误CloudCore 的地址写错边缘节点永远连不上镜像拉取超时直接把部署卡死在第一步。这套资源就是冲这三个痛点来的——CentOS 7.9 上先用 kubeadm 搭 K8s 1.22.17再部署 Kubeedge 1.13.1最后用 MetalLB 做负载均衡器把 CloudCore 的通信端口稳定暴露出来。镜像文件、yaml 配置、keadm 工具包全部打好包适合已经能独立搭起 K8s 集群、但还没碰过边缘计算或者被 Kubeedge 连接问题卡住的运维和研发。2. 环境准备与 K8s 集群搭建版本匹配是第一步卡版本比卡命令更常见很多人一上来就急着跑 keadm init结果 Keblet 都没起来CloudCore 更是无从谈起。Kubeedge 对 K8s 版本有明确的兼容区间1.13.1 这个版本配 K8s 1.22.17 是验证过的组合。下面的步骤先把系统基础打好再搭集群最后解释为什么这么选版本。2.1 系统初始化swap、selinux、内核参数一个都不能少CentOS 7.9 装完第一件事不是装 docker而是先把系统参数捋顺。Kubeedge 边缘节点要跑容器K8s 的 kubelet 对 swap 和 selinux 有硬性要求这三条命令缺一不可# 关闭 swapkubelet 默认不允许 swap 超过阈值 swapoff -a sed -i s/.*swap.*/#/ /etc/fstab # selinux 设为 permissiveenforcing 状态会导致容器挂载目录被拒 setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config # 开启 bridge-nf-call-iptables否则 Pod 间通信会因 iptables 规则不生效而异常 cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sysctl --systemswapoff和sed改 fstab 是配套操作只执行前者重启后 swap 会回来kubelet 又会报错。net.ipv4.ip_forward 1经常会被人漏掉EdgeCore 里的 EdgeHub 模块转发流量时依赖它漏掉之后边缘节点与云端通信会间歇性失败表现成一种很难排查的玄学问题。2.2 kubeadm 部署 K8s 1.22.17从初始化到 Node 节点加入K8s 1.22.17 算是 1.22 系列比较稳的版本支持 containerd 和 Docker 运行时。这里以 containerd 为例因为 Kubeedge 的 EdgeCore 默认 runtime 类型就是 containerd保持统一能少改一个配置# 安装 kubeadm、kubelet、kubectl版本锁在 1.22.17 cat /etc/yum.repos.d/kubernetes.repo EOF [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/ enabled1 gpgcheck0 EOF yum install -y kubeadm-1.22.17 kubelet-1.22.17 kubectl-1.22.17 systemctl enable --now kubelet # 初始化 Master 节点Pod 网段必须和 Calico 保持一致 kubeadm init \ --apiserver-advertise-address192.168.20.11 \ --pod-network-cidr10.244.0.0/16 \ --kubernetes-versionv1.22.17 \ --image-repositoryregistry.cn-hangzhou.aliyuncs.com/google_containers初始化时指定阿里云镜像仓库是必要操作默认的k8s.gcr.io在国内环境会直接拉超时。--pod-network-cidr10.244.0.0/16是 Calico 的默认网段后面部署网络插件时不用改配置。--apiserver-advertise-address是 Master 的内网 IP别填公网 IP否则 kubelet 探测 apiserver 时会走不通。初始化完成后按输出提示执行export KUBECONFIG/etc/kubernetes/admin.conf然后部署 Calico# 应用 Calico 网络插件资源包里已提供 calico.yaml kubectl apply -f calico.yaml # 查看集群状态等 node 变成 Ready kubectl get nodesCalico 的 yaml 里默认使用 IPIP 模式如果你的集群所有节点在同一二层网络可以改成 BGP 模式性能更好。这个后面踩坑章节会细说。Node 节点加入的命令很简单但注意 token 有效期只有 24 小时如果集群搭完隔天才装 Kubeedgetoken 已经失效需要用kubeadm token create --print-join-command重新生成。2.3 版本匹配的硬约束为什么是 1.22.17 而不是更新的版本选版本这事我吃过亏。Kubeedge 1.13.1 的 CloudCore 对 Kubernetes API 的兼容性是经过官方验证的直接看兼容性矩阵它对应的 K8s 版本区间就是 1.22 到 1.23 左右。你如果非要用 K8s 1.28 去配 Kubeedge 1.13.1keadm 初始化时 CloudCore 拉取资源就会因为 CRD 版本差异直接报错。还有一个隐性问题值得注意K8s 1.24 之后彻底移除了 dockershim如果习惯用 Docker 做运行时就得装 cri-dockerd 适配层。而 Kubeedge 1.13.1 的 EdgeCore 在设计上对 containerd 的支持更完整保持 K8s 1.22.17 containerd 的组合相当于同时避开两个坑——版本不兼容和运行时适配。提示这套资源里的 yaml 文件和镜像都是基于上述版本组合打包的换版本意味着 yaml 可能失效离线镜像也可能用不上。3. 部署 KubeedgeCloudCore 和 EdgeCore 的初始化与通信机制Kubeedge 的部署逻辑分三步走云端装 CloudCore、边缘节点装 EdgeCore、两端建立通信隧道。这套资源用 keadm 命令行工具完成第一和第二步再把 CloudCore 的通信端口用 LoadBalancer 方式暴露出去这一步是打通边缘节点和云端的关键。3.1 keadm init 部署 CloudCore云端组件装到 Master 节点CloudCore 承载着 CloudHub、EdgeController、DeviceController 三个核心模块。CloudHub 负责监听边缘节点连接EdgeController 通过 K8s API 监听资源变化并下发。把这个组件部署到 K8s 集群里直接用 keadm 命令完成所有编排# 解压 keadm 工具包 tar -zxvf keadm-v1.13.1-linux-amd64.tar.gz # 部署 CloudCoreadvertise-address 指定为 MetalLB 将要分配的 VIP ./keadm init --advertise-address192.168.20.100 --kubeedge-versionv1.13.1--advertise-address这个参数是全文最容易出错的地方。如果你把这理解成 Master 节点的内网 IP那 CloudCore 的 Service 即使创建成功边缘节点也会拿着这个 IP 去连 CloudHub跨网段直接失败。正确做法是先规划好 MetalLB 的 IP 池范围从这个范围里挑一个 IP 作为 CloudCore 的访问入口。初始化完成后CloudCore 会以 Deployment 形式跑在kubeedge命名空间# 查看 CloudCore 状态 kubectl get pods -n kubeedge kubectl get svc -n kubeedge3.2 keadm join 把边缘节点拉进来token 引导与 EdgeCore 拉起过程边缘节点上需要先安装好 containerd 和 kubelet然后对应不同的系统架构选择加入参数。加入流程会先拉取 EdgeCore 镜像再生成 edgecore.service 服务并由 systemd 拉起运行时整个过程像这样# 获取 CloudCore 的 token在 Master 上执行 kubectl get secret -n kubeedge token -o jsonpath{.data.token} | base64 -d # 边缘节点加入集群在边缘机上执行 ./keadm join --cloudcore-ipport192.168.20.100:10000 \ --tokenxxxxx \ --kubeedge-versionv1.13.1--cloudcore-ipport的 IP 必须和 CloudCore 的--advertise-address保持一致端口用 10000 是 CloudHub 的默认 WebSocket 端口如果用的是 HTTPS 则对应 10002。EdgeCore 内部的 EdgeHub 模块会通过这个地址与云端建立长连接。加入完成后回到 Master 上执行kubectl get nodes如果看到边缘节点状态带node.kubernetes.io/kubeedge标签说明加入成功。3.3 CloudCore 服务化为什么用 LoadBalancer 暴露是正解默认情况下 CloudCore 的 Service 是 ClusterIP 类型边缘节点只能通过节点 IP NodePort 方式访问。但有三个问题节点 IP 变化会导致连接断开、端口映射容易冲突、跨网段时边缘设备无法感知节点 IP。资源包里把 CloudCore 改造成了 LoadBalancer 类型的 ServiceYAML 里大概是这样的核心配置apiVersion: v1 kind: Service metadata: name: cloudcore namespace: kubeedge spec: type: LoadBalancer loadBalancerIP: 192.168.20.100 selector: k8s-app: kubeedge kubeedge: cloudcore ports: - name: cloudhub port: 10000 targetPort: 10000 - name: cloudhub-https port: 10002 targetPort: 10002把type改成LoadBalancer并指定loadBalancerIPMetalLB 会从配置好的 IP 池里分配这个地址并借助 Layer2 模式通过 ARP 响应让整个二层网络内的设备都能访问这个 IP。这比用externalIPs字段手动绑定节点 IP 更稳定后者没有健康检查IP 对应的节点挂了服务就断了。MetalLB 会持续监控后端 Pod 的健康状态自动切换流量。4. MetalLB 负载均衡器Layer2 模式下的 IP 分配与服务暴露Kubeedge 场景里引入 MetalLB 不只是为了给 nginx 测试服务分配 IP更重要的是给 CloudCore 一个稳定的通信入口。这一章把 MetalLB 的部署、IP 池配置和验证流程走一遍。4.1 为什么选 Layer2 模式没有 BGP 环境的最省事方案MetalLB 支持 Layer2 和 BGP 两种模式。Layer2 模式下MetalLB 的 speaker 组件会在节点上响应 Service IP 的 ARP 请求把 VIP 的流量引导到某个节点再由 kube-proxy 转发到后端 Pod。BGP 模式则需要物理路由器配合需要额外配置 BGP peer对多数内网测试环境来说成本偏高。这套资源走的就是 Layer2 模式两个 yaml 文件——first-ipaddresspool.yaml定义地址池l2-forward.yaml开启通告。如果你只有一台物理机做测试Layer2 模式完全够用它不依赖路由器能力只要节点互通就能工作。4.2 metallb-native.yaml 与 IP 地址池配置全过程MetalLB 的部署方式随版本演进变化很大metallb-native.yaml表明用的是 v0.13.x 以上的 native 方式不需要单独的 manifests 目录。安装流程分三步# 1. 安装 MetalLB 的全部组件包括 controller 和 speaker kubectl apply -f metallb-native.yaml # 2. 定义可用 IP 池网段必须和集群节点在同一二层网络 cat first-ipaddresspool.yaml EOF apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.20.100-192.168.20.200 EOF kubectl apply -f first-ipaddresspool.yaml # 3. 开启 Layer2 通告把 IP 池与通告规则绑定 cat l2-forward.yaml EOF apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2-forward namespace: metallb-system spec: ipAddressPools: - first-pool EOF kubectl apply -f l2-forward.yamlIP 池的范围建议单独规划一段别跟 DHCP 的分配范围重叠否则其他设备拿到相同 IP 会导致 ARP 冲突Service 的访问时通时不通。L2Advertisement里的ipAddressPools数组可以关联多个池适合按业务划分不同网段的场景。4.3 验证负载均衡从 pending 到 EXTERNAL-IP 的完整过程部署完 MetalLB创建测试 Service验证 VIP 分配是否正常工作# 创建 nginx 部署和 LoadBalancer Serviceyaml 在资源包里 kubectl apply -f nginx.yaml kubectl apply -f nginx-loadbalancer.yaml # 查看服务状态等待 EXTERNAL-IP 从 pending 变为具体 IP kubectl get svc nginx-lb第一次执行kubectl get svc时看到EXTERNAL-IP是pending是正常的MetalLB 需要几秒钟完成 IP 分配和通告。如果超过 30 秒还是 pending执行kubectl logs -n metallb-system -l componentcontroller看日志八成是 IP 池没有关联到通告规则。拿到 VIP 后在集群内任意节点执行curl http://192.168.20.100能返回 nginx 默认页面说明负载均衡链路已打通。此时再回头看 CloudCore 的 Service确认它也拿到了192.168.20.100这个 IP边缘节点就能通过它建立连接了。5. 避坑指南Kubeedge 部署中最常翻车的五个场景Kubeedge 的部署文档写得不差但实际操作中翻车的点非常集中。下面五个坑都是我在部署过程中真实踩过的按「现象 → 原因 → 解决」的格式写清楚遇到同类问题可以直接照着排查。5.1 坑一镜像导入后 Pod 仍然 ImagePullBackOff现象用ctr images import kubeedge.tar导入了镜像但是 Pod 启动时仍然报拉取镜像失败。原因containerd 的分区 namespace 机制。kubelet 默认使用k8s.io这个 namespace用ctr images import不指定 namespace 时导入到的是defaultkubelet 根本看不到这些镜像。解决导入镜像时显式指定 namespacectr -n k8s.io images import kubeedge.tar ctr -n k8s.io images import coreedge.tar ctr -n k8s.io images import metallb_image.tar5.2 坑二边缘节点加入后状态一直是 Ready,Unknown现象kubectl get nodes看到边缘节点存在但状态列显示Ready,Unknown过几分钟又变回NotReady。原因CloudCore 和 EdgeCore 之间的 WebSocket 连接没有建立成功。最常见的是 CloudCore 的 Service 类型没有改成 LoadBalancer边缘节点拿不到正确端口或者--advertise-address配置成了 Master 的节点 IP边缘节点访问的是内网地址实际不可达。解决先确认 CloudCore Service 拿到了 VIP再检查边缘节点的journalctl -u edgecore日志搜索failed to connect字段定位是网络不通还是端口错误。5.3 坑三keadm init 报证书相关错误现象初始化 CloudCore 时提示证书签名不匹配或者证书有效期异常。原因keadm 会自动为 CloudCore 生成证书但生成过程依赖 K8s API Server 的版本。K8s 版本和 Kubeedge 版本不在兼容区间时就会出现这类问题。解决确认 K8s 版本是 1.22.17不要用最新的 1.29 之类的版本。如果你是先升级过集群再装 Kubeedge建议直接重建集群别在版本错乱的环境里硬磕。5.4 坑四MetalLB 分配不到外部 IP现象kubectl get svc显示 EXTERNAL-IP 一直是pendingMetalLB 的 controller 日志没有异常。原因IP 池配置的网段和集群节点不在同一个二层网络或者 IP 池被其他设备占用。Layer2 模式下 MetalLB 的 speaker 要把 VIP 宣告到局域网网段不互通就永远分配不了。解决把 IP 池里的 IP 改成和 Master 节点同一网段192.168.20.x确保这个网段的路由是可达的。另外检查节点防火墙有没有屏蔽 7946 端口的 VRRP 协议Layer2 模式会用到。5.5 坑五CloudCore 重启后边缘节点全部掉线现象kubectl rollout restart deployment cloudcore -n kubeedge后所有边缘节点的 Pod 都报连接失败。原因CloudCore 重启导致 WebSocket 连接断开EdgeCore 的 EdgeHub 模块需要重新发起握手请求但 token 已经过期。边缘节点持有的 token 和云端重新生成的 token 对不上。解决在边缘节点上重新执行 keadm join使用最新的 token# Master 上重新获取 token kubectl get secret -n kubeedge token -o jsonpath{.data.token} | base64 -d # 边缘节点重新加入 ./keadm join --cloudcore-ipport192.168.20.100:10000 --token新token --kubeedge-versionv1.13.16. 从部署到验证用 nginx 服务打通 LoadBalancer 全链路部署完 Kubeedge 和 MetalLB最后一步是验证整个链路能不能跑通。资源包里提供了现成的 nginx 和 Service 配置直接复现一遍能从 CloudCore、MetalLB、边缘节点三个维度确认系统的健康状态。先部署测试服务# 应用 nginx Deployment 和 LoadBalancer Service kubectl apply -f nginx.yaml kubectl apply -f nginx-loadbalancer.yaml # 确认 Pod 已经 Running且 EXTERNAL-IP 已分配 kubectl get pods -l appnginx kubectl get svc nginx-lb验证链路分三层来看对应不同的组件第一层验证 MetalLB 是否正常工作在任意节点上curl http://192.168.20.100如果返回 nginx 欢迎页说明 VIP 分配和二层宣告都正常。如果超时优先检查l2-forward.yaml是否有语法错误kubectl describe svc nginx-lb里的 Events 会给出具体报错。第二层验证 CloudCore 通信端口是否正常暴露在 Master 上检查# 确认 cloudcore Service 的 EXTERNAL-IP 是否已分配到规划 IP kubectl get svc -n kubeedge cloudcore # 如果 VIP 没分配成功看 MetalLB 的 controller 日志 kubectl logs -n metallb-system -l componentcontroller --tail50如果 CloudCore 的 EXTERNAL-IP 能正常访问说明 MetalLB 工作正常。边缘节点通过这个 IP 连接 CloudCore 的 10000 端口就是一条干净的链路。第三层验证边缘节点是否真正纳入集群管理到边缘节点上执行# 检查 EdgeCore 服务的运行状态 systemctl status edgecore # 回到 Master 查看节点状态Ready 和 agent 标签都存在 kubectl get nodes -o wide边缘节点日志里出现connection established字样就表示 EdgeHub 与 CloudHub 的 WebSocket 连接已稳定建立。这套资源的完整验证流程看似四个步骤实际上是把 CloudCore、EdgeCore、MetalLB、Calico 四条线串起来做了一次端到端连通性测试。最后说个个人习惯我在确认边缘节点加入成功之后会立刻把 keadm 和所有 tar 包归档到一个固定目录并记录 CloudCore Service 的 VIP 到本地笔记。因为每次 CloudCore 重启后边缘节点都需要重新 join如果没有记录 VIP 和 token后面排查问题时又要重新翻资源包里的文档。希望这套流程能帮你在搭 Kubeedge 的时候少走几个来回一次跑通。本文还有配套的精品资源点击获取