Kubernetes 1.28集群Flannel网络配置实战从ImagePullBackOff到Harbor私有仓库全解析在Kubernetes集群部署过程中网络插件的配置往往是第一个需要跨越的技术门槛。而当我们选择Flannel作为CNI插件时镜像拉取失败和私有仓库配置问题就像两座难以绕过的大山特别是对于国内环境下的运维团队。本文将带您深入这两个问题的核心不仅提供解决方案更会剖析背后的原理让您在下次遇到类似问题时能够举一反三。1. Flannel网络插件部署的镜像困境当我们在Kubernetes 1.28集群中部署Flannel网络插件时最常遇到的错误就是ImagePullBackOff。这个看似简单的错误背后其实隐藏着多个技术层面的挑战。1.1 镜像拉取失败的根源分析使用kubectl describe pod命令查看Flannel Pod的状态时通常会看到类似如下的错误信息Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m default-scheduler Successfully assigned kube-flannel/kube-flannel-ds-abcde to node1 Normal Pulling 1m (x4 over 2m) kubelet Pulling image flannel/flannel:v0.25.1 Warning Failed 1m (x4 over 2m) kubelet Failed to pull image flannel/flannel:v0.25.1: rpc error: code Unknown desc failed to pull and unpack image docker.io/flannel/flannel:v0.25.1: failed to resolve reference docker.io/flannel/flannel:v0.25.1: failed to do request: Head https://registry-1.docker.io/v2/flannel/flannel/manifests/v0.25.1: dial tcp: lookup registry-1.docker.io on 10.96.0.10:53: no such host Warning Failed 1m (x4 over 2m) kubelet Error: ErrImagePull Normal BackOff 30s (x6 over 2m) kubelet Back-off pulling image flannel/flannel:v0.25.1 Warning Failed 30s (x6 over 2m) kubelet Error: ImagePullBackOff造成这一问题的核心原因有三网络访问限制国内网络环境无法稳定访问Docker Hub等国外镜像仓库容器运行时变更Kubernetes 1.24版本移除了dockershim默认使用containerd镜像命名空间隔离containerd中的k8s.io命名空间与默认命名空间分离1.2 离线镜像导入的完整流程对于无法访问外网的环境离线导入镜像是可行的解决方案。以下是详细的操作步骤# 1. 下载离线镜像包假设已获取flannel-v0.25.1.tar.gz和flannel-cni-plugin-v1.4.0-flannel1.tar.gz # 2. 将镜像包上传到master节点 scp flannel-*.tar.gz usermaster:/tmp/ # 3. 导入到containerd的k8s.io命名空间 sudo ctr -n k8s.io images import /tmp/flannel-v0.25.1.tar.gz sudo ctr -n k8s.io images import /tmp/flannel-cni-plugin-v1.4.0-flannel1.tar.gz # 4. 验证镜像导入 sudo ctr -n k8s.io images ls | grep flannel注意必须使用-n k8s.io参数指定命名空间因为Kubernetes默认从这个命名空间查找镜像。1.3 Flannel配置文件的修改要点原始的kube-flannel.yml需要做两处关键修改镜像地址改为使用本地镜像去掉仓库前缀拉取策略设置为IfNotPresent避免kubelet尝试从远程仓库拉取修改后的配置片段示例containers: - name: kube-flannel image: flannel:v0.25.1 imagePullPolicy: IfNotPresent2. Containerd与Harbor私有仓库的深度集成虽然离线导入镜像可以临时解决问题但长期来看搭建私有镜像仓库才是更专业的解决方案。对于Kubernetes 1.28版本containerd与Harbor的集成需要特别注意以下配置细节。2.1 Containerd配置架构解析从containerd 1.6版本开始配置方式发生了变化主配置文件/etc/containerd/config.tomlCRI插件配置仓库配置/etc/containerd/certs.d/host:port/hosts.toml每个仓库独立配置这种分离式设计提高了灵活性但也增加了配置复杂度。2.2 分步配置Harbor私有仓库以下是详细的配置流程需要在每个节点执行# 1. 创建Harbor仓库配置目录 sudo mkdir -p /etc/containerd/certs.d/harbor.example.com # 2. 创建hosts.toml配置文件 cat EOF | sudo tee /etc/containerd/certs.d/harbor.example.com/hosts.toml server https://harbor.example.com [host.https://harbor.example.com] capabilities [pull, resolve, push] skip_verify true EOF # 3. 重启containerd服务 sudo systemctl restart containerd提示如果Harbor使用自签名证书必须设置skip_verify true否则会出现证书验证错误。2.3 镜像推送与拉取测试配置完成后可以通过以下步骤验证# 1. 标记本地镜像 sudo ctr -n k8s.io images tag flannel:v0.25.1 harbor.example.com/library/flannel:v0.25.1 # 2. 推送镜像到Harbor sudo ctr -n k8s.io images push harbor.example.com/library/flannel:v0.25.1 --plain-http # 3. 从Harbor拉取测试 sudo ctr -n k8s.io images pull harbor.example.com/library/flannel:v0.25.1 --plain-http3. Flannel部署的进阶优化解决了镜像问题后我们还可以对Flannel的部署进行一些优化调整以获得更好的网络性能。3.1 网络后端选择与性能对比Flannel支持多种后端实现不同后端有各自的优缺点后端类型性能跨节点通信配置复杂度适用场景VXLAN中支持低通用场景Host-gw高需要L2网络中同机房部署UDP低通用低测试环境在kube-flannel.yml中可以通过修改net-conf.json部分来指定后端net-conf.json: | { Network: 10.244.0.0/16, Backend: { Type: vxlan } }3.2 资源请求与限制配置为Flannel DaemonSet添加适当的资源限制可以避免网络组件占用过多节点资源resources: requests: cpu: 100m memory: 50Mi limits: cpu: 200m memory: 100Mi4. 常见问题排查指南即使按照最佳实践配置在实际部署中仍可能遇到各种问题。以下是几个典型问题的排查方法。4.1 镜像拉取失败排查流程当Pod处于ImagePullBackOff状态时可以按照以下步骤排查检查Pod描述信息kubectl describe pod pod-name验证节点上的镜像是否存在ctr -n k8s.io images ls | grep image-name检查containerd日志journalctl -u containerd -n 100 -f测试手动拉取镜像ctr -n k8s.io images pull image-url4.2 网络不通问题诊断如果Flannel Pod正常运行但节点间网络不通可以使用以下命令诊断# 检查Flannel接口配置 ip addr show flannel.1 # 检查路由表 ip route show # 测试跨节点通信 ping 其他节点Pod IP4.3 与Harbor集成时的证书问题当遇到x509证书错误时除了设置skip_verify外还可以将Harbor的CA证书添加到系统信任链# 1. 获取Harbor CA证书 openssl s_client -connect harbor.example.com:443 -showcerts /dev/null 2/dev/null | openssl x509 -outform PEM harbor-ca.pem # 2. 将证书复制到系统目录 sudo cp harbor-ca.pem /usr/local/share/ca-certificates/ # 3. 更新CA证书 sudo update-ca-certificates # 4. 重启containerd sudo systemctl restart containerd在实际生产环境中我们团队发现containerd 1.6版本对Harbor的集成确实比早期版本更加规范但配置复杂度也相应提高。建议在测试环境充分验证后再应用到生产集群。对于大规模集群可以考虑使用配置管理工具如Ansible批量部署containerd的Harbor集成配置以确保持续一致性。