Chapter 1 of 6 · 5 practices · 5 min · 4-question quiz
Workloads and manifests
How to describe an application so the cluster can manage it: controllers instead of bare Pods, consistent labels, exact image references and manifests kept in version control.
Start: Run Pods through a controller, never as bare Pods5 practices in this chapter
- 1Run Pods through a controller, never as bare PodsA Pod created on its own is not rescheduled if its node fails or is drained. The Kubernetes configuration guide says not to use naked Pods when you can avoid it, because nothing recreates them.
- 2Label every object with the recommended app labelsServices, Deployments, PodDisruptionBudgets and NetworkPolicies all find Pods through label selectors. Inconsistent labels lead to Services that route to nothing, budgets that protect the wrong Pods…
- 3Reference images by an exact version or digest, never latestWith
:latestor no tag, you cannot tell which build is running, a rollback may pull the same broken image again, and two nodes can run different code under the same manifest. The Kubernetes… - 4Keep manifests in version control and apply them declarativelyChanges made with
kubectl editorkubectl scaleon a live cluster are invisible to review and vanish the next time someone applies the files. The configuration guide says never to apply manifests… - 5Use namespaces to separate teams, apps and trust levelsNamespaces are where RBAC bindings, ResourceQuotas, LimitRanges, Pod Security labels and default-deny NetworkPolicies attach. Putting everything in
defaultleaves you nowhere to hang those controls.
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.