简介：《Kubernetes in Action》中文版是容器编排领域的经典译作，由七牛容器云团队翻译，Manning原版引进，适合初中级开发者系统学习Kubernetes。全书从Docker与Kubernetes的起源与演进讲起，结合“部署一个应用”的具体场景，逐步深入集群架构、部署升级、服务发现、负载均衡等核心机制，并覆盖监控、调试、伸缩等生产环境必备技能，同时穿插数据中心操作系统、Plan9等历史背景，帮助读者理解K8s为何成为容器编排的事实标准。这份PDF为全书中译本，共1个PDF文件，压缩包约15.62MB，排版与纸质版一致，支持全文检索与划线批注，便于在桌面或移动端碎片化学习，也适合用作随查随用的参考手册。目前已有1204人浏览/下载，是快速建立K8s知识体系、提升云原生实践能力的高性价比参考资源，中文版更降低了英文原版的阅读门槛。
1. 从“会敲命令”到“敢讲原理”，这份 PDF 为什么适合拿来当主线教材
第一次接触 Kubernetes 时，我手里全是别人给的 YAML，kubectl apply和kubectl delete早就点熟了，真到集群出问题却又不知道先看哪条日志。把 Kubernetes in Action 中文版.pdf 当作主线教材补了一遍之后，Pod 为什么是调度原子、Deployment 靠什么控制副本、Service 的负载均衡由谁完成，这些默认值背后的设计意图才算真正落地。这份 PDF 不是命令速查手册，它先用容器运行机制铺垫，再一路推到控制器和调度器，最后落到网络与存储；适合刚从文档堆里走出来的开发者，也适合准备系统考证、想把知识点串成体系的人。如果你已经能用 Docker 跑容器，却说不清 K8s 里的调度和自愈是怎么发生的，这本书就是那条能把你串起来的线。
2. 这本书的“线”长什么样：从容器运行到集群调度的推演逻辑
2.1 为什么主线是先懂运行机制，再学操作命令
大部分入门资料按任务组织：要发一个应用，先写 Deployment；要访问，再写 Service。这本书相反，它先解释容器里跑起来的是什么——镜像、层、命名空间、cgroup 这些底层的隔离和限制手段，然后再讲 K8s 为什么把 Pod 当作最小调度单元。没有这一步铺垫，后面读 Pod 的内容，往往只会记住“一个 Pod 可以放多个容器”，却不知共享网络栈和存储卷意味着哪些设计取舍。
书中把控制器循环描述成“期望状态 vs 实际状态”的连续收敛过程，这一点会贯穿全书。第一次读时，我最大的收获不是记住了几个 YAML 字段，而是明白 kubectl 只是对着某个期望状态发请求，真正负责干活的是 kube-controller-manager 和 kube-scheduler。带着这个思路，再去看官方文档的架构页，每一段都能对得上。
这里的关键价值是建立检索顺序：生产环境遇到问题，先判断是哪一层——Pod 没起来是调度和镜像问题，网络不通是 Service 与 Endpoint 问题，存储没挂上则要看卷供应。书按这条线展开，读者天然获得分层排查的框架，而不是在 kubectl describe 输出里乱翻。所以我不建议跳过开头直接抄 YAML，那样后面遇到 CrashLoopBackOff 时，会连日志从哪里看起都不知道。
2.2 中文术语与原文术语对照：读 PDF 时先把这组词标好
中文版在多数章节翻译流畅，但术语是重灾区；同一概念在书里和 kubectl 命令里经常是两种写法。我的常见做法是：一边读中文，一边在 PDF 上标注英文原词，后续查命令和写 YAML 都以英文原词为准。常用对照关系我列在下面，这也是我读第二遍时做的第一件事。
| 书里常见中文 | 英文原文 | 出现的场景 |
|---|---|---|
| 副本集 | ReplicaSet | 控制一组完全相同的 Pod |
| 部署 | Deployment | 管理发布和滚动更新 |
| 服务 | Service | 提供稳定访问入口与负载均衡 |
| 探针 | Probe | 存活、就绪、启动三类检查 |
| 容忍 | Toleration | 与节点污点配合影响调度 |
| 驱逐 | Eviction | 资源压力或节点异常时移走 Pod |
建议你在读每章前，把这一章的术语抄到一页纸笔记里。阅读时发现“服务”这个词被用了两种语义——ClusterIP 服务和整套微服务——立刻暂停，看英文语境里写的是 Service 还是一个泛指概念。这种“双语交叉验证”的习惯，能让你在后续写 YAML 时少犯很多低级错误。
2.3 这本书的边界和补齐路径：官方文档应该以什么身位出现
这本书覆盖了单集群运维的主干内容，但它不是参考资料。它不会把每个 API 字段都展开，也不会记录特性演进的时间线；举一个常见例子：网络策略在书里只是一章，真要配置允许或拒绝规则时，字段细节仍要回到官方文档的 NetworkPolicy 页。
我一般把书当主线，官方文档当“字典”用。顺序是先读一个核心章节，随后在官方文档里只查这个对象的最新字段，不往下铺开。另一个高质量搭配是按版本查“已废弃 API 清单”：书出版时间带有一定的版本印记，这些清单能快速暴露哪些定义已经过时。特别是 Ingress、PodSecurityPolicy 这类对象，字段变化幅度大，很容易在自建集群上翻车。
如果你只有一次认真读文档的机会，我建议把时间花在两个地方：一个是kubectl explain对某个对象的字段解释，另一个是版本发布说明里的废弃列表。前者解决“这个字段还有没有”，后者解决“我该不该换写法”。把这两个工具和书的主线配在一起，就不会掉进“看书全会、上手全废”的坑。
3. 用这份 PDF 做主线的最低实操闭环：一台笔记本就能跑通
3.1 环境选型：minikube、kind 和 kubeadm 怎么选
边看书边敲命令，离不开一个本地集群。三选一即可支撑学习：
| 方案 | 定位 | 适合场景 | 代价 |
|---|---|---|---|
| minikube | 开箱即用的单机集群 | 按章节学习、验证 Pod/Service | 额外占用内存 |
| kind | 以容器跑节点 | CI 和快速重建场景 | 网络功能需要额外配置 |
| kubeadm | 生产一致的部署方式 | 演练证书、高可用、升级 | 初始化步骤多 |
我推荐先选 minikube，原因很直接：书中高频操作集中在 Pod、Deployment、Service 上，minikube 能把存储类、内置 DNS、控制面组件都提前配好，省掉网络插件对学习的干扰。等你把书里主流程走完一遍，再用 kubeadm 重建一套集群，前后对比就能体会到“生产环境比学习环境多出来的配置到底是什么”。
# 先确认本机 Docker 可用，再启动一个单节点集群 minikube start \ --driver=docker \ --cpus=4 \ --memory=6144 \ --kubernetes-version=v1.30.3参数说明：--driver=docker表示复用本机 Docker 作为驱动，比虚拟机驱动启动更快；--cpus和--memory要根据电脑实际配置下调，内存不足会导致 etcd 频繁重启，这时看minikube logs最直接。--kubernetes-version不建议盲目写最新版，先用minikube version查看默认版本，再选一个与当前书籍配套版本接近的 v1.30 左右的稳定版。启动失败时，优先看minikube status与minikube logs --file=-，多数问题集中在内存不足或镜像拉取。
3.2 从副本控制到第一个 Deployment：字段再少也要敲一遍
在书本里“Deployment 驱动 ReplicaSet”这一段，最有效的验证就是亲手写一个最小 YAML。核心只有三个部分：头部声明、期望副本数、Pod 模板。
apiVersion: apps/v1 # 早期书里可能是 extensions/v1beta1，这里用当前稳定版 kind: Deployment metadata: name: web-demo # 部署名；kubectl 命令里会直接引用 spec: replicas: 3 # 期望的副本数，控制器会一直纠正到 3 selector: matchLabels: app: web-demo # 选中模板 Pod 的标签 template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.25-alpine ports: - containerPort: 80 resources: # requests 用于调度，limits 用于运行时限制 requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi这段 YAML 的逻辑关系是：Deployment 声明“我要 3 个带 app=web-demo 标签的 Pod”，ReplicaSet 负责保障数量，调度器负责把 Pod 放到节点上。selector.matchLabels必须与模板里的标签一致，这是 Deployment 能“认清自己孩子”的依据，漏掉任何一个都会导致控制器拒绝创建。
# 推送期望状态 kubectl apply -f deployment.yaml kubectl rollout status deployment/web-demo kubectl get pods -l app=web-demo -o wide kubectl logs deployment/web-demo --tail=20四条命令各有分工：apply 把期望状态提交给 API Server，rollout status 显示发布是否完成，get 带-o wide能同时看到 Pod 所在节点与 IP，logs 则直接看应用输出。如果 Pod 一直处于 ContainerCreating，先别急着查 logs，用kubectl describe pod看事件，镜像拉取失败和存储卷挂载问题都会在那里出现。
3.3 把书的示例变成自己的练习：三个能立刻触发的方向
直接照抄示例很难有手感，先做三个必改练习：
第一处，把replicas从 3 改成 0，观察kubectl get rs的输出，再恢复成 3，看控制器如何补齐副本；这是“期望状态”最直观的一次演示。第二处，手动删除一个 Pod，观察 ReplicaSet 在几秒内重新创建，这是自愈能力的直接体现。第三处，给容器加上探针，人为制造健康检查失败，看 Pod 被标记为未就绪或反复重启。
livenessProbe: # 存活探针：失败会重启容器 httpGet: path: /healthz port: 80 initialDelaySeconds: 5 periodSeconds: 10 readinessProbe: # 就绪探针：失败时从 Endpoint 摘除 httpGet: path: /readyz port: 80 initialDelaySeconds: 3 periodSeconds: 5字段含义不要抄错：initialDelaySeconds是容器启动后等几秒再开始检查，periodSeconds是每隔几秒检查一次。这里的探针路径必须真实存在，否则 Pod 会一直重启；这也是故意制造故障的好方法。读到这里，把“探针决定路由”这句话和刚才看到的现象联系起来，比单纯背诵字段解释有用得多。
4. 读这份 PDF 的避坑记录：版本错位、术语偏差和 YAML 缩进三类高频翻车
4.1 现象：按书里的方式初始化集群，kubelet 一直 NotReady
现象：用 kubeadm init 之后，节点几分钟内依然 NotReady，日志里反复报容器运行时的 cgroup 驱动和 kubelet 期望不一致。
原因：这本书早期内容写成的时代，容器运行时默认配置与今天不同。当前版本的 containerd 默认关闭SystemdCgroup，而 kubelet 主推 systemd 作为 cgroup 驱动，两端不一致会导致 Pod Sandbox 创建失败，最终节点状态异常。
解决：修改 containerd 配置，把SystemdCgroup打开，再重启容器运行时和 kubelet。
# 将 containerd 的 systemd cgroup 开关打开 sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml sudo systemctl restart containerd sudo systemctl restart kubelet这条命令只对 containerd 生效；如果节点用的是其他运行时，先执行grep -n SystemdCgroup /etc/containerd/config.toml确认配置键位置，再手动改动。这类问题不是玄学，多数环境的差异就出在这类“两侧驱动不一致”上；等以后再经历一次集群初始化，这会是你的第一个检查项。
4.2 现象：中文翻译和命令字段对不上，查参数时找不到入口
现象：看着“探针”“容忍”这些词能明白意思，在 kubectl 命令里却不知道参数应该叫 probe 还是 toleration，于是只能反查。
原因：Kubernetes 的命令和 YAML 字段是 API 层面的英文词汇，中文书更倾向用习惯词汇翻译。术语本身不是问题，真正的问题是术语表没有边界，读者不知道哪些词必须回到英文语境里理解。
解决：读每个核心对象前，先用kubectl explain把字段名过一遍，再继续看书。这样你把中文概念和实际命令桥接起来，后续排错时就能直接定位。
kubectl explain deployment.spec.template.spec.containers kubectl explain pod.spec.tolerations第一个命令会展开容器字段，里面能看到探针、资源、端口等结构的完整解释；第二个命令则显示容忍字段的对偶结构。目的不只是查参数，而是建立你的“术语桥”：一旦中文描述有歧义，以kubectl explain的输出为最终标准。
4.3 现象：书里的 YAML 提交以后报 no matches for kind
现象：按书里抄录一份 Ingress，执行kubectl apply返回错误，提示no matches for kind "Ingress"。
原因：旧版 Kubernetes 把 Ingress 放在extensions/v1beta1API 组里，新版本已经完全移除了该入口；YAML 头部还在用旧 apiVersion，因此创建请求无法匹配到任何资源类型。
解决：先查出当前集群支持的资源写法，再手工调整 apiVersion 和相关字段。
# 当前 k8s 版本支持的资源清单 kubectl api-resources | grep ingress # 查看 ingress 当前字段说明 kubectl explain ingress处理时注意：新版 Ingress 还引入spec.ingressClassName字段，要求提前建好 IngressClass。这是字段迁移时常见的连环改动，不是改一行 apiVersion 就完事。遇到这类报错，先看错误最后一行，再判断是不是 API 变更，避免把整个 YAML 重写一遍。
4.4 现象：从 PDF 复制出来的 YAML，apply 一直报缩进错误
现象：明明内容没少，复制到终端后kubectl apply -f立刻报错，不是error parsing就是did not find expected key。很多人会选择把缩进全部删掉重敲，一改就错。
原因：PDF 只负责排版，不负责保留代码的结构。自动折行和字符间距会让缩进在视觉上看起来一致，但复制出来可能混入全角空格；YAML 语法对空格种类数量都敏感，于是解析直接失败。
解决：粘贴后用一个能显示空格的编辑器打开，开启“显示空格”和“显示制表符”，把全角空格统一替换成半角空格，再把每级缩进固定成两个空格。
# 错误：前两行看起来对齐，实际混入了 tab 和全角空格 spec: template: spec: containers: - name: nginx # 正确：每层用两个半角空格递进 spec: template: spec: containers: - name: nginx这个错误 kubectl 不会告诉你具体在哪一行，只能靠编辑器定位。我习惯在保存前执行一次 YAML 格式化，再看 diff；如果格式化前后的变化很大，说明原文缩进本来就有问题。把这一步固定成流程，就能避开“从 PDF 复制—粘贴—跑不通”的连锁反应。
5. 从“读完整本 PDF”到“拥有自己的集群”：四个动作完成知识迁移
5.1 第一遍精读只留四条主线，其余先扫
第一遍阅读不必追求每章都细。重点抓住四条主线：Pod 生命周期、Deployment 演化、Service 寻址、存储与配置抽象。
为什么是这四个？生产环境里大多数故障都围绕这几个点展开：Pod 起不来、流量到不了、存储没挂上、配置随版本漂移。书里关于调度、安全、扩展控制器的章节，完全可以放到第二遍再读。第一遍拆得太细，容易被细节淹没，后面章节反而失去耐心。
每条主线读完后，用自己的话写一小段总结。Pod 生命周期这一段应当解释为什么调度和健康检查是相关联的；Deployment 演化这一段应当能说清滚动更新和回滚的分工。把时间花在“你能讲得清楚的部分”上，剩下不太明白的内容标注出来，让第二遍阅读变得更有针对性。
5.2 用三个核心对象搭一个“最小可运行系统”
把部署抽象成 Deployment + Service + ConfigMap 组成一条数据通路，书中的很多概念就会发生关联。设定一个模拟项目X：跑一个 web 服务，从一个 ConfigMap 里读取环境变量，经由 Service 暴露给本机访问。先把配置对象推上去：
kubectl create configmap web-config \ --from-literal=APP_MSG=hello \ --dry-run=client -o yaml | kubectl apply -f -这里用了--dry-run=client -o yaml的原因在于：先看要生成的 YAML 再实际应用，避免手写 ConfigMap 时出现字段拼写问题。它的核心逻辑是，配置变更不需要重新打包镜像，只需要更新 Pod 环境变量即可生效。
接着创建一个 Service，把流量入口固定下来。
apiVersion: v1 kind: Service metadata: name: web-demo-svc spec: selector: app: web-demo ports: - port: 80 targetPort: 80字段说明：selector是流量路由依据，它必须与 Deployment 模板里的 label 完全匹配，Service 才能发现端点；port是服务暴露端口，targetPort是容器端口。apply 后用kubectl get endpoints web-demo-svc观察端点列表，如果是空的，先检查标签是否写错。这个最小系统跑通以后，再往里面加存储卷和探针，就会发现书里的知识都串起来了。
5.3 把书里的排查过程变成命令习惯：describe、events 和日志怎么串起来
书里讲状态和故障的地方，落到命令上是三段式习惯。第一段，kubectl get pods先看整体状态；第二段，kubectl describe pod <名称>看事件和最近的状态迁移；第三段，kubectl logs看容器实际输出。绝大多数问题都能在这个循环里定位。
社区常犯的毛病是只盯着 logs 看，但 Pending、ImagePullBackOff、CrashLoopBackOff 这三类高频问题，答案往往藏在事件里。Pending 多半是调度不满足，ImagePullBackOff 是镜像拉取失败，CrashLoopBackOff 则需要结合日志看退出原因——而这一切几乎都能从kubectl describe里读到第一手信息。
另一个好习惯是查看容器上一次退出时的日志：
kubectl logs <pod-name> --previous这个命令专门用来看容器重启前的输出。CrashLoopBackOff 的情况下，当前日志往往只有一行启动报错，上一次的日志反而记录了完整的堆栈或数据库连接失败信息。把这些习惯固定下来，再回头看书里的故障章节，你会发现作者讲的正是这套排查节奏。
6. 验收：合上书以后，用十分钟的“断网排查”检验自己有没有学会
6.1 先回答三个问题
把这本书的 PDF 合上，面对一个“Pod 卡在 Pending”的小故障，你能说出先去查调度、镜像还是资源？我给自己设计的验收方式是三题：副本数与期望不符时谁会纠正它；Pod CrashLoopBackOff 时先看日志还是事件；Service 没有端点就绪时流量会怎样。能脱口而出“ReplicaSet 会纠正”“先看 describe 再查日志”“没有端点流量就断掉”，这一遍才勉强过关。
这三题正好对应书里最重要的三块内容：控制器、监控诊断、网络入口。答不上来就翻对应章节，翻完再答一遍，比从头再看第二遍效率高很多。
6.2 三次断网排练，建立肌肉记忆
我习惯把本地集群模拟成故障现场，按书里的思路做断网排查。
# 故障现场：只见状态，不带任何参考资料 kubectl get pods -o wide kubectl describe pod <pod-name> kubectl get events --sort-by=.lastTimestamp三个命令各看各的层次：get 看整体状态，describe 看单 Pod 的调度与事件，events 按时间排序看全局动态。用它们组成闭环，可以逐步把集群状态还原为应用日志结论。做完一次，在笔记里记下“我在哪一步绕了弯路”。
连续做三次以后，那些在第二章里还像概念一样的控制器、标签、端点，就会变成排障时的反应记忆。我也把这个排练固定成每次迁移环境之前的常规项目：在新集群上部署一套最小服务，跑一次探针故障，确认自己能按这个顺序找到根因，再开始做正事。你可以先不追求速度，先把三步走顺，再慢慢压缩时间。希望帮到你。
本文还有配套的精品资源，点击获取
