[helm] First-class existingSecret form for the readiness probe credential

[morazow]

Search before asking

• I searched in the issues and found nothing similar.

Description

tablet.readinessProbe.healthCheckAuth takes the probe credential as a literal, which the chart inlines into the StatefulSet's exec command. Keeping it out of the manifest is possible today only through the generic top-level secrets.env list, which is documented (#4329) but indirect: the credential lives far from the probe settings it belongs to, and the connection between the two is a naming convention on READINESS_HEALTH_CHECK_AUTH rather than something the values schema expresses.

The chart already has an existingSecret {name, key} idiom for exactly this, used three times in security.*:

• security.internal.sasl.plain.existingSecret
• security.zookeeper.sasl.plain.existingSecret
• security.client.sasl.plain.users[].existingSecret

Proposal

Accept the same shape on the probe credential:

tablet:
  readinessProbe:
    healthCheckAuth:
      existingSecret:
        name: fluss-readiness-probe-auth
        key: auth

rendering READINESS_HEALTH_CHECK_AUTH through secretKeyRef on the container instead of exporting a literal in the probe command. readiness-check.sh already reads that variable from the environment, so neither the script nor ClusterHealthReadinessCheck changes.

The value should be component-neutral rather than tablet-specific: #4115 gives the coordinator a health-based readiness probe that needs the same credential.

Accepting both a string and a map on one key needs a decision on backward compatibility for the existing literal form.

Overlaps #3926: if the probe derives its client auth from server.yaml, both the literal and the existingSecret form become unnecessary.

Willingness to contribute

• I'm willing to submit a PR!