feat(grounds-geyser)!: drop the hostPort - #167
Merged
Merged
Conversation
A Bedrock client still has to reach UDP 19132 on a node address — that has not changed, and 19132 sits outside the NodePort range so an ordinary Service cannot serve it. What changed is who provides it. Binding the port here costs the whole namespace its PodSecurity level: baseline forbids hostPort, so one pod claiming it means enforcing `privileged` for everything alongside. That is a large price for one port. The region's Pulumi stack owns a Service with `externalIPs` set to the node addresses instead. Cilium runs with kube-proxy replacement and programs those, so UDP 19132 on any node address reaches these pods with no pod claiming a port on the host, and the namespace goes back to baseline. Verified before writing this, not assumed: a probe Service with externalIPs on 19133 answered a RakNet ping identically to the live hostPort on 19132. BREAKING CHANGE: bedrock.hostPort is gone, and the chart no longer exposes the port by itself — a deployment needs the Service its region provides.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A Bedrock client still has to reach UDP 19132 on a node address — that has not changed, and 19132 sits outside the NodePort range so an ordinary Service cannot serve it. What changed is who provides it.
Binding the port here costs the whole namespace its PodSecurity level:
baselineforbids hostPort, so one pod claiming it means enforcingprivilegedfor everything alongside. That is a large price for one port, and it is what groundsgg/grounds-pulumi#434 had to pay.The region's Pulumi stack owns a Service with
externalIPsset to the node addresses instead (groundsgg/grounds-pulumi#438). Cilium runs with kube-proxy replacement and programs those, so UDP 19132 on any node address reaches these pods with no pod claiming a port on the host — and the namespace goes back to baseline.Verified before writing this
A probe Service with
externalIPson 19133, selecting the same pods, answered a RakNet ping identically to the live hostPort on 19132:Breaking
bedrock.hostPortis gone and the chart no longer exposes the port by itself — a deployment needs the Service its region provides. Both bind 19132, so the two cannot overlap: expect a short Bedrock outage between this rolling out and the Pulumi side applying.helm lintclean,kubeconform -strict2/2 valid, and zerohostPortin the rendered output.