[Feature Proposal] - Include InitContainer Sidecars in Port assignment

[nrwiersma]

Is your feature request related to a problem? Please describe. We would like to use InitContainers for sidecar containers, given that the lifecycle is better managed, but port assignment in Agones currently only looks for the containers in Containers meaning the sidecars cannot use external ports.

Describe the solution you'd like https://github.com/googleforgames/agones/blob/main/pkg/apis/agones/v1/gameserver.go#L731

Here, InitContainers with an Always restart policy should be considered.

Describe alternatives you've considered None, there is no other way to do this.

Additional context

Link to the Agones Feature Proposal (if any)

Discussion Link (if any)

[markmandel]

Ooh! Interesting idea!

A couple of thoughts / questions:

1. Have you done any testing to see if hostPort works with init containers? In theory it should be fine - but curious if you've done a POC with a pod?
2. Something like this would probably work, I think:

apiVersion: agones.dev/v1
kind: GameServer
metadata:
  generateName: init-example-
spec
  ports:
    - name: game-port
      containerPort: 7655 # A port for the new main game container
      container: rust-simple
      protocol: UDP
      containerType: Init # default would be "Standard" -- **THIS WOLD BE NEW**
  template:
    spec:
      initContainers:
        - name: rust-simple
          image: us-docker.pkg.dev/agones-images/examples/rust-simple-server:0.13

Edit: reworked yaml to use actual init container,

[nrwiersma]

1. My understanding is yes, but I have not yet run a test. Will do a proper test soon. Also seems there is a bug in the k8s scheduler though, that would delay this a bit: https://github.com/kubernetes/kubernetes/issues/132037
2. I am not sure if Init sidecars can share a name with a container. I would assume not, as getting logs would be interesting. I will look into this, but if they cannot share a name, then no additional config is needed. Was my initial thought anyway.

[markmandel]

Ah that scheduler issue will be an issue - we lean on that a bit to push containers to other nodes when they spin up based on port decisions. Glad you caught that.

I also redid the example above to use an actual init container.

[nrwiersma]

Looks like 1.33.6 should contain the patch for it, and 1.34.2 it seems, so will try my tests against one of those if I can.

[markmandel]

Somehow lost the containerType: Init addition to the config I was describing that would say which type of container we add the port to.

Sad we didn't start with a top level container key and add port, name etc under it - but decisions were made! 🤦🏻

[nrwiersma]

It seems hostPort works on init sidecars:

Init Containers:
  init-myservice:
    Container ID:  containerd://313007946742a043978451062db3455bc63f16a9c6cd8e42ca16536e2093acb3
    Image:         busybox:1.28
    Image ID:      docker.io/library/busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
    Port:          8080/TCP
    Host Port:     34134/TCP
    Command:
      sh
      -c
      sleep 3600
    State:          Running
      Started:      Mon, 01 Dec 2025 08:05:29 +0200
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-wl7zb (ro)

It also does not allow InitContainers to have the same name as a Container:

The Pod "myapp-pod" is invalid: spec.initContainers[0].name: Duplicate value: "myapp-container"

So specifying containerType: Init is not actually needed.

[markmandel]

So specifying containerType: Init is not actually needed.

oh, I see what you are saying. It might just make things easier for us behind the scenes🤔 or maybe not -- it's not like they are huge loops around so many containers that it'll actually matter.

🤷🏻 not a strong opinion from me - probably comes down to a decision at implementation time.

[nrwiersma]

I took a crack at this, let me know what you think. I will do some more indepth testing with it over the next couple of days to further validate it.

[nrwiersma]

Limited testing (single GameServer), the controller and mutation validator seem happy. Ports are assigned, and Kubernetes has accepted the offering.