Merge pull request #70 from jk-cluster/feat/minecraft-router-app-1.46.4

Minecraft-router: update to mc-router 1.46.4 (Fleet migration stage 3)
This commit is contained in:
jklein authored and GitHub committed 2026-08-23 13:56:05 +00:00
commit d1f2ef0027
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