AWS Fargate allows users to run containerized applications without thinking about their underlying infrastructure. Serverless container adoption has continued to grow across clouds, and Fargate accounts for the majority of this type of workload within AWS. With Amazon Elastic Kubernetes Service (EKS), users have the option to seamlessly manage their infrastructure with AWS Fargate instead of manually provisioning EC2 worker nodes.

Datadog integrates with Amazon EKS on AWS Fargate, so you can automatically collect metrics and get deep visibility into your environment. This integration also includes support for Autodiscovery, so the Datadog Agent can immediately detect applications running in your cluster and collect monitoring data from them. You can also configure Datadog APM to collect distributed traces from applications running on Amazon EKS to monitor the performance of those applications in real time.

In this post, we’ll show you an example of how you can deploy the Datadog Agent to get visibility into an application that runs on Amazon EKS using AWS Fargate.

Deploy Datadog on Amazon EKS on AWS Fargate

AWS Fargate abstracts away the underlying infrastructure of Amazon EKS and provides on-demand compute capacity for containers. So instead of deploying the Datadog Agent to your nodes, as you would in a regular Kubernetes cluster, you’ll need to run the Datadog Agent as a sidecar container in each pod to ensure that all your pods are monitored. If you’re running a mixed Amazon EKS cluster, with some pods running on AWS Fargate and some pods running on Amazon EC2 instances, you should still deploy the Agent as a DaemonSet to the EC2 instances.

You will also need to set up role-based access control (RBAC) in Amazon EKS so that the Datadog Agent can query the Kubernetes API for monitoring data; see the documentation for full details on setting up the Datadog service account, ClusterRole, and ClusterRoleBinding. If your application also utilizes RBAC, you’ll need to ensure that the Agent container and your application containers have all the permissions they need, for example, by creating a ClusterRoleBinding that links your application’s service account with the Agent’s ClusterRole, or by adding the Datadog Agent’s required permissions to the ClusterRole associated with your application’s service account.

To start monitoring your application pods running on AWS Fargate instances, you can install the Datadog Cluster Agent by using Datadog Helm chart v3.59.1 or later. First, you’ll need to create a secret in the datadog-agent and application (here, fargate) namespaces by running the following commands:

kubectl create secret generic datadog-secret -n datadog-agent --from-literal api-key='<API_KEY>'  --from-literal token='<TOKEN>'
kubectl create secret generic datadog-secret -n fargate --from-literal api-key='<API_KEY>'  --from-literal token='<TOKEN>'

Specifying an API_KEY enables the Cluster Agent and Agent sidecar to communicate with Datadog endpoints. TOKEN is required for communication between Cluster Agent and Agent sidecars. See our documentation for more details.

Next, use the following command to install the Datadog Cluster Agent with the admission controller sidecar injection feature enabled and with the provider set to fargate. To install the Agent as a DaemonSet on the nodes in a mixed Amazon EKS cluster, you would need to set agents.enabled to true.

helm install datadog datadog/datadog -n datadog-agent \
    --set datadog.clusterName=cluster-name \
    --set agents.enabled=false \
    --set datadog.apiKeyExistingSecret=datadog-secret \
    --set clusterAgent.tokenExistingSecret=datadog-secret \
    --set clusterAgent.admissionController.agentSidecarInjection.enabled=true \
    --set clusterAgent.admissionController.agentSidecarInjection.provider=fargate

Once the installation succeeds and the Cluster Agent pods are running, the admission controller will inject Agent sidecars in all pods matching the agent.datadoghq.com/sidecar:fargate label.

The following example creates a Redis Deployment. Every pod started by the Deployment will have a Datadog Agent sidecar added automatically, allowing you to get end-to-end visibility into their performance—without changing or rebuilding your application.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: redis
 namespace: fargate
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: redis
       agent.datadoghq.com/sidecar: "fargate"
     name: redis
     annotations:
       ad.datadoghq.com/redis.check_names: '["redisdb"]'
       ad.datadoghq.com/redis.init_configs: '[{}]'
       ad.datadoghq.com/redis.instances: |
         [
           {
             "host": "%%host%%",
             "port": "6379"
           }
         ]
   spec:
     serviceAccountName: datadog-agent
     containers:
     - name: redis
       image: redis:latest
       args:
         - "redis-server"
       ports:
       - containerPort: 6379

In this example, we’ve added pod annotations to configure Autodiscovery, which means the Agent will automatically run a check on the Redis container in the same pod.

This method automatically deploys Datadog’s Cluster Agent on Amazon EKS on AWS Fargate. The Cluster Agent will run on a single pod and collect events from the API server. It will also complete cluster checks if you’ve configured any (e.g., if you’d like to run an HTTP check to monitor the latency of an NGINX-backed service).

The admission controller provides an automated way to monitor new workloads or adjust the configuration of the workloads you’re already monitoring with Datadog (e.g., if you need to update the version of the Agent). Instead of manually updating each resource manifest and adding a sidecar, you can simply add the agent.datadoghq.com/sidecar:fargate label to the workload you want to monitor and let the admission controller inject the Datadog Agent sidecar upon pod creation. This ensures that you can easily deploy the Agent to your workloads without updating a separate resource manifest for each of your workloads.

With more advanced settings, you can gain more granular control of which pods get Agent sidecar injection. You will also have the ability to configure Agent features, version, and resource usage. See our documentation for more details.

To monitor any of the AWS services you’re running alongside Amazon EKS on AWS Fargate, such as Application Load Balancer, make sure you enable our AWS integration if you haven’t done so already.

Monitor Amazon EKS on AWS Fargate with Datadog

Once you’ve deployed the Agent to your application running on Amazon EKS on AWS Fargate, you should see Kubernetes metrics appear in Datadog, along with data from services detected via Autodiscovery (e.g., Redis in the example above). Although Datadog can collect host-level metrics from any EKS nodes that aren’t managed by Fargate, you won’t see any system-level metrics from any of your Fargate-provisioned “hosts” because AWS manages that infrastructure for you.

This integration includes standard Kubernetes and Docker tags (e.g., docker_image, pod_name, kube_deployment) that you can use to filter for any subset of your container infrastructure. If you want to leverage any custom tags, you can configure the sidecar with a DD_TAGS environment variable. For more details on how to configure the sidecar profile, see our documentation.

Deep visibility, right out of the gate

With Amazon EKS on AWS Fargate, teams can spend more time developing their container applications, and less time managing the underlying infrastructure. To learn more about running Amazon EKS pods on AWS Fargate, check out the official documentation. And see our in-depth guides for Amazon EKS monitoring and AWS Fargate monitoring for more information.

We’re pleased to provide real-time visibility into your dynamic container environments, regardless of how they’re managed or where they’re running. If you’re already a Datadog customer, consult our documentation to learn how to get started. Otherwise, sign up for a free trial.