|
2 | 2 |
|
3 | 3 | ## 1. Overview |
4 | 4 |
|
5 | | -`okdev` is a lightweight, Kubernetes-native development environment tool for AI/LLM infra engineers. |
| 5 | +`okdev` is a Kubernetes-native CLI for development session orchestration, designed for AI/LLM infrastructure workflows. |
6 | 6 |
|
7 | 7 | It intentionally avoids: |
8 | | -- Okteto-style platform coupling and heavy cloud assumptions |
9 | | -- DevPod-style UI dependency and single-machine-bound workflows |
| 8 | +- platform-coupled hosted control planes |
| 9 | +- UI-dependent workflows |
| 10 | +- machine-local session state as source of truth |
10 | 11 |
|
11 | | -It centers on one idea: |
12 | | -- **A Kubernetes PodSpec (with minimal okdev metadata) defines the full dev environment** |
| 12 | +Core model: |
| 13 | +- **A PodSpec plus minimal `okdev` metadata defines the development environment.** |
13 | 14 |
|
14 | 15 | Design goals: |
15 | | -- Simple CLI + Kubernetes API integration |
16 | | -- Shareable dev sessions across machines and teammates |
17 | | -- Works with existing clusters, namespaces, RBAC, and admission policies |
18 | | -- Reproducible LLM infra dev stacks (GPU, model caches, large datasets, sidecars) |
| 16 | +- deterministic CLI behavior over Kubernetes APIs |
| 17 | +- cross-machine session reattachment |
| 18 | +- compatibility with existing namespace/RBAC/admission policy constraints |
| 19 | +- reproducible AI infra stacks (GPU, cache volumes, large data paths, sidecars) |
19 | 20 |
|
20 | 21 | --- |
21 | 22 |
|
@@ -57,22 +58,22 @@ Needs: |
57 | 58 | ## 4. Product Principles |
58 | 59 |
|
59 | 60 | 1. **PodSpec-first**: no custom DSL required for core environment definition. |
60 | | -2. **Stateless client**: source of truth lives in Git + cluster objects, not local hidden state. |
| 61 | +2. **Stateless control path**: source of truth is Git + cluster objects, not a proprietary control plane. |
61 | 62 | 3. **Kubernetes-native identity**: contexts, kubeconfig, namespaces, service accounts. |
62 | 63 | 4. **Explicit over implicit**: predictable commands and clear object ownership. |
63 | | -5. **Low cognitive load**: a small command set that covers 80% of daily dev. |
| 64 | +5. **Operational simplicity**: small command surface with clear failure modes. |
64 | 65 |
|
65 | 66 | --- |
66 | 67 |
|
67 | 68 | ## 5. UX Summary |
68 | 69 |
|
69 | | -Core flow: |
| 70 | +Execution flow: |
70 | 71 | 1. Developer adds `.okdev.yaml` to repo, embedding or referencing PodSpec. |
71 | 72 | 2. `okdev up` creates/resumes a dev session in a namespace. |
72 | | -3. `okdev connect` opens terminal/SSH and optionally starts port forwards. |
| 73 | +3. `okdev up` configures SSH aliasing, managed forwards, and sync bootstrap. |
73 | 74 | 4. `okdev sync` mirrors local repo <-> pod workspace. |
74 | | -5. Developer can leave and later reconnect from another machine via `okdev up`. |
75 | | -6. `okdev down` stops session (or deletes, based on policy). |
| 75 | +5. Developer reconnects later from any machine with kube access via `okdev up` / `okdev ssh`. |
| 76 | +6. `okdev down` tears down runtime resources; PVC cleanup is explicit. |
76 | 77 |
|
77 | 78 | --- |
78 | 79 |
|
@@ -192,8 +193,8 @@ Notes: |
192 | 193 |
|
193 | 194 | Avoiding a custom operator keeps setup simple and portable: |
194 | 195 | - lower operational overhead |
195 | | -- easier to adopt in locked-down enterprise clusters |
196 | | -- fewer cluster-wide permissions |
| 196 | +- easier adoption in restricted enterprise clusters |
| 197 | +- avoids cluster-wide CRD/controller requirements |
197 | 198 |
|
198 | 199 | A controller/operator can be added later for advanced fleet features. |
199 | 200 |
|
|
0 commit comments