Search before asking
Description
Problem
The Helm chart's JAAS init container has no resources block.
It is defined in helm/templates/_jaas.tpl (fluss.security.jaas.initContainer, the render-jaas-config container) and rendered into both StatefulSets (sts-coordinator.yaml, sts-tablet.yaml) whenever fluss.security.jaas.required evaluates true, i.e. on every SASL-enabled install.
Kubernetes computes the pod Quality of Service (QoS) class over init containers as well as regular containers. A container with no requests and limits makes the whole pod Burstable, even when every main container sets requests == limits.
So a SASL enabled Fluss cluster cannot reach Guaranteed QoS, whatever the user puts in values.yaml resources. The Guaranteed matters for benchmark and production placement: it puts the server pods last in the eviction order under node pressure.
There is no workaround through values: coordinator.initContainers / tablet.initContainers only append extra containers, they cannot modify the chart-injected one.
Proposal
Give the container requests == limits.
Two options:
-
A fixed small default (for example 100m CPU / 128Mi memory). The container only runs envsubst plus two file copies, so a small constant is safe. Downside: it contradicts the chart's stated policy of not defaultingresources.
-
A values knob, for example security.jaasInitContainer.resources, empty by default, applied to the container when set. This matches the existing resources: {} philosophy and is fully backwards compatible.
Either way the pod's effective request does not grow for scheduling: init containers run before the main containers, and the scheduler uses max(any init container, sum of main containers), so any value at or below the main container's size changes nothing except the QoS class.
Willingness to contribute
Search before asking
Description
Problem
The Helm chart's JAAS init container has no
resourcesblock.It is defined in
helm/templates/_jaas.tpl(fluss.security.jaas.initContainer, therender-jaas-configcontainer) and rendered into both StatefulSets (sts-coordinator.yaml,sts-tablet.yaml) wheneverfluss.security.jaas.requiredevaluates true, i.e. on every SASL-enabled install.Kubernetes computes the pod Quality of Service (QoS) class over init containers as well as regular containers. A container with no requests and limits makes the whole pod
Burstable, even when every main container setsrequests == limits.So a SASL enabled Fluss cluster cannot reach
GuaranteedQoS, whatever the user puts invalues.yamlresources. TheGuaranteedmatters for benchmark and production placement: it puts the server pods last in the eviction order under node pressure.There is no workaround through values:
coordinator.initContainers/tablet.initContainersonly append extra containers, they cannot modify the chart-injected one.Proposal
Give the container
requests == limits.Two options:
A fixed small default (for example
100mCPU /128Mimemory). The container only runsenvsubstplus two file copies, so a small constant is safe. Downside: it contradicts the chart's stated policy of not defaultingresources.A values knob, for example
security.jaasInitContainer.resources, empty by default, applied to the container when set. This matches the existingresources: {}philosophy and is fully backwards compatible.Either way the pod's effective request does not grow for scheduling: init containers run before the main containers, and the scheduler uses
max(any init container, sum of main containers), so any value at or below the main container's size changes nothing except the QoS class.Willingness to contribute