★ FEATURED ARTICLE 1. 项目缘起为什么需要一份k8s流程创建清单先说句实在话我在生产环境里折腾kubernetes也有四五年了从最早用kubeadm手动敲命令一步步初始化集群到后来用Kubekey这类工具做全家桶式部署前前后后搭了不下二十套环境。每次搭完我都会发现流程里总有那么几步是文档里没写透、但是实际踩坑概率极高的地方比如证书续签、GPU调度、监控组件落盘路径这些细节光靠官方文档根本不够非得自己踏踏实实干一遍才能记住。这份k8s流程创建清单本质上不是一篇理论科普而是一份我实操验证过的、可以直接照着抄作业的部署与运维路线图。它覆盖了从环境评估、组件规划、集群初始化到高可用搭建、证书运维、GPU纳管、监控落地的完整链路。无论你是刚接触容器编排的运维新人还是已经在用docker、想往k8s迁移的后端工程师又或者是公司里需要独立交付一套生产集群的架构师这份清单都能帮你少走很多弯路。很多人一听到k8s就头大觉得组件多、概念抽象、坑又深。但如果你把它拆成流程创建清单来对待事情就清晰多了——它无非就是先想清楚要什么再按步骤交付什么最后持续维护什么。这篇文章我会按实际部署的先后顺序把每一步为什么要这么做、怎么做、出问题怎么排查都摊开来讲即使是零基础也能顺着走完。2. 整体设计与核心思路拆解2.1 先搞懂k8s和docker到底什么关系热词里一直有人在问k8s和docker区别这个问题其实也是我每次给团队培训时必讲的第一课。简单说docker解决的是单个容器怎么跑它负责把应用连同依赖打包成镜像、启动成容器k8s解决的是一堆容器怎么编排它负责调度、伸缩、故障恢复、服务发现这些集群层面的事。举一个生活化的例子docker像是一个个独立的集装箱每个箱子里的货物已经打包好了你随时能把它吊到车上拉走。k8s则是整个港口的调度系统它要知道哪个箱子放哪个泊位、哪艘船需要几个箱子、哪个吊机空闲、哪个箱子出了问题需要重新调配。没有dockerk8s就失去了运行容器的基础没有k8sdocker容器多了之后会陷入手动管理地狱。在生产实践中k8s默认的容器运行时已经可以是containerd不再直接依赖docker但docker依然广泛用于镜像构建和调试。所以我强烈建议初学者先理解docker的镜像、容器、网络、存储四大块再上手k8s否则后面讲Pod、Deployment、Service的时候你会一直纠结这和docker容器有什么区别这种基础问题上。2.2 项目清单的核心构成这份流程创建清单我习惯分成五个阶段规划阶段、部署阶段、高可用阶段、扩展阶段、运维阶段。规划阶段要回答我要搭几台机器、什么配置、选哪个版本部署阶段解决怎么把控制面和节点初始化起来高可用阶段解决多台master怎么保证不单点扩展阶段解决GPU怎么调度、监控怎么落地运维阶段解决证书过期、命令速查、控制器管理等日常问题。这五个阶段不是割裂的前面每一步的选择都会影响后面的实现方式。比如你规划阶段选了Kubekey作为部署工具那高可用和证书续签的路径就跟kubeadm完全不同又比如你规划阶段决定了要跑GPU推理任务那节点就需要提前装好驱动和runtime否则后面加上去非常痛苦。这也是我把它叫清单而不是教程的原因——清单的核心价值在于告诉你每个环节的输入和输出让你清晰地知道现在处于什么位置、下一步该做什么。2.3 工具选型逻辑为什么我选Kubekey搜索热词里有人提到了k8s三台master怎么保证高可用kubekey说明很多人已经在用Kubekey了。我个人在实际项目中也更推荐用Kubekey来做生产集群的部署原因有几个第一它对高可用架构的支持是内置的。Kubekey允许你通过一个简单的配置文件指定三台master、三台worker、三组etcd然后一条命令完成集群初始化底层自动帮你把负载均衡、健康检查都配置好。相比kubeadm手动搭HA工作量直接降低了一个量级。第二它对GPU环境和监控扩展有专门的方案。Kubekey支持在集群初始化时直接启用GPU支持也能通过ks组件一键安装Prometheus监控栈不需要你在部署完 k8s 之后再去东拼西凑各种operator。第三它在中国大陆网络环境下非常友好。kubeadm默认拉取的是谷歌的镜像仓库在国内经常卡住Kubekey会从可用的镜像源拉取而且自带了离线部署包的支持内网环境也能顺利装。当然kubekey也不是万能的。如果你对集群的定制化要求极度严格比如要自己编译kubelet、要自定义apiserver的参数那kubeadm依然是更好的选择。我的建议是默认场景直接用Kubekey快速落地特殊场景再考虑kubeadm手动方式。3. 核心细节解析与实操要点3.1 集群规划三台master高可用的架构解剖热词里k8s三台master怎么保证高可用是很多人关心的重点。先说架构三台master组成控制面高可用本质上是三个组件的高可用——etcd、kube-apiserver、kube-scheduler/kube-controller-manager。etcd集群状态存储三副本组成raft集群少数节点故障不影响写入。kube-apiserver所有组件交互的统一入口前面需要挂负载均衡可以是haproxykeepalived也可以用云厂商的SLB把请求分发到三台master上的apiserver。kube-scheduler和kube-controller-manager二者通过leader选举机制同一时刻只有一个实例在工作其他处于standby主节点挂了会自动切换。用Kubekey部署时它的配置文件里会有一个hosts段落你需要把三台master的IP都列出来并且指定一个VIP地址虚拟IP作为负载均衡入口。这个VIP就是kubeconfig里server字段和worker节点join时使用的地址。实操中我需要提醒三个细节etcd尽量不要放在性能太差的磁盘上SSD是必须的如果并发写入压力大延迟会直接反映在API响应上。三台master之间时区和时间要同步时间漂移超过一定范围etcd会报clock skew错误严重的直接导致选举失败。不要在master节点上随意跑高负载业务Pod控制面和业务混部需要非常谨慎否则节点资源一旦被打满整个集群调度都会受影响。3.2 证书体系与自动续签策略证书过期是很多k8s集群运行一年后突然罢工的头号原因。k8s各组件之间默认用TLS证书进行身份认证apiserver、kubelet、etcd都有各自的证书证书有效期默认是一年。如果不做自动续签一年后你会遇到集群状态异常、kubectl命令报certificate has expired、甚至节点NotReady等连锁故障。解决证书自动续签的方案我按可靠性排序使用Kubekey的证书轮转工具它在集群部署完成后带有一个证书更新命令可以一键轮转所有组件证书操作前它会自动备份旧证书执行完成后要求你逐个节点重启kubelet。我实测下来这个方案最省心。kubeadm方式如果集群是用kubeadm装的可以用kubeadm cert renew all手动续签再更新kubeconfig。缺点是生产环境里如果忘了定时执行还是会出现过期问题。部署证书自动续期组件比如一些第三方项目会在证书即将到期时自动调用续签并触发组件重启。这种方案自动化程度最高但引入额外的组件也意味着多一层排障复杂度。我给一个务实的建议不管用哪种方案都要在监控里加一条证书剩余有效期的告警剩余时间低于30天就开始提醒。我见过太多团队把续签这事Write进备忘录结果一忙起来就忘了最后集群出问题才手忙脚乱。3.3 控制器和常用命令的底层逻辑热词里提到k8s控制器和k8s常用命令我放在一起说因为它们其实是同一件事的两个面。控制器是一堆后台循环负责保证集群的期望状态和实际状态一致。Deployment控制器发现Pod数量比期望少了就创建Node控制器发现节点挂了就标记NotReady并按规定驱离PodHPA控制器发现CPU占用高了就扩容副本数。理解控制器之后k8s常用命令就好记多了。很多人背命令总是背了忘其实就是没抓住底层逻辑。kubectl get是查看实际状态kubectl describe是查看事件和详细状态kubectl apply是声明期望状态kubectl logs和kubectl exec是排障入口。这五个命令能解决日常80%的问题。但我要特别强调一个命令叫kubectl get events --sort-by.metadata.creationTimestamp这个在排查疑难杂症时比什么都有用。Pod创建失败、调度不成功、卷挂载超时所有原因都会以事件的形式呈现事件比Pod的描述信息更详细、更实时。我每次接手别人的问题集群第一步永远是看事件而不是盯着describe反复看。4. 实操过程从裸机到可用k8s集群的全流程实录4.1 环境准备清单我以三台master、三台worker、操作系统Ubuntu 22.04 LTS为例ubuntu高可用k8s部署也是热词里被频繁搜索的场景。部署前需要确认以下内容每台节点至少2核4Gmaster建议4核8Gworker根据业务负载定。关闭Swapkubelet默认要求swap关闭才能正常工作。用swapoff -a和注释fstab里的swap行实现。确保节点时间同步安装chrony或ntpsec配置好时间源。确保主机名唯一并且/etc/hosts里解析好所有节点的主机名和IP防止组件之间通过hostname找不到对方。如果需要Pod跨节点通信保证底层网络支持VXLAN默认网段不要和物理网络冲突我一般习惯用10.244.0.0/16。Kubekey安装很简单下载二进制或者用包管理器都能装装完生成配置文件kk create config然后编辑这个YAML文件。4.2 KubeKey快速部署示例下面是配置文件里最核心的段落我把它做成了带中文注释的简化版apiVersion: kubekey.kubesphere.io/v1alpha2 kind: Cluster metadata: name: sample spec: hosts: - {name: master1, address: 192.168.1.21, internalAddress: 192.168.1.21, user: root, password: your-password, role: [etcd, master]} - {name: master2, address: 192.168.1.22, internalAddress: 192.168.1.22, user: root, password: your-password, role: [etcd, master]} - {name: master3, address: 192.168.1.23, internalAddress: 192.168.1.23, user: root, password: your-password, role: [etcd, master]} - {name: worker1, address: 192.168.1.31, internalAddress: 192.168.1.31, user: root, password: your-password, role: [worker]} - {name: worker2, address: 192.168.1.32, internalAddress: 192.168.1.32, user: root, password: your-password, role: [worker]} - {name: worker3, address: 192.168.1.33, internalAddress: 192.168.1.33, user: root, password: your-password, role: [worker]} controlPlaneEndpoint: domain: lb.k8s.local address: 192.168.1.100 port: 6443 network: plugin: calico kubePodsCIDR: 10.244.0.0/16 kubeServiceCIDR: 10.96.0.0/16 kubernetes: version: v1.28.2然后执行./kk create cluster -f config-sample.yaml整个流程会分阶段输出日志先是检查所有节点连通性然后安装依赖、导入镜像接着初始化etcd、apiserver、controller-manager、scheduler最后安装网络插件和CoreDNS。整个过程大概15到30分钟取决于节点性能和网络下载速度。这条命令跑完你再用kubectl get nodes查看看到六台节点全部Ready集群基本就算搭建成功了。从实操角度说如果卡在某个阶段先检查输出日志的报错段落绝大多数问题出在节点连通性、SSH认证或者镜像拉取上。4.3 部署Prometheus监控栈热词里k8s部署prometheus和部署prometheus监控k8s被反复搜索说明监控是刚需。部署Prometheus到k8s有一个核心思路叫operator模式先部署Prometheus Operator再通过自定义资源声明监控目标operator负责生成底层的Deployment、Service、ServiceMonitor等对象。在Kubekey环境里最简单的做法是启用KubeSphere全家桶自带的监控组件它会自动创建Prometheus、Grafana、Alertmanager并且把k8s自身的组件指标、节点指标、Pod指标全部纳入采集。如果你不想装全家桶单独用kube-prometheus-stackHelm chart也可以它同样基于operator模式。有一点必须提醒监控数据存储是持久化的而Pod默认是临时存储。所以在部署之前一定要先规划好存储类StorageClass。没有存储类Prometheus的PVC创建不出来数据会全部写本地临时目录一旦Pod重建历史监控数据全部丢失。我个人的习惯是先部署一个基于NFS或本地盘的StorageClass再装监控栈。部署完成之后你能在Grafana里看到Node Exporter的主机指标、kubelet提供的Pod指标、apiserver的QPS和延迟等面板。这些面板能直接回答集群负载如何有没有Pod频繁重启节点磁盘是否快满了这类问题。4.4 GPU调度配置要点再讲热词里提到的k8s与gpu安装教程和k8s调用gpu。GPU要能被k8s调度需要满足三个条件物理机上装好了NVIDIA驱动、节点上安装了NVIDIA Container Toolkit、k8s里部署了对应的GPU插件比如NVIDIA Device Plugin。安装步骤我按经验排列装驱动用nvidia-smi能正常输出显卡信息。安装NVIDIA Container Toolkit它负责把宿主机GPU挂载进容器环境。部署NVIDIA Device Plugin它作为DaemonSet在每个GPU节点上运行向kubelet上报可用GPU数量。在Pod里声明resources.limits.nvidia.com/gpu: 1调度器就会自动把Pod分配到有GPU且资源充足的节点。常见的坑有两个一是驱动版本和容器运行时不匹配导致GPU插件上报失败二是节点上有多张卡但是插件默认只上报了部分卡。遇到这类问题先看Device Plugin的日志再看节点上的nvidia-smi输出对齐一下。GPU调度是现在大模型推理和训练场景的刚需我把这部分单独列出来就是因为很多人集群搭好了才发现GPU用不了回头再补这部分的成本远高于一开始就规划好。5. 常见问题与排查技巧实录5.1 证书过期引发的一连串故障去年我帮一个朋友处理过一次线上事故现象是kubectl命令能列出部分资源但Pod调度新任务时一直Pending节点状态时好时坏。用kubectl get nodes能看到部分节点NotReadymaster日志里反复出现x509: certificate has expired。排查路径很简单在master节点执行kubeadm certs check-expiration发现apiserver和kubelet的证书剩余时间只剩3天。我当时用Kubekey的证书轮转工具做了全量续签再重启了所有节点的kubelet服务集群才恢复正常。这件事给我最大的教训是证书续签不能靠人肉记账必须自动化告警双保险。证书过期不是小概率事件而是每一年都会准时发生的黑天鹅。5.2 节点NotReady的快速定位思路节点NotReady的原因太多了我按出现频率排序kubelet没起来先systemctl status kubelet看状态。网络插件故障Calico或Flannel的Pod挂掉检查网络插件相关Pod日志。磁盘空间满kubelet无法做Pod清理和镜像拉取。证书过期kubelet和apiserver之间的双向认证失败。内存或CPU压力过大节点触发了系统级的资源保护机制。排查的时候不要乱试先看节点下的事件再按上面顺序逐项排除。已经排到第4、5项的人基本都能在10分钟内定位问题。5.3 常见问题速查表和建议症状可能原因快速处理kubectl命令报端口连接失败apiserver未启动或VIP不通检查master上的kube-apiserver容器、负载均衡服务状态Pod一直Pending资源不足或节点亲和性不满足kubectl describe pod看Events重点查调度失败原因Pod反复CrashLoopBackOff启动命令或依赖缺失kubectl logs看退出日志检查环境变量和存活探针Service无法访问Pod标签选择器或端口配置错误确认Service的selector和Pod的labels匹配检查Endpoints集群证书即将过期未做自动续签立即执行轮转工具并在监控里配置有效期告警GPU Pod无法调度驱动或Device Plugin异常检查nvidia-smi和插件日志确认limits字段写法正确以上这些场景基本覆盖了k8s集群从搭建、运行到维护全生命周期里最容易踩的坑。后面我会在个人经验里多说两句。5.4 关于常用命令的实战建议命令不在多关键是组合。我给你一套排障组合拳kubectl get nodes -o wide kubectl get pods -A -o wide kubectl get events -A --sort-by.metadata.creationTimestamp kubectl top nodes kubectl top pods -A第一行看节点和IP第二行看全局Pod状态第三行看最近事件第四、五行看资源水位。这套组合下来集群大部分问题都能定位到组件层面了下一步再深入具体Pod去describe或logs。我还建议平时养成定期巡检的习惯。每周看一眼节点水位和Pod运行状态每月检查一次证书剩余时长每个季度整理一次镜像清理和存储清理。k8s这套系统本身不会主动告诉你哪里有问题它只会把问题暴露在日志和指标里你要主动去读。6. 个人经验总结与扩展建议这套流程创建清单我按自身实际执行过的方式写完了。最后再多说几句体己话。我在实际部署过程中最大的感受是规划比执行重要。很多人一上来就想执行kk create cluster结果在HA架构、网络规划、存储规划上没想清楚后面补丁越打越多。比如高可用VIP地址如果在规划阶段就指定好worker加入集群的时候就能一步到位如果等到全部部署完才发现用了单点IP再把worker全部重新join一遍的代价让我想起来就头疼。另外我想单独提一下k8s权威指南第五版pdf下载这个热搜词。大家对学习资料的需求很旺盛但我真心建议不要只囤PDF不实操。k8s这种系统光看书是学不会的一定要自己动手搭一套集群哪怕是最小规模的单机集群。搭完就练调度、练网络、练排障把Pod、Deployment、Service、Ingress这些核心对象都亲手玩一遍比啃五本PDF都有用。这份流程创建清单后续还可以朝几个方向扩展。一是加上多集群管理比如用KubeSphere或Rancher统一管理多套集群二是加上业务层面发布策略比如蓝绿发布、金丝雀发布这些都要在Ingress和Service Mesh层面做定制三是加上灾备和容灾演练比如模拟一台master或者一个worker挂掉验证集群的恢复时间。每一项展开下去都是一篇实操性极强的文章。最后分享一个小技巧每次改完集群配置不管是加节点、改证书还是换网络插件都先把旧的配置文件和当前集群状态导出一份快照。k8s本身的声明式哲学就是一切皆可重现但你要保留好期望状态的定义出了问题才能快速回到上一个已知可用状态。切勿在没有备份的情况下动集群核心组件这条经验是我拿几次半夜加班换来的。希望这份清单能帮你把k8s从听起来很复杂变成一步一步能搞定。现在就可以打开终端按照环境准备清单先检查一遍然后启动你的第一套集群试试看。
阅读完成 · 觉得有帮助？
