No, the k8s "kubelet", which runs on each worker node, doesn't use much RAM. Java services have notoriously spiky memory usage, so you end up provisioning much more RAM than you need in the average case to be able to support the spikes, so you underutilize RAM in the average case. The previous poster is describing an issue where they overprovisioned RAM heavily, and so, ended up using a lot of nodes due to the way memory requests and limits are managed in k8s.
You fix this by enabling swap and and allocating pods to nodes based on their common memory usage, and accept that your worker node will slow down when some Java process wants all the RAM.
Tbh, k8s "system" namespaces also consume quite a bit (particulary if you wanna run a minimal system) - at least 0.5 vCPU on each node and something like 0.5-1GB of RAM. This is only important for the smallest systems, but still is a hindrance to K8s adoption for such projects.
You fix this by enabling swap and and allocating pods to nodes based on their common memory usage, and accept that your worker node will slow down when some Java process wants all the RAM.