Add plugins and custom configuration files in Elastic Cloud on Kubernetes

On Elastic Cloud on Kubernetes, Elasticsearch and Kibana run in Kubernetes pods. Unlike Elastic Cloud Hosted and Elastic Cloud Enterprise, Elastic Cloud on Kubernetes does not host a catalog of plugins that you enable on a deployment. You must install any plugin that is not already in the base image before the main Elasticsearch container starts. That includes official Elasticsearch plugins, community or third-party plugins, and plugins you write yourself.

You can also add custom configuration files such as synonym dictionaries, SAML metadata, or CA certificates to the Elasticsearch configuration directory.

Refer to Plugins and custom configuration files for options that apply to other deployment types.

Custom container images and init containers install the same plugins. They differ in when the installation occurs: a custom image includes the plugins at build time, while an init container installs them each time a pod starts. This determines the infrastructure you need to maintain, how quickly nodes become ready, and whether node startup depends on network access.

With a custom container image, you build the plugins into an image based on the official Elastic images, so they are already in place when the container starts. Nodes start faster, need no internet access at runtime, and every node runs an identical image. In exchange, you need a container registry and build infrastructure, and each Elasticsearch version upgrade means building and publishing a new image. You can include custom configuration files in the image as well.

With init containers, an init container runs elasticsearch-plugin install before Elasticsearch starts. You can get started without a registry and change plugin versions by editing the manifest, but every new node repeats the download, which uses bandwidth and delays startup. It also ties node creation to network availability, so a network problem or an incorrect plugin reference can cause new nodes to fail. If your pods run in a service mesh, review the note about using Istio.

Use a custom image when reproducibility and predictable startup are priorities, such as in production environments. Use init containers when you need to iterate quickly, or when maintaining a container registry and build pipeline is not practical.

To make files such as synonym dictionaries, certificates, or SAML metadata available to Elasticsearch, mount them from a ConfigMap or Secret using a volume and volume mount. This is the standard Kubernetes way to get files into a pod, and file content stays managed as Kubernetes objects, so updating a file means updating the ConfigMap or Secret instead of rebuilding an image. The trade-off is that you maintain those objects alongside your Elasticsearch manifests.

To run Kibana with additional plugins, use a custom container image that already includes them. Refer to Install Kibana plugins for more information.