[BUG]CacheRuntime: a partially specified `resources` silently drops the rest of the container's resource requirements

[btxu-db]

What is your environment(Kubernetes version, Fluid version, etc.)

• Kubernetes v1.30.0 (kind v0.23.0)
• Fluid controller built from 2a4968a9, i.e. the fix for [BUG]container resources in CacheRuntimeClass are silently dropped #6161 (PR fix(cache): preserve CacheRuntimeClass template resources when unset #6165) is already applied — this matters, see Additional Information
• Runtime: CacheRuntime

Describe the bug

AdvancedStatefulSetManager.updateResources replaces the container's entire ResourceRequirements struct rather than merging it key by key:

// pkg/ddc/cache/component/advanced_statefulset_manager.go:299
container.Resources = *resources.DeepCopy()

ResourceRequirements holds Limits, Requests and Claims. Anything the user does not restate in CacheRuntime.spec.<component>.resources is dropped from the workload on the next reconcile, including values that were rendered from the CacheRuntimeClass template at creation time. There is no error and no event.

The practical case is a user who only wants to raise one number. Setting just limits.memory also clears requests.cpu, limits.cpu, requests.memory and claims, which changes both how the pod is scheduled and what caps its usage on the node.

What you expect to happen:

Only the keys the user actually set should change. Values that came from the CacheRuntimeClass template and were not mentioned in the CacheRuntime should survive the sync.

How to reproduce it

1. CacheRuntimeClass whose worker template declares a full set of resources:

topology:
  worker:
    template:
      spec:
        containers:
        - name: worker
          resources:
            requests: {cpu: "1", memory: 2Gi}
            limits:   {cpu: "2", memory: 4Gi}

2. Create a CacheRuntime that does not set spec.worker.resources. The AdvancedStatefulSet correctly
   inherits the template values and stays there (verified stable over 70s of reconciles, generation 1):

gen = 1  {"limits":{"cpu":"2","memory":"4Gi"},"requests":{"cpu":"1","memory":"2Gi"}}

3. Now raise a single value — the memory limit only:

kubectl patch cacheruntime restest --type=merge \
  -p '{"spec":{"worker":{"resources":{"limits":{"memory":"8Gi"}}}}}'

4. Everything else is gone, and the pods roll (generation 1 -> 2):

gen = 2  {"limits":{"memory":"8Gi"}}

limits.cpu: 2, requests.cpu: 1 and requests.memory: 2Gi were all dropped. On the resulting pod:

qosClass = Burstable
worker    {"limits":{"memory":"8Gi"},"requests":{"memory":"8Gi"}}

The container now has no CPU request and no CPU limit at all, so the scheduler stops reserving CPU for it
and nothing caps its CPU usage on the node. The requests.memory: 8Gi is Kubernetes defaulting requests to
limits, which also silently raises the memory reservation from the intended 2Gi to 8Gi.

Additional Information

• This is not a duplicate of [BUG]container resources in CacheRuntimeClass are silently dropped #6161, although both land on the same lines. [BUG]container resources in CacheRuntimeClass are silently dropped #6161 covers the case where resources is not set at all, and its fix (fix(cache): preserve CacheRuntimeClass template resources when unset #6165) makes ComponentSpec.Resources a pointer so that nil means "leave the workload alone". A partially filled value is still non-nil, so it is still applied wholesale and this case survives that fix. The reproduction above was run on a build that already contains fix(cache): preserve CacheRuntimeClass template resources when unset #6165, so this is
  not the old bug resurfacing. The two also want different remedies: [BUG]container resources in CacheRuntimeClass are silently dropped #6161 needed a nil check, this one needs a
  decision about merge semantics.
• A unit-level probe driving updateResources directly confirms Claims is dropped the same way, alongside
  Limits and Requests. The cluster reproduction above does not exercise Claims because the test workload
  does not use DRA.
• image and replicas on the same code path are not affected. updateImage (advanced_statefulset_manager.go:271) returns early when either Image or ImageTag is empty, and replicas is protected by +kubebuilder:default=1 in the CRD.
• Choosing merge over replace has a semantic consequence worth settling first: once values are merged, a user can no longer remove a single key by omitting it. That is the same "user can not remove resource" concern raised in the fix(cache): preserve CacheRuntimeClass template resources when unset #6165 review, so the two are probably best decided together.