ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

ARM架构Kylin V10系统部署K8S 1.26.15集群实战指南

ARM架构Kylin V10系统部署K8S 1.26.15集群实战指南 简介本资源面向国产化信创环境下的云原生实践者聚焦Kylin V10操作系统与ARM64架构CPU的深度适配提供一套开箱即用的Kubernetes 1.26.15一主一从集群部署方案解决在国产ARM平台基于containerd运行时构建稳定K8S集群的技术落地难题适用于边缘计算、信创云平台及教学实验等场景。压缩包共38个文件619.64MB涵盖14个ARM64专用二进制tar.gz包含kube-apiserver、etcd、calico-cni等、11个Kylin V10适配rpm依赖包、4个自动化脚本load_images.sh/get_images.sh等、3个关键YAML配置kubeadm-config.yaml/calico.yaml等以及service、conf、kubelet、kubeadm等核心组件文件目录结构按部署流程组织便于分步执行与故障定位。目前已有260人学习下载用户可直接复用全部镜像加载脚本、CNI插件离线包、systemd服务模板及RBAC基础配置显著降低ARMKylin环境下K8S部署的编译适配与网络调试门槛。1. 项目概述与背景最近在给一个国产化项目做技术选型和POC验证客户那边硬件清一色是华为鲲鹏920的ARM服务器操作系统指定要用银河麒麟Kylin V10。需求很明确要在上面跑一套容器化的业务平台Kubernetes后面简称K8S自然是首选。但真上手部署时发现网上基于x86_64和CentOS的教程铺天盖地而针对“Kylin V10 ARM”这个组合的、能从头到尾跑通的实战记录却少得可怜尤其是用containerd作为容器运行时、部署相对较新版本如1.26.x的完整指南。这次部署的目标是一个经典的一主一从1 Master, 1 Worker生产就绪迷你集群。选择K8S 1.26.15这个版本是因为它处于一个长期支持版本1.26的末期相对稳定修复了早期的大量问题同时又包含了一些较新的特性。而用containerd替代Docker一方面是顺应K8S项目自身的发展趋势从1.24版本开始已弃用Docker作为默认运行时另一方面也是考虑到containerd更轻量、更专注性能开销和资源占用也更优特别适合资源相对受限或对性能有极致要求的ARM服务器环境。这个合集就是我这次从零开始在ARM架构的Kylin V10上用containerd成功部署K8S 1.26.15集群的完整实战记录。我会把过程中所有关键步骤、踩过的坑、参数调优以及背后的原理都梳理出来目标就是让你能拿着这份指南在自己的ARM服务器上复现一个同样稳定可靠的K8S环境。2. 环境准备与系统调优部署前的准备工作至关重要尤其是在国产化操作系统和ARM架构下一些默认配置可能并不适合运行K8S。这一步没做好后面会冒出各种稀奇古怪的问题。2.1 硬件与操作系统确认首先你需要确认你的服务器环境。我的两台机器配置如下Master节点华为TaiShan 2280服务器鲲鹏920 5250处理器64核64GB内存Kylin V10 SP1。Worker节点华为TaiShan 200服务器鲲鹏920 3226处理器32核32GB内存Kylin V10 SP1。通过命令确认架构和系统# 查看CPU架构确认是aarch64ARM64 uname -m # 输出应为aarch64 # 查看操作系统详细信息 cat /etc/os-release # 应能看到包含“Kylin Linux Advanced Server release V10 (Sword)”等信息注意Kylin V10有不同的版本如桌面版、服务器版务必使用服务器版。ARM架构下所有的软件包都必须是对应aarch64架构的不能混用x86_64的包。2.2 基础系统配置接下来进行一系列必须的系统配置这些配置在两个节点上都需要执行。1. 主机名与Hosts解析为每台机器设置易于识别的主机名并配置静态的hosts解析避免后续因DNS问题导致节点间通信失败。# 在Master节点执行 hostnamectl set-hostname k8s-master # 在Worker节点执行 hostnamectl set-hostname k8s-worker # 编辑所有节点的 /etc/hosts 文件添加如下内容假设你的IP不同请替换 vim /etc/hosts在文件中添加192.168.1.100 k8s-master 192.168.1.101 k8s-worker2. 关闭防火墙与SELinuxK8S需要大量端口进行组件间通信生产环境会配置特定的防火墙规则但在学习和部署阶段直接关闭可以避免很多麻烦。Kylin V10默认使用firewalld。systemctl stop firewalld systemctl disable firewalld同时关闭SELinux将其模式设置为permissive。setenforce 0 sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config3. 关闭Swap交换分区Kubernetes要求节点禁用Swap以确保kubelet正常工作。否则Pod的内存请求/限制会变得不准确。# 临时关闭 swapoff -a # 永久关闭注释掉swap相关行 sed -i / swap / s/^\(.*\)$/#\1/g /etc/fstab4. 配置内核参数与模块加载K8S需要一些特定的内核参数。编辑/etc/sysctl.d/k8s.conf文件cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-ip6tables 1 net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF加载br_netfilter模块并应用配置modprobe br_netfilter sysctl --system5. 配置时间同步集群内所有节点时间必须同步否则证书会出问题。使用chronyd进行同步。systemctl enable --now chronyd chronyc sources -v # 查看同步状态2.3 安装前置依赖与Containerd在ARM架构的Kylin V10上软件源可能需要配置。银河麒麟有自带的源但可能不包含最新版本的容器相关软件。我们可以优先使用麒麟源部分软件从官方或第三方ARM兼容源获取。1. 配置Yum源可选确保系统可以安装基础工具如wget,vim,conntrack等。yum install -y wget vim conntrack-tools ipvsadm ipset socat2. 安装ContainerdContainerd的安装包可以从其GitHub Release页面下载ARM64版本。这里我们安装版本1.6.21。# 下载containerd wget https://github.com/containerd/containerd/releases/download/v1.6.21/containerd-1.6.21-linux-arm64.tar.gz # 解压到系统目录 tar Cxzvf /usr/local containerd-1.6.21-linux-arm64.tar.gz # 生成并安装systemd服务文件 wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service mv containerd.service /usr/lib/systemd/system/ # 创建默认配置文件 mkdir -p /etc/containerd containerd config default /etc/containerd/config.toml3. 关键配置修改Containerd的Cgroup驱动为systemd这是与K8S集成最关键的一步。K8S默认使用systemd作为cgroup驱动我们需要让containerd与之匹配。vim /etc/containerd/config.toml找到[plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc.options]部分将SystemdCgroup设置为true。[plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc.options] ... SystemdCgroup true4. 安装runc和CNI插件Containerd需要runc和CNI插件。# 下载并安装runc (ARM64版本) wget https://github.com/opencontainers/runc/releases/download/v1.1.4/runc.arm64 install -m 755 runc.arm64 /usr/local/sbin/runc # 下载并安装CNI插件 wget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-arm64-v1.1.1.tgz mkdir -p /opt/cni/bin tar Cxzvf /opt/cni/bin cni-plugins-linux-arm64-v1.1.1.tgz5. 启动并设置Containerdsystemctl daemon-reload systemctl enable --now containerd systemctl status containerd # 检查状态6. 配置crictl工具可选但推荐crictl是类似docker的命令行工具用于调试containerd。创建其配置文件cat /etc/crictl.yaml EOF runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false EOF可以测试一下crictl ps应该返回空列表因为没有容器在运行。3. K8S组件安装与集群初始化基础环境就绪后我们就可以安装Kubernetes的核心组件了kubeadm, kubelet, kubectl。3.1 配置Kubernetes Yum源并安装由于网络原因直接从Google的源下载可能较慢。我们可以使用阿里云提供的Kubernetes镜像源它提供了ARM64的包。# 1. 添加阿里云Kubernetes Yum源 cat /etc/yum.repos.d/kubernetes.repo EOF [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64 enabled1 gpgcheck1 repo_gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF # 2. 安装指定版本的kubelet, kubeadm, kubectl # 这里安装1.26.15版本注意版本号要完全匹配 yum install -y kubelet-1.26.15 kubeadm-1.26.15 kubectl-1.26.15 --disableexcludeskubernetes # 3. 设置kubelet开机自启先不启动等初始化后再启动 systemctl enable kubelet实操心得在ARM架构下务必确认Yum源中确实有你需要的版本。yum list available kubeadm --showduplicates可以查看所有可用版本。如果阿里云源没有可能需要从其他国内镜像站或官方源寻找ARM64的RPM包手动安装。3.2 使用kubeadm初始化Master节点这是最核心的一步。我们需要为kubeadm准备一个初始化配置文件因为它需要知道我们使用containerd以及一些特定的镜像仓库地址国内访问k8s.gcr.io很慢需要替换。1. 生成初始化配置文件kubeadm config print init-defaults kubeadm-init.yaml2. 编辑配置文件我们需要修改几个关键部分vim kubeadm-init.yaml主要修改点localAPIEndpoint.advertiseAddress: 改为Master节点的IP地址如192.168.1.100。nodeRegistration.criSocket: 将默认的docker socket路径改为containerd的路径unix:///run/containerd/containerd.sock。imageRepository: 将默认的k8s.gcr.io替换为国内镜像仓库例如阿里云镜像仓库registry.aliyuncs.com/google_containers。这是ARM架构下能成功拉取镜像的关键kubernetesVersion: 确保版本是v1.26.15。networking.podSubnet: 如果你打算使用Calico、Flannel等网络插件需要根据插件的默认网段配置。例如Calico常用192.168.0.0/16。这个配置必须与后续安装的网络插件匹配一个修改后的配置片段示例apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 192.168.1.100 # 你的Master IP bindPort: 6443 nodeRegistration: criSocket: unix:///run/containerd/containerd.sock # 关键修改 imagePullPolicy: IfNotPresent taints: null --- apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.26.15 # 指定版本 imageRepository: registry.aliyuncs.com/google_containers # 关键修改国内镜像 networking: podSubnet: 192.168.0.0/16 # 根据你的网络插件设置 serviceSubnet: 10.96.0.0/123. 预拉取镜像使用修改后的配置文件让kubeadm先检查并拉取所需镜像这可以提前发现问题。kubeadm config images pull --config kubeadm-init.yaml如果一切顺利你会看到一系列ARM64架构的镜像被成功拉取例如[config/images] Pulled registry.aliyuncs.com/google_containers/kube-apiserver-arm64:v1.26.15 [config/images] Pulled registry.aliyuncs.com/google_containers/kube-controller-manager-arm64:v1.26.15 ...4. 初始化Master节点执行初始化命令--upload-certs参数会自动上传证书方便后续高可用扩展。kubeadm init --config kubeadm-init.yaml --upload-certs这个过程会持续几分钟如果成功最后会输出类似以下信息请务必完整保存这部分输出特别是kubeadm join开头的命令它是Worker节点加入集群的凭证。Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config Alternatively, if you are the root user, you can run: export KUBECONFIG/etc/kubernetes/admin.conf You should now deploy a pod network to the cluster. Run “kubectl apply -f [podnetwork].yaml” with one of the options listed at: https://kubernetes.io/docs/concepts/cluster-administration/addons/ Then you can join any number of worker nodes by running the following on each as root: kubeadm join 192.168.1.100:6443 --token your-token \ --discovery-token-ca-cert-hash sha256:your-hash \ --control-plane --certificate-key your-certificate-key # 如果是控制平面节点 # 或者 kubeadm join 192.168.1.100:6443 --token your-token \ --discovery-token-ca-cert-hash sha256:your-hash # 如果是工作节点5. 配置kubectl按照上面提示为当前用户配置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因为还没装网络插件。3.3 Worker节点加入集群在Worker节点k8s-worker上重复第2章环境准备与系统调优和第3.1节K8S组件安装的所有步骤。确保containerd、kubelet等组件安装配置一致。然后使用Master节点初始化成功后输出的kubeadm join命令注意使用那个没有--control-plane的普通Worker加入命令在Worker节点上以root身份执行。kubeadm join 192.168.1.100:6443 --token your-token \ --discovery-token-ca-cert-hash sha256:your-hash加入成功后在Master节点上再次执行kubectl get nodes应该能看到两个节点状态都是NotReady。4. 网络插件安装与集群验证没有网络插件集群内的Pod无法通信。这里我们选择Calico它对ARM架构支持良好功能也强大。4.1 安装Calico网络插件在Master节点上操作。我们需要下载Calico的ARM64兼容的部署清单。访问Calico官方文档找到对应版本这里用v3.26.1的安装方式。对于ARM64和kubeadm的默认CIDR192.168.0.0/16可以使用以下命令# 下载Calico的Tigera Operator部署清单ARM兼容 curl https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml -O # 下载自定义资源定义(CR)配置这里需要指定pod网段 curl https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml -O关键修改编辑custom-resources.yaml文件确保其中的cidr字段与kubeadm-init.yaml中设置的podSubnet192.168.0.0/16一致。# custom-resources.yaml 部分内容 apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - blockSize: 26 cidr: 192.168.0.0/16 # 确保这里是192.168.0.0/16 encapsulation: VXLANCrossSubnet natOutgoing: Enabled nodeSelector: all()应用这两个清单文件kubectl create -f tigera-operator.yaml kubectl create -f custom-resources.yaml4.2 验证集群状态安装完成后需要等待几分钟让Calico的Pod全部启动并运行。使用以下命令观察状态# 查看所有命名空间的Pod状态等待所有Pod都是Running状态 kubectl get pods --all-namespaces -w # 查看节点状态应该都变为Ready kubectl get nodes # 输出示例 # NAME STATUS ROLES AGE VERSION # k8s-master Ready control-plane 15m v1.26.15 # k8s-worker Ready none 10m v1.26.15 # 查看集群组件健康状态 kubectl get cs4.3 部署测试应用为了验证集群网络和调度是否完全正常我们可以部署一个最简单的测试应用。# 部署一个Nginx Deployment kubectl create deployment nginx-test --imagenginx:alpine --replicas2 # 将部署的Nginx服务暴露出来NodePort方式 kubectl expose deployment nginx-test --port80 --typeNodePort # 查看Pod状态和Service信息 kubectl get pods,svc -o wide如果两个Pod分别被调度到Master和Worker节点上并且状态都是Running同时Service分配了一个NodePort如30080那么就可以通过浏览器或curl访问http://任意节点IP:NodePort看到Nginx欢迎页面这证明集群部署成功。5. 常见问题与深度排查指南在ARMKylin V10的环境下部署你大概率会遇到一些特有或常见的问题。这里我把踩过的坑和解决方法汇总一下。5.1 镜像拉取失败相关问题这是最常见的问题错误信息通常包含ImagePullBackOff或ErrImagePull。问题现象Pod状态一直是ImagePullBackOffkubectl describe pod pod-name看到错误原因是拉取镜像失败。排查思路确认镜像地址和架构首先检查你拉取的镜像是否有ARM64版本。很多镜像默认是x86_64的。例如nginx:latest可能有多架构支持但一些特定镜像可能没有。尽量使用明确支持多架构或标有-arm64标签的镜像如nginx:alpineAlpine Linux通常提供多架构支持。检查容器运行时配置在节点上直接使用crictl pull命令测试拉取镜像例如crictl pull nginx:alpine。如果失败可能是containerd配置的镜像加速器registry-mirrors有问题或者/etc/containerd/config.toml中配置的pause镜像不对。K8S 1.26使用的pause镜像是registry.aliyuncs.com/google_containers/pause:3.9ARM64。检查K8S初始化配置确保kubeadm-init.yaml中的imageRepository正确指向了包含ARM64镜像的仓库。国内常用registry.aliyuncs.com/google_containers。解决方法对于工作负载镜像在Deployment的spec.template.spec.containers.image字段中尽量使用官方明确支持多架构的镜像标签。如果必须使用没有ARM64版本的镜像可以考虑在ARM服务器上使用docker buildx构建自己的ARM64版本镜像并推送到私有仓库。5.2 节点NotReady问题节点状态长时间处于NotReady。问题现象kubectl get nodes显示节点状态为NotReady。排查思路查看节点详情kubectl describe node node-name在Conditions部分查看具体是哪个条件出了问题常见的是NetworkUnavailable或KubeletNotReady。检查kubelet服务在问题节点上执行systemctl status kubelet查看服务是否正常运行日志是否有报错journalctl -xeu kubelet。常见错误包括cgroup驱动不一致kubelet日志出现”Failed to start ContainerManager failed to initialize top level QOS containers”之类的错误。这通常是因为容器运行时containerd和kubelet的cgroup驱动不一致。我们之前已经将containerd配置为systemd还需要确保kubelet的启动参数也配置了--cgroup-driversystemd。在Kylin V10上编辑/etc/sysconfig/kubelet添加KUBELET_EXTRA_ARGS”--cgroup-driversystemd”然后重启kubeletsystemctl daemon-reload systemctl restart kubelet。CRI连接失败kubelet日志出现”failed to get runtime version”或连接/run/containerd/containerd.sock失败。检查containerd是否在运行以及/etc/containerd/config.toml中CRI插件是否启用默认是启用的同时检查/var/run/containerd/containerd.sock文件是否存在。检查网络插件Pod如果问题是NetworkUnavailable说明Calico或其他网络插件没有在该节点上成功运行。在该节点上执行crictl ps查看是否有calico-node相关的容器。使用kubectl logs -n calico-system calico-node-pod-name -c calico-node查看具体日志。常见问题包括内核模块缺失Calico需要ip_set,xt_set,ip_tables等内核模块。在Kylin V10上使用modprobe手动加载并确保开机自动加载。IPv4转发未开启虽然我们在sysctl中配置了但可能未生效。再次确认sysctl net.ipv4.ip_forward输出为1。Pod网段冲突Calico配置的IP池cidr必须与kubeadm-init.yaml中的podSubnet完全一致。5.3 kubeadm init/preflight errors 初始化预检错误执行kubeadm init时失败。问题现象kubeadm init命令在预检阶段报错。排查思路仔细阅读错误信息。kubeadm会进行一系列预检。Swap未关闭错误信息明确提示。按照2.2节步骤彻底关闭Swap。端口被占用6443, 10250, 10259等端口被占用。使用ss -tlnp | grep 端口号查找并结束占用进程。containerd未运行或socket路径不对确保containerd服务是active (running)状态并且kubeadm-init.yaml中的criSocket路径正确。防火墙或SELinux干扰虽然我们关闭了但有时策略残留。确保iptables -L规则是开放的或者完全清空规则。5.4 ARM架构特有的问题QEMU用户态模拟性能问题绝对不要在物理ARM服务器上使用QEMU用户态模拟来运行x86容器。性能极差且问题多多。所有镜像必须使用ARM64原生镜像。内核版本与功能Kylin V10的内核版本可能较旧确保其支持K8S所需的所有特性如OverlayFS, VXLAN等。通常V10 SP1的内核是够用的。可以通过uname -r查看。第三方软件兼容性一些常用的运维工具或监控组件如某些版本的nfs-utils可能没有为ARM架构充分测试。在安装前最好先通过yum search或查看软件包官网确认其对ARM64的支持情况。6. 生产环境考量与后续优化部署完成只是第一步要让这个集群能用于实际生产还需要做不少加固和优化工作。6.1 证书与令牌管理初始化集群时生成的kubeadm join令牌默认24小时有效。如果需要长期有效或添加新节点可以手动管理。# 生成一个永不过期的令牌 kubeadm token create --ttl 0 # 查看所有令牌 kubeadm token list # 获取CA证书的sha256哈希值用于拼接join命令 openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2/dev/null | openssl dgst -sha256 -hex | sed s/^.* //6.2 配置镜像拉取策略与加速在生产环境通常会使用私有镜像仓库。需要配置containerd和K8S以支持私有仓库认证。在/etc/containerd/config.toml中配置私有仓库的mirrors和configs。在K8S中创建docker-registry类型的Secret然后在Pod的imagePullSecrets字段中引用。对于公有镜像可以继续使用国内镜像加速器。编辑containerd配置# /etc/containerd/config.toml [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors] [plugins.”io.containerd.grpc.v1.cri”.registry.mirrors.”docker.io”] endpoint [“https://你的镜像加速器地址“]6.3 节点资源预留与kubelet配置确保系统进程和K8S组件有足够的资源避免因资源竞争导致节点不稳定。编辑/etc/sysconfig/kubelet添加资源预留参数KUBELET_EXTRA_ARGS”--cgroup-driversystemd --system-reservedcpu500m,memory1Gi --kube-reservedcpu500m,memory2Gi --eviction-hardmemory.available5%,nodefs.available10%”这表示为系统守护进程预留0.5核CPU和1Gi内存为K8S系统组件预留0.5核CPU和2Gi内存并设置了硬驱逐阈值。6.4 网络策略与安全Calico默认安装后允许所有Pod间通信。在生产环境应根据最小权限原则配置NetworkPolicy限制不必要的网络流量。你可以通过编写NetworkPolicy资源来定义入口ingress和出口egress规则。6.5 监控与日志一个没有监控的集群就像在黑暗中开车。至少需要部署以下组件Metrics Server为K8S Dashboard和HPA提供资源指标。ARM64有官方镜像直接部署即可。Prometheus Grafana全面的监控告警方案。需要寻找ARM64兼容的镜像或自行构建。日志收集考虑使用EFKElasticsearch, Fluentd, Kibana或Loki栈。同样需要确认ARM64镜像的可用性。6.6 高可用与备份目前是一主一从Master节点是单点。对于生产环境至少需要三个Master节点以实现高可用。这涉及到使用外部负载均衡器、kubeadm的--control-plane-endpoint参数以及更复杂的证书配置。此外定期备份/etc/kubernetes/pki目录和/etc/kubernetes下的配置文件至关重要可以使用etcdctl工具备份etcd数据。这次在ARM架构的银河麒麟V10上部署K8S 1.26.15集群最大的体会就是“细节决定成败”。从系统参数的一个配置项到镜像仓库的一个地址再到软件包的一个架构后缀任何一步的疏忽都可能导致部署失败。尤其是cgroup驱动、镜像架构、网络插件CIDR这几个地方是连环坑的高发区。把这份指南里的步骤和注意事项都走通你的ARM K8S集群地基就算打牢了。后续在上面部署应用时首要关注点依然是每一个镜像是否都有aarch64的版本这是ARM生态下玩转云原生的第一道也是最重要的一道门槛。本文还有配套的精品资源点击获取
返回列表