|
| 1 | +--- |
| 2 | +title: Using KitOps with Kubeflow Model Registry |
| 3 | +description: Minimal quickstart for packaging a ModelKit with KitOps and storing it behind Kubeflow Model Registry using OCI-based storage. |
| 4 | +keywords: kubeflow model registry, kitops, modelkit, oci model registry, kubeflow oci, modelpack kubeflow, model registry oci storage, kubeflow kitops integration |
| 5 | +--- |
| 6 | + |
| 7 | +# Using KitOps with Kubeflow Model Registry |
| 8 | + |
| 9 | +This guide shows a **small, end-to-end quickstart** for using KitOps with the Kubeflow Model Registry: |
| 10 | + |
| 11 | +- Package a tiny sklearn model as a **ModelKit**. |
| 12 | +- Push it to an **OCI registry**. |
| 13 | +- Reference that same OCI location from **Kubeflow Model Registry**. |
| 14 | + |
| 15 | +Once this is working, you can extend it into full pipelines, CI/CD, and richer metadata workflows. |
| 16 | + |
| 17 | +## Architecture Overview |
| 18 | + |
| 19 | +High-level flow: |
| 20 | + |
| 21 | +```mermaid |
| 22 | +flowchart LR |
| 23 | + A[Local Model (sklearn .pkl)] --> B[KitOps ModelKit] |
| 24 | + B --> C[OCI Registry (e.g., ECR / GCR / Harbor)] |
| 25 | + C --> D[Kubeflow Model Registry] |
| 26 | + D --> E[Kubeflow Pipeline / Notebook] |
| 27 | +``` |
| 28 | + |
| 29 | +- **Local / CI**: Train and export a model (for example, a sklearn `.pkl` file). |
| 30 | +- **KitOps**: Use `kit init` and `kit pack` to create a ModelKit. |
| 31 | +- **OCI registry**: Store the ModelKit in any OCI-compatible registry. |
| 32 | +- **Kubeflow Model Registry**: Register a model/version whose URI points at that OCI reference. |
| 33 | +- **Kubeflow Pipelines / notebooks**: Resolve the version from the registry and use KitOps to unpack the ModelKit for inference or further processing. |
| 34 | + |
| 35 | +## Prerequisites |
| 36 | + |
| 37 | +- **KitOps CLI** installed — follow the [KitOps installation guide](../cli/installation.md). |
| 38 | +- Access to an **OCI-compatible registry** (for example, `ghcr.io`, ECR, GCR, Harbor, Docker Hub, or JFrog Artifactory). |
| 39 | +- A **Kubeflow cluster** with the **Model Registry** component installed. See Kubeflow’s [Model Registry getting started guide](https://www.kubeflow.org/docs/components/model-registry/getting-started/). |
| 40 | +- `kubectl` configured for the cluster and rights to create or use registry credentials (Kubernetes Secrets). |
| 41 | +- Python environment (with `scikit-learn` and `pickle`) available for training a tiny sklearn model. |
| 42 | + |
| 43 | +> In this quickstart, replace `<registry>`, `<repo-namespace>`, `<k8s-namespace>`, and `my-modelkit` with values that match your environment. |
| 44 | +
|
| 45 | +## Quickstart (local) |
| 46 | + |
| 47 | +This section focuses on **local steps**: install KitOps, package a tiny model (for example, `model.pkl`) as a ModelKit, then push it to an OCI registry that Kubeflow Model Registry can later reference. |
| 48 | +For local cluster testing, you can use tools like `minikube` or `kind` with registry access configured. This is useful when validating Kubernetes Secrets and Kubeflow pipeline steps. |
| 49 | + |
| 50 | +### 1. Install and verify the Kit CLI |
| 51 | + |
| 52 | +Follow the official [installation instructions](../cli/installation.md) for your OS (Homebrew, ZIP/TAR, or build-from-source). |
| 53 | + |
| 54 | +Verify the binary is available: |
| 55 | + |
| 56 | +```bash |
| 57 | +kit --help |
| 58 | +``` |
| 59 | + |
| 60 | +(Optional) You can also validate these steps by building KitOps from source (using the “Build KitOps from Source” section in the install docs) and running `kit --help`. |
| 61 | + |
| 62 | +### 2. Train and save a tiny sklearn model |
| 63 | + |
| 64 | +Create and run a small Python script (for example, `train_and_save.py`) to produce `model.pkl`: |
| 65 | + |
| 66 | +```python |
| 67 | +from sklearn.linear_model import LogisticRegression |
| 68 | +import pickle |
| 69 | + |
| 70 | +X = [[0], [1], [2], [3]] |
| 71 | +y = [0, 0, 1, 1] |
| 72 | + |
| 73 | +model = LogisticRegression().fit(X, y) |
| 74 | + |
| 75 | +with open("model.pkl", "wb") as f: |
| 76 | + pickle.dump(model, f) |
| 77 | +``` |
| 78 | + |
| 79 | +After running the script you should have: |
| 80 | + |
| 81 | +```bash |
| 82 | +ls |
| 83 | +# model.pkl |
| 84 | +# train_and_save.py |
| 85 | +``` |
| 86 | + |
| 87 | +### 3. Create and package a ModelKit |
| 88 | + |
| 89 | +Create a directory to hold the ModelKit contents and generate a `Kitfile`: |
| 90 | + |
| 91 | +```bash |
| 92 | +mkdir my-modelkit |
| 93 | +cp model.pkl my-modelkit/ |
| 94 | +cd my-modelkit |
| 95 | + |
| 96 | +kit init . \ |
| 97 | + --name "my-modelkit" \ |
| 98 | + --desc "Minimal sklearn demo model" \ |
| 99 | + --author "ML Platform Team" |
| 100 | +``` |
| 101 | + |
| 102 | +This creates the minimal ModelKit metadata (a manifest file such as `Kitfile` or `modelkit.yaml`, depending on your KitOps version) that tells KitOps which files belong in the ModelKit. |
| 103 | + |
| 104 | +Example manifest (illustrative — confirm manifest field names with the KitOps manifest schema in the CLI docs). For this tiny model it might look like: |
| 105 | + |
| 106 | +```yaml |
| 107 | +# illustrative manifest — confirm fields with the KitOps manifest schema in the CLI docs |
| 108 | +manifestVersion: 1.0 |
| 109 | +package: |
| 110 | + name: my-modelkit |
| 111 | + description: Minimal sklearn demo model |
| 112 | + version: 0.1.0 |
| 113 | + authors: |
| 114 | + - ML Platform Team |
| 115 | +model: |
| 116 | + path: model.pkl |
| 117 | +``` |
| 118 | +
|
| 119 | +Now pack the directory into a ModelKit and tag it with your OCI reference: |
| 120 | +
|
| 121 | +```bash |
| 122 | +kit pack . \ |
| 123 | + -t <registry>/<repo-namespace>/my-modelkit:0.1.0 |
| 124 | +``` |
| 125 | + |
| 126 | +This builds a local ModelKit that is ready to be pushed. |
| 127 | + |
| 128 | +### 4. Push the ModelKit to an OCI registry |
| 129 | + |
| 130 | +First log in to the registry (only needed once per environment). The `kit` command examples below show typical flags; if you see errors, confirm the exact subcommands/flags for your version of KitOps in the [CLI reference](../cli/cli-reference.md): |
| 131 | + |
| 132 | +```bash |
| 133 | +kit login <registry> -u "<REGISTRY_USER>" -p "<REGISTRY_PASSWORD>" |
| 134 | +``` |
| 135 | + |
| 136 | +If your registry uses Docker-native authentication, you can also run: |
| 137 | + |
| 138 | +```bash |
| 139 | +docker login <registry> |
| 140 | +``` |
| 141 | + |
| 142 | +or use any registry-specific auth flow (for example, GitHub Container Registry with a personal access token). |
| 143 | +> Example: GitHub Container Registry (GHCR) requires a personal access token (PAT) as the password. |
| 144 | +
|
| 145 | +Then push the tagged ModelKit: |
| 146 | + |
| 147 | +```bash |
| 148 | +kit push <registry>/<repo-namespace>/my-modelkit:0.1.0 |
| 149 | +``` |
| 150 | + |
| 151 | +**Note:** The `kit` examples are illustrative. Confirm exact subcommands/flags for your installed KitOps CLI version in `../cli/cli-reference.md`. |
| 152 | + |
| 153 | +At this point you have: |
| 154 | + |
| 155 | +- A tiny sklearn model packaged as a **ModelKit**. |
| 156 | +- Stored in your **OCI registry** under the reference |
| 157 | + `<registry>/<repo-namespace>/my-modelkit:0.1.0`. |
| 158 | + |
| 159 | +If your registry is private and you run Kubeflow in a Kubernetes cluster, create a Docker registry Secret so cluster workloads (including Kubeflow) can pull the ModelKit image: |
| 160 | + |
| 161 | +```bash |
| 162 | +kubectl create secret docker-registry kitops-regcred \ |
| 163 | + --docker-server=<registry> \ |
| 164 | + --docker-username=<username> \ |
| 165 | + --docker-password=<password> \ |
| 166 | + --docker-email=<email> \ |
| 167 | + -n <k8s-namespace> |
| 168 | +``` |
| 169 | + |
| 170 | +You can then reference this Secret via `imagePullSecrets` on a `ServiceAccount`, Pod spec, or Kubeflow workload so the cluster can pull from your registry. |
| 171 | + |
| 172 | +For example, attach it to a `ServiceAccount` (replace `default` with the ServiceAccount used by your Kubeflow components or pipeline runtime): |
| 173 | + |
| 174 | +```bash |
| 175 | +kubectl patch serviceaccount default \ |
| 176 | + -p '{"imagePullSecrets": [{"name": "kitops-regcred"}]}' \ |
| 177 | + -n <k8s-namespace> |
| 178 | +``` |
| 179 | + |
| 180 | +Replace `<repo-namespace>` (OCI repository namespace) and `<k8s-namespace>` (Kubernetes namespace) with values that match your environment. |
| 181 | + |
| 182 | +### 5. Verify in Kubeflow Model Registry |
| 183 | + |
| 184 | +With the ModelKit available in your registry, you can now reference it from Kubeflow Model Registry. |
| 185 | + |
| 186 | +Use the official Kubeflow documentation to: |
| 187 | + |
| 188 | +1. Access the Model Registry UI or API endpoint in your cluster. |
| 189 | +2. Create or register a model (for example, `my-modelkit`) and use the full OCI reference |
| 190 | + `<registry>/<repo-namespace>/my-modelkit:0.1.0` as the backing URI or storage location. |
| 191 | +3. Confirm that the model and version appear in the Model Registry UI or by calling the Python client’s `list_models()` (or equivalent) in a notebook. |
| 192 | + |
| 193 | +For detailed steps, see the Kubeflow [Model Registry getting started guide](https://www.kubeflow.org/docs/components/model-registry/getting-started/). |
| 194 | + |
| 195 | +Once this is working, you can: |
| 196 | + |
| 197 | +- Use Kubeflow Model Registry to track additional versions (`0.2.0`, `1.0.0`, etc.). |
| 198 | +- Resolve the “current” version from notebooks or pipelines. |
| 199 | +- Call KitOps (`kit pull` / `kit unpack`) inside Kubeflow workloads using that same OCI reference. |
| 200 | + |
| 201 | +Common patterns for **Kubeflow-side authentication** include: |
| 202 | + |
| 203 | +- Configuring `imagePullSecrets` on the `ServiceAccount` used by Kubeflow components. |
| 204 | +- Storing registry credentials in Secrets used by controllers or pipeline runtimes. |
| 205 | +- Mounting workload-specific Secrets into Pods that run `kit` commands. |
| 206 | + |
| 207 | +**Tested with:** |
| 208 | +- KitOps CLI version: TBD (TODO) |
| 209 | +- Kubeflow version: TBD (TODO) |
| 210 | +- Local test cluster: TBD (TODO) |
| 211 | + |
| 212 | +## Links and References |
| 213 | + |
| 214 | +- **KitOps docs** |
| 215 | + - [Install KitOps CLI](../cli/installation.md) |
| 216 | + - [Kit CLI reference](../cli/cli-reference.md) |
| 217 | + - [Getting started with ModelKits](../get-started.md) |
| 218 | +- **Kubeflow Model Registry** |
| 219 | + - [Getting started](https://www.kubeflow.org/docs/components/model-registry/getting-started/) |
| 220 | + - [Python client reference](https://www.kubeflow.org/docs/components/model-registry/reference/python-client/) |
| 221 | + |
| 222 | +If your documentation site does not render Mermaid diagrams, you can include a static PNG (for example, `kubeflow-model-registry-architecture.png`) as a fallback representation of the architecture. |
| 223 | + |
| 224 | + |
0 commit comments