1. 为什么选ARM架构跑K8s以及V1.30.6这版有什么不一样先聊点背景。我们团队最早接触ARM架构的Kubernetes集群是因为一批服务器换成了华为鲲鹏920另外还混了一部分Ampere Altra的实例。坦白说最开始并不是我们主动想往ARM上迁而是新型号的机器就只有ARM核跑x86镜像全部拉不下来才被逼着把整套容器平台往ARM生态上搬。结果真跑起来才发现ARM架构做K8s集群这件事性价比和能耗比都相当能打尤其是承载一些中低并发的微服务、内部系统、CI流水线完全不虚同价位的x86节点。但ARM集群部署有个很现实的问题网上的教程七成还停留在用kubeadm部署amd64集群的思路上直接把命令抄过来镜像一拉就报image pull failed或者干脆init阶段就卡死。我在部署V1.30.6的时候踩了不少这类坑所以这次把完整的kubeadm部署ARM架构Kubernetes V1.30.6的流程整理出来重点讲清楚跟x86有什么不同、哪些地方必须单独处理以及遇到故障怎么定位处置。这篇内容适合三类读者一是刚拿到ARM服务器准备搭K8s的运维新手二是已经会用kubeadm搭x86集群、现在要迁移到ARM平台的工程师三是被镜像架构问题折磨到怀疑人生的友军。先说说V1.30.6这个版本本身。Kubernetes从1.29开始就全面引入了更成熟的multi-arch镜像支持到了1.30这一代控制面组件kube-apiserver、kube-controller-manager、kube-scheduler都已经原生提供linux/arm64的镜像。也就是说如果直接从官方registryregistry.k8s.io拉镜像kubeadm自己是知道该拉arm64版本的这个问题已经不像早期版本那么痛苦了。麻烦的是另外两个点第一如果你的集群环境访问不了registry.k8s.io需要配置代理或者镜像仓库那么代理和镜像仓库本身得支持多架构转发否则拉下来的可能还是amd64的包第二pod网络插件、CoreDNS、Metrics Server这些配套组件很多老版本的镜像没有arm64 tag必须选对版本。这两块我会在后面专门展开。另外Kubernetes 1.30里kubeadm的默认行为也有一些变化比如kubelet证书轮换的默认配置更严格etcd的存储版本默认v3--cri-socket参数如果不显式指定kubeadm会自动探测containerd的socket路径。这些变化在ARM平台上和x86平台上是同样的行为但排查问题时要注意版本相关特性别拿1.24时代的经验硬套。2. 环境规划ARM节点选型、操作系统和网络的基础准备先把机器准备好。ARM架构的服务器现在主要就那么几条线华为鲲鹏920系列、Ampere Altra系列、飞腾系列还有云厂商提供的ARM云主机对应AWS的Graviton阿里云的倚天710华为云的鲲鹏云主机等。如果你拿树莓派4B这类开发板来玩流程是一样的只是性能和内存上限不同部署单节点实验集群或者简单的双节点集群是足够的。操作系统这里必须多说一句。网上搜“arm版centos下载”的人很多但我个人强烈不建议在生产环境用CentOS跑ARM架构的K8s集群。不是CentOS不好而是CentOS对ARM核的优化和兼容性测试明显不如Ubuntu和Debian尤其是内核模块、驱动、cgroup版本配合这块踩坑概率太高。我用的系统是Ubuntu 22.04 LTSaarch64版本内核版本默认5.15配合Kubernetes 1.30.6完全没问题。如果团队里习惯DebianDebian 12也很好。RHEL系比较适合的替代是Rocky Linux 9ARM版做得还行但下面所有命令基于Ubuntu/Debian的apt包管理。2.1 节点配置建议我自己实验环境的配置清单如下你可以直接参考角色主机名配置系统数量控制面k8s-master-arm4核 / 8GB内存 / 100GB磁盘Ubuntu 22.04 aarch641工作节点k8s-node-arm-014核 / 8GB内存 / 100GB磁盘Ubuntu 22.04 aarch641工作节点k8s-node-arm-024核 / 8GB内存 / 100GB磁盘Ubuntu 22.04 aarch641如果是单节点集群可以在控制面节点上允许调度Pod也就是去掉control-plane的taint。这个我后面会讲。纯学习用途2核4G内存的配置也跑得动就是不要期望它能同时扛多少Pod。2.2 基础系统配置IPv4转发、内核模块、主机名解析无论底层是不是ARM基础配置都是那套三板斧但因为有后续容器网络的要求一个都不能漏。# 修改主机名建议每个节点设置有意义的名字 sudo hostnamectl set-hostname k8s-master-arm # 打开IPv4转发桥接流量走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 EOF sudo sysctl --system# 验证模块加载成功 lsmod | grep br_netfilter # 输出里能看到 br_netfilter 就说明OK这里有一点容易漏ARM平台的Ubuntu 22.04默认可能没加载br_netfilter如果你不先 modprobe 再写sysctl后面Calico或者Flannel建虚拟网卡时会报iptables: No chain/target/match by that name这类错误。检查的话用lsmod | grep br_netfilter如果没输出就用上面的modprobe命令加载。另外建议把各节点的IP和主机名写到/etc/hosts。虽然kubeadm会自动处理很多通信但工作节点join的时候如果hostname解析不了kubelet注册会异常慢甚至出现明明join成功了控制面却看不到节点的尴尬情况。# 以实际IP为准这个假设是内网地址 cat EOF /etc/hosts 192.168.31.101 k8s-master-arm 192.168.31.102 k8s-node-arm-01 192.168.31.103 k8s-node-arm-02 EOF2.3 关闭swap与Setenux/防火墙处理沿用K8s传统swap必须关开启swap kubelet会拒绝启动。kubelet从1.24以后默认不支持swap即使到了1.30官方仍然推荐关掉swap以获得稳定的性能模型。sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab防火墙方面Ubuntu默认的ufw如果是关闭状态就不用管。如果有ufw或者iptables规则策略建议放行这几个端口服务端口kube-apiserver6443etcd2379-2380kubelet10250NodePort服务30000-32767flannel/Calico VXLAN8472/4789最省事的做法是测试环境直接关掉防火墙内网隔离好的情况下问题不大。生产环境按需精确放行不要偷懒全开安全底线还是要守。3. 安装containerd运行时ARM架构最容易翻车的第一关Kubernetes从1.24版本开始就没收掉了docker-shimCRI运行时基本上就是containerd和CRI-O二选一。我用的是containerd这个在ARM平台支持度最好、社区材料最多。安装containerd的时候有个经典坑直接apt install containerd装出来的版本往往偏老尤其Ubuntu 22.04自带的containerd是1.6.x某个小版本虽然理论上也能用但建议装新一点的版本Kubernetes 1.30V1.30.6要求CRI兼容版本范围如果containerd太老kubelet会告警甚至无法连接。3.1 安装containerd的推荐方式官方推荐用Docker官方的apt源来安装containerd这个源里面有各架构的包ARM64完全没问题sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg # 添加Docker官方GPG key sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod ar /etc/apt/keyrings/docker.asc # 添加软件源注意这里的archarm64是重点 echo \ deb [archarm64 signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y containerd.io注意看上面source列表里我特意写了archarm64这是必须的。如果你从x86机器上直接复制source列表而不改架构apt会找不到arm64的包然后报错。装完以后检查版本containerd --version # 我这里输出的是 containerd containerd.io 1.7.223.2 修改containerd配置SystemdCgroup必须开启containerd默认配置对Kubernetes是不友好的cgroup驱动不对会导致kubelet和containerd互相打架。直接用下面的方法生成并修改默认配置sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml然后编辑/etc/containerd/config.toml重点修改两处。第一处是SystemdCgroup从false改成truesudo sed -i s/SystemdCgroup false/SystemdCgroup true/ /etc/containerd/config.toml有些教程会让你同时把sandbox_image改成registry.k8s.io/pause:3.9或者类似地址原因是你拉不下来pause镜像时kubelet无法启动Pod。这里要注意1.30.6默认的pause镜像版本是3.10但无论哪个版本优先保证你的节点能访问registry.k8s.io如果访问不了这里就要改成你私有仓库的pause镜像地址。还有第二处值得检查如果你要通过代理访问镜像仓库要知道containerd本身不读https_proxy环境变量。要么在systemd的service里配HTTP_PROXY要么在config.toml里给registry单独配。这个细节经常被忽略结果就是docker能拉镜像kubeadm拉镜像却超时。配置修改完重启containerdsudo systemctl restart containerd sudo systemctl status containerd3.3 ARM平台上containerd拉镜像的架构行为很多人以为containerd会自动拉arm64架构的镜像实际上它根据节点本身的架构选择镜像架构。如果镜像仓库帮你处理了manifest list多架构镜像索引那确实自动选对但如果你配置了镜像仓库mirror而后端镜像源只同步了amd64的tag那就拉错了。这是我排障过程中遇到频率最高的一个点。验证方式很直接手动拉一个官方pause镜像看看返回的架构sudo crictl pull registry.k8s.io/pause:3.10 sudo crictl inspecti registry.k8s.io/pause:3.10 | grep -i arch # 期望输出 arch: arm64如果输出是amd64说明镜像源或者代理配置有问题后面kubeadm init基本必挂。4. 安装kubeadm、kubelet、kubectl固定版本避免意外升级Kubernetes官方从1.28开始把deb仓库迁移到了pkgs.k8s.io老的apt.kubernetes.io已经停止更新。这块网上教程版本很混乱有的还在用旧源新版本装不上。4.1 添加Kubernetes官方apt源# 安装必要的工具 sudo apt-get install -y apt-transport-https ca-certificates curl gpg # 下载Kubernetes新源GPG key sudo curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key \ | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg # 添加源注意这里的架构路径是自动识别的ARM64也能正确匹配 echo deb [signed-by/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ \ | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update这里顺带解释一下为什么不用apt install kubelet就完事。kubeadm安装K8s集群有一个铁律kubeadm、kubelet、kubectl三个组件的版本必须严格一致大版本不一致直接不给初始化小版本不一致也容易出现控制面与节点行为不一致的问题。所以必须指定版本号sudo apt-get install -y kubelet1.30.6-1.1 kubeadm1.30.6-1.1 kubectl1.30.6-1.1Deb仓库的版本号后面会带-1.1这种额外后缀这是上游对每个版本做的revision标记复制时不要漏掉。如果报找不到这个版本可以先apt-cache policy kubeadm看看源里有哪些版本。4.2 锁版本防止误升级虽然在这个仓库里跑apt upgrade大概率不会自动升级K8s组件但为了安全还是建议把版本钉死尤其是生产环境sudo apt-mark hold kubelet kubeadm kubectl以后要升级K8s版本时先unhold再操作升级完成后再次hold。这算是一个朴素的运维习惯但是真能挡住很多手滑。5. kubeadm init的关键参数与arm镜像适配开始初始化之前先把kubeadm当前的配置看一眼确认默认拉取的镜像架构思路kubeadm config images list输出里能看到一长串registry.k8s.io/kube-apiserver:v1.30.6这样的镜像清单。这时你可以跑kubeadm config images pull --image-serialtrue预拉镜像提前暴露网络或架构问题。这个小步骤能节约init失败后再逐条排查的时间。5.1 init命令的推荐写法sudo kubeadm init \ --apiserver-advertise-address192.168.31.101 \ --control-plane-endpointk8s-master-arm \ --pod-network-cidr10.244.0.0/16 \ --kubernetes-versionv1.30.6 \ --image-repositoryregistry.k8s.io几个参数逐个解释--apiserver-advertise-address指定API Server对外监听的IP如果是多网卡机器不指定的话kubeadm会自己挑一个经常挑错。--control-plane-endpoint多个控制面节点时这里一般填负载均衡器或虚拟IP单控制面节点直接填主节点hostname。--pod-network-cidr这个CIDR必须跟你后面选的CNI插件匹配。用Flannel默认就用10.244.0.0/16用Calico可以用192.168.0.0/16建议一开始就规划好改起来很麻烦。--image-repository默认就是registry.k8s.io。如果你有内网镜像仓库比如registry.local:5000就把这里改成内网仓库。但这里有个ARM的大坑——内网仓库里的K8s控制面镜像如果只同步了amd64架构那init依然会挂。所以走私有仓库之前务必确认仓库支持multi-arch。5.2 镜像仓库选择直连、代理还是私有仓库如果你的机器能直接访问registry.k8s.io那init过程最省心arm64架构镜像会自动拉取。如果访问不了通常的做法是让containerd走HTTP代理。在/etc/systemd/system/containerd.service.d/http-proxy.conf里配置[Service] EnvironmentHTTP_PROXYhttp://proxy.example.com:3128 EnvironmentHTTPS_PROXYhttp://proxy.example.com:3128 EnvironmentNO_PROXYlocalhost,127.0.0.1,10.244.0.0/16,192.168.0.0/16然后systemctl daemon-reload systemctl restart containerd。注意NO_PROXY里必须包含Pod网段、Service网段、节点网段否则K8s内部的健康检查流量也会走代理导致Pod一直不能Ready。5.3 init完成后必做的三件事init成功后会输出一段重要信息包含kubeconfig路径和join令牌。标准配置mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config这里建议把admin.conf备份一份后续管理集群的CI/CD系统都会用到这个文件cp /etc/kubernetes/admin.conf ~/admin.conf.bak然后要看一看集群状态——但注意这时集群还没装CNI网络插件所以节点状态是NotReady这非常正常kubectl get nodes # NAME STATUS ROLES AGE VERSION # k8s-master-arm NotReady control-plane 1m v1.30.66. 给控制面挑选合适的CNI插件Flannel与Calico的arm支持对比CNI插件是ARM集群里最容易出问题的第二个环节。很多旧版本的CNI不提供arm64镜像或者提供的镜像有bug导致Pod网络无法工作。我的经验是控制面节点和工作节点全是ARM架构的小规模集群优先选Flannel简单直接如果集群规模大、需要NetworkPolicy隔离策略就选Calico。V1.30.6 Ubuntu 22.04 aarch64的组合这两个插件都有官方arm64镜像。6.1 用Flannel快速打通Pod网络Flannel对ARM的支持一直不错安装命令跟x86完全一致kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml如果GitHub的raw地址访问不了可以先把yaml下到本地再applywget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml kubectl apply -f kube-flannel.yml这里有个经验不要直接在kubectl apply -f后面接GitHub地址来使用helm之类的包管理工具链——因为有些同学那台机器上没有wget或curl代理配置直接apply有时候会默默拉取失败。最好是先下到本地grep image: kube-flannel.yml看一眼镜像地址和tag。拉镜像时注意flannel所有组件的镜像名字都带flannel或flannel-cni-plugin正常情况下kubelet启动Pod时会自动按arm64拉取。但我遇到过几个版本内置的cni-plugin镜像tag没有arm64的情况后来统一把flannel升级到最新release版本就解决了。版本锁定建议不要用master分支的yaml用release tag的版本稳定得多。6.2 Calico的arm64镜像注意事项如果要用Calico官方yaml比较大包含几十个资源对象安装命令kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/tigera-operator.yaml kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/custom-resources.yamlCalico从3.25开始对arm64的支持已经很完整了tigera-operator和calico-node都有multi-arch镜像。装完以后检查kubectl get pods -n calico-system我这里不展开Calico的所有功能了因为大多数ARM环境部署K8s是为了中轻量负载NetworkPolicy需求不是刚需。Flannel的overlay网络已经能满足绝大多数场景。6.3 验证CNI是否正常等CNI的Pod都进入Running状态后节点会从NotReady变成Readykubectl get nodes # NAME STATUS ROLES AGE VERSION # k8s-master-arm Ready control-plane 5m v1.30.6如果状态迟迟不变用kubectl describe node k8s-master-arm查看Kubelet的Condition最下面通常写着原因比如network plugin is not ready那就是CNI没有装好。7. 工作节点join选举令牌、证书和ARM架构一致性控制面准备好了以后工作节点加入集群是重头戏。虽然kubeadm join命令看着只是一条命令但工作节点侧也需要完整安装kubelet、kubeadm、containerd少一个都进不来。7.1 工作节点侧重复基础安装工作节点上执行第2节的所有系统配置、第3节的containerd安装、第4节的kubeadm/kubelet/kubectl安装。也就是除了kubeadm init不执行其余全部节点都一样。这里提醒一下如果你在给几十台ARM节点批量部署别一台台手工跑建议把这些命令整理成脚本或者直接用Ansible批量执行一次粘贴比人工逐台输入要稳定得多。7.2 获取join配置在控制面节点上执行kubeadm token create --print-join-command比如输出kubeadm join 192.168.31.101:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx在一个节点上执行它即可。如果你要在控制面加入第二个master需要先拿到证书keykubeadm init phase upload-certs --upload-certs这个key配合--control-plane参数才能join成控制面节点。不过这篇内容主要讲的是单控制面加多工作节点的部署形态多控制面高可用集群需要提前部署负载均衡器操作复杂度会翻倍可以先不着急。7.3 join之后的验证工作节点join后回到控制面看节点列表等一两分钟后就能看到新节点加入kubectl get nodes -o wide观察STATUS列是否为ReadyVERSION是否为v1.30.6以及ARCHITECTURE是否为arm64kubectl get nodes -o jsonpath{range .items[*]}{.metadata.name}{\t}{.status.nodeInfo.architecture}{\n}{end}输出的architecture列必须是arm64如果出现x86_64说明工作节点本身系统装错了跑的可能是x86用户态加ARM内核这种混合环境后面会莫名其妙出一堆问题。7.4 单节点集群去除控制面污点如果你的环境只有一台机器kubeadm init默认会给控制面节点打上污点node-role.kubernetes.io/control-plane:NoSchedule普通Pod不会调度上去。单节点集群需要去掉这个污点kubectl taint nodes --all node-role.kubernetes.io/control-plane-命令最后的破折号表示删除污点。执行后控制面节点就可以运行普通Pod了。8. 验证部署一个小型应用并处理arm镜像适配集群准备好了部署一个测试应用来验证全链路是否正常。这里选nginx做冒烟测试因为它同时提供amd64和arm64镜像能避免镜像问题干扰网络和调度验证。kubectl create deployment nginx-test --imagenginx:1.27 kubectl expose deployment nginx-test --typeNodePort --port80 kubectl get pods -o wide kubectl get svc如果一切正常Pod的STATUS是RunningNODE列显示工作节点IP然后在工作节点上用curl http://localhost:NodePort就能看到nginx默认欢迎页。但如果是生产业务镜像可能就没有这么顺利了。很多内部业务镜像只打了linux/amd64的tag到了ARM节点上直接ImagePullBackOff。排查这个问题的标准姿势kubectl describe pod xxx # Events: # Failed to pull image repo/biz:v1.2: manifest unknown: manifest unknown # The image repo/biz:v1.2 cannot be found in the arm64 repository这种错误基本就是镜像没有arm64版。解决办法有三种一是让开发配合重新构建multi-arch镜像用docker buildx一条命令同时推送amd64和arm64两个架构的manifest二是临时切到模拟层比如在ARM上跑qemu-user来跑amd64的容器但是性能损失大不建议生产用三是把Pod调度到同时预留的x86节点上组成ARM x86混合集群。这三种方案各有适用场景多数团队一开始做不到全量arm64化混合集群反而是最现实的路径。我实际遇到过一个更隐蔽的问题某中间件镜像的manifest列出了arm64拉取也不报错但容器起来后立刻CrashLoopBackOff看日志发现是镜像里的二进制依赖了x86指令集。这种情况只能重建镜像没有捷径。9. 升级https证书与kubelet健康检查的运维排障部署完成不等于万事大吉。K8s集群在运行过程中还有两个高频问题尤其在ARM平台上更为突出证书过期和kubelet健康检查异常。9.1 kubeadm内置证书自动续签Kubernetes 1.30的kubeadm提供了非常贴心的证书生命周期管理。控制面集群证书默认有效期一年但kubeadm会定期自动检查并更新它们在本地被管理的证书。实测下来集群跑半年以上证书续签是静默完成的不需要人工干预。当然你可以手动看一下证书的有效期kubeadm certs check-expiration输出会显示每个证书的剩余时间。如果某些证书确实快过期了但没被自动续签多半是因为kubelet重启过或者配置异常。手动续签的命令kubeadm certs renew all执行完需要重启kubelet和控制面组件。这条路建议只在自动续签失效时使用平时靠它反而不安全。9.2 kubelet健康检查ARM上常见的内存与CPU分配问题Kubelet每10秒会定期向API Server汇报节点状态如果汇报异常节点会被标记成NotReady。我遇到最多的原因是节点内存不足。ARM节点跑容器时个别业务容器会申请超过节点实际可用资源的内存request导致kubelet健康检查连续失败。排查命令kubectl describe node k8s-node-arm-01 # Conditions: # MemoryPressure True看到MemoryPressure为True时说明节点内存紧张。应对办法调整Pod的requests/limits或者清理一些无用的Deployment。这点在ARM小内存节点上尤其需要关注4GB内存跑十几个Pod是极限了不要硬塞。10. 多架构镜像是后期绕不开的主题等集群稳定运行了半个月你会发现ARM集群真正的心智负担不是部署而是业务镜像的arm64适配。团队协作上最有效的做法是建立镜像架构规范所有新业务镜像必须以multi-arch方式构建推送而不是单独构建arm64 tag。这样只要镜像仓库域名不变Pod无论调度到哪个架构的节点都正常。multi-arch镜像的构建其实非常简单是每个镜像维护者都应该掌握的技能docker buildx create --use --name multiarch-builder docker buildx build \ --platform linux/amd64,linux/arm64 \ -t repo/biz:latest \ --push .关键点是--platform只写amd64和arm64两个。有些团队会想连arm32一起构建我不建议。K8s节点跑armhf32位ARM的场景已经非常罕见而且arm32的镜像在arm64节点上需要通过兼容层运行性能损失得不偿失。镜像仓库方面推荐使用Harbor它天然支持存储和转发multi-arch manifest并且在UI上能看到每个镜像的架构列表。如果你用自建的简易Docker Registry版本必须在2.8以上老版本对multi-arch的支持有坑。高可用方面等多控制面节点扩展时需要提前规划负载均衡器。控制面API Server的负载均衡可以用HAProxy加Keepalived或者云厂商的SLB。ETCD集群必须奇数节点三个控制面节点是起步配置。把这些想清楚后面往生产环境扩展就不会手忙脚乱。最后分享一个我个人的部署习惯每次搭建我都会把完整的操作记录写入一个deploy-notes.md包括每台机器的IP、操作系统版本、内核参数、kubeadm init时用到的每个参数、CNI版本。因为K8s集群稍有规模后某次小版本升级或者某个节点重装都很容易跟初始配置不一致有一份集群体检文档排查问题的时间至少缩短一半。ARM集群尤其需要这份文档——毕竟在ARM生态里很多组件的版本兼容关系比x86更微妙记下走过的路能帮你自己和后来的人省下大量试错成本。