KitOps Documentation

repository·main·Indexed 23 days ago

https://github.com/kitops-ml/kitops

KitOps is a CNCF open-source tool for packaging, versioning, and securely sharing AI/ML projects using OCI-compliant ModelKits. It enables teams to treat AI assets like container images for standardized deployment, security scanning, and lifecycle management. The project includes the Kit CLI for managing ModelKits, the PyKitOps Python SDK for programmatic integration, and support for cryptographic signatures via Cosign and AI Bill of Materials (AI SBOM) for compliance.

Tokens
58.1K
Snippets
153
Records
310
Agent score
75%

What's inside KitOps

  1. What is KitOps?

    main
    KitOps is an open-source standard for packaging, versioning, and sharing AI projects. It bundles models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation into a single versioned OCI (Open Container Initiative) artifact. These artifacts are stored in your existing container registry, allowing you to manage AI assets just like container images.
  2. Use KitOps with MLOps, Serving, and Pipeline tools

    main

    Because KitOps follows OCI standards, it is compatible with a wide range of tools across the ML lifecycle.

    MLOps Tools

    KitOps works with major platforms for model tracking, experimentation, and orchestration, including:

    • Amazon SageMaker, Azure ML, Google Vertex, Databricks, MLFlow, Weights & Biases, Hugging Face, Kubeflow, and more.

    Serving Platforms

    Any platform that accepts containers can serve KitOps ModelKits, such as:

    • Kubernetes (EKS, AKS, GKE), Kserve, Red Hat OpenShift, Amazon Fargate, and Amazon Lambda.

    Pipeline & Storage Tools

    KitOps integrates with standard CI/CD and storage tools:

    • CI/CD: GitHub Actions, GitLab Pipelines, Jenkins, Circle CI, Argo CD, and Tekton.
    • Storage/Version Control: Amazon S3, Git, and Git LFS.
  3. What is a ModelKit?

    main

    A ModelKit is a self-contained, immutable, and versioned bundle used to package AI/ML projects. It is built on OCI (Open Container Initiative) technology, allowing it to be stored and retrieved from any standard container registry.

    A ModelKit can include:

    • Model weights
    • Datasets
    • Agents and MCP servers
    • Prompts and metadata
    • Environment configurations and code
    • Experiment run results and hyperparameters

    Key Properties:

    • Tamper-proof: Every component is protected by SHA-256 digests.
    • Signable: Fully compatible with Cosign for cryptographic verification.
    • Compatible: Natively works with all major OCI container registries.
    • Selectively unpacked: You can pull only specific layers (e.g., just the model weights) without downloading the entire bundle.
  4. What is a Kitfile?

    main

    A Kitfile is a YAML-based manifest that serves as the blueprint for an AI project packaged as a ModelKit in KitOps. It defines the components of your project—such as models, datasets, code, prompts, and documentation—allowing you to package, version, and deploy them via any OCI-compatible registry.

    Key benefits include:

    • Full traceability for models, agents, or combined projects.
    • Reproducibility across different environments.
    • Seamless collaboration between ML, DevOps, and AI engineers.
    • Integration with CI/CD pipelines.
  5. What is ModelKit?

    main

    ModelKit is a standardized, OCI-compliant packaging format designed for AI projects. It bundles various AI project artifacts—such as models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation—into a single, versioned, and shareable artifact.

    Key characteristics include:

    • OCI-compliant: ModelKits can be stored, tagged, and versioned in any standard container registry (e.g., DockerHub, GitHub Packages, or private registries) using familiar DevOps tools.
    • Selective Unpacking: You can unpack specific parts of a kit (e.g., only prompts or only model weights) to optimize pipelines.
    • Asset Reuse: Supports reusing shared assets like datasets or configs across multiple kits without duplicating storage.
    • Versatile Content: Handles both large binary files (model weights) and small text files (prompts, configs) within the same artifact.
  6. Understand the ModelKit structure and components

    main

    A ModelKit is a comprehensive bundle of AI/ML artifacts (models, datasets, code, and parameters). It is composed of three primary elements:

    1. Artifacts: The modular building blocks of the kit. Each artifact is stored and addressed individually. Supported media types include:
      • Serialized Model: application/vnd.kitops.modelkit.model.v1.tar
      • Additional Model files (e.g. adaptors): application/vnd.kitops.modelkit.modelpart.v1.tar
      • Datasets: application/vnd.kitops.modelkit.dataset.v1.tar
      • Code: application/vnd.kitops.modelkit.code.v1.tar
      • Docs: application/vnd.kitops.modelkit.docs.v1.tar
    2. Kitfile: A central record (using application/vnd.kitops.modelkit.config.v1+json) that details the properties, relationships, and intended uses of the included artifacts.
    3. ModelKit Manifest: An immutable JSON document following the OCI Image Manifest Specification. It contains metadata like creation date, authorship, and cryptographic hashes of all artifacts and the Kitfile to ensure integrity.
  7. Verify ModelKit signatures in Kubernetes

    main

    The Kit init container supports Sigstore [Cosign] verification to ensure ModelKit integrity. You can use either local keys or keyless OIDC verification.

    Option A: Local Cosign Key

    1. Store your Cosign public key in a Kubernetes Secret.
    2. Mount the Secret as a volume in the initContainer.
    3. Set the COSIGN_KEY environment variable to the path where the key is mounted.

    Option B: Keyless OIDC Verification

    Set the following environment variables in the initContainer:

    • COSIGN_CERT_IDENTITY: The expected identity.
    • COSIGN_CERT_OIDC_ISSUER: The OIDC issuer URL.
  8. Identify and name ModelKits using IDs, Tags, and Repositories

    main

    ModelKits are managed using a hierarchical naming system:

    • ModelKitID: A unique identifier derived from the SHA256 hash of the manifest (e.g., sha256:a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9).
    • Tag: A user-friendly descriptive name mapped to a ModelKitID.
      • Allowed characters: [a-zA-Z0-9_.-]
      • Constraints: Cannot start with . or -; maximum length of 128 characters.
    • Repository: A collection of tags grouped under a common prefix.
      • Format: repository:tag (e.g., in myllm:3.1.4, myllm is the repository).
      • Structure: Slash-separated name components, optionally prefixed by a DNS hostname (which may include an optional port like :8080).
      • Name Component Rules: May contain lowercase characters, digits, and separators (period ., one or two underscores __, or one or more dashes -). Components cannot start or end with a separator.
  9. Cancel KitOps operations with timeouts or signals

    main

    Every KitOps function returns a CancellablePromise. You can call .cancel() to terminate the underlying process. This is useful for:

    1. Timeouts: Imposing a deadline on long-running operations like push or pull.
    2. User Signals: Wiring cancellation to signals like SIGINT for graceful interruption.

    When cancelled, the promise rejects with an AbortError (specifically a DOMException with name: 'AbortError').

    import { push } from '@kitops/kitops-ts';
    
    async function pushWithTimeout(ref, timeoutMs) {
      const op = push(ref);
      const timer = setTimeout(() => op.cancel(), timeoutMs);
    
      try {
        await op;
      } catch (err) {
        if (err instanceof DOMException && err.name === 'AbortError') {
          console.error(`Push timed out after ${timeoutMs}ms`);
          process.exit(1);
        }
        throw err;
      } finally {
        clearTimeout(timer);
      }
    }
    
    await pushWithTimeout('registry.example.com/org/my-model:v1.0.0', 5 * 60 * 1000);
    import { pull } from '@kitops/kitops-ts';
    
    const op = pull('registry.example.com/org/my-model:v1.0.0');
    
    process.once('SIGINT', () => {
      console.log('\nInterrupted — cancelling pull…');
      op.cancel();
    });
    
    try {
      await op;
      console.log('Pull complete.');
    } catch (err) {
      if (err instanceof DOMException && err.name === 'AbortError') {
        console.log('Pull cancelled.');
        process.exit(130); // standard exit code for SIGINT
      }
      throw err;
    }
  10. Understand OCI Manifest types for ModelKits

    main

    When using the inspect() method, KitOps returns an OCI image manifest. The Manifest object contains the schemaVersion, mediaType, and an artifactType. The config field holds the Kitfile descriptor, while the layers array contains descriptors for each content layer. Metadata can be attached via annotations.

    interface Manifest {
      schemaVersion: number;
      mediaType: string;
      artifactType?: string;
      config: ManifestDescriptor;
      layers: ManifestDescriptor[];
      annotations: ManifestAnnotations;
    }
  11. Use FilterFlag to select specific layers or paths

    main

    A FilterFlag is a string expression used by unpack and info commands to target specific content within a ModelKit.

    Accepted Formats:

    • 'model': Selects the entire model layer.
    • 'datasets:training': Selects a named dataset (e.g., datasets:training).
    • 'docs:./README.md': Selects a specific file within a layer (e.g., docs:./README.md).
    • 'model,datasets:validation': Selects multiple layers using comma-separated values.
    type FilterFlag = string