From b1f1d30b0948af1b48d8955514092baff37c8812 Mon Sep 17 00:00:00 2001 From: JacksonDavenport Date: Fri, 18 Apr 2025 16:55:05 -0700 Subject: [PATCH 1/4] Structural changes to order, pre-reqs (profile,keys,rbac), and add troubleshooting auth command --- eks_fargate/README.md | 190 ++++++++++++++++++++++++------------------ 1 file changed, 107 insertions(+), 83 deletions(-) diff --git a/eks_fargate/README.md b/eks_fargate/README.md index 633142ef271b9..5403c8f322a69 100644 --- a/eks_fargate/README.md +++ b/eks_fargate/README.md @@ -7,59 +7,48 @@ Amazon EKS on AWS Fargate is a managed Kubernetes service that automates certain aspects of deployment and maintenance for any standard Kubernetes environment. Kubernetes nodes are managed by AWS Fargate and abstracted away from the user. -**Note**: Cloud Network Monitoring (CNM) is not supported for EKS Fargate. - -## Setup - These steps cover the setup of the Datadog Agent v7.17+ in a container within Amazon EKS on AWS Fargate. See the [Datadog-Amazon EKS integration documentation][2] if you are not using AWS Fargate. AWS Fargate pods are not physical pods, which means they exclude [host-based system-checks][3], like CPU, memory, etc. In order to collect data from your AWS Fargate pods, you must run the Agent as a sidecar of your application pod with custom RBAC, which enables these features: +If the Agent is running as a sidecar, it can communicate only with containers on the same pod. Run an Agent for every pod you wish to monitor. + - Kubernetes metrics collection from the pod running your application containers and the Agent - [Autodiscovery][4] - Configuration of custom Agent Checks to target containers in the same pod - APM and DogStatsD for containers in the same pod -### EC2 Node - -If you don't specify through [AWS Fargate Profile][5] that your pods should run on fargate, your pods can use classical EC2 machines. If it's the case see the [Datadog-Amazon EKS integration setup][6] in order to collect data from them. This works by running the Agent as an EC2-type workload. The Agent setup is the same as that of the [Kubernetes Agent setup][7], and all options are available. To deploy the Agent on EC2 nodes, use the [DaemonSet setup for the Datadog Agent][8]. - -### Installation +**Note**: Cloud Network Monitoring (CNM) is not supported for EKS Fargate. -To get the best observability coverage monitoring workloads in Amazon EKS Fargate, install the Datadog integrations for: +## Prerequisites +### Fargate Profile -- [Kubernetes][9] -- [AWS][10] -- [EKS][11] -- [EC2][12] (if you are running an EC2-type node) +If you don't specify through [AWS Fargate Profile][5] that your pods should run on fargate, your pods can use classical EC2 machines. If it's the case see the [Datadog-Amazon EKS integration setup][6] in order to collect data from them. This works by running the Agent as an EC2-type workload. The Agent setup is the same as that of the [Kubernetes Agent setup][7], and all options are available. To deploy the Agent on EC2 nodes, use the [DaemonSet setup for the Datadog Agent][8]. -Also, set up integrations for any other AWS services you are running with EKS (for example, [ELB][13]). +### Keys and Tokens -#### Manual installation +Create a Kubernetes secret `datadog-secret` containing your Datadog API key and Cluster Agent token in the Datadog installation and application namespaces: -To install, download the custom Agent image: `datadog/agent` with version v7.17 or above. + ```shell + kubectl create secret generic datadog-secret -n datadog-agent \ + --from-literal api-key= --from-literal token= + kubectl create secret generic datadog-secret -n fargate \ + --from-literal api-key= --from-literal token= + ``` -If the Agent is running as a sidecar, it can communicate only with containers on the same pod. Run an Agent for every pod you wish to monitor. +For more information how these secrets are used, see the [Cluster Agent Setup][35]. -### Configuration +**Note**: You cannot change the name of the secret containing the Datadog API key and Cluster Agent token. It must be `datadog-secret` for the Agent in the sidecar to connect to Datadog when using the automatic injection methods. -To collect data from your applications running in Amazon EKS Fargate over a Fargate node, follow these setup steps: +### Amazon EKS Fargate RBAC -- [Set up Amazon EKS Fargate RBAC rules](#amazon-eks-fargate-rbac). -- [Deploy the Agent as a sidecar](#running-the-agent-as-a-sidecar). -- Set up Datadog [metrics](#metrics-collection), [logs](#log-collection), [events](#events-collection), and [traces](#traces-collection) collection. - -To have EKS Fargate containers in the Datadog Live Container View, enable `shareProcessNamespace` on your pod spec. See [Process Collection](#process-collection). - -#### Amazon EKS Fargate RBAC - -Use the following Agent RBAC when deploying the Agent as a sidecar in Amazon EKS Fargate: +Create a `ClusterRole` using the following RBAC for necessary sidecar Agent permissions: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: - name: datadog-agent + name: datadog-agent-fargate rules: - apiGroups: - "" @@ -81,15 +70,21 @@ rules: - nodes/healthz verbs: - get ---- +``` + +After creating this `ClusterRole` you must create a `ClusterRoleBinding` to attach this to the namespaced `ServiceAccount` that your pods are using. This `ClusterRoleBinding` below references this previously created `ClusterRole`. + +If your pods do not currently use a `ServiceAccount` you can create one like the following. + +```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: - name: datadog-agent + name: datadog-agent-fargate roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole - name: datadog-agent + name: datadog-agent-fargate subjects: - kind: ServiceAccount name: datadog-agent @@ -102,7 +97,53 @@ metadata: namespace: default ``` -#### Running the Agent as a sidecar +This creates a ServiceAccount `datadog-agent` in the `default` namespace which can be used in your pods in the `default` namespace. Adjust this for your desired namespace. + +If you are using multiple ServiceAccounts across namespaces this can be updated to your environment like so: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: datadog-agent-fargate +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: datadog-agent-fargate +subjects: + - kind: ServiceAccount + name: + namespace: + - kind: ServiceAccount + name: + namespace: + - kind: ServiceAccount + name: + namespace: +``` + +## Setup + +### Installation + +To get the best observability coverage monitoring workloads in Amazon EKS Fargate, install the Datadog integrations for: + +- [Kubernetes][9] +- [AWS][10] +- [EKS][11] +- [EC2][12] (if you are running an EC2-type node) + +Also, set up integrations for any other AWS services you are running with EKS (for example, [ELB][13]). + +To collect data from your applications running in Amazon EKS Fargate over a Fargate node, follow these setup steps: + +- [Set up Amazon EKS Fargate RBAC rules](#amazon-eks-fargate-rbac). +- [Deploy the Agent as a sidecar](#running-the-agent-as-a-sidecar). +- Set up Datadog [metrics](#metrics-collection), [logs](#log-collection), [events](#events-collection), and [traces](#traces-collection) collection. + +To have EKS Fargate containers in the Datadog Live Container View, enable `shareProcessNamespace` on your pod spec. See [Process Collection](#process-collection). + +### Running the Agent as a sidecar You can run the Agent as a sidecar by using the [Datadog Admission Controller][36] (requires Cluster Agent v7.52+) or with manual sidecar configuration. With the Admission Controller, you can inject an Agent sidecar into every pod that has the label `agent.datadoghq.com/sidecar:fargate`. @@ -110,30 +151,14 @@ With manual configuration, you must modify every workload manifest when adding o -##### Admission Controller using Datadog Operator +### Admission Controller using Datadog Operator
This feature requires Cluster Agent v7.52.0+, Datadog Operator v1.7.0+, and the EKS Fargate integration.
The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. -**Prerequisites** - -* Set up RBAC in the application namespace(s). See the [Amazon EKS Fargate RBAC](#amazon-eks-fargate-rbac) section on this page. -* Bind above RBAC to application pod by setting Service Account name. -* Create a Kubernetes secret `datadog-secret` containing your Datadog API key and Cluster Agent token in the Datadog installation and application namespaces: - - ```shell - kubectl create secret generic datadog-secret -n datadog-agent \ - --from-literal api-key= --from-literal token= - kubectl create secret generic datadog-secret -n fargate \ - --from-literal api-key= --from-literal token= - ``` - For more information how these secrets are used, see the [Cluster Agent Setup][35]. - -**Note**: You cannot change the name of the secret containing the Datadog API key and Cluster Agent token. It must be `datadog-secret` for the Agent in the sidecar to connect to Datadog. - -###### Setup +#### Standard injection setup 1. Create a `DatadogAgent` custom resource in the `datadog-agent.yaml` with Admission Controller enabled: @@ -202,7 +227,7 @@ The setup below configures the Cluster Agent to communicate with the Agent sidec memory: 256Mi {{< /highlight >}} -###### Sidecar profiles and custom selectors +##### Sidecar profiles and custom selectors To further configure the Agent or its container resources, use the properties in your `DatadogAgent` resource. Use the `spec.features.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. Use the `spec.features.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target workload pods instead of updating the workload to add `agent.datadoghq.com/sidecar:fargate` labels. @@ -284,30 +309,14 @@ To further configure the Agent or its container resources, use the properties in -##### Admission Controller using Helm +### Admission Controller using Helm
This feature requires Cluster Agent v7.52.0+.
The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. -**Prerequisites** - -* Set up RBAC in the application namespace(s). See the [Amazon EKS Fargate RBAC](#amazon-eks-fargate-rbac) section on this page. -* Bind above RBAC to application pod by setting Service Account name. -* Create a Kubernetes secret `datadog-secret` containing your Datadog API key and Cluster Agent token in the Datadog installation and application namespaces: - - ```shell - kubectl create secret generic datadog-secret -n datadog-agent \ - --from-literal api-key= --from-literal token= - kubectl create secret generic datadog-secret -n fargate \ - --from-literal api-key= --from-literal token= - ``` - For more information how these secrets are used, see the [Cluster Agent Setup][35]. - -**Note**: You cannot change the name of the secret containing the Datadog API key and Cluster Agent token. It must be `datadog-secret` for the Agent in the sidecar to connect to Datadog. - -###### Setup +#### Standard injection setup 1. Create a file, `datadog-values.yaml`, that contains: @@ -371,7 +380,7 @@ The following is a `spec.containers` snippet from a Redis deployment where the A memory: 256Mi {{< /highlight >}} -###### Sidecar profiles and custom selectors +##### Sidecar profiles and custom selectors To further configure the Agent or its container resources, use the Helm property `clusterAgent.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. Use the `clusterAgent.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target workload pods instead of updating the workload to add `agent.datadoghq.com/sidecar:fargate` labels. @@ -459,7 +468,7 @@ containers: -##### Manual +### Manual To start collecting data from your Fargate type pod, deploy the Datadog Agent v7.17+ as a sidecar of your application. This is the minimum configuration required to collect metrics from your application running in the pod, notice the addition of `DD_EKS_FARGATE=true` in the manifest to deploy your Datadog Agent sidecar. @@ -516,7 +525,7 @@ spec: **Note**: Add your desired `kube_cluster_name:` to the list of `DD_TAGS` to ensure your metrics are tagged by your desired cluster. You can append additional tags here as space separated `:` tags. For Agents `7.34+` and `6.34+`, this is not required. Instead, set the `DD_CLUSTER_NAME` environment variable. -###### Running the Cluster Agent or the Cluster Checks Runner +#### Running the Cluster Agent or the Cluster Checks Runner Datadog recommends you run the Cluster Agent to access features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. @@ -570,11 +579,6 @@ In both cases, you need to change the Datadog Agent sidecar manifest in order to - -## Cluster performance - -For insights into your EKS cluster performance, enable a [Cluster Check Runner][34] to collect metrics from the [`kube-state-metrics`][33] service. - ## Metrics collection ### Integration metrics @@ -807,7 +811,7 @@ Optionally, deploy cluster check runners in addition to setting up the Datadog C For Agent 6.19+/7.19+, [Process Collection][26] is available. Enable `shareProcessNamespace` on your pod spec to collect all processes running on your Fargate pod. For example: -``` +```yaml apiVersion: v1 kind: Pod metadata: @@ -823,18 +827,38 @@ spec: ### Metrics -The eks_fargate check submits a heartbeat metric `eks.fargate.pods.running` that is tagged by `pod_name` and `virtual_node` so you can keep track of how many pods are running. +The `eks_fargate` check submits a heartbeat metric `eks.fargate.pods.running` that is tagged by `pod_name` and `virtual_node` so you can keep track of how many pods are running. ### Service Checks -eks_fargate does not include any service checks. +The `eks_fargate` check does not include any service checks. ### Events -eks_fargate does not include any events. +The `eks_fargate` check does not include any events. ## Troubleshooting +### ServiceAccount Kubelet permissions + +****TBD + +Ensure you have the right permissions on the ServiceAccount associated with your pod. If your pod does not have a ServiceAccount associated with it, or, it isn't bound to the correct ClusterRole it won't have access to Kubelet. + +This can be validated with a command like: + +```shell +kubectl auth can-i get nodes/pods --as system:serviceaccount:: +``` + +For example if your Fargate pod is in the `fargate` namespace with the ServiceAccount `datadog-agent`: +```shell +kubectl auth can-i get nodes/pods --as system:serviceaccount:fargate:datadog-agent +``` + +This will return `yes` or `no` based on the access. + + ### Datadog Agent Container Security Context The Datadog Agent container is designed to run as the dd-agent user (UID: 100). If you override the default security context by setting, for example, `runAsUser: 1000` in your pod spec, the container fails to start due to insufficient permissions. You may see errors such as: From c066d4c5d79ca8bcf585f4344c1c42d29c2beda1 Mon Sep 17 00:00:00 2001 From: JacksonDavenport Date: Wed, 23 Apr 2025 17:42:55 -0700 Subject: [PATCH 2/4] Clarify context, prereqs, and agent sidecar setup --- eks_fargate/README.md | 799 +++++++++++++++++++++++------------------- 1 file changed, 432 insertions(+), 367 deletions(-) diff --git a/eks_fargate/README.md b/eks_fargate/README.md index 5403c8f322a69..72f0f8f9e3a21 100644 --- a/eks_fargate/README.md +++ b/eks_fargate/README.md @@ -5,44 +5,53 @@
This page describes the EKS Fargate integration. For ECS Fargate, see the documentation for Datadog's ECS Fargate integration.
-Amazon EKS on AWS Fargate is a managed Kubernetes service that automates certain aspects of deployment and maintenance for any standard Kubernetes environment. Kubernetes nodes are managed by AWS Fargate and abstracted away from the user. +Amazon EKS Fargate is a managed Kubernetes service that automates certain aspects of deployment and maintenance for any standard Kubernetes environment. The EKS Fargate nodes are managed by AWS Fargate and abstracted away from the user. -These steps cover the setup of the Datadog Agent v7.17+ in a container within Amazon EKS on AWS Fargate. See the [Datadog-Amazon EKS integration documentation][2] if you are not using AWS Fargate. +EKS Fargate pods not run on traditional EKS nodes and EC2 instances. While the Agent does report [system checks][3], like `system.cpu.*` and `system.memory.*`, these are just for the Agent container. In order to collect data from your AWS Fargate pods, run the Agent as a sidecar within *each* of your desired application pods. The pod needs to be deployed with custom RBAC granting permissions to the kubelet for the Agent to get the required information. -AWS Fargate pods are not physical pods, which means they exclude [host-based system-checks][3], like CPU, memory, etc. In order to collect data from your AWS Fargate pods, you must run the Agent as a sidecar of your application pod with custom RBAC, which enables these features: +The Agent can only monitor the other containers in the same pod as itself. It will also communicate with the Cluster Agent for some of its reporting. Overall the Agent can: -If the Agent is running as a sidecar, it can communicate only with containers on the same pod. Run an Agent for every pod you wish to monitor. +- Report Kubernetes metrics collection from the pod running your application containers and the Agent +- Run [Autodiscovery][4] based Agent integrations against the containers in the same pod +- Collect APM and DogStatsD metrics for containers in the same pod -- Kubernetes metrics collection from the pod running your application containers and the Agent -- [Autodiscovery][4] -- Configuration of custom Agent Checks to target containers in the same pod -- APM and DogStatsD for containers in the same pod +If you have a mixed cluster of traditional EKS Nodes and Fargate pods, you will manage the traditional Datadog Kubernetes installation with a Helm Chart or Datadog Operator, and then manage your EKS Fargate pods separately. **Note**: Cloud Network Monitoring (CNM) is not supported for EKS Fargate. ## Prerequisites -### Fargate Profile +### Fargate profile -If you don't specify through [AWS Fargate Profile][5] that your pods should run on fargate, your pods can use classical EC2 machines. If it's the case see the [Datadog-Amazon EKS integration setup][6] in order to collect data from them. This works by running the Agent as an EC2-type workload. The Agent setup is the same as that of the [Kubernetes Agent setup][7], and all options are available. To deploy the Agent on EC2 nodes, use the [DaemonSet setup for the Datadog Agent][8]. +Create and specify [AWS Fargate Profile][5] that your pods should run with to deploy your pods within EKS Fargate. -### Keys and Tokens +If you do not specify a Fargate Profile your pods use classical EC2 machines. To monitor these pods follow the traditional approach of setting up the [Datadog-Amazon EKS integration setup][6] and [Kubernetes Agent setup][7]. -Create a Kubernetes secret `datadog-secret` containing your Datadog API key and Cluster Agent token in the Datadog installation and application namespaces: +### Secret for keys and tokens - ```shell - kubectl create secret generic datadog-secret -n datadog-agent \ - --from-literal api-key= --from-literal token= - kubectl create secret generic datadog-secret -n fargate \ - --from-literal api-key= --from-literal token= - ``` +Create a Kubernetes secret `datadog-secret` containing your Datadog API key and a 32 character alphanumeric token for the Cluster Agent. If you are deploying your traditional Datadog installation in one namespace and the Fargate pods in a different namespace, create the secret in *each* Fargate namespace. + +For example: + ```shell + # Create the secret in the namespace:datadog-agent + kubectl create secret generic datadog-secret -n datadog-agent \ + --from-literal api-key= \ + --from-literal token= + + # Create the secret in the namespace:fargate + kubectl create secret generic datadog-secret -n fargate \ + --from-literal api-key= \ + --from-literal token= + ``` -For more information how these secrets are used, see the [Cluster Agent Setup][35]. +This token is used for the Agent / Cluster Agent communication. Creating it in advance ensures both the traditional setups and Fargate pod get the same token value (as opposed to letting the Helm Chart or Operator create a random token for you). For more information how this token is used, see the [Cluster Agent Setup][35]. **Note**: You cannot change the name of the secret containing the Datadog API key and Cluster Agent token. It must be `datadog-secret` for the Agent in the sidecar to connect to Datadog when using the automatic injection methods. ### Amazon EKS Fargate RBAC -Create a `ClusterRole` using the following RBAC for necessary sidecar Agent permissions: +This process involves creating a `ClusterRole` for the necessary permissions, and binding it to the `ServiceAccount` your pods are using. + +Create a `ClusterRole` using the following manifest for to provide the sidecar Agent the necessary permissions: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -72,9 +81,9 @@ rules: - get ``` -After creating this `ClusterRole` you must create a `ClusterRoleBinding` to attach this to the namespaced `ServiceAccount` that your pods are using. This `ClusterRoleBinding` below references this previously created `ClusterRole`. +After creating this `ClusterRole` create a `ClusterRoleBinding` to attach this to the namespaced `ServiceAccount` that your pods are currently using. The `ClusterRoleBindings` below reference this previously created `ClusterRole`. -If your pods do not currently use a `ServiceAccount` you can create one like the following. +If your pods do not currently use a `ServiceAccount` you can create a setup like the following. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -88,18 +97,18 @@ roleRef: subjects: - kind: ServiceAccount name: datadog-agent - namespace: default + namespace: fargate --- apiVersion: v1 kind: ServiceAccount metadata: name: datadog-agent - namespace: default + namespace: fargate ``` -This creates a ServiceAccount `datadog-agent` in the `default` namespace which can be used in your pods in the `default` namespace. Adjust this for your desired namespace. +This creates a `ServiceAccount` named `datadog-agent` in the `fargate` namespace that is referenced in the `ClusterRoleBinding`. Adjust this for your desired namespace of your Fargate pods and set this as the `serviceAccountName` in your pod spec. -If you are using multiple ServiceAccounts across namespaces this can be updated to your environment like so: +If you are using multiple `ServiceAccounts` across namespaces this can be updated to your environment like so: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -122,30 +131,26 @@ subjects: namespace: ``` +See the section below on [Troubleshooting: ServiceAccount Permissions](#serviceaccount-kubelet-permissions) for commands to validate your permission. + ## Setup -### Installation +Be sure to follow the prerequisite steps above for setting up your profile, secrets, and permissions prior to installing the Datadog Agent. -To get the best observability coverage monitoring workloads in Amazon EKS Fargate, install the Datadog integrations for: +If you have a mixed cluster of the traditional EKS nodes and Fargate pods you may want to first install the traditional [Agent in Kubernetes][7] using the above Secrets. As well as install the Datadog cloud integrations for [AWS][10]. -- [Kubernetes][9] -- [AWS][10] -- [EKS][11] -- [EC2][12] (if you are running an EC2-type node) -Also, set up integrations for any other AWS services you are running with EKS (for example, [ELB][13]). +### Installation -To collect data from your applications running in Amazon EKS Fargate over a Fargate node, follow these setup steps: +To collect data from your applications running in Amazon EKS Fargate over a Fargate node you will run the Agent as a sidecar. This can be done either manually or using the Datadog Admission Controller's automatic injection. This automatic injection requires the Cluster Agent to be running, and will automatically add the Agent sidecar to your desired pods. -- [Set up Amazon EKS Fargate RBAC rules](#amazon-eks-fargate-rbac). -- [Deploy the Agent as a sidecar](#running-the-agent-as-a-sidecar). -- Set up Datadog [metrics](#metrics-collection), [logs](#log-collection), [events](#events-collection), and [traces](#traces-collection) collection. +Both methods require you to set your RBAC and `serviceAccountName` in your pod manually. -To have EKS Fargate containers in the Datadog Live Container View, enable `shareProcessNamespace` on your pod spec. See [Process Collection](#process-collection). +After installation you can further configure the Agent for [Autodiscovery Integrations](#integration-metrics), [DogStatsD metrics](#dogstatsd), [Traces](#traces-collection), and [Process Collection](#process-collection). [Log collection](#log-collection) is supported in EKS Fargate, however is not managed by the Agent. ### Running the Agent as a sidecar -You can run the Agent as a sidecar by using the [Datadog Admission Controller][36] (requires Cluster Agent v7.52+) or with manual sidecar configuration. With the Admission Controller, you can inject an Agent sidecar into every pod that has the label `agent.datadoghq.com/sidecar:fargate`. +You can run the Agent as a sidecar by using the [Datadog Admission Controller][36] (requires Cluster Agent v7.52+) or with manual sidecar configuration. With the Admission Controller, you can inject an Agent sidecar into every pod that has the label `agent.datadoghq.com/sidecar: fargate`. With manual configuration, you must modify every workload manifest when adding or changing the Agent sidecar. Datadog recommends you use the Admission Controller. @@ -153,16 +158,18 @@ With manual configuration, you must modify every workload manifest when adding o ### Admission Controller using Datadog Operator -
This feature requires Cluster Agent v7.52.0+, Datadog Operator v1.7.0+, and the EKS Fargate integration. +
This feature requires Cluster Agent v7.52.0+, Datadog Operator v1.7.0+. .
-The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. +If you do not have the Datadog Operator already running see the [Operator install steps here][7]. + +The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [event collection][29], [Kubernetes resources view][30], and [cluster checks][31]. #### Standard injection setup -1. Create a `DatadogAgent` custom resource in the `datadog-agent.yaml` with Admission Controller enabled: +1. Create a `DatadogAgent` custom resource in the `datadog-agent.yaml` with Admission Controller injection and the fargate provider enabled: - ```yaml + ```yaml apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: @@ -181,134 +188,161 @@ The setup below configures the Cluster Agent to communicate with the Agent sidec agentSidecarInjection: enabled: true provider: fargate - ``` - Then apply the new configuration: + ``` + Then apply the new configuration based on your namespace - ```shell - kubectl apply -n datadog-agent -f datadog-agent.yaml - ``` + ```shell + kubectl apply -n datadog-agent -f datadog-agent.yaml + ``` -2. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any pod created with the label `agent.datadoghq.com/sidecar:fargate`. - **The Admission Controller does not mutate pods that are already created**. +2. After the Cluster Agent reaches a running state and registers Admission Controller's mutating webhooks add the label `agent.datadoghq.com/sidecar: fargate` to your desired pods (not the parent workload) to trigger the injection of the Datadog Agent sidecar container. -**Example result** - - The following is a `spec.containers` snippet from a Redis deployment where the Admission Controller injected an Agent sidecar. The sidecar is automatically configured using internal defaults, with additional settings to run in an EKS Fargate environment. The sidecar uses the image repository and tags set in `datadog-agent.yaml`. Communication between Cluster Agent and sidecars is enabled by default. +**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent will not connect to Kubernetes. + +##### Example standard injection result + +The following is output from a sample Redis Deployment's pod where the Admission Controller injected an Agent sidecar. The environment variables and resource settings are automatically applied based on the Datadog Fargate profile's internal default values. + +The sidecar uses the image repository and tags set in `datadog-agent.yaml`. Communication between Cluster Agent and sidecars is enabled by default. - {{< highlight yaml "hl_lines=7-29" >}} - containers: - - args: - - redis-server - image: redis:latest - # ... - - env: - - name: DD_API_KEY - valueFrom: - secretKeyRef: - key: api-key - name: datadog-secret - - name: DD_CLUSTER_AGENT_AUTH_TOKEN - valueFrom: - secretKeyRef: - key: token - name: datadog-secret - - name: DD_EKS_FARGATE - value: "true" - # ... - image: gcr.io/datadoghq/agent:7.51.0 - imagePullPolicy: IfNotPresent - name: datadog-agent-injected - resources: - limits: - cpu: 200m - memory: 256Mi - requests: - cpu: 200m - memory: 256Mi + {{< highlight yaml "hl_lines=15-37" >}} + metadata: + labels: + app: redis + eks.amazonaws.com/fargate-profile: fp-fargate + agent.datadoghq.com/sidecar: fargate + spec: + serviceAccountName: datadog-agent + containers: + - name: my-redis + image: redis:latest + args: + - redis-server + # (...) + + - name: datadog-agent-injected + image: gcr.io/datadoghq/agent:7.64.0 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_AGENT_AUTH_TOKEN + valueFrom: + secretKeyRef: + key: token + name: datadog-secret + # (...) + resources: + limits: + cpu: 200m + memory: 256Mi + requests: + cpu: 200m + memory: 256Mi {{< /highlight >}} -##### Sidecar profiles and custom selectors - -To further configure the Agent or its container resources, use the properties in your `DatadogAgent` resource. Use the `spec.features.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. Use the `spec.features.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target workload pods instead of updating the workload to add `agent.datadoghq.com/sidecar:fargate` labels. - - 1. Create a `DatadogAgent` custom resource in `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. - - **Example** - - In the following example, a selector targets all pods with the label `"app": redis`. The sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and resource settings. - - ```yaml - spec: - features: - admissionController: - agentSidecarInjection: - enabled: true - provider: fargate - selectors: - - objectSelector: - matchLabels: - "app": redis - profiles: - - env: - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED - value: "true" - resources: - requests: - cpu: "400m" - memory: "256Mi" - limits: - cpu: "800m" - memory: "512Mi" - ``` - - Then apply the new configuration: - - ```shell - kubectl apply -n datadog-agent -f datadog-agent.yaml - ``` +#### Sidecar profiles and custom selectors - 2. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any pod created with the label `app:redis`. - **The Admission Controller does not mutate pods that are already created**. +To further configure the Agent or its container resources, use the properties in your `DatadogAgent` resource. +- Use the `spec.features.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. +- Use the `spec.features.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target your desired workload pods instead of pods with the `agent.datadoghq.com/sidecar: fargate` label. + +You can adjust the profile of the injected Agent container without updating the label selector if desired. - **Example result** +For a full example: - The following is a `spec.containers` snippet from a Redis deployment where the Admission Controller injected an Agent sidecar. The environment variables and resource settings from `datadog-agent.yaml` are automatically applied. +1. Create a `DatadogAgent` custom resource in `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. + + In the following example, a selector targets all pods with the label `app: redis`. The new sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. + + ```yaml + #(...) + spec: + #(...) + features: + admissionController: + agentSidecarInjection: + enabled: true + provider: fargate + selectors: + - objectSelector: + matchLabels: + app: redis + profiles: + - env: + - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + value: "true" + resources: + requests: + cpu: "400m" + memory: "256Mi" + limits: + cpu: "800m" + memory: "512Mi" + ``` + + Then apply the new configuration: + + ```shell + kubectl apply -n datadog-agent -f datadog-agent.yaml + ``` + +2. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any new pod created with the label `app: redis`. **The Admission Controller does not mutate pods that are already created**. + +##### Example custom profile result + +The following is output from a Redis Deployment's pod where the Admission Controller injected an Agent sidecar based on the pod label `app: redis` instead of the label `agent.datadoghq.com/sidecar: fargate`. + +The environment variables and resource settings are automatically applied based on the new Fargate profile configured in the `DatadogAgent`. - {{< highlight yaml "hl_lines=12-30" >}} - labels: - app: redis - eks.amazonaws.com/fargate-profile: fp-fargate - pod-template-hash: 7b86c456c4 - # ... - containers: - - args: - - redis-server - image: redis:latest - # ... - - env: - - name: DD_API_KEY - valueFrom: - secretKeyRef: - key: api-key - name: datadog-secret - # ... - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED - value: "true" - # ... - image: gcr.io/datadoghq/agent:7.51.0 - imagePullPolicy: IfNotPresent - name: datadog-agent-injected - resources: - limits: - cpu: 800m - memory: 512Mi - requests: - cpu: 400m - memory: 256Mi - {{< /highlight >}} + {{< highlight yaml "hl_lines=29-38" >}} + metadata: + labels: + app: redis + eks.amazonaws.com/fargate-profile: fp-fargate + spec: + serviceAccountName: datadog-agent + containers: + - name: my-redis + image: redis:latest + args: + - redis-server + # (...) + + - name: datadog-agent-injected + image: gcr.io/datadoghq/agent:7.64.0 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_AGENT_AUTH_TOKEN + valueFrom: + secretKeyRef: + key: token + name: datadog-secret + - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + value: "true" + #(...) + resources: + requests: + cpu: "400m" + memory: "256Mi" + limits: + cpu: "800m" + memory: "512Mi" + {{< /highlight >}} + ### Admission Controller using Helm
This feature requires Cluster Agent v7.52.0+. @@ -318,212 +352,235 @@ The setup below configures the Cluster Agent to communicate with the Agent sidec #### Standard injection setup -1. Create a file, `datadog-values.yaml`, that contains: - - ```sh - datadog: - clusterName: - apiKeyExistingSecret: datadog-secret - agents: - enabled: false - clusterAgent: - tokenExistingSecret: datadog-secret - admissionController: - agentSidecarInjection: - enabled: true - provider: fargate - ``` - **Note**: Use `agents.enabled=false` for a Fargate-only cluster. On a mixed cluster, set `agents.enabled=true` to create a DaemonSet for monitoring workloads on EC2 instances. - -2. Deploy the chart: - - ```bash - helm install datadog-agent -f datadog-values.yaml datadog/datadog - ``` +1. Create a Helm configuration file `datadog-values.yaml` with Admission Controller injection and the fargate provider enabled: + + ```yaml + datadog: + apiKeyExistingSecret: datadog-secret + clusterName: + clusterAgent: + tokenExistingSecret: datadog-secret + admissionController: + agentSidecarInjection: + enabled: true + provider: fargate + ``` + + **Note**: You can set `agents.enabled=false` for a Fargate-only cluster to skip creating the traditional DaemonSet for monitoring workloads on the EC2 instances. + +2. Deploy the chart in your desired namespace: + + ```shell + helm install datadog-agent -f datadog-values.yaml datadog/datadog + ``` + +3. After the Cluster Agent reaches a running state and registers Admission Controller's mutating webhooks add the label `agent.datadoghq.com/sidecar: fargate` to your desired pods (not the parent workload) to trigger the injection of the Datadog Agent sidecar container. + +**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent will not connect to Kubernetes. + +##### Example standard injection result + +The following is output from a sample Redis Deployment's pod where the Admission Controller injected an Agent sidecar. The environment variables and resource settings are automatically applied based on the Datadog Fargate profile's internal default values. + +The sidecar uses the image repository and tags set in the Helm values. Communication between Cluster Agent and sidecars is enabled by default. + + {{< highlight yaml "hl_lines=15-37" >}} + metadata: + labels: + app: redis + eks.amazonaws.com/fargate-profile: fp-fargate + agent.datadoghq.com/sidecar: fargate + spec: + serviceAccountName: datadog-agent + containers: + - name: my-redis + image: redis:latest + args: + - redis-server + # (...) + + - name: datadog-agent-injected + image: gcr.io/datadoghq/agent:7.64.0 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_AGENT_AUTH_TOKEN + valueFrom: + secretKeyRef: + key: token + name: datadog-secret + # (...) + resources: + limits: + cpu: 200m + memory: 256Mi + requests: + cpu: 200m + memory: 256Mi + {{< /highlight >}} -3. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any pod created with the label `agent.datadoghq.com/sidecar:fargate`. - **The Admission Controller does not mutate pods that are already created**. +#### Sidecar profiles and custom selectors -**Example result** - -The following is a `spec.containers` snippet from a Redis deployment where the Admission Controller injected an Agent sidecar. The sidecar is automatically configured using internal defaults, with additional settings to run in an EKS Fargate environment. The sidecar uses the image repository and tags set in the Helm values. Communication between Cluster Agent and sidecars is enabled by default. - -{{< highlight yaml "hl_lines=7-29" >}} - containers: - - args: - - redis-server - image: redis:latest - # ... - - env: - - name: DD_API_KEY - valueFrom: - secretKeyRef: - key: api-key - name: datadog-secret - - name: DD_CLUSTER_AGENT_AUTH_TOKEN - valueFrom: - secretKeyRef: - key: token - name: datadog-secret - - name: DD_EKS_FARGATE - value: "true" - # ... - image: gcr.io/datadoghq/agent:7.51.0 - imagePullPolicy: IfNotPresent - name: datadog-agent-injected - resources: - limits: - cpu: 200m - memory: 256Mi - requests: - cpu: 200m - memory: 256Mi -{{< /highlight >}} +To further configure the Agent or its container resources, use the properties in the Helm Chart: -##### Sidecar profiles and custom selectors +- Use the Helm property `clusterAgent.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. +- Use the `clusterAgent.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target your desired workload pods instead of pods with the `agent.datadoghq.com/sidecar: fargate` label. -To further configure the Agent or its container resources, use the Helm property `clusterAgent.admissionController.agentSidecarInjection.profiles` to add environment variable definitions and resource settings. Use the `clusterAgent.admissionController.agentSidecarInjection.selectors` property to configure a custom selector to target workload pods instead of updating the workload to add `agent.datadoghq.com/sidecar:fargate` labels. +You can adjust the profile of the injected Agent container without updating the label selector if desired. -1. Create a Helm `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. +For a full example: - **Example** +1. Create a Helm `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. - In the following example, a selector targets all pods with the label `"app": redis`. The sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and resource settings. + In the following example, a selector targets all pods with the label `app: redis`. The sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. - ```yaml - clusterAgent: - admissionController: - agentSidecarInjection: - selectors: - - objectSelector: - matchLabels: - "app": redis - profiles: - - env: - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED - value: "true" - resources: - requests: - cpu: "400m" - memory: "256Mi" - limits: - cpu: "800m" - memory: "512Mi" - ``` + ```yaml + #(...) + clusterAgent: + admissionController: + agentSidecarInjection: + enabled: true + provider: fargate + selectors: + - objectSelector: + matchLabels: + app: redis + profiles: + - env: + - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + value: "true" + resources: + requests: + cpu: "400m" + memory: "256Mi" + limits: + cpu: "800m" + memory: "512Mi" + ``` -2. Install the chart: +2. Upgrade your Helm Chart: ```shell - 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 \ - -f datadog-values.yaml + helm upgrade datadog-agent -f datadog-values.yaml datadog/datadog ``` - **Note**: Use `agents.enabled=false` for a Fargate-only cluster. On a mixed cluster, set `agents.enabled=true` to create a DaemonSet for monitoring workloads on EC2 instances. -3. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any pod created with the label `app:redis`. +3. After the Cluster Agent reaches a running state and registers Admission Controller mutating webhooks, an Agent sidecar is automatically injected into any pod created with the label `app: redis`. **The Admission Controller does not mutate pods that are already created**. -**Example result** - -The following is a `spec.containers` snippet from a Redis deployment where the Admission Controller injected an Agent sidecar. The environment variables and resource settings from `datadog-values.yaml` are automatically applied. - -{{< highlight yaml "hl_lines=12-30" >}} -labels: - app: redis - eks.amazonaws.com/fargate-profile: fp-fargate - pod-template-hash: 7b86c456c4 -# ... -containers: -- args: - - redis-server - image: redis:latest -# ... -- env: - - name: DD_API_KEY - valueFrom: - secretKeyRef: - key: api-key - name: datadog-secret - # ... - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED - value: "true" - # ... - image: gcr.io/datadoghq/agent:7.51.0 - imagePullPolicy: IfNotPresent - name: datadog-agent-injected - resources: - limits: - cpu: 800m - memory: 512Mi - requests: - cpu: 400m - memory: 256Mi -{{< /highlight >}} +##### Example custom profile result + +The following is output from a Redis Deployment's pod where the Admission Controller injected an Agent sidecar based on the pod label `app: redis` instead of the label `agent.datadoghq.com/sidecar: fargate`. + +The environment variables and resource settings are automatically applied based on the new Fargate profile configured in the Helm configuration. + + {{< highlight yaml "hl_lines=29-37" >}} + metadata: + labels: + app: redis + eks.amazonaws.com/fargate-profile: fp-fargate + spec: + serviceAccountName: datadog-agent + containers: + - name: my-redis + image: redis:latest + args: + - redis-server + # (...) + + - name: datadog-agent-injected + image: gcr.io/datadoghq/agent:7.64.0 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_AGENT_AUTH_TOKEN + valueFrom: + secretKeyRef: + key: token + name: datadog-secret + - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + value: "true" + #(...) + resources: + requests: + cpu: "400m" + memory: "256Mi" + limits: + cpu: "800m" + memory: "512Mi" + {{< /highlight >}} ### Manual -To start collecting data from your Fargate type pod, deploy the Datadog Agent v7.17+ as a sidecar of your application. This is the minimum configuration required to collect metrics from your application running in the pod, notice the addition of `DD_EKS_FARGATE=true` in the manifest to deploy your Datadog Agent sidecar. +To start collecting data from your Fargate type pod, deploy the Datadog Agent v7.17+ as a sidecar container within your application's pod. This is the minimum configuration required to collect metrics from your application running in the pod, notice the addition of `DD_EKS_FARGATE=true` in the manifest to deploy your Datadog Agent sidecar. + +Replace the placeholder values: +- `` with the [Datadog API key from your organization][14]. +- `` to your site: {{< region-param key="dd_site" code="true" >}}. Defaults to `datadoghq.com` + +As well as ensure you are using a `serviceAccountName` with the prerequisite permissions. ```yaml apiVersion: apps/v1 kind: Deployment metadata: - name: "" - namespace: default + name: "" + namespace: default spec: - selector: - matchLabels: - app: "" - replicas: 1 - template: - metadata: - labels: - app: "" - name: "" - spec: - serviceAccountName: datadog-agent - containers: - - name: "" - image: "" - ## Running the Agent as a side-car - - image: datadog/agent - name: datadog-agent - env: - - name: DD_API_KEY - value: "" - ## Set DD_SITE to "datadoghq.eu" to send your - ## Agent data to the Datadog EU site - - name: DD_SITE - value: "datadoghq.com" - - name: DD_EKS_FARGATE - value: "true" - - name: DD_CLUSTER_NAME - value: "" - - name: DD_KUBERNETES_KUBELET_NODENAME - valueFrom: - fieldRef: - apiVersion: v1 - fieldPath: spec.nodeName - resources: - requests: - memory: "256Mi" - cpu: "200m" - limits: - memory: "256Mi" - cpu: "200m" + selector: + matchLabels: + app: "" + replicas: 1 + template: + metadata: + labels: + app: "" + spec: + serviceAccountName: datadog-agent + containers: + # Your original container + - name: "" + image: "" + + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + env: + - name: DD_API_KEY + value: "" + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_NAME + value: "" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + resources: + requests: + memory: "256Mi" + cpu: "200m" + limits: + memory: "256Mi" + cpu: "200m" ``` -**Note**: Don't forget to replace `` with the [Datadog API key from your organization][14]. - -**Note**: Add your desired `kube_cluster_name:` to the list of `DD_TAGS` to ensure your metrics are tagged by your desired cluster. You can append additional tags here as space separated `:` tags. For Agents `7.34+` and `6.34+`, this is not required. Instead, set the `DD_CLUSTER_NAME` environment variable. +**Note**: Add `DD_TAGS` to append additional space separated `:` tags. The `DD_CLUSTER_NAME` environment variable will set your `kube_cluster_name` tag. #### Running the Cluster Agent or the Cluster Checks Runner @@ -533,49 +590,61 @@ When using EKS Fargate, there are two possible scenarios depending on whether or If the EKS cluster runs Fargate and non-Fargate workloads, and you want to monitor the non-Fargate workload through Node Agent DaemonSet, add the Cluster Agent/Cluster Checks Runner to this deployment. For more information, see the [Cluster Agent Setup][25]. -The Cluster Agent token must be reachable from the Fargate tasks you want to monitor. If you are using the Helm Chart or Datadog Operator, this is not reachable by default because a secret in the target namespace is created. - -You have two options for this to work properly: - -* Use an hardcoded token value (`clusterAgent.token` in Helm, `credentials.token` in the Datadog Operator); convenient, but less secure. -* Use a manually-created secret (`clusterAgent.tokenExistingSecret` in Helm, not available in the Datadog Operator) and replicate it in all namespaces where Fargate tasks need to be monitored; secure, but requires extra operations. -**Note**: The `token` value requires a minimum of 32 characters. - -If the EKS cluster runs only Fargate workloads, you need a standalone Cluster Agent deployment. And, as described above, choose one of the two options for making the token reachable. - -Use the following Helm `values.yaml`: +When deploying your Cluster Agent use the Secret and token created in the prerequisite steps. +##### Helm ```yaml datadog: - apiKey: + apiKeyExistingSecret: datadog-secret clusterName: -agents: - enabled: false clusterAgent: - enabled: true - replicas: 2 - env: - - name: DD_EKS_FARGATE - value: "true" + tokenExistingSecret: datadog-secret ``` +Set `agents.enabled=false` if you are not using standard non-Fargate workloads. +##### Operator +```yaml +apiVersion: datadoghq.com/v2alpha1 +kind: DatadogAgent +metadata: + name: datadog +spec: + global: + clusterAgentTokenSecret: + secretName: datadog-secret + keyName: token + credentials: + apiSecret: + secretName: datadog-secret + keyName: api-key +``` + +##### Configuring sidecar In both cases, you need to change the Datadog Agent sidecar manifest in order to allow communication with the Cluster Agent: ```yaml - env: + containers: + #(...) + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + env: + #(...) + - name: DD_CLUSTER_NAME + value: - name: DD_CLUSTER_AGENT_ENABLED value: "true" - name: DD_CLUSTER_AGENT_AUTH_TOKEN - value: # Use valueFrom: if you're using a secret + valueFrom: + secretKeyRef: + name: datadog-secret + key: token - name: DD_CLUSTER_AGENT_URL value: https://..svc.cluster.local:5005 - - name: DD_ORCHESTRATOR_EXPLORER_ENABLED # Required to get Kubernetes resources view - value: "true" - - name: DD_CLUSTER_NAME - value: ``` +Se the `DD_CLUSTER_AGENT_URL` relative to the Service name and Namespace created for your Datadog Cluster Agent. + @@ -841,11 +910,9 @@ The `eks_fargate` check does not include any events. ### ServiceAccount Kubelet permissions -****TBD - -Ensure you have the right permissions on the ServiceAccount associated with your pod. If your pod does not have a ServiceAccount associated with it, or, it isn't bound to the correct ClusterRole it won't have access to Kubelet. +Ensure you have the right permissions on the `ServiceAccount` associated with your pod. If your pod does not have a `ServiceAccount` associated with it, or, it isn't bound to the correct ClusterRole it won't have access to Kubelet. -This can be validated with a command like: +This access can be validated with a command like: ```shell kubectl auth can-i get nodes/pods --as system:serviceaccount:: @@ -958,13 +1025,11 @@ Additional helpful documentation, links, and articles: [4]: https://docs.datadoghq.com/getting_started/agent/autodiscovery/ [5]: https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html [6]: http://docs.datadoghq.com/integrations/amazon_eks/#setup -[7]: http://docs.datadoghq.com/agent/kubernetes -[8]: http://docs.datadoghq.com/agent/kubernetes/daemonset_setup +[7]: http://docs.datadoghq.com/agent/kubernetes/installation [9]: https://app.datadoghq.com/account/settings#integrations/kubernetes [10]: https://app.datadoghq.com/account/settings#integrations/amazon-web-services [11]: https://app.datadoghq.com/account/settings#integrations/amazon-eks [12]: https://app.datadoghq.com/account/settings#integrations/amazon-ec2 -[13]: http://docs.datadoghq.com/integrations/kubernetes [14]: https://app.datadoghq.com/organization-settings/api-keys [15]: https://docs.datadoghq.com/agent/kubernetes/integrations/ [16]: https://docs.datadoghq.com/integrations/#cat-autodiscovery From a7cf8ef58370af9bd249d77d33d961c14386754a Mon Sep 17 00:00:00 2001 From: JacksonDavenport Date: Thu, 24 Apr 2025 11:07:59 -0700 Subject: [PATCH 3/4] Fix all subintegrations, links, raw API Key --- eks_fargate/README.md | 551 +++++++++++++++++++++--------------------- 1 file changed, 279 insertions(+), 272 deletions(-) diff --git a/eks_fargate/README.md b/eks_fargate/README.md index 72f0f8f9e3a21..3d18a145c009c 100644 --- a/eks_fargate/README.md +++ b/eks_fargate/README.md @@ -7,12 +7,12 @@ Amazon EKS Fargate is a managed Kubernetes service that automates certain aspects of deployment and maintenance for any standard Kubernetes environment. The EKS Fargate nodes are managed by AWS Fargate and abstracted away from the user. -EKS Fargate pods not run on traditional EKS nodes and EC2 instances. While the Agent does report [system checks][3], like `system.cpu.*` and `system.memory.*`, these are just for the Agent container. In order to collect data from your AWS Fargate pods, run the Agent as a sidecar within *each* of your desired application pods. The pod needs to be deployed with custom RBAC granting permissions to the kubelet for the Agent to get the required information. +EKS Fargate pods not run on traditional EKS nodes and EC2 instances. While the Agent does report [system checks][1], like `system.cpu.*` and `system.memory.*`, these are just for the Agent container. In order to collect data from your AWS Fargate pods, run the Agent as a sidecar within *each* of your desired application pods. The pod needs to be deployed with custom RBAC granting permissions to the kubelet for the Agent to get the required information. The Agent can only monitor the other containers in the same pod as itself. It will also communicate with the Cluster Agent for some of its reporting. Overall the Agent can: - Report Kubernetes metrics collection from the pod running your application containers and the Agent -- Run [Autodiscovery][4] based Agent integrations against the containers in the same pod +- Run [Autodiscovery][2] based Agent integrations against the containers in the same pod - Collect APM and DogStatsD metrics for containers in the same pod If you have a mixed cluster of traditional EKS Nodes and Fargate pods, you will manage the traditional Datadog Kubernetes installation with a Helm Chart or Datadog Operator, and then manage your EKS Fargate pods separately. @@ -22,13 +22,13 @@ If you have a mixed cluster of traditional EKS Nodes and Fargate pods, you will ## Prerequisites ### Fargate profile -Create and specify [AWS Fargate Profile][5] that your pods should run with to deploy your pods within EKS Fargate. +Create and specify [AWS Fargate Profile][3] that your pods should run with to deploy your pods within EKS Fargate. -If you do not specify a Fargate Profile your pods use classical EC2 machines. To monitor these pods follow the traditional approach of setting up the [Datadog-Amazon EKS integration setup][6] and [Kubernetes Agent setup][7]. +If you do not specify a Fargate Profile your pods use classical EC2 machines. To monitor these pods follow the traditional approach of setting up the [Datadog-Amazon EKS integration setup][4] and [Kubernetes Agent setup][5]. ### Secret for keys and tokens -Create a Kubernetes secret `datadog-secret` containing your Datadog API key and a 32 character alphanumeric token for the Cluster Agent. If you are deploying your traditional Datadog installation in one namespace and the Fargate pods in a different namespace, create the secret in *each* Fargate namespace. +Create a Kubernetes secret `datadog-secret` containing your [Datadog API key][7] and a 32 character alphanumeric token for the Cluster Agent. If you are deploying your traditional Datadog installation in one namespace and the Fargate pods in a different namespace, create the secret in *each* Fargate namespace. For example: ```shell @@ -43,7 +43,7 @@ For example: --from-literal token= ``` -This token is used for the Agent / Cluster Agent communication. Creating it in advance ensures both the traditional setups and Fargate pod get the same token value (as opposed to letting the Helm Chart or Operator create a random token for you). For more information how this token is used, see the [Cluster Agent Setup][35]. +This token is used for the Agent / Cluster Agent communication. Creating it in advance ensures both the traditional setups and Fargate pod get the same token value (as opposed to letting the Helm Chart or Operator create a random token for you). For more information how this token is used, see the [Cluster Agent Setup][17]. **Note**: You cannot change the name of the secret containing the Datadog API key and Cluster Agent token. It must be `datadog-secret` for the Agent in the sidecar to connect to Datadog when using the automatic injection methods. @@ -137,7 +137,7 @@ See the section below on [Troubleshooting: ServiceAccount Permissions](#servicea Be sure to follow the prerequisite steps above for setting up your profile, secrets, and permissions prior to installing the Datadog Agent. -If you have a mixed cluster of the traditional EKS nodes and Fargate pods you may want to first install the traditional [Agent in Kubernetes][7] using the above Secrets. As well as install the Datadog cloud integrations for [AWS][10]. +If you have a mixed cluster of the traditional EKS nodes and Fargate pods you may want to first install the traditional [Agent in Kubernetes][5] using the above Secrets. As well as install the Datadog cloud integrations for [AWS][6]. ### Installation @@ -150,7 +150,7 @@ After installation you can further configure the Agent for [Autodiscovery Integr ### Running the Agent as a sidecar -You can run the Agent as a sidecar by using the [Datadog Admission Controller][36] (requires Cluster Agent v7.52+) or with manual sidecar configuration. With the Admission Controller, you can inject an Agent sidecar into every pod that has the label `agent.datadoghq.com/sidecar: fargate`. +You can run the Agent as a sidecar by using the [Datadog Admission Controller][25] (requires Cluster Agent v7.52+) or with manual sidecar configuration. With the Admission Controller, you can inject an Agent sidecar into every pod that has the label `agent.datadoghq.com/sidecar: fargate`. With manual configuration, you must modify every workload manifest when adding or changing the Agent sidecar. Datadog recommends you use the Admission Controller. @@ -161,9 +161,9 @@ With manual configuration, you must modify every workload manifest when adding o
This feature requires Cluster Agent v7.52.0+, Datadog Operator v1.7.0+. .
-If you do not have the Datadog Operator already running see the [Operator install steps here][7]. +If you do not have the Datadog Operator already running see the [Operator install steps here][5]. -The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [event collection][29], [Kubernetes resources view][30], and [cluster checks][31]. +The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [event collection][21], [Kubernetes resources view][22], and [cluster checks][23]. #### Standard injection setup @@ -257,7 +257,7 @@ For a full example: 1. Create a `DatadogAgent` custom resource in `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. - In the following example, a selector targets all pods with the label `app: redis`. The new sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. + In the following example, a selector targets all pods with the label `app: redis`. The new sidecar profile configures a `DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. ```yaml #(...) @@ -274,7 +274,7 @@ For a full example: app: redis profiles: - env: - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED value: "true" resources: requests: @@ -328,7 +328,7 @@ The environment variables and resource settings are automatically applied based secretKeyRef: key: token name: datadog-secret - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED value: "true" #(...) resources: @@ -348,7 +348,7 @@ The environment variables and resource settings are automatically applied based
This feature requires Cluster Agent v7.52.0+.
-The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. +The setup below configures the Cluster Agent to communicate with the Agent sidecars, allowing access to features such as [events collection][21], [Kubernetes resources view][22], and [cluster checks][23]. #### Standard injection setup @@ -437,7 +437,7 @@ For a full example: 1. Create a Helm `datadog-values.yaml` file that configures a sidecar profile and a custom pod selector. - In the following example, a selector targets all pods with the label `app: redis`. The sidecar profile configures a `DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. + In the following example, a selector targets all pods with the label `app: redis`. The sidecar profile configures a `DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED` environment variable and new resource settings. ```yaml #(...) @@ -452,7 +452,7 @@ For a full example: app: redis profiles: - env: - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED value: "true" resources: requests: @@ -507,7 +507,7 @@ The environment variables and resource settings are automatically applied based secretKeyRef: key: token name: datadog-secret - - name: DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED + - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED value: "true" #(...) resources: @@ -526,11 +526,9 @@ The environment variables and resource settings are automatically applied based To start collecting data from your Fargate type pod, deploy the Datadog Agent v7.17+ as a sidecar container within your application's pod. This is the minimum configuration required to collect metrics from your application running in the pod, notice the addition of `DD_EKS_FARGATE=true` in the manifest to deploy your Datadog Agent sidecar. -Replace the placeholder values: -- `` with the [Datadog API key from your organization][14]. -- `` to your site: {{< region-param key="dd_site" code="true" >}}. Defaults to `datadoghq.com` +Replace the placeholder value `` to your site: {{< region-param key="dd_site" code="true" >}}. Defaults to `datadoghq.com`. As well as ensure you are using a `serviceAccountName` with the prerequisite permissions. -As well as ensure you are using a `serviceAccountName` with the prerequisite permissions. +This uses the Secret `datadog-secret` for the API Key created in the prerequisite steps. ```yaml apiVersion: apps/v1 @@ -539,56 +537,59 @@ metadata: name: "" namespace: default spec: - selector: - matchLabels: - app: "" replicas: 1 + selector: + matchLabels: + app: "" template: metadata: labels: app: "" - spec: - serviceAccountName: datadog-agent - containers: - # Your original container - - name: "" - image: "" - - # Running the Agent as a side-car - - name: datadog-agent - image: gcr.io/datadoghq/agent:7 - env: - - name: DD_API_KEY - value: "" - - name: DD_SITE - value: "" - - name: DD_EKS_FARGATE - value: "true" - - name: DD_CLUSTER_NAME - value: "" - - name: DD_KUBERNETES_KUBELET_NODENAME - valueFrom: - fieldRef: - apiVersion: v1 - fieldPath: spec.nodeName - resources: - requests: - memory: "256Mi" - cpu: "200m" - limits: - memory: "256Mi" - cpu: "200m" + spec: + serviceAccountName: datadog-agent + containers: + # Your original container + - name: "" + image: "" + + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_CLUSTER_NAME + value: "" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + resources: + requests: + memory: "256Mi" + cpu: "200m" + limits: + memory: "256Mi" + cpu: "200m" ``` **Note**: Add `DD_TAGS` to append additional space separated `:` tags. The `DD_CLUSTER_NAME` environment variable will set your `kube_cluster_name` tag. #### Running the Cluster Agent or the Cluster Checks Runner -Datadog recommends you run the Cluster Agent to access features such as [events collection][29], [Kubernetes resources view][30], and [cluster checks][31]. +Datadog recommends you run the Cluster Agent to access features such as [events collection][21], [Kubernetes resources view][22], and [cluster checks][23]. When using EKS Fargate, there are two possible scenarios depending on whether or not the EKS cluster is running mixed workloads (Fargate/non-Fargate). -If the EKS cluster runs Fargate and non-Fargate workloads, and you want to monitor the non-Fargate workload through Node Agent DaemonSet, add the Cluster Agent/Cluster Checks Runner to this deployment. For more information, see the [Cluster Agent Setup][25]. +If the EKS cluster runs Fargate and non-Fargate workloads, and you want to monitor the non-Fargate workload through Node Agent DaemonSet, add the Cluster Agent/Cluster Checks Runner to this deployment. For more information, see the [Cluster Agent Setup][17]. When deploying your Cluster Agent use the Secret and token created in the prerequisite steps. @@ -620,7 +621,7 @@ spec: keyName: api-key ``` -##### Configuring sidecar +##### Configuring sidecar for Cluster Agent In both cases, you need to change the Datadog Agent sidecar manifest in order to allow communication with the Cluster Agent: ```yaml @@ -652,139 +653,178 @@ Se the `DD_CLUSTER_AGENT_URL` relative to the Service name and Namespace created ### Integration metrics -Use [Autodiscovery labels with your application container][15] to start collecting its metrics for the [supported Agent integrations][16]. +Use [Autodiscovery annotations with your application container][8] to start collecting its metrics for the [supported Agent integrations][9]. ```yaml apiVersion: apps/v1 kind: Deployment metadata: - name: "" - namespace: default + name: "" + namespace: default spec: - replicas: 1 - selector: - matchLabels: - app: "" - template: - metadata: - labels: - app: "" - name: "" - annotations: - ad.datadoghq.com/.check_names: '[]' - ad.datadoghq.com/.init_configs: '[]' - ad.datadoghq.com/.instances: '[]' - spec: - serviceAccountName: datadog-agent - containers: - - name: "" - image: "" - ## Running the Agent as a side-car - - image: datadog/agent - name: datadog-agent - env: - - name: DD_API_KEY - value: "" - ## Set DD_SITE to "datadoghq.eu" to send your - ## Agent data to the Datadog EU site - - name: DD_SITE - value: "datadoghq.com" - - name: DD_EKS_FARGATE - value: "true" - - name: DD_KUBERNETES_KUBELET_NODENAME - valueFrom: - fieldRef: - apiVersion: v1 - fieldPath: spec.nodeName - resources: - requests: - memory: "256Mi" - cpu: "200m" - limits: - memory: "256Mi" - cpu: "200m" -``` - -**Notes**: + replicas: 1 + selector: + matchLabels: + app: "" + template: + metadata: + labels: + app: "" + annotations: + ad.datadoghq.com/.checks: | + { + "": { + "init_config": , + "instances": [] + } + } + spec: + serviceAccountName: datadog-agent + containers: + # Your original container + - name: "" + image: "" -- Don't forget to replace `` with the [Datadog API key from your organization][14]. -- Container metrics are not available in Fargate because the `cgroups` volume from the host can't be mounted into the Agent. The [Live Containers][17] view reports 0 for CPU and Memory. + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + # (...) +``` ### DogStatsD -Set up the container port `8125` over your Agent container to forward [DogStatsD metrics][18] from your application container to Datadog. +Set up the container port `8125` over your Agent container to forward [DogStatsD metrics][10] from your application container to Datadog. ```yaml apiVersion: apps/v1 kind: Deployment metadata: - name: "" - namespace: default + name: "" + namespace: default spec: - replicas: 1 - selector: - matchLabels: - app: "" - template: - metadata: - labels: - app: "" - name: "" - spec: - serviceAccountName: datadog-agent - containers: - - name: "" - image: "" - ## Running the Agent as a side-car - - image: datadog/agent - name: datadog-agent - ## Enabling port 8125 for DogStatsD metric collection - ports: - - containerPort: 8125 - name: dogstatsdport - protocol: UDP - env: - - name: DD_API_KEY - value: "" - ## Set DD_SITE to "datadoghq.eu" to send your - ## Agent data to the Datadog EU site - - name: DD_SITE - value: "datadoghq.com" - - name: DD_EKS_FARGATE - value: "true" - - name: DD_KUBERNETES_KUBELET_NODENAME - valueFrom: - fieldRef: - apiVersion: v1 - fieldPath: spec.nodeName - resources: - requests: - memory: "256Mi" - cpu: "200m" - limits: - memory: "256Mi" - cpu: "200m" -``` + replicas: 1 + selector: + matchLabels: + app: "" + template: + metadata: + labels: + app: "" + spec: + serviceAccountName: datadog-agent + containers: + # Your original container + - name: "" + image: "" + + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + ports: + - name: dogstatsdport + containerPort: 8125 + protocol: UDP + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + # (...) -**Note**: Don't forget to replace `` with the [Datadog API key from your organization][14]. +``` ### Live containers -Datadog Agent v6.19+ supports live containers in the EKS Fargate integration. Live containers appear on the [Containers][19] page. +Datadog Agent v6.19+ supports live containers in the EKS Fargate integration. Live containers appear on the [Containers][11] page. -### Live processes +### Kubernetes resources view -Datadog Agent v6.19+ supports live processes in the EKS Fargate integration. Live processes appear on the [Processes][20] page. To enable live processes, [enable shareProcessNamespace in the pod spec][21]. +To collect Kubernetes resource views, you need a [Cluster Agent setup][17] and a valid connection between the sidecar Agent and Cluster Agent. This is connected for you automatically if you are using the sidecar injection setup. -### Kubernetes resources view +When configuring manually ensure you are [connecting the sidecar Agent](#configuring-sidecar-for-cluster-agent). + +## Process collection + +For Agent 6.19+/7.19+, [Process Collection][18] is available. Set the Agent environment variable `DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED=true` and [set `shareProcessNamespace: true` on your pod spec][13] to collect all processes running on your Fargate pod. + +For example: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: "" + namespace: default +spec: + replicas: 1 + selector: + matchLabels: + app: "" + template: + metadata: + labels: + app: "" + spec: + serviceAccountName: datadog-agent + shareProcessNamespace: true + containers: + # Your original container + - name: "" + image: "" -To collect Kubernetes resource views, you need a [Cluster Agent setup](#running-the-cluster-agent-or-the-cluster-checks-runner). + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + - name: DD_PROCESS_CONFIG_PROCESS_COLLECTION_ENABLED + value: "true" + # (...) +``` ## Log collection ### Collecting logs from EKS on Fargate with Fluent Bit. -Monitor EKS Fargate logs by using [Fluent Bit][22] to route EKS logs to CloudWatch Logs and the [Datadog Forwarder][23] to route logs to Datadog. +Monitor EKS Fargate logs by using [Fluent Bit][14] to route EKS logs to CloudWatch Logs and the [Datadog Forwarder][15] to route logs to Datadog. 1. To configure Fluent Bit to send logs to CloudWatch, create a Kubernetes ConfigMap that specifies CloudWatch Logs as its output. The ConfigMap specifies the log group, region, prefix string, and whether to automatically create the log group. @@ -804,94 +844,70 @@ Monitor EKS Fargate logs by using [Fluent Bit][22] to route EKS logs to CloudWat log_stream_prefix awslogs-firelens-example auto_create_group true ``` -2. Use the [Datadog Forwarder][23] to collect logs from Cloudwatch and send them to Datadog. +2. Use the [Datadog Forwarder][15] to collect logs from Cloudwatch and send them to Datadog. ## Traces collection -Set up the container port `8126` over your Agent container to collect traces from your application container. [Read more about how to set up tracing][24]. +Set up the container port `8126` over your Agent container to collect traces from your application container. As well as set the [`shareProcessNamespace: true` in the pod spec][13] to assist the Agent for origin detection. + +[Read more about how to set up tracing][16]. ```yaml apiVersion: apps/v1 kind: Deployment metadata: - name: "" - namespace: default + name: "" + namespace: default spec: - replicas: 1 - selector: - matchLabels: - app: "" - template: - metadata: - labels: - app: "" - name: "" - spec: - serviceAccountName: datadog-agent - ## Putting the agent in the same namespace as the application for origin detection with cgroup v2 - shareProcessNamespace: true - containers: - - name: "" - image: "" - ## Running the Agent as a side-car - - image: datadog/agent - name: datadog-agent - ## Enabling port 8126 for Trace collection - ports: - - containerPort: 8126 - name: traceport - protocol: TCP - env: - - name: DD_API_KEY - value: "" - ## Set DD_SITE to "datadoghq.eu" to send your - ## Agent data to the Datadog EU site - - name: DD_SITE - value: "datadoghq.com" - - name: DD_EKS_FARGATE - value: "true" - - name: DD_APM_ENABLED - value: "true" - - name: DD_KUBERNETES_KUBELET_NODENAME - valueFrom: - fieldRef: - apiVersion: v1 - fieldPath: spec.nodeName - resources: - requests: - memory: "256Mi" - cpu: "200m" - limits: - memory: "256Mi" - cpu: "200m" + replicas: 1 + selector: + matchLabels: + app: "" + template: + metadata: + labels: + app: "" + spec: + serviceAccountName: datadog-agent + shareProcessNamespace: true + containers: + # Your original container + - name: "" + image: "" + + # Running the Agent as a side-car + - name: datadog-agent + image: gcr.io/datadoghq/agent:7 + ports: + - name: traceport + containerPort: 8126 + protocol: TCP + env: + - name: DD_API_KEY + valueFrom: + secretKeyRef: + key: api-key + name: datadog-secret + - name: DD_SITE + value: "" + - name: DD_EKS_FARGATE + value: "true" + - name: DD_KUBERNETES_KUBELET_NODENAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: spec.nodeName + # (...) ``` -**Note**: Don't forget to replace `` with the [Datadog API key from your organization][14]. +In EKS Fargate you do not have to set the `DD_AGENT_HOST` address in your application container. Let this default to `localhost`. ## Events collection -To collect events from your Amazon EKS Fargate API server, run a [Datadog Cluster Agent within your EKS cluster](#running-the-cluster-agent-or-the-cluster-checks-runner) and [Enable Event collection for your Cluster Agent][19]. - -Optionally, deploy cluster check runners in addition to setting up the Datadog Cluster Agent to enable cluster checks. +To collect events from your Amazon EKS Fargate API server, run the [Datadog Cluster Agent][17] within your EKS cluster. The Cluster Agent collects Kubernetes events, including those for the EKS Fargate pods, by default. **Note**: You can also collect events if you run the Datadog Cluster Agent in a pod in Fargate. -## Process collection - -For Agent 6.19+/7.19+, [Process Collection][26] is available. Enable `shareProcessNamespace` on your pod spec to collect all processes running on your Fargate pod. For example: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: -spec: - shareProcessNamespace: true -... -``` - -**Note**: CPU and memory metrics are not available. - ## Data Collected ### Metrics @@ -1009,47 +1025,38 @@ clusterAgent: runAsUser: 100 ``` -Need help? Contact [Datadog support][20]. +Need help? Contact [Datadog support][12]. ## Further Reading Additional helpful documentation, links, and articles: -- [Key metrics for monitoring AWS Fargate][32] -- [How to collect metrics and logs from AWS Fargate workloads][27] -- [AWS Fargate monitoring with Datadog][28] - -[1]: http://docs.datadoghq.com/integrations/ecs_fargate/ -[2]: http://docs.datadoghq.com/integrations/amazon_eks/ -[3]: http://docs.datadoghq.com/integrations/system -[4]: https://docs.datadoghq.com/getting_started/agent/autodiscovery/ -[5]: https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html -[6]: http://docs.datadoghq.com/integrations/amazon_eks/#setup -[7]: http://docs.datadoghq.com/agent/kubernetes/installation -[9]: https://app.datadoghq.com/account/settings#integrations/kubernetes -[10]: https://app.datadoghq.com/account/settings#integrations/amazon-web-services -[11]: https://app.datadoghq.com/account/settings#integrations/amazon-eks -[12]: https://app.datadoghq.com/account/settings#integrations/amazon-ec2 -[14]: https://app.datadoghq.com/organization-settings/api-keys -[15]: https://docs.datadoghq.com/agent/kubernetes/integrations/ -[16]: https://docs.datadoghq.com/integrations/#cat-autodiscovery -[17]: https://app.datadoghq.com/containers -[18]: http://docs.datadoghq.com/tracing/setup -[19]: https://app.datadoghq.com/containers -[20]: https://app.datadoghq.com/process -[21]: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/ -[22]: https://aws.amazon.com/blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/ -[23]: https://docs.datadoghq.com/serverless/libraries_integrations/forwarder/ -[24]: http://docs.datadoghq.com/tracing/#send-traces-to-datadog -[25]: http://docs.datadoghq.com/agent/cluster_agent/setup/ -[26]: https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/?tab=k8sfile#process-collection -[27]: https://www.datadoghq.com/blog/tools-for-collecting-aws-fargate-metrics/ -[28]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/ -[29]: https://docs.datadoghq.com/agent/kubernetes/?tab=helm#event-collection -[30]: https://docs.datadoghq.com/infrastructure/livecontainers/#kubernetes-resources-view -[31]: https://docs.datadoghq.com/agent/cluster_agent/clusterchecks/#overview -[32]: https://www.datadoghq.com/blog/aws-fargate-metrics/ -[33]: https://github.com/kubernetes/kube-state-metrics -[34]: https://docs.datadoghq.com/containers/guide/clustercheckrunners -[35]: http://docs.datadoghq.com/agent/cluster_agent -[36]: https://docs.datadoghq.com/containers/cluster_agent/admission_controller/?tab=operator +- [Key metrics for monitoring AWS Fargate][24] +- [How to collect metrics and logs from AWS Fargate workloads][19] +- [AWS Fargate monitoring with Datadog][20] + +[1]: http://docs.datadoghq.com/integrations/system +[2]: https://docs.datadoghq.com/getting_started/agent/autodiscovery/ +[3]: https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html +[4]: http://docs.datadoghq.com/integrations/amazon_eks/#setup +[5]: http://docs.datadoghq.com/agent/kubernetes/installation +[6]: /account/settings#integrations/amazon-web-services +[7]: /organization-settings/api-keys +[8]: https://docs.datadoghq.com/agent/kubernetes/integrations/ +[9]: https://github.com/DataDog/integrations-core +[10]: https://docs.datadoghq.com/developers/dogstatsd/ +[11]: /containers +[12]: https://docs.datadoghq.com/help/ +[13]: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/ +[14]: https://aws.amazon.com/blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/ +[15]: https://docs.datadoghq.com/serverless/libraries_integrations/forwarder/ +[16]: http://docs.datadoghq.com/tracing/#send-traces-to-datadog +[17]: http://docs.datadoghq.com/agent/cluster_agent/setup/ +[18]: https://docs.datadoghq.com/infrastructure/process/?tab=kubernetesmanual#installation +[19]: https://www.datadoghq.com/blog/tools-for-collecting-aws-fargate-metrics/ +[20]: https://www.datadoghq.com/blog/aws-fargate-monitoring-with-datadog/ +[21]: https://docs.datadoghq.com/containers/kubernetes/configuration/#enable-kubernetes-event-collection +[22]: https://docs.datadoghq.com/infrastructure/containers/orchestrator_explorer +[23]: https://docs.datadoghq.com/agent/cluster_agent/clusterchecks/#overview +[24]: https://www.datadoghq.com/blog/aws-fargate-metrics/ +[25]: https://docs.datadoghq.com/containers/cluster_agent/admission_controller/?tab=operator From 8dae15d449d38f66c5899fda85840acaa969df38 Mon Sep 17 00:00:00 2001 From: JacksonDavenport Date: Fri, 25 Apr 2025 10:41:05 -0700 Subject: [PATCH 4/4] Fix some typos and eng notes --- eks_fargate/README.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/eks_fargate/README.md b/eks_fargate/README.md index 3d18a145c009c..948d9720f1617 100644 --- a/eks_fargate/README.md +++ b/eks_fargate/README.md @@ -7,15 +7,15 @@ Amazon EKS Fargate is a managed Kubernetes service that automates certain aspects of deployment and maintenance for any standard Kubernetes environment. The EKS Fargate nodes are managed by AWS Fargate and abstracted away from the user. -EKS Fargate pods not run on traditional EKS nodes and EC2 instances. While the Agent does report [system checks][1], like `system.cpu.*` and `system.memory.*`, these are just for the Agent container. In order to collect data from your AWS Fargate pods, run the Agent as a sidecar within *each* of your desired application pods. The pod needs to be deployed with custom RBAC granting permissions to the kubelet for the Agent to get the required information. +EKS Fargate pods do not run on traditional EKS nodes backed by EC2 instances. While the Agent does report [system checks][1], like `system.cpu.*` and `system.memory.*`, these are just for the Agent container. In order to collect data from your EKS Fargate pods, run the Agent as a sidecar within *each* of your desired application pods. The pod needs to be deployed with custom RBAC granting permissions to the kubelet for the Agent to get the required information. -The Agent can only monitor the other containers in the same pod as itself. It will also communicate with the Cluster Agent for some of its reporting. Overall the Agent can: +The Agent sidecar is responsible for monitoring the other containers in the same pod as itself. As well as communicating with the Cluster Agent for portions of its reporting. Overall the Agent can: - Report Kubernetes metrics collection from the pod running your application containers and the Agent - Run [Autodiscovery][2] based Agent integrations against the containers in the same pod - Collect APM and DogStatsD metrics for containers in the same pod -If you have a mixed cluster of traditional EKS Nodes and Fargate pods, you will manage the traditional Datadog Kubernetes installation with a Helm Chart or Datadog Operator, and then manage your EKS Fargate pods separately. +If you have a mixed cluster of traditional EKS Nodes and Fargate pods, you manage the traditional Datadog Kubernetes installation with a Helm Chart or Datadog Operator deployment, and then manage your EKS Fargate pods separately. With the Datadog Admission Controller the Cluster Agent can manage the deployment of the Agent sidecars for you. **Note**: Cloud Network Monitoring (CNM) is not supported for EKS Fargate. @@ -142,7 +142,7 @@ If you have a mixed cluster of the traditional EKS nodes and Fargate pods you ma ### Installation -To collect data from your applications running in Amazon EKS Fargate over a Fargate node you will run the Agent as a sidecar. This can be done either manually or using the Datadog Admission Controller's automatic injection. This automatic injection requires the Cluster Agent to be running, and will automatically add the Agent sidecar to your desired pods. +To collect data from your applications running in Amazon EKS Fargate over a Fargate node you run the Agent as a sidecar container within your pods. This can be done either manually or using the Datadog Admission Controller's automatic injection. This automatic injection requires the Cluster Agent to be running, and automatically adds the Agent sidecar to your desired pods on creation. Both methods require you to set your RBAC and `serviceAccountName` in your pod manually. @@ -197,7 +197,7 @@ The setup below configures the Cluster Agent to communicate with the Agent sidec 2. After the Cluster Agent reaches a running state and registers Admission Controller's mutating webhooks add the label `agent.datadoghq.com/sidecar: fargate` to your desired pods (not the parent workload) to trigger the injection of the Datadog Agent sidecar container. -**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent will not connect to Kubernetes. +**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent cannot connect to Kubernetes. ##### Example standard injection result @@ -376,7 +376,7 @@ The setup below configures the Cluster Agent to communicate with the Agent sidec 3. After the Cluster Agent reaches a running state and registers Admission Controller's mutating webhooks add the label `agent.datadoghq.com/sidecar: fargate` to your desired pods (not the parent workload) to trigger the injection of the Datadog Agent sidecar container. -**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent will not connect to Kubernetes. +**Note:** The Admission Controller does not mutate pods that are already created, only new pods. Nor does it adjust your `serviceAccountName`, if you have not set the RBAC for this pod the Agent cannot connect to Kubernetes. ##### Example standard injection result @@ -581,7 +581,7 @@ spec: cpu: "200m" ``` -**Note**: Add `DD_TAGS` to append additional space separated `:` tags. The `DD_CLUSTER_NAME` environment variable will set your `kube_cluster_name` tag. +**Note**: Add `DD_TAGS` to append additional space separated `:` tags. The `DD_CLUSTER_NAME` environment variable sets your `kube_cluster_name` tag. #### Running the Cluster Agent or the Cluster Checks Runner @@ -644,7 +644,7 @@ In both cases, you need to change the Datadog Agent sidecar manifest in order to value: https://..svc.cluster.local:5005 ``` -Se the `DD_CLUSTER_AGENT_URL` relative to the Service name and Namespace created for your Datadog Cluster Agent. +See the `DD_CLUSTER_AGENT_URL` relative to the Service name and Namespace created for your Datadog Cluster Agent. @@ -764,9 +764,7 @@ Datadog Agent v6.19+ supports live containers in the EKS Fargate integration. Li ### Kubernetes resources view -To collect Kubernetes resource views, you need a [Cluster Agent setup][17] and a valid connection between the sidecar Agent and Cluster Agent. This is connected for you automatically if you are using the sidecar injection setup. - -When configuring manually ensure you are [connecting the sidecar Agent](#configuring-sidecar-for-cluster-agent). +To collect Kubernetes resource views, you need a [Cluster Agent setup][17] and a valid connection between the sidecar Agent and Cluster Agent. When using the Admission Controller's sidecar injection setup this is connected for you automatically. When configuring the sidecar manually ensure you are [connecting the sidecar Agent](#configuring-sidecar-for-cluster-agent). ## Process collection @@ -939,7 +937,7 @@ For example if your Fargate pod is in the `fargate` namespace with the ServiceAc kubectl auth can-i get nodes/pods --as system:serviceaccount:fargate:datadog-agent ``` -This will return `yes` or `no` based on the access. +This returns `yes` or `no` based on the access. ### Datadog Agent Container Security Context