1.0.0-beta1 release highlightsedit

StatefulSetsedit

ECK now uses StatefulSets under the hood to orchestrate Elasticsearch clusters. Prior to 1.0.0-beta1, upgrading a cluster storing large volumes of data could take hours or even days because data had to be replicated to newly created Elasticsearch nodes. With StatefulSets, you can simply reuse persistent volumes and significantly reduce the time and resources used to upgrade an Elasticsearch cluster. See Nodes orchestration for more detail.

Resource version promotionedit

Custom resources have graduated to version v1beta1. Old resources must be migrated to the new version to work with ECK 1.0.0-beta1. Resources created using an older version will continue to run but the operator will not manage them. To receive all the benefits of ECK 1.0.0-beta1, we recommend deleting old custom resources and recreating them. See Upgrade ECK for more information.

Validation changesedit

OpenAPI validation of resources on admission is no longer enforced on Kubernetes versions 1.13 or lower. This is due to a limitation in older versions of Kubernetes where multiple versions for CRDs are not supported.

Webhook validation has also temporarily been removed from this release. It is currently being reworked.

More control over TLS settingsedit

Users have more control over TLS settings of the Elasticsearch HTTP layer, Kibana, and APM Server in this release. It is now possible to use external certificates from well-known CAs, utilities like cert-manager, or even completely disable automatic provisioning of TLS certificates. The latter can be useful when TLS is handled at a different layer, for instance, with Istio deployments. See: Setup your own certificate and Disable TLS.

Secure settings enhancementsedit

Secure settings have received multiple ergonomics improvements. It is now possible to specify secure settings from mutiple secrets. It is also possible to specify specific items in a Kubernetes secret to be used as a secure setting, rather than having to use all items in a secret.

Default limitsedit

Default limits are now set for the various resource types if none are explicitly specified. Previously, if left at the default, Pods would consume unbounded amounts of memory, which could lead them to be OOM killed. This allows for a better experience in demo scenarios. We recommend in production that both requests and limits be set appropriately. See Manage compute resources for more information.

Breaking Changesedit

The 1.0.0-beta version of the operator does not delete resources created by older versions of the operator, but it also does not manage them. Attempting to delete resources created with a 0.9.0 version will hang if ECK 1.0.0-beta1 is running. Please see the upgrading documentation for more information.

Known Issuesedit

The following are known issues that will be addressed in the next release:

Native realm disablededit

The native realm is incorrectly disabled by default. Users can reenable the native realm by adding it to the realm chain in their Elasticsearch configuration (#2037)

Memory leak in the ECK processedit

The operator process is slowly leaking memory which will eventually lead to an out of memory situation and a restart of the operator process. The operator is designed to be resilient to restarts and will resume functioning once it is restarted. Managed resources (Elasticsearch, Kibana and APM Server) are not affected. There is no workaround. (#1984)

ECK restarts when using non-default change budgetedit

When using a non-default change budget with maxUnavailable set to a value greater than 1 to manage an Elasticsearch cluster with dedicated master nodes, the process will continuously crash with a nil pointer dereference related panic and restart. There is no workaround other than using the default change budget. (#2034)