Cuốn sách Kubernetes 22 chương mà FDE không nên đọc từ trang đầu
Dồn sức vào chương 9, 10, 12, 13 và 14, rồi tự chạy từng manifest trong repo ví dụ đi kèm sách.

Tóm tắt nhanh
- Ấn bản thứ ba dày 328 trang, có 22 chương cộng phụ lục A, ebook ra ngày 2/8/2022
- Với FDE, phần cần đọc trước là các chương 9, 10, 12, 13 và 14, từ ReplicaSets tới RBAC
- Trong RBAC, update và patch là hai quyền riêng: thiếu patch thì Role có thể chặn chính lần rollout nó định cho phép
Thử hình dung tuần đầu bạn làm việc tại một khách hàng doanh nghiệp. Họ không cho bạn quyền admin cluster. Họ cấp một namespace và hỏi đúng một câu: app của bạn cần những quyền gì, và vì sao.
Muốn trả lời câu đó cho đàng hoàng, bạn cần hiểu Kubernetes từ bên trong. Kubernetes: Up and Running có hẳn một chương cho đúng chuyện này. Ấn bản thứ ba do O’Reilly xuất bản, ebook ra ngày 2/8/2022, dày 328 trang, do Brendan Burns, Joe Beda và Kelsey Hightower viết; một số nhà phân phối liệt kê thêm Lachlan Evenson.
Lời giới thiệu sách mở đầu bằng nhận định rằng Kubernetes đã thay đổi tận gốc cách lập trình viên và người vận hành build, deploy và bảo trì ứng dụng trên cloud. Đó chính là việc hằng ngày của FDE: ship phần mềm lên hạ tầng của người khác.
Nhưng sách có 22 chương cộng phụ lục A, và đọc tuần tự từ đầu đến cuối là cách nhanh nhất để bỏ dở giữa chừng. Đọc theo thứ tự những việc bạn sẽ gặp ở khách hàng thì hiệu quả hơn.
Mở thẳng chương 9, ngồi lâu đến chương 13
Nếu bạn đã dùng Kubernetes ở mức cơ bản, đừng bắt đầu từ trang một. Phần giữa sách mới là chỗ đáng tiền: chương 9 là ReplicaSets, chương 10 là Deployments, chương 12 là Jobs, chương 13 gộp ConfigMaps và Secrets. Các object chuyên biệt như DaemonSets, Jobs, ConfigMaps và Secrets nằm trong số mục tiêu học chính của sách.
Lý do đọc kỹ rất thực tế. Khi app của bạn không lên trong cluster của khách hàng, bạn sẽ phải lần qua đúng những object này: Deployment có rollout không, ReplicaSet có đủ pod không, cấu hình có được nạp từ ConfigMap không.
Đừng chỉ đọc. Repo ví dụ chính thức, kubernetes-up-and-running/examples, theo giấy phép Apache-2.0, đặt tên file theo số chương, chẳng hạn 5-1-kuard-pod.yaml. README không ghi repo ứng với ấn bản nào, nên khi một manifest lệch với trang sách, hãy coi đó là bài tập debug chứ đừng vội bỏ.
App demo của sách là kuard. Nó có một workload tổng hợp sinh khóa RSA 4096 bit để mô phỏng batch worker, một hàng đợi trong bộ nhớ có REST API, và đặt tên phiên bản bằng màu thay vì số. Bạn có sẵn thứ để thực hành rollout, batch và work queue mà không phải tự viết app.
Một bài tập cụ thể: deploy kuard bằng Deployment, đổi sang phiên bản màu khác để xem rollout, rồi xóa một pod để thấy ReplicaSet tạo lại nó. Kế tiếp, chạy workload sinh khóa dưới dạng Job và chuyển cấu hình sang ConfigMap. Chỉ một bài tập nhỏ, bạn đã đi qua bốn chương (9, 10, 12, 13).
RBAC là chương bạn dùng để thương lượng với khách hàng
Chương 14, Role-Based Access Control for Kubernetes, là chương FDE nên đọc trước buổi họp đầu tiên, vì nó chính là câu trả lời cho câu hỏi ở đầu bài.
Hai cách xin quyền tạo ra hai cuộc nói chuyện rất khác nhau. Xin cluster-admin “cho tiện” dễ khiến đội bảo mật chần chừ, vì họ không biết bạn sẽ làm gì với chừng ấy quyền. Cách còn lại là gửi một Role chỉ có hiệu lực trong namespace được cấp, mỗi nhóm quyền kèm một dòng lý do.
Chi tiết dễ sai nằm ở verb. Tài liệu Kubernetes ánh xạ HTTP PUT sang verb update và HTTP PATCH sang verb riêng là patch, nên có update không có nghĩa là được patch. Server-Side Apply gửi request dưới dạng PATCH. Một Role thiếu patch vì thế có thể chặn chính lần rollout nó định cho phép.
Lấy app kuard ở trên, chạy trong một namespace giả định tên kuard-demo:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kuard-deployer
namespace: kuard-demo
rules:
# Tự rollout bản mới của kuard (server-side apply gửi PATCH, nên cần cả patch)
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "create", "update", "patch"]
# Chạy và dọn Job sinh khóa RSA
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["create", "delete", "get", "list"]
# Xem trạng thái pod khi debug
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
# Đổi cấu hình app
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "update", "patch"]
Role này chưa gắn vào ai; bạn còn cần một RoleBinding trỏ tới tài khoản sẽ dùng nó. Trước khi gửi, hãy tự chạy thử với đúng Role đó trên cluster cục bộ: một lần apply bị từ chối ở máy bạn rẻ hơn nhiều so với ở buổi demo của khách hàng.
Yêu cầu như vậy cho đội bảo mật đủ thông tin để ra quyết định, và cho thấy bạn hiểu hệ thống của họ. Lòng tin bắt đầu từ chính tờ yêu cầu đó. Các chương sau chương 14 và phụ lục A thì cứ để đó, mở ra khi hệ thống của khách hàng thật sự chạm tới.
Biến chương sách thành dòng trong CV
Nếu bạn đang nhắm tới vai trò FDE, đừng dừng ở việc đọc xong sách. Hãy giữ lại sản phẩm của từng chương trong một repo: manifest kuard, Job sinh khóa, ConfigMap, và Role giới hạn theo namespace kèm lý do cho từng verb.
Trong CV, hãy viết một dòng kể việc bạn đã làm, chẳng hạn deploy app có batch worker lên Kubernetes với quyền RBAC tối thiểu trong một namespace. Một dòng như vậy mở đường cho người phỏng vấn hỏi sâu, chẳng hạn vì sao cần patch bên cạnh update, và bạn có sẵn repo để chỉ vào.
Cuốn sách đã ra được vài năm. Nhưng câu hỏi ở chương 14 thì sớm muộn khách hàng nào cũng sẽ đặt ra cho bạn.
Bài này có hữu ích không?
Cảm ơn bạn đã góp ý!