Amazon EKS on AWS Fargate

Docs > Integraciones > Amazon EKS on AWS Fargate

Supported OS Linux Mac OS Windows

Integration version4.2.1

Información general

En esta página se describe la integración de EKS Fargate. Para ECS Fargate, consulta la documentación sobre la integración de ECS Fargate de Datadog.

Amazon EKS on AWS Fargate es un servicio gestionado de Kubernetes que automatiza ciertos aspectos del despliegue y mantenimiento de cualquier entorno estándar de Kubernetes. AWS Fargate gestiona los nodos de Kubernetes y los abstrae del usuario.

Nota: Network Performance Monitoring (NPM) no es compatible con EKS Fargate.

Configuración

Estos pasos cubren la configuración del Datadog Agent v7.17+ en un contenedor dentro de Amazon EKS on AWS Fargate. Consulta la documentación de la integración de Datadog y Amazon EKS si no utilizas AWS Fargate.

Los pods de AWS Fargate no son pods físicos, lo que significa que excluyen las checks de los sistemas basados en hosts, como CPU, memoria, etc. Para recopilar los datos de los pods de AWS Fargate, debes ejecutar el Agent como sidecar de un pod de aplicación con control de acceso basado en roles (RBAC) personalizado. Esto habilita las siguientes características:

Recopilación de las métricas de Kubernetes del pod que ejecuta los contenedores de aplicaciones y el Agent
Autodiscovery
Configuración de checks personalizadas del Agent para establecer los contenedores en el mismo pod como destino
APM y DogStatsD para los contenedores del mismo pod

Nodo de EC2

Si no se especifica a través de AWS Fargate Profile que los pods deben ejecutarse en Fargate, los pods pueden utilizar máquinas de EC2 clásicas. En ese caso, consulta la configuración de la integración de Datadog y Amazon EKS para recopilar sus datos. Esto funciona con la ejecución del Agent como una carga de trabajo de tipo EC2. La configuración del Agent es la misma que la configuración del Kubernetes Agent, y todas las opciones están disponibles. Para desplegar el Agent en nodos de EC2, utiliza la configuración del DaemonSet del Datadog Agent.

Instalación

Para obtener las mejores cargas de trabajo de monitorización de la cobertura de observabilidad en AWS EKS Fargate, instala las integraciones de Datadog para los siguientes servicios:

Kubernetes
AWS
EKS
EC2 (si ejecutas un nodo de tipo EC2)

Además, configura las integraciones para cualquier otro servicio de AWS que ejecutes con EKS (por ejemplo, ELB).

Instalación manual

Para realizar la instalación, descarga la imagen personalizada del Agent: datadog/agent con la versión 7.17 o una superior.

Si el Agent se ejecuta como sidecar, solo puede comunicarse con contenedores del mismo pod. Ejecuta un Agent para cada pod que quieras monitorizar.

Configuración

Para recopilar los datos de las aplicaciones que se ejecutan en AWS EKS Fargate a través de un nodo de Fargate, sigue estos pasos de configuración:

Configurar las reglas de RBAC de AWS EKS Fargate.
Desplegar el Agent como sidecar.
Configurar la recopilación de métricas, logs, eventos y trazas de Datadog.

Para ver los contenedores de EKS Fargate en la Datadog Live Container View, habilita shareProcessNamespace en las especiaciones del pod. Consulta Recopilación de procesos.

RBAC de AWS EKS Fargate

Utiliza el siguiente RBAC del Agent cuando despliegues el Agent como sidecar en AWS EKS Fargate:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: datadog-agent
rules:
  - apiGroups:
    - ""
    resources:
    - nodes
    - namespaces
    - endpoints
    verbs:
    - get
    - list
  - apiGroups:
      - ""
    resources:
      - nodes/metrics
      - nodes/spec
      - nodes/stats
      - nodes/proxy
      - nodes/pods
      - nodes/healthz
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: datadog-agent
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: datadog-agent
subjects:
  - kind: ServiceAccount
    name: datadog-agent
    namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: datadog-agent
  namespace: default

Ejecución del Agent como sidecar

Puedes ejecutar el Agent como sidecar mediante el Datadog Admission Controller (requiere el Cluster Agent v7.52+) o con una configuración de sidecar manual. Con el Admission Controller, puedes inyectar un sidecar del Agent en cada pod que tenga la etiqueta (label) agent.datadoghq.com/sidecar:fargate.

Con la configuración manual, debes modificar cada manifiesto de carga de trabajo al añadir o cambiar el sidecar del Agent. Datadog recomienda utilizar el Admission Controller.

Admission Controller con Datadog Operator

Esta característica requiere el Cluster Agent v7.52.0+, el Datadog Operator v1.7.0+ y la integración de EKS Fargate.

La siguiente configuración permite que el Cluster Agent se comunique con los sidecars del Agent y acceda a características como la recopilación de eventos, la vista de recursos de Kubernetes y las checks de clústeres.

Requisitos previos

Configura el RBAC en el espacio de nombres de aplicación. Consulta la sección RBAC de AWS EKS Fargate de esta página.

Crea un secreto de Kubernetes que contenga tu clave de la API de Datadog y el token del Cluster Agent en los espacios de nombres de instalación y aplicación de Datadog:

kubectl create secret generic datadog-secret -n datadog-agent \
        --from-literal api-key=<YOUR_DATADOG_API_KEY> --from-literal token=<CLUSTER_AGENT_TOKEN>
kubectl create secret generic datadog-secret -n fargate \
        --from-literal api-key=<YOUR_DATADOG_API_KEY> --from-literal token=<CLUSTER_AGENT_TOKEN>

Para obtener más información sobre cómo se utilizan estos secretos, consulta la Configuración del Cluster Agent.

Configuración

Crea un recurso personalizado DatadogAgent en datadog-agent.yaml con el Admission Controller habilitado:

 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
   features:
     admissionController:
       agentSidecarInjection:
         enabled: true
         provider: fargate

A continuación, aplica la nueva configuración:

kubectl apply -n datadog-agent -f datadog-agent.yaml

Una vez que el Cluster Agent alcanza un estado de ejecución y registra los webhooks mutados del Admission Controller, se inyecta automáticamente un sidecar del Agent en cualquier pod creado con la etiqueta agent.datadoghq.com/sidecar:fargate. El Admission Controller no muta los pods ya creados.

Resultado de ejemplo

A continuación se muestra un fragmento de spec.containers de un despliegue de Redis en el que el Admission Controller inyecta un sidecar del Agent. El sidecar se configura automáticamente con los valores predeterminados internos e incluye parámetros adicionales para ejecutarse en un entorno de EKS Fargate. El sidecar utiliza el repositorio de imágenes y las etiquetas (tags) configurados en datadog-agent.yaml. La comunicación entre el Cluster Agent y los sidecars está habilitada por defecto.

  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

Perfiles de sidecar y selectores personalizados

Para ampliar la configuración del Agent o de sus recursos de contenedores, utiliza las propiedades de tu recurso DatadogAgent. Utiliza la propiedad spec.features.admissionController.agentSidecarInjection.profiles para añadir definiciones de variables de entorno y parámetros de recursos. Utiliza la propiedad spec.features.admissionController.agentSidecarInjection.selectors para configurar un selector personalizado y establecer los pods de una carga de trabajo como destino en lugar de actualizar la carga de trabajo para añadir las etiquetas agent.datadoghq.com/sidecar:fargate.

Crea un recurso personalizado DatadogAgent en el archivo datadog-values.yaml que configure un perfil de sidecar y un selector de pods personalizado.

Ejemplo

En el siguiente ejemplo, un selector tiene todos los pods establecidos como destino con la etiqueta "app": redis. El perfil de sidecar configura una variable de entorno DD_PROCESS_AGENT_PROCESS_COLLECTION_ENABLED y parámetros de recursos.

   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"

A continuación, aplica la nueva configuración:

kubectl apply -n datadog-agent -f datadog-agent.yaml

Una vez que el Cluster Agent alcanza un estado de ejecución y registra los webhooks mutados del Admission Controller, se inyecta automáticamente un sidecar del Agent en cualquier pod creado con la etiqueta app:redis. El Admission Controller no muta los pods ya creados.

Resultado de ejemplo

A continuación se muestra un fragmento de spec.containers de un despliegue de Redis en el que el Admission Controller inyecta un sidecar del Agent. Las variables de entorno y los parámetros de recursos de datadog-agent.yaml se aplican automáticamente.

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
    valor: "true"
  # ...
  image: gcr.io/datadoghq/agent:7.51.0
  imagePullPolicy: IfNotPresent
  name: datadog-agent-injected
  recursos:
    limits:
      cpu: 800m
      memory: 512Mi
    requests:
      cpu: 400m
      memory: 256Mi

Admission Controller con Helm

Esta característica requiere el Cluster Agent v7.52.0+.

Requisitos previos

Configura el RBAC en el espacio de nombres de aplicación. Consulta la sección RBAC de AWS EKS Fargate de esta página.

Crea un secreto de Kubernetes que contenga tu clave de la API de Datadog y el token del Cluster Agent en los espacios de nombres de instalación y aplicación de Datadog:

kubectl create secret generic datadog-secret -n datadog-agent \
        --from-literal api-key=<YOUR_DATADOG_API_KEY> --from-literal token=<CLUSTER_AGENT_TOKEN>
kubectl create secret generic datadog-secret -n fargate \
        --from-literal api-key=<YOUR_DATADOG_API_KEY> --from-literal token=<CLUSTER_AGENT_TOKEN>

Para obtener más información sobre cómo se utilizan estos secretos, consulta la Configuración del Cluster Agent.

Configuración

Instala el Datadog Agent con el Cluster Agent y el Admission Controller habilitados:

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

Nota: Utiliza agents.enabled=false para un clúster exclusivo de Fargate. En el caso de un clúster mixto, define agents.enabled=true para crear un DaemonSet destinado a la monitorización de cargas de trabajo en instancias de EC2.

Una vez que el Cluster Agent alcanza un estado de ejecución y registra los webhooks mutados del Admission Controller, se inyecta automáticamente un sidecar del Agent en cualquier pod creado con la etiqueta agent.datadoghq.com/sidecar:fargate. El Admission Controller no muta los pods ya creados.

Resultado de ejemplo

A continuación se muestra un fragmento de spec.containers de un despliegue de Redis en el que el Admission Controller inyecta un sidecar del Agent. El sidecar se configura automáticamente con los valores predeterminados internos e incluye parámetros adicionales para ejecutarse en un entorno de EKS Fargate. El sidecar utiliza el repositorio de imágenes y las etiquetas configurados en los valores de Helm. La comunicación entre el Cluster Agent y los sidecars está habilitada por defecto.

  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
      valor: "true"
    # ...
    image: gcr.io/datadoghq/agent:7.51.0
    imagePullPolicy: IfNotPresent
    name: datadog-agent-injected
    recursos:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi

Perfiles de sidecar y selectores personalizados

Para ampliar la configuración del Agent o de sus recursos de contenedores, utiliza la propiedad de Helm clusterAgent.admissionController.agentSidecarInjection.profiles para añadir definiciones de variables de entorno y parámetros de recursos. Utiliza la propiedad clusterAgent.admissionController.agentSidecarInjection.selectors para configurar un selector personalizado y establecer los pods de una carga de trabajo como destino en lugar de actualizar la carga de trabajo para añadir las etiquetas agent.datadoghq.com/sidecar:fargate.

Crea un archivo datadog-values.yaml de Helm que configure un perfil de sidecar y un selector de pods personalizado.

Ejemplo

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"

Instala el chart:

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

Una vez que el Cluster Agent alcanza un estado de ejecución y registra los webhooks mutados del Admission Controller, se inyecta automáticamente un sidecar del Agent en cualquier pod creado con la etiqueta app:redis. El Admission Controller no muta los pods ya creados.

Resultado de ejemplo

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
    valor: "true"
  # ...
  image: gcr.io/datadoghq/agent:7.51.0
  imagePullPolicy: IfNotPresent
  name: datadog-agent-injected
  recursos:
    limits:
      cpu: 800m
      memory: 512Mi
    requests:
      cpu: 400m
      memory: 256Mi

Manual

Para empezar a recopilar datos de tu pod de tipo Fargate, despliega el Datadog Agent v7.17+ como sidecar de tu aplicación. Esta es la configuración mínima necesaria para recopilar métricas de la aplicación que se ejecuta en el pod. Observa la adición de DD_EKS_FARGATE=true en el manifiesto para desplegar el sidecar del Datadog Agent.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: "<APPLICATION_NAME>"
 namespace: default
spec:
 selector:
   matchLabels:
     app: "<APPLICATION_NAME>"
 replicas: 1
 template:
   metadata:
     labels:
       app: "<APPLICATION_NAME>"
     name: "<POD_NAME>"
   spec:
     serviceAccountName: datadog-agent
     containers:
     - name: "<APPLICATION_NAME>"
       image: "<APPLICATION_IMAGE>"
     ## Ejecución del Agent como sidecar
     - image: datadog/agent
       name: datadog-agent
       env:
       - name: DD_API_KEY
         value: "<YOUR_DATADOG_API_KEY>"
         ## Define DD_SITE como "datadoghq.eu" para enviar los
         ## datos del Agent al sitio de Datadog de la UE
       - name: DD_SITE
         value: "datadoghq.com"
       - name: DD_EKS_FARGATE
         value: "true"
       - name: DD_CLUSTER_NAME
         value: "<CLUSTER_NAME>"
       - name: DD_KUBERNETES_KUBELET_NODENAME
         valueFrom:
           fieldRef:
             apiVersion: v1
             fieldPath: spec.nodeName
      resources:
          requests:
            memory: "256Mi"
            cpu: "200m"
          limits:
            memory: "256Mi"
            cpu: "200m"

Nota: No olvides reemplazar <YOUR_DATADOG_API_KEY> por la clave de la API de Datadog de tu organización.

Nota: Añade el kube_cluster_name:<CLUSTER_NAME> que quieras a la lista de DD_TAGS para asegurarte de que tus métricas se etiqueten según el clúster deseado. Puedes añadir etiquetas adicionales aquí como etiquetas <KEY>:<VALUE> separadas por espacios. Para los Agents 7.34+ y 6.34+, esto no es necesario. En su lugar, establece la variable de entorno DD_CLUSTER_NAME.

Ejecución del Cluster Agent o el Cluster Checks Runner

Datadog recomienda ejecutar el Cluster Agent para acceder a características como la recopilación de eventos, la vista de recursos de Kubernetes y las checks de clústeres.

Cuando se utiliza EKS Fargate, hay dos escenarios posibles dependiendo de si el clúster de EKS ejecuta o no cargas de trabajo mixtas (de Fargate y que no son de Fargate).

Si el clúster de EKS ejecuta cargas de trabajo de Fargate y que no son de Fargate, y quieres monitorizar la carga de trabajo que no es de Fargate a través de Node Agent DaemonSet, añade el Cluster Agent o el Cluster Checks Runner a este despliegue. Para obtener más información, consulta la Configuración del Cluster Agent.

El token del Cluster Agent debe ser accesible desde las tareas de Fargate que quieres monitorizar. Si utilizas el Helm Chart o el Datadog Operator, dicho token no es accesible por defecto porque se crea un secreto en el espacio de nombres de destino.

Tienes dos opciones para que esto funcione correctamente:

Utilizar un valor de token codificado (clusterAgent.token en Helm, credentials.token en el Datadog Operator). Esto es práctico, pero menos seguro.
Utilizar un secreto creado manualmente (clusterAgent.tokenExistingSecret en Helm, no disponible en el Datadog Operator) y replicarlo en todos los espacios de nombres donde las tareas de Fargate necesiten monitorización. Esto es seguro, pero requiere operaciones adicionales. Nota: El valor de token debe tener un mínimo de 32 caracteres.

Si el clúster de EKS solo ejecuta cargas de trabajo de Fargate, necesitas un despliegue independiente del Cluster Agent. Además, debes elegir una de las dos opciones para hacer que el token sea accesible, como se describió arriba.

Utiliza el siguiente archivo values.yaml de Helm:

datadog:
  apiKey: <YOUR_DATADOG_API_KEY>
  clusterName: <CLUSTER_NAME>
agents:
  enabled: false
clusterAgent:
  enabled: true
  replicas: 2
  env:
    - name: DD_EKS_FARGATE
      value: "true"

En ambos casos, es necesario modificar el manifiesto del sidecar del Datadog Agent para permitir la comunicación con el Cluster Agent:

       env:
        - name: DD_CLUSTER_AGENT_ENABLED
          value: "true"
        - name: DD_CLUSTER_AGENT_AUTH_TOKEN
          value: <hardcoded token value> # Utiliza valueFrom: si usas un secreto
        - name: DD_CLUSTER_AGENT_URL
          value: https://<CLUSTER_AGENT_SERVICE_NAME>.<CLUSTER_AGENT_SERVICE_NAMESPACE>.svc.cluster.local:5005
        - name: DD_ORCHESTRATOR_EXPLORER_ENABLED # Obligatorio para obtener la vista de recursos de Kubernetes
          value: "true"
        - name: DD_CLUSTER_NAME
          value: <CLUSTER_NAME>

Rendimiento del clúster

Para obtener información sobre el rendimiento de tu clúster de EKS, habilita un Cluster Check Runner para recopilar métricas del servicio kube-state-metrics.

Recopilación de métricas

Métricas de las integraciones

Utiliza etiquetas de Autodiscovery con tu contenedor de aplicaciones de modo que puedas empezar a recopilar sus métricas para las integraciones del Agent compatibles.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: "<APPLICATION_NAME>"
 namespace: default
spec:
 replicas: 1
 selector:
   matchLabels:
     app: "<APPLICATION_NAME>"
 template:
   metadata:
     labels:
       app: "<APPLICATION_NAME>"
     name: "<POD_NAME>"
     annotations:
      ad.datadoghq.com/<CONTAINER_NAME>.check_names: '[<CHECK_NAME>]'
      ad.datadoghq.com/<CONTAINER_IDENTIFIER>.init_configs: '[<INIT_CONFIG>]'
      ad.datadoghq.com/<CONTAINER_IDENTIFIER>.instances: '[<INSTANCE_CONFIG>]'
   spec:
     serviceAccountName: datadog-agent
     containers:
     - name: "<APPLICATION_NAME>"
       image: "<APPLICATION_IMAGE>"
     ## Ejecución del Agent como sidecar
     - image: datadog/agent
       name: datadog-agent
       env:
       - name: DD_API_KEY
         value: "<YOUR_DATADOG_API_KEY>"
         ## Define DD_SITE como "datadoghq.eu" para enviar los
         ## datos del Agent al sitio de Datadog de la UE
       - 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"

Notas:

No olvides reemplazar <YOUR_DATADOG_API_KEY> por la clave de la API de Datadog de tu organización.
Las métricas de contenedores no están disponibles en Fargate porque el volumen cgroups del host no puede montarse en el Agent. La vista de Live Containers informa 0 para CPU y memoria.

DogStatsD

Configura el puerto de contenedor 8125 con el contenedor del Agent de modo que puedas reenviar las métricas de DogStatsD desde tu contenedor de aplicaciones a Datadog.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: "<APPLICATION_NAME>"
 namespace: default
spec:
 replicas: 1
 selector:
   matchLabels:
     app: "<APPLICATION_NAME>"
 template:
   metadata:
     labels:
       app: "<APPLICATION_NAME>"
     name: "<POD_NAME>"
   spec:
     serviceAccountName: datadog-agent
     containers:
     - name: "<APPLICATION_NAME>"
       image: "<APPLICATION_IMAGE>"
     ## Ejecución del Agent como sidecar
     - image: datadog/agent
       name: datadog-agent
       ## Habilitación del puerto 8125 para la recopilación de métricas de DogStatsD
       ports:
        - containerPort: 8125
          name: dogstatsdport
          protocol: UDP
       env:
       - name: DD_API_KEY
         value: "<YOUR_DATADOG_API_KEY>"
         ## Define DD_SITE como "datadoghq.eu" para enviar los
         ## datos del Agent al sitio de Datadog de la UE
       - 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"

Nota: No olvides reemplazar <YOUR_DATADOG_API_KEY> por la clave de la API de Datadog de tu organización.

Live Containers

El Datadog Agent v6.19+ admite contenedores activos en la integración de EKS Fargate. Los contenedores activos aparecen en la página Containers (Contenedores).

Procesos activos

El Datadog Agent v6.19+ admite procesos activos en la integración de EKS Fargate. Los procesos activos aparecen en la página Processes (Procesos). Para habilitar los procesos activos, habilita shareProcessNamespace en las especificaciones del pod.

Vista de recursos de Kubernetes

Para recopilar las vistas de recursos de Kubernetes, necesitas una Configuración del Cluster Agent.

Recopilación de logs

Recopilación de logs de EKS en Fargate con Fluent Bit.

Monitoriza los logs de EKS Fargate mediante Fluent Bit para enrutar los logs de EKS a CloudWatch Logs y el Datadog Forwarder para enrutar logs a Datadog.

Para configurar Fluent Bit de modo que envíe logs a CloudWatch, crea un ConfigMap de Kubernetes que especifique CloudWatch Logs como salida. El ConfigMap especifica el grupo de logs, la región, la cadena de prefijo y si se debe crear automáticamente el grupo de logs.

 kind: ConfigMap
 apiVersion: v1
 metadata:
   name: aws-logging
   namespace: aws-observability
 data:
   output.conf: |
     [OUTPUT]
         Name cloudwatch_logs
         Match   *
         region us-east-1
         log_group_name awslogs-https
         log_stream_prefix awslogs-firelens-example
         auto_create_group true

Utiliza el Datadog Forwarder para recopilar logs de CloudWatch y enviarlos a Datadog.

Recopilación de trazas

Configura el puerto de contenedor 8126 con el contenedor del Agent para recopilar las trazas de tu contenedor de aplicaciones. Obtén más información sobre cómo configurar el rastreo.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: "<APPLICATION_NAME>"
 namespace: default
spec:
 replicas: 1
 selector:
   matchLabels:
     app: "<APPLICATION_NAME>"
 template:
   metadata:
     labels:
       app: "<APPLICATION_NAME>"
     name: "<POD_NAME>"
   spec:
     serviceAccountName: datadog-agent
     ## Colocación del Agent en el mismo espacio de nombres que la aplicación para la detección del origen con cgroup v2
     shareProcessNamespace: true
     containers:
     - name: "<APPLICATION_NAME>"
       image: "<APPLICATION_IMAGE>"
     ## Ejecución del Agent como sidecar
     - image: datadog/agent
       name: datadog-agent
       ## Habilitación del puerto 8126 para la recopilación de trazas
       ports:
        - containerPort: 8126
          name: traceport
          protocol: TCP
       env:
       - name: DD_API_KEY
         value: "<YOUR_DATADOG_API_KEY>"
         ## Define DD_SITE como "datadoghq.eu" para enviar los
         ## datos del Agent al sitio de Datadog de la UE
       - 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"

Nota: No olvides reemplazar <YOUR_DATADOG_API_KEY> por la clave de la API de Datadog de tu organización.

Recopilación de eventos

Para recopilar eventos del servidor de la API de AWS EKS Fargate, ejecuta un Datadog Cluster Agent dentro de tu clúster de EKS y habilita la recopilación de eventos del Cluster Agent.

Opcionalmente, despliega los ejecutores de checks de clústeres además de configurar el Datadog Cluster Agent para habilitar las checks de clústeres.

Nota: También puedes recopilar eventos si ejecutas el Datadog Cluster Agent en un pod de Fargate.

Recopilación de procesos

Para el Agent 6.19+/7.19+, está disponible la Recopilación de procesos. Habilita shareProcessNamespace en las especificaciones del pod para recopilar todos los procesos que se estén ejecutando en el pod de Fargate. Por ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: <NAME>
spec:
  shareProcessNamespace: true
...

Nota: Las métricas de CPU y memoria no están disponibles.

Datos recopilados

Métricas

La check eks_fargate envía una métrica de frecuencia eks.fargate.pods.running que se etiqueta según pod_name y virtual_node para que puedas realizar un seguimiento de cuántos pods se están ejecutando.

Checks de servicio

eks_fargate no incluye ninguna check de servicio.

Eventos

eks_fargate no incluye ningún evento.

Solucionar problemas

¿Necesitas ayuda? Ponte en contacto con el servicio de asistencia de Datadog.

Referencias adicionales

Más enlaces, artículos y documentación útiles: