feature: support CRD-based configuration

Describe the feature

This issue proposes using CRD to manage the vLLM engine deployments for more flexible management of resources. Specifically, I propose an alternative design for the current helm chart deployment mechanism (not replacing helm chart, but a complementary deployment mechanism) to start vLLM engines/PVCs/services with CRD, and the current fields in the CRDs in my initial version are in the followed example CR manifest. Most fields are inherited from current helm chart template.

apiVersion: serving.vllm.ai/v1alpha1
kind: ProductionStack
metadata:
  name: test-stack
spec:
  # Deployment strategy
  deploymentStrategy: "Recreate"  # Optional: default is RollingUpdate. Recreat is only used for testing on 1 gpu server

  # Model configuration
  model:
    name: "Llama-3.2-1B-Instruct"
    path: ""  # Optional: local path to model files
    modelURL: "meta-llama/Llama-3.2-1B-Instruct"  # Optional: URL to download model
    enableLoRA: false  # Optional: enable LoRA support
    enableTool: false  # Optional: enable automatic tool choice
    toolCallParser: ""  # Optional: specify tool call parser
    chatTemplate: ""  # Optional: specify chat template
    trustRemoteCode: false  # Optional: enable loading custom model code
    dtype: "float16"  # Optional: data type (float16, bfloat16, or float32)
    maxNumSeqs: 256  # Optional: maximum number of sequences to process in parallel
    maxModelLen: 4096  # Optional: maximum model length

  # vLLM-specific configuration
  vllmConfig:
    image: "vllm/vllm-openai:v0.8.3"  # Optional: default is vllm/vllm-openai:latest
    imagePullRegistry: "docker.io"  # Optional: default is docker.io
    imagePullPolicy: "IfNotPresent"  # Optional: Always, IfNotPresent, or Never
    imagePullSecretName: ""  # Optional: secret for pulling images
    hfTokenSecret:
      name: "huggingface-token"  # Optional: secret for Hugging Face token
    enableChunkedPrefill: false  # Optional: enable chunked prefill
    enablePrefixCaching: false  # Optional: enable prefix caching
    tensorParallelSize: 1  # Optional: number of GPUs for tensor parallelism
    gpuMemoryUtilization: "0.4"  # Optional: target GPU memory utilization (0.0 to 1.0)
    maxLoras: 0  # Optional: maximum number of LoRAs to support
    extraArgs:  # Optional: additional command-line arguments passed to vllm serve
      - "--block-size=16"
    v1: false  # Optional: enable v1 compatibility mode

  # LM Cache configuration
  lmcacheConfig:
    enabled: false  # Optional: enable LM Cache
    cpuOffloadingBufferSize: "4Gi"  # Optional: size of CPU offloading buffer
    diskOffloadingBufferSize: "8Gi"  # Optional: size of disk offloading buffer
    remoteUrl: ""  # Optional: URL of remote cache server
    remoteSerde: ""  # Optional: serialization format for remote cache

  # Router configuration
  routerConfig:
    routerType: "roundrobin"  # Optional: type of router (roundrobin or session)

  # Number of model serving replicas
  replicas: 1  # Optional: default is 1

  # Resource requirements for each replica
  resources:
    cpu: "4"  # Optional: CPU resource requirement
    memory: "16Gi"  # Optional: memory resource requirement
    gpu: "1"  # Optional: GPU resource requirement

  # Environment variables to set
  env:  # Optional: environment variables
    - name: "CUDA_VISIBLE_DEVICES"
      value: "0"
    - name: "VLLM_LOG_LEVEL"
      value: "INFO"

Why do you need this feature?

To provide better usability and flexibility when managing production stack.

Additional context

No response

Start by reviewing the current Helm chart deployment mechanism and the example ProductionStack manifest in this issue. Determine how the proposed CRD should create and manage vLLM engines, PVCs, and services while remaining complementary to Helm. Done means the CRD-based deployment path supports the listed configuration areas and its behavior is documented and validated.