ocdp-workload-manifests

Standalone Kubernetes manifests and post-renders 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 postRenders from this repository.

Architecture

OCDP keeps the responsibilities split:

Git repo
  apps/<app>/base
  apps/<app>/components
  packages/<app>/post-renders/<postRender>
    kustomization.yaml
    userInputs.yaml

ocdp-server PostgreSQL
  WorkloadTemplate metadata
  WorkloadTemplate Helm source
  WorkloadTemplate source.postRender.repositoryUrl/ref/path
  user-facing values schema / parameters
  access bindings
  no Workload instance storage

target cluster
  Workload CR as the canonical user workload
  runtime Kubernetes resources

This repository stores Git bases, reusable components, and Kustomize postRenders. For Helm-backed workloads, the operator runs helm template first, writes that output as rendered.yaml, then renders the selected postRender with Workload spec.values. A postRender 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 postRenders:

templateType: composite
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
  postRender:
    type: kustomize
    repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
    ref: main
    path: packages/code-server/post-renders/k3s-hami

After the template is stored in PostgreSQL and assigned to users or groups, users call ocdp-server to create a workload by submitting templateId, workspaceId, and values. ocdp-server resolves the template from PostgreSQL and writes a Workload CR into the target Kubernetes cluster. The operator renders Helm with the resolved values, applies the Kustomize postRender, and then applies the final Kubernetes resources. The final user-created workload lives in Kubernetes, not in PostgreSQL.

Layout

apps/
  code-server/
    base/
    components/
  vllm-server/
    base/
    components/
  litellm/
    base/
    components/
packages/
  code-server/
    post-renders/
      k3s-hami/
        kustomization.yaml
        userInputs.yaml
      k3s-hami-v4/
        kustomization.yaml
        userInputs.yaml
tests/
  kustomize/

Server Usage

ocdp-server should store a Helm source plus a Kustomize postRender reference:

source:
  type: helm
  repositoryUrl: https://kuoss.github.io/helm-charts
  chart: code-server
  version: 3.16.1
  releaseName: "{{ name }}"
  postRender:
    type: kustomize
    repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
    ref: main
    path: packages/code-server/post-renders/k3s-hami

For one deployment, ocdp-server stores the Helm chart reference, static Helm values, postRender reference, and the template value contract. The postRender renders with Workload spec.values, so environment-specific implementation details should live in the selected postRender instead of in the WorkloadTemplate create form.

Exposure

Base services should stay internally reachable unless an environment postRender intentionally changes the Service shape. For standard self-service workloads, exposure is an admin postRender decision and a user read view, not a user workload 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 postRender needs NodePort, it may leave the concrete nodePort for Kubernetes to allocate:

- 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

make validate

make validate runs kubectl kustomize against non-user test overlays under tests/kustomize.

5.0 KiB Raw Blame History