Does this init container applies changes to complete host?

General Discussions
1

Hi,
I am fairly new to kubernetes and want to build a statefulset for elasticsearch.
I found this one here during my search in web:

My question is about the init container given there:

 spec:
      initContainers:
      - name: init-sysctl
        image: busybox:1.27.2
        command:
        - sysctl
        - -w
        - vm.max_map_count=262144
        securityContext:
          privileged: true

      - name: es-master
        image: quay.io/pires/docker-elasticsearch-kubernetes:6.3.0
        env:
        - name: NAMESPACE
        ...

Is my understanding correct, that the init container applies the change to the host and that it is immediately valid for all pods running on that given host?

If so I should remember to use this with care because different init containers could set different values for same parameter.

Thanks,
Andreas

2

That is correct. I would personally avoid using that example as it requires a privileged securityContext. If you want to set the settings for the host, you could do it as a one off job, daemonset, or manage it at the host directly.

3

Hi @mrbobbytables, thanks for your reply.

A question about the daemonset:
With the daemonsets I got in touch with yet, they are checking if a pod is running on the nodes which are matching the selector. If I delete such a pod it gets restarted immediately.

Setting up these settings needs to be done once after starting the kubernetes node if my assumption is correct.
How can I configure a daemonset to run only once after boot / really seldom?

Is a daemonset always running in privilleged security context or is this optional as in “normal” pods?

Thanks, Andreas

4

It’d still run, but could just sleep and check to ensure the settings are set on an interval.

Its optional for all pods, but is HIGHLY discouraged unless you absolutely need to. For example in our clusters, we have a pod security policy in place that prevents the running of any privileged pod unless its managed by us as admins and is in a few specific namespaces (e.g. kube-system).

5

great, then I think I have a path now to go along.
many thanks.

6

As a side note, this Bob is saying might not be so clear how nice it is. You know the reconciliation loop idea of kubernetes? That basically you observe the world, the desired state and then do what is needed (create a pod, delete, etc.) to make both match?

This is basically the same, for your setting. If someone changes it, if it interfieres with another setting from another workload or something, this will be automatically fixed for you.

This has the advantage of “fixing” it without human intervention while you can still log/mail/what is best for you to investigate why this happened when is best for you :slight_smile:

7

It’s worth pointing out that some sysctls are global and some are namespaced, so while it may be true in this case that it is global, it isn’t ALWAYS.