Files
helm-charts/minecraft-router/values.yaml
T
jklein e4b3c06674 Restart the router when its routing config changes (2.0.0+up1.46.4)
The deployment now carries a checksum/config annotation over the rendered
ConfigMap, so a changed routing table produces a new pod template and a
controlled rollout.

Without it a mapping change was inert but looked successful: the file is
mounted with subPath (kubelet never refreshes those in a running container)
and mc-router reads ROUTES_CONFIG only at startup. That combination caused the
minecraft-server stage-3 outage - the ConfigMap pointed at the renamed
services, the running router kept proxying to the old ones, and the pod stayed
Ready throughout.

Major bump: runtime behaviour changes. A mapping change now costs a router
restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which
clients cannot connect. That restart is what makes the change take effect at
all.

Refs #82.
2026-08-23 18:52:19 +02:00

144 lines
6.1 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
# Routing table of the router: which client-facing hostname is proxied to which
# backend Minecraft server. Required and must not be empty - a router without
# routes is not operable, and there is no sensible default.
# Every entry needs "domain" and "internalUrl"; the optional "port" overrides
# server.backendPort for that single backend:
# mappings:
# - domain: mc.example.com
# internalUrl: survival-service.minecraft.svc.cluster.local
# - domain: creative.example.com
# internalUrl: creative-service.minecraft.svc.cluster.local
# port: 25566
# Since chart 2.0.0 a change here rolls the router pod: the deployment carries
# a checksum/config annotation over the rendered ConfigMap. That restart is
# required for the change to take effect at all - the config is mounted with
# subPath and mc-router only reads it at startup - and costs a few seconds of
# proxy downtime, during which clients cannot connect.
mappings: null
server:
# Replica count for this workload; 0 is allowed and scales it down.
# The chart-global scaleDown flag takes precedence.
replicas: 1
# nodePort of the router Service. 25565 is the Minecraft default port and is
# deliberately outside the Kubernetes default node-port range (30000-32767) -
# the cluster runs an extended --service-node-port-range. Do NOT "fix" this
# into the default range: the Minecraft clients connect to this exact port.
outwardPort: 25565
# Port the router listens on for Minecraft client connections (mc-router
# --port); used as containerPort and as the Service's cluster-internal port.
port: 25565
# Default port of the backend Minecraft servers, used for every mapping that
# does not carry its own "port".
backendPort: 25565
# Port of the mc-router HTTP API (--api-binding). Not exposed by the Service;
# only the probes talk to it.
apiPort: 8080
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
requests:
cpu: 100m
memory: 50Mi
ephemeral-storage: 50Mi
# The probes query the mc-router API. Even in 1.46.4 there is still no
# /health or /healthz endpoint - the API server serves GET/POST /routes,
# POST /defaultRoute, DELETE /routes/{addr}, /vars and /metrics and nothing
# else - so GET /routes stays the health signal. It answers with the live
# routing table, and the API server is only started after the routes config
# has been read and the Minecraft listener is up, so a 200 here means the
# router is actually serving clients.
# The "Accept: application/json" header was mandatory in 1.25.1 (the API
# router matched on it and answered 404 without it); mc-router 1.32.2 dropped
# that matcher, so from there on the header is optional. It is kept because
# it is the correct request for a JSON endpoint and the response is identical
# with and without it - removing it would be churn without any gain.
livenessProbe:
httpGet:
path: /routes
port: api-port
httpHeaders:
- name: Accept
value: application/json
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /routes
port: api-port
httpHeaders:
- name: Accept
value: application/json
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# The startup probe gates liveness/readiness. mc-router is a single static Go
# binary that reads one config file and serves the API in well under a
# second; budget = periodSeconds * failureThreshold = 30s.
startupProbe:
httpGet:
path: /routes
port: api-port
httpHeaders:
- name: Accept
value: application/json
periodSeconds: 2
timeoutSeconds: 5
failureThreshold: 15
securityContext:
pod:
runAsNonRoot: true
# Up to 1.45.x the itzg/mc-router image was built FROM scratch and
# declared no user, so it would have run as root. Since 1.46.0 it is
# based on cgr.dev/chainguard/static and declares USER 65532. The chart
# keeps pinning its own unprivileged uid/gid regardless, so the runtime
# identity does not silently change with the base image; the statically
# linked binary needs no particular uid/gid.
runAsUser: 10000
runAsGroup: 10000
# Keeps the mounted routing-config ConfigMap readable for that gid.
fsGroup: 10000
fsGroupChangePolicy: Always
container:
allowPrivilegeEscalation: false
# No deviation needed: the image ships nothing but the static binary and
# a CA bundle, mc-router writes nothing, and the only mount is the
# read-only routing config.
readOnlyRootFilesystem: true
runAsNonRoot: true
capabilities:
drop:
- ALL
add: []
# Extra environment variables for the router container, appended to the ones
# the chart always sets (ROUTES_CONFIG). This is also how every mc-router
# option that the chart does not model explicitly is set: mc-router parses
# its flags with go-flagsfiller, so every "--some-flag" is equally settable
# as "SOME_FLAG" (that is exactly how ROUTES_CONFIG maps to --routes-config).
# Useful examples in 1.46.4: LOG_LEVEL (debug/info/warn/error),
# BACKEND_DIAL_TIMEOUT, CONNECTION_RATE_LIMIT.
# 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: []