New and notableedit
New and notable changes in version 1.1.0 of Elastic Cloud on Kubernetes. See Elastic Cloud on Kubernetes version 1.1.0 for the full list of changes.
Remote cluster supportedit
Establishing uni-directional connections from ECK-managed Elasticsearch clusters to other Elasticsearch clusters for cross-cluster replication and cross-cluster search purposes is now easy to achieve through a few additions to the YAML manifest. This feature is available for all managed clusters running a supported version of Elasticsearch with an Enterprise or Enterprise trial licence.
Declarative user managementedit
File realm users and roles are now configurable using Kubernetes secrets. This enables consistent and auditable user management practices and GitOps use cases.
Validation has been extended to more ECK resource types to catch invalid configurations during admission. Enabling the validating webhook will extend the capabilities of ECK to catch most common configuration issues during update operations as well.
Enforce RBAC on associationsedit
Access control policies can be enforced on cross-namespace Elasticsearch associations created by Kibana and APM Server instances. This feature is disabled by default to avoid breaking existing deployments. See Restrict cross-namespace resource associations for more information.
Filebeat discovery hintsedit
ECK resources have the correct discovery hints added by default to facilitate Filebeat discovery.
Default container registry for air-gapped installationsedit
The default container registry used by the operator can be configured to ease deployments in air-gapped environments. When the container registry is correctly configured, users no longer need to specify the container image field in their manifests.
Removal of operator rolesedit
The concept of
namespace operator roles no longer exists, and as such, the
--operator-roles flag has been removed. Instead, you can configure the operator to manage a pre-defined set of namespaces by passing a comma-separated list of namespaces to the
--namespaces flag (default behaviour is to manage all namespaces). Instead of the
webhook role, use the dedicated
--enable-webhook flag to manage the webhook. See Configure ECK for more information about operator configuration flags.
Container port name changeedit
Container ports of managed resources are now named according to the protocol (
https for TLS enabled ports and
http for TLS disabled ports). Previously they were named
http regardless of the protocol being used. If you have any configurations that refer to the container ports by name (Ingress configurations, for example), review those to ensure that they use the correct name. One option may be to temporarily change to targeting the port number (e.g.
9200 for Elasticsearch), rather than the name, before updating ECK. Once the container port is updated to the new name, you can change to targeting the port name again.
Readiness probe change for Kibana and APM Serveredit
Default readiness probes generated by the operator for Kibana and APM Server resources have changed from HTTP GET actions to exec actions. This is to accommodate environments where host-to-pod communication is restricted for security reasons. This change will affect ingress resources that are used to expose Kibana or APM Server, as some ingress controllers re-purpose the pod readiness probe as a health check. If you are unable to access Kibana or APM Server through the ingress after upgrading to ECK 1.1.0, override the readiness probe definitions as follows:
apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: quickstart spec: version: 8.5.3 count: 1 elasticsearchRef: name: quickstart podTemplate: spec: containers: - name: kibana readinessProbe: httpGet: scheme: HTTPS path: "/login" port: 5601
apiVersion: apm.k8s.elastic.co/v1 kind: ApmServer metadata: name: quickstart spec: version: 8.5.3 count: 1 elasticsearchRef: name: quickstart podTemplate: spec: containers: - name: apm-server readinessProbe: httpGet: scheme: HTTPS path: "/" port: 8200
ECK versions prior to 1.1.0 generate Elasticsearch passwords using a weak random number generator. If an attacker is able to determine when an Elasticsearch cluster was deployed, they may be able to more easily brute force the Elasticsearch credentials generated by ECK. For existing clusters, we recommend users regenerate credentials following the steps detailed here. Resources created by ECK 1.1.0 do not require any action.