Advanced configuration
editAdvanced configuration
editIf you already looked at the Elasticsearch on ECK documentation, some of these concepts might sound familiar to you. The resource definitions in ECK share the same philosophy when you want to:
- Customize the Pod configuration
- Customize the product configuration
- Manage HTTP settings
- Use secure settings
Pod configuration
editYou can customize the Kibana Pod using a Pod template.
The following example demonstrates how to create a Kibana deployment with custom node affinity and resource limits.
apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: kibana-sample spec: version: 8.15.3 count: 1 elasticsearchRef: name: "elasticsearch-sample" podTemplate: spec: containers: - name: kibana resources: requests: memory: 1Gi cpu: 0.5 limits: memory: 2Gi cpu: 2 nodeSelector: type: frontend
The name of the container in the Pod template must be kibana
.
See Set compute resources for Kibana, Enterprise Search and APM Server for more information.
Kibana configuration
editYou can add your own Kibana settings to the spec.config
section.
The following example demonstrates how to set the elasticsearch.requestHeadersWhitelist
configuration option.
apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: kibana-sample spec: version: 8.15.3 count: 1 elasticsearchRef: name: "elasticsearch-sample" config: elasticsearch.requestHeadersWhitelist: - authorization
Scale out a Kibana deployment
editTo deploy more than one instance of Kibana, all the instances must share the same encryption key. To set your own encryption key, set the xpack.security.encryptionKey
property using a secure setting, as described in Secure settings. If you don’t set any encryption key, the operator generates one for you.
While most reconfigurations of your Kibana instances are carried out in rolling upgrade fashion, all version upgrades will cause Kibana downtime. This happens because you can only run a single version of Kibana at any given time. For more information, see Upgrade Kibana.