Introducing Elastic Cloud on Kubernetes Stack Configuration Policies

By

Omer Kushmaro

illustration-generic-cloud-update-1680x980-midnight.png

Managing and maintaining the configuration of Elasticsearch for your specific use case and application, through various continuous integration and delivery steps, is a hard task. It often requires “init steps” in your infrastructure as code processes, such as creating specific application-related users, roles, data retention and backup policies, and often dealing with RESTful API calls and misconfigurations that might happen along the way.

This is why we’re excited to introduce a new type of Custom Resource (CRD) to Elastic Cloud on Kubernetes (ECK) — Elastic Stack Configuration Policies. This new policy CRD allows you to explicitly configure Elasticsearch clusters managed by ECK.

With the Stack Configuration Policy CRD, you can set policies to configure various aspects of the Elastic stack, such as snapshot policies and repositories, index lifecycle management (ILM) policies, index templates, component templates, various cluster settings, and more.

Anything configured by such a policy will be immutable by any other means, giving you the power to enforce specific settings on one or more of your Elasticsearch clusters.

This opens up a wide range of use cases, from setting and controlling backup policies for your dev and production clusters to applying consistent data retention schemes using ILM policies, and ultimately, creating reusable and consistent Elasticsearch clusters, without the need to manually intervene or modify Elasticsearch on creation.

Example: Snapshot backup policy

Using the Stack Configuration Policies, ECK users can enforce a backup repository and snapshot policy for all of our Elasticsearch clusters above version 8.6.1.

For the creation of the cluster, we’ll use the same regular workflow as presented in the ECK quickstart example:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 8.6.1
  nodeSets:
  - name: default
    count: 3
    Config:
      # Read more here about this configuration
      node.store.allow_mmap: false

*node.store.allow_mmap: false is not recommended for production workloads, read more here.

Now that we have a cluster up and running, we can enforce a backup policy, which will connect to a specific snapshot repository, and perform backups using a snapshot lifecycle management (SLM) policy:

apiVersion: stackconfigpolicy.k8s.elastic.co/v1alpha1
kind: StackConfigPolicy
metadata:
  name: backup-policy
spec:
  elasticsearch:
    snapshotRepositories:
      backup-repo:
        type: gcs
        settings:
          bucket: my-bucket
    snapshotLifecyclePolicies:
      backup-slm:
        schedule: "0 1 2 3 4 ?"
        name: "<production-snap-{now/d}>"
        repository: backup-repo
        config:
          indices: ["*"]
          ignore_unavailable: true
          include_global_state: false
        retention:
          expire_after: "7d"
          min_count: 1
          max_count: 20

The above Stack Configuration Policy will enforce a repository configuration and SLM policy configuration for all of the Elasticsearch clusters managed by ECK. Notice that the policy uses the same parameters that are required by the Elasticsearch API to define the SLM policy and repository, only in a YAML format instead of a JSON one. Policy syntax for the objects supported is identical to the equivalent Elasticsearch API syntax.

There are several ways to control which clusters a policy is enforced upon. 

Policy enforcement

When a Stack Configuration Policy is deployed to the operator namespace, all Elasticsearch clusters in all namespaces will be enforced with the policy. 

When you deploy a Stack Configuration Policy in a namespace other than the operators namespace, the policy will be enforced only for clusters in that namespace.

The feature also supports resource-selector based enforcement, and as such, you can add the resourceSelector and matchLabel configuration, for the policy to be enforced on any Elasticsearch cluster object with a specific label like so:

apiVersion: stackconfigpolicy.k8s.elastic.co/v1alpha1
kind: StackConfigPolicy
metadata:
  name: label-enforced-policy
  Namespace: my-namespace
spec:
  resourceSelector:
    matchLabels:
      env: my-label
  …

Once a policy is deleted, the configuration element associated with it will be deleted from the clusters associated with it as well. 

Get started

To get started with ECK and Stack Configuration Policies, download Elastic Cloud on Kubernetes 2.6.1 now.

Sign up for Elastic Cloud free trial

Spin up a fully loaded deployment on the cloud provider you choose. As the company behind Elasticsearch, we bring our features and support to your Elastic clusters in the cloud.

Start free trial