手把手从零搭建 Kubernetes：不靠脚本、不走捷径的硬核学习指南

你是否曾点开 kubeadm init 后，看着控制台飞速滚动的输出却一脸茫然？是否在排查 Pod 无法调度时，连 kube-apiserver 和 etcd 的通信链路都画不出来？Kubernetes The Hard Way 正是为这类困惑而生——它拒绝自动化脚本，坚持手动执行每一条命令、配置每一项证书、部署每一个组件，用“最笨”的方式带你穿透 Kubernetes 底层肌理。这不是一个用来快速上线生产集群的工具，而是一套专为深度理解设计的沉浸式实验手册。

核心功能

从零构建最小可用集群：完整搭建含 1 个控制平面节点（含 kube-apiserver、etcd、kube-scheduler、kube-controller-manager）和 2 个 worker 节点的三节点集群，覆盖所有核心组件的手动部署流程，帮你建立对 Kubernetes 架构的全局认知。
亲手实践 TLS 安全体系：从生成根证书颁发机构（CA）、为每个组件签发专属证书（如 apiserver-server、kubelet-client、front-proxy），到配置双向 TLS 认证，彻底搞懂 Kubernetes 中“谁在验证谁、凭什么是可信的”这一关键安全逻辑。
深入 etcd 集群初始化细节：手动配置 etcd 成员发现、静态节点列表、TLS 加密通信及数据持久化路径，理解 Kubernetes 状态存储的底层依赖与高可用基础，避免把 etcd 当作黑盒调用。
精细化管控 kubeconfig 文件生成：为不同角色（管理员、worker、kubectl 用户）分别生成带权限约束的 kubeconfig，明确 context、user、cluster 三要素如何协同工作，为后续 RBAC 实践打下坚实基础。
显式配置 Pod 网络路由：不依赖 CNI 插件自动注入，而是手动为每个 worker 节点添加静态路由规则（如 ip route add 10.200.0.0/24 via 10.240.0.20），直观理解 CNI 插件背后真正解决的网络可达性问题。
端到端加密数据保护：手动创建 AES-256 加密密钥、编写 data-encryption-config.yaml 并挂载至 kube-apiserver，真实启用静态数据加密（Static Encryption at Rest），掌握敏感资源（如 Secret）在 etcd 中的落盘保护机制。
跳板机（Jumpbox）隔离操作环境：强制所有部署操作必须通过独立的跳板虚拟机发起，模拟企业级运维安全边界，培养“不可直接登录生产节点”的工程习惯，而非在本地终端随意执行命令。
提供标准化清理流程：每个实验后附带 docs/13-cleanup.md，给出精准的资源销毁命令（如 gcloud compute instances delete 或 vagrant destroy），避免实验残留污染环境，养成可重复、可销毁的基础设施思维。

技术亮点

纯命令行驱动，零抽象封装：全文档不使用 Ansible、Terraform 或任何配置管理工具，所有操作均基于 Linux 基础命令（curl、openssl、cfssl、systemctl）和原始二进制文件（kubernetes v1.32.x、containerd v2.1.x、CNI v1.6.x、etcd v3.6.x），确保每一步执行效果完全透明、可追溯。
面向 ARM64 与 AMD64 双架构支持：明确要求实验环境为 ARM64 或 AMD64 物理/虚拟机，文档中所有二进制下载链接、系统服务配置均适配主流服务器 CPU 架构，规避 x86_64 兼容性陷阱，贴合云原生基础设施演进趋势。
模块化实验设计，逐层递进：13 个文档按严格依赖顺序组织（从前提准备 → 跳板机 → 计算资源 → CA → 证书 → kubeconfig → 加密密钥 → etcd → 控制平面 → Worker → kubectl 配置 → 网络路由 → 验证测试），每步仅聚焦单一目标，杜绝知识过载。
生产级组件版本锁定：明确指定各组件精确版本号（如 etcd v3.6.x），并提供对应 GitHub 发布页链接，避免因版本混用导致 TLS 协议不兼容、API 版本错位等常见故障，保障学习过程稳定可靠。
轻量级依赖，无云厂商绑定：虽以 Google Cloud（gcloud CLI）为默认示例，但所有计算资源章节均提供 Vagrant + VirtualBox 本地替代方案，用户可完全离线复现，无需注册任何云平台账号或产生费用。

适合哪些人用

本项目专为渴望穿透 Kubernetes 表层封装、直面系统本质的技术学习者打造。典型用户包括：Kubernetes 初学者在掌握 kubectl 基础命令后，希望理解 “为什么需要证书”、“Pod IP 如何被分配”、“NodeNotReady 状态背后发生了什么”；SRE/运维工程师需排查线上集群 TLS 过期、etcd leader 频繁切换、kubelet 无法注册等问题，需回溯组件间通信链路；云原生开发者正开发 Operator 或自定义控制器，需精准控制 API Server 访问策略与认证流程。

真实场景案例：某金融公司内部 Kubernetes 培训营，讲师带领学员用 2 天时间完成全部 13 个实验，随后学员能独立分析生产集群中 kube-controller-manager 日志中的 “x509: certificate signed by unknown authority” 错误，并定位到 CA 证书未同步至某 worker 节点；另一案例是 DevOps 团队在迁移至新云平台前，用该教程快速验证自建 CNI 插件与新版 containerd v2.1.x 的兼容性，绕过 kubeadm 的版本锁死限制。

快速上手

推荐使用 Vagrant 本地实验（免云账号）：

安装 VirtualBox 7.0+ 和 Vagrant 2.4+
克隆仓库：git clone https://github.com/kelseyhightower/kubernetes-the-hard-way
进入目录执行：vagrant up（自动创建 4 台 Ubuntu 22.04 虚拟机）
按文档顺序执行：cd docs && for i in $(seq -f "%02g" 1 13); do echo "=== $i ==="; cat $i-*.md | head -20; done（快速预览结构）
重点实操前 3 步：01-prerequisites.md（确认工具链）、02-jumpbox.md（SSH 登录 jumpbox）、03-compute-resources.md（vagrant ssh 切换节点）

关键命令示例（生成 kube-apiserver 证书）：
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-csr.json | cfssljson -bare apiserver

同类对比 / 注意事项

vs kubeadm：kubeadm 是“高速公路”，追求 5 分钟上线；KTHW 是“徒步登山道”，强制你看清每块岩石纹路。kubeadm 抽象了证书、etcd、网络等细节，而 KTHW 将其全部展开——二者非替代关系，而是“先学 KTHW，再用 kubeadm”的黄金组合。
vs Kelsey 自己的其他教程：不同于其广为人知的《Kubernetes Up and Running》图书，KTHW 不讲概念、不给结论，只给命令和预期输出，逼迫读者主动思考“这行命令改了哪个配置？影响哪个组件？”
重要注意事项：文档明确声明“结果非生产就绪”，例如单节点控制平面无高可用、未配置审计日志、未启用 admission webhook 等；实验中所有证书有效期默认设为 1 年，切勿直接用于生产；ARM64 环境需额外验证 containerd v2.1.x 的 systemd 服务模板兼容性。