jklein
0c403b6100
The computed limits (limitFactor 3 x request = 1536Mi memory, 30Mi ephemeral storage) were too small for real documents: a 12 MB HTML already gets the container OOM-killed, and the caller sees no HTTP error at all, just a dropped connection and a rising RESTARTS counter. Rather than raise the requests and reserve conversion-sized capacity on the node around the clock, requests and limits are decoupled: the requests stay as they were, and both limits are now set explicitly. The chart already supported this - an explicit limit wins over the limitFactor computation. Measured in a throwaway k3d cluster with the official image (HTML via Chromium), building on the series in the issue: 18 MB HTML, 2Gi -> OOMKilled 18 MB HTML, 2560Mi -> OOMKilled 18 MB HTML, 3Gi -> HTTP 200 in ~22s, 21 MB PDF 12 MB HTML, 1536Mi -> OOMKilled (the old computed limit) 12 MB HTML, 2Gi -> HTTP 200 in ~13s Memory beyond 3Gi buys nothing: gotenberg's own request timeout is 30s and the chart passes no flags to change it, so a document needing more memory has already run out of time (a 25 MB HTML misses the 30s even at 4Gi). The ephemeral-storage limit is raised in the same change, because raising memory alone only moves the failure. With 3Gi memory and the old 30Mi limit, /tmp peaked at 40 MB on a single conversion and at ~125 MB over a short series, and the pod was evicted: Pod ephemeral local storage usage exceeds the total limit of containers 30Mi That failure is worse than the OOM-kill: the pod does not restart, it is replaced, and the old one is left behind as Evicted. The defaults in the effectiveResources helper are updated in lockstep with values.yaml, so an erased "resources:" block (#99) falls back to the new explicit limits instead of the old computed ones. NOTES.txt is pulled along. Its numbers came from effectiveResources already, but the text described a threshold that has moved and advice that no longer holds: raising the request no longer drags the limit with it now that the limits are explicit. The warning is kept but no longer claims memory is the first limit you hit - with these limits, the 30s timeout is. Major, because the runtime behaviour changes and the pod may occupy more memory during large conversions than it was allowed to before. Fixes #106
81 lines
3.2 KiB
YAML
81 lines
3.2 KiB
YAML
# Scale the whole chart down without uninstalling it: scaleDown: true renders
|
|
# every Deployment/StatefulSet with replicas: 0 (and suspends CronJobs) and
|
|
# takes precedence over any per-workload replicas value. PVCs, Secrets and
|
|
# Services stay in place; scaleDown: false brings the workloads back up.
|
|
scaleDown: false
|
|
|
|
gotenberg:
|
|
# Replica count for this workload; 0 is allowed and scales it down.
|
|
# The chart-global scaleDown flag takes precedence.
|
|
replicas: 1
|
|
# The official image runs as the dedicated gotenberg user (uid 1001). /tmp
|
|
# and /home/gotenberg are writable emptyDirs so Chromium/LibreOffice keep
|
|
# working with a read-only root filesystem.
|
|
securityContext:
|
|
pod:
|
|
runAsNonRoot: true
|
|
runAsUser: 1001
|
|
runAsGroup: 1001
|
|
container:
|
|
allowPrivilegeEscalation: false
|
|
readOnlyRootFilesystem: true
|
|
runAsNonRoot: true
|
|
capabilities:
|
|
drop:
|
|
- ALL
|
|
# Gotenberg exposes a documented health endpoint at /health.
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /health
|
|
port: gotenberg-port
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /health
|
|
port: gotenberg-port
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
# The startup probe gates liveness/readiness. Startup budget = 5s * 30 = 150s.
|
|
startupProbe:
|
|
httpGet:
|
|
path: /health
|
|
port: gotenberg-port
|
|
periodSeconds: 5
|
|
timeoutSeconds: 5
|
|
failureThreshold: 30
|
|
# Extra environment variables. Values are rendered through tpl; value,
|
|
# secretKeyRef and configMapKeyRef forms are supported.
|
|
env: []
|
|
resources:
|
|
# Limits are optional: memory and ephemeral-storage limits default to
|
|
# limitFactor x the request, an explicitly set limit always wins, and a
|
|
# CPU limit is only set when configured explicitly under "limits".
|
|
limitFactor: 3
|
|
# The requests stay small on purpose: gotenberg idles at a few dozen MB,
|
|
# so reserving conversion-sized capacity on the node would waste it
|
|
# around the clock. Conversions are short bursts, and the limits below
|
|
# cover the burst instead (issue #106).
|
|
requests:
|
|
cpu: 0.1
|
|
memory: 512Mi
|
|
ephemeralStorage: 10Mi
|
|
# Set explicitly rather than left to limitFactor x request, because the
|
|
# computed limits (1536Mi / 30Mi) were too small for real documents.
|
|
# Measured with the official image, HTML converted via Chromium:
|
|
# - 18 MB HTML: OOMKilled at 2Gi and 2560Mi, converts at 3Gi in ~22s
|
|
# (21 MB PDF). 12 MB HTML already OOM-kills at the old 1536Mi.
|
|
# - Raising memory alone only moves the failure: with 3Gi memory and
|
|
# the old 30Mi ephemeral limit, /tmp peaked at 40 MB on a single
|
|
# conversion and at ~125 MB over a short series, and the pod was
|
|
# evicted ("ephemeral local storage usage exceeds the total limit of
|
|
# containers 30Mi") instead of OOM-killed.
|
|
# Memory beyond 3Gi buys nothing: gotenberg's own request timeout is 30s
|
|
# and the chart passes no flags to change it, so a document that needs
|
|
# more memory than this has already run out of time.
|
|
limits:
|
|
memory: 3Gi
|
|
ephemeralStorage: 256Mi
|