1. 为什么说卡在Calico安装上的时间九成都耗在“链路”上前阵子帮客户在一批国内云主机上搭Kubernetes集群控制面用kubeadm初始化的一切正常就差CNI网络插件。版本选型时看了官方文档推荐Calico v3.26.4我心想这东西也就下载一个manifest、apply一下的事结果从下午两点折腾到晚上。先用curl拉官方calico.yaml连着超时三次好不容易拉到文件kubectl apply之后节点上的Pod开始ImagePullBackOffdescribe一看镜像还是从quay.io拉取直接卡死。后来逐行检查YAML才发现有些镜像藏在initContainers里之前只替换了主干镜像漏了一处整个集群就等于没装上网络组件。那次经历让我彻底意识到一个问题在国内网络环境下装Calico真正的卡点从来不是Calico本身怎么配置而是“链路”两个字。链路包含三层GitHub链接、镜像仓库链接、以及网段和网络封装的配置链路。任何一层不通装出来的集群都是半残状态。1.1 抛开Calico配置先看它到底依赖哪些网络资源Calico安装时涉及的外部依赖其实非常集中官方manifest文件默认是从raw.githubusercontent.com下载这个域名在国内的访问质量时好时坏尤其对于几百KB的YAML经常下载到一半连接被重置。Calico组件镜像默认指向quay.io/calico/*少数版本也会引用docker.io/calico/*。quay.io在国内的可用性比docker.io还差很多服务器根本不配访问这个仓库。如果要使用calicoctl命令行工具还要从GitHub Release下载二进制同样是网络瓶颈。也就是说你还没开始碰Calico的网络模型配置光是获取安装文件这一步就已经把一大半耐心耗完了。很多时候不是你的Kubernetes集群有问题而是连最基本的imagePull都完成不了。1.2 只在daemon层配置镜像加速解决不了全部问题不少人的第一反应是给Docker或containerd配上镜像加速器以为这样就能绕过网络问题。这个思路没错但有个坑很多人没意识到Docker的registry-mirrors只会代理Docker Hubdocker.io的镜像对quay.io完全不生效。你就算配了加速器Calico默认manifest里的quay.io/calico/node依然走原始地址速度该慢还是慢该超时还是超时。containerd的配置稍微灵活一点你可以在config.toml里针对某个registry单独指定mirror endpoint比如对docker.io配置华为云加速地址。但问题在于如果manifest里写的是quay.io你同样要单独再写一条quay.io的mirror配置。更麻烦的是公共镜像加速器近年来频繁失效今天能用明天可能就超时尤其在业务高峰期。所以我一直强调一个观点加速器只能作为兜底真正可靠的方式是先把镜像搬到你自己能完全掌控的私有仓库里然后再一次性把manifest里的image字段整体替换掉。1.3 版本选择为什么这次锁定v3.26.4Calico目前迭代很快v3.27、v3.28都已经发布但我在生产环境依然倾向于选择v3.26.4。原因很简单这个版本足够稳定支持主流Kubernetes版本且网上踩坑资料相对丰富。它对eBPF数据面、WireGuard加密、BGP和VXLAN都有完整支持功能上没有明显短板。对于国内多数用户来说追新版本的意义不大反而可能引入新的镜像tag漂移或配置项变更。这篇文章后面所有命令和脚本都基于v3.26.4编写如果你用其他版本注意把镜像tag和manifest下载路径改成对应版本即可脚本的核心逻辑完全通用。2. 安装前需要拍板的三个环境决策部署模式、网段和网络封装很多人在Calico安装失败后第一反应是怀疑镜像拉取实际上有一类问题纯粹是安装前没把环境变量定清楚。我建议在动手执行任何命令前先花十分钟确认三件事用哪种方式部署、Pod网段定多少、网络封装模式选什么。这三件事决定后面所有操作的大方向。2.1 部署模式单文件manifest是多数场景的最优解Calico官方提供了三种主流部署方式我整理了适合不同场景的选择部署方式适用场景优点国内网络环境下的实际问题Operator需要自动升级、大规模集群管理功能全持续管理Calico版本自动化程度高Operator自身镜像也要替换且引入了额外CRD和控制器排查链路更长单文件manifest中小集群、一次性安装、离线交付单文件易审查、易改image、可控性强需要手动处理镜像替换但难度不大Helm已有Helm体系、需要模板化部署values可编程适合批量交付需要维护chart仓库和OCI registry隔离网络下多一层工具链我的建议很直接如果你像大多数用户一样只需要一个稳定可靠的CNI别恋战Operator单文件manifest是性价比最高的方案。它最大的好处是你能用grep和sed直接审查每一个镜像和参数所有东西都在一个文件里出了问题很容易定位。2.2 网段规划kubeadm和Calico的CIDR必须统一这是很多人忽略的问题。kubeadm init时如果指定了--pod-network-cidr10.244.0.0/16但Calico安装时保持默认的192.168.0.0/16就会出现一个非常隐蔽的现象Calico创建了自己的IPPoolPod也能分配IP但节点上的路由表会和kube-controller-manager预期的Pod网段不一致导致跨节点通信时包被丢进黑洞。查看当前集群的Pod网段配置kubeadm config view | grep -i pod-subnet如果已经装完Calico可以通过Calico的IPPool确认当前实际使用的网段kubectl get ippool -o yaml | grep -A5 cidr我的经验是如果没有特殊要求直接让kubeadm init时的Pod网段对齐Calico默认值192.168.0.0/16这样安装Calico时一行都不用改。如果不巧你的VPC内网网段已经占用了192.168.0.0/16那就要同步修改kubeadm参数和Calico的CALICO_IPV4POOL_CIDR环境变量两边必须保持一致。2.3 网络封装模式公有云上优先避开IPIPCalico的跨节点通信有几种主流封装模式选错模式在云上是个大坑模式封装方式适用场景云环境注意点IPIP默认隧道封装跨子网、虚拟化网络部分云安全组不放行协议号4导致隧道包被丢弃VXLANUDP 4789封装对网络和设备兼容性要求高的场景需要放行UDP 4789端口BGP无封装直接路由自建机房、Underlay网络可控公有云VPC如果不支持BGP网关跨节点路由难以自动下发很多人在公有云上装完Calico后遇到一个经典问题Pod都能创建单个节点内部通信正常但跨节点的Pod ping不通。查了半天才发现IPIP封装要求底层网络允许IP-in-IP协议的包通过而云主机的安全组默认不会放行协议号4。这种情况下要么在安全组里显式放开要么干脆把Calico改成VXLAN模式然后在安全组里放行UDP 4789。对于纯裸机IDC环境IPIP通常够用性能开销也比VXLAN低一些。2.4 节点运行时差异docker、containerd、k3s的坑不一样国内存量集群很多还在用Docker运行时但新集群基本都切到containerd了。这两个运行时的镜像加速配置完全不同。Docker只要修改/etc/docker/daemon.json的registry-mirrors字段containerd则要改/etc/containerd/config.toml下的[plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io]。如果你用的是k3s还要多处理一层k3s默认自带flannel想换成Calico必须先禁用flannel否则两个CNI会争抢/etc/cni/net.d/目录下的配置文件。二进制方式安装的Kubernetes集群则要确保kubelet的CNI配置目录和Calico的DaemonSet挂载路径一致。这些细节不提前确认安装时就会多出很多莫名其妙的报错。3. 华为云SWR镜像同步与节点加速器配置先把镜像这件事彻底解决镜像问题不解决后面所有步骤都是空谈。我的完整思路分三步走第一在能正常下载镜像的构建机上把Calico相关镜像同步到华为云SWR第二在目标节点上配置华为云镜像加速器作为兜底第三用脚本把manifest里的镜像地址一次性替换掉。这里先讲前两步。3.1 先梳理Calico v3.26.4到底要哪几个镜像单文件manifest方式安装Calico时核心组件镜像如下镜像说明calico/node主要节点代理负责路由、ACL、隧道等calico/cniCNI插件安装容器在节点上安装网络插件二进制calico/kube-controllers控制器组件负责IPPool管理等calico/pod2daemon-flexvolFlexVolume驱动可选但manifest中常出现以上镜像在v3.26.4版本中tag基本都是v3.26.4。如果你额外安装了Typha或API Server还需要同步calico/typha和calico/apiserver不过单文件manifest默认不会启用这些组件。建议先把镜像列表保存下来方便后续循环处理cat calico-images.txt EOF calico/node calico/cni calico/kube-controllers calico/pod2daemon-flexvol EOF3.2 在能正常访问外网的构建机上完成同步与推送首先要有一台网络环境正常的构建机这台机器必须能稳定地从quay.io或docker.io拉取镜像。在构建机上执行以下步骤先登录华为云SWR登录指令在华为云容器镜像服务控制台的“组织管理”里可以拿到长这样docker login swr.cn-north-4.myhuaweicloud.com -u ... -p ...然后批量拉取、打tag、推送export VERv3.26.4 export MIRRORswr.cn-north-4.myhuaweicloud.com/calico while read img; do echo pull ${img}:${VER} docker pull quay.io/${img}:${VER} echo tag ${img}:${VER} docker tag quay.io/${img}:${VER} ${MIRROR}/${img}:${VER} echo push ${img}:${VER} docker push ${MIRROR}/${img}:${VER} done calico-images.txt这里有个关键细节我建议在SWR上创建一个组织名称就叫calico这样推送后仓库路径会是swr.cn-north-4.myhuaweicloud.com/calico/node这样的结构和后面sed替换脚本里的前缀正好衔接。如果你把组织命名为其他名字后面脚本里的MIRROR_REGISTRY变量也要同步修改。推送完成后到SWR控制台确认镜像列表都存在别急着往下走。很多人到了这一步发现某个镜像没push上结果pod创建时卡在ImagePullBackOff回头排查才发现是tag拼错了或签名没登录。3.3 在目标节点上配置华为云镜像加速器同步完镜像后节点本身的镜像拉取能力也建议顺手优化一把。华为云容器镜像服务控制台会提供一个专属的镜像加速器地址格式类似https://xxxx.mirror.swr.myhuaweicloud.com。对于Docker运行时修改/etc/docker/daemon.json{ registry-mirrors: [https://xxxx.mirror.swr.myhuaweicloud.com] }然后重启Docker并验证systemctl restart docker docker info | grep -A2 Registry Mirrors对于containerd运行时先备份配置cp /etc/containerd/config.toml /etc/containerd/config.toml.bak然后在合适位置加入[plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://xxxx.mirror.swr.myhuaweicloud.com]重启containerd后用crictl验证systemctl restart containerd crictl pull docker.io/library/alpine:3.18这里要特别提醒如果你使用的containerd版本较老config.toml里默认可能是空配置直接覆盖新配置即可新版本则要保留原有的sandbox_image等字段。写错一个标点containerd都起不来。3.4 镜像同步环节常见的两个失误第一个失误是SWR命名空间层级搞错。SWR的地址结构是swr.region.myhuaweicloud.com/{组织名}/{仓库名}很多人把组织名直接设成一个很长的路径导致脚本替换后镜像地址里出现多层目录pull的时候反而报404。我的建议是组织名保持简洁比如calico让每一个镜像仓库名和原本的calico/xxx一一对应。第二个失误是替换不完整只处理了Deployment和DaemonSet里的image:漏掉了initContainers里的镜像。Calico的calico-nodeDaemonSet里其实有多个容器包括install-cni、flexvol-driver等它们的镜像同样在image:字段下要求sed替换时必须覆盖整个YAML所有出现image:的位置。这也是为什么我强烈推荐用脚本统一替换而不是手动逐行改。4. 镜像替换脚本设计思路与完整实现v3.26.4版既然要长期和国内网络环境打交道手动改manifest终究不是办法。我干脆写了一个可复用的脚本来解决三个问题自动下载或读取manifest、自动替换所有镜像地址、可选自动apply。脚本本身不复杂但每一步都针对前面提到的坑做了处理。4.1 为什么手动sed一个文件还不够手动改YAML的第一个问题是容易漏。一个calico.yaml文件里可能有二三十处image:字段分布在Deployment、DaemonSet、initContainers等不同位置肉眼检查非常容易遗漏。第二个问题是不同manifest里镜像写法不统一有的写全路径quay.io/calico/node:v3.26.4有的简写calico/node:v3.26.4手动正则替换很容易出错。脚本的价值就在于把整个过程自动化并且用替换前后的镜像列表做差异对比让你一眼看到有没有漏网之鱼。4.2 脚本完整代码下面这个脚本适用于Calico v3.26.4核心思路同样适用于其他版本。我把变量尽量放到顶部方便你改。#!/usr/bin/env bash # # install-calico-v3.26.4.sh # 用途国内网络环境下快速生成Calico v3.26.4 manifest并替换镜像为华为云SWR地址 # 用法 # ./install-calico-v3.26.4.sh # ./install-calico-v3.26.4.sh --apply # ./install-calico-v3.26.4.sh -f /path/to/calico.yaml --apply # set -euo pipefail # 需要按实际情况修改 MIRROR_REGISTRYswr.cn-north-4.myhuaweicloud.com/calico CALICO_VERSIONv3.26.4 MANIFEST_URLhttps://raw.githubusercontent.com/projectcalico/calico/${CALICO_VERSION}/manifests/calico.yaml MANIFEST_FILEcalico-${CALICO_VERSION}.yaml LOCAL_FILE APPLYfalse # usage() { cat EOF Usage: $0 [--apply] [-f local-manifest] --apply 替换完镜像后自动执行 kubectl apply --server-side -f, --file 使用本地已下载的 calico.yaml跳过网络下载 EOF exit 1 } while [[ $# -gt 0 ]]; do case $1 in --apply) APPLYtrue; shift ;; -f|--file) LOCAL_FILE$2; shift 2 ;; *) usage ;; esac done log_info() { echo [INFO] $(date %Y-%m-%d %H:%M:%S) $* } # 1. 获取 manifest if [[ -n $LOCAL_FILE ]]; then if [[ ! -f $LOCAL_FILE ]]; then echo [ERROR] 本地文件不存在: $LOCAL_FILE 2 exit 1 fi cp $LOCAL_FILE $MANIFEST_FILE log_info 使用本地 manifest: $LOCAL_FILE else log_info 下载官方 manifest: $MANIFEST_URL if ! curl -L --fail --retry 5 --connect-timeout 10 -o $MANIFEST_FILE $MANIFEST_URL; then echo [ERROR] 从 GitHub 下载失败请先用 -f 指定本地文件。 2 exit 1 fi fi # 2. 打印替换前镜像列表 log_info 替换前镜像列表: grep -E ^\s*image: $MANIFEST_FILE | sed s/^[[:space:]]*// | sort -u # 3. 核心替换同时处理 quay.io/calico/、docker.io/calico/、calico/ 三种写法 sed -i -E s#(image:[[:space:]])((quay\.io|docker\.io)/)?calico/#\1${MIRROR_REGISTRY}/#g $MANIFEST_FILE # 4. 可选离线/内网环境下把 imagePullPolicy 从 Always 改为 IfNotPresent sed -i /imagePullPolicy: Always/s/Always/IfNotPresent/ $MANIFEST_FILE # 5. 打印替换后镜像列表人工确认 log_info 替换后镜像列表: grep -E ^\s*image: $MANIFEST_FILE | sed s/^[[:space:]]*// | sort -u # 6. 自动 apply if [[ $APPLY true ]]; then log_info 执行 kubectl apply --server-side ... kubectl apply --server-side -f $MANIFEST_FILE else log_info manifest 已生成: $MANIFEST_FILE log_info 确认无误后执行: kubectl apply --server-side -f $MANIFEST_FILE fi4.3 逐段解读下载、替换、校验、应用下载部分用curl -L --fail --retry 5 --connect-timeout 10遇到GitHub抽风会自动重试五次。如果还是失败脚本会提示你用-f参数指定本地已下载的manifest。这个设计很实际在国内网络环境下直接把下载失败当“正常流程”处理让用户自己选择用哪种方式拿到文件。替换部分是整个脚本的核心。正则是sed -i -E s#(image:[[:space:]])((quay\.io|docker\.io)/)?calico/#\1${MIRROR_REGISTRY}/#g $MANIFEST_FILE这段正则的意思是找到image:开头的位置后面如果跟的是quay.io/或docker.io/就忽略然后匹配calico/最后把整个前缀替换成${MIRROR_REGISTRY}/。由于calico/xxx后面的tag是保留的所以calico/node:v3.26.4会变成swr.cn-north-4.myhuaweicloud.com/calico/node:v3.26.4tag不会被破坏。校验部分非常关键。脚本替换前和替换后都会打印一份去重后的镜像列表你肉眼扫一眼就能确认替换后不应该再出现quay.io或裸的calico/开头的镜像地址。如果你看到还有漏网说明manifest里可能出现了其他不常见写法需要手动处理。imagePullPolicy的修改属于可选项。默认情况下Calico的镜像策略是Always这会让节点每次重建Pod时都尝试访问镜像仓库判断远端是否有新镜像。在离线或内网环境下这会拖慢Pod启动速度所以我顺手改成IfNotPresent。如果你希望保持升级时自动拉取新镜像的行为可以把这句sed删掉。最后apply时用了kubectl apply --server-side。这是Calico官方推荐的方式因为manifest中涉及大量字段所有权冲突server-side apply能有效减少“Invalid value: ... field is immutable”这类报错。4.4 使用示例与手动网络参数调整执行脚本前先加执行权限chmod x install-calico-v3.26.4.sh只生成替换后的manifest不自动部署./install-calico-v3.26.4.sh确认镜像列表无误后手动applykubectl apply --server-side -f calico-v3.26.4.yaml一次性搞定./install-calico-v3.26.4.sh --apply如果你的Pod网段不是Calico默认的192.168.0.0/16脚本不会自动帮你改CALICO_IPV4POOL_CIDR因为这句配置在官方manifest里默认是注释状态用sed自动解开注释并替换value的鲁棒性不够好。我的建议是安装前用grep -n CALICO_IPV4POOL_CIDR calico-v3.26.4.yaml定位到对应段落手动把注释去掉并改成你规划的网段。例如# - name: CALICO_IPV4POOL_CIDR # value: 192.168.0.0/16改成- name: CALICO_IPV4POOL_CIDR value: 10.244.0.0/16同理多网卡节点上需要显式指定IP自动探测方式也可以在这个文件里找到IP_AUTODETECTION_METHOD段解开注释并修改。5. 安装完成不代表结束跨节点连通性验证与常用检查手段apply完成不等于Calico已经正常工作。很多人的习惯是看一眼Pod全部Running就认为成功但跨节点通信才是网络插件的终极大考。5.1 安装后的第一轮检查先看节点上Calico相关Pod的状态kubectl get pods -n kube-system -l k8s-appcalico-node -owide正常情况下所有节点上的calico-node都应该是Running状态。如果某个节点上的Pod一直不是Running用describe和logs定位kubectl describe pod -n kube-system calico-node-pod-name kubectl logs -n kube-system calico-node-pod-name -c install-cniinstall-cni容器负责在节点上写入CNI配置它如果失败Calico数据平面就无法工作。日志里常见的错误包括无法写入/etc/cni/net.d/目录、检测到旧的flannel配置等。同时检查IPPool是否创建成功kubectl get ippool如果显示default-ipv4-ippool说明Calico已经初始化了默认IP池。如果没有说明Calico数据平面初始化失败需要看calico-node日志。5.2 跨节点Pod通信测试最靠谱的验收方式单节点内通信走的是本地路由测不出CNI的真正问题所以必须把测试Pod调度到两个不同节点上。可以写一个简单的测试YAMLapiVersion: v1 kind: Pod metadata: name: ping-a spec: nodeName: node-1 containers: - name: alpine image: docker.io/library/alpine:3.18 command: [sleep, 3600] --- apiVersion: v1 kind: Pod metadata: name: ping-b spec: nodeName: node-2 containers: - name: alpine image: docker.io/library/alpine:3.18 command: [sleep, 3600]然后kubectl apply -f ping-test.yaml kubectl get pods -o wide kubectl exec -it ping-a -- ping -c 4 ping-b的PodIP如果ping不通先别急着怀疑Calico坏了按下面排查路径顺序看节点安全组是否放行了对应模式所需的协议和端口。每个节点上Pod网段的路由是否正确用ip route查看。隧道设备是否正常存在IPIP模式下应该有tunl0VXLAN模式下应该有vxlan.calico。5.3 只想快速定位时这几条命令最管用看路由表ip route | grep -E tunl0|vxlan.calico如果发现Pod网段的路由指向blackhole说明Felix认为这个网段不可达通常是IPPool配置或节点IP探测出了问题。看Felix核心日志kubectl logs -n kube-system ds/calico-node -c calico-node --tail100 | grep -iE error|fatal看CNI插件日志需要登录到对应节点tail -n 100 /var/log/calico/cni/cni.log这套检查顺序我用了很多次基本能定位99%的安装后异常。6. 复盘四个高频故障的定位路径与处理办法最后这部分我把实际工作中遇到最多的四类故障整理出来每个都按照“现象、定位、处理”的顺序写。这些案例不是理论推演都是我真实踩过或者帮别人排查过的场景。6.1 案例一多网卡节点自动探测选错网卡故障现象集群里某些节点上Calico一切正常但另一台双网卡服务器上的Pod跨节点不通。calico-node显示Running但Felix日志里看到的节点IP是内网管理网IP而不是业务网IP。定位方法查看该节点上Felix启动日志搜索autodetect或Using autodetected IPv4 address确认Calico实际选中的IP地址是哪个网卡的地址。如果选错你会看到这个IP和Kubernetes NodeIP不一致或者这个IP对应的网卡根本不是Pod流量应该走的路径。处理方式在calico-node的DaemonSet环境变量里显式指定探测方式不建议再用自动探测。kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHODinterfaceeth0或者用一个更稳妥的方式kubectl set env daemonset/calico-node -n kube-system IP_AUTODETECTION_METHODcan-reach192.168.1.1can-reach的意思是把192.168.1.1作为目标地址让Calico自动选择能够到达该地址的网卡。这种方式比interfaceeth0更灵活因为不需要关心网卡名是否统一。修改后DaemonSet会滚动重启等Pod起来后再检查一次kubectl get nodes -o wide看节点的InternalIP是否恢复正常。6.2 案例二Pod网段与VPC网段冲突路由越走越歪故障现象集群基础功能正常Pod能创建但某些集群外服务访问不通或者集群内访问VPC内其他资源时延居高不下。定位方法在节点上执行ip route如果看到包含VPC内网IP段的明细路由被指到tunl0或vxlan.calico几乎可以断定是Pod网段和VPC网段重叠了。Calico会把去往这些IP的流量封装进隧道而底层VPC网络又会根据路由表把包直接转发到真实地址两套逻辑冲突结果就是路由黑洞或绕路。处理方式如果集群还在初始化阶段最稳妥的办法是重新规划网段把Pod网段改成一个和VPC完全不重叠的地址段比如172.16.128.0/17修改kubeadm参数和Calico的CALICO_IPV4POOL_CIDR后重新部署。如果集群已经跑了一段时间修改IPPool属于高危操作必须谨慎。建议先排空工作负载再删除旧IPPool并创建新IPPool。一个参考步骤是kubectl delete ippool default-ipv4-ippool然后创建新池apiVersion: crd.projectcalico.org/v1 kind: IPPool metadata: name: default-ipv4-ippool spec: cidr: 172.16.128.0/17 ipipMode: Never vxlanMode: Always natOutgoing: true同时更新Calico节点环境变量CALICO_IPV4POOL_CIDR为新网段否则节点会重新创建默认池。整个操作期间网络会中断最好在维护窗口执行。6.3 案例三Flannel残留的CNI配置让Calico一直卡初始化故障现象calico-node的install-cni容器反复重启日志提示CNI配置目录里已经存在其他CNI的配置或者干脆报错找不到/etc/cni/net.d/10-calico.conflist。定位方法登录异常节点查看CNI配置目录ls -l /etc/cni/net.d/如果发现10-flannel.conflist、cni0.conflist等其他CNI写入的文件说明之前装过其他网络插件残留配置没有清理干净。处理方式把旧CNI配置全部清掉并重启kubelet。systemctl stop kubelet rm -f /etc/cni/net.d/* systemctl start kubelet如果集群里还挂着旧的Flannel DaemonSet一并通过kubectl delete ds kube-flannel-ds -n kube-flannel删掉否则kubelet和CNI目录可能被再次写入。这个案例非常典型。很多用户喜欢先试Flannel不行再换Calico中间如果没有彻底清理Calico的install-cni容器就会一直启动失败。6.4 案例四额外开启Typha后小集群反而出现不稳定故障现象如果按照某些官方文档额外启用了Typha但在二三十台节点的小集群里反而出现calico-node节点状态频繁抖动、Felix周期性reload的情况。定位方法查看Typha和后端连接日志kubectl logs -n kube-system deploy/calico-typha --tail50如果看到大量connection reset、context deadline exceeded之类的错误说明Typha与API Server或Calico节点之间的长连接不稳定。处理方式小集群真的不建议开Typha。Typha的设计初衷是应对大规模集群中每个节点都直连API Server的压力二三十台节点的环境下API Server负载完全可控多一层Typha反而增加故障点。如果用的是单文件manifest方式安装不用额外操作默认就没开Typha。如果是通过Operator安装可以在配置里显式关闭Typha或者调整副本数为0。如果已经单独部署了Typha直接删除对应Deployment和Service并在Calico节点上清除TYPHAA相关环境变量FELIX_TYPHAENABLED设为false保存配置后滚动重启Calico节点即可。这里我想多说一句不要因为某个组件听起来“高级”就盲目启用一切以集群规模和实际需求为准。Calico本身就足够轻量小集群安安静静跑单文件manifest反而最稳定。回头再看这次安装过程其实真正解决问题的思路很简单先保证镜像分发链路通畅再统一替换manifest最后按部就班验证网络。只要把这套路径沉淀成脚本和配置模板以后不管在哪个region、哪批节点上装Calico都能避免反复踩同样的坑。我自己现在装新集群时都会把calico-images.txt、替换后的YAML、节点加速器配置模板一起放进内部Git仓库后续扩容或新集群复用基本不碰外网。这个习惯帮我省下的时间远比第一次写脚本多得多。
