If 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
You 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: 7.10.2 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
See Set compute resources for Kibana and APM Server for more information.
You can add your own Kibana settings to the
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: 7.10.2 count: 1 elasticsearchRef: name: "elasticsearch-sample" config: elasticsearch.requestHeadersWhitelist: - authorization
To 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.