diff --git a/pilot/arc.tpl.html b/pilot/arc.tpl.html index de551e3..fa635f5 100644 --- a/pilot/arc.tpl.html +++ b/pilot/arc.tpl.html @@ -55,9 +55,9 @@
+

A note on the commands: this site uses oc, + OpenShift's CLI. Everything shown works identically with kubectl - + oc is a superset that adds OpenShift's own verbs. Read + kubectl in the docs, type whichever your cluster gives you.

An image got built - of what, exactly? Pushed - to where, and what travelled? Applied - which is not the same as launched. Running - according to whom? Every course below takes one of those words apart. The armour is already loose.

@@ -95,15 +99,32 @@
-

A stack of diffs wearing a name

+

A container is a process, not a machine

+

If you arrived here from Linux, take this translation first: a running container is an + ordinary process on your kernel. No guest OS, no hypervisor. The kernel gives it + namespaces so it sees its own PID tree, mounts, network and hostname, and + cgroups so its CPU and memory can be capped. ps on the host + lists it. kill on the host kills it. Podman leans into that: no + daemon sits in the middle - the container is a child of your own shell - and rootless mode + maps your user onto root inside the container through a user namespace, so root in + there is an unprivileged UID out here.

+

So what does the image provide? The filesystem that process sees. That is the whole + job, and it is why an image is a stack of layers rather than a disk image.

+ +

What the image actually is

An image is not a copy of a machine. It is a stack of read-only layers, each recording only what changed from the one beneath. Layers are content-addressed, so an identical layer is stored once and reused by every image that references it, so a pull only fetches the layers you do not already have. A base sits at the bottom, your dependencies on it, your code - usually the smallest layer, always the most volatile - above that.

-

The top slab in the scene is the odd one out: the writable layer is not part of the - image. The runtime adds it when it creates the container, and discards it when - that container dies. Nothing written there ships, and nothing written there survives.

+

Those layers become one filesystem through a union mount - overlayfs, the same + kernel feature you can mount by hand. The read-only image layers are the lower dirs; the + container gets a fresh upper dir of its own. Writes land in the upper, and editing an + existing file copies it up there first, leaving the image layer untouched underneath.

+

That upper dir is the top slab in the scene, and it is the odd one out: the writable + layer is not part of the image. The runtime creates it with the container and + discards it when that container dies. Nothing written there ships, and nothing written there + survives - which is the entire reason volumes exist.

Change a layer and every layer above it must be rebuilt.

The order is a caching decision

The builder caches layer by layer, and a cached layer survives only while everything @@ -159,8 +180,23 @@

Field note. If you are SSHing into nodes to "fix" things, you are arm-wrestling the reconciler - and it does not get tired. Change the desired state instead.

-

Everything the delivery arc teaches from Course VI onward is this loop - wearing bigger clothes - git as the desired state, whole fleets as reconciled objects. +

What the control plane is made of

+

"Control plane" is four processes and a database, and naming them makes every later error + message readable. The api-server is the only door: everything authenticates, is + authorised and is admitted there, and it is the only component allowed to touch etcd - + the key-value store holding the entire cluster state. Lose etcd and you have lost the + cluster, which is why backing it up is the homework nobody should skip. The scheduler + decides which node a new pod belongs on and writes that decision down; it never starts + anything. The controller-manager runs the reconciliation loops. Nothing talks + sideways - every component watches the api-server.

+

One of those loops is the chain you will debug most: a Deployment creates a + ReplicaSet, and the ReplicaSet creates pods. That is why the deploy in the + aperitif printed deployment.apps/api created and you then went + looking for a pod - and why, when a rollout is stuck with no pod at all, the answer is + upstream in that chain rather than on any node.

+

etcd is the truth. Everything else is a cache of it.

+

Everything the delivery arc teaches from Course VI onward is the same + loop at a bigger scale - git as the desired state, whole fleets as reconciled objects. Learn the promise once; it repeats all the way up.

Pre-reads: C-I  Further: Kubernetes overview · @@ -496,7 +532,7 @@

Course VIII · Helm

-

A chart is a function.
The values file is the cluster speaking.

+

Stop copying YAML between clusters.
Ship the function instead.

The default way to run one app on five clusters is five copies of the YAML, and the default result is five slightly different apps. The inversion: stop copying outputs and ship the function. A chart is a template with holes; each cluster supplies one small values @@ -514,7 +550,7 @@

-

It's Go under the braces

+

You are writing a program, not YAML

Helm templates are Go text/template: {{ .Values.device.address }} is a pipeline walking a values object, _helpers.tpl holds the named templates - the partials every manifest includes, not @@ -648,7 +684,7 @@