Ответ от mk_sta полезен, и вся необходимая информация, вероятно, содержится в этих документах, но я считаю, что в полном ответе стоит обобщить основные моменты.
Ваш параметр -Xmx2048m (2 ГБ) устанавливает максимальный размер кучи, но приложение будет использовать больше памяти, чем это - Metaspace, сборщик мусора и много других служебных данных (это память «вне кучи»).
Независимо от того, насколько просто ваше приложение, Java будет использовать доступный размер кучи. Трехстрочное приложение, выводящее случайные строки, если ему выделена куча в 2 Гб, в конечном итоге будет использовать все это. Так что не имеет значения, если ваше приложение Spring Boot «простое» - куча будет расти, пока не достигнет максимума, и тогда вы увидите сборку мусора - это зубчатые зубы на вашей зеленой линии.
Таким образом, эти две вещи вместе, вероятно, объясняют, почему вы видите верхнюю границу использования памяти около 3,8 ГБ.
Графики, которые вы строите, вероятно, показывают приложение с хорошим поведением, так что перестаньте беспокоиться об утечках памяти. Я не могу сказать по картинке, если это небольшие или крупные коллекции. Т.е. по картине я не могу понять, как мало вы можете рискнуть сжать Xmx.
Несмотря на то, что вы говорите, что приложение Spring Boot «простое», невозможно узнать, не увидев, насколько оно сложное на самом деле. Но документ со ссылкой на mk_ska здесь ...
https://github.com/dsyer/spring-boot-memory-blog/blob/master/cf.md
... очень полезен, потому что показывает некоторые хорошие настройки по умолчанию для "небольших" приложений Spring Boot - например, приложение, использующее Freemarker для генерации нестатического контента, может успешно работать с кучей 32 МБ.
Так что простой ответ - попытаться уменьшить ваш -Xmx до минимального значения, прежде чем вы увидите, что сборщик мусора ломится. Вы также можете получить его до 32 МБ.
Затем вы можете использовать эти результаты, чтобы установить некоторые разумные значения для предела ресурса и запроса ресурса в ваших манифестах K8S. Вам понадобится намного больше, чем, например, 32 МБ размера кучи - как указано в этом документе, загрузочные приложения Spring намного лучше с объемом контейнера 512 МБ или 1 ГБ. Вы могли бы обойтись с 256 МБ, но это сложно.