jklein
e4b3c06674
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.
13 lines
244 B
YAML
13 lines
244 B
YAML
apiVersion: v2
|
|
name: minecraft-router
|
|
description: A Helm chart for deploying a itzg/mc-router
|
|
icon: https://avatars.githubusercontent.com/u/988985
|
|
|
|
type: application
|
|
|
|
version: 2.0.0+up1.46.4
|
|
appVersion: "1.46.4"
|
|
|
|
maintainers:
|
|
- name: jklein
|