Known limitationsedit

Running as root and within a single namespaceedit

Elastic Agent in Fleet mode has to run as root, and in the same namespace as the Elasticsearch cluster it connects to.

Due to current configuration limitations on Fleet/Elastic Agent side, ECK needs to establish trust between Elastic Agents and Elasticsearch. ECK can fetch the required Elasticsearch CA correctly if both resources are in the same namespace. To establish trust, the Pod needs to update the CA store through a call to update-ca-trust before Elastic Agent runs. To call it successfully, the Pod needs to run with elevated privileges.

Running Endpoint Security integrationedit

Running Endpoint Security integration is not yet supported in containerized environments, like Kubernetes. This is not an ECK limitation, but the limitation of the integration itself. Note that you can use ECK to deploy Elasticsearch, Kibana and Fleet Server, and add Endpoint Security integration to your policies if Elastic Agents running those policies are deployed in non-containerized environments.

Storing local state in host path volumeedit

Elastic Agent when managed by ECK stores local state in a host path volume. This ensures that integrations run by the agent can continue their work without duplicating work that has already been done after the Pod has been recreated for example because of a Pod configuration change. Multiple replicas of an agent, for example Fleet Servers, can not be deployed on the same underlying Kubernetes node as they would try to use the same host path. If local state storage in host path volumes is not desired this can be turned off by configuring an emptyDir volume instead:

kind: Agent
  name: fleet-server
    replicas: 3
        - name: agent-data
          emptyDir: {}