dae5a097e9
A deploy was running the same max ram for both the pod and the java app. This led to issues where the java app would use its max ram and the pod would think it was out of memory. It would kill the pod and the minecraft server with it, often not saving the last few minutes of progress. Now the deploy runs 1GiB extra ram than the java app.
24 lines
1.1 KiB
YAML
24 lines
1.1 KiB
YAML
apiVersion: v2
|
|
name: minecraft
|
|
description: A Minecraft server for kubernetes
|
|
|
|
# A chart can be either an 'application' or a 'library' chart.
|
|
#
|
|
# Application charts are a collection of templates that can be packaged into versioned archives
|
|
# to be deployed.
|
|
#
|
|
# Library charts provide useful utilities or functions for the chart developer. They're included as
|
|
# a dependency of application charts to inject those utilities and functions into the rendering
|
|
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
|
|
type: application
|
|
|
|
# This is the chart version. This version number should be incremented each time you make changes
|
|
# to the chart and its templates, including the app version.
|
|
# Versions are expected to follow Semantic Versioning (https://semver.org/)
|
|
version: 1.0.2
|
|
|
|
# This is the version number of the application being deployed. This version number should be
|
|
# incremented each time you make changes to the application. Versions are not expected to
|
|
# follow Semantic Versioning. They should reflect the version the application is using.
|
|
appVersion: 1.16.4
|