Create custom images

You can create your own custom application images (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, and Elastic Maps Server) instead of using the base images provided by Elastic. You might want to do this to have a canonical image with all the necessary plugins pre-loaded rather than installing them through an init container each time a Pod starts. You must use the official image as the base for custom images. For example, if you want to create an Elasticsearch 8.17.0 image with the Google Cloud Storage Repository Plugin, you can do the following:

There are various hosting options for your images. If you use Google Kubernetes Engine, it is automatically configured to use the Google Container Registry. Check Using Container Registry with Google Cloud for more information. To use the image, you can then push to the registry with:

docker tag elasticsearch-gcs:8.17.0 gcr.io/$PROJECT-ID/elasticsearch-gcs:8.17.0
docker push gcr.io/$PROJECT-ID/elasticsearch-gcs:8.17.0

Configure your Elasticsearch specification to use the newly pushed image, for example:

spec:
  version: 8.17.0
  image: gcr.io/$PROJECT-ID/elasticsearch-gcs:8.17.0

The steps are similar for Azure Kubernetes Service and AWS Elastic Container Registry.

For more information, check the following references:

When creating custom resources (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, and Elastic Maps Server), the operator defaults to using container images pulled from the docker.elastic.co registry. If you are in an environment where external network access is restricted, you could configure the operator to use a different default container registry by starting the operator with the --container-registry command-line flag. Check Configure ECK for more information on how to configure the operator using command-line flags and environment variables.

The operator expects container images to be located at specific paths in the default container registry. Make sure that your container images are stored at the right path and are tagged correctly with the stack version number. For example, if your private registry is my.registry and you wish to deploy components from stack version 8.17.0, the following image paths should exist: