[Operator] Add separate resource requests and limits

[banlor]

Summary

The operator currently copies one CPU and memory value into both requests and limits, so users cannot tune scheduling and caps independently.

• Add separate CPU and memory requests and limits to the operator resource API.
• Keep the existing flat resource fields as backward-compatible defaults.
• Apply the same conversion to VLLMRuntime, its sidecar, VLLMRouter, and CacheServer.
• Keep GPU requests and limits equal because Kubernetes requires that for extended resources.

Tests

• Focused controller resource tests and API/CRD validation tests
• go vet ./...
• go build ./...
• Full Go suite compared with clean main; both had the same seven Windows envtest failures, and the e2e target requires GNU Make on this host
• Generated CRD, deepcopy, sample, and installer parity checks

Closes #901

[gemini-code-assist]

Code Review

This pull request introduces support for independent CPU and memory requests and limits within ResourceRequirements across VLLMRuntime, VLLMRouter, and CacheServer resources, while preserving backward compatibility with flat resource fields. It adds schema validation, helper functions for building and comparing resources, and comprehensive unit tests. One critical issue was identified in the sidecar container defaulting logic, where explicitly configured requests can exceed the default limits, potentially causing Pod creation failures. A fix was suggested to dynamically adjust limits to match requests in these scenarios.

[gemini-code-assist]

When only requests.cpu or requests.memory is explicitly configured for the sidecar (e.g., requests.cpu: "1"), the flat defaults (cpu: "0.5" and memory: "128Mi") are still applied to the limits. This results in an invalid resource configuration where the request is greater than the limit (e.g., request 1 vs limit 0.5), causing the Kubernetes API server to reject the Pod creation.

To prevent this, we should ensure that the limits are automatically adjusted to be at least equal to the requests if the default limits are lower than the explicitly requested values.

	sidecarResourceConfig := sidecarConfig.Resources
	if sidecarResourceConfig.CPU == "" {
		sidecarResourceConfig.CPU = "0.5"
	}
	if sidecarResourceConfig.Memory == "" {
		sidecarResourceConfig.Memory = "128Mi"
	}
	if sidecarResourceConfig.GPU == "" {
		sidecarResourceConfig.GPU = "0"
	}
	sidecarResources, err := buildResourceRequirements(sidecarResourceConfig)
	if err != nil {
		return corev1.Container{}, fmt.Errorf("build VLLMRuntime sidecar resources: %w", err)
	}

	// Ensure requests do not exceed limits due to sidecar defaulting
	if cpuReq, ok := sidecarResources.Requests[corev1.ResourceCPU]; ok {
		if cpuLimit, ok := sidecarResources.Limits[corev1.ResourceCPU]; ok {
			if cpuReq.Cmp(cpuLimit) > 0 {
				sidecarResources.Limits[corev1.ResourceCPU] = cpuReq.DeepCopy()
			}
		}
	}
	if memReq, ok := sidecarResources.Requests[corev1.ResourceMemory]; ok {
		if memLimit, ok := sidecarResources.Limits[corev1.ResourceMemory]; ok {
			if memReq.Cmp(memLimit) > 0 {
				sidecarResources.Limits[corev1.ResourceMemory] = memReq.DeepCopy()
			}
		}
	}

[banlor]

fixed in this update. sidecar defaults now adjust around one-sided CPU and memory values, and explicit request-over-limit combinations fail before reconciliation. added regressions for all four controller paths.