在华为云欧拉（openEuler）ARM64架构上部署Kubernetes，必须使用原生aarch64版本的kubelet、containerd、CNI插件及镜像，提前加载br_netfilter/ip_vs等内核模块，禁用SELinux和swap，配置containerd启用systemd-cgroup，并指定ARM兼容的镜像仓库与版本，否则将出现exec format error、NotReady或CoreDNS崩溃等问题。
直接说结论：在华为云欧拉（openEuler）上装 Kubernetes，别硬套 x86 教程，ARM64 架构下必须确认所有组件原生支持 aarch64，且容器运行时、CNI 插件、kubelet 二进制都得是 ARM 版本。否则会卡在 exec format error、image not found 或节点 NotReady。
确认 openEuler 版本与内核模块是否就绪
openEuler 22.03 LTS（含 SP1/SP3）是当前最稳妥的选择，但 SP 版本间内核模块加载行为有差异：
必须提前加载
br_netfilter和ip_vs系列模块，否则 kube-proxy IPVS 模式启动失败-
/etc/modules-load.d/k8s.conf中要显式列出：br_netfilter ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack
验证方式：
lsmod | grep -E 'br_netfilter|ip_vs'，缺任何一个都可能导致 Calico/Flannel 启动后 Pod 网络不通openEuler 默认启用
SELINUX=permissive，但 kubeadm 要求彻底禁用（SELINUX=disabled），仅setenforce 0不够，重启后会恢复swap 必须永久关闭：
swapoff -a+ 注释/etc/fstab中所有 swap 行，否则kubeadm init直接报错
containerd 替代 Docker 是更稳的选择
华为云欧拉默认不预装 Docker，且社区版 Docker 对 aarch64 的维护滞后（比如 24.x+ 版本在某些 SP3 内核上 cgroupv2 兼容性差）：
推荐用系统自带的
containerd（openEuler 22.03 自带 1.6+，满足 k8s 1.28+ 要求）-
关键配置项必须设对：
/etc/containerd/config.toml中：[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true
若用 systemd-cgroup（openEuler 默认），
SystemdCgroup = true必须开启，否则 kubelet 报cgroup driver mismatch配置完执行：
systemctl restart containerd && crictl info确认 RuntimeReady 为 true不建议强行用 Docker：即使装上，也要改
/etc/docker/daemon.json加"exec-opts": ["native.cgroupdriver=systemd"]，且需额外装cri-dockerd—— 多一层封装，多一个故障点
kubeadm init 时必须指定 ARM 兼容参数
kubeadm 默认拉取的是 amd64 镜像，不加干预会在 master 节点卡住：
- 所有节点先执行：
kubeadm config images pull --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.28.2（替换成你选的版本） - init 命令不能省略
--image-repository和--cri-socket：kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --image-repository registry.aliyuncs.com/google_containers \ --cri-socket unix:///run/containerd/containerd.sock \ --kubernetes-version v1.28.2
- 如果用 Calico，后续
kubectl apply -f的 manifest 必须是 ARM 适配版（官方 manifests 默认不含 aarch64 镜像，得手动替换calico/cni、calico/node镜像 tag 为arm64后缀版，或用calico/v3.26.3这类已内置多架构的版本） -
kubeadm join命令里若含--control-plane，确保所有 master 节点的/etc/hosts解析一致，否则 etcd 成员注册失败，出现context deadline exceeded错误
网络插件选型和镜像源是隐形大坑
Calico 和 Flannel 在 ARM 上表现差异明显：
Flannel 的
quay.io/coreos/flannel官方镜像从 v0.22.0 起才正式支持 aarch64，旧版直接拉取失败Calico 的
docker.io/calico/cni镜像在 v3.25 之前未做 multi-arch push，必须用类似docker.io/calico/cni:v3.26.3-arm64这种明确带架构后缀的 tag（或改 manifest 用imagePullPolicy: Always强制校验）-
国内环境务必配镜像加速：
- containerd 配置中加
registry.mirrors（如阿里云<a href="https://www.php.cn/link/6fabe12b784d22a2b9af5570011eed9d">https://www.php.cn/link/6fabe12b784d22a2b9af5570011eed9d</a>） - kubeadm
--image-repository推荐用registry.cn-hangzhou.aliyuncs.com/google_containers，比默认的 gcr.io 可靠得多
- containerd 配置中加
最容易被忽略的一点：openEuler 的
firewalld即使 disabled，也可能残留iptables规则，导致 NodePort 不通。部署后跑个curl -v http://<node-ip>:30000</node-ip>测试前，先iptables -L -t nat | grep 30000看规则是否生效
复杂点在于：ARM 生态的镜像不是“存在就行”，而是得同时满足「架构匹配 + registry 可达 + manifest 正确声明 platform」。少验证其中一环，就会在节点 Ready 后突然发现 CoreDNS CrashLoopBackOff 或 DNS 解析失败——那往往不是配置问题，是镜像本身没跑起来。
