| 1 | # ppt169_kubernetes_blueprint - Design Spec |
| 2 | |
| 3 | > Capability-showcase deck for the Blueprint / Isometric Technical Drawing direction (P0 in `docs/roadmap.md`). Stress-tests geometric shape generalization and chart-structure extensibility through a Kubernetes cluster architecture walkthrough. |
| 4 | |
| 5 | ## I. Project Information |
| 6 | |
| 7 | | Item | Value | |
| 8 | | ---- | ----- | |
| 9 | | **Project Name** | ppt169_kubernetes_blueprint | |
| 10 | | **Canvas Format** | PPT 16:9 (1280×720) | |
| 11 | | **Page Count** | 10 | |
| 12 | | **Design Style** | B) General Consulting + Blueprint / Isometric Technical Drawing | |
| 13 | | **Target Audience** | Engineers / DevOps / SRE / technical decision-makers | |
| 14 | | **Use Case** | Internal technical briefing, training material, engineering whitepaper hero chapter | |
| 15 | | **Created Date** | 2026-05-21 | |
| 16 | |
| 17 | --- |
| 18 | |
| 19 | ## II. Canvas Specification |
| 20 | |
| 21 | | Property | Value | |
| 22 | | -------- | ----- | |
| 23 | | **Format** | PPT 16:9 | |
| 24 | | **Dimensions** | 1280×720 | |
| 25 | | **viewBox** | `0 0 1280 720` | |
| 26 | | **Margins** | 60px left/right, 50px top/bottom | |
| 27 | | **Content Area** | 1160×620 (header 60px, body 510px, footer 50px) | |
| 28 | |
| 29 | --- |
| 30 | |
| 31 | ## III. Visual Theme |
| 32 | |
| 33 | ### Theme Style |
| 34 | |
| 35 | - **Style**: Blueprint / Isometric Technical Drawing — engineering schematic on dark blueprint paper, thin cyan line work, isometric 3D projection of components, technical annotation language (dimension lines, arrows, component codes, coordinate grids) |
| 36 | - **Theme**: Dark theme |
| 37 | - **Tone**: Engineering, technical, precise, schematic — speaks the language of an industrial blueprint hung on a wall, not a marketing slide |
| 38 | |
| 39 | ### Color Scheme |
| 40 | |
| 41 | | Role | HEX | Purpose | |
| 42 | | ---- | --- | ------- | |
| 43 | | **Background** | `#0E2A47` | Deep navy blueprint paper | |
| 44 | | **Secondary bg** | `#1A3A5C` | Region / panel backing | |
| 45 | | **Primary** | `#5BA3E0` | Blueprint line color — component frames, connectors, isometric edges | |
| 46 | | **Accent** | `#FFB627` | Single-spot amber — callouts, current state, key path highlight (classic engineering drawing convention) | |
| 47 | | **Secondary accent** | `#3E7AB8` | Line darker tone, secondary borders | |
| 48 | | **Body text** | `#F0F4F8` | Chalk-on-blueprint off-white | |
| 49 | | **Secondary text** | `#A0B8D0` | Sub-annotation, captions | |
| 50 | | **Tertiary text** | `#6B85A3` | Footer / page-number / coordinate labels | |
| 51 | | **Border / grid** | `#2D4A6B` | Blueprint grid (thin gridlines under everything) | |
| 52 | | **Success** | `#7FD99F` | Healthy / Running state | |
| 53 | | **Warning** | `#FF6B6B` | Failed / NotReady / error state | |
| 54 | |
| 55 | 60-30-10: deep navy background ~60%, cyan line work ~30%, amber accent <10% |
| 56 | |
| 57 | ### Gradient Scheme |
| 58 | |
| 59 | ```xml |
| 60 | <!-- Subtle blueprint paper vignette (corner darkening, like an old technical drawing) --> |
| 61 | <radialGradient id="bgVignette" cx="50%" cy="50%" r="75%"> |
| 62 | <stop offset="60%" stop-color="#0E2A47" stop-opacity="0"/> |
| 63 | <stop offset="100%" stop-color="#000000" stop-opacity="0.35"/> |
| 64 | </radialGradient> |
| 65 | |
| 66 | <!-- Amber callout glow --> |
| 67 | <radialGradient id="amberGlow" cx="50%" cy="50%" r="50%"> |
| 68 | <stop offset="0%" stop-color="#FFB627" stop-opacity="0.4"/> |
| 69 | <stop offset="100%" stop-color="#FFB627" stop-opacity="0"/> |
| 70 | </radialGradient> |
| 71 | ``` |
| 72 | |
| 73 | --- |
| 74 | |
| 75 | ## IV. Typography System |
| 76 | |
| 77 | ### Font Plan |
| 78 | |
| 79 | **Typography direction**: Tech / developer — sans-serif body for readability + monospace for every K8s component name (`kube-apiserver` / `etcd` / `PVC` / `ClusterIP`), mirroring engineering documentation conventions. |
| 80 | |
| 81 | | Role | Chinese | English | Fallback tail | |
| 82 | | ---- | ------- | ------- | ------------- | |
| 83 | | **Title** | `"Microsoft YaHei"` | `Arial` | `sans-serif` | |
| 84 | | **Body** | `"Microsoft YaHei"` | `Arial` | `sans-serif` | |
| 85 | | **Emphasis** | same as Body | — | — | |
| 86 | | **Code** | — | `Consolas, "Courier New"` | `monospace` | |
| 87 | |
| 88 | **Per-role font stacks**: |
| 89 | |
| 90 | - Title: `Arial, "Microsoft YaHei", sans-serif` |
| 91 | - Body: `Arial, "Microsoft YaHei", sans-serif` |
| 92 | - Emphasis: same as Body |
| 93 | - Code: `Consolas, "Courier New", monospace` |
| 94 | |
| 95 | ### Font Size Hierarchy |
| 96 | |
| 97 | **Baseline**: Body font size = **18px** (dense — many components / labels per page) |
| 98 | |
| 99 | | Purpose | Ratio to body | This deck (body=18) | Weight | |
| 100 | | ------- | ------------- | ------------------- | ------ | |
| 101 | | Cover title (hero) | 3.5x | 64px | Bold | |
| 102 | | Chapter / section opener | 2.5x | 45px | Bold | |
| 103 | | Page title | 1.7x | 30px | Bold | |
| 104 | | Hero number | 1.7-2x | 32-36px | Bold | |
| 105 | | Subtitle | 1.3x | 24px | SemiBold | |
| 106 | | **Body** | **1x** | **18px** | Regular | |
| 107 | | Annotation / caption | 0.75x | 13-14px | Regular | |
| 108 | | Coordinate label / footer | 0.6x | 11px | Regular (mono) | |
| 109 | |
| 110 | --- |
| 111 | |
| 112 | ## V. Layout Principles |
| 113 | |
| 114 | ### Page Structure |
| 115 | |
| 116 | - **Header area**: 60px — page title + small page-code (`P03 / 10`) in monospace right-aligned |
| 117 | - **Content area**: 510px — central drawing region, often an isometric/blueprint diagram |
| 118 | - **Footer area**: 50px — coordinate-grid origin marker, project code (`K8S-ARCH-2026`), page number |
| 119 | |
| 120 | ### Layout Pattern Library (this deck uses) |
| 121 | |
| 122 | | Pattern | Pages | |
| 123 | | ------- | ----- | |
| 124 | | Single-element isometric centered | P01 (cover), P05 (lifecycle), P08 (HA topology), P09 (comm flow), P10 (closing) | |
| 125 | | Two-plane vertical split (control/data) | P02 | |
| 126 | | Hub-and-spoke (centered apiserver) | P03 | |
| 127 | | Module composition (isometric node anatomy) | P04 | |
| 128 | | Vertical pillars (4 parallel columns) | P06 | |
| 129 | | Layered stack (PV / PVC / StorageClass) | P07 | |
| 130 | |
| 131 | ### Spacing Specification |
| 132 | |
| 133 | | Element | This Project | |
| 134 | | ------- | ------------ | |
| 135 | | Safe margin from canvas edge | 60px (L/R), 50px (T/B) | |
| 136 | | Content block gap | 30px | |
| 137 | | Icon-text gap | 10px | |
| 138 | | Isometric tile depth (3D z-offset) | 12px | |
| 139 | | Grid spacing (background) | 40px (major) / 8px (minor) | |
| 140 | | Annotation leader-line length | 60-120px | |
| 141 | | Component-frame border-radius | 4px (engineering-precise, not soft cards) | |
| 142 | |
| 143 | --- |
| 144 | |
| 145 | ## VI. Icon Usage Specification |
| 146 | |
| 147 | ### Source |
| 148 | |
| 149 | - **Library**: `tabler-outline` (line-art, matches blueprint line work) |
| 150 | - **Stroke width**: `1.5` (deck-wide) |
| 151 | - **Usage method**: SVG placeholder `<use data-icon="tabler-outline/icon-name" .../>` |
| 152 | |
| 153 | ### Recommended Icon List |
| 154 | |
| 155 | | Purpose | Icon Path | Page | |
| 156 | | ------- | --------- | ---- | |
| 157 | | Network / cluster | `tabler-outline/network` | P02, P09 | |
| 158 | | Server / API | `tabler-outline/server` | P03 | |
| 159 | | Database / store | `tabler-outline/database` | P03 (etcd) | |
| 160 | | Cog / scheduler | `tabler-outline/settings` | P03 (scheduler) | |
| 161 | | Refresh / controller loop | `tabler-outline/refresh` | P03 (controller-manager) | |
| 162 | | Cloud | `tabler-outline/cloud` | P03 (cloud-controller-manager) | |
| 163 | | Cube / pod | `tabler-outline/cube` | P04, P05 | |
| 164 | | Box / container | `tabler-outline/box` | P04 | |
| 165 | | Route / proxy | `tabler-outline/route` | P04, P06 | |
| 166 | | Heartbeat / lifecycle | `tabler-outline/heartbeat` | P05 | |
| 167 | | Plug / service | `tabler-outline/plug` | P06 | |
| 168 | | Disk / storage | `tabler-outline/device-floppy` | P07 | |
| 169 | | Stack / layered | `tabler-outline/stack` | P02, P07 | |
| 170 | | Shield / health | `tabler-outline/shield-check` | P08 | |
| 171 | | Send / arrow | `tabler-outline/arrow-right` | universal | |
| 172 | |
| 173 | --- |
| 174 | |
| 175 | ## VII. Visualization Reference List |
| 176 | |
| 177 | Catalog read: 71 templates |
| 178 | |
| 179 | | Page | Template | Path | Summary-quote (verbatim) | Usage | |
| 180 | | ---- | -------- | ---- | ------------------------ | ----- | |
| 181 | | P03 | hub_spoke | `templates/charts/hub_spoke.svg` | "Pick for 1 core capability + 4-8 surrounding capabilities (platform/ecosystem); each spoke = title or title + 1-2 line description. Skip if" | kube-apiserver as central hub + 4 other control-plane components as spokes — captures the architectural truth that "everything goes through apiserver" | |
| 182 | | P05 | process_flow | `templates/charts/process_flow.svg` | "Pick for 3-8 sequential steps connected by simple arrows — approval workflows, customer onboarding, request handling, lifecycle stages. Skip" | Pod lifecycle phases Pending → Running → Succeeded / Failed (with Unknown branch) | |
| 183 | | P06 | vertical_pillars | `templates/charts/vertical_pillars.svg` | "Pick for 1×3 / 1×4 / 1×5 vertical column layout where each pillar = one independent category with title + bullets — PEST (Political/Economic" | 4 Service types as parallel pillars: ClusterIP / NodePort / LoadBalancer / ExternalName | |
| 184 | | P09 | client_server_flow | `templates/charts/client_server_flow.svg` | "Pick for left-side clients + right-side servers with labeled bidirectional arrows for key interactions (request/response/push). Each module" | Components on the left + kube-apiserver center + etcd right, with labeled watch/write arrows | |
| 185 | |
| 186 | **Runners-up considered**: |
| 187 | |
| 188 | - `hub_inward_arrows` | rejected for P03: that template is for "forces pointing inward" (Porter's Five Forces). Apiserver is a hub all roads pass *through*, not a target of inward pressure — `hub_spoke` reads truer. |
| 189 | - `numbered_steps` | rejected for P05: pod lifecycle is not a fixed sequence; it has a fork (Succeeded vs Failed) and a re-entry path (restart). `process_flow` handles branching arrows; `numbered_steps` forces a single chain. |
| 190 | - `comparison_table` | rejected for P06: Service types vary along too many independent axes (scope / port range / external requirement / use case). A pillars layout lets each type carry its own structure without forcing parallel rows. |
| 191 | - `layered_architecture` | rejected for P02 (P02 is free design): the catalog template is too card-heavy for the blueprint aesthetic — re-implementing the two-plane split as a custom isometric diagram is exactly the capability this deck demonstrates. |
| 192 | |
| 193 | --- |
| 194 | |
| 195 | ## VIII. Image Resource List |
| 196 | |
| 197 | **No images.** This deck is intentionally all-SVG / all-vector — every architectural diagram is a hand-drawn isometric blueprint. Mixing raster AI images would dilute the stress-test of geometric shape generalization that the Blueprint direction is meant to demonstrate. |
| 198 | |
| 199 | --- |
| 200 | |
| 201 | ## IX. Content Outline |
| 202 | |
| 203 | ### Part 1: Setting the frame |
| 204 | |
| 205 | #### Slide 01 — Cover |
| 206 | |
| 207 | - **Layout**: Single isometric hero — a stylized cluster of cube-stacks rendered in cyan line art, centered, with title overlay |
| 208 | - **Title**: `Kubernetes Cluster Architecture` |
| 209 | - **Subtitle**: `A Blueprint of the Modern Container Orchestrator` |
| 210 | - **Meta**: `K8S-ARCH-2026 · DRAWING 01 OF 10 · ENGINEERING REFERENCE` |
| 211 | |
| 212 | #### Slide 02 — Two planes: control vs data |
| 213 | |
| 214 | - **Layout**: Vertical split — top half = control plane (5 component glyphs in a row), bottom half = data plane (3 worker-node isometric blocks), connected by a single labeled spine |
| 215 | - **Title**: `Two Planes, One Spine` |
| 216 | - **Content**: |
| 217 | - Control plane → global decisions, desired-state holder |
| 218 | - Data plane → workload execution (Pods) |
| 219 | - `kube-apiserver` is the only link — every line crosses through it |
| 220 | |
| 221 | ### Part 2: Component anatomy |
| 222 | |
| 223 | #### Slide 03 — Control plane components |
| 224 | |
| 225 | - **Layout**: Hub-and-spoke; `kube-apiserver` at the hub with `etcd` adjacent (the only direct talker); `kube-scheduler` / `kube-controller-manager` / `cloud-controller-manager` as spokes |
| 226 | - **Visualization**: hub_spoke (adapted) |
| 227 | - **Title**: `The Control Plane: 5 Components` |
| 228 | - **Content**: one-line role for each component, mono code label per component |
| 229 | |
| 230 | #### Slide 04 — Worker node anatomy |
| 231 | |
| 232 | - **Layout**: Isometric exploded-view of a single worker node — outer shell labeled, kubelet/kube-proxy/runtime as inner modules, Pods stacked as cubes inside the runtime |
| 233 | - **Title**: `Worker Node: Three Layers` |
| 234 | - **Content**: |
| 235 | - `kubelet` — agent reconciling PodSpecs against the local node |
| 236 | - `kube-proxy` — Service rules via iptables / IPVS / nftables |
| 237 | - Container runtime — `containerd` / `CRI-O` over the CRI contract |
| 238 | |
| 239 | ### Part 3: Lifecycle and networking |
| 240 | |
| 241 | #### Slide 05 — Pod lifecycle phases |
| 242 | |
| 243 | - **Layout**: Horizontal process flow; 4 phase nodes + 1 Unknown branch; restart loop callout |
| 244 | - **Visualization**: process_flow (adapted) |
| 245 | - **Title**: `Pod Lifecycle: One Schedule, Many States` |
| 246 | - **Content**: `Pending → Running → {Succeeded | Failed}`; Unknown branch when node unreachable; restart policy `Always` / `OnFailure` / `Never` |
| 247 | |
| 248 | #### Slide 06 — Service networking: 4 types |
| 249 | |
| 250 | - **Layout**: 4 parallel pillars, each pillar an isometric tower showing what gets exposed where |
| 251 | - **Visualization**: vertical_pillars (adapted) |
| 252 | - **Title**: `Services: Four Ways to Be Reachable` |
| 253 | - **Content**: ClusterIP (internal) / NodePort (30000-32767 on every node) / LoadBalancer (cloud LB) / ExternalName (DNS CNAME) |
| 254 | |
| 255 | ### Part 4: Persistence and topology |
| 256 | |
| 257 | #### Slide 07 — Storage: three resources |
| 258 | |
| 259 | - **Layout**: Layered stack — top: Pod, mid: PVC, bottom: PV; right side: StorageClass + CSI driver as the provisioner spine |
| 260 | - **Title**: `Storage: PV / PVC / StorageClass` |
| 261 | - **Content**: Static vs dynamic provisioning; access modes `RWO` / `ROX` / `RWX` / `RWOP`; reclaim `Retain` / `Delete` |
| 262 | |
| 263 | #### Slide 08 — HA topology: stacked vs external etcd |
| 264 | |
| 265 | - **Layout**: Two isometric diagrams side by side — left: stacked (etcd co-located with control-plane host); right: external (etcd on dedicated hosts) — each annotated with trade-offs |
| 266 | - **Title**: `HA Topology: Stacked or External` |
| 267 | - **Content**: ≥3 hosts; odd-numbered etcd members (3 or 5); leader-elected scheduler / controller-manager |
| 268 | |
| 269 | ### Part 5: The spine + closing |
| 270 | |
| 271 | #### Slide 09 — Everything-through-apiserver |
| 272 | |
| 273 | - **Layout**: client_server_flow — clients (kubectl / kubelet / scheduler / controller-manager) on the left, kube-apiserver center, etcd on the right; labeled arrows |
| 274 | - **Visualization**: client_server_flow (adapted) |
| 275 | - **Title**: `Every Line Crosses the API Server` |
| 276 | - **Content**: API-mediated state transitions enable plug-ability, observability, audit |
| 277 | |
| 278 | #### Slide 10 — Takeaways |
| 279 | |
| 280 | - **Layout**: Negative-space-driven, three condensed lines centered against the blueprint grid |
| 281 | - **Title**: `Three Things to Remember` |
| 282 | - **Content**: |
| 283 | - One spine — `kube-apiserver` mediates every state change |
| 284 | - One truth — `etcd` is the only persistent store |
| 285 | - One reconcile loop — controllers watch, diff, act; everything else is a variation |
| 286 | |
| 287 | --- |
| 288 | |
| 289 | ## X. Speaker Notes Requirements |
| 290 | |
| 291 | - **Filename**: match SVG name (`01_cover.svg` → `notes/01_cover.md`) |
| 292 | - **Total duration target**: ~12 minutes (1-1.5 min per content page; cover/closing shorter) |
| 293 | - **Notes style**: Technical / informative — speaker is a senior engineer walking a peer audience through architecture; avoid marketing tone |
| 294 | |
| 295 | --- |
| 296 | |
| 297 | ## XI. Technical Constraints Reminder |
| 298 | |
| 299 | Standard PPT Master SVG constraints (see `references/shared-standards.md`). Key reminders for this deck: |
| 300 | |
| 301 | 1. Every isometric line drawing is hand-authored SVG — `<polygon>` / `<line>` / `<path>` primitives; no raster fallback |
| 302 | 2. The blueprint grid background is a `<pattern>` ref'd by `<rect>` (allowed) — not `class` / `<style>` |
| 303 | 3. Prefer opacity per child; `<g opacity>` remains converter-compatible with an approximate-fidelity warning |
| 304 | 4. Transparency defaults to `stop-opacity` / `fill-opacity`; `rgba()` remains converter-compatible |
| 305 | 5. Component codes (`kube-apiserver`, `etcd`, `PVC`, etc.) MUST use `font-family="Consolas, 'Courier New', monospace"` for the mono visual contract |
| 306 | 6. Coordinate labels in footer use the same mono family — engineering-document texture |
| 307 |