jklein
1e28d1a992
Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render. Port half only: this chart offers no networkPolicy.probeSources - its probes put no packet on the network - so there is no redirected probe to allow and an ipBlock for one would match nothing while making the rule look like it did something. ci/run-networkpolicy-test.sh ties that exemption to the absence of probeSources, not to a chart name.
224 lines
10 KiB
YAML
224 lines
10 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
|
|
|
|
# Erasing this block (dev: with no sub-keys, or --set dev=null) falls back to
|
|
# the defaults below instead of aborting the render — same for game, server and
|
|
# the hardening/probe/resources blocks (Gitea issue #16, issue #99).
|
|
dev:
|
|
debug: false
|
|
|
|
game:
|
|
experimental: false
|
|
maxPlayers: 4
|
|
# Seasonal (holiday) events. The image only knows the negative switch
|
|
# DISABLESEASONALEVENTS, so the chart NEGATES this value on the way in:
|
|
# enableSeasonalEvents: true renders DISABLESEASONALEVENTS="false" (events
|
|
# run), false renders "true" (events off). Only true/false are accepted, in
|
|
# boolean or string form; anything else aborts the render instead of being
|
|
# read as one of the two.
|
|
#
|
|
# The default is false on purpose, and it is not a preference: it reproduces
|
|
# what this chart has ALWAYS rendered. Up to 6.1.0 the key was called
|
|
# game.seasonalEvents and was passed through UNCHANGED, so its default true
|
|
# wrote DISABLESEASONALEVENTS=true — the events were off in every install,
|
|
# while values.schema.json claimed "true means events are enabled" (#215).
|
|
# Keeping the rendered result identical is what makes this rename loud
|
|
# instead of silent: nobody's server changes behaviour by upgrading, and the
|
|
# old key is now rejected by the schema, so anyone who set it has to decide
|
|
# again. Set enableSeasonalEvents: true to actually switch the events on.
|
|
enableSeasonalEvents: false
|
|
|
|
# Erasing this block, or any single key in it, falls back to the defaults below
|
|
# (Gitea issue #16) — with the documented exception of storage, see there.
|
|
# Before 7.0.1 "server: null" aborted the render, and a single erased key was
|
|
# the quieter half: a nulled gamePort rendered an empty port number into the
|
|
# Service and the StatefulSet, rejected by the API server at apply time and by
|
|
# nothing before it.
|
|
server:
|
|
# Replica count for this workload; 0 is allowed and scales it down.
|
|
# The chart-global scaleDown flag takes precedence.
|
|
replicas: 1
|
|
gamePort: 30777
|
|
messagingPort: 30888
|
|
# The size of the data PVC, and the ONE key of this block that is NOT
|
|
# null-safe — deliberately, not by oversight. An erased storage (including
|
|
# "server: null") renders a PVC without a size, which fails at apply time
|
|
# instead of quietly sizing the volume from the chart. Whether that is still
|
|
# the right trade is negotiated in Gitea issue #39, not here.
|
|
storage: 20Gi
|
|
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".
|
|
# The game server holds a large world in memory, so the default factor
|
|
# stays at 2 to keep the limit at the previously published 8Gi.
|
|
limitFactor: 2
|
|
requests:
|
|
memory: "4Gi"
|
|
cpu: "1"
|
|
ephemeral-storage: "5Gi"
|
|
|
|
# Extra environment variables for the server container, appended to the ones
|
|
# the chart always sets (DEBUG, MAXPLAYERS, PGID, PUID, SKIPUPDATE, STEAMBETA,
|
|
# DISABLESEASONALEVENTS, SERVERGAMEPORT, SERVERMESSAGINGPORT). Values are
|
|
# rendered through tpl and support the value, secretKeyRef and configMapKeyRef
|
|
# forms:
|
|
# - name: SOME_ENV
|
|
# value: "{{ .Release.Name }}"
|
|
# - name: FROM_SECRET
|
|
# valueFrom:
|
|
# secretKeyRef:
|
|
# name: "some-secret"
|
|
# key: "someKey"
|
|
# - name: FROM_CONFIGMAP
|
|
# valueFrom:
|
|
# configMapKeyRef:
|
|
# name: "some-configmap"
|
|
# key: "someKey"
|
|
env: []
|
|
|
|
# The image's healthcheck script queries the server's HTTPS API on the game
|
|
# port (SERVERGAMEPORT), so liveness/startup keep working under port overrides.
|
|
livenessProbe:
|
|
exec:
|
|
command:
|
|
- "/bin/sh"
|
|
- "-c"
|
|
- "/home/steam/healthcheck.sh"
|
|
failureThreshold: 4
|
|
successThreshold: 1
|
|
periodSeconds: 30
|
|
timeoutSeconds: 10
|
|
readinessProbe:
|
|
tcpSocket:
|
|
port: api
|
|
periodSeconds: 10
|
|
timeoutSeconds: 5
|
|
failureThreshold: 3
|
|
# The startup probe gates liveness/readiness. The server downloads / updates
|
|
# the game files via Steam on startup, which can take a long time:
|
|
# budget 30s * 40 = 20 minutes.
|
|
startupProbe:
|
|
exec:
|
|
command:
|
|
- "/bin/sh"
|
|
- "-c"
|
|
- "/home/steam/healthcheck.sh"
|
|
periodSeconds: 30
|
|
timeoutSeconds: 10
|
|
failureThreshold: 40
|
|
|
|
securityContext:
|
|
pod:
|
|
runAsNonRoot: true
|
|
# The wolveix/satisfactory-server image supports rootless operation only
|
|
# as its built-in "steam" user (uid/gid 1000) - the entrypoint rejects any
|
|
# other non-root uid/gid. The PUID/PGID env vars only apply to the root
|
|
# entrypoint path and are ignored when running non-root.
|
|
runAsUser: 1000
|
|
runAsGroup: 1000
|
|
# fsGroup keeps the data volume writable for the steam user.
|
|
# OnRootMismatch (instead of Always) skips the recursive chown/chmod of
|
|
# the multi-GB game files on every pod start; volumes provisioned by chart
|
|
# versions < 4.0.0 were already chowned to 1000:1000 by the image's root
|
|
# entrypoint.
|
|
fsGroup: 1000
|
|
fsGroupChangePolicy: OnRootMismatch
|
|
# 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.
|
|
seccompProfile:
|
|
type: RuntimeDefault
|
|
container:
|
|
allowPrivilegeEscalation: false
|
|
# Works because the chart mounts emptyDirs at /tmp and the steam user's
|
|
# ~/.steam, ~/.config and ~/.local (steamcmd bootstraps itself into
|
|
# ~/.local/share/Steam on start); all other writes go to the PVC at
|
|
# /config.
|
|
readOnlyRootFilesystem: true
|
|
runAsNonRoot: true
|
|
capabilities:
|
|
drop:
|
|
- ALL
|
|
add: []
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# NetworkPolicy (Gitea #5). On by default. The reference implementation with
|
|
# the full reasoning is template-chart; the convention is in README, "Chart
|
|
# style guidelines", and the operator's view on this chart's wiki page.
|
|
# ---------------------------------------------------------------------------
|
|
networkPolicy:
|
|
# enabled IS THE ONLY VALUE HERE, and that is deliberate. The single inbound
|
|
# rule is open to any source and there is no egress section at all (see
|
|
# below), so allowedNamespaces and probeSources would both reach no rule -
|
|
# and a value that silently does nothing is worse than one that is absent,
|
|
# because it reads as a control.
|
|
#
|
|
# WHAT THIS POLICY ALLOWS: inbound the three declared game ports only, open
|
|
# to any source - they are NodePorts and the clients are players on the
|
|
# internet. THERE IS NO EGRESS SECTION, and that is the decision in this
|
|
# chart rather than an omission.
|
|
#
|
|
# TWO REASONS, AND THEY COMPOUND. First, the outbound requirement is Steam's
|
|
# content delivery, which is not a pinnable port list: SteamCMD uses TCP 80,
|
|
# 443 and 27015-27050, the master servers UDP 27000-27100 and 4380, Valve
|
|
# changes the set, and the server re-downloads on every update. Second, and
|
|
# decisively: satisfactory is the ONE chart here with no install-test at all
|
|
# (ci/excluded-charts.txt - the image is multiple GB and the first start
|
|
# pulls over 10GB). An egress cap here would be the only one in the sweep
|
|
# with no empirical check behind it, on the chart whose correct port set is
|
|
# least knowable, and a review cannot verify a Steam port range.
|
|
#
|
|
# So policyTypes names Ingress only, for the same reason valkey does: a rule
|
|
# that has to be widened until it permits everything makes the object look
|
|
# stricter than it is. A deployment that wants an egress cap should write one
|
|
# at release level, where Steam's behaviour can be observed.
|
|
#
|
|
# The game port is allowed as BOTH TCP and UDP, because the server binds it
|
|
# as both - a TCP-only rule would be accepted and would drop half the game
|
|
# traffic.
|
|
enabled: true
|
|
|
|
# The policy's INBOUND side. Mind the three names that overlap as substrings,
|
|
# because a search for "ingress" matches all of them and they are different
|
|
# things:
|
|
#
|
|
# ingress (top level) the Ingress OBJECT this chart
|
|
# renders - host, TLS, className
|
|
# networkPolicy.ingress this block: what the policy lets IN
|
|
# networkPolicy.ingressController the SOURCE SELECTOR for the ingress
|
|
# controller's pods. A SIBLING of this block
|
|
# and NO PART OF IT, despite the name.
|
|
ingress:
|
|
# Opens the pod for Istio's ambient mesh (Gitea #143). OFF by default and
|
|
# additive: while it is false this chart renders byte for byte as it did
|
|
# before the value existed.
|
|
#
|
|
# It renders 15008/TCP inbound - ztunnel's HBONE tunnel. Every inbound mesh
|
|
# connection arrives on it, and ambient "does not and will never bypass
|
|
# Kubernetes NetworkPolicy enforcement", so without this port a pod whose
|
|
# namespace has joined the mesh is unreachable.
|
|
#
|
|
# ONE HALF SHORTER THAN ELSEWHERE, deliberately. In other charts this switch
|
|
# also adds 169.254.7.127/32 as a probe source, because inside the mesh the
|
|
# kubelet's probes are redirected away from the worker node's address. This
|
|
# chart has no networkPolicy.probeSources at all, so the rule carrying the
|
|
# probe port is never restricted by source - and an unrestricted rule needs
|
|
# no probe address. An ipBlock for one would match nothing while making the
|
|
# rule look like it did something, which is the kind of strict-looking empty
|
|
# rule ci/run-networkpolicy-test.sh exists to catch; that script ties the
|
|
# exemption to the absence of probeSources rather than to a chart name.
|
|
#
|
|
# NOT PROVEN: that 15008 alone is enough comes from Istio's documentation;
|
|
# measured on this cluster is only which listeners ztunnel opens, and no
|
|
# namespace carries istio.io/dataplane-mode yet.
|
|
ambientMesh: false
|
|
|