consider http probes instead of exec probes?

[billimek]

Is this a request for help?: No

---

FEATURE REQUEST:

The artifactory helm chart by default leverages exec-style probes to invoke curl commands, e.g.

  livenessProbe:
    enabled: true
    config: |
      exec:
        command:
          - sh
          - -c
          - curl -s -k --fail --max-time {{ .Values.probes.timeoutSeconds }} {{ include "artifactory.scheme" . }}://localhost:{{ .Values.router.internalPort }}/router/api/v1/system/liveness
      initialDelaySeconds: {{ if semverCompare "<v1.20.0-0" .Capabilities.KubeVersion.Version }}90{{ else }}0{{ end }}
      periodSeconds: 10
      timeoutSeconds: {{ .Values.probes.timeoutSeconds }}
      failureThreshold: 5
      successThreshold: 1

Is the curl command necessary to properly probe the health of the instances, or is it possible to leverage https style probes to achieve the same end-result?

The reason for this ask is that there is currently an open kubernetes issue related to using exec-style probes and possibly resulting in high system CPU/load.

Version of Helm and Kubernetes: helm3, 1.22.8-gke.202

Which chart: artifactory

[eldada]

Hi @billimek. We actually moved to using exec probes with curl because of https://github.com/kubernetes/kubernetes/issues/89898. We saw this happening in our production clusters (many false positives), and the move to the exec probes fixed it.

You can replace them with http probes without worry. It should work the same. This is why it's fully configurable. We are aware of https://github.com/kubernetes/kubernetes/issues/82440, and are also impacted by it, but when choosing between the two options, we prefer higher CPU but better availability.

[billimek]

Thanks for the quick reply and context @eldada. I'll definitely watch https://github.com/kubernetes/kubernetes/issues/89898 now too. It's too bad there are challenges with both exec and http probes!

[eldada]

Spoke too soon... we tested this internally and found some gaps in making it work with a simple switch to http. I'm reopening this for now. Will come back to it once we have a working solution.