Perform OS-Level Kernel Tuning

Sysctl: vm.max_map_count

Some components in the Opstella stack (e.g., SonarQube, Elasticsearch-based services) require a higher limit on the number of memory map areas a process may have.

This is REQUIRED for ALL Worker Nodes in your Kubernetes Cluster.

Failure to set this parameter may cause these services to fail to start or crash unexpectedly.

1. Pre-check current value

Run the following command to check the current value on each worker node:

sudo sysctl vm.max_map_count

If the value is greater than or equal to 262144, you can skip this section.

2. Set value permanently

To set this value permanently, add or update the vm.max_map_count setting in /etc/sysctl.conf.

... (deducted)
vm.max_map_count=262144

3. Reload sysctl configuration

sudo sysctl --system
sudo systemctl restart systemd-sysctl

4. Verify the setting

sudo sysctl vm.max_map_count

The output should return 262144.

Clusters without node access (managed Kubernetes)

On a managed Kubernetes service the nodes usually cannot be reached over SSH at all, so none of the commands above can be run. vm.max_map_count is not namespaced, so any Pod on the node reads the node’s own value through /proc. Use a DaemonSet that already runs on every node — antrea-agent, cilium, calico-node, kube-proxy — as the way in:

for p in $(kubectl get pod -n kube-system -l component=antrea-agent -o name); do
  echo -n "$(kubectl get $p -n kube-system -o jsonpath='{.spec.nodeName}'): "
  kubectl exec -n kube-system $p -- cat /proc/sys/vm/max_map_count
done

Every node must report 262144 or higher. Many managed node images already ship a much larger value (VMware TKG v1.34.2+vmware.2, for example, ships 1048576), in which case there is nothing to do.

If a node is below the requirement and you cannot log in to it, the value has to be raised where the node is defined, not on the running node:

• the node-pool / node-image template of your provider (preKubeadmCommands, cloud-init, a baked image), or
• a privileged DaemonSet that sets the sysctl on start, or
• securityContext.sysctls on the Pod, which needs vm.max_map_count in the kubelet’s --allowed-unsafe-sysctls.

Editing /etc/sysctl.conf does not survive a node replacement

On a managed cluster nodes are replaced on every upgrade and on some reconciles, and a replaced node comes back with the image’s value. A value set by hand on a running node is lost with that node — put it in the node template if it has to hold.