sysctl initContainer requires runAsUser: 0 starting Elasticsearch 8.0.0

[mike-serchenia]

If using example from the documentation, upgrade from 7.17 to 8.0 fails with

bootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least...

sysctl: permission denied on key "vm.max_map_count", ignoring

example

          initContainers:
            - command:
                - sh
                - -c
                - sysctl -w vm.max_map_count=262144
              name: sysctl
              securityContext:
                privileged: true

solution

          initContainers:
            - command:
                - sh
                - -c
                - sysctl -w vm.max_map_count=262144
              name: sysctl
              image: busybox:1.28
              securityContext:
                privileged: true

[pebrc]

We should upgrade the documentation and make sure the init container example for setting this value still works with 8.0.

[barkbay]

We don't need to rely on the busybox image. Starting with 8.0 Elasticsearch container is not running as root anymore, which is required to run sysctl. You can add runAsUser: 0 to force the init container to run as root:

        initContainers:
          - command:
              - sh
              - -c
              - sysctl -w vm.max_map_count=262144
            name: sysctl
            securityContext:
              privileged: true
              runAsUser: 0

I'll create a PR to update the example in the doc.

[KannappanSomu]

hi , containers are not allowed to run as root in many of the managed kubernetes service. so intit container fails
(example : from azure kuberntes aks version 1.22)

works fine with aks version below 1.22

[mmpetarpeshev]

Please update the docs, people like me lost their time on debugging that.

[nitinjagjivan]

privileged: true is not supported with k8s v1.25 PSA baseline/restricted Pod Security Standards. Also privileged containers are dangerous.
Is there any alternative way?

[thbkrkr]

As mentioned here: https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-virtual-memory.html, an alternative if you can't run privileged containers and therefore can't increase the kernel setting vm.max_map_count is to disable mmap, but remember that this not recommended for production workloads.

By default, Elasticsearch uses memory mapping (mmap) to efficiently access indices. Usually, default values for virtual address space on Linux distributions are too low for Elasticsearch to work properly, which may result in out-of-memory exceptions. This is why the quickstart example disables mmap through the node.store.allow_mmap: false setting. For production workloads, it is strongly recommended to increase the kernel setting vm.max_map_count to 262144 and leave node.store.allow_mmap unset.