The 22-chapter Kubernetes book FDEs should not read from page one

Picture your first week at an enterprise customer. They will not give you cluster admin. They hand you a namespace and ask exactly one question: what permissions does your app need, and why?

To answer that properly, you need to understand Kubernetes from the inside. Kubernetes: Up and Running has a whole chapter on precisely this. The third edition, published by O’Reilly, came out as an ebook on 2 August 2022. It runs to 328 pages and is written by Brendan Burns, Joe Beda and Kelsey Hightower; some distributors also list Lachlan Evenson.

The book’s description opens with the claim that Kubernetes has radically changed the way developers and operators build, deploy and maintain applications in the cloud. That is the daily work of an FDE: shipping software onto someone else’s infrastructure.

But the book has 22 chapters plus Appendix A, and reading it front to back is the quickest way to abandon it halfway. It works better read in the order of the problems you will meet at a customer.

Go straight to chapter 9 and stay through chapter 13

If you already use Kubernetes at a basic level, do not start on page one. The middle of the book is where the value is: chapter 9 covers ReplicaSets, chapter 10 Deployments, chapter 12 Jobs, and chapter 13 combines ConfigMaps and Secrets. Specialised objects such as DaemonSets, Jobs, ConfigMaps and Secrets are among the book’s main stated learning goals.

The reason to read these closely is practical. When your app will not come up in a customer’s cluster, these are exactly the objects you will have to trace through: did the Deployment roll out, does the ReplicaSet have enough pods, is the configuration being loaded from the ConfigMap?

Do not just read. The official examples repo, kubernetes-up-and-running/examples, licensed under Apache-2.0, names its files by chapter number, for example 5-1-kuard-pod.yaml. The README does not say which edition the repo corresponds to, so when a manifest differs from the page, treat it as a debugging exercise rather than a reason to give up.

The book’s demo app is kuard. It includes a synthetic workload that generates 4096-bit RSA keys to simulate a batch worker, an in-memory queue with a REST API, and versions named after colours rather than numbers. That gives you something ready-made to practise rollouts, batch jobs and work queues without writing your own app.

One concrete exercise: deploy kuard with a Deployment, switch to a different colour version to watch the rollout, then delete a pod to see the ReplicaSet recreate it. Next, run the key-generation workload as a Job and move the configuration into a ConfigMap. One small exercise takes you through four chapters (9, 10, 12, 13).

RBAC is the chapter you negotiate with

Chapter 14, Role-Based Access Control for Kubernetes, is the one an FDE should read before the first meeting, because it is the answer to the question at the top of this piece.

Two ways of asking for permissions lead to two very different conversations. Asking for cluster-admin “to keep things simple” tends to make the security team hesitate, because they cannot tell what you will do with that much power. The alternative is to send a Role that applies only within the namespace you were given, with a one-line reason for each group of permissions.

The detail that is easy to get wrong is the verb. The Kubernetes documentation maps HTTP PUT to the update verb and HTTP PATCH to a separate verb, patch, so having update does not mean you can patch. Server-Side Apply sends its requests as PATCH. A Role without patch can therefore block the very rollout it was meant to allow.

Take the kuard app above, running in a hypothetical namespace called kuard-demo:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kuard-deployer
  namespace: kuard-demo
rules:
  # Roll out new kuard versions ourselves (server-side apply sends PATCH, so patch is needed too)
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch"]
  # Run and clean up the RSA key-generation Job
  - apiGroups: ["batch"]
    resources: ["jobs"]
    verbs: ["create", "delete", "get", "list"]
  # Inspect pod status while debugging
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
  # Change app configuration
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "update", "patch"]

This Role is not yet bound to anyone; you still need a RoleBinding pointing at the account that will use it. Before sending it, test it yourself with exactly that Role on a local cluster: an apply rejected on your own machine costs far less than one rejected during the customer’s demo.

A request like this gives the security team enough information to make a decision, and shows that you understand their system. Trust starts with that request. The chapters after 14 and Appendix A can wait; open them when the customer’s system actually touches those topics.

Turn the chapters into a line on your CV

If you are aiming for an FDE role, do not stop at finishing the book. Keep what each chapter produces in a repo: the kuard manifests, the key-generation Job, the ConfigMap, and the namespace-scoped Role with a reason for each verb.

On your CV, write one line describing what you did, for example deploying an app with a batch worker to Kubernetes with minimal RBAC permissions in a single namespace. A line like that invites an interviewer to dig deeper, say into why patch is needed alongside update, and you have a repo ready to point to.

The book has been out for a few years. But the question in chapter 14 is one every customer will put to you sooner or later.