Files
helm-charts/gotenberg/values.yaml
T
jklein 37b76e353c gotenberg: seccompProfile RuntimeDefault in the pod context
Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod.

The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.

Gotenberg is the chart where a syscall filter was most likely to bite: it
drives headless Chromium and LibreOffice, and browser sandboxes are the
classic casualty of a restrictive seccomp profile. Verified in k3d that
both engines still work under the filter - Chromium HTML->PDF and
LibreOffice document->PDF both return real, non-empty PDFs, and the
kernel reports Seccomp: 2 (filter mode) inside the container.

Major bump: runtime behavior changes.

Refs #84
2026-08-23 23:08:37 +02:00

95 lines
4.0 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
# RuntimeDefault applies the container runtime's default seccomp filter,
# which blocks the syscalls a normal workload never makes. It sits in the
# pod context on purpose: from here it covers every container in the pod
# including init containers, while a container-level seccompProfile would
# have to be repeated for each one (and silently missed on the next one
# added). A container that genuinely needs a different filter can still
# override it under securityContext.container, which wins over this value.
#
# Verified against both conversion engines, because a browser sandbox is
# the classic case where a syscall filter bites: Chromium HTML->PDF and
# LibreOffice document->PDF both still return real PDFs under the filter,
# and /health reports chromium and libreoffice as "up".
seccompProfile:
type: RuntimeDefault
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