[kibana] Chart template to add custom readinessProbe methods

[Ant0wan]

Prerequisites

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

---

Description

This PR aims at templating readinessProbes fields giving the possibility to use either:

• default exec command provided in the helm template
• to provide custom field httpGet
• to provide custom field custom exec command.

Context

Migration of our kubernetes deployments to Spinnaker including Kibana.

Kibana deployment with Spinnaker fails due to variable substitutions made by Orca over the Kibana helm chart corrupting Kibana's Helm chart. Here is a reference to that issue.. A fix on Spinnaker side should be made in a mid/long-term thanks to a code base refactoring ongoing + link.

As a work around to make our Kibana deployment work and as an improvement of the Kibana Helm chart, I suggest to add the option to customize readinessProbe.

Expected template behavior

List of the changes this PR will make in the possible use of the Kibana Helm chart.

Use Case 1 - No custom readinessProbe defined (default use case)

This use case aims at not breaking the already existing implementation everyone is probably using aka no custom readinessProbe exec nor httpGet.

If no readinessProbe.exec specified or empty nor readinessProbe.httpGet specified or empty it will take the default readinessProbe.exec specified in templates/deployment.yaml. ReadinessProbe deployment output will be the default one:

[...]
        readinessProbe:
          [...]
          exec:
            command:
              - bash
              - -c
              - |
                #!/usr/bin/env bash -e

                # Disable nss cache to avoid filling dentry cache when calling curl
                # This is required with Kibana Docker using nss < 3.52
                export NSS_SDB_USE_CACHE=no

                http () {
                    local path="${1}"
                    set -- -XGET -s --fail -L

                    if [ -n "${ELASTICSEARCH_USERNAME}" ] && [ -n "${ELASTICSEARCH_PASSWORD}" ]; then
                      set -- "$@" -u "${ELASTICSEARCH_USERNAME}:${ELASTICSEARCH_PASSWORD}"
                    fi

                    STATUS=$(curl --output /dev/null --write-out "%{http_code}" -k "$@" "{{ .Values.protocol }}://localhost:{{ .Values.httpPort }}${path}")
                    if [[ "${STATUS}" -eq 200 ]]; then
                      exit 0
                    fi

                    echo "Error: Got HTTP code ${STATUS} but expected a 200"
                    exit 1
                }

                http "{{ .Values.healthCheckPath }}"

Use Case 2 - Use custom readinessProbe exec

If the readinessProbe.exec field is specified in values.yaml, the specified probe will be included in the deployment.

values.yaml example:

readinessProbe:
  [...]
  exec:
    command:
      - echo
      - 'ok'

ReadinessProbe deployment output will be the specified one from values.yaml:

[...]
        readinessProbe:
          [...]
          exec:
            command:
              - echo
              - 'ok'

Use Case 3 - Use custom readinessProbe httpGet

If the readinessProbe.httpGet field is specified in values.yaml, the specified probe will be included in the deployment.

values.yaml example:

readinessProbe:
  [...]
  httpGet:
    path: /app/kibana
    port: 5601

ReadinessProbe deployment output will be the specified one from values.yaml:

[...]
        readinessProbe:
          [...]
          httpGet:
            path: /app/kibana
            port: 5601

Broken Use Case - Both custom readinessProbe httpGet and exec use

If both readinessProbe.httpGet and readinessProbe.httpGet fields are specified in values.yaml, the specified probes will be included in the deployment.
This will trigger an error from Kubernetes at deployment time. Multiple defined probe methods cannot be used at the moment as defined by the Kubernetes spec. However, this might change with time. The non-definitive aspect of this implementation led me to NOT implement error management for such case.

Tests added in kibana/tests/*.py

tests/kibana_test.py::test_httpget_readinessprobe PASSED
tests/kibana_test.py::test_exec_readinessprobe_custom PASSED

[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?

[cla-checker-service]

💚 CLA has been signed

[Ant0wan]

Hi @pugnascotia, sorry for tagging you. I saw you approved some of the PR related to Kibana. I wanted to ask about the process I should follow for this PR. Have a nice day :-)

[pugnascotia]

@jmlrt can you help out here? I've done very little in this repository.

[Ant0wan]

@jmlrt any update on this ? I am stuck till the PR isn't merged - sorry for bothering with this :-)

[jmlrt]

Hey @Ant0wan, we were busy finalizing the 8.5.1 release and announcement for the future of this repository.

Regarding that, not sure when this PR will be reviewed, sorry.

[Ant0wan]

Hi guys, @jmlrt && @pugnascotia - any update on this ? :-) Have a nice day

[Ant0wan]

Hi fellows, happy new year ! :-)
Any update on this PR ? Many thanks