164 lines
4.9 KiB
Markdown
164 lines
4.9 KiB
Markdown
# ocdp-workload-manifests
|
|
|
|
Standalone Kubernetes manifests and post-render presets for OCDP workloads.
|
|
|
|
This repository is intentionally just a Git repository of app manifests. There is
|
|
no global catalog index and no dependency on the Gitea API. `ocdp-server` stores
|
|
the template contract; the operator renders Helm sources and then applies
|
|
Kustomize presets from this repository.
|
|
|
|
## Architecture
|
|
|
|
OCDP keeps the responsibilities split:
|
|
|
|
```text
|
|
Git repo
|
|
apps/<app>/base
|
|
apps/<app>/components
|
|
packages/<app>/presets/<preset>
|
|
kustomization.yaml
|
|
userInputs.yaml
|
|
|
|
ocdp-server PostgreSQL
|
|
WorkloadTemplate metadata
|
|
WorkloadTemplate Helm source
|
|
WorkloadTemplate source.preset.repositoryUrl/ref/path
|
|
user-facing values schema / parameters
|
|
access bindings
|
|
no WorkloadClaim instance storage
|
|
|
|
target cluster
|
|
WorkloadClaim CR as the canonical user claim
|
|
Workload CR
|
|
runtime Kubernetes resources
|
|
```
|
|
|
|
This repository stores Git bases, reusable components, and Kustomize presets.
|
|
For Helm-backed workloads, the operator runs `helm template` first, writes that
|
|
output as `rendered.yaml`, then renders the selected preset with Workload
|
|
`spec.values`. A preset may include `userInputs.yaml` so admins can see which
|
|
values should become the WorkloadTemplate user-facing parameter schema. This
|
|
metadata file is not a Kubernetes resource and is not referenced by Kustomize.
|
|
|
|
An admin creates or updates a `WorkloadTemplate` in `ocdp-server`. That template
|
|
can point at a Helm chart plus one of these Git presets:
|
|
|
|
```yaml
|
|
templateType: kustomize
|
|
source:
|
|
type: helm
|
|
repositoryUrl: https://kuoss.github.io/helm-charts
|
|
chart: code-server
|
|
version: 3.16.1
|
|
releaseName: "{{ name }}"
|
|
values: |
|
|
fullnameOverride: "{{ name }}"
|
|
serviceAccount:
|
|
create: false
|
|
persistence:
|
|
enabled: true
|
|
size: 20Gi
|
|
preset:
|
|
type: kustomize
|
|
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
|
|
ref: main
|
|
path: packages/code-server/presets/k3s-hami
|
|
```
|
|
|
|
After the template is stored in PostgreSQL and assigned to users or groups, users
|
|
call `ocdp-server` to create a claim by submitting `templateId`, `workspaceId`,
|
|
and values. `ocdp-server` resolves the template from PostgreSQL and writes a
|
|
`WorkloadClaim` CR into the target Kubernetes cluster. The operator renders Helm
|
|
with the resolved values, applies the Kustomize preset, and then applies the
|
|
final Kubernetes resources. The final user-created claim lives in Kubernetes,
|
|
not in PostgreSQL.
|
|
|
|
## Layout
|
|
|
|
```text
|
|
apps/
|
|
code-server/
|
|
base/
|
|
components/
|
|
vllm-server/
|
|
base/
|
|
components/
|
|
litellm/
|
|
base/
|
|
components/
|
|
packages/
|
|
code-server/
|
|
presets/
|
|
k3s-hami/
|
|
kustomization.yaml
|
|
userInputs.yaml
|
|
tests/
|
|
kustomize/
|
|
```
|
|
|
|
## Server Usage
|
|
|
|
`ocdp-server` should store a Helm source plus a Kustomize preset reference:
|
|
|
|
```yaml
|
|
source:
|
|
type: helm
|
|
repositoryUrl: https://kuoss.github.io/helm-charts
|
|
chart: code-server
|
|
version: 3.16.1
|
|
releaseName: "{{ name }}"
|
|
preset:
|
|
type: kustomize
|
|
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
|
|
ref: main
|
|
path: packages/code-server/presets/k3s-hami
|
|
```
|
|
|
|
For one deployment, `ocdp-server` stores the Helm chart reference, static Helm
|
|
values, preset reference, and the template value contract. The preset renders
|
|
with Workload `spec.values`, so environment-specific implementation details
|
|
should live in the selected preset instead of in the WorkloadTemplate create
|
|
form.
|
|
|
|
## Exposure
|
|
|
|
Base services should stay internally reachable unless an environment preset
|
|
intentionally changes the Service shape. For standard self-service workloads,
|
|
exposure is an admin preset decision and a user read view, not a user claim
|
|
input.
|
|
|
|
Reusable components are still useful implementation building blocks:
|
|
|
|
- `components/ingress`: keep the app Service internal and route through an
|
|
ingress controller.
|
|
- `components/service-loadbalancer`: change the app Service to `LoadBalancer`.
|
|
- `components/service-nodeport`: change the app Service to `NodePort`.
|
|
|
|
When a preset needs NodePort, it may leave the concrete nodePort for Kubernetes
|
|
to allocate:
|
|
|
|
```yaml
|
|
- op: add
|
|
path: /spec/type
|
|
value: NodePort
|
|
```
|
|
|
|
Do not hard-code shared NodePort values in app bases or reusable components.
|
|
|
|
Environment overlays are different from user values. They are selected by the
|
|
platform from cluster, workspace, or customer policy information and can carry
|
|
things like Service type, StorageClass, IngressClass, GPU runtime class,
|
|
registry prefix, pull-secret wiring, node selectors, tolerations, and
|
|
site-specific labels. The user-facing exposure view is derived after reconcile:
|
|
ClusterIP is hidden from ordinary users, NodePort uses the agent access host and
|
|
observed nodePort, and LoadBalancer uses observed external IP/hostname and port.
|
|
|
|
## Validate
|
|
|
|
```bash
|
|
make validate
|
|
```
|
|
|
|
`make validate` runs `kubectl kustomize` against non-user test overlays under
|
|
`tests/kustomize`.
|