adding some architecture notes #21
Conversation
| - 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
#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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
yup, work scheduled on #4. Thanks!
|
merging for now, will change when #25 is fixed |
Adding some additional architecture notes and design thoughts about