Schematic viewer · rev 9.0

UNDER THE HOOD

Interactive schematics of the whole stack, from kernel to pager to the GPU: twelve sheets, one reconciliation loop, everywhere. Pick a scenario and follow the orange signal through every internal component that touches it.

Sheet 00, Linux. The prequel: every sheet above compiles down to this one. Containers, images, resource limits, network policies. All of it is a handful of kernel primitives worn as a costume. Trace fork & exec (what running ls actually does), then build a container by hand with namespaces, cap what it uses with cgroups, fake its filesystem with overlayfs & pivot_root, disarm it with capabilities · seccomp · LSM, and finish with eBPF, programs running inside the kernel itself. Keys: step · space play.
Fig. 0, user space · syscall boundary · kernel · hardwareclick any component for its role
user space · ring 3 bash your shell process fork() → exec() glibc syscall wrappers kernel space · ring 0 syscall interface, the only door · ~330 calls scheduler EEVDF · runqueues memory mgmt virtual mem · COW VFS mounts · overlayfs net stack netfilter · veth namespaces pid · net · mnt · user cgroups v2 cpu · memory · io · pids security caps · seccomp · LSM eBPF verified in-kernel code hardware CPUs · rings RAM · MMU disk · NVMe NIC · queues
Sheet 01, Docker. How a single command becomes a running, isolated Linux process. Trace docker run through the full chain (CLI → dockerd → containerd → shim → runc → kernel), then go deeper: image builds with BuildKit and layer caching, volumes and copy-on-write, networking with veth pairs and embedded DNS, security from the default sandbox to the never-do list, and compose. Keys: step · space play.
Fig. 1, docker engine on a linux hostclick any component for its role
registry manifests + layer blobs linux host docker CLI /var/run/docker.sock dockerd API · images · volumes BuildKit Dockerfile → layers image store overlay2 · copy-on-write writable layer layer 3 · COPY app/ layer 2 · apt install layer 1 · debian base ↑ merged view = rootfs volumes /var/lib/docker/volumes containerd snapshots · OCI spec containerd-shim per-container parent runc transient container · nginx a namespaced linux process pid · net · mnt ns uts · ipc · user ns cgroups cpu/mem rootfs: overlay2 seccomp · caps dropped bridge network veth · iptables · DNS
Sheet 02, Kubernetes. How declarative YAML becomes running workloads. Trace every major resource type through the control plane, Deployment, StatefulSet, DaemonSet, Job/CronJob, Service, Ingress, Gateway API, PV/PVC storage, NetworkPolicy, HPA, ConfigMap, security, plus the Web request trace: the full journey of a page load from browser → cloud LB → gateway → service → your pod. Keys: step · space play.
Fig. 2, control plane · worker node · traffic pathclick any component for its role
kubectl your terminal control plane kube-apiserver authn · RBAC · admission etcd cluster state store controller-manager ~30 reconcile loops kube-scheduler filter → score → bind CSI provisioner provisioner · attacher worker node kubelet node agent containerd CRI runtime → runc pod replica 1 pod replica 2 pod replica 3 kube-proxy iptables / ipvs CNI agent eBPF / iptables gateway pod envoy · nginx PV · disk attached volume browser internet client cloud LB L4 · public IP
Sheet 03, GitOps. Where the YAML in Sheet 02 actually comes from. Nobody runs kubectl in production: a controller (ArgoCD) living inside the cluster pulls desired state from git and reconciles the cluster toward it. The same watch → diff → act loop Kubernetes uses internally, applied to deployment itself. Trace git push → sync end to end, then drift & self-heal (what happens to a 2am kubectl edit), rollback via git revert, sync waves & hooks for ordered releases with DB migrations, and ApplicationSet fleet stamping. Keys: step · space play.
Fig. 3, git → argocd → clusterclick any component for its role
developer git push · PR merge git repository the source of truth kubernetes cluster argocd namespace argocd-server API · UI · webhook repo-server clone · helm · kustomize app-controller diff · sync · health redis manifest / state cache appset-controller generators → apps kube-apiserver sheet 02 takes over live workloads deployments · pods · ingress shop ×3 api ×2 kubectl edit manual drift
Sheet 04, Terraform / IaC. The layer everything above runs on. One binary, but three moving parts most people never see: providers are separate processes speaking gRPC, resources form a dependency graph walked in parallel, and state is the binding between your config and real cloud IDs. Trace terraform apply end to end (watch the DAG light up in dependency order), then destroy (the graph reversed), drift & import, state surgery, and Terraform in CI, GitOps for infrastructure, closing the loop with Sheet 03. Keys: step · space play.
Fig. 4, core · providers · state · cloudclick any component for its role
your machine / ci runner developer terraform apply .tf files HCL · modules terraform core parse · graph · plan · walk resource graph vpc subnet sg instance state backend s3 / gcs · tfstate lock: dynamodb item provider plugin separate process · gRPC registry providers · modules cloud APIs signed REST · rate limits real infrastructure what you're billed for vpc · ec2 k8s cluster buckets · dns · iam
Sheet 05, Observability. You built it (04), deployed it (03), orchestrated it (02). Now prove it works, and find out at 3am when it doesn't. Trace a metric's journey from a counter in your code through scrape loop, WAL and TSDB to a Grafana panel; follow the alert path through pending → firing → Alertmanager grouping → the on-call phone; turn reliability into a currency with SLOs & burn rates; add logs & traces, the other two pillars; and finish with HA & meta-monitoring, who watches the watchmen. Keys: step · space play.
Fig. 5, scrape · store · query · pageclick any component for its role
kube-apiserver target discovery app pod /metrics endpoint prometheus scrape loop pull model · every 30s rule engine recording · alerting WAL append-only · fsync TSDB head → 2h blocks PromQL query engine alertmanager group · inhibit · route pagerduty → human the 3am hop grafana dashboards · explore
Sheet 06, Git. The database everything since Sheet 03 trusts as its source of truth, so it deserves its own schematic. Git is a content-addressed object store with a thin porcelain of commands on top. Trace the anatomy of a commit (blobs, trees, refs, HEAD), branch & merge mechanics, what push & fetch actually transfer, time travel & recovery via the reflog, and rewriting history. When new hashes are fine and when they're a team incident. Keys: step · space play.
Fig. 6, working dir · .git · remoteclick any component for its role
working dir your files .git, the local database index staging area · binary object store content-addressed blob · tree commit · tag sha = identity refs branches · tags HEAD symref → branch reflog your safety net packfiles deltas · gc remote (origin) github · bare repo same objects · same refs
Sheet 07, CI/CD. The machinery between Sheet 06's push and Sheet 03's sync. Trace a pipeline run from webhook to green check, why caching makes or breaks build times, the two models of CD (push-deploy vs handing off to GitOps), supply-chain security from OIDC to signed provenance, and the unglamorous craft of reliable pipelines, flaky tests, merge queues, hermetic runners. Keys: step · space play.
Fig. 7, forge · engine · runner · registry · prodclick any component for its role
developer push · open PR git forge webhooks · checks API workflow engine parse · queue · schedule runner ephemeral vm / pod steps as containers cache keyed by lockfile hash artifacts build outputs registry images · provenance cloud / prod OIDC · no static keys or: hand off to sheet 03
Sheet 08, DNS. The system every outage postmortem suspects first, usually correctly. Trace a full resolution from getaddrinfo() through /etc/hosts, systemd-resolved and a recursive resolver iterating root → TLD → authoritative; then the Kubernetes DNS path with its infamous ndots:5; a working tour of records & TTLs; a debugging field guide (SERVFAIL vs NXDOMAIN vs the 5-second k8s timeout); and DNS as infrastructure, failover, geo-routing, and its limits as a load balancer. Keys: step · space play.
Fig. 8, stub · recursive · root · tld · authoritativeclick any component for its role
linux host application getaddrinfo() stub resolver nsswitch · /etc/hosts systemd-resolved 127.0.0.53 · cache kubernetes pod path coredns cluster.local · ndots:5 recursive resolver cache · iteration root servers 13 letters · anycast .com TLD delegation + glue authoritative route53 · the answer
Sheet 09, TLS & PKI. The padlock, taken apart. Trace the TLS 1.3 handshake (SNI, key shares, why forward secrecy matters), the chain of trust from leaf to root and its classic failure modes, ACME issuance as a cert-manager controller loop (Sheet 02's pattern, again), mTLS & service identity (including the fact that every kubectl call you've ever made was mutual TLS) and the failure museum: expiry, clock skew, and why revocation never really worked. Keys: step · space play.
Fig. 9, client · server · ca · cert-managerclick any component for its role
client browser · service trust store ~150 root CAs server nginx · envoy · gateway key + leaf + chain certificate authority let's encrypt · ACME CT logs · public issuance cert-manager k8s controller · ACME tls secret tls.crt · tls.key
Sheet 10, Secrets (Vault). Sheet 02 warned you: Secrets in etcd are base64, not protection. Vault is the systemic answer. Trace the seal & barrier (why stolen storage is useless), the killer feature. dynamic database credentials that didn't exist before the request and are dropped after the lease; the auth & policy model where everything is a path; transit & PKI engines (encryption-as-a-service, Vault as your internal CA for Sheet 09's mTLS); and the Kubernetes integration patterns with their honest trade-offs. Keys: step · space play.
Fig. 10, auth · policy · engines · barrier · storageclick any component for its role
app pod wants db creds kube-apiserver tokenreview vault auth methods kubernetes · oidc policies path-based ACL secret engines kv · database · pki transit · cloud iam barrier. Everything below is ciphertext storage (raft) encrypted at rest · replicated postgres real database users created · dropped unseal / KMS shamir 3-of-5 · auto
Sheet 11, AI / LLM Serving. The newest workload wearing all ten previous sheets' patterns, plus one genuinely new bottleneck. Trace the anatomy of an inference request (prefill vs decode, continuous batching, the KV cache); model rollout & canary. Sheet 03/07's playbook applied to checkpoints instead of containers; GPU autoscaling economics. The one workload where request-based autoscaling actually is the right call; a RAG pipeline (embed, retrieve, ground); and LLM observability & cost, new SLIs for a workload billed by the token. Keys: step · space play.
Fig. 11, gateway · scheduler · gpu pool · retrievalclick any component for its role
client / app streaming consumer api gateway auth · rate limit · route scheduler / queue continuous batching inference pool gpu inference pods prefill · decode kv cache gpu memory · paged model registry versioned checkpoints embedding svc text → vector vector db ann index gpu autoscaler queue depth · util llm observability ttft · cost/token