This vault has two jobs: teach the mechanisms behind devata, and preserve enough context to rebuild the platform later. Those jobs need different kinds of notes. A dated migration record should not silently become a runbook, and a concept note should not depend on a cluster still having the state that first exposed the concept.
Pick a path
| If you want to… | Start with | Finish when you can… |
|---|---|---|
| Understand the whole system | devata-system-map | draw the control and data boundaries from memory |
| Rebuild the cluster | reconstructing-devata | name every authoritative input and off-cluster dependency in order |
| Learn Kubernetes through the real lab | kubernetes, then concept-map | explain the controller loop and trace one request and one persistent write |
| Study operations and failure reasoning | recovering-loki-wal-replay-oom, then deleting-the-hypervisor | separate symptom, current failure loop, original trigger, and final proof |
| Follow the chronology | journey | connect dated decisions to their current successor design |
| Find curriculum gaps | kubernetes-coverage | choose the next gap that can be grounded in real devata work |
Read, observe, explain, reconstruct
Use four passes instead of reading straight through:
- Read: state the problem and predict the mechanism before following commands.
- Observe: run only the commands whose context and safety boundary you understand.
- Explain: close the page and draw or say the causal chain in your own words.
- Reconstruct: name the declared input, controller, runtime object, proof, and rollback.
flowchart LR Read --> Predict Predict --> Observe Observe --> Explain Explain --> Reconstruct Reconstruct -. gap found .-> Read
Know which kind of page you are reading
- Architecture explains the current durable shape. It should change when the design changes.
- Concept explains a portable mechanism and uses
devataas evidence. - Lab is safe to repeat and states context, mutation risk, expected output, and cleanup.
- Case study is a dated record. Commands show what happened, not automatic permission to repeat it.
- Operations gives an ordered recovery or reconstruction procedure with gates.
- Planning records chronology and possible work. It is never the source of truth for the running cluster.
Commands are evidence until their safety box says otherwise
Always confirm
kubectl config current-context, the repository, and the target node before using a command from a historical page. A command that was correct during a migration can be destructive against the completed system.
The source hierarchy
When pages disagree, use this order:
- live read-only observation for what is running now;
- the current default branch of the
labrepository for intended state; - architecture and operations pages for the durable model;
- dated case studies and the journey for historical reasoning;
- planning notes for possibilities, not facts.
The next page is devata-system-map.