This documentation contains work-in-progress information for future Elastic Stack and Cloud releases. Use the version selector to view supported release docs. It also contains some Elastic Cloud serverless information. Check out our serverless docs for more details.

« 1.4.1 release highlights 1.3.2 release highlights »

› ›

1.4.0 release highlights

edit

1.4.0 release highlights

edit

New and notable

edit

New and notable changes in version 1.4.0 of Elastic Cloud on Kubernetes. Check Elastic Cloud on Kubernetes version 1.4.0 for the full list of changes.

Support for Elastic Agent

edit

Elastic Agent provides a unified way to monitor logs, metrics, and other types of data from your Kubernetes infrastructure quickly and easily. You can use a single Elastic Agent deployment to replace multiple Beats deployments that were previously required to collect the different types of data you want to monitor. ECK 1.4.0 introduces experimental support for Elastic Agent in standalone mode as a technology preview.

Known issues

edit

On Kubernetes version 1.16 or higher, if the operator is installed using Helm and if the validating webhook is enabled, you might be prevented from increasing the storage size of Elasticsearch volumeClaimTemplates even if the underlying storage class allows expansion. This is due to a change in how admissionregistration.k8s.io/v1 resources match update requests to validating webhook endpoints. As a workaround, you can patch the validating webhook as follows:

# If you installed using the Helm defaults, the name of the webhook would be elastic-operator.elastic-system.k8s.elastic.co
# If the operator name or namespace was changed during the installation, the name would reflect those changes.
WEBHOOK=$(kubectl get validatingwebhookconfiguration --no-headers -o custom-columns=NAME:.metadata.name | grep 'k8s.elastic.co')
kubectl patch validatingwebhookconfiguration "$WEBHOOK" \
    --patch='{"webhooks": [{"name": "elastic-es-validation-v1.k8s.elastic.co", "matchPolicy": "Exact"}, {"name": "elastic-es-validation-v1beta1.k8s.elastic.co", "matchPolicy": "Exact"}]}'

Elastic Agent currently writes its runtime state into the filesystem of its container. As a consequence, the identity of the Elastic Agent changes on container restarts and any internal state of applications run by that Elastic Agent is lost. As a workaround, you can mount the agent-data hostPath volume into the Elastic Agent container in the location where the process writes its runtime state. You also have to run the Elastic Agent as the root user to be able to access the hostPath volume, as shown in the following example:

apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
  name: elastic-agent
spec:
  version: 7.11.1
  daemonSet:
    podTemplate:
      spec:
        containers:
        - name: agent
          securityContext:
            runAsUser: 0
          volumeMounts:
          - name: agent-data
            mountPath: /usr/share/elastic-agent/data/elastic-agent-9b2fec/run

The mountPath differs from version to version as it contains the hash of the version control system reference which was used to build Elastic Agent. You can find out which path to use by either inspecting the Docker image, or by running a command against the container:

docker run -ti --entrypoint bash docker.elastic.co/beats/elastic-agent:7.11.1 -c "ls /usr/share/elastic-agent/data"

« 1.4.1 release highlights 1.3.2 release highlights »