Kibana Helm Charts

[jmlrt]

Product teams tasks

We’d like to have chart reviews from product teams to validate that they are following product recommended configuration for Kubernetes:

Kibana

• Review Kibana Helm Chart @tylersmalley

[jmlrt]

Hi @tylersmalley,
Thank you for working on this issue.

Kibana chart code is in helm-charts/kibana.

This chart will create the following K8S resources:

• Deployment which will manage the Kibana pods
• Service which will expose the pods as network services internal to the K8S cluster
• (Optional) ConfigMap containing kibana.yml content (default values in values.yaml)
• (Optional) Ingress which manage external access to the service

What we would like for this review

• Validate that a chart deployment with default values provides a well-configured Kibana
• Validate that we don't need additional K8S resources for specific Kibana use cases (examples additional services/ingress for exposing other ports, additional initContainer, additional volumes for persistency)
• Validate the default resources requests / limits
• Validate readinessProbe to check that Kibana is ready and help us define a livenessProbe (quoting @Crazybus livenessProbe = I'm dead, restart me / readinessProbe = I'm not ready to receive traffic, wait for me)
• Validate that we can't use RollingUpdate strategy and need Recreate during updates
• Any other thing that could be relevant

Please ping me if you have any questions

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[tylersmalley]

@jmlrt,

Still going through actual testing of this - but wanted answer some of the questions.

Validate the default resources requests / limits

I believe we will want to modify these. On Cloud we have found that most utilizing reporting in Kibana require 2GB of system memory. For that, I believe we should set requests.memory to 2Gi. With that, what would you suggest the limits.memory be set to? It's my understanding that if it hits this value the container will be killed. Additionally, we will want to set NODE_OPTIONS="--max-old-space-size=1800" in deployment.yaml#L81 to make sure we're using the heap available correctly.

Validate readinessProbe to check that Kibana is ready

Yes, this is the correct method until the work is completed for #46984. livenessProbe could be the same check, but will need to give it some thought.

Validate that we can't use RollingUpdate strategy and need Recreate during updates

That is correct, Kibana does not support rolling upgrades and the previous version fully brought down before a newer version is stood up. We're tracking rolling upgrades here.

[jmlrt]

Thanks for this first feedback 👍

Validate the default resources requests / limits

We usually recommand setting requests = limits, I'll create a PR to change requests.memory from 500Mi to 2Giand limits.memory from 1Gi to 2Gi.

It's my understanding that if it hits this value the container will be killed.

That's true. Do you have a lot of use cases where kibana can require more memory?

EDIT: created elastic/helm-charts#540

[tylersmalley]

It really shouldn't require more memory as most is on heap, so setting the max-old-space-size to 1800 should keep us below 2G.

[jmlrt]

@tylersmalley Do you have other feedback to add for Kibana chart or can we close this issue?

[tylersmalley]

@jmlrt I have retested this and everything appears to be running smoothly now. Thanks! I don't see anything else left here, OK to close?

[jmlrt]

Closing it so. Thanks for your review 🙏

[jmlrt]

livenessProbe could be the same check, but will need to give it some thought.

=> related to elastic/helm-charts#575