fix(fluentd): propagate dnsPolicy to the configcheck pod - #2285

Description

newCheckPod copies dnsConfig from the Fluentd spec into the configcheck pod, but not dnsPolicy:

InitContainers:     initContainer,
Containers:         container,
DNSConfig:          fluentdSpec.DNSConfig,   // dnsPolicy is missing

The aggregator StatefulSet, a few files over in statefulset.go, sets both:

DNSPolicy: r.fluentdSpec.DNSPolicy,
DNSConfig: r.fluentdSpec.DNSConfig,

So the configcheck pod always ran with the API server default of ClusterFirst, while the aggregator it is meant to validate ran with whatever policy the user configured.

These two fields are not independent. With dnsPolicy: None a pod resolves only through dnsConfig; with ClusterFirst the dnsConfig is merged on top of cluster DNS. A configcheck pod that resolves names differently from the aggregator can pass or fail for reasons the aggregator will not reproduce, which is the opposite of what the check is for. The same applies to Default and ClusterFirstWithHostNet.

The fix is one line: copy dnsPolicy alongside dnsConfig.

Deliberately left alone, to keep this narrow — happy to fold either in if you would rather:

• topologySpreadConstraints is also not propagated, but that looks intentional. The function already strips podAntiAffinity with the comment "pod anti-affinity has been disabled to avoid blocking configcheck pods accidentally", and a DoNotSchedule spread constraint would block a configcheck pod in exactly the same way.
• terminationGracePeriodSeconds is not propagated either, but configcheck pods are restartPolicy: Never and short-lived, so it has no practical effect.

Link to the issue in case of a bug fix.

Refs #2228

That issue reports the configcheck pod missing parts of the configured pod spec. It names podSecurityContext specifically, and I should be upfront that podSecurityContext is not the problem on current master — newCheckPod does set SecurityContext: fluentdSpec.Security.PodSecurityContext, and I verified it lands on the pod. The report was filed against 6.2.2. dnsPolicy is a real instance of the same class of gap, so this PR fixes that one rather than closing the issue. I have left a note there with the details.

Testing details

1. Manual - verified on a kind cluster (v1.33.1), A/B against the released operator. Logging with spec.fluentd.dnsPolicy: None plus a custom dnsConfig:

   	aggregator StatefulSet	configcheck pod
   released 6.7.0	dnsPolicy: None	dnsPolicy: ClusterFirst
   this PR	dnsPolicy: None	dnsPolicy: None

   dnsConfig was identical in all four cases, which is what makes the mismatch matter. The Logging resource was deleted and recreated between the two runs so the configcheck result was not served from status.configCheckResults — I confirmed the "after" pod had a new UID and a creationTimestamp later than the operator rollout. The configcheck still completed (status.configCheckResults: {"893225a7": true}) and the aggregator came up, so propagating the policy does not break the check.

2. Unit tests - added pkg/resources/fluentd/appconfigmap_test.go. TestNewCheckPodDNSSettings covers unset, None with a dnsConfig, ClusterFirstWithHostNet and Default; TestNewCheckPodDNSSettingsMatchStatefulSet asserts the configcheck pod and the aggregator pod template agree, so the two cannot drift apart again.

   As a negative control I reverted the one-line fix and confirmed the new tests fail with expected: "None", actual: "". The Unset case passes either way by design — it is the boundary case that pins the no-change-for-existing-users behaviour.

3. go test ./pkg/resources/..., make lint (0 issues in both modules) and make generate all clean; make generate produces no diff beyond the two files in this PR.

Any backward incompatible change? If so, please explain.

No. dnsPolicy is not defaulted anywhere in the API, so an installation that does not set spec.fluentd.dnsPolicy leaves the field empty and the API server continues to apply ClusterFirst to the configcheck pod exactly as before. Only installations that explicitly set a policy see a change, and for them the new behaviour is the one they asked for.