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

> 重点读第 9、10、12、13、14 章，再用配套示例仓库亲手跑一遍每个清单。

原文: https://fdetimes.net/zh/books-courses/kubernetes-up-and-running-fde-reading-guide/

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

要答好这个问题，你得从内部理解 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` 的命名空间里：

```yaml
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 章里的那个问题，每个客户迟早都会问你。

**本周动手试试:**

- 克隆 kubernetes-up-and-running/examples 仓库，搭一个本地集群，运行第 9、10、12、13 章编号的清单
- 用 Deployment 部署 kuard，删掉一个 Pod 观察 ReplicaSet 重建它，再把 RSA 密钥生成负载作为 Job 运行
- 为你的应用写一个限定命名空间的 Role，写明每个动词的理由，并确认同时包含 patch 和 update

## 信源

- [Kubernetes: Up and Running, 3rd Edition – Ebookpoint](https://ebookpoint.pl/hview5513/e_2utg_ebook.htm)

- [Kubernetes: Up and Running (Burns) – Schweitzer Online](https://www.schweitzer-online.de/en/ebook/Burns/Kubernetes-Up-Running/9781098110154/A64851561/)

- [kubernetes-up-and-running/examples – GitHub](https://github.com/kubernetes-up-and-running/examples)

- [kubernetes-up-and-running/kuard – GitHub](https://github.com/kubernetes-up-and-running/kuard)

- [Authorization – Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)

- [Server-Side Apply – Kubernetes documentation](https://kubernetes.io/docs/reference/using-api/server-side-apply/)