阿里云ECS上基于kubeadm搭建Kubernetes最新稳定版集群实践

3台阿里云服务器一个下午把Kubernetes集群最新稳定版完整跑通这事说难不难但你要是在网上搜教程大概率会卡在镜像拉取、安全组、containerd配置这几个地方。这篇文章就把我2026年3月11日这次实操的完整过程整理出来选型思路、初始化细节、kubeadm部署链路、网络插件选择、证书续签和故障转移全是我实际跑过一遍的内容适合想用阿里云服务器搭Kubernetes集群、又不想被旧教程误导的运维和开发同学参考。1. 为什么3台阿里云ECS是搭K8s集群的“标准答案”1.1 硬件选型2C4G能不能跑内存决定体验下限我这次用的3台ECS都是2核4G的规格。先说结论跑起来没问题但如果你想在上面跑真实业务4G内存属于“有点紧但能用”的状态。Kubernetes控制面组件本身就会吃掉一部分内存etcd、kube-apiserver、kube-controller-manager、kube-scheduler这些组件加起来稳定占用大概在1.2G到1.5G左右。再加上CoreDNS、网络插件的Pod以及节点上kubelet本身的开销4G内存剩下给业务容器的空间就比较有限了。给你一个直观的参考组件内存占用参考kube-apiserver300-500Metcd200-400Mkube-controller-manager80-150Mkube-scheduler60-100Mkubelet80-150MCoreDNS Flannel/Calico150-300M如果你是学习、测试、跑Demo2C4G足够。如果是企业试用环境建议直接上4C8G或者给Master节点单独加内存。磁盘方面系统盘40G起步比较稳妥镜像和容器日志消耗起来很快我建议再挂一块数据盘至少40G后面无论是搞镜像仓库缓存还是跑有状态服务都从容一些。1.2 系统版本与仓库选择Rocky Linux 9还是Ubuntu 24.04操作系统我选的Rocky Linux 9.x。原因有三点第一阿里云公共镜像直接有Rocky Linux开ECS的时候选一下就行第二沿用systemd生态和yum/dnf包管理对于以前用CentOS的团队切换成本几乎为零第三内核版本4.18以上满足Kubernetes对overlayfs、netfilter等模块的要求。也可以用Ubuntu 24.04 LTSapt源里就有containerd、kubeadm这些包社区资料也多。但如果你问我的个人意见国内公司存量服务器里CentOS的影子太重Rocky作为开源继承者是更平滑的过渡方案。版本选择上我装的是Kubernetes最新稳定版v1.35.x以你操作当天为准先看kubeadm能拉到什么版本。这里强调一个原则Kubernetes官方只维护最近三个大版本的更新装太老的版本意味着没有安全补丁很多新组件也不兼容。既然是从零开始直接上最新稳定版是最省心的选择不要为了“稳定”去装三年前的版本。1.3 网络规划内网IP、主机名、安全组放行清单阿里云ECS默认给你一张内网网卡和一个公网IP公网IP其实是NAT映射出来的这一点后面非常关键。Kubernetes集群内部通信包括kubeadm init时指定的apiserver地址、节点之间kubelet互相访问都必须用内网IP千万别用公网IP去初始化否则你会看到各种莫名其妙的超时和握手失败。我这次的主机名规划是节点角色主机名内网IP示例Masterk8s-master01172.16.0.100Workerk8s-worker01172.16.0.101Workerk8s-worker02172.16.0.102三台机器在同一VPC下内网互通默认没问题。但注意如果你的ECS不在同一安全组需要在安全组规则里放行对方的访问。我建议直接建一个专门的安全组把三台实例都加进去然后按下面的清单配置入方向规则协议端口范围源用途TCP220.0.0.0/0SSH登录TCP64430.0.0.0/0生产建议限定IPKubernetes API ServerTCP2379-2380内网网段etcd后面扩容高可用用得上TCP10250内网网段kubelet 与 apiserver 通信TCP10256内网网段kube-proxyTCP30000-327670.0.0.0/0按需NodePort 服务对外暴露这里有个小坑很多人配完安全组只想到放行SSH和6443结果Worker节点加入集群后一直NotReady一查日志全是连接apiserver超时其实就是10250端口没放开。2. 系统初始化这步省事后面全是坑2.1 关闭swap、加载内核模块、配置sysctlKubernetes对节点的要求其实很明确第一条就是把swap关掉。kubelet默认情况下是不允许swap存在的因为K8s的内存管理机制假设所有内存都可以被回收调度一旦使用swap整个调度模型就乱了。三台机器都要执行swapoff -a sed -i /swap/d /etc/fstab systemctl daemon-reloadsed那行是为了把/etc/fstab里的swap挂载项删掉确保ECS重启后swap不会再被自动打开。我见过很多人的集群运行几个月后一重启就NotReady就是因为fstab没注释swap一开kubelet直接罢工。接着加载Kubernetes网络转发需要的内核模块modprobe overlay modprobe br_netfilter再写入sysctl配置cat EOF /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 sysctl --systemnet.ipv4.ip_forward告诉内核允许IP转发这是容器跨节点通信的基础。bridge-nf-call-iptables则是让经过Linux网桥的流量也能被iptables/netfilter规则处理Kubernetes的Service转发依赖这个。2.2 安装并配置containerd把sandbox_image换成国内镜像Kubernetes 1.24之后内置的dockershim被移除了官方推荐和默认的容器运行时是containerd。如果你在网上看到“基于Docker安装Kubernetes”的教程那基本都是需要额外装cri-dockerd的旧方案在最新版上老老实实用containerd就好不需要多绕一圈。安装containerdRocky下用yum-config-manager加Docker源然后安装containerd.io包dnf install -y yum-utils yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo dnf install -y containerd.io systemctl enable --now containerd装完之后别急着用默认配置必须先改两处。第一处是sandbox_image也就是pause镜像的地址。默认它指向registry.k8s.io在国内网络环境下基本拉不动。第二处是SystemdCgroupcontainerd默认是false但Kubernetes要跟kubelet的cgroup驱动保持一致必须改成true。把默认配置导出来再修改containerd config default /etc/containerd/config.toml然后编辑/etc/containerd/config.tomlsandbox_image registry.aliyuncs.com/google_containers/pause:3.10 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc] [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup truepause的版本号会随Kubernetes版本变化最稳妥的方式是先用kubeadm config images list查出来对应的镜像列表再改sandbox_image。改完重启containerdsystemctl restart containerd这里强调一下如果你打算在集群里跑业务镜像也可以顺手在config.toml的registry部分配置镜像加速或内网镜像仓库。企业里有私有Harbor的话把Harbor地址配到mirrors里后面所有节点拉镜像都会走内网速度快一个量级。2.3 时间同步与主机名解析时间同步是Kubernetes集群里最容易忽略、出了事又特别难排查的一环。证书校验、etcd选举都对时间高度敏感节点间时间偏差超过一定阈值会出现类似“certificate has expired or is not yet valid”这种坑爹报错证书明明没过期就是握手失败。统一用chrony做时间同步dnf install -y chrony systemctl enable --now chronyd chronyc sources看到输出里state对应^*就说明时间源已经同步上了。三台机器都执行一遍。主机名解析这块我直接在三台机器的/etc/hosts里写死内网IP的对应关系cat EOF /etc/hosts 172.16.0.100 k8s-master01 172.16.0.101 k8s-worker01 172.16.0.102 k8s-worker02 EOF虽然阿里云VPC里有内网DNS但有些组件在解析主机名时会有缓存和超时问题写hosts是最简单粗暴可靠的做法。3. kubeadm拉起控制面从init到两个Worker加入3.1 安装kubeadm/kubelet/kubectl注意版本对齐三台机器都需要安装kubelet、kubeadm、kubectl这三个二进制。配置阿里云镜像源cat EOF /etc/yum.repos.d/kubernetes.repo [kubernetes] nameKubernetes baseurlhttps://mirrors.aliyun.com/kubernetes-new/core/stable/v1.35/rpm/ enabled1 gpgcheck1 repo_gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/kubernetes-new/core/stable/v1.35/rpm/ EOF然后dnf install -y kubelet kubeadm kubectl systemctl enable --now kubelet注意这里有个“正常现象”你刚装完kubelet就enable此刻它大概率是启动失败的因为集群还没初始化kubelet找不到配置文件。不用慌继续往下走。版本对齐很重要。三台机器执行kubeadm version输出的Kubernetes版本必须一致。如果某个源拉到了不同小版本用dnf install kubelet-版本号 kubeadm-版本号 kubectl-版本号锁定版本别让yum自动装了个最新的。3.2 kubeadm init参数一个个说清楚控制面节点上执行初始化命令。先建一个kubeadm配置文件方便后续证书续签时复用cat EOF /etc/kubernetes/kubeadm-config.yaml apiVersion: kubeadm.k8s.io/v1beta4 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 172.16.0.100 bindPort: 6443 --- apiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration imageRepository: registry.aliyuncs.com/google_containers clusterName: kubernetes networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 EOF然后执行kubeadm init --config /etc/kubernetes/kubeadm-config.yaml --upload-certs几个参数逐个说清楚。imageRepository用阿里云镜像仓库地址这一步直接解决国内拉不到镜像的问题。podSubnet是Pod网段Flannel默认就是10.244.0.0/16Calico默认用192.168.0.0/16这个网段决定了网络插件能管理哪些Pod IP一定要跟后面你要装的网络插件匹配。advertiseAddress就是本机内网IP让apiserver在内网地址上监听集群内部通过内网访问它。初始化成功后会输出一段提示里面包含三块重要信息一共拉取了哪些控制面镜像、如何配置kubectl、如何把Worker加入集群。保存好这段输出。接着配置kubectlmkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config这时候kubectl get nodes应该能看到控制面节点但状态是NotReady很正常因为网络插件还没装。3.3 Worker节点加入token过期、证书指纹校验Worker节点加入集群用的是kubeadm join。在控制面节点上生成一条带token的命令kubeadm token create --print-join-command输出大概是kubeadm join 172.16.0.100:6443 --token xxxxxx --discovery-token-ca-cert-hash sha256:xxxxxxxx两条Worker机器分别执行。如果初始化用了--upload-certs、想把Worker提升为控制面节点join命令里还会多一个--certificate-key参数。join过程中常见的坑有两个。第一个是“dial tcp ...:6443 connect: connection refused”或者“i/o timeout”多半是安全组没放行6443或者advertiseAddress写成了公网IP。第二个是discovery-token-ca-cert-hash哈希不一致这个hash是集群CA证书的指纹如果直接复制的命令一般不会错但如果你是在别的地方转抄、手输很容易栽在这。join成功后在控制面节点上执行kubectl get nodes看到所有节点Ready就能继续装网络插件了。4. 网络插件落定Flannel还是Calico4.1 先想明白容器网络在阿里云VPC里怎么走网络插件是Kubernetes集群里最不能马虎的部分。默认情况下Pod和Pod之间要通信但Pod的IP是动态分配的、会漂移这就需要CNI插件来统一规划和管理Pod网络。Flannel走VXLAN overlay简单、轻量、排障直观适合中小规模集群和测试环境。Calico则支持BGP路由直连模式和丰富的NetworkPolicy性能更好企业级生产环境用得更多。这次先讲Flannel因为它最快能跑通等后面你熟悉了整套流程再上Calico也不迟。有个细节要提前说Flannel默认使用10.244.0.0/16网段所以kubeadm init的时候podSubnet必须写成10.244.0.0/16不然Flannel分配Pod IP时会跟集群配置打架。4.2 安装Flannel并验证Pod互通在控制面节点上下载Flannel的manifest并应用kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml如果你的网络环境无法直接访问GitHub就先把YAML下载到本地再apply或者在有外网环境的地方下载好后上传到服务器。等待Pod拉取镜像和启动kubectl get pods -n kube-flannel -o wide全部Running之后再看节点状态kubectl get nodes两个Worker节点应该都变成Ready了。这时候做两个验证。第一个是跨节点Pod互通给一个Deployment指定调度到不同节点然后进Pod里ping对方Pod的IP。第二个是CoreDNS解析加固kubectl run --rm -it dns-test --imagebusybox -- sh nslookup kubernetes.default.svc.cluster.local能解析出来说明集群的service-discovery链路是通的。4.3 若选Calico避免的两个坑如果你的环境要求NetworkPolicy或者更大规模直接用Calico。这里只说两个最容易踩的坑。第一个Calico的custom-resources.yaml里默认的IPPool网段是192.168.0.0/16你必须在apply之前把IPPool的cidr改成和kubeadm init时--pod-network-cidr一致的网段否则Calico分配的Pod IP不在集群声明的网段里节点状态会反复NotReady。第二个默认启用了IPIP封装跨节点通信会多一层封装开销。阿里云同一VPC内网其实可以直接走底层网络路由建议把IPIP模式改成VXLAN或直接关闭overlay或者根据实际网络环境把MTU调到合理值。另外如果你已经装了Flannel再换Calico要先把Flannel的manifest彻底清理干净包括删除CNI配置和flannel.1网卡否则两个CNI插件的配置会互相覆盖非常难排查。5. 证书续签、节点重启与故障转移真正决定集群能不能用的细节5.1 证书有效期不是无限期的check和renewKubernetes集群里的证书分两拨。第一拨是控制面组件的服务证书kube-apiserver、etcd、kube-controller-manager这些组件的证书有效期一年kubeadm不会自动给你续。第二拨是kubelet的客户端证书从Kubernetes 1.26开始kubelet的证书轮换是默认开启的它会自动续签这部分不用你操心。但控制面那波证书你必须定期看。查看证书有效期kubeadm certs check-expiration输出里会列出所有控制面证书的剩余时间。如果发现快到期了执行续签kubeadm certs renew all --config/etc/kubernetes/kubeadm-config.yaml systemctl restart kubelet上面特意挂了--config因为新版kubeadm要求续签时带上初始化配置否则有些证书会按默认参数重新签发可能导致apiserver地址之类的信息和现网不一致。续签之后还有一步容易漏掉控制面的静态Pod是按文件变更触发重启的但证书文件更新不一定及时触发Pod重启所以建议手动重建一遍控制面Pod让它们读取新证书kubectl -n kube-system delete pod -l tiercontrol-plane如果没有这一步你会发现kubeadm certs check-expiration已经显示新证书但kubectl访问还是报证书过期就是因为apiserver进程还在用旧证书。我建议直接在crontab里加一条月度任务每个月自动续签并重建静态Pod省得手动操作0 3 1 * * /usr/local/bin/kubeadm certs renew all --config/etc/kubernetes/kubeadm-config.yaml /dev/null 21 systemctl restart kubelet kubectl -n kube-system delete pod -l tiercontrol-plane /dev/null 215.2 ECS重启后节点NotReady的恢复姿势阿里云ECS控制台点击重启这在业务上很常见。节点重启之后集群能不能自动恢复取决于几个自启动服务有没有enable。至少确认这三项systemctl enable containerd systemctl enable kubelet systemctl enable chronyd即便都enable了重启后节点仍然可能NotReady。我的排查顺序是固定的第一看kubelet状态第二看containerd状态第三看swap有没有复活第四看时间对不对。systemctl status kubelet journalctl -xeu kubelet --no-pager | tail -n 50如果是swap问题日志里会出现Running with swap on is not supported回去把fstab里的swap行删干净。如果kubelet状态正常但节点一直NotReady再查crictl能不能跟containerd通信crictl ps能看到容器列表就说明容器运行时没问题接下来再看网络插件Pod是不是还正常。5.3 单master的故障转移局限与升级为高可用的思路3台机器最常见的布局就是1主2从我这次也是这么搭的。但你要清楚一点单Master架构下如果Master宕机集群的控制面就不可用了kubectl、调度、自动伸缩全都失效但Worker节点上已经运行着的Pod不会马上挂容器还在跑只是没有了“大脑”。如果你的业务要求控制面高可用那至少要从“1个Master”扩展成“3个控制面节点”。3台机器正好可以做成3控制面加2工作节点的混合部署。实现方式有两种思路。第一种用kubeadm join --control-plane把另外两台节点加入控制面kubeadm init --upload-certs初始化时通过--upload-certs把控制面证书上传然后worker节点上执行带--control-plane和--certificate-key参数的join命令。第二种前面挂一个阿里云内网SLB把三个控制面节点的6443端口都加入后端服务器组这样apiserver的访问入口就变成了SLB的内网IPWorker节点的join地址和kubeconfig里的server地址都指向SLB。这套方案更符合生产习惯扩缩容控制面节点也不会影响客户端连接。需要注意的细节是etcd的多数派机制。三个etcd节点最多允许挂掉一个这是Raft协议决定的。如果你只有2个etcd节点挂掉任意一个etcd就可能选不出Leader整个集群的控制面就废了所以生产环境etcd节点必须是奇数且至少3个。6. 复盘我踩过的3个阿里云专属坑以及常用排查命令6.1 三个坑第一个坑是安全组只放行了SSH。Worker节点join的时候报“dial tcp 172.16.0.100:6443: i/o timeout”我第一反应是防火墙结果firewalld根本没开查了一圈才发现是安全组入方向规则没有6443。阿里云安全组是作用在虚拟网卡上的你在服务器里用iptables看不到它。第二个坑是初始化时用了公网IP做advertiseAddress。当时图省事觉得公网IP外面能访问结果控制面节点自己都连不上apiserver因为公网IP是NAT出来的数据包在内网里根本找不到这个IP。所有节点间的通信必须走内网IP。第三个坑是containerd的SystemdCgroup没改kubelet起来之后疯狂报Failed to run sandbox节点状态一直是NotReady。这个问题网上讨论很多但每次实操还是会遇到把config.toml里那行改成true重启containerd问题就消失了。6.2 常用排查命令把这几个命令记下来集群出问题的时候能省一半时间# 看kubelet最近报错 journalctl -xeu kubelet --no-pager | tail -n 100 # 看容器运行时里实际有哪些容器 crictl ps -a # 看容器日志 crictl logs container-id # 看节点详细状态和条件 kubectl describe node node-name # 看网络插件Pod日志 kubectl logs -n kube-flannel -l appflannel # 看端口监听情况 ss -tlnp | grep -E 6443|10250|2379 # 直接探测apiserver健康 curl -k https://127.0.0.1:6443/healthz6.3 给你的入门建议如果是第一次搭Kubernetes集群我建议先在3台2C4G的ECS上完整跑通这套流程初始化、加Worker、装网络插件、部署一个Nginx Deployment暴露NodePort访问。跑通之后再去折腾证书续签、高可用、网络策略这些进阶内容。这个顺序能让你把“Kubernetes到底怎么运作的”这件事建立起来而不是停留在照着命令敲的层面。我自己的体会是Kubernetes里的坑绝大多数不是它本身复杂而是环境细节没对齐。内网IP没用好、安全组没放行、cgroup驱动不一致、swap没关掉任何一个细节漏了后面排查的时间都是以小时计的。这3台阿里云服务器装完集群之后现在跑了一个自建监控和一整套日志采集整体很稳。后面我还打算把Calico的NetworkPolicy和Ingress-nginx补上到时候再有心得再写一篇。