cluster: OpenShift-first narrative - oc as the command language, scope panel reframed, node investigation via oc describe/debug, generic-model caption on Course II

This commit is contained in:
2026-08-25 17:25:01 +10:00
parent cf0295383b
commit 8f2224deca
2 changed files with 15 additions and 7 deletions
+14 -7
View File
@@ -32,6 +32,9 @@
<p>The Exploded Cluster teaches how modern container platforms work by taking them apart,
literally. Each course is one machine drawn as a single exploded illustration, sliced into its
real components and wired to your scroll, so the architecture moves while the words explain it.
OpenShift is the teaching lens. <span class="mono">oc</span> is the command language. Kubernetes
primitives explain the machinery underneath. Occasional lab notes show a separate Kubernetes
environment where a concept was observed; they are not a claim that the lab runs OpenShift.
Start with the aperitif&#39;s four terminal commands - three that deliver, one that checks - and
finish knowing how a change travels from a Git commit to a running, secret-fed, digest-pinned workload on a fleet. The library at the end links only to official documentation, so every claim here can be
checked against its source.</p>
@@ -69,10 +72,10 @@
</div>
<div class="prose">
<p class="aside">A note on the commands: this site uses <span class="mono">oc</span>,
OpenShift's CLI. The Kubernetes commands here work the same
under <span class="mono">kubectl</span>; <span class="mono">oc</span> is a superset, and the
OpenShift-only parts (SCCs, Routes) are its own. Read
<span class="mono">kubectl</span> in the docs, type whichever your cluster gives you.</p>
OpenShift's CLI. Examples use <span class="mono">oc</span>, the OpenShift CLI, against
Kubernetes API resources - for those, <span class="mono">kubectl</span> behaves identically.
Where a step needs OpenShift APIs (SCCs, Routes, ClusterOperators, MachineConfig), it will
not exist on a plain Kubernetes cluster, and the text says so.</p>
<p>That <span class="mono">1/1</span> reads as containers-ready over containers-wanted: a pod
can hold more than one, which is Course IIIb.</p>
<p>Three of those were delivery actions - build, push, apply, and the
@@ -171,6 +174,8 @@
alt="A small fleet mid-explosion: one wide command slab with a strong cyan seam
hovering above a row of three identical worker blocks, all floating apart in
the void.">
<figcaption class="fieldnote">Generic OpenShift/Kubernetes cluster model - not a diagram
of the homelab.</figcaption>
</figure>
<ol class="legend"></ol>
</div>
@@ -247,9 +252,11 @@
runtime, not the kubelet, and kube-proxy, or an eBPF datapath replacing it, makes
Service addresses route to real pods.</p>
<p class="sayit">The scheduler places the pod. The kubelet realises it. The runtime runs it.</p>
<p class="fieldnote"><b>Field note.</b> Node NotReady? The kubelet is a systemd unit
like any other: <span class="mono">journalctl -u kubelet</span> on that node, and check it
can still reach the api-server. A node that cannot phone home is presumed lost.</p>
<p class="fieldnote"><b>Field note.</b> Node NotReady?
<span class="mono">oc describe node</span> shows its conditions and the last heartbeat, and
the node's events say what the platform already knows. When you need the node itself,
<span class="mono">oc debug node/&lt;name&gt;</span> is the supported doorway - not SSH. A
node that cannot phone home is presumed lost.</p>
<p class="closeline">The control plane does not start container processes directly. It records
and reconciles intent; node-side components execute it - the kubelet turning intent into
instructions, the runtime turning instructions into processes.</p>
+1
View File
@@ -282,6 +282,7 @@ const banned = [
[/every manifest <span class="mono">include<\/span>s/, "broken 'include s' construction"],
[/two policies renders from one field/, "subject/verb error 'renders from one field'"],
[/grown-up chart/, "'grown-up chart' (use 'production-grade chart')"],
[/journalctl -u kubelet/, "node-shell instruction (use oc describe / oc debug node)"],
];
// legend blurbs are inlined into the app JS (the SCENES const), so scan both surfaces
const visible = html + "\n" + app;