Conditional init container, default to disabled

[NickLarsenNZ]

Not everyone can run privileged containers, even though vm.max_map_count is set on the platform.

• Chart version not bumped (the versions are all bumped and released at the same time)
• README.md updated with any new values or changes
• Updated template tests in ${CHART}/tests/*.py
• Updated integration tests in ${CHART}/examples/*/test/goss.yaml

It's unclear whether the chart version in README.md is bumped automatically

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[Crazybus]

This is really useful. I totally didn't think about environments where this would be set on the node level. Thank you for making it configurable!

Apart from the 2 review comments this PR only needs the new value added into the readme. Apart from that it is all ready to go!

[Crazybus]

Did you mean to put false here? The default value that you added to the test is true so the template tests are going to fail.

[Crazybus]

This will need to go after the initContainers: block otherwise this will break extraInitContainers. There is a template test that catches this use case too which is failing:

________________________________ test_adding_a_extra_init_container _________________________________

    def test_adding_a_extra_init_container():
        config = '''
    extraInitContainers: |
      - name: do-something
        image: busybox
        command: ['do', 'something']
    '''
        r = helm_template(config)
>       extraInitContainer = r['statefulset'][uname]['spec']['template']['spec']['initContainers']
E       KeyError: 'initContainers'

[Crazybus]

It's unclear whether the chart version in README.md is bumped automatically

It's not bumped automatically. This chart is released with the same versioning and cadence of the rest of the elastic stack. There will also be occasional extra patch releases in between releases too though.

[Crazybus]

I also need that but I'm curious why you didn't use https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#setting-sysctls-for-a-pod ? This in meant for that use case and this way you don't have to run a privileged container.

I would love to use this but there are a couple of reasons why we can't yet.

1. It's only available as a beta feature in 1.12. We currently support 1.8 and up.
2. To actually enable this sysctl value in 1.12 it requires a Kubernets admin to make changes to the kubelet flags to support it. So that would mean that it wouldn't be possible to run Elasticsearch with the default configuration for all Kubenetes providers.

All unsafe sysctls are disabled by default and must be allowed manually by the cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be scheduled, but will fail to launch.
With the warning above in mind, the cluster admin can allow certain unsafe sysctls for very special situations like e.g. high-performance or real-time application tuning. Unsafe sysctls are enabled on a node-by-node basis with a flag of the kubelet, e.g.:

I would be totally open for a PR that allows the sysctl values to bet set via this method, however we can't make it the default just yet.

[JorisAndrade]

Thanks for the context @Crazybus, I started #220 in the meantime as it is blocking us.

[JorisAndrade]

@Crazybus I guess you should close this one :)