Configuration Changes To Deploy to GKE
Hey, made a few changes and tested it on my GKE account:
- removed the volume in order for GKE to assign a persistent volume by itself.
- added a storage class instead of the volume
- change the service from node port to load balancer since the node ip isn't fixed
- added update strategy to solve a locked file bug when 2 pods are trying to run the server simultaneously
- removed node from the values file
- changed some of the resources requests to match the machine I chose.
I created a GKE standard cluster with a single n1-standard-4 node in order to have some breathing room in regards to resources. I chose preemptible nodes in order to reduce costs. So far it's looking good. Will update if I encounter any bugs
I'm doing some parallel work around this area (hosting a minecraft server in GKE) and would love to work together with you on this!
I don't see volume.path from the values yaml digested anywhere, is it used?
@salineselin I am letting the GKE decide where to place the volume. I am only giving it the volume claim. So far it works, I am now working on making it work when using pre-emptible nodes.
I'm not merging yet because I'm working on a fix for preemptible nodes. Since the node is changing I probably need to use stateful set for the volumes to transfer properly to the new node. Will update as soon as I'll have the fix
Oh wow somehow I didn't find this before, but it might be a good source of information for running minecraft in kubernetes with Helm. https://github.com/itzg/docker-minecraft-server
hi y'all. I think we need to leave the volume in for people who are not running on GKE. There must be a way to add these changes and make them some kind of configuration value in the helm chart. Any ideas?
Since there are different files needed, I think it's best to keep branches in the repo for local deployment and GKE deployment. There is an option of adding a flag in the values file to let helm know if it needs to process certain files