Add e2e test for Dynamic LoRA Adapter Sidecar metrics scraping

[shotarok]

What would you like to be added

Add end-to-end (e2e) tests to verify that Dynamic LoRA Adapter Sidecar metrics can be properly scraped from the metrics endpoint at port 8080.

Why is this needed

As discussed in PR #980, we need comprehensive e2e tests that include test cases for scraping Dynamic LoRA Adapter Sidecar metrics with assertions for the expected metrics. The PR introduces the lora_syncer_adapter_status metric, but we currently lack e2e tests that validate the full metrics scraping workflow in a real deployment scenario.

The Dynamic LoRA Adapter Sidecar currently exposes the following metrics:

• lora_syncer_adapter_status: Status of LoRA adapters (1=loaded, 0=not_loaded) with adapter_name label

Implementation Details

The e2e test should:

1. Deploy a vLLM model server with dynamic LoRA adapter sidecar container
2. Configure a ConfigMap to specify which LoRA adapters to load/unload
3. Trigger adapter loading/unloading operations
4. Scrape the metrics endpoint at port 8080
5. Assert that the lora_syncer_adapter_status metric is present with appropriate values
6. Verify metrics reflect the correct adapter status (loaded/not loaded)

Current Limitations

As mentioned in the PR discussion, the vLLM simulator currently does not support the following endpoints needed for complete e2e testing

• /v1/load_lora_adapter
• /v1/unload_lora_adapter

This issue can be implemented once the vLLM simulator is enhanced to support these endpoints, or by using a real vLLM deployment in the e2e test environment.

[UPDATED] vllm-simulator supports the endpoints. So, there is no limitation for the e2e test.

Related Issues

Resolves discussion in PR #980: #980 (comment)
Depends on: vLLM simulator enhancement to support LoRA adapter endpoints

[shotarok]

I updated the current limitations in the issue description because it turns out the vllm-simulator supports the endpoints: llm-d/llm-d-inference-sim#58 (comment).

[shotarok]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale