Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Passthrough on GKE Autopilot #3721

Closed
zmerlynn opened this issue Mar 20, 2024 · 0 comments
Closed

Support Passthrough on GKE Autopilot #3721

zmerlynn opened this issue Mar 20, 2024 · 0 comments
Assignees
Labels
kind/feature New features for Agones

Comments

@zmerlynn
Copy link
Collaborator

zmerlynn commented Mar 20, 2024

When I implemented support for GKE Autopilot (#2777), I blocked the Passthrough port policy on Autopilot because it was complicated: Right now we do a handshake with Autopilot - we create the Pod with a special annotation that says "give me a host port in range X..Y". We then backfill the GameServer object from that. That's fine for Dynamic since we can just treat Autopilot as the source of truth for the port number, but for Passthrough that doesn't work: On Passthrough we need to bind the container to the allocated port - but on Autopilot this allocation happens in an Autopilot webhook, during Pod creation. To support Passthrough, we would need a webhook on Pods after Autopilot's warden-mutating webhook that could then propagate the port setting back to the container.

Looking at webhook options, we could do this pretty safely and filter it pretty much to this exact case:

  • Let's do this all under an AutopilotPassthroughPort Feature Gate
  • When there is a Passthrough port on Autopilot, add a new label, e.g. agones.dev/port: "autopilot-passthrough"
  • In every install, add a webhook:
    • named zzz-agones-mutation-webhook: look, it's cheesy, but webhooks are run in alphabetical order (I verified this), so pick an "end of the phone book" name. But even then, we could guarantee that it's run last with a reinvocationPolicy.
    • The webhook would be scoped to Pod CREATE
    • With an objectSelector of the label we created above - this drastically limits the scope and should increase the extensions load a bit, but not nearly so much as intercepting all Pod.

The webhook could then back the container port from the allocated port.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New features for Agones
Projects
None yet
Development

No branches or pull requests

1 participant