1. 从“能跑起来”到“跑得稳”Kubernetes架构到底在解决什么问题很多人第一次接触Kubernetes脑子里冒出来的第一个念头就是“我要搭一个集群”。这个想法本身没错但如果连它内部到底怎么运转的都没搞清楚搭出来的集群大概率只是个“能跑”的玩具一旦遇到节点宕机、Pod反复重启、服务发现失效这类问题就只能对着日志干瞪眼。我自己早期也是这样照着文档一顿操作把集群拉起来结果一个节点网络抖动整个业务直接雪崩排查了整整两天才发现是控制平面组件之间的通信出了问题。从那以后我才明白理解架构不是学术研究而是排障和调优的基本功。Kubernetes本质上是一个声明式的容器编排系统。这句话听起来很官方但拆开来看它包含两个关键信息第一你告诉它“我想要什么状态”而不是“你去做这一步那一步”第二它负责把实际状态不断向你的期望状态靠拢。这个“靠拢”的过程就是整个架构运转的核心逻辑。打个比方你装修房子时给设计师一张效果图说“我要这个样子”设计师会自己安排水电、泥瓦、木工各工种进场中间哪个环节出了问题他自己协调你不需要盯着每个工人干活。Kubernetes里的控制平面就是那个“设计师”工作节点上的组件就是各个“工种”。那这套系统到底适合谁来用如果你只是跑一个单机的小服务说实话Docker Compose就够了上Kubernetes属于杀鸡用牛刀。但当你面临多台服务器、多个服务互相调用、需要滚动更新不中断服务、需要自动扩缩容这些场景时Kubernetes的价值就体现出来了。它解决的核心问题可以归纳为三类调度问题把容器放到合适的机器上、编排问题管理容器之间的依赖和通信、自愈问题出故障时自动恢复。这三类问题在传统运维模式下需要大量人工脚本和监控告警来支撑而Kubernetes把它们变成了平台的内置能力。我见过不少团队在搭建集群时犯一个典型错误上来就选最复杂的方案什么高可用、多主节点、外部etcd集群全安排上结果维护成本极高出了问题反而因为组件太多难以定位。我的建议是先理解架构中每个组件的职责边界再根据实际业务规模决定搭建方案。小团队从单控制平面起步完全够用等业务量上来了再平滑扩展。接下来我会把架构拆开揉碎讲清楚然后再手把手带你走一遍集群搭建的完整流程包括那些文档里不会写的坑。2. 控制平面与工作节点每个组件到底在干什么活2.1 API Server整个集群的“前台接待”API Server是Kubernetes集群的唯一入口所有组件之间的通信都要经过它。你可以把它理解成一个公司的前台不管你是来办事的、来汇报的、还是来查询信息的都得先到前台登记前台负责验证你的身份、记录你的请求、然后把信息转达给相应的部门。API Server做的事情本质上就是接收REST请求、做认证授权、校验数据格式、然后写入etcd。这里有一个很多人忽略的细节API Server是无状态的。这意味着你可以部署多个API Server实例来做负载均衡它们之间不需要互相通信所有状态都存在etcd里。这个设计非常巧妙因为无状态意味着水平扩展极其简单。但反过来这也意味着etcd的健康状况直接决定了整个集群的可用性。我踩过一次坑etcd所在节点的磁盘IO突然飙升导致API Server响应超时kubectl命令全部卡死看起来像是集群挂了实际上只是etcd写不进去了。所以后来我在搭建集群时一定会给etcd单独配SSD或者高性能云盘并且监控磁盘的写入延迟。API Server还有一个关键机制叫Watch。简单说其他组件不需要不停地问API Server“有没有新变化”而是建立一个长连接API Server有变化时主动推送。这就像你关注了一个公众号有新文章它会推给你而不是你每隔五分钟去刷新一次。这个机制是Kubernetes能够快速响应状态变化的基础。2.2 etcd集群的“记忆中枢”etcd是一个分布式的键值存储Kubernetes把所有集群数据都放在里面——包括你创建的Deployment、Service、ConfigMap以及各个组件的状态信息。它的重要性怎么强调都不过分etcd挂了整个集群就失去了“记忆”所有操作都无法进行。etcd使用Raft一致性算法来保证多个副本之间的数据一致。简单解释一下Raft在一个etcd集群中有一个Leader和多个Follower所有写操作都必须经过LeaderLeader把操作日志复制给Follower超过半数节点确认后才算写入成功。这就是为什么etcd集群的节点数必须是奇数——3个节点允许挂1个5个节点允许挂2个始终保持多数派存活。在实际搭建中etcd的性能调优是个大学问。我总结了几条经验第一etcd对磁盘延迟极其敏感官方建议的写入延迟是10ms以内如果超过100ms就会出现明显问题第二etcd的数据目录要和系统盘分开避免系统日志写入影响etcd性能第三定期做defrag和compaction否则数据库文件会越来越大查询越来越慢。这些操作在文档里往往一笔带过但在生产环境中不做的话迟早会出问题。2.3 Scheduler与Controller Manager调度员和维修工Scheduler的职责很单一决定一个Pod应该放到哪个节点上运行。它有一套复杂的打分机制综合考虑节点的CPU、内存剩余量、亲和性规则、污点容忍等因素。你可以把它想象成一个物流调度员手头有一堆包裹Pod和一堆货车节点他要决定哪个包裹上哪辆车最合理。Controller Manager则是一组控制器的集合每个控制器负责一种资源的期望状态维护。比如Deployment控制器确保你指定数量的Pod副本一直在运行Node控制器负责在节点失联时标记节点状态。它们的工作模式就是不断对比期望状态和实际状态发现差异就采取行动。这个“对比-修正”的循环是Kubernetes自愈能力的核心。我特别想提一下Controller Manager里的云控制器管理器Cloud Controller Manager。如果你在云平台上搭建集群这个组件负责和云平台的API交互比如自动创建负载均衡器、管理云盘挂载等。很多人在自建集群时忽略了这部分导致Service类型为LoadBalancer时一直处于Pending状态排查半天才发现是没有部署云控制器。2.4 Kubelet与Kube-proxy节点上的“驻场工程师”Kubelet是运行在每个工作节点上的代理它负责管理本节点上的Pod生命周期。具体来说它从API Server接收Pod的调度结果然后调用容器运行时比如containerd来创建、启动、停止容器同时持续监控容器状态并上报给API Server。Kubelet是节点上最核心的组件它挂了的话该节点上的Pod管理就完全失控了。Kube-proxy负责实现Service的网络代理功能。当你创建一个Service时Kube-proxy会在每个节点上配置相应的转发规则把发往Service虚拟IP的流量转发到后端的Pod。它支持iptables和IPVS两种模式IPVS模式在大规模集群下性能明显更好因为iptables规则是线性匹配的Service数量多了之后匹配效率会急剧下降。我在超过50个Service的集群里实测过IPVS模式的转发延迟比iptables低了将近一个数量级。容器运行时是另一个关键角色。早期Kubernetes默认用Docker后来因为Docker的调用链太长Kubelet - dockershim - Docker - containerd - runc社区推出了CRI容器运行时接口标准现在主流的运行时是containerd和CRI-O。containerd比Docker更轻量启动容器更快资源占用更少这也是为什么新版本Kubernetes都推荐用containerd的原因。3. 搭建方案怎么选别一上来就追求“生产级高可用”3.1 三种主流搭建方式的真实对比在动手之前你得先决定用哪种方式搭建集群。目前主流的方式有三种kubeadm、二进制手动部署、以及各种发行版工具如k3s、minikube等。每种方式适合的场景完全不同选错了会浪费大量时间。搭建方式适合场景优点缺点kubeadm学习、测试、中小规模生产官方支持、步骤标准化、升级方便部分配置不够灵活、排查问题需要一定基础二进制部署大规模生产、需要深度定制完全可控、每个组件参数可调步骤繁琐、容易出错、维护成本高k3s边缘计算、资源受限环境极轻量、单二进制、安装极简默认配置做了裁剪、不适合复杂场景minikube本地开发学习一条命令启动、资源占用小单节点、不能模拟真实集群我的建议很直接如果你是第一次搭建无脑选kubeadm。它是官方维护的工具把大量繁琐的证书生成、组件配置、启动参数都封装好了你只需要几条命令就能拉起一个功能完整的集群。等你对各个组件的行为有了直观感受之后再去尝试二进制部署那时候你会对每个配置项的意义有更深刻的理解。3.2 搭建前的环境准备这些细节决定了后面会不会翻车环境准备阶段是最容易被忽视的环节但很多后续问题的根源都在这里。我列一下必须检查的项目操作系统层面需要关闭Swap。Kubernetes的设计假设是节点内存不足时通过驱逐Pod来释放资源而不是依赖Swap。如果Swap开着kubelet的行为会变得不可预测。关闭方法是在所有节点执行swapoff -a并且注释掉/etc/fstab里的Swap行。另外需要加载br_netfilter和overlay两个内核模块前者用于iptables对桥接流量的处理后者用于Overlay文件系统。网络层面所有节点之间必须能互相通信包括控制平面和工作节点之间的所有端口。具体来说控制平面需要开放6443API Server、2379-2380etcd、10250Kubelet API、10259Scheduler、10257Controller Manager等端口。工作节点需要开放10250和30000-32767NodePort范围。如果你在云平台上安全组规则一定要提前配好我见过太多因为安全组没开导致节点加入失败的案例。主机名和hosts每个节点的主机名必须唯一并且所有节点都能通过主机名解析到对方。最稳妥的方式是在/etc/hosts里手动添加所有节点的映射。虽然可以用DNS但在集群还没跑起来的时候hosts文件是最可靠的。时间同步所有节点的时间必须一致否则证书验证会失败。用chronyd或ntpd都行关键是确保时间偏差在秒级以内。这个问题很隐蔽因为时间不同步不会立刻报错而是在证书过期检查时突然出问题。提示以上所有操作需要在每个节点上执行建议写成一个初始化脚本避免手动操作遗漏。3.3 用kubeadm走一遍完整流程环境准备好之后就可以开始安装了。首先是安装容器运行时这里以containerd为例。安装完成后需要配置containerd使用systemd作为cgroup驱动这一步非常关键因为kubelet默认也是用systemd如果两者不一致会出现Pod无法启动的问题。配置方法是修改/etc/containerd/config.toml把SystemdCgroup设为true然后重启containerd。接下来安装kubeadm、kubelet、kubelet三个二进制工具。注意版本要一致不要一个装1.28一个装1.29。安装完成后执行kubeadm init初始化控制平面。这里有几个参数需要根据实际情况调整--pod-network-cidrPod网络的网段必须和你后面要安装的网络插件匹配。比如Calico默认用192.168.0.0/16Flannel默认用10.244.0.0/16。--apiserver-advertise-addressAPI Server对外通告的地址多网卡机器上一定要指定正确的网卡IP。--control-plane-endpoint如果你打算做多控制平面高可用这里要填一个统一的访问入口比如VIP或负载均衡地址。初始化成功后按照提示配置kubectl的kubeconfig文件然后安装网络插件。网络插件是必须的否则Pod之间无法通信CoreDNS也无法启动。Calico和Flannel是最常用的两个选择Calico功能更丰富支持网络策略Flannel更简单适合入门。我一般推荐新手先用Flannel跑通再换Calico体验网络策略。最后是加入工作节点。在控制平面初始化成功后会输出一条kubeadm join命令包含token和证书哈希值。在工作节点上执行这条命令即可加入集群。注意token默认24小时过期如果过期了需要用kubeadm token create重新生成。4. 集群跑起来之后验证、排障与那些文档不会告诉你的坑4.1 集群健康检查的完整清单集群搭好之后不要急着部署业务先做一轮完整的健康检查。我通常按以下顺序排查第一步kubectl get nodes确认所有节点状态是Ready。如果是NotReady用kubectl describe node 节点名查看具体原因常见的有网络插件没装好、容器运行时没启动、kubelet配置错误等。第二步kubectl get pods -n kube-system确认所有系统Pod都是Running状态。CoreDNS、kube-proxy、网络插件的Pod一个都不能少。如果有Pod处于CrashLoopBackOff用kubectl logs看日志大概率是镜像拉取失败或者配置有问题。第三步kubectl run一个测试Pod验证Pod能否正常调度、启动、获取IP。然后用kubectl exec进入Pod测试DNS解析是否正常nslookup kubernetes.default测试跨节点Pod通信是否正常。第四步创建一个Service验证ClusterIP和NodePort是否可达。这一步能验证kube-proxy的转发规则是否正确配置。4.2 我踩过的五个真实坑第一个坑cgroup驱动不一致导致kubelet启动失败。这个问题的表现是kubelet服务反复重启日志里报“failed to run Kubelet: misconfiguration: kubelet cgroup driver: cgroupfs is different from docker cgroup driver: systemd”。解决方法就是统一改成systemdcontainerd和kubelet都要改。第二个坑Pod网段和宿主机网段冲突。有一次我在一个内网环境搭建集群Pod网段设了192.168.0.0/16结果和公司内网网段完全重叠导致Pod访问内网服务时路由混乱。后来改成10.244.0.0/16才解决。搭建前一定要确认Pod网段和Service网段不与现有网络重叠。第三个坑节点加入集群后状态一直是NotReady。排查发现是防火墙没开放VXLAN端口Flannel用8472/UDP。云平台的安全组和主机防火墙都要检查缺一不可。第四个坑CoreDNS一直CrashLoopBackOff。日志显示无法连接API Server最后发现是CoreDNS的Pod无法访问API Server的ClusterIP。根因是kube-proxy的iptables规则没生效而kube-proxy没生效的原因是它自身的Pod还没Running。这是一个循环依赖问题解决办法是确保网络插件先于CoreDNS启动通常网络插件的DaemonSet会优先调度。第五个坑证书过期导致集群不可用。kubeadm默认生成的证书有效期是一年一年后API Server无法启动。这个问题在测试环境特别容易遇到因为搭完就不管了。解决办法是定期用kubeadm certs check-expiration检查证书有效期快到期时用kubeadm certs renew续期。4.3 集群日常维护的几个关键操作集群跑起来只是开始日常维护才是真正的考验。首先是节点管理当需要维护某个节点时用kubectl drain把上面的Pod安全驱逐到其他节点维护完成后用kubectl uncordon恢复调度。注意drain的时候要加--ignore-daemonsets和--delete-emptydir-data参数否则会因为DaemonSet Pod和emptyDir数据而卡住。其次是etcd备份。这是最重要但最容易被忽略的操作。etcd的数据一旦丢失整个集群的配置就全没了。备份命令是etcdctl snapshot save建议做成定时任务每天备份一次并且定期演练恢复流程。我见过太多团队备份了但从来没恢复过真出事的时候发现备份文件是坏的。最后是版本升级。Kubernetes的版本迭代很快但不要盲目追新。升级前一定要看官方的变更日志确认有没有废弃的API。升级顺序是先升控制平面再升工作节点每次升一个小版本不要跨版本升级。用kubeadm升级的话流程是kubeadm upgrade plan查看可升级版本然后kubeadm upgrade apply执行升级最后升级kubelet和kubectl。5. 从单节点到高可用集群扩展时机的判断与操作5.1 什么时候该考虑高可用单控制平面的集群存在单点故障如果控制平面节点挂了虽然已经运行的Pod不会受影响但你无法执行任何kubectl操作也无法调度新的Pod。对于测试环境这无所谓但对于生产环境这就是一个定时炸弹。判断是否需要高可用的标准很简单如果你的业务不能接受控制平面故障期间无法进行任何集群操作那就需要高可用。通常来说正式的生产环境都应该至少有三个控制平面节点。但也不要过度设计三个控制平面节点已经能容忍一个节点故障对于绝大多数场景足够了。五个节点的复杂度明显上升除非你有特殊需求否则没必要。5.2 高可用集群的搭建要点高可用集群的核心是多个API Server实例前面加一个负载均衡器。所有组件kubelet、kube-proxy、Controller Manager等都通过这个负载均衡地址访问API Server。负载均衡器可以是硬件F5、软件HAProxyKeepalived或者云平台提供的负载均衡服务。etcd也需要做成集群通常是三个或五个节点。etcd集群的搭建有两种方式一种是与控制平面节点混布另一种是独立部署。混布的好处是节省机器坏处是etcd对磁盘IO要求高和API Server抢资源可能互相影响。如果条件允许我建议etcd独立部署用单独的SSD盘这样性能最稳定。还有一个容易忽略的点是证书的SAN列表。高可用集群中API Server的证书必须包含负载均衡器的地址否则通过负载均衡访问时会报证书错误。用kubeadm搭建时在配置文件的apiServer.certSANs里加上负载均衡地址即可。5.3 扩容工作节点的注意事项工作节点的扩容相对简单用之前保存的join命令在新节点上执行即可。但有几个细节需要注意新节点的操作系统版本、容器运行时版本、kubelet版本要和其他节点保持一致否则可能出现兼容性问题。另外如果集群使用了网络策略新节点上的网络插件配置也要确认正确。扩容之后建议用kubectl top nodes观察各节点的资源使用情况确认调度是否均衡。如果发现某些节点负载明显偏高可能是Pod的亲和性配置或者资源请求设置不合理需要进一步调整。6. 写在最后一些个人体会搭建Kubernetes集群这件事说难不难说简单也不简单。工具已经把大部分复杂度封装好了但真正考验人的是遇到问题时的排查能力而这种能力只能来自对架构的深入理解。我自己的经验是每次遇到问题不要急着搜答案先根据架构图想一想“哪个环节可能出了问题”然后沿着数据流向一步步排查。这个过程一开始很慢但积累下来之后你会发现大部分问题都能在几分钟内定位到根因。另外不要迷信“最佳实践”。社区里流传的很多配置方案是针对大规模集群的你的场景可能完全不一样。比如有人说etcd必须独立部署但如果你就三台机器跑个小业务混布完全没问题。理解每个建议背后的前提条件比盲目照搬重要得多。最后分享一个习惯每次搭建完集群我会写一份“搭建记录”包括用了什么版本、改了哪些配置、遇到了什么问题、怎么解决的。这份记录在后续升级或者重建集群时能省下大量时间。好记性不如烂笔头这话在运维领域永远不过时。