No ingress gate: this chart has no Ingress at all (clients reach it via a
NodePort), and ingress.domain appears neither in its templates nor in its
values.
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, including the entries of the mappings list,
where domain and internalUrl are required.
2. Null-safety for hardening, probes and resources (#99). Two things a
rebuilt default probe must not lose, both verified:
- the API port is addressed by NAME ("api-port"), so the probe keeps
working when server.apiPort is overridden.
- mc-router still has no /health endpoint in 1.46.4, so GET /routes is
the health signal, and the "Accept: application/json" header belongs
to that request.
The pod context keeps pinning uid/gid 10000 even though the image
declares USER 65532 since 1.46.0, so the runtime identity does not
silently change with the base image.
mappings stays deliberately not null-safe: the chart fails loudly on a
missing or empty routing table, which is the loud class #99 excludes - a
router without routes is not operable and has no sensible default.
Rendering with normal values is byte-identical to 2.0.0.
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.
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.
Stage 2 of the Fleet migration for minecraft-router: bring the chart up to the
repo style guidelines. Chart 0.1.1+up1.25.1 -> 1.0.0+up1.25.1 (major: resource
renames, mappings becomes required, probes and security hardening change the
runtime behavior; appVersion unchanged).
- Resources renamed to {{ .Release.Name }}-{{ .Chart.Name }}-<kind>, templates
to <chart>.<kind>.yaml; the deployment label now matches its own selector.
- mappings is required and must not be empty (the old default rendered
"<nil>": "<nil>:25565"); every entry needs domain and internalUrl.
- Ports come from values: server.port (router listen port, also passed as
--port), server.backendPort (default backend port, overridable per mapping),
server.apiPort (--api-binding, used by the probes). Defaults stay 25565 /
25565 / 8080, server.outwardPort keeps its 25565 default and comment.
- _helpers.tpl added (resources/limitFactor and replicas/scaleDown helpers),
resources come from values, no CPU limit.
- replicas value plus the chart-global scaleDown flag.
- Additive env block rendered through tpl (value / secretKeyRef /
configMapKeyRef).
- Values-configurable securityContext.pod / .container with hardened defaults:
non-root uid/gid 10000, readOnlyRootFilesystem, no privilege escalation, all
capabilities dropped.
- Liveness, readiness and startup probes on the mc-router API: GET /routes with
an "Accept: application/json" header (the API router matches on that header
and answers 404 without it).
- icon added to Chart.yaml.
- CI fixture supplies mappings; README chart table entry updated.
Takes the existing mc-router chart over from cluster-config as-is so the
deployment can move to Fleet without any change to the rolled-out state.
Convention alignment follows in stage 2, the app update in stage 3.
The only deviation from "unchanged": Chart.yaml carried name:
minecraft-server (copy-paste from the sister chart). The publish job pushes
by the glob <directory>-*.tgz while helm package names the archive after the
Chart.yaml name, so without this correction the push finds no file.
Version 0.1.1+up1.25.1 - chart semver stays at 0.1.1, the +up suffix is repo
policy and does not affect rendering.
Also wires up CI: publish workflow, change-app-version choice list,
install-test values (CI-only node-port override, since 25565 is outside the
k3d default range) and the README chart table.
jklein