Update minecraft-router to mc-router 1.46.4

Chart 1.0.0+up1.25.1 -> 1.0.1+up1.46.4 (patch: plain app-version update,
no values-schema and no chart-side behavior change). appVersion is the
image tag; itzg/mc-router publishes Docker tags without the "v" prefix
that the git tags carry since 1.35.0, so "1.46.4" is correct.

Verified against the upstream sources at v1.46.4 rather than the release
titles alone:

- --api-binding and --port are unchanged, so the chart's args still
  apply.
- The ROUTES_CONFIG env var and the routes config schema
  ({"default-server": ..., "mappings": {addr: "host:port"}}) are
  byte-for-byte identical to 1.25.1. Confirmed in a cluster: both
  mappings, including a per-mapping port override, are loaded.
- There is still no /health endpoint, so the probes keep using
  GET /routes. The "Accept: application/json" matcher that made the
  header mandatory in 1.25.1 was dropped in 1.32.2; the header is kept
  because it is harmless and correct.
- The image moved from scratch to cgr.dev/chainguard/static in 1.46.0
  and now declares USER 65532. The chart keeps pinning uid/gid 10000, so
  the runtime identity does not change.

Only the values comments that the update made inaccurate are touched; no
value, default or template changes. The comments now also record that
every unmodelled mc-router flag is reachable through server.env, which
is why the new 1.26-1.46 options need no new chart values.
This commit is contained in:
jklein committed 2026-08-23 15:51:48 +02:00
1 parent d01125cb7f
commit a7a966de0e
2 files changed
+31 -14

No files matched your search

+2 -2
View File
@@ -5,8 +5,8 @@ icon: https://avatars.githubusercontent.com/u/988985
type: application type: application
version: 1.0.0+up1.25.1 version: 1.0.1+up1.46.4
appVersion: "1.25.1" appVersion: "1.46.4"
maintainers: maintainers:
- name: jklein - name: jklein
+29 -12
View File
@@ -44,11 +44,18 @@ server:
cpu: 100m cpu: 100m
memory: 50Mi memory: 50Mi
ephemeral-storage: 50Mi ephemeral-storage: 50Mi
# The probes query the mc-router API. GET /routes answers with the live # The probes query the mc-router API. Even in 1.46.4 there is still no
# routing table, but only with the "Accept: application/json" header - the # /health or /healthz endpoint - the API server serves GET/POST /routes,
# API router matches on it and answers 404 without it. The API server is # POST /defaultRoute, DELETE /routes/{addr}, /vars and /metrics and nothing
# started after the routes config has been read and the Minecraft listener is # else - so GET /routes stays the health signal. It answers with the live
# up, so a 200 here means the router is actually serving clients. # 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: livenessProbe:
httpGet: httpGet:
path: /routes path: /routes
@@ -85,9 +92,12 @@ server:
securityContext: securityContext:
pod: pod:
runAsNonRoot: true runAsNonRoot: true
# The itzg/mc-router image is built FROM scratch and declares no user, so # Up to 1.45.x the itzg/mc-router image was built FROM scratch and
# it would run as root by default. The statically linked binary needs no # declared no user, so it would have run as root. Since 1.46.0 it is
# particular uid/gid, so the chart pins an unprivileged one. # 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 runAsUser: 10000
runAsGroup: 10000 runAsGroup: 10000
# Keeps the mounted routing-config ConfigMap readable for that gid. # Keeps the mounted routing-config ConfigMap readable for that gid.
@@ -95,8 +105,9 @@ server:
fsGroupChangePolicy: Always fsGroupChangePolicy: Always
container: container:
allowPrivilegeEscalation: false allowPrivilegeEscalation: false
# No deviation needed: the scratch image writes nothing, and the only # No deviation needed: the image ships nothing but the static binary and
# mount is the read-only routing config. # a CA bundle, mc-router writes nothing, and the only mount is the
# read-only routing config.
readOnlyRootFilesystem: true readOnlyRootFilesystem: true
runAsNonRoot: true runAsNonRoot: true
capabilities: capabilities:
@@ -104,8 +115,14 @@ server:
- ALL - ALL
add: [] add: []
# Extra environment variables for the router container, appended to the ones # Extra environment variables for the router container, appended to the ones
# the chart always sets (ROUTES_CONFIG). Values are rendered through tpl and # the chart always sets (ROUTES_CONFIG). This is also how every mc-router
# support the value, secretKeyRef and configMapKeyRef forms: # 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 # - name: SOME_ENV
# value: "{{ .Release.Name }}" # value: "{{ .Release.Name }}"
# - name: FROM_SECRET # - name: FROM_SECRET