学K8S和真正动手搭K8S之间隔着一个经常被忽略又极其关键的组件——etcd。我见过不少朋友聊Pod、Deployment头头是道但问一句“K8S把集群状态到底存在哪”答案就开始含糊了。实际上K8S控制面的所有状态节点的调度结果、Pod的实时状态、ConfigMap和Secret的内容全部以键值对形式存放在etcd里。etcd才是那个真正决定“你现在看到的集群长什么样”的数据库。这篇文章从K8S基础架构讲起带着你把它最关键的数据底座拆开看明白然后完整走一遍单节点etcd服务的部署流程。过程中会把Raft协议的通俗逻辑、配置文件里每个字段的含义、systemd托管方法、备份恢复手段都讲清楚。适合正在搭实验环境、或者想彻底搞懂K8S控制面组件之间如何协作的人。内容全部基于我实际搭建和踩坑的经验不是照搬文档。1. 先把K8S的大体结构讲透etcd到底坐在哪张椅子上1.1 控制面的四块拼图API Server、调度器、控制器、etcdK8S集群从逻辑上分成两大部分控制面和工作节点。工作节点是真正跑业务容器的地方控制面负责做决策、管状态。控制面里的核心组件主要有四个API Server、Controller Manager、Scheduler以及一个独立的分布式键值存储etcd。我用一个类比来解释这四者的关系把K8S当成一家公司API Server是前台接待处所有外部请求、内部组件之间的沟通都要经过它Controller Manager是拿着规章制度做检查的部门不停确保现实状态和期望状态一致Scheduler是排班员负责把任务分配合适的人而etcd就是这家公司的档案室所有决定、所有现场记录都写进档案业务人员要了解现状也去档案室查。没有档案室整个公司所有决策都会失去依据。所以控制面正常运行的基本路径是你通过kubectl向API Server提交一个期望状态API Server把这个期望状态写入etcdScheduler从etcd读到新任务并做调度决策Controller Manager通过watch机制监听状态变化并持续调整。etcd一旦不可用API Server连读写都无法完成整个集群的控制功能直接瘫痪。这也是为什么etcd在K8S里地位如此之高。1.2 为什么K8S的数据存储偏偏是一个键值库有人可能会想K8S这么复杂的系统为什么不用MySQL这种传统数据库理解这个问题的关键在于K8S对数据存储的需求非常特殊。首先需要强一致。API Server是最核心的组件所有控制器都通过它读取状态如果读到的数据是过期的或者不一致的调度和控制器就可能做出错误决策。etcd基于Raft共识算法能保证写入一旦返回成功后续任何节点都能读到这个值这就是强一致性。其次还需要监听Watch能力Controller Manager和Scheduler不需要定期轮询数据而是订阅key的变化数据一变就立即收到通知。这是K8S能对资源变化做出秒级响应的重要原因。再就是Lease租约机制节点心跳、Pod存活都依赖这个能力租约到期自动清理避免用复杂任务定期扫描。用表格对比一下更直观能力etcdRedisMySQL一致性Raft强一致主从异步复制可能丢数据半同步或组复制可以做到但部署重变更通知原生Watch有Pub/Sub但消息不持久、语义不同需解析binlog实现复杂租约机制内建Lease有TTL但精准续约能力没有etcd完善需自己写表、写定时任务命令事务支持mini-transactionLua脚本强事务能力部署形态独立小进程适合组件间协调独立进程重运维成本高一句话总结etcd是专门为“分布式系统中的协调状态”设计的产品K8S需要的能力它刚好都有而这几个能力在通用数据库上要么缺失要么需要大量额外开发。所以K8S选etcd不是偶然是设计定位决定的。1.3 单节点etcd什么时候够用什么时候属于“没办法只能这么干”单节点etcd部署在我的日常里非常常见基本集中在三类场景本地开发学习、搭建最小化K8S实验集群、边缘或离线环境里只要一个控制面。在这些场景下单节点etcd完全够用。K8S实验环境不追求可用性只追求“能跑、能练、能观察”。而生产环境的K8S集群etcd几乎都会以三个节点起步因为单节点一旦故障整个集群的控制权就没了。这个取舍本质上是你愿意为“控制器挂一台”承受多大损失。学习环境都能接受生产环境坚决不能接受。所以这篇文章里的单节点部署本身就是一种“实验室方案”我会把其中的得与失讲明白。如果你在真实生产环境照搬我把话放前面至少组三台etcd这只是底线。2. 动手前必须搞清楚的etcd核心机制2.1 Raft协议讲成人话会议记录员和过半确认etcd内部最重要的东西就是Raft协议它负责让集群里多个节点保持一致。不想读论文的话可以把它理解成一套“全员投票的会议记录机制”。集群里会选出一个Leader叫负责人负责把大家的修改意见记成日志然后分发给每个成员。每个成员收到后确认“我记下了”当超过一半的成员都确认之后这次修改才真正生效。单节点etcd的quorum是1也就是只需要自己确认就算生效没有任何网络分裂问题写路径极短。这也是单节点etcd性能表现不错的原因之一。这里有个常识节点数设计通常取奇数三个节点允许坏一个五个节点允许坏两个。原因也很简单过半确认要求“严格超过一半”两个节点反而比一个节点更脆弱。所以生产环境一定是三五七这样的奇数组合。理解了Raft的过半机制你就会明白etcd的强一致性不是玄学是靠日志复制和投票保证的。2.2 版本选择与数据落盘规划部署etcd之前先干两件事选版本、选目录。etcd目前主流版本是3.5分支也是K8S较新版本控制面通用的选择。版本跨度不要太大太老的3.3或者太新的4.x在没有明确兼容依据前都不要碰。以我的经验看K8S官方文档里那张“每个K8S版本推荐使用的etcd版本对照表”最稳妥跟着选就行。数据目录建议放在独立磁盘上有条件优先用SSD。etcd本质上是一个写敏感的存储组件磁盘IO延迟会直接影响写响应时间进而影响K8S资源提交的延迟。单独划一个 /var/lib/etcd 目录是为了权限隔离独立磁盘则是为了性能隔离避免其他业务日志把磁盘IO占满之后整个K8S控制面跟着遭殃。单节点etcd虽然不需要应对集群通信但数据目录膨胀是必须考虑的问题。默认后端配额是2GB达到配额后etcd会进入只读模式K8S也就没法再创建新资源。这个问题我会在后面的常见问题章节里详细记录这里先记住存储空间不是越大越安心你得有一套监控和压缩方案。2.3 端口、目录和权限动手前先画一张小地图etcd占用两个端口2379是客户端通信端口K8S的API Server通过它读写数据2380是集群节点间通信端口单节点环境用不到但配置里必须保留。用一张小地图记忆2379面向外部2380面向内部。目录规划建议如下可执行文件/usr/local/bin/etcd、etcdctl配置文件/etc/etcd/etcd.conf.yml数据目录/var/lib/etcd日志交给systemd的journald统一管理权限方面我们专门建一个名为etcd的系统用户给它的权限就是数据目录的读写权。不要用root去跑etcd虽然能跑但一旦被攻破或者误操作权限边界完全不同。最小权限原则在这里同样适用。3. 单节点etcd服务部署全过程实录3.1 环境准备与二进制安装这里以一台干净的Linux服务器为例systemd作为初始化系统。单节点etcd的资源要求不高2核4G起步完全够用关键是磁盘别太慢。第一步创建系统用户和目录useradd --system --home /var/lib/etcd --shell /sbin/nologin etcd mkdir -p /var/lib/etcd /etc/etcd chown -R etcd:etcd /var/lib/etcd然后去etcd官方Release页面下载对应版本的Linux amd64压缩包。命令示例ETCD_VERv3.5.9 wget https://github.com/etcd-io/etcd/releases/download/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz tar zxf etcd-${ETCD_VER}-linux-amd64.tar.gz cp etcd-${ETCD_VER}-linux-amd64/etcd /usr/local/bin/ cp etcd-${ETCD_VER}-linux-amd64/etcdctl /usr/local/bin/ etcd --version etcdctl version熟悉Linux的直接用这种做法简单透明也方便脚本化和固化版本。用发行版仓库安装虽然省事但仓库里的版本往往偏旧跟K8S版本兼容性不一定对得上。我是偏好二进制方案的特别是在这种“我应该精确知道跑在什么版本上”的组件上。下载如果比较慢可以找靠谱的镜像加速但一定校验压缩包的sha256避免文件损坏或者篡改。3.2 写配置文件每一个字段都值得看懂etcd从3.4开始推荐使用YAML格式配置。下面是单节点环境一份最简配置name: etcd-single>