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

adding some architecture notes #21

Merged
merged 2 commits into from
Oct 14, 2021
Merged

Conversation

dgkanatsios
Copy link
Collaborator

Adding some additional architecture notes and design thoughts about

  • port allocation for each GameServer
  • allocation architecture

@dgkanatsios dgkanatsios self-assigned this Oct 14, 2021
- Have the controller's API service (which accepts the allocation requests) forward the allocation request to the sidecar. This is done via having the sidecar expose its HTTP server inside the cluster. Of course, this assumes that we trust the processes running on the containers in the cluster.

For communicating with the sidecar, we picked the second approach. Main reasoning was to minimize the amount of watches to the Kubernetes API server.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 2nd approach reduces the watches down on the API server, but now we have case were we should be enforcing some kind of security check on the controller->pod communication. In the 1st approach we get this authZ check because the pod service account will need to be granted the needed permission on the GS resource type to setup a watch.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#25 tracks this work


## Logging

Thundernetes does not attempt to solve game server logging. There are various solutions on Kubernetes on this problem e.g. having a sidecar that will grab all stdout/stderr output and forward it to a logging aggregator.
Thundernetes does not attempt to solve the game server logging problem. There are various solutions on Kubernetes on this problem e.g. running a [fluentd](https://www.fluentd.org/) DaemonSet in the cluster which will grab the logs and forward them to an output of your choice.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something that might be useful here in the future is samples of patterns for logging with game servers, so the data can be picked up by fluentd, or other consumer.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup, work scheduled on #4. Thanks!

Copy link
Collaborator

@khaines khaines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are great additions. I added some comments for the current material, but nothing blocking at all

@dgkanatsios
Copy link
Collaborator Author

merging for now, will change when #25 is fixed

@dgkanatsios dgkanatsios merged commit c3a6f4e into master Oct 14, 2021
@dgkanatsios dgkanatsios deleted the dev/digkanat/architecture branch October 14, 2021 23:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants