Build HelixWorks from Laptop to AWS: the 61-Day Dependency Map
Run it in the public monorepo
This course is built around the public HelixWorks Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.
Source: app/Dockerfile
FROM nginx:1.29-alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
Code to reality
- Declared intent
- Package the first web workload with one repeatable runtime and HTTP port.
- Interpreter
- The Docker builder executes each instruction and records an immutable image layer.
- Software effect
- The image contains the HelixWorks page at the nginx document root and declares port 80.
- Hardware effect
- A running container consumes host CPU, memory, storage layers, and a network namespace.
- Observable evidence
- docker image inspect and an HTTP request to the running container identify the image and response.
The product problem
You are starting with no Kubernetes knowledge. The goal is not to memorize object names. It is to build HelixWorks, a multi-tenant application-generation platform, and learn each Kubernetes mechanism when the product creates a reason for it.
HelixWorks has a web entry point and separate control-plane, generator, runtime, broker, and evidence responsibilities. Local development must be cheap and observable; dev, staging, and production must be isolated; production finishes on private Amazon EKS. Kubernetes continuously reconciles declared state through controllers rather than running a manifest once (Kubernetes controllers). Amazon EKS still leaves application, worker-node, identity, and data decisions with the platform team (EKS shared responsibility).
One analogy, then the real system
Think of HelixWorks as a publishing factory. Containers are sealed workstations, Pods are replaceable work crews, Services are stable internal phone numbers, controllers are supervisors, and Git is the approved operating manual. AWS eventually supplies the secured industrial estate. The analogy stops there: the real evidence is an image digest, Kubernetes object status, a customer request, and a durable audit event.
How the days depend on one another
Do not skip a failed proof. A later day assumes the preceding evidence exists.
| Days | Product dependency unlocked | HelixWorks evidence at the boundary |
|---|---|---|
| 0–3 | Source becomes a small, non-root, repeatable container image | Build output, image metadata, runtime user, HTTP response |
| 4–7 | A local cluster can schedule the first HelixWorks Pod | API context, Ready nodes, rendered Pod, container logs |
| 8–12 | Replaceable replicas gain stable networking and supporting workloads | Deployment ownership, EndpointSlices, DNS request, Job outcome |
| 13–18 | Placement, capacity, scaling, and health become explicit | scheduler events, requests/limits, probe transitions, HPA inputs |
| 19–26 | Configuration, identity, authorization, and network policy become boundaries | secret/config references, TLS identity, RBAC denials, policy denials |
| 27–35 | Operators learn machines, storage, DNS, networking, upgrades, and restore | node state, PVC binding, DNS trace, upgrade plan, restore proof |
| 36–40 | Symptoms become an evidence-led troubleshooting workflow | metrics, logs, events, JSONPath query, diagnosed owner |
| 41–48 | Delivery becomes reusable and evolvable | registry digest, Helm/Kustomize render, stateful identity, Gateway route |
| 49–55 | Extension and admission become governed platform capabilities | CRD status, reconciliation, admission denial, runtime and HA evidence |
| 56–60 | Production operations connect software to memory, hardware, and AWS | metric-to-incident trace, OOM diagnosis, rack/EKS responsibility dossier |
The complete 61-day route
| Day | HelixWorks build step | Why it must come now |
|---|---|---|
| 0 | Product and dependency map | Defines the proof-driven route |
| 1 | Container fundamentals | Gives one process an isolated runtime |
| 2 | Dockerize the web entry point | Produces the first runnable HelixWorks image |
| 3 | Multi-stage build | Separates build tools from production bytes |
| 4 | Why orchestration exists | Exposes the replacement and scheduling problem |
| 5 | Kubernetes architecture | Identifies API, controllers, scheduler, and kubelet |
| 6 | Multi-node Kind cluster | Creates the safe local substrate |
| 7 | Declarative Pod | Sends the first desired state to the API |
| 8 | Deployment and ReplicaSet | Makes the web process replaceable |
| 9 | Service | Gives changing Pods a stable address |
| 10 | Namespace | Creates an initial tenancy boundary |
| 11 | Init and sidecar containers | Separates setup and supporting behavior |
| 12 | DaemonSet, Job, CronJob | Models node-wide and finite work |
| 13 | Labels and scheduling | Connects selection to placement |
| 14 | Taints and tolerations | Protects specialized nodes |
| 15 | Node affinity | Expresses required and preferred placement |
| 16 | Requests and limits | Makes scheduling capacity honest |
| 17 | HPA and VPA | Separates replica scaling from sizing |
| 18 | Startup, readiness, liveness | Separates start, traffic, and recovery signals |
| 19 | ConfigMap and Secret | Removes environment data from images |
| 20 | TLS foundations | Explains transport identity and encryption |
| 21 | Kubernetes TLS | Connects certificates to cluster endpoints |
| 22 | Authentication and authorization | Separates identity from permission |
| 23 | Namespaced RBAC | Gives services least-privilege access |
| 24 | Cluster-scoped RBAC | Governs the few global capabilities |
| 25 | ServiceAccounts | Gives each workload a distinct identity |
| 26 | NetworkPolicy | Restricts service-to-service reachability |
| 27 | kubeadm cluster | Reveals the machine-level control plane |
| 28 | Container storage | Distinguishes image, writable layer, and mount |
| 29 | PV, PVC, StorageClass | Gives state an explicit lifecycle |
| 30 | DNS foundations | Explains names before cluster DNS |
| 31 | CoreDNS | Traces HelixWorks service discovery |
| 32 | CNI and runtimes | Traces packets and container execution |
| 33 | Ingress | Introduces controlled external HTTP routing |
| 34 | Cluster upgrade | Changes platform versions with a rollback plan |
| 35 | etcd backup and restore | Protects Kubernetes control-plane state |
| 36 | Monitoring, logging, alerting | Creates observable operating signals |
| 37 | Application troubleshooting | Follows request-to-Pod failures |
| 38 | Cluster troubleshooting | Follows controller and node failures |
| 39 | Network and node maintenance | Separates packet faults from machine work |
| 40 | JSONPath and advanced kubectl | Extracts precise operational evidence |
| 41 | Operator practice | Turns knowledge into timed, repeatable diagnosis |
| 42 | Private registry | Controls image distribution |
| 43 | Helm | Packages parameterized installation |
| 44 | Kustomize | Reuses a base across environments |
| 45 | StatefulSet | Gives ordered, stable identity where required |
| 46 | Priority and preemption | Protects critical services under pressure |
| 47 | Gateway API | Models richer traffic ownership |
| 48 | Ingress migration | Changes routing without losing customer evidence |
| 49 | CRDs | Extends the API with HelixWorks-specific intent |
| 50 | Operators | Reconciles that intent continuously |
| 51 | Admission controllers | Rejects unsafe desired state before persistence |
| 52 | Dynamic provisioning | Connects storage claims to provisioners |
| 53 | CRI and cri-dockerd | Locates the kubelet/runtime boundary |
| 54 | Pod Security | Enforces a restricted process baseline |
| 55 | HA control plane | Removes one control-plane machine as a single point |
| 56 | Prometheus and Mimir | Connects a metric to an incident decision |
| 57 | Kubernetes memory | Connects physical RAM, cgroups, requests, and limits |
| 58 | OOM workflow | Diagnoses memory termination without guessing |
| 59 | On-premises substrate | Maps racks, networks, and storage to cluster promises |
| 60 | Managed Kubernetes on AWS | Produces the final shared-responsibility launch dossier |
Learning contract
Every day answers five questions: what intent did we declare, which interpreter acted, what software state changed, what physical resource was used, and what evidence proves it? HelixWorks remains the recurring product. A command that exits successfully is not enough; capture the object status and the customer-visible effect.
Day 0 proof
- [ ] Explain HelixWorks’s six service responsibilities without Kubernetes jargon.
- [ ] Trace the dependency chain from source to an EKS customer request.
- [ ] Identify which day supplies the prerequisite for any later topic.
- [ ] Create an evidence folder keyed by day, environment, source revision, and timestamp.
- [ ] Refuse to advance when a prerequisite proof is missing.
Next: Day 1 starts with the smallest real unit: one process inside one container image.