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

Set the hostName of the Pod to the name of the GameServer #2704

Closed
markmandel opened this issue Aug 9, 2022 · 2 comments · Fixed by #2826
Closed

Set the hostName of the Pod to the name of the GameServer #2704

markmandel opened this issue Aug 9, 2022 · 2 comments · Fixed by #2826
Labels
good first issue These are great first issues. If you are looking for a place to start, start here! help wanted We would love help on these issues. Please come help us! kind/feature New features for Agones
Milestone

Comments

@markmandel
Copy link
Member

Is your feature request related to a problem? Please describe.

If you want to connect from within a Agones cluster to a Pod that is backing a GameServer, you have to lookup the internal IP of the Pod to be able to do so.

If you know the name of the GameServer, it would be useful to be able to utilise a DNS record to connect to it from within a cluster.

Describe the solution you'd like

Set the hostName value on the Pod to the same name as the GamseServer (which is the same name as the pod) on creation.

If the end user want to have a DNS record for the Pod inside the cluster, much like one already can with StatefulSets, they can create a headless service to do so:

Describe alternatives you've considered

People can lookup the internal IP through the Kubernetes API, but it requires some more coding to do so.

Additional context

https://agones.slack.com/archives/C9DGM5DS8/p1658939259987459

@markmandel markmandel added kind/feature New features for Agones help wanted We would love help on these issues. Please come help us! good first issue These are great first issues. If you are looking for a place to start, start here! labels Aug 9, 2022
@valentintorikian
Copy link
Contributor

valentintorikian commented Sep 3, 2022

Isn't the pod name (which is the GS name) already the pod hostName ? Wouldn't setting Pod.spec.hostName = gs.Name be a noop in that case ?

EDIT: After a bit of backtracking in that slack thread if found the reference to that piece of doc https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ that Mark linked.

Note: Because A or AAAA records are not created for Pod names, hostname is required for the Pod's A or AAAA record to be
created. A Pod with no hostname but with subdomain will only create the A or AAAA record for the headless Service
(default-> subdomain.my-namespace.svc.cluster-domain.example), pointing to the Pod's IP address. Also, Pod needs to become > ready in order to have a record unless publishNotReadyAddresses=True is set on the Service.

valentintorikian pushed a commit to valentintorikian/agones that referenced this issue Sep 3, 2022
@zmerlynn
Copy link
Collaborator

zmerlynn commented Nov 2, 2022

@valentintorikian - I see you have a commit that would fix this. Would you like to send a PR? Thanks!

markmandel added a commit to markmandel/agones that referenced this issue Nov 26, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
markmandel added a commit to markmandel/agones that referenced this issue Nov 26, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
markmandel added a commit to markmandel/agones that referenced this issue Nov 26, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
markmandel added a commit to markmandel/agones that referenced this issue Nov 27, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
markmandel added a commit to markmandel/agones that referenced this issue Dec 1, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
markmandel added a commit to markmandel/agones that referenced this issue Dec 15, 2022
This change sets the hostName (if not already set) on the Pod of the
GameServer, if an end user would like a DNS entry to communicate
directly to the GameServer Pod in the cluster.

Since this is a relatively minor change, no FeatureFlag was created.

Closes googleforgames#2704
zmerlynn pushed a commit that referenced this issue Dec 15, 2022
Under the `PodHostname` feature gate, this change sets the hostName
(if not already set) on the Pod of the GameServer, if an end user would
like a DNS entry to communicate directly to the GameServer Pod in the
cluster.

Closes #2704
@Kalaiselvi84 Kalaiselvi84 added this to the 1.29.0 milestone Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue These are great first issues. If you are looking for a place to start, start here! help wanted We would love help on these issues. Please come help us! kind/feature New features for Agones
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants