multipaperk8s / multipaperhelm Goto Github PK

Describe the solution you'd like
Affinity, Anti Affinity, Node Selectors and Tolerations as stated by the Kubernetes documentation.

Describe alternatives you've considered
None.

Additional context
None.

Is your feature request related to a problem? Please describe. (Optional)
Currently the Helm chart has no guard for working with older versions.

Describe the solution you'd like
Rather than supporting from Kubernetes 1.23, the support should start at the earliest supported version: 1.21

Describe alternatives you've considered
None. It is not user friendly to only keep the latest version.

Additional context
The Kubernetes version is taken from the Kubernetes release history and support. Not from any cloud providers.

Describe the solution you'd like
A non-tty based console access to MultiPaper on the officially supported images.

Describe alternatives you've considered
None.

Additional context
Approach to attach yourself to the console will be using kubectl attach <pod> -i -c multipaper

Describe the solution you'd like
Make Multipaper completely configurable. This means that we provide options such as: compression, built-in proxy to be configurable and automatically modify the configmap based on this.

Describe alternatives you've considered
Adjust values.yaml with configurations that are easy to use rather than having a YAML configuration. Currently the settings to make modifyable are:

• advertiseToBuiltInProxy (proxy enabled)
• syncScoreboards (options for MultiPaper)
• interServerCompressionThreshold (compression section, enabled, compression size, etc.)
• interServerConsolidationDelay (in combination with compression)
• useLocalPlayerCountForServerIsFullKick
• ticksPerInactiveEntityTracking

Additional context
The current options are not configurable:

• filesToSyncOnStartup (always disabled)
• filesToSyncInRealTime (always disabled)
• filesToOnlyUploadOnServerStop (always disabled)
• filesToNotSync (all files)
• logFileSyncing (always disabled)
• syncJsonFiles (always disabled)
• bungeecordName (generated)
• multipaperMasterAddress (interpolated)

The following file(s) are already completely configurable and only need updates in the future:

• eula.txt
• server.properties (interpolation for server port)
• whitelist.json
• ops.json
• banned-players.json
• banned-ips.json
• bukkit.yml
• permissions.yml
• commands.yml
• help.yml
• spigot.yml (interpolation for bungeecord whether using proxy, bungeecord or velocity)
• paper.yml
• airplane.yml
• pufferfish.yml

Follow up on: MultiPaperK8s/MultiPaperImages#4

Move the world volumes to a single data volume mounted on the current working directory /multipaper/data. All synced files and folders should be saved on this Volume if they wish to be persisted.

Describe the solution you'd like
Velocity Integration with automatic loadbalancing, service discovery and persistency. Clone of MultiPaper Master + Proxy but instead running MultiPaper Master as a Velocity Plugin.
Automatically switch the configuration values once switching from MultiPaper Master standalone to Velocity.
Make completely configurable.

Describe alternatives you've considered
None

Additional context
None

Describe the solution you'd like
Implement RBAC.

TBD.

Describe alternatives you've considered
Not using RBAC.

Additional context
None

Describe the solution you'd like
Implement an Horizontal Pod Autoscaler for the MultiPaper servers once the load gets too much.
Scaling would, for now, go based on CPU and/or memory. Everything about the Horizontal Pod Autoscaler needs to be configurable via values.yaml

Describe alternatives you've considered
None.

Additional context
None.

Describe the solution you'd like
Define Resource requests and limits for the MultiPaper server and master.
Everything about the resources needs to be configurable via values.yaml

Describe alternatives you've considered
None.

Additional context
None.

Describe the solution you'd like
Define a Security Context for both the master and the multipaper server pods. Disabling any feature that is unnecessary and limiting the processes. Currently only the master server ensures running as the multipaper user and group.

Describe alternatives you've considered
Not enforcing more restrictions on the pods and what can be executed on them.

Additional context
None.

Describe the solution you'd like
Define a Disruption Budget for higher availability. This is to ensure less disruptions during an upgrade, (accidental) removals or failures.

Describe alternatives you've considered
Not implementing it and letting administrators define this themselves.

Additional context
None.

Describe the bug
When attempting to connect to a client running 1.19.2 on a local kind cluster I get the following error:

Internal Exception: io.netty.handler.codec.DeconderException:
java.lang.NullPointerException: Cannot invoke "qw$a.a(int, qx)" because the return value of "java.util.Map.get(Object)" is null

To Reproduce
Steps to reproduce the behavior:

1. Build a multipaper server and master image running 1.19.2
2. Use a 1.19.2 client
3. Deploy the helm chart to a local kind cluster
4. port forward a server pod
5. attempt to connect to the server pod via localhost:25565

Expected behavior
A minecraft client running the same version as the server is able to connect

Possible Solution (Optional)
I'm not sure if there is something I am doing wrong with the deployment expectations or if this is just an untested thing.

Versioning
Helm Version: version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.17.5"}

Master Version: 2.10.1 Build 35
Server Version: 1.19.2 Build 35
Kubernetes Version: Major:"1", Minor:"25", GitVersion:"v1.25.2", GitCommit:"5835544ca568b757a8ecae5c153f317e5736700e", GitTreeState:"clean", BuildDate:"2022-09-22T05:25:21Z", GoVersion:"go1.19.1", Compiler:"gc", Platform:"linux/amd64"

Is your feature request related to a problem? Please describe. (Optional)
Currently you need to define a volume through a subPath for each ConfigMap based volume. Multiple data volumes are also used. This seems unnecessary.

Describe the solution you'd like
Transform the ConfigMap based volumes to a projected volume on a single path.

Describe alternatives you've considered
Keeping the current setup.

Additional context
None.