Operator for Kubernetes that will take care of the gist of your Elasticsearch cluster, managing your:
- Templates
- Indices
This operator is the glue between the state of your Elasticsearch cluster and Kubernetes. By using Elasticsearch's excellent Java client, it wil try to create, update and delete the custom resources defined in this directory.
Always make sure only 1 instance of the Operator is running at the same time to prevent concurrency issues
The Docker image for this repository is available at docker.pkg.github.com/frankkoornstra/elasticsearch-gist-operator/elasticsearch-gist-operator:{version tag}. To use Github's Docker repository, you will need to authenticate.
You'll probably want to deploy the Operator inside Kubernetes. If you want to see a simplistic example of how to do that, clone this repository and - only when connected to your development cluster! - run:
cd kubernetes-resources
make GITHUB_USERNAME=<your github username> GITHUB_TOKEN=<github token>It will:
- Create a secret, needed to pull the docker image from Github's Docker repository. You'll need to create a token with
read:packagescapabilities to do this. - Update the CRDs that the operator defines
- Create a deployment for the Operator
By using the Recreate deployment strategy in Kubernetes, you make sure only one instance of the Operator is running at the same time.
The Operator is semantically versioned. It obviously has a huge dependency on Elasticsearch so versioning of the Operator is tightly bound to the Elasticsearch version.
Any bumps in parts of the Elasticsearch library version will always result in a bump in the same part of that version in the Operator; ie a major version bump in the Elasticsearch library results in a major version bump of the Operator version, same with minor and patch.
Bumps in the Operator major, minor and patch versions can still happen independently so multiple major versions of the operator might be compatible with the same major Elatiscsearch version (although we'll do our best to avoid this).
In the table below you can find the compatibility between versions of this operator and Elasticsearch.
| Operator | Elasticsearch |
|---|---|
| 0.1 (alpha) | 6.8 |
The Operator controls the following resources:
- Templates
- Indices
Usually one of the first steps is to setup templates. They contain mappings and settings as well as a pattern that can match to-be created indices. Once an index gets created that matches one or more template patterns, all the contents of those templates will be applied to the new index.
You can create and update templates with this operator by sticking to the definition of the custom resource, an example is also availabe
The bread and butter of Elasticsearch; this will contain all your documents. Indices have three core components: settings, a mapping and aliases. All three of them can be managed by this operator, although there are some things to take into consideration, outlined below.
You can create and update indices with this operator by sticking to the definition of the custom resource, an example is also availabe
Settings come in two kinds: static or dynamic.
When you create an index, all settings in your CRD will be applied. When you update and index, only the dynamic settings will be applied.
Mappings adhere to the concept of backwards compatibility (BC), for details browse the Elasticsearch documentation on what is and is not BC.
Whenever you update a mapping in an index in a non-BC manner, the update will fail.
This will be reflected by a FAILED status object in the CRD, the reason why it failed will also be in the status object.
Simple: it'll remove existing aliases that aren't in the CRD anymore, it will ad the ones that don't exist yet.
This operator does not support filters on aliases (yet, PRs welcome)
- Upsert/delete templates
- Upsert/delete indices
- Upsert index aliases (without filters or routing)
- Integration tests with Elasticsearch
- Github Actions to run tests for PRs
- Release process
- Status subresource