Cheat notes · Module 00 · Orientation

Orientation: what a platform team owns in Kubernetes

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Kubernetes stores what you declare and runs controllers that make the cluster match it. A platform team shares one cluster between teams, so every object has an owner: the platform team owns the namespace and the rules around a team, the team owns what runs inside.

Remember

Declare, then reconcile: kubectl apply sends an object to the API server, which stores it in etcd. Controllers and kubelets then make it true.
The API server is the only door. kubectl, controllers, the scheduler and every kubelet talk to it and to nothing else.
Namespace: the unit a platform team hands to a product team. Quotas, permissions and network rules attach to it.
Two folders, two owners: tenants/<team>/ (platform team), apps/<team>/ (product team). Kubernetes ignores folders; people do not.
A kind node is a Docker container: k8s-control-plane, k8s-worker, k8s-worker2. The kube context is kind-k8s.
Every namespace gets a label for free: kubernetes.io/metadata.name=<name>, which network rules select on.

Pitfalls

A node goes NotReady with no error anywhere: only a status. You see it only if you look, or if an alert does.
Changing the cluster from the wrong context. Check kubectl config current-context before every change.

Commands

`kubectl config current-context`	Which cluster you are about to change
`kubectl get nodes`	Nodes and their status
`kubectl get pods -n kube-system -o wide`	The cluster's own parts, with their nodes
`kubectl apply --dry-run=server -f FILE`	Would the API server accept it? Changes nothing
`kubectl get namespace NS --show-labels`	A namespace and its labels

tenants/checkout/namespace.yaml (module 00)

apiVersion: v1
kind: Namespace
metadata:
  name: checkout-dev
  labels:
    team: checkout

Test yourself

Answer in your head first, then open the answer.

What does kubectl apply -f namespace.yaml actually do?

It sends the object to the API server, which stores it; controllers then make the cluster match.

A node shows NotReady. What does that tell you?

The control plane stopped hearing from that node's kubelet. It says nothing yet about the pods.

Why are namespaces under tenants/ and Deployments under apps/?

Different owners: the platform team sets the rules around a team, the team decides what runs inside.

Where module 00 leaves you: A cluster kind-k8s with three Ready nodes. Your repo on GitHub holds cluster/kind.yaml and tenants/checkout/namespace.yaml. The namespace checkout-dev exists and is empty.