这本 22 章的 Kubernetes 书，FDE 别从第一页读

设想你在一家大型企业客户的第一周。对方不会给你集群管理员权限，只给你一个命名空间，然后只问一个问题：你的应用需要哪些权限，为什么？

要答好这个问题，你得从内部理解 Kubernetes。《Kubernetes: Up and Running》专门有一章讲的正是这件事。这本书由 O’Reilly 出版，第三版电子书于 2022 年 8 月 2 日推出，共 328 页，作者为 Brendan Burns、Joe Beda 和 Kelsey Hightower；部分发行渠道还列出了 Lachlan Evenson。

书的简介开篇就说，Kubernetes 彻底改变了开发者和运维人员在云上构建、部署和维护应用的方式。这正是前线部署工程师（FDE）的日常：把软件交付到别人的基础设施上。

但这本书有 22 章外加附录 A，从头读到尾，最容易半途而废。更好的读法，是按你在客户现场会遇到的问题顺序来读。

直接跳到第 9 章，一直读到第 13 章

如果你已经会基本使用 Kubernetes，就别从第一页开始。这本书的价值在中段：第 9 章讲 ReplicaSet，第 10 章讲 Deployment，第 12 章讲 Job，第 13 章合讲 ConfigMap 和 Secret。DaemonSet、Job、ConfigMap、Secret 这类专用对象，本就是书中明确列出的主要学习目标。

精读这几章的理由很实际。应用在客户集群里起不来时，你要逐个排查的正是这些对象：Deployment 发布成功了吗？ReplicaSet 的 Pod 数量够不够？配置有没有从 ConfigMap 加载进来？

不要只读。官方示例仓库 kubernetes-up-and-running/examples 采用 Apache-2.0 许可，文件按章节编号命名，例如 5-1-kuard-pod.yaml。README 没有说明仓库对应哪一版，所以当清单和书页内容不一致时，把它当成一次调试练习，而不是放弃的理由。

书中的演示应用叫 kuard。它自带一个生成 4096 位 RSA 密钥的合成负载，用来模拟批处理 worker；一个带 REST API 的内存队列；版本用颜色命名，而不是数字。这样不用自己写应用，就能直接练发布、批处理任务和工作队列。

一个具体练习：用 Deployment 部署 kuard，切换到另一个颜色版本观察发布过程，再删掉一个 Pod，看 ReplicaSet 把它重建出来。接着把密钥生成负载作为 Job 运行，并把配置移到 ConfigMap 里。一个小练习就覆盖了四章（9、10、12、13）。

RBAC 是你拿来谈判的那一章

第 14 章《Role-Based Access Control for Kubernetes》是 FDE 应该在第一次会议前读完的一章，因为它回答的正是开头那个问题。

两种申请权限的方式，会带来截然不同的对话。为了“省事”直接要 cluster-admin，往往会让安全团队犹豫，因为他们看不出你会拿这么大的权限做什么。另一种做法是发过去一个只在分配给你的命名空间内生效的 Role，并为每组权限附上一句理由。

最容易出错的细节是动词。Kubernetes 文档把 HTTP PUT 对应到 update 动词，把 HTTP PATCH 对应到另一个独立动词 patch，所以有 update 不代表能 patch。Server-Side Apply 发出的请求是 PATCH。因此，缺少 patch 的 Role 可能恰好挡住它本该放行的发布。

以上面的 kuard 应用为例，假设它运行在名为 kuard-demo 的命名空间里：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kuard-deployer
  namespace: kuard-demo
rules:
  # 自行发布 kuard 新版本（server-side apply 发送的是 PATCH，所以也需要 patch）
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch"]
  # 运行并清理 RSA 密钥生成 Job
  - apiGroups: ["batch"]
    resources: ["jobs"]
    verbs: ["create", "delete", "get", "list"]
  # 调试时查看 Pod 状态
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
  # 修改应用配置
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "update", "patch"]

这个 Role 还没有绑定到任何人，你还需要一个 RoleBinding，指向将使用它的账号。发出之前，先在本地集群上用这个 Role 原样测一遍：在自己机器上被拒绝的 apply，代价远小于在客户演示时被拒绝。

这样的申请能给安全团队足够的信息做决定，也表明你理解他们的系统。信任就从这份申请开始。第 14 章之后的章节和附录 A 可以先放一放，等客户系统真正涉及这些主题时再翻开。

把章节变成简历上的一行

如果你的目标是 FDE 岗位，别止步于读完这本书。把每一章的产出都保存在一个仓库里：kuard 的清单、密钥生成 Job、ConfigMap，以及限定在命名空间内、每个动词都附有理由的 Role。

在简历上用一行写清你做了什么，例如：将带批处理 worker 的应用部署到 Kubernetes，在单一命名空间内仅使用最小 RBAC 权限。这样一行字会引导面试官深挖，比如问你为什么 update 之外还需要 patch，而你正好有现成的仓库可以展示。

这本书已经出版好几年了。但第 14 章里的那个问题，每个客户迟早都会问你。