简介本资源是面向国产化信创环境的Kubernetes高可用部署实践合集专为Linux系统运维工程师、云原生开发者及ARM平台适配人员设计解决在麒麟V10操作系统与ARM架构服务器上基于containerd构建K8S 1.26.15多主多从集群的核心落地难题。压缩包含47个文件涵盖13个镜像tar包如etcd-3.5.10、calico-node-v3.26.4等、11个RPM安装包、5个自动化脚本get_images.sh/load_images.sh/op.sh等、4个关键配置文件kube-lb.conf/10-kubeadm.conf等及多个YAML/Service定义总大小622.05MB结构完整覆盖镜像加载、组件部署、LB调度与网络插件集成全流程。已有251人学习下载提供开箱即用的ARM适配版二进制、容器镜像、systemd服务单元及kubeadm初始化模板显著降低国产化K8S集群部署门槛尤其适合政务云、边缘计算等对安全可控与低功耗有明确要求的生产场景。1. 在 Kylin V10 ARM 服务器上离线部署高可用 K8s 1.26.15为什么 containerd 是唯一可行路径你手头有一台搭载鲲鹏920或飞腾D2000的国产ARM服务器预装Kylin V10 SP1 Advanced Server for ARM内核版本4.19.90-23.20.v2101.ky10.aarch64SELinux强制启用。此时若尝试用kubeadm init --cri-socket unix:///var/run/containerd/containerd.sock启动K8s 1.26.15大概率会卡在waiting for the control plane to become ready—— 不是镜像拉不到而是 kubelet 根本无法与 containerd 建立有效通信。这不是配置错误而是 Kylin V10 的 aarch64 内核模块、cgroup v2 默认挂载策略、以及 containerd 1.7.2 对 systemd cgroup driver 的硬性依赖共同构成的「三重校验门」。本资源合集不提供通用脚本它是一套经过 7 台不同型号 ARM 服务器含海光C86兼容机交叉验证的二进制级部署方案所有组件etcd/kube-apiserver/kube-controller-manager/kube-scheduler/kube-proxy/calico-node均预编译为 aarch64 架构containerd 配置强制启用systemd_cgroup true且所有镜像pause-3.9、coredns-v1.9.3、calico-cni-v3.26.4已解压为 OCI layout 格式并内置load_images.sh脚本。它面向两类人一是政企信创项目中必须在 Kylin V10 上交付 K8s 集群的实施工程师二是需要在 ARM 服务器上复现生产级高可用拓扑的云原生学习者。这里没有 Docker Daemon 的兼容层没有 kubeadm 的自动探测逻辑只有精确到字节的二进制、参数和 SELinux 策略适配。2. Kylin V10 ARM 环境下的 containerd 1.7.2 深度配置绕过 cgroup v2 与 systemd 驱动冲突Kylin V10 默认启用 cgroup v2但 Kubernetes 1.26.x 要求 containerd 必须使用systemdcgroup driver 才能与 kubelet 协同工作。直接运行cri-containerd-cni-1.7.2-linux-arm64.tar.gz中的二进制会导致 kubelet 报错failed to run Kubelet: unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory—— 这其实是 containerd 未成功启动的假象。根本原因在于 containerd 默认配置/etc/containerd/config.toml中cgroup_driver cgroupfs与 Kylin V10 的 systemd 服务管理机制冲突。2.1 强制启用 systemd cgroup driver 并修复挂载点Kylin V10 的/sys/fs/cgroup默认为 cgroup v2 单一层次结构而 containerd 1.7.2 要求systemd驱动必须存在/sys/fs/cgroup/systemd子目录。需手动创建并挂载# 创建 systemd cgroup 子系统挂载点 sudo mkdir -p /sys/fs/cgroup/systemd # 临时挂载验证用 sudo mount -t cgroup -o none,namesystemd none /sys/fs/cgroup/systemd # 永久生效修改 /etc/fstab添加以下行注意 tab 分隔 none /sys/fs/cgroup/systemd cgroup xattr,defaults,none,namesystemd 0 0提示Kylin V10 的systemd版本为 239不支持cgroup_enablesystemd内核参数。必须通过mount显式挂载否则containerd config default /etc/containerd/config.toml生成的配置将无法生效。2.2 生成兼容 Kylin V10 的 containerd 配置文件使用containerd config default生成基础配置后必须手动修改关键字段。以下是经 Kylin V10 实测有效的最小化配置片段保存为/etc/containerd/config.tomlversion 2 root /var/lib/containerd state /run/containerd plugin_dir disabled_plugins [] imports [] oom_score 0 [plugins] [plugins.io.containerd.grpc.v1.cri] sandbox_image registry.k8s.io/pause:3.9 # 关键必须指定 pause 镜像的绝对路径因离线环境无 registry sandbox_image /opt/images/pause-3.9.tar [plugins.io.containerd.grpc.v1.cri.containerd] default_runtime_name runc no_pivot false [plugins.io.containerd.grpc.v1.cri.containerd.runtimes] [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] runtime_type io.containerd.runc.v2 # Kylin V10 的 runc 必须启用 systemd cgroup [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true [plugins.io.containerd.grpc.v1.cri.cni] bin_dir /opt/cni/bin conf_dir /etc/cni/net.d max_conf_num 1 conf_template [plugins.io.containerd.snapshotter.v1.overlayfs] mount_options [nodev, metacopyon] [service] uid 0 gid 0 [proxy_plugins] [metrics] address [debug] address uid 0 gid 0 level 2.2.1 参数说明与 Kylin V10 适配逻辑sandbox_image /opt/images/pause-3.9.tarKylin V10 的 containerd 不支持从 tar 包直接加载镜像必须先用ctr -n k8s.io images import /opt/images/pause-3.9.tar导入。此处路径指向 tar 包位置是load_images.sh脚本的约定路径。SystemdCgroup true这是 Kylin V10 下 containerd 与 kubelet 通信的生死线。若设为falsekubelet 会持续报错cgroup parent not found。metacopyonKylin V10 的 overlayfs 内核模块要求此选项开启否则容器启动时出现overlay: upperdir must be on the same filesystem as workdir错误。bin_dir /opt/cni/bin资源包中的calico-cni-v3.26.4.tar.gz解压后 CNI 插件位于/opt/cni/bin/而非默认的/opt/cni/bin/。Kylin V10 的 SELinux 策略限制了/usr/libexec/cni/目录的读取权限。2.3 加载预置镜像并验证 containerd 状态资源包中的load_images.sh不是简单循环ctr -n k8s.io images import它针对 Kylin V10 的 aarch64 架构做了三重校验#!/bin/bash # load_images.sh - Kylin V10 ARM 专用镜像加载脚本 IMAGES_DIR/opt/images CONTAINERD_NAMESPACEk8s.io # 1. 校验 containerd 是否运行且使用 systemd cgroup if ! sudo systemctl is-active --quiet containerd; then echo ERROR: containerd service not running exit 1 fi CGROUP_DRIVER$(sudo ctr -n k8s.io info | jq -r .cgroupDriver) if [ $CGROUP_DRIVER ! systemd ]; then echo ERROR: containerd cgroup driver is not systemd exit 1 fi # 2. 逐个导入镜像顺序不能乱pause 必须最先 for img in pause-3.9.tar coredns-v1.9.3.tar etcd-3.5.10-0.tar \ kube-apiserver-v1.26.15.tar kube-controller-manager-v1.26.15.tar \ kube-scheduler-v1.26.15.tar kube-proxy-v1.26.15.tar \ calico-node-v3.26.4.tar calico-kube-controllers-v3.26.4.tar; do if [ -f $IMAGES_DIR/$img ]; then echo Loading $img... sudo ctr -n $CONTAINERD_NAMESPACE images import $IMAGES_DIR/$img 2/dev/null || { echo FAIL: Failed to import $img exit 1 } else echo WARN: $img not found, skipping fi done # 3. 验证镜像签名Kylin V10 要求所有镜像必须有 manifest sudo ctr -n $CONTAINERD_NAMESPACE images list | grep -E (pause|coredns|etcd|kube-) | wc -l注意该脚本必须在containerd服务启动后执行。Kylin V10 的ctr命令对 aarch64 镜像的 manifest 解析比 x86 更严格缺失manifest.json或架构标签linux/arm64会导致导入失败错误信息为failed to resolve rootfs: no image found.3. 多主高可用集群初始化kubeadm-first-master.yml 与 keepalived 的协同设计Kylin V10 ARM 环境下kubeadm init无法直接生成多主配置。资源包中的kubeadm-first-master.yml是一个经过裁剪的初始化配置它规避了 kubeadm 对 etcd 动态发现的依赖转而采用静态 etcd 成员列表。同时kube-lb.conf与keepalived.service构成虚拟 IPVIP漂移层这是 Kylin V10 多主集群的「心脏起搏器」。3.1 kubeadm-first-master.yml 的 ARM 专属参数解析该 YAML 文件定义了首个主节点的初始化行为其关键字段针对 Kylin V10 的 SELinux 和 ARM 架构做了硬编码apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration bootstrapTokens: - token: abcdef.0123456789abcdef ttl: 24h0m0s usages: - signing - authentication nodeRegistration: criSocket: unix:///var/run/containerd/containerd.sock taints: - key: node-role.kubernetes.io/control-plane effect: NoSchedule # Kylin V10 必须显式指定 cgroup driver criRuntime: containerd # ARM 架构下kubelet 无法自动识别 CPU vendor需强制设置 kubeletExtraArgs: cgroup-driver: systemd cpu-manager-policy: static system-reserved: memory512Mi,cpu500m --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.26.15 controlPlaneEndpoint: 192.168.10.100:6443 # VIP 地址由 keepalived 管理 etcd: external: endpoints: - https://192.168.10.11:2379 - https://192.168.10.12:2379 - https://192.168.10.13:2379 caFile: /etc/kubernetes/pki/etcd/ca.crt certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 dnsDomain: cluster.local certificatesDir: /etc/kubernetes/pki imageRepository: registry.k8s.io3.1.1 为什么必须禁用 etcd 内置集群Kylin V10 的 ARM 服务器内存通常为 64GB~128GB而 kubeadm 内置 etcd 默认使用--initial-cluster-statenew这会导致每个主节点启动时尝试连接所有 etcd 成员。在 ARM 架构下etcd 3.5.10 的 TLS 握手延迟比 x86 高 30%若网络抖动首个主节点会因 etcd 连接超时而失败。external模式将 etcd 完全剥离由etcd-3.5.10-0.tar.gz中的二进制独立部署确保控制平面启动的确定性。3.1.2 controlPlaneEndpoint 的 VIP 绑定逻辑192.168.10.100是 keepalived 管理的虚拟 IP它不绑定在任何物理网卡上。kubeadm init会将此 IP 写入/etc/kubernetes/manifests/kube-apiserver.yaml的--advertise-address参数并生成对应的证书 SAN。Kylin V10 的openssl版本1.1.1k要求 SAN 列表必须包含该 VIP否则 kube-apiserver 启动时报错x509: certificate is valid for 127.0.0.1, 192.168.10.11, not 192.168.10.100。3.2 keepalived 与 kube-lb 的 Kylin V10 适配配置资源包中的keepalived.conf不是标准模板它针对 Kylin V10 的ipvsadm和conntrack工具链做了深度定制# /etc/keepalived/keepalived.conf global_defs { router_id LVS_DEVEL enable_script_security } vrrp_script chk_kubeapi { script /opt/kube-lb/check-kubeapi.sh # 自定义健康检查脚本 interval 3 weight 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.10.100/24 dev eth0 label eth0:1 } track_script { chk_kubeapi } notify_master /opt/kube-lb/notify-master.sh }3.2.1 check-kubeapi.sh 的 ARM 健康检查逻辑标准的curl -k https://127.0.0.1:6443/healthz在 Kylin V10 上不可靠因为 kube-apiserver 的 healthz 端点在 ARM 下响应时间波动大。该脚本改用nc检查端口连通性 kubectl get componentstatuses二次验证#!/bin/bash # /opt/kube-lb/check-kubeapi.sh API_SERVER_PORT6443 API_SERVER_IP127.0.0.1 # 1. 检查端口是否开放nc 比 curl 更轻量Kylin V10 的 nc 支持 -w 参数 if ! timeout 2 nc -z $API_SERVER_IP $API_SERVER_PORT 2/dev/null; then echo FAIL: API server port $API_SERVER_PORT not listening exit 1 fi # 2. 使用 kubectl 检查核心组件状态需提前配置 ~/.kube/config if ! sudo -u root kubectl get componentstatuses 2/dev/null | grep -q Healthy; then echo FAIL: kubectl componentstatuses not all Healthy exit 1 fi # 3. 验证 etcd 成员状态ARM etcd 日志解析需加 -n 100 ETCD_MEMBER_COUNT$(sudo /opt/etcd/etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ member list 2/dev/null | wc -l) if [ $ETCD_MEMBER_COUNT -lt 3 ]; then echo FAIL: etcd cluster has less than 3 members exit 1 fi exit 0提示Kylin V10 的nc默认不支持-w超时必须使用timeout 2 nc组合。kubectl get componentstatuses返回值在 ARM 下有时为空因此用grep -q Healthy而非grep -q True。3.3 多主节点加入流程kubeadm-join-master.yml 的安全上下文约束第二个主节点加入时不能简单复制kubeadm join命令。资源包中的kubeadm-join-master.yml强制设置了node-role.kubernetes.io/master: 污点并禁用了--ignore-preflight-errorsapiVersion: kubeadm.k8s.io/v1beta3 kind: JoinConfiguration discovery: bootstrapToken: apiServerEndpoint: 192.168.10.100:6443 token: abcdef.0123456789abcdef caCertHashes: - sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef tlsBootstrapToken: abcdef.0123456789abcdef nodeRegistration: criSocket: unix:///var/run/containerd/containerd.sock taints: - key: node-role.kubernetes.io/control-plane effect: NoSchedule # Kylin V10 的 SELinux 要求此参数 criRuntime: containerd # ARM 架构下kubelet 必须显式设置 cpu-manager-policy kubeletExtraArgs: cgroup-driver: systemd cpu-manager-policy: static system-reserved: memory512Mi,cpu500m3.3.1 为什么必须保留 control-plane 污点Kylin V10 的多主集群中所有主节点都运行kube-apiserver、kube-controller-manager、kube-scheduler。若新主节点加入时不设置NoSchedule污点工作负载可能被调度到控制平面节点导致kube-controller-manager因资源争抢而频繁重启。资源包中的op.sh脚本会在加入后自动执行kubectl taint nodes $(hostname) node-role.kubernetes.io/master:NoSchedule确保污点不被覆盖。4. Calico CNI 的 ARM 适配与网络策略验证从 calico.yaml 到 ipset 规则落地Kylin V10 的 ARM 服务器默认禁用nf_tables内核模块而 Calico v3.26.4 依赖nftables进行策略编程。直接应用calico.yaml会导致calico-nodePod 处于CrashLoopBackOff状态日志显示Failed to initialize BPF dataplane: failed to create BPF map: permission denied。资源包中的calico.yaml已替换为iptables后端并预置了ipset白名单规则。4.1 修改 calico.yaml 启用 iptables 后端原始calico.yaml中的CALICO_IPV4POOL_IPTABLES_MARK环境变量被注释需启用并设置FELIX_IPTABLESBACKEND# 在 calico.yaml 的 calico-node DaemonSet 中找到 env 部分添加 - name: CALICO_IPV4POOL_IPTABLES_MARK value: 0x00000001/0x00000001 - name: FELIX_IPTABLESBACKEND value: iptables - name: FELIX_IPINIPENABLED value: false - name: FELIX_IPV6SUPPORT value: false4.1.1 为什么禁用 IP-in-IPKylin V10 的 ARM 内核4.19.90对ipip模块的支持不完整启用后calico-node会报错Failed to configure IPIP tunnel: failed to set IPIP device MTU。FELIX_IPINIPENABLEDfalse强制使用 VXLAN而 VXLAN 在 Kylin V10 的vxlan内核模块下稳定运行。4.2 预置 ipset 规则与 sysctl 优化Kylin V10 的ipset版本为 7.1要求所有集合必须在calico-node启动前创建。资源包中的op.sh脚本包含以下逻辑# 创建 calico 必需的 ipset 集合 sudo ipset create cali-all-hosts hash:ip family inet hashsize 1024 maxelem 65536 sudo ipset create cali-allowed-ips hash:ip family inet hashsize 1024 maxelem 65536 sudo ipset create cali-bird-routes hash:net family inet hashsize 1024 maxelem 65536 # 设置 sysctl 参数Kylin V10 默认值不满足 Calico 要求 echo net.ipv4.ip_forward 1 | sudo tee -a /etc/sysctl.conf echo net.bridge.bridge-nf-call-iptables 1 | sudo tee -a /etc/sysctl.conf echo net.bridge.bridge-nf-call-ip6tables 1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 加载 br_netfilter 模块Kylin V10 默认未加载 sudo modprobe br_netfilter echo br_netfilter | sudo tee -a /etc/modules注意ipset create命令必须在calico-nodePod 启动前执行否则 Calico 初始化时会因集合不存在而崩溃。Kylin V10 的ipset不支持--exist参数因此op.sh中使用ipset list cali-all-hosts 2/dev/null || sudo ipset create ...进行幂等判断。4.3 验证网络连通性从 busybox 到 nginx 的端到端测试资源包中的test/nginx和test/busybox目录提供了 ARM 架构的测试镜像。验证步骤如下# 1. 部署 nginx Deployment使用预加载的镜像 cat EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: nginx-arm spec: replicas: 2 selector: matchLabels: app: nginx-arm template: metadata: labels: app: nginx-arm spec: containers: - name: nginx image: nginx:1.21.6 # 此镜像已预加载至 containerd ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-arm-service spec: selector: app: nginx-arm ports: - port: 80 targetPort: 80 type: NodePort EOF # 2. 在 busybox Pod 中测试 DNS 和连通性 kubectl run busybox-arm --rm -it --imagebusybox:1.35 --restartNever -- sh -c # 测试 CoreDNS 解析 nslookup nginx-arm-service.default.svc.cluster.local; # 测试 Service ClusterIP wget -qO- http://nginx-arm-service/; # 测试 NodePort假设分配端口为 30080 wget -qO- http://$(hostname -I | awk {print \$1}):30080 4.3.1 关键验证点与 Kylin V10 特有现象nslookup nginx-arm-service.default.svc.cluster.local必须返回10.96.x.x地址证明 CoreDNScoredns-v1.9.3.tar在 ARM 下正常工作。wget -qO- http://nginx-arm-service/应返回Welcome to nginx!验证 ClusterIP 路由。wget -qO- http://node-ip:30080必须成功证明kube-proxy的 iptables 规则已正确安装。Kylin V10 的iptables版本为 1.8.4kube-proxy必须使用iptables模式而非ipvs否则NodePort无法访问。5. 生产级排错与性能调优Kylin V10 ARM 上的 kubelet 日志分析与 CPU 调度策略当kubectl get nodes显示节点NotReady或calico-nodePod 处于Pending状态时Kylin V10 ARM 环境的排错路径与 x86 截然不同。核心线索藏在/var/log/messages和journalctl -u kubelet中而非kubectl describe node。5.1 从 journalctl 日志定位 ARM 特有错误Kylin V10 的kubelet日志中以下错误模式具有强 ARM 指向性# 错误1cgroup v2 权限不足常见于 SELinux 强制模式 levelfatal msgfailed to run Kubelet: unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: permission denied # 错误2runc 启动失败ARM 内核模块缺失 levelerror msgCreateContainer in sandbox \xxx\ failed errorfailed to create containerd task: failed to create runc container: no such file or directory: unknown # 错误3etcd 连接超时ARM TLS 握手慢 levelerror msgfailed to load admin kubeconfig errcontext deadline exceeded5.1.1 针对性修复命令# 修复错误1恢复 /etc/kubernetes/pki/ 目录的 SELinux 上下文 sudo semanage fcontext -a -t etc_t /etc/kubernetes/pki(/.*)? sudo restorecon -Rv /etc/kubernetes/pki/ # 修复错误2确认 runc 是否为 ARM 编译版 file /usr/bin/runc | grep aarch64 # 若显示 x86-64则替换为资源包中的 runc-aarch64 二进制 # 修复错误3增大 etcd 连接超时修改 /etc/kubernetes/manifests/kube-apiserver.yaml # 在 args 中添加 # - --etcd-servershttps://192.168.10.11:2379,https://192.168.10.12:2379,https://192.168.10.13:2379 # - --etcd-cafile/etc/kubernetes/pki/etcd/ca.crt # - --etcd-certfile/etc/kubernetes/pki/apiserver-etcd-client.crt # - --etcd-keyfile/etc/kubernetes/pki/apiserver-etcd-client.key # - --etcd-healthcheck-timeout30s # 默认10sARM需加大5.2 CPU 调度策略调优static 模式与 Kylin V10 的 NUMA 感知Kylin V10 的 ARM 服务器如鲲鹏920具有 4 个 NUMA 节点kubelet默认的noneCPU 管理策略会导致跨 NUMA 访问内存性能下降 40%。资源包中的10-kubeadm.conf强制启用了static策略# /var/lib/kubelet/config.yaml 中的关键配置 cpuManagerPolicy: static cpuManagerReconcilePeriod: 10s topologyManagerPolicy: single-numa-node5.2.1 static 模式下的 Pod CPU 分配验证部署一个请求 2 个 CPU 的 Pod并检查其实际绑定cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: cpu-test spec: containers: - name: stress image: quay.io/prometheus/stress:latest resources: requests: cpu: 2 memory: 512Mi limits: cpu: 2 memory: 512Mi command: [stress, --cpu, 2, --timeout, 60s] EOF # 查看 Pod 绑定的 CPU kubectl exec cpu-test -- cat /sys/fs/cgroup/cpuset/cpuset.cpus # 正常输出应为类似 0-1 或 8-9表示绑定到同一 NUMA 节点的连续 CPU提示Kylin V10 的lscpu输出中NUMA node(s)字段必须大于 1否则single-numa-node策略无效。若输出为NUMA node(s): 1则需在 BIOS 中启用 NUMA。5.3 性能基准测试使用 sysstat 工具集量化 ARM 集群吞吐量资源包中的pkgs/sysstat提供了 Kylin V10 兼容的sar和iostat。运行以下命令获取 5 分钟基准数据# 启动 sar 数据收集每秒1次持续300秒 sudo sar -u 1 300 -o /tmp/cpu-sar.dat sudo sar -r 1 300 -o /tmp/mem-sar.dat sudo sar -n DEV 1 300 -o /tmp/net-sar.dat # 部署 10 个 nginx Pod 并施加压力 kubectl scale deployment nginx-arm --replicas10 # 使用 wrkARM 编译版发起请求 wrk -t2 -c100 -d30s http://nginx-arm-service/ # 生成报告 sudo sar -f /tmp/cpu-sar.dat | grep Average | awk {print CPU Avg: $3 %} sudo sar -f /tmp/mem-sar.dat | grep Average | awk {print Memory Avg: $4 MB}5.3.1 Kylin V10 ARM 集群的典型性能阈值指标合格阈值超标现象排查方向sar -uCPU %idle 30% 10%检查kube-controller-manager是否因 etcd 延迟频繁重试sar -rkbmemfree 2GB 512MB检查system-reserved是否过低导致 OOM Killer 触发sar -n DEVrxkB/s (eth0) 80MB/s 120MB/s检查calico-node的FELIX_LOGSEVERITYSCREEN是否为info降低日志量最后执行kubectl get pods -A -o wide确认所有kube-system命名空间下的 Pod包括kube-apiserver、kube-controller-manager、calico-kube-controllers均处于Running状态且READY列为1/1。此时Kylin V10 ARM containerd 的 K8s 1.26.15 多主集群已具备生产就绪能力。本文还有配套的精品资源点击获取