Kubernetes Explorer de Datadog vous permet de surveiller l’état des pods, des déploiements et d’autres ressources Kubernetes. Vous pouvez également afficher les spécifications des ressources pour les pods en échec au sein d’un déploiement, corréler l’activité des nœuds avec les logs associés, suivre l’utilisation des ressources, mettre à l’échelle automatiquement les workloads et corriger les erreurs.

Configuration

Activer Kubernetes Explorer

Kubernetes Explorer est activé par défaut pour la plupart des installations du Datadog Agent.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    orchestratorExplorer:
      enabled: true

datadog:
  clusterName: <CLUSTER_NAME>
  # (...)
  processAgent:
    enabled: true
  orchestratorExplorer:
    enabled: true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
kubectl create secret generic datadog-secret --from-literal api-key=$DD_API_KEY

mode: deployment
replicaCount: 1

image:
  repository: otel/opentelemetry-collector-contrib
  tag: 0.154.0
  pullPolicy: IfNotPresent

extraEnvs:
  - name: DD_API_KEY
    valueFrom:
      secretKeyRef:
        name: datadog-secret
        key: api-key

presets:
  kubernetesObjects:
    enabled: true
    watch: true

config:
  receivers:
    k8sobjects:
      interval: 3m

config:
  exporters:
    datadog:
      api:
        site: <YOUR_DATADOG_SITE>
        key: ${env:DD_API_KEY}
      orchestrator_explorer:
        enabled: true

  processors:
    resourcedetection:
      detectors: [k8s_api, eks]
      override: false
      eks:
        resource_attributes:
          k8s.cluster.name:
            enabled: true

  service:
    pipelines:
      logs:
        receivers: [k8sobjects]
        processors: [resourcedetection]
        exporters: [datadog]

  processors:
    resourcedetection:
      detectors: [k8s_api]
      override: false
    resource/add-cluster-name:
      attributes:
        - key: k8s.cluster.name
          value: <YOUR_CLUSTER_NAME>
          action: upsert

  service:
    pipelines:
      logs:
        receivers: [k8sobjects]
        processors: [resourcedetection, resource/add-cluster-name]
        exporters: [datadog]

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm install deployment-collector open-telemetry/opentelemetry-collector \
  --values ./deployment-collector.yaml

processors:
  k8sattributes:
    auth_type: "serviceAccount"
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.replicaset.name
        - k8s.statefulset.name
        - k8s.daemonset.name
        - k8s.cronjob.name
        - k8s.job.name
        - k8s.container.name
    pod_association:
      - sources:
          - from: resource_attribute
            name: k8s.pod.uid
      - sources:
          - from: resource_attribute
            name: k8s.pod.ip
      - sources:
          - from: resource_attribute
            name: k8s.pod.name
          - from: resource_attribute
            name: k8s.namespace.name
      - sources:
          - from: connection

service:
  pipelines:
    logs:
      processors: [k8sattributes, resourcedetection, ...]
    metrics:
      processors: [k8sattributes, resourcedetection, ...]
    traces:
      processors: [k8sattributes, resourcedetection, ...]

./install

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
export DD_SITE="datadoghq.com"  # for example us3.datadoghq.com, datadoghq.eu

kubectl create namespace opentelemetry-operator-system \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl create secret generic datadog-secret \
  --namespace opentelemetry-operator-system \
  --from-literal="api-key=$DD_API_KEY" \
  --from-literal="dd-site=$DD_SITE" \
  --dry-run=client -o yaml | kubectl apply -f -

mkdir -p deployment

# EKS, GKE, or AKS (resource detector auto-populates k8s.cluster.name):
cp examples/eks-deployment/values.yaml deployment/values.yaml
cp examples/gcp-deployment/values.yaml deployment/values.yaml
cp examples/aks-deployment/values.yaml deployment/values.yaml

# Other platforms (set the cluster name manually):
cp examples/manually-set-k8s-cluster-name/values.yaml deployment/values.yaml

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm upgrade --install opentelemetry-kube-stack \
  open-telemetry/opentelemetry-kube-stack \
  --namespace opentelemetry-operator-system \
  --values ./values.yaml \
  --values ./deployment/values.yaml

Ajoutez des tags personnalisés aux ressources

Pour faciliter le filtrage, vous pouvez ajouter des tags personnalisés à vos ressources Kubernetes via la variable d’environnement DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS. Ces tags n’apparaissent que dans [Kubernetes Explorer].

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    liveContainerCollection:
      enabled: true
    orchestratorExplorer:
      enabled: true
  override:
    agents:
      containers:
        processAgent:
          env:
            - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
              value: "tag1:value1 tag2:value2"
    clusterAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"

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

agents:
  containers:
    processAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"
clusterAgent:
  env:
    - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
      value: "tag1:value1 tag2:value2"

- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
  value: "tag1:value1 tag2:value2"

Utilisation

Vues

Basculez entre les Pods, Clusters, Namespaces et d’autres ressources Kubernetes dans le menu déroulant Select Resources situé dans le coin supérieur gauche de la page.

Chacune de ces vues inclut un tableau de données. Vous pouvez ainsi organiser facilement vos données par champ (statut, nom ou encore étiquettes Kubernetes). La Cluster Map détaillée vous offre une vue d’ensemble de vos pods et clusters Kubernetes.

Consultez Détails du filtre de requête pour plus de détails sur la façon de filtrer ces vues.

Grouper par fonctionnalité et facettes

Regroupez les pods par tags, labels Kubernetes ou annotations Kubernetes pour obtenir une vue agrégée qui vous permet de trouver des informations plus rapidement. Vous pouvez effectuer un regroupement en utilisant la barre « Group by » en haut à droite de la page ou en cliquant sur un tag ou un label particulier et en localisant la fonction de regroupement dans le menu contextuel, comme illustré ci-dessous.

Il est également possible d’utiliser les facettes sur la partie gauche de la page pour regrouper des ressources, ou encore pour filtrer les ressources les plus importantes, comme les pods avec un statut CrashLoopBackOff.

Carte du cluster

Une carte de cluster vous donne une vue d’ensemble de vos pods et clusters Kubernetes. Vous pouvez voir toutes vos ressources ensemble sur un seul écran avec des groupes et des filtres personnalisés, et choisir les métriques pour remplir la couleur des nœuds.

Pour examiner des ressources spécifiques depuis une Cluster Map, cliquez sur un cercle ou un groupe. Les détails s’affichent alors dans un volet distinct.

Information panel

Cliquez sur une ligne du tableau ou d’un objet dans une Cluster Map pour afficher des informations sur la ressource associée dans un volet latéral

L’onglet YAML du panneau latéral affiche la définition complète de la ressource. À partir de la version 7.44.0 de l’Agent, il inclut également sept jours d’historique des définitions. Vous pouvez comparer ce qui a changé au fil du temps et entre différentes versions. L’heure indiquée correspond approximativement au moment où les modifications ont été appliquées à la ressource.

Pour éviter de multiplier les changements inutiles, les modifications concernant uniquement les champs suivants sont ignorées :

• metadata.resourceVersion
• metadata.managedFields
• metadata.generation
• metadata.annotations["kubernetes.io/config.seen"]
• status

Les autres onglets comportent des informations supplémentaires permettant de résoudre les éventuels problèmes concernant la ressource sélectionnée :

• Logs : Affichez les logs de votre conteneur ou ressource. Cliquez sur n’importe quel log pour afficher les logs associés dans le Log Explorer.
• APM : Affichez les traces de votre conteneur ou ressource, y compris la date, le service, la durée, la méthode et le code d’état d’une trace.
• Metrics : Affichez les métriques en direct pour votre conteneur ou ressource. Vous pouvez afficher n’importe quel graphique en plein écran, en partager un instantané ou l’exporter depuis cet onglet.
• Processes : Affichez tous les processus en cours d’exécution dans le conteneur de cette ressource.
• Network : Affichez les performances réseau d’un conteneur ou d’une ressource, y compris les champs source, destination, volume envoyé et reçu, et débit. Utilisez le champ Destination pour effectuer une recherche par tags comme DNS ou ip_type, ou utilisez le filtre Group by dans cette vue pour regrouper les données réseau par tags, comme pod_name ou service.
• Événements : Affichez tous les événements Kubernetes pour votre ressource.
• Monitors : Affichez les monitors tagués, délimités ou regroupés pour cette ressource.

Pour obtenir un dashboard détaillé de cette ressource, cliquez sur l’option View Dashboard en haut à droite de ce volet.

Resource Utilization

Pour la page Resource Utilization, consultez Resource Utilization.

Dans l’onglet Kubernetes Explorer, vous pouvez explorer une sélection de métriques d’utilisation des ressources.

Toutes les colonnes de cette vue peuvent être triées, ce qui vous permet d’identifier des workloads spécifiques en fonction de leur utilisation des ressources.

Query filter details

Vous pouvez filtrer les ressources affichées en fournissant une requête dans la barre de recherche Filter by, située en haut à gauche de la page.

Syntax

Une requête de filtre est composée de termes et d’opérateurs. Exemple :

Terms

Vous pouvez utiliser plusieurs types de termes :

Remarque : Vous pourriez trouver les mêmes paires clé-valeur à la fois comme tag et comme étiquette (ou annotation)a; cela dépend de la configuration de votre cluster.

Les attributs de ressource suivants sont pris en charge dans la Correspondance de chaîne arbitraire :

• metadata.name
• metadata.uid
• Adresses IP trouvées dans :
  • Pods
  • Nœuds (internes et externes)
  • Services (IP de cluster, externes et d’équilibreur de charge)

Vous n’avez pas besoin de spécifier une clé pour rechercher une ressource par nom ou par IP. Les guillemets ne sont pas requis, sauf si votre recherche de chaîne inclut certains caractères spéciaux.

Comparators

Tous les termes prennent en charge l’opérateur d’égalité :. Metric value terms support numeric comparisons as well:

• :> Greater than (for example, metric#cpu_usage_avg15:>0.9)
• :>= Greater than or equal
• :< Less than
• :<= Less than or equal

Operators

Pour combiner plusieurs termes dans une requête complexe, vous pouvez utiliser l’un des opérateurs booléens suivants (sensibles à la casse) :

OR raccourci de valeur

Plusieurs termes partageant la même clé peuvent être combinés en un seul terme s’ils utilisent tous l’opérateur OR. Par exemple, cette requête :

app_name:web-server OR app_name:database OR app_name:event-consumer

Il est possible d’indiquer uniquement ce qui suit :

app_name:(web-server OR database OR event-consumer)

Wildcards

Vous pouvez utiliser * wildcards dans un terme pour filtrer par correspondances partielles, aussi bien pour values que pour keys. Quelques exemples :

• kube_job:stats-*: Find all resources with a kube_deployment tag value starting with stats-.
• pod_name:*canary: Find all resources with a pod_name value ending in canary.
• label#release:* : Trouver toutes les ressources avec un label release, quelle que soit sa valeur.
• -label#*.datadoghq.com/* : Trouver les ressources qui n’ont aucun Datadog scoped label.
• kube_*:*stats*canary : Trouver les ressources qui ont des tags de ressources associés (kube_*), avec stats au milieu de la valeur, se terminant également par canary.

Tags extraits

En plus des tags que vous avez configurés dans votre agent Datadog, Datadog injecte des tags générés basés sur les attributs des ressources qui peuvent répondre à vos besoins de recherche et de regroupement. Ces tags sont ajoutés aux ressources de manière conditionnelle, lorsqu’ils sont pertinents.

Toutes les ressources

Toutes les ressources possèdent le tag kube_cluster_name et toutes les ressources avec un espace de nommage possèdent le tag kube_namespace qui leur est ajouté.

De plus, les ressources contiennent un tag kube_<api_kind>:<metadata.name>. Par exemple, un déploiement nommé web-server-2 se verrait automatiquement attribuer le tag kube_deployment:web-server-2.

Remarque : Il existe quelques exceptions à ce modèle :

• Les pods utilisent pod_name à la place.
• VPA : verticalpodautoscaler.
• HPA : horizontalpodautoscaler.
• Persistent Volume Claims : persistentvolumeclaim.

Selon les étiquettes appliquées à la ressource, les tags suivants sont également extraits :

Relations

Les ressources associées se verront attribuer mutuellement des tags. Quelques exemples :

• Un pod qui fait partie du déploiement « XYZ » aura un tag kube_deployment:xyz.
• Une ingress qui pointe vers le service « A » aura un tag kube_service:a.

Les ressources générées à partir de ressources « parent » auront les tags kube_ownerref_kind et kube_ownerref_name (tels que les pods et les jobs).

Conseil : Utilisez la fonction de saisie semi-automatique des requêtes de filtrage pour découvrir quels tags de ressources associés sont disponibles. Saisissez kube_ et voyez quels résultats sont suggérés.

Pods

Les pods possèdent les tags suivants :

• pod_name
• pod_phase (extrait du manifeste)
• pod_status (calculé de la même manière que kubectl)

Workloads

Les ressources de workload (pods, déploiements, StatefulSets, etc.) possèdent les tags suivants, qui indiquent leur statut de prise en charge par la page Resources Utilization :

• resource_utilization (supported ou unsupported)
• missing_cpu_requests
• missing_cpu_limits
• missing_memory_requests
• missing_memory_limits

Conditions

Certaines conditions, pour certaines ressources, sont extraites sous forme de tags. Par exemple, vous pouvez trouver le tag kube_condition_available sur les déploiements. Le format du tag est toujours kube_condition_<name> avec une valeur true ou false.

Conseil : Utilisez la fonction de saisie semi-automatique pour découvrir quelles conditions sont disponibles sur un type de ressource donné en saisissant kube_condition et en examinant les résultats.

Tags spécifiques aux ressources

Certaines ressources possèdent des tags spécifiques qui sont extraits en fonction de l’environnement de votre cluster. Les tags suivants sont disponibles en plus des tags partagés ci-dessus.

Filtres d’utilisation des ressources

Des métriques d’utilisation de ressources sont appliquées aux ressources de workload suivantes :

• Clusters
• Nœuds
• Pods

Ces métriques sont calculées au moment de la collecte, sur la base des valeurs moyennes des 15 dernières minutes. Vous pouvez filtrer par valeurs de métrique comme suit : metric#<metric_name><comparator><numeric_value>.

• metric_name est une métrique disponible (voir ci-dessous)
• comparator est un comparateur pris en charge
• et numeric_value est une valeur à virgule flottante.

Pour les Pods, les noms de métriques suivants sont disponibles :

De plus, les métriques suivantes sont disponibles pour les clusters et nœuds :

• cpu_usage_pct_alloc_avg15
• cpu_requests_pct_alloc_avg15
• mem_usage_pct_alloc_avg15
• mem_requests_pct_alloc_avg15

Unités de mesure

Les métriques relatives au CPU sont stockées en tant que nombre de cœurs.

Les métriques relatives à la mémoire sont stockées en tant qu’octets.

Les pourcentages (*_pct_*) sont stockés sous forme de nombres à virgule flottante, où 0.0 correspond à 0% et 1.0 correspond à 100%. La valeur est le rapport des deux métriques indiquées - par exemple, cpu_usage_pct_limits_avg15 est la valeur de usage / limits. Les valeurs des métriques peuvent être supérieures à 100%, comme le pourcentage d’utilisation du processeur par les requêtes.

Remarques et problèmes connus

• Les données sont mises à jour automatiquement à intervalles constants.
• Dans les clusters avec plus de 1000 déploiements ou ReplicaSets, vous pourriez remarquer une utilisation accrue du processeur par le Cluster Agent. Il existe une option pour désactiver le nettoyage des conteneurs dans le chart Helm. Consultez le dépôt du chart Helm pour plus de détails.

Lectures complémentaires

Documentation, liens et articles supplémentaires utiles:

Surveillez vos opérateurs Kubernetes pour assurer le bon fonctionnement de vos applications.BLOG Premiers pas avec l'observabilité KubernetesCENTRE D'APPRENTISSAGE