- 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
- HTTP settings and TLS SANs
- 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
- Run Kibana on ECK
- Run APM Server on ECK
- Run Elastic Agent on ECK
- Run Enterprise Search on ECK
- Run Beats on ECK
- Secure the Elastic Stack
- Access Elastic Stack services
- Customize Pods
- Manage compute resources
- 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/v1beta1
- kibana.k8s.elastic.co/v1
- kibana.k8s.elastic.co/v1beta1
- Glossary
- Third-party dependencies
- API Reference
- 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.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
Grant privileged permissions to Beats
editGrant privileged permissions to Beats
editDeploying Beats on Openshift may require some privileged permissions. This section describes how to create a ServiceAccount, add the ServiceAccount to the privileged
SCC, and use it to run Beats.
The following example assumes that Beats is deployed in the Namespace elastic
with the ServiceAccount heartbeat
. You can replace these values according to your environment.
If you used the examples from the recipes directory, the ServiceAccount may already exist.
-
Create a dedicated ServiceAccount:
oc create serviceaccount heartbeat -n elastic
-
Add the ServiceAccount to the required SCC:
oc adm policy add-scc-to-user privileged -z heartbeat -n elastic
-
Update the Beat manifest to use the new ServiceAccount, for example:
apiVersion: beat.k8s.elastic.co/v1beta1 kind: Beat metadata: name: heartbeat spec: type: heartbeat version: 8.17.0 elasticsearchRef: name: elasticsearch config: heartbeat.monitors: - type: tcp schedule: '@every 5s' hosts: ["elasticsearch-es-http.default.svc:9200"] - type: tcp schedule: '@every 5s' hosts: ["kibana-kb-http.default.svc:5601"] deployment: replicas: 1 podTemplate: spec: serviceAccountName: heartbeat securityContext: runAsUser: 0
If SELinux is enabled, the Beat Pod might fail with the following message:
Exiting: Failed to create Beat meta file: open /usr/share/heartbeat/data/meta.json.new: permission denied
To fix this error, apply the label svirt_sandbox_file_t
to the directory /var/lib/elastic/heartbeat/heartbeat-data/
on the Kubernetes node:
chcon -Rt svirt_sandbox_file_t /var/lib/elastic/heartbeat/heartbeat-data/
Repeat this step on all the hosts where the heartbeat Pod can be deployed.
Some Beats may require additional permissions. For example, Filebeat
needs additional privileges to read other container logs on the host. In this case, you can use the privileged
field in the security context of the container spec:
apiVersion: beat.k8s.elastic.co/v1beta1 kind: Beat metadata: name: filebeat spec: type: filebeat ... daemonSet: podTemplate: spec: serviceAccountName: filebeat automountServiceAccountToken: true ... containers: - name: filebeat securityContext: runAsUser: 0 privileged: true # This is required to access other containers logs volumeMounts: - name: varlibdockercontainers mountPath: /var/lib/docker/containers volumes: - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers
See the complete examples in the recipes directory.
ElasticON events are back!
Learn about the Elastic Search AI Platform from the experts at our live events.
Register now