- Elastic Cloud on Kubernetes:
- Overview
- Quickstart
- Operating ECK
- Orchestrating Elastic Stack applications
- Run Elasticsearch on ECK
- JVM heap size
- Node configuration
- Volume claim templates
- Storage recommendations
- Transport settings
- Virtual memory
- Settings managed by ECK
- Secure settings
- Custom configuration files and plugins
- Init containers for plugin downloads
- Update strategy
- Pod disruption budget
- Nodes orchestration
- Advanced Elasticsearch node scheduling
- Create automated snapshots
- Remote clusters
- Readiness probe
- Pod PreStop hook
- Elasticsearch autoscaling
- JVM heap dumps
- Security Context
- Run Kibana on ECK
- Run APM Server on ECK
- Run standalone Elastic Agent on ECK
- Run Fleet-managed Elastic Agent on ECK
- Run Elastic Maps Server on ECK
- Run Enterprise Search on ECK
- Run Beats on ECK
- Secure the Elastic Stack
- Access Elastic Stack services
- Customize Pods
- Manage compute resources
- Autoscaling stateless applications
- Upgrade the Elastic Stack version
- Run Elasticsearch on ECK
- Advanced topics
- Reference
- API Reference
- agent.k8s.elastic.co/v1alpha1
- apm.k8s.elastic.co/v1
- apm.k8s.elastic.co/v1beta1
- beat.k8s.elastic.co/v1beta1
- common.k8s.elastic.co/v1
- common.k8s.elastic.co/v1beta1
- elasticsearch.k8s.elastic.co/v1
- elasticsearch.k8s.elastic.co/v1beta1
- enterprisesearch.k8s.elastic.co/v1
- enterprisesearch.k8s.elastic.co/v1beta1
- kibana.k8s.elastic.co/v1
- kibana.k8s.elastic.co/v1beta1
- maps.k8s.elastic.co/v1alpha1
- Glossary
- Third-party dependencies
- API Reference
- Release highlights
- 1.8.0 release highlights
- 1.7.1 release highlights
- 1.7.0 release highlights
- 1.6.0 release highlights
- 1.5.0 release highlights
- 1.4.1 release highlights
- 1.4.0 release highlights
- 1.3.2 release highlights
- 1.3.1 release highlights
- 1.3.0 release highlights
- 1.2.2 release highlights
- 1.2.1 release highlights
- 1.2.0 release highlights
- 1.1.2 release highlights
- 1.1.1 release highlights
- 1.1.0 release highlights
- 1.0.1 release highlights
- 1.0.0 release highlights
- 1.0.0-beta1 release highlights
- Release notes
- Elastic Cloud on Kubernetes version 1.8.0
- Elastic Cloud on Kubernetes version 1.7.1
- Elastic Cloud on Kubernetes version 1.7.0
- Elastic Cloud on Kubernetes version 1.6.0
- Elastic Cloud on Kubernetes version 1.5.0
- Elastic Cloud on Kubernetes version 1.4.1
- Elastic Cloud on Kubernetes version 1.4.0
- Elastic Cloud on Kubernetes version 1.3.2
- Elastic Cloud on Kubernetes version 1.3.1
- Elastic Cloud on Kubernetes version 1.3.0
- Elastic Cloud on Kubernetes version 1.2.2
- Elastic Cloud on Kubernetes version 1.2.1
- Elastic Cloud on Kubernetes version 1.2.0
- Elastic Cloud on Kubernetes version 1.1.2
- Elastic Cloud on Kubernetes version 1.1.1
- Elastic Cloud on Kubernetes version 1.1.0
- Elastic Cloud on Kubernetes version 1.0.1
- Elastic Cloud on Kubernetes version 1.0.0
- Elastic Cloud on Kubernetes version 1.0.0-beta1
Transport settings
editTransport settings
editThe transport module in Elasticsearch is used for internal communication between nodes within the cluster as well as communication between remote clusters. See the Elasticsearch documentation for details. For customization options of the HTTP layer see Services and TLS certificates.
Customize the Transport Service
editIn the spec.transport.service.
section, you can change the Kubernetes service used to expose the Elasticsearch transport module:
spec: transport: service: metadata: labels: my-custom: label spec: type: LoadBalancer
Check the Kubernetes Publishing Services (ServiceTypes) that are currently available.
When you change the clusterIP
setting of the service, ECK deletes and re-creates the service, as clusterIP
is an immutable field. This will cause a short network disruption, but in most cases it should not affect existing connections as the transport module uses long-lived TCP connections.
Configure a custom Certificate Authority
editElasticsearch uses X.509 certificates to establish encrypted and authenticated connections across nodes in the cluster. By default, ECK creates a self-signed CA certificate to issue a certificate for each node in the cluster.
You can use a Kubernetes secret to provide your own CA instead of the self-signed certificate that ECK will then use to create node certificates for transport connections.
The CA certificate must be stored in the secret under ca.crt
and the private key must be stored under ca.key
.
You need to reference the name of a secret that contains the TLS private key and the CA certificate, in the spec.transport.tls.certificate
section, as shown in this example:
spec: transport: tls: certificate: secretName: custom-ca
Customize the node transport certificates
editThe operator generates a self-signed TLS certificates for each node in the cluster. You can add extra IP addresses or DNS names to the generated certificates as follows:
apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: quickstart spec: version: 8.17.2 transport: tls: subjectAltNames: - ip: 1.2.3.4 - dns: hulk.example.com nodeSets: - name: default count: 3
On this page