[cvas22]

What this PR does / why we need it:

Adds spec.ports to the Fluentd CRD, a list of ContainerPorts like the FluentBit and Collector CRDs already have. Each port is added to the fluentd container (StatefulSet and DaemonSet) and to the fluentd Service.

The operator only opens ports for the forward and http global inputs, because those are the only inputs whose port it knows. Any other input, such as a syslog source in a customPlugin, listens on a port that is neither exposed on the container nor reachable through the Service. #1610 asks for exactly this ("or the fluentd CRD allows to specify ports like the fluentbit CRD"):

spec:
  globalInputs:
    - customPlugin:
        config: |
          <source>
            @type syslog
            port 5140
            bind 0.0.0.0
            tag foo
          </source>
  ports:
    - name: syslog
      containerPort: 5140
      protocol: UDP

The Service port uses the same name, protocol and number as the container port, matching how the FluentBit Service handles spec.ports. When ports isn't set, nothing changes.

Which issue(s) this PR fixes:

Fixes #1610

Does this PR introduced a user-facing change?

The Fluentd CRD supports spec.ports to expose additional container ports, also added to the fluentd Service, for inputs such as customPlugin sources.

Notes

@cw-Guo suggested on the issue that managed plugins should get their ports derived automatically, and that still works as before. This PR covers the inputs the operator can't derive a port for, the same way FluentBit and Collector do.

I ran the generators (make generate manifests docs-update, in a golang:1.26 container) rather than editing generated files by hand. They updated the deepcopy, the Fluentd CRDs (config, both charts, manifests/setup/setup.yaml) and docs/fluentd.md.

Tested locally: go test ./pkg/operator/ ./apis/fluentd/... ./controllers/ passes, including the new TestFluentdAdditionalPorts, which checks the container port and the Service port. go vet and gofmt are clean. I haven't run it against a live cluster.

[joshuabaird]

Thanks for this, it looks good. It follows the same pattern as the Collector, and the generated files all line up. This branch currently conflicts with master, but only in the generated CRD files (the three fluentd.fluent.io_fluentds.yaml copies and manifests/setup/setup.yaml). Rebasing onto master and rerunning make generate manifests should fix it.

A few non-blocking things:

1. Port names. ContainerPort.name is optional, but a Service with more than one port needs every port named. If someone sets a forward input and adds an unnamed entry to spec.ports, creating the Service will fail. Could we either require name (a CEL rule on the field would work) or at least mention it in the field description?

2. Duplicate ports. If an entry in spec.ports uses the same port and protocol as the forward or http input, the pod is accepted but the Service is rejected. A short note in the docs would probably be enough here.

3. Test coverage. Could you add a case that combines a forward input with spec.ports? That would cover port ordering and the multi-port Service, which is where issue 1 shows up. A table-driven test would also make it easier to add cases later.

[cvas22]

Thanks for the review! Rebased onto master and regenerated with make generate manifests docs-update (693bb99), so the CRD conflicts are gone. On your points:

1. Port names: I went with the CEL rule. spec.ports now has self.all(p, has(p.name) && p.name != '') with the message "every port needs a name", so an unnamed entry is rejected when the Fluentd resource is applied, before the Service would fail.
2. Duplicate ports: the field description now says every port needs a name and that it shouldn't repeat the port and protocol of a forward or http input, which the Service already exposes. That ends up in the CRD and docs/fluentd.md.
3. Tests: TestFluentdAdditionalPorts is now table-driven, with only additional ports, a forward input plus spec.ports (checking container port order metrics → forward → syslog and both Service ports), and no additional ports.

I didn't run the tests locally this time and am relying on CI.

[joshuabaird]

Thanks for the quick turnaround, LGTM.