> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensormesh.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Started

> Pick an install method for Tensormesh Platform and verify your cluster is ready.

This page covers what you need before installing **Tensormesh Platform** and helps you pick an
install method. The Helm method installs the operator and its CRDs; "Modify an Existing vLLM
Deployment" wires an existing vLLM workload to an operator you've already installed.

## What gets installed

<CardGroup cols={2}>
  <Card title="Operator" icon="gear">
    A small controller-manager Deployment that watches the CRs below cluster-wide. It also
    serves the mutating webhook that wires vLLM pods to the engine.
  </Card>

  <Card title="CRDs" icon="file-code">
    `LMCacheEngine`, `LMCacheCoordinator`, and `CacheBlendEngine` — the specs the operator reconciles.
  </Card>

  <Card title="Engine DaemonSet" icon="layer-group">
    One LMCache cache server pod per GPU node, created by the operator from your CR.
  </Card>

  <Card title="Coordinator" icon="sitemap">
    A fleet-wide Deployment the engines register with, for cross-node cache coordination.
  </Card>
</CardGroup>

## Prerequisites

<AccordionGroup>
  <Accordion title="Kubernetes 1.28 or newer" icon="dharmachakra">
    The chart's `kubeVersion` constraint is `>=1.28.0-0`. OpenShift 4.16+ and EKS / GKE / AKS
    on a supported control plane all qualify.
  </Accordion>

  <Accordion title="At least one GPU node" icon="microchip">
    The engine DaemonSet schedules onto nodes labeled `nvidia.com/gpu.present=true`. On
    clusters with the NVIDIA GPU Operator installed, this label is set automatically. On
    clusters without it, label your GPU nodes manually:

    ```bash theme={null}
    kubectl label node <node-name> nvidia.com/gpu.present=true
    ```

    On a cluster with no GPU nodes the install still succeeds; the DaemonSet stays at
    `0` desired replicas until a matching node appears.
  </Accordion>

  <Accordion title="CDI enabled (NVIDIA GPU Operator < v25.10.0)" icon="microchip">
    The NVIDIA GPU Operator exposes GPUs via the Container Device Interface (CDI). Before GPU
    Operator v25.10.0, CDI was off by default (`cdi.enabled: false`). With it off, the engine/vLLM
    pods get stuck in `ContainerCreating` with no clear error.
    On those versions, enable CDI in the GPU `ClusterPolicy`:

    ```bash theme={null}
    oc patch clusterpolicy gpu-cluster-policy --type=merge -p '{
      "spec": { "cdi": { "enabled": true, "default": true } }
    }'
    ```

    GPU Operator v25.10.0+ enables CDI by default; no action needed. See
    [Troubleshooting → Pod stuck in `ContainerCreating`](/v1.0.0/installation/troubleshooting#pod-stuck-in-containercreating-cdi)
    if you hit this.
  </Accordion>

  <Accordion title="Cluster-admin permissions" icon="shield-halved">
    Installation creates cluster-scoped objects (a CRD, a `ClusterRole`, and a
    `ClusterRoleBinding`). You need permission to create those.
  </Accordion>

  <Accordion title="A CLI for your platform" icon="terminal">
    `kubectl` on Kubernetes, `oc` on OpenShift. The two are interchangeable for everything
    in these docs. Examples are shown with `kubectl` unless an OpenShift-specific command
    is required.
  </Accordion>
</AccordionGroup>

## Pick an install method

<CardGroup cols={2}>
  <Card title="Helm" icon="circle-nodes" href="/v1.0.0/installation/helm">
    The primary path. Single `helm install` command, simple upgrades and rollbacks.
  </Card>

  <Card title="Modify Existing vLLM Deployment" icon="wrench" href="/v1.0.0/installation/existing-deployment">
    Patch an existing vLLM Deployment to mount the engine connection ConfigMap and use
    LMCache MP mode safely.
  </Card>
</CardGroup>

## Verify your cluster is ready

Run these three preflight checks before installing.

<Steps>
  <Step title="Kubernetes is 1.28 or newer">
    ```bash theme={null}
    kubectl version
    ```

    Look at the `Server Version` line: anything `v1.28.0` or newer qualifies. OpenShift
    users can also run `oc version`; the `Kubernetes Version` line is what matters.
  </Step>

  <Step title="At least one GPU node is labeled (or you accept an empty DaemonSet)">
    ```bash theme={null}
    kubectl get nodes -l nvidia.com/gpu.present=true
    ```

    A non-empty list means the engine DaemonSet has somewhere to schedule. An empty list
    is fine for an operator-only install; see
    [Install with Helm](/v1.0.0/installation/helm#quick-install).
  </Step>

  <Step title="You can create cluster-scoped resources">
    ```bash theme={null}
    kubectl auth can-i create customresourcedefinitions.apiextensions.k8s.io
    kubectl auth can-i create clusterroles.rbac.authorization.k8s.io
    kubectl auth can-i create clusterrolebindings.rbac.authorization.k8s.io
    ```

    All three must return `yes`. As a shortcut,
    `kubectl auth can-i '*' '*' --all-namespaces` returning `yes` means you're effectively
    cluster-admin.

    Each command also prints a `Warning: resource '...' is not namespace scoped` line;
    that's expected (these *are* cluster-scoped resources) and harmless. The `yes`/`no`
    answer is what matters.
  </Step>
</Steps>

If any check fails: bump the cluster version, label the GPU nodes (see the prerequisites above), or
ask a cluster admin for the missing RBAC.