1. 为什么在ARM架构下部署K8s值得单独写一篇装过K8s的人应该都有体会从裸机到集群跑起来其实就是一条标准流水线。装容器运行时、初始化控制面、装CNI网络插件、等所有Pod就绪熟手一小时以内可以搞定。但是当你拿到的是一台ARM架构的服务器流水线就可能变成处处碰壁的炼狱。同样的命令x86上没问题ARM上就直接报错或者镜像根本拉不下来。这不是个例而是横在所有ARM部署者面前的普遍痛点。这篇文章要解决的就是这个痛点。标题里有两个关键词ARM架构以及K8s 1.34.5 与 KubeSphere 3.4.1 的组合。ARM架构意味着从操作系统选型、软件源配置、容器运行时到镜像仓库里的每一个镜像都必须有 arm64/aarch64 的版本缺一个就卡壳。Kubernetes 提供底层容器编排能力KubeSphere 3.4.1 则是构建在其之上的企业级容器平台提供可视化运维、多租户、监控日志等功能。两者一起部署实际工作中也大多是为了获得一个开箱即用的容器云管理界面。文章会覆盖两条完整路径一条是在线部署教你从零开始把集群拉起来另一条是离线部署适合内网隔离、没有外网访问权限的生产环境。两条路径都会包含实际操作中验证过的步骤和踩坑记录。适合谁看维护着ARM服务器、准备上K8s的运维做边缘计算或者私有云方案的技术人以及刚拿到一批国产ARM机器、想从零建集群的团队。不管你是第一次接触ARM还是已经在x86上熟练了想迁移这篇内容都能帮你把试错成本降下来。1.1 标题拆解我们要交付什么把标题拆开看任务其实包含三个交付物第一基于ARM架构的Kubernetes 1.34.5集群第二KubeSphere 3.4.1平台第三支持在线安装和离线安装两种交付方式。先说Kubernetes。1.34.5属于当前较新的K8s版本控制面组件kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy都需要对应的v1.34.5二进制而且必须是arm64版本。ARM架构下这些二进制不太好找很多人就是卡在这一步。再说KubeSphere 3.4.1。它本质上不是一个单体应用而是一堆部署在集群里的组件构成包括 ks-apiserver、ks-console、ks-controller-manager以及Prometheus监控栈、Grafana、Elasticsearch日志组件等。安装时不仅要拉KubeSphere本身的镜像还要带上一堆依赖组件镜像离线场景下要准备的材料非常多。最后说在线/离线。在线部署的逻辑是网络可达、软件源可用难点在于拉镜像的速度和版本匹配。离线部署的逻辑是全面隔离任何需要从外网获取的东西都要预先准备好包括系统软件包、K8s二进制、所有容器镜像。两种模式翻车点完全不同我会分别细讲。1.2 在线和离线是两种完全不同的底层逻辑为什么要分开写因为它们的准备思路差异极大。在线部署你只需要一台能访问外部网络镜像仓库的ARM机器给系统配置好软件源装上containerd初始化集群CNI网络起来KubeSphere基本就顺了。最大的变量是网络速度和镜像加速。离线部署就麻烦一点。你得在另一台同样ARM架构且有网的机器上把所有需要的东西导出成文件再搬到目标内网。这包括Kubernetes组件二进制、containerd安装包、系统依赖包、所有相关镜像的tar包缺一样都不行。而且离线环境下无法临时从Docker Hub拉镜像所以必须提前建好私有镜像仓库或者把镜像导入到节点本地。还有一点很多人会忽略离线打包必须在同架构机器上进行。在x86机器上导出的镜像tar包拿到ARM机器上是没法用的。这不是简单的跨平台可执行文件问题而是容器镜像的镜像平台标识就是linux/arm64架构不匹配容器运行时拒绝启动。2. 部署前置要素准备2.1 确认ARM架构与系统环境拿到机器之后第一步不是装软件而是确认CPU架构。执行uname -m输出 aarch64 就说明是64位ARM架构。ARM64和aarch64在绝大多数场景下可以看作同一个概念软件包标识和Docker镜像平台字段里有时候写linux/arm64有时候写linux/arm/v8指的都是同一个目标平台。系统方面基于ARM64的Linux发行版都可以常见的开源选项有Ubuntu ARM版和openEuler具体看你的使用习惯。需要注意的是不同发行版的软件源结构不同对容器运行时和K8s组件的支持程度也不同。有的旧版本系统自带glibc版本过低可能会带不动最新版Kubernetes的二进制所以尽量别用太老的版本。节点规划建议如下表格节点角色主机名配置推荐系统盘说明Masterarm-master4核8G50G SSD跑控制面组件和KubeSphere控制面Worker-1arm-worker18核16G100G SSD跑业务负载和KubeSphere监控组件Worker-2arm-worker28核16G100G SSD跑业务负载和日志组件如果只是测试环境也可以单节点部署把Master和Worker合并。但要做完整功能演示尤其是跑KubeSphere的监控和日志栈建议至少给Master节点分配4核8G否则内存很快会被打满出现各种OOM导致的组件重启。2.2 系统初始化关闭Swap和防火墙这部分和x86上部署K8s的逻辑一致但ARM机器上比较容易遗忘。首先关闭SwapKubernetes从1.8版本开始明确要求节点必须关闭Swap否则kubelet会拒绝启动。编辑/etc/fstab把swap那一行注释掉然后swapoff -a临时关闭。然后关闭防火墙。生产环境当然是按最小权限放行端口但部署阶段建议先关闭系统防火墙排除干扰项。命令是systemctl disable --now firewalld或者用对应发行版的防火墙管理命令。如果是在有安全管控的环境里至少要确保Kubernetes的6443、2379-2380、10250、30000-32767端口互通。还需要加载内核模块。K8s依赖overlay和br_netfilter两个模块前者是容器镜像分层存储的基础后者用于网桥流量经过iptables处理。用下面的命令写入系统配置cat EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter接着写内核网络参数cat EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 vm.swappiness 0 EOF sudo sysctl --system这几个参数尤其重要。net.bridge.bridge-nf-call-iptables保证节点上的iptables规则能作用于容器间的网桥流量不设置的话Service的ClusterIP转发很可能不生效出现跨Pod访问不通的诡异问题。net.ipv4.ip_forward是Pod出网通信的基础缺少它Pod无法访问外网。还有一个容易忽略的点时间同步。Kubernetes集群对时间偏差很敏感尤其多节点场景下如果节点间时间差超过一定阈值etcd会报错kubelet的健康检查也会异常。ARM机器很多没有内置RTC电池开机后时间容易混乱建议部署前安装并启用chrony或者ntp确认timedatectl显示的时间和实际时间一致。3. 在线部署Kubeadm完整流程加KubeSphere 3.4.13.1 容器运行时Containerd的安装与配置先在/etc/apt/sources.list或者yum源里确认一下软件源支持aarch64架构这一点很重要有的第三方源默认只同步了x86_64的包会导致安装containerd时直接报No matching package。官方源和主流开源镜像源基本都已经同步了ARM架构的容器运行时包建议直接使用官方源。安装containerd本身没什么特别的apt install containerd.io或yum install containerd即可。真正的问题是配置。用默认配置在ARM上跑大概率会出问题。安装完成后执行mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml然后重点修改两个地方。第一SystemdCgroup改成true让containerd使用systemd管理cgroup。第二sandbox_image的默认值是registry.k8s.io/pause:3.10但这个地址在很多网络环境访问不了需要改成你本地能访问的镜像仓库地址并且确保这个pause镜像是有linux/arm64平台的版本。修改后的关键配置大致长这样[plugins.io.containerd.grpc.v1.cri] sandbox_image 你的可访问仓库地址/pause:3.10 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true改完配置文件后重启containerdsystemctl restart containerd systemctl enable containerd具体操作不复杂但要注意pause镜像哪怕晚一步配置集群初始化时kubelet会反复创建sandbox失败报Failed to create pod sandbox。而这个问题在网络不可达时极其隐蔽因为NotReady状态会让人先怀疑kubelet配置实际上就是初始化容器的镜像拉不下来。3.2 安装Kubeadm、Kubelet、Kubectl这里的主版本必须跟目标集群版本一致也就是v1.34.5。用软件源安装时先锁定版本号apt-get install -y kubelet1.34.5-00 kubeadm1.34.5-00 kubectl1.34.5-00ARM架构下安装这三件套时同样要确认软件源。装完之后需要让kubelet开机自启但不让它自动启动因为还没有初始化集群直接启动会报错apt-mark hold kubelet kubeadm kubectl systemctl enable kubeletapt-mark hold是为了避免后面apt upgrade把版本升级导致和文档不一致。我在实际部署中发现版本漂移是集群出各种兼容性问题的重要来源锁定版本是很有必要的习惯。3.3 用Kubeadm初始化控制面初始化之前先拉取控制面镜像。这一步能提前发现网络问题避免在init过程里卡住。可以用kubeadm直接拉kubeadm config images list --kubernetes-version v1.34.5 kubeadm config images pull --kubernetes-version v1.34.5 --image-repository xxx--image-repository用于指定镜像仓库地址如果你的网络访问registry.k8s.io不通就换成可访问的公共镜像仓库地址。注意仓库里的镜像必须包含arm64版本否则pull阶段会提示manifest unknown。拉完镜像开始初始化。典型命令如下kubeadm init \ --apiserver-advertise-address192.168.1.11 \ --kubernetes-version v1.34.5 \ --pod-network-cidr10.244.0.0/16 \ --service-cidr10.96.0.0/12--pod-network-cidr这个网段要跟CNI插件的默认网段匹配不同CNI插件的默认网段不一样。以Calico为例它的默认网段通常是192.168.0.0/16而Flannel默认是10.244.0.0/16。我在自己的环境里习惯用10.244.0.0/16搭配Flannel或者192.168.0.0/16搭配Calico避免后面手工调整网络配置。这里以10.244.0.0/16为例后面选Flannel或者Calico时都需要对应调整。执行成功后终端会输出三部分内容kubeconfig配置命令、join token命令、以及安全提示。kubectl的配置文件是这样的mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config执行完后可以用kubectl get nodes查看Master节点此时状态应该是NotReady因为CNI网络插件还没装这个是预期的。3.4 安装CNI网络插件Kubernetes本身不提供Pod间网络通信方案需要装CNI插件。推荐看场景Calico功能全面支持NetworkPolicy适合生产Flannel简单轻量适合快速验证。安装Calico时直接用官方提供的manifest文件kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml官方manifest是multi-arch的在ARM节点上会自动拉取对应的arm64镜像所以只要镜像能拉到节点网络就会自动就绪。如果网络环境不好可以先把calico.yaml下载下来把里面的image地址改成私有仓库地址再kubectl apply。在ARM架构下有个常见坑Calico默认使用的bird进程和VXLAN模式对内核模块有要求少数精简版内核没有编译相应的overlay模块会导致Calico Pod起不来。遇到这种情况检查节点的dmesg日志有没有相关报错然后选择换成IPIP模式或Flannel的VXLAN。等Pod状态全部Running后Master节点状态会变成Readykubectl get nodes3.5 Worker节点加入Worker节点只需要安装containerd、kubelet和kubeadm然后执行Master初始化时输出的join命令即可kubeadm join 192.168.1.11:6443 --token xxxx --discovery-token-ca-cert-hash sha256:xxxx如果token过期在Master上重新生成kubeadm token create --print-join-command在ARM架构下经常遇到的一个问题是Worker节点跟Master节点镜像仓库配置不一致导致初始化Pod拉镜像失败。不管你是几台Worker都要保证containerd的sandbox_image配置一致这个步骤不能省。3.6 安装KubeSphere 3.4.1KubeSphere的在线安装比较简单它提供了一套基于Kubernetes原生资源的安装方式。先安装核心配置文件kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.4.1/kubesphere-installer.yaml kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.4.1/cluster-configuration.yaml第一条命令会创建KubeSphere需要的Namespace、CRD和Controller。第二条命令会创建一个ClusterConfiguration对象它告诉安装器要启用哪些组件比如监控、日志、告警等。实际项目中可以根据机器配置剪裁如果只有4核8G的Master建议先只启用核心功能监控日志组件后续再开不然内存很容易被撑爆。安装过程会持续几分钟到十几分钟不等取决于镜像拉取速度。查看进度kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l appks-install -o jsonpath{.items[0].metadata.name}) -f等全部Pod Running后拉取控制台服务kubectl get svc -n kubesphere-system ks-console默认情况下KubeSphere控制台通过NodePort暴露端口通常是30880。初始管理员账号是admin初始密码在较新版本中一般是P88w0rd首次登录后会强制要求修改。建议登录后立刻把默认密码改掉并把账号绑定到平台内置的多因子认证上。4. 离线部署没有互联网也能交付集群4.1 离线方案整体介绍离线部署的核心是物料准备。在线部署是实时从网络上拉取组件和镜像离线部署则要求你提前把所有组件和镜像打包成一个文件搬到目标环境后解压、导入、安装。相比在线部署离线多出来的工作量都在准备阶段。工程上常用的离线部署组件是KubeKey。它可以做到一条命令同时处理Kubernetes和KubeSphere的安装。KubeKey会把以下内容打包到artifact文件里Kubernetes组件二进制、etcd二进制、containerd安装包、所有相关容器镜像以及KubeSphere安装所需的各类chart和CRD。在目标机器上导入artifact之后再执行集群创建命令它就不需要访问任何外部网络。离线部署最适合的场景包括政务或企业内部完全隔离的网络环境、客户现场不允许外联的生产环境、以及依赖公网不稳定导致在线安装反复失败的边缘机房。4.2 在联网的ARM准备机上生成离线物料准备机必须是ARM架构可以是云上的一台arm64虚机也可以是你本地的一台同架构服务器。至于为什么要同架构前面已经讲过就不再重复了。首先下载KubeKey。在arm64机器上需要下载的是arm64版本的kk二进制。下载完成后赋予可执行权限并移到系统路径chmod x kk sudo mv kk /usr/local/bin/下一步是生成manifest。manifest是离线打包的清单文件它声明了要导出的版本和组件范围kk create manifest --k8s v1.34.5 --with-kubesphere v3.4.1执行后会生成一个manifest.yaml文件它里面定义了要打包哪些镜像仓库、哪些组件版本。在ARM机器上生成的manifest会自动带arm64的架构标识不需要手工改。如果需要修改镜像仓库为内网仓库可以编辑manifest里的仓库配置项把所有镜像的仓库前缀改成目标内网仓库地址这样后续安装时就无需再调整。接着导出artifactkk artifact export -m manifest.yaml -o k8s-kubesphere-arm64.tar.gz这条命令会做两件事下载所有Kubernetes和KubeSphere相关镜像并拉取Kubernetes和etcd二进制然后打包到单个tar.gz文件里。文件大小通常在2到4GB之间取决于启用的组件数量。导出过程最耗时网络好也要等一段时间建议在磁盘空间充裕的机器上操作导出前先df -h确认空间足够。导出完成之后把artifact文件和接下来要用的配置文件一起拷贝到离线环境的跳板机上。4.3 在目标内网导入镜像仓库离线机器上需要准备两样东西一是刚才导出的artifact包二是一个可用的私有镜像仓库。你可以选择在企业内网已有的镜像仓库也可以直接在目标节点上启动一个registry服务。KubeKey提供了一个导入命令可以直接把artifact里的镜像导入到节点的本地containerd里kk artifact import -m manifest.yaml -o k8s-kubesphere-arm64.tar.gz这个命令会在本机启动一个临时容器仓库服务把镜像全部加载进去然后后续集群创建时就从本地这个仓库拉取。如果你的目标环境有多台节点就需要把artifact分发到每一台节点上分别执行导入或者搭建一个能被所有节点访问的私有镜像仓库。生产环境建议选择后者。在有网准备机上提前把镜像推送进私有仓库然后在目标环境修改所有节点的containerd配置指向该仓库地址。KubeKey的离线安装虽然支持节点本地仓库但多节点环境下同步artifact文件还要考虑磁盘空间和传输时间不如统一仓库来得干净。4.4 离线创建集群并带上KubeSphere在目标环境先写好集群配置文件。最简单的方式是先生成一个默认配置kk create config --with-kubesphere v3.4.1然后修改生成的config.yaml把节点IP、角色、SSH账号密码、主机名等信息填进去。单节点测试下只保留一个masterworker节点即可。关键配置项包括apiVersion: kubekey.kubesphere.io/v1alpha1 kind: Cluster metadata: name: arm-cluster spec: hosts: - { name: master1, address: 192.168.1.11, internalAddress: 192.168.1.11, user: root, password: 你的密码, arch: arm64 } - { name: worker1, address: 192.168.1.12, internalAddress: 192.168.1.12, user: root, password: 你的密码, arch: arm64 } roleGroups: etcd: - master1 control-plane: - master1 worker: - worker1 controlPlaneEndpoint: ip: 192.168.1.11 domain: cluster.local kubernetes: version: v1.34.5 imageRepo: 你的私有仓库地址 registry: plainHTTP: true privateRegistry: 你的私有仓库地址注意arch: arm64这个字段KubeKey依赖这个字段判断节点架构。如果填错成amd64后面拉镜像会匹配到x86版本节点直接起不来。配置无误后离线创建集群kk create cluster -f config.yaml --with-kubesphere v3.4.1安装器和kubelet会在节点上逐步执行导入二进制、初始化containerd、创建etcd、启动控制面、安装CNI、部署KubeSphere组件。整个过程不需要外网。因为镜像已经导入所以也不会卡在ImagePull阶段。等输出日志中出现控制台访问信息就说明安装完成。同样的默认端口30880访问控制台默认账号密码跟在线安装一致。5. ARM架构下的典型坑点与调优5.1 镜像架构不匹配是最隐蔽的问题在线安装时Pod报ImagePullBackOff很多人第一反应是网络问题或者镜像不存在但ARM环境里最常被忽视的是架构不匹配。判断方法很简单在Node上手动拉镜像时会看到类似提示crictl pull your.registry.com/xxx:v1.34.5如果镜像仓库里只有linux/amd64的镜像拉取时会返回manifest unknown。有些镜像设置了multi-arch索引会自动拉arm64有些镜像没有那就会报错。所以在准备镜像时尽量用docker manifest inspect或者crane manifest检查目标镜像是否包含linux/arm64平台。这个坑在离线部署里更致命因为离线包生成时如果拉了amd64镜像目标机器上根本发现不了直到Pod起不来才会暴露。我自己的做法是在准备机上完成artifact导出后随便挑几个关键镜像比如pause、kube-apiserver、calico-node通过crictl检查镜像的平台字段确认都是arm64之后才开始搬运。5.2 系统软件源和glibc兼容性ARM机器上安装系统依赖包最容易出问题的就是软件源。很多第三方软件源只同步了x86_64的包执行apt或yum安装的时候会报404或者找不到包。解决方式直接换成官方源或者支持aarch64的公共镜像源。另一个问题是glibc版本。新版本Kubernetes的二进制对系统的glibc版本有要求如果系统比较老运行kubelet时会报version GLIBC_2.32 not found遇到这种问题不要试图手动升级glibc太容易把系统搞崩。正确做法是选择新一点的系统镜像重新部署比如把系统替换为较新的长期支持发行版。5.3 Calico和Flannel在ARM上的选择CNI插件选择上我在ARM环境更倾向于Flannel或者Calico的VXLAN模式。原因很简单ARM节点尤其在多租户环境中网络性能比x86要敏感Overlay封装的开销更大。Flannel的VXLAN实现比较轻量对ARM的支持也稳定。Calico的eBPF数据面在较新的内核上才支持而且ARM上对eBPF的适配不如x86成熟使用默认iptables模式时性能还行但配置复杂度略高。如果内网环境万兆以上MTU设置不正确直接导致Pod间大包通信异常出现TCP传输慢、小包正常大包卡住的现象。解决办法是手动调整Calico的MTU参考物理网卡MTU减去VXLAN封装头开销。5.4 内核参数与内存分配调优ARM设备做K8s节点时内存通常比x86同价位服务器紧张。跑KubeSphere时最直观的感受是Prometheus组件非常吃内存。KubeSphere默认的监控栈会占用大约2到3GB内存如果Master节点只有8GB光控制面组件就接近临界值。建议在安装KubeSphere时在cluster-configuration.yaml里裁剪组件。比如先不启用日志组件减少Elasticsearch的副本数或者调整Prometheus的存储保留时长从默认7天改成2天。保留30到60天的监控数据是后期需求初期先把集群跑稳更重要。内核参数方面在原有K8s标准参数基础上我习惯追加以下内容net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 fs.file-max 1048576net.core.somaxconn调整的是Pod内高并发连接队列长度特别是跑七层代理或网关类应用时默认值128会明显限制接入能力。fs.file-max则需要跟节点内存匹配防止高并发场景下出现toomany open files。5.5 证书过期与版本锁定的提醒Kubernetes默认签发的一年期证书集群跑了一年之后控制面和Kubelet通信证书就会陆续失效。节点会慢慢变成NotReadykube-apiserver日志里报证书过期。在ARM集群里处理方式跟x86一样执行kubeadm certs renew all然后重启控制面组件。注意证书续期的前提是集群还能正常访问如果已经过期到完全不可用的状态就要手动备份etcd后重新初始化。为了避免这种局面建议从一开始就写好证书到期的监控告警。另外ARM环境里更要注意容器运行时的版本锁定。containerd升级有时会改变配置兼容行为一旦集群稳定就不要频繁升级。每升一个主版本先在一台非生产节点上验证避免全线升级导致集群雪崩。6. 常见问题速查表6.1 部署阶段排查清单下面表格里的内容是我在ARM部署过程中实际遇到过的典型问题和处理方式直接照着排查可以省很多时间现象可能原因排查和处理kubeadm init一直拉镜像失败镜像仓库地址不通或缺arm64镜像先kubeadm config images pull单独测试仓库不通就换可访问地址并配置containerdkubelet报sandbox创建失败pause镜像地址不可达或用了amd64平台检查containerd的sandbox_image配置确保是arm64的pause镜像节点状态一直是NotReadyCNI网络插件未装或装错检查是否有calico/flannel pod在Running否则查看kubelet日志定位网络模块Calico Pod反复重启系统内核缺少overlay模块或MTU配置不对dmesgCoreDNS一直Pending或CrashLoop节点DNS配置错误或宿主机resolv.conf包含无效DNS调整节点DNS设置检查CoreDNS配置中upstreamNameserverWorker节点加入后无法就绪kube-proxy或CNI daemonset没有调度到该节点kubectl get pod -A -o wide看worker上的关键Pod排查镜像和调度标签KubeSphere控制台无法访问ks-console svc未Ready或端口被防火墙挡查看ks-console svc的NodePort确认Pod全部Running防火墙放行端口Pod创建很慢卡在ContainerCreatingVolume插件或镜像拉取慢确认存储相关组件运行正常镜像提前导入到本地containerd6.2 运行阶段优化建议集群稳定运行后建议做几件事。第一把kubectl get nodes的节点状态做成监控告警第二定时检查证书过期时间提前续期第三定期清理容器镜像的悬空tag避免本地磁盘被堆积镜像占满。镜像GC方面containerd默认会在磁盘使用率达到85%时触发回收但回收策略比较保守有时候GC不彻底。可以在crictl层面手动清理异常Pod和残留镜像crictl rmi --prune还有一个细节是日志轮转。容器日志如果不做轮转长时间运行会写满系统盘。Kubernetes的kubelet可以配置日志轮转参数在/etc/sysconfig/kubelet里加上KUBELET_EXTRA_ARGS--container-log-max-files5 --container-log-max-size100Mi这个配置会限制单个容器日志文件大小和最大文件数在ARM机器上尤为重要因为ARM设备本地磁盘通常比x86服务器小日志打满盘之后整个节点会进入异常状态Pod会被拉走排查起来非常被动。在长期运行的大型集群里建议逐步引入集群层面的监控和日志方案把节点日志统一收集到中心化存储具体工具按团队现有技术栈选就好。我个人在实际部署中的体会是ARM架构的K8s集群没有幸存者偏差只要在准备阶段把架构确认、镜像平台验证、软件源配置三关过好后面其实跟x86差别不大。但如果这三关有一关没守住后续排查的时间往往是最初部署时间的几倍。最后再分享一个小技巧在一开始部署时就把集群配置文件和离线artifact文件归档好标注清楚版本号和架构平台很多看起来玄乎的环境问题最后都是因为版本不一致导致的归档做得好问题能少一半。