[BUG]CacheRuntime: runtime-level `imagePullSecrets` and `podMetadata` never reach the component pods

[btxu-db]

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

• Kubernetes v1.30.0 (kind v0.23.0)
• Fluid CacheRuntime controller v1.1.0, source at 77a3b320
• Runtime: CacheRuntime

Describe the bug

CacheRuntimeSpec has two runtime-level fields whose doc comments say they apply to every component:

// api/v1alpha1/cacheruntime_types.go:160
// PodMetadata contains labels and annotations that will be propagated to all component pods.
PodMetadata PodMetadata `json:"podMetadata,omitempty"`

// api/v1alpha1/cacheruntime_types.go:164
// ImagePullSecrets is an optional list of references to secrets in the same namespace
// to use for pulling any of the images used by this PodSpec.
ImagePullSecrets []corev1.LocalObjectReference `json:"imagePullSecrets,omitempty" ...`

They are in the CRD and the API server takes them, but as far as I can find nothing reads them. transformComponentPodTemplate (pkg/ddc/cache/engine/transform_common.go:64) builds the pod template from the CacheRuntimeClass template and the component-level spec. The runtime-level layer never enters:

$ grep -rn "Spec\.PodMetadata\|Spec\.ImagePullSecrets" pkg/ddc/cache/ --include="*.go" | grep -v _test
pkg/ddc/cache/engine/transform_common.go:69:  if runtimeCompSpec.PodMetadata.Labels != nil {
pkg/ddc/cache/engine/transform_common.go:72:  if runtimeCompSpec.PodMetadata.Annotations != nil {

Both hits are runtimeCompSpec, the component-level RuntimeComponentCommonSpec. I could not find any reader of runtime.Spec.PodMetadata or runtime.Spec.ImagePullSecrets elsewhere in the repo either.

imagePullSecrets is the one likely to hurt. The secret does not land on the pod, so the kubelet has nothing to authenticate with, and a component image behind a private registry should fail to pull. Nothing errors and no event is emitted on the CacheRuntime, and a pull failure names the image and the registry rather than the field that went missing, so the natural things to check are the secret, the credentials and the image reference. The runtime spec is not an obvious suspect.

I should be clear about what I did and did not verify: the reproduction below shows the field being dropped, but I did not confirm the pull failure end to end. The cluster I tested on has no registry egress at all, so pulls there fail on the network before credentials come into it.

What you expect to happen:

spec.imagePullSecrets and spec.podMetadata reach all component pods, the way their doc comments say. podMetadata exists at both the runtime and the component level, so those two need a defined precedence.

How to reproduce it

Set both runtime-level fields, and a component-level podMetadata as a control:

apiVersion: data.fluid.io/v1alpha1
kind: CacheRuntime
metadata:
  name: ipstest
  namespace: bugtest
spec:
  runtimeClassName: bugtest-class
  # ---- runtime level ----
  imagePullSecrets:
    - name: my-registry-secret
  podMetadata:
    labels:
      from-runtime-level: "yes"
    annotations:
      owner: btxu
  master:
    replicas: 1
  worker:
    replicas: 1
    # ---- component level, as a control ----
    podMetadata:
      labels:
        from-component-level: "yes"
    tieredStore:
      levels:
        - emptyDir:
            quota: 1Gi
          high: '0.8'
          low: '0.5'

The AdvancedStatefulSet that comes out:

imagePullSecrets            = []
labels.from-runtime-level   = []     <- spec.podMetadata
labels.from-component-level = [yes]  <- spec.worker.podMetadata  (control)
annotations.owner           = []     <- spec.podMetadata

Same on the pod:

$ kubectl -n bugtest get pod ipstest-worker-0 -o jsonpath='{.spec.imagePullSecrets}'
                       # empty

$ kubectl -n bugtest get pod ipstest-worker-0 -o jsonpath='{.metadata.labels}'
{... "from-component-level":"yes" ...}   # no from-runtime-level, no owner annotation

The control is the point: component-level podMetadata lands, which rules out template rendering and the manifest itself. Only the runtime-level layer goes missing. No Warning event on the CacheRuntime, and nothing in the controller log about either field.

Additional Information

spec.options and spec.volumes are the runtime-level fields that do work. options composes all three layers, at pkg/ddc/cache/engine/cm.go:146:

Options: utils.UnionMapsWithOverride(
    utils.UnionMapsWithOverride(runtimeClass.Topology.Master.Options, runtime.Spec.Options),
    runtime.Spec.Master.Options),

runtimeClass template < runtime level < component level. podMetadata has the same three-layer shape and wants the same treatment; right now the middle argument is simply missing from transformComponentPodTemplate.

imagePullSecrets looks simpler than that. It has no component-level counterpart, so there is no precedence to settle, and the runtime-level list should be able to go straight into podTemplate.Spec.ImagePullSecrets. If that holds, it could be fixed without waiting on whatever is decided for podMetadata.

One caveat for whoever picks this up. Both fields would be read on the transform path, which runs at setup, so propagating them would not by itself make them updatable on a live CacheRuntime: syncRuntimeSpec currently handles only runtimeVersion, resources and replicas.

This has the same shape as several other CacheRuntime bugs I have filed: spec accepted, nothing on the pod, no error. The meta-issue collects them and what I think they have in common.