简介Calico image v3.25.0离线包是面向Kubernetes集群管理员与运维人员的网络插件部署工具用于解决内网或离线环境无法在线拉取镜像造成Calico无法安装配置的难点。通过该包可不连接外部网络快速完成Calico的部署并启用网络策略管理适合生产环境受限或安全要求较高的集群。压缩包共3个文件包含一个tar格式的Docker镜像包集成Felix、BIRD、Typha等Calico核心服务组件、一个yaml格式的资源配置文件以及一份txt格式的离线安装说明文档。包体大小187.24MB结构紧凑便于内网传输也方便在离线镜像仓库中导入。已有449人学习/下载。用户可参照离线安装文档配合配置文件快速部署Calico并根据实际业务编写细粒度网络策略实现跨主机容器通信与安全管控。对于网络受限但仍需维护集群的团队这是一份稳定、高效的部署参考。 做Kubernetes集群实施的人十有八九都被离线环境这四个字折磨过。私有云、政务网、工厂生产区网络物理隔离是常态集群管理面的机器全都访问不了外网好不容易把K8s组件装起来了到网络插件这一步镜像拉不下来整套环境就卡住了。我在这种环境里反复折腾过好几轮最后形成一套固定打法提前准备calico-image-v3.25.0离线包。这个包把Calico v3.25.0用到的所有容器镜像、部署清单和辅助工具一次性打包好现场只需要导入镜像再apply清单几分钟就能把Pod网络拉起来。这篇就把我从打包到排障的完整流程写出来适合正在跟K8s网络死磕的运维也适合刚接触离线部署的新手照着抄作业。1. 先搞清楚Calico离线包到底要解决什么问题1.1 Calico在集群里扮演什么角色Calico是Kubernetes生态里使用率最高的CNI网络插件之一核心就干两件事一是给每个Pod分配IP、打通跨节点通信二是通过NetworkPolicy提供细粒度的网络策略控制。底层实现依赖BGP路由协议让每个节点的路由表主动学习彼此的路由数据包按路由表转发性能损耗很小。相比Flannel的VXLAN隧道方案Calico在跨节点通信上更接近物理路由器的行为而且策略能力是Flannel完全不具备的。所以生产集群里选Calico的比例非常高我经手的项目基本默认就是它。用更直白的话说Calico就像小区里的物业和交通管理员。Pod是住户需要稳定的门牌号IP和通畅的道路路由而不同住户之间的拜访规则网络策略也由它来定。没有它即使K8s集群本身是活的Pod之间也谈不上互联互通上层业务根本起不来。1.2 为什么非要准备离线包在能联网的环境里Calico部署就是kubectl apply -f calico.yaml一步到位镜像自动从Docker Hub或quay.io拉取。但离线环境没有这个前提kubelet只会反复重试拉取然后一路ImagePullBackOff节点状态亮红灯。这个问题的本质是K8s集群的网络组件存在先有鸡还是先有蛋的依赖——Calico本身要跑起来才能给其他Pod分配网络而Calico的镜像已经卡在没有网络的状态里。如果现场有几十上百个节点没有提前准备好镜像资源后面每台机器都要单独处理人在现场会非常被动。离线包的意义不光是把镜像打成tar包更在于把整个依赖关系固定下来哪些镜像、什么版本、是否匹配目标K8s版本这些在办公室就能全部验证完不用到现场再试错。抱着这种提前固化依赖的思路离线包才能真的提升交付效率而不是变成另一个搬运负担。1.3 为什么选v3.25.0这个版本v3.25.0在Calico版本序列里算是比较成熟的一个。它处于Kubernetes 1.24到1.27的兼容区间内覆盖了不少企业现在还在跑的主流K8s版本。我实测下来这个版本的calico-node内存占用控制得不错在2核4G的小型节点上也能稳定运行配置文件结构相对稳定网上能查到的资料和案例很多遇到问题不至于孤立无援。除非你有新特性或者特定K8s版本的要求否则在离线场景下没有必要追新选一个验证过的稳定版本更重要。这个思路也适用于所有离线依赖管理版本一旦确定就锁死在文档里不随便改动。生产环境里面稳定远比新潮值钱这是我踩过几次版本坑之后最深的体会。2. 离线包制作镜像清单、拉取、导出与导入2.1 一张表理清镜像依赖Calico v3.25.0默认部署下来涉及的核心镜像并不多离线打包前建议先把清单固定成表格避免漏掉任何一个。我常用的清单如下镜像名组件作用离线是否必需calico/cni:v3.25.0把CNI插件二进制安装到宿主机 /opt/cni/bin必需calico/node:v3.25.0核心Agent负责BGP路由、策略执行、健康检查必需calico/kube-controllers:v3.25.0控制器同步节点和策略资源必需calico/pod2daemon-flexvol:v3.25.0FlexVolume驱动用于卷挂载按需calico/typha:v3.25.0API聚合层降低API Server压力按需大规模集群其中typha这个组件节点数量超过50时强烈建议开启。普通规模的测试集群不开也可以官方文档也建议小规模时保持关闭以降低复杂度。另外如果开了CSI相关功能还需要额外准备calico/csi和calico/node-driver-registrar但大多数场景用不到我在制包时一般不加。2.2 联网机器上完成拉取与导出准备一台可以联网的Linux机器注意CPU架构必须和目标集群一致。uname -m看结果x86_64就选amd64架构镜像aarch64就选arm64。架构不一致的镜像导入后虽然能load进去但容器启动会直接报exec format error这个坑很隐蔽我见过不止一个同事踩过。确认架构后按顺序执行拉取和导出IMAGES( docker.io/calico/cni:v3.25.0 docker.io/calico/node:v3.25.0 docker.io/calico/kube-controllers:v3.25.0 docker.io/calico/pod2daemon-flexvol:v3.25.0 ) for img in ${IMAGES[]}; do docker pull $img done docker save -o calico-images-v3.25.0.tar \ docker.io/calico/cni:v3.25.0 \ docker.io/calico/node:v3.25.0 \ docker.io/calico/kube-controllers:v3.25.0 \ docker.io/calico/pod2daemon-flexvol:v3.25.0导出的tar包一般几百MB可以用tar.gz再压缩一层方便U盘或内部传输工具拷贝。拷贝到目标环境前最好在联网机器上再核对一次镜像清单和校验值避免传输过程中文件损坏。这个校验动作虽然不起眼但在弱网环境下能避免很多莫名其妙的问题。2.3 目标节点上的导入方式docker与containerd两套现在的K8s集群运行时是containerd居多。如果你在用docker起的集群直接docker load -i calico-images-v3.25.0.tar就行。但很多新集群的节点根本不装docker导入必须走containerd的接口ctr -n k8s.io images import calico-images-v3.25.0.tar注意-n k8s.io这个参数kubelet只从k8s.io命名空间读取镜像。不加它会导入到default命名空间kubelet还是看不到部署的时候照样ImagePullBackOff。如果你有私有镜像仓库更推荐的方式是把tar包上传到仓库服务器重新打tag后push到仓库节点配置好仓库地址后按名拉取。这样扩容新节点时不用再惦记镜像导入这件事一劳永逸。2.4 别忘了calicoctl和联网阶段能准备的其他工具除了镜像我建议在联网阶段把calicoctl工具也准备好。calicoctl是排查Calico问题最顺手的命令行工具v3.25.0对应的版本从GitHub release页面直接下载curl -L -o calicoctl https://github.com/projectcalico/calico/releases/download/v3.25.0/calicoctl-linux-amd64 chmod x calicoctl sudo mv calicoctl /usr/local/bin/另外calico.yaml清单文件也建议在联网机器上先下载好跟tar包放在一起。现场如果没有网络临时找一台外网机器去下载显然不现实。把这些一次性备齐离线部署才能真正做到心里有数。整个离线包的完整目录结构我习惯这样组织calico-v3.25.0-offline/ ├── calico.yaml ├── calico-images-v3.25.0.tar ├── calicoctl └── README.txtREADME里写明版本、架构、导入命令和验证命令方便其他人接手。这个习惯在团队协作时尤其重要。3. 部署Calico v3.25.0从YAML到网络就绪3.1 准备manifests并适配私有仓库部署的第一步是获取官方清单。在联网阶段下载一份calico.yamlcurl -L https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -o calico.yaml如果目标环境有私有镜像仓库最省事的做法是把清单里所有镜像地址批量替换成仓库地址sed -i s#docker.io/calico#registry.example.com/calico#g calico.yaml替换后建议用grep image calico.yaml检查一遍确认所有image字段都正确。这里有个容易忽略的点如果你的私有仓库没有对外开放HTTPS证书还需要在每个节点配置containerd或dockerd的insecure-registries否则镜像拉取会失败而且报错信息不太直观。我在一个项目里遇到过所有节点都显示ErrImagePull最后发现就是registry证书信任没配好加上insecure_registries后立刻恢复。3.2 正式部署与状态确认所有准备工作就绪后进入部署环节。在Master节点执行kubectl apply -f calico.yamlCalico会创建namespace、RBAC、DaemonSet、Deployment等一堆资源通常一两分钟内就能看到状态变化。接着验证kubectl get pods -n kube-system -l k8s-appcalico-node -o wide kubectl get pods -n kube-system -l k8s-appcalico-kube-controllers kubectl get nodes如果一切正常calico-node的所有Pod都处于Running状态节点在kubectl get nodes里也会变成Ready。这里要注意一点有时候calico-node显示Running但节点迟迟不Ready大概率就是readinessProbe里BGP peering还没建立成功这个在第4部分单独展开。不要看到Running就以为万事大吉一定要确认节点Ready和网络策略生效。3.3 网络功能验证连个Pod试一下光看节点Ready还不够我习惯部署完成后立刻做一轮网络冒烟测试。创建两个测试Pod放在不同节点上验证跨主机通信kubectl run test-a --imagebusybox -- sleep 3600 kubectl run test-b --imagebusybox -- sleep 3600进入其中一个Podping另一个Pod的IP。如果通了说明跨节点网络正常。再测试一下ClusterIP服务访问确认kube-proxy的规则和Calico的路由能配合起来。如果要验证NetworkPolicy可以给某个namespace打上策略只允许特定标签的Pod访问然后观察另一个Pod的请求是否被拒绝。这一套操作下来才算真正验证了Calico的网络能力而不是仅仅看节点状态。我自己的经验是冒烟测试脚本最好提前写好里面包含Pod互通、Service访问、NetworkPolicy阻断三个用例到现场直接执行输出一目了然。这样既节省时间也减少现场操作出错的可能。3.4 关键参数调整IP检测、Pod网段、IPIP/VXLANcalico.yaml里直接改动的地方不多但有三个经常需要调整。第一个是IP_AUTODETECTION_METHOD。多数机器有多个网卡Calico默认自动检测第一个合法IP很容易选到docker0或内网管理口导致Pod网段通信异常。稳妥的做法是指定物理网卡- name: IP_AUTODETECTION_METHOD value: interfaceeth.*第二个是Pod网段默认是192.168.0.本文还有配套的精品资源点击获取 Kubernetes离线环境实战：Calico v3.25.0离线包制作与集群部署
简介Calico image v3.25.0离线包是面向Kubernetes集群管理员与运维人员的网络插件部署工具用于解决内网或离线环境无法在线拉取镜像造成Calico无法安装配置的难点。通过该包可不连接外部网络快速完成Calico的部署并启用网络策略管理适合生产环境受限或安全要求较高的集群。压缩包共3个文件包含一个tar格式的Docker镜像包集成Felix、BIRD、Typha等Calico核心服务组件、一个yaml格式的资源配置文件以及一份txt格式的离线安装说明文档。包体大小187.24MB结构紧凑便于内网传输也方便在离线镜像仓库中导入。已有449人学习/下载。用户可参照离线安装文档配合配置文件快速部署Calico并根据实际业务编写细粒度网络策略实现跨主机容器通信与安全管控。对于网络受限但仍需维护集群的团队这是一份稳定、高效的部署参考。 做Kubernetes集群实施的人十有八九都被离线环境这四个字折磨过。私有云、政务网、工厂生产区网络物理隔离是常态集群管理面的机器全都访问不了外网好不容易把K8s组件装起来了到网络插件这一步镜像拉不下来整套环境就卡住了。我在这种环境里反复折腾过好几轮最后形成一套固定打法提前准备calico-image-v3.25.0离线包。这个包把Calico v3.25.0用到的所有容器镜像、部署清单和辅助工具一次性打包好现场只需要导入镜像再apply清单几分钟就能把Pod网络拉起来。这篇就把我从打包到排障的完整流程写出来适合正在跟K8s网络死磕的运维也适合刚接触离线部署的新手照着抄作业。1. 先搞清楚Calico离线包到底要解决什么问题1.1 Calico在集群里扮演什么角色Calico是Kubernetes生态里使用率最高的CNI网络插件之一核心就干两件事一是给每个Pod分配IP、打通跨节点通信二是通过NetworkPolicy提供细粒度的网络策略控制。底层实现依赖BGP路由协议让每个节点的路由表主动学习彼此的路由数据包按路由表转发性能损耗很小。相比Flannel的VXLAN隧道方案Calico在跨节点通信上更接近物理路由器的行为而且策略能力是Flannel完全不具备的。所以生产集群里选Calico的比例非常高我经手的项目基本默认就是它。用更直白的话说Calico就像小区里的物业和交通管理员。Pod是住户需要稳定的门牌号IP和通畅的道路路由而不同住户之间的拜访规则网络策略也由它来定。没有它即使K8s集群本身是活的Pod之间也谈不上互联互通上层业务根本起不来。1.2 为什么非要准备离线包在能联网的环境里Calico部署就是kubectl apply -f calico.yaml一步到位镜像自动从Docker Hub或quay.io拉取。但离线环境没有这个前提kubelet只会反复重试拉取然后一路ImagePullBackOff节点状态亮红灯。这个问题的本质是K8s集群的网络组件存在先有鸡还是先有蛋的依赖——Calico本身要跑起来才能给其他Pod分配网络而Calico的镜像已经卡在没有网络的状态里。如果现场有几十上百个节点没有提前准备好镜像资源后面每台机器都要单独处理人在现场会非常被动。离线包的意义不光是把镜像打成tar包更在于把整个依赖关系固定下来哪些镜像、什么版本、是否匹配目标K8s版本这些在办公室就能全部验证完不用到现场再试错。抱着这种提前固化依赖的思路离线包才能真的提升交付效率而不是变成另一个搬运负担。1.3 为什么选v3.25.0这个版本v3.25.0在Calico版本序列里算是比较成熟的一个。它处于Kubernetes 1.24到1.27的兼容区间内覆盖了不少企业现在还在跑的主流K8s版本。我实测下来这个版本的calico-node内存占用控制得不错在2核4G的小型节点上也能稳定运行配置文件结构相对稳定网上能查到的资料和案例很多遇到问题不至于孤立无援。除非你有新特性或者特定K8s版本的要求否则在离线场景下没有必要追新选一个验证过的稳定版本更重要。这个思路也适用于所有离线依赖管理版本一旦确定就锁死在文档里不随便改动。生产环境里面稳定远比新潮值钱这是我踩过几次版本坑之后最深的体会。2. 离线包制作镜像清单、拉取、导出与导入2.1 一张表理清镜像依赖Calico v3.25.0默认部署下来涉及的核心镜像并不多离线打包前建议先把清单固定成表格避免漏掉任何一个。我常用的清单如下镜像名组件作用离线是否必需calico/cni:v3.25.0把CNI插件二进制安装到宿主机 /opt/cni/bin必需calico/node:v3.25.0核心Agent负责BGP路由、策略执行、健康检查必需calico/kube-controllers:v3.25.0控制器同步节点和策略资源必需calico/pod2daemon-flexvol:v3.25.0FlexVolume驱动用于卷挂载按需calico/typha:v3.25.0API聚合层降低API Server压力按需大规模集群其中typha这个组件节点数量超过50时强烈建议开启。普通规模的测试集群不开也可以官方文档也建议小规模时保持关闭以降低复杂度。另外如果开了CSI相关功能还需要额外准备calico/csi和calico/node-driver-registrar但大多数场景用不到我在制包时一般不加。2.2 联网机器上完成拉取与导出准备一台可以联网的Linux机器注意CPU架构必须和目标集群一致。uname -m看结果x86_64就选amd64架构镜像aarch64就选arm64。架构不一致的镜像导入后虽然能load进去但容器启动会直接报exec format error这个坑很隐蔽我见过不止一个同事踩过。确认架构后按顺序执行拉取和导出IMAGES( docker.io/calico/cni:v3.25.0 docker.io/calico/node:v3.25.0 docker.io/calico/kube-controllers:v3.25.0 docker.io/calico/pod2daemon-flexvol:v3.25.0 ) for img in ${IMAGES[]}; do docker pull $img done docker save -o calico-images-v3.25.0.tar \ docker.io/calico/cni:v3.25.0 \ docker.io/calico/node:v3.25.0 \ docker.io/calico/kube-controllers:v3.25.0 \ docker.io/calico/pod2daemon-flexvol:v3.25.0导出的tar包一般几百MB可以用tar.gz再压缩一层方便U盘或内部传输工具拷贝。拷贝到目标环境前最好在联网机器上再核对一次镜像清单和校验值避免传输过程中文件损坏。这个校验动作虽然不起眼但在弱网环境下能避免很多莫名其妙的问题。2.3 目标节点上的导入方式docker与containerd两套现在的K8s集群运行时是containerd居多。如果你在用docker起的集群直接docker load -i calico-images-v3.25.0.tar就行。但很多新集群的节点根本不装docker导入必须走containerd的接口ctr -n k8s.io images import calico-images-v3.25.0.tar注意-n k8s.io这个参数kubelet只从k8s.io命名空间读取镜像。不加它会导入到default命名空间kubelet还是看不到部署的时候照样ImagePullBackOff。如果你有私有镜像仓库更推荐的方式是把tar包上传到仓库服务器重新打tag后push到仓库节点配置好仓库地址后按名拉取。这样扩容新节点时不用再惦记镜像导入这件事一劳永逸。2.4 别忘了calicoctl和联网阶段能准备的其他工具除了镜像我建议在联网阶段把calicoctl工具也准备好。calicoctl是排查Calico问题最顺手的命令行工具v3.25.0对应的版本从GitHub release页面直接下载curl -L -o calicoctl https://github.com/projectcalico/calico/releases/download/v3.25.0/calicoctl-linux-amd64 chmod x calicoctl sudo mv calicoctl /usr/local/bin/另外calico.yaml清单文件也建议在联网机器上先下载好跟tar包放在一起。现场如果没有网络临时找一台外网机器去下载显然不现实。把这些一次性备齐离线部署才能真正做到心里有数。整个离线包的完整目录结构我习惯这样组织calico-v3.25.0-offline/ ├── calico.yaml ├── calico-images-v3.25.0.tar ├── calicoctl └── README.txtREADME里写明版本、架构、导入命令和验证命令方便其他人接手。这个习惯在团队协作时尤其重要。3. 部署Calico v3.25.0从YAML到网络就绪3.1 准备manifests并适配私有仓库部署的第一步是获取官方清单。在联网阶段下载一份calico.yamlcurl -L https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -o calico.yaml如果目标环境有私有镜像仓库最省事的做法是把清单里所有镜像地址批量替换成仓库地址sed -i s#docker.io/calico#registry.example.com/calico#g calico.yaml替换后建议用grep image calico.yaml检查一遍确认所有image字段都正确。这里有个容易忽略的点如果你的私有仓库没有对外开放HTTPS证书还需要在每个节点配置containerd或dockerd的insecure-registries否则镜像拉取会失败而且报错信息不太直观。我在一个项目里遇到过所有节点都显示ErrImagePull最后发现就是registry证书信任没配好加上insecure_registries后立刻恢复。3.2 正式部署与状态确认所有准备工作就绪后进入部署环节。在Master节点执行kubectl apply -f calico.yamlCalico会创建namespace、RBAC、DaemonSet、Deployment等一堆资源通常一两分钟内就能看到状态变化。接着验证kubectl get pods -n kube-system -l k8s-appcalico-node -o wide kubectl get pods -n kube-system -l k8s-appcalico-kube-controllers kubectl get nodes如果一切正常calico-node的所有Pod都处于Running状态节点在kubectl get nodes里也会变成Ready。这里要注意一点有时候calico-node显示Running但节点迟迟不Ready大概率就是readinessProbe里BGP peering还没建立成功这个在第4部分单独展开。不要看到Running就以为万事大吉一定要确认节点Ready和网络策略生效。3.3 网络功能验证连个Pod试一下光看节点Ready还不够我习惯部署完成后立刻做一轮网络冒烟测试。创建两个测试Pod放在不同节点上验证跨主机通信kubectl run test-a --imagebusybox -- sleep 3600 kubectl run test-b --imagebusybox -- sleep 3600进入其中一个Podping另一个Pod的IP。如果通了说明跨节点网络正常。再测试一下ClusterIP服务访问确认kube-proxy的规则和Calico的路由能配合起来。如果要验证NetworkPolicy可以给某个namespace打上策略只允许特定标签的Pod访问然后观察另一个Pod的请求是否被拒绝。这一套操作下来才算真正验证了Calico的网络能力而不是仅仅看节点状态。我自己的经验是冒烟测试脚本最好提前写好里面包含Pod互通、Service访问、NetworkPolicy阻断三个用例到现场直接执行输出一目了然。这样既节省时间也减少现场操作出错的可能。3.4 关键参数调整IP检测、Pod网段、IPIP/VXLANcalico.yaml里直接改动的地方不多但有三个经常需要调整。第一个是IP_AUTODETECTION_METHOD。多数机器有多个网卡Calico默认自动检测第一个合法IP很容易选到docker0或内网管理口导致Pod网段通信异常。稳妥的做法是指定物理网卡- name: IP_AUTODETECTION_METHOD value: interfaceeth.*第二个是Pod网段默认是192.168.0.本文还有配套的精品资源点击获取