Known limitations

Until version 7.14.0 and ECK version 2.10.0, Elastic Agent and Fleet Server were required to run as root.

As of Elastic Stack version 7.14.0 and ECK version 2.10.0 it is also possible to run Elastic Agent and Fleet as a non-root user. See Storing local state in host path volume for instructions.

Until ECK version 2.11.0, Elastic Agent and Fleet Server were required to run within the same Namespace as Elasticsearch.

As of ECK version 2.11.0, Elastic Agent, Fleet Server and Elasticsearch can all be deployed in different Namespaces.

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.

When deployed with ECK, the Fleet Server Pod makes an HTTP call to itself during Fleet initialization using its Service. Since a Pod cannot reach itself through its Service on minikube when CNI is disabled, the call hangs until the connection times out and the Pod enters a crash loop.

Solution: enable CNI when starting minikube: minikube start --cni=true.

Elastic Agent managed by ECK stores local state in a host path volume by default. 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. Consider the following options for managing local state storage:

• If local state storage in hostPath volumes is not desired this can be turned off by configuring an emptyDir volume instead.
• Stack 8.16+ The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability Generally available since 8.16 This functionality is generally available and ready for production usage. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes. If local state storage is still desired but running the Agent container as root is not allowed, then you can give the Agent container the CHOWN and SETPCAP capabilities. At startup, Elastic Agent changes the owner of its state directory to its own user and group.
• If you use an Elastic Agent version before 8.16 or cannot grant additional capabilities to the Agent container, you can use a DaemonSet to adjust the permissions of the Agent local state on each node before Elastic Agent starts. This DaemonSet must run as root (runAsUser: 0) and might also require privileged: true. Also note the Kibana changes required to trust the Elasticsearch CA when running in fleet mode.

Full configuration examples exist in Running as a non-root user.

Two Elastic Agent Pods on the same Kubernetes node cannot use the same host path at the same time. The second Pod stops with the error failed to get app lock: another elastic-agent is already running. This happens in two cases:

• You deploy Elastic Agent as a Deployment with more than one replica, and Kubernetes schedules two replicas on the same node.
• You update a Deployment that has one replica, for example to change resources. By default, a Deployment uses the RollingUpdate strategy. The strategy starts the new Pod before it stops the old Pod. If both Pods run on the same node, the new Pod fails until the old Pod stops.

To avoid the error, use one of these options:

1. Deploy Elastic Agent as a DaemonSet. A DaemonSet runs one Pod on each node.

2. For a Deployment with one replica, set the update strategy to Recreate so that Kubernetes stops the old Pod before starting the new one. The Elastic Agent is not available during the update.

   apiVersion: agent.k8s.elastic.co/v1alpha1
   kind: Agent
   metadata:
     name: elastic-agent
   spec:
     deployment:
       replicas: 1
       strategy:
         type: Recreate
   ...
   

3. For a Deployment with more than one replica, add a podAntiAffinity rule to prevent two replicas from running on the same node. Make sure that the cluster has more available nodes than replicas. Otherwise, a Pod stays in the Pending state.

   apiVersion: agent.k8s.elastic.co/v1alpha1
   kind: Agent
   metadata:
     name: elastic-agent
   spec:
     deployment:
       replicas: 2
       podTemplate:
         spec:
           affinity:
             podAntiAffinity:
               requiredDuringSchedulingIgnoredDuringExecution:
               - labelSelector:
                   matchLabels:
                     agent.k8s.elastic.co/name: elastic-agent
                 topologyKey: kubernetes.io/hostname
   ...
   

   1. Use the name of the Elastic Agent resource.

4. Use an emptyDir volume instead of the host path volume. Elastic Agent then does not keep its local state when a Pod restarts. This option is not recommended. Refer to Storing local state in host path volume.