Datadog の Kubernetes Explorer を使用すると、Pod、Deployment、その他の Kubernetes リソースの状態を監視できます。Deployment 内の失敗した Pod のリソース仕様を表示したり、ノードのアクティビティを関連するログと関連付けたり、リソース使用状況を追跡したり、ワークロードを自動的にスケーリングしたり、エラーを修正したりすることもできます。

構成

Kubernetes Explorer を有効にする

Kubernetes Explorer は、ほとんどの 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

リソースにカスタムタグを追加する

フィルタリングを容易にするために、DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS 環境変数を使用して Kubernetes リソースにカスタムタグを追加できます。これらのタグは、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"

使用方法

ビュー

ページ左上隅の Select Resources ドロップダウンメニューで、Pods、Clusters、Namespaces、およびその他の Kubernetes リソースを切り替えます。

これらの各ビューには、ステータス、名前、Kubernetes ラベルなどのフィールドごとにデータを整理しやすくするためのデータテーブルと、Pod および Kubernetes クラスターの全体像を把握するための詳細なクラスターマップが含まれています。

これらのビューのフィルタリング方法の詳細については、クエリフィルターの詳細を参照してください。

機能やファセットでグループ化する

タグ、Kubernetes ラベル、または Kubernetes アノテーションで Pod をグループ化すると、集約されたビューで情報をより迅速に見つけられるようになります。ページ右上の [Group by] (グループ化の基準) バーを使用するか、特定のタグやラベルをクリックしてコンテキストメニューからグループ化機能を見つけ、次のようにグループ化できます。

また、ページ左側のファセットを使用してリソースをグループ化したり、最も注意すべきリソース (ステータスが CrashLoopBackOff の Pod など) をフィルタリングしたりすることもできます。

クラスターマップ

クラスターマップを使用すると、Pod と Kubernetes クラスターの全体像を把握できます。カスタマイズされたグループとフィルターを使用してすべてのリソースを 1 つの画面でまとめて表示し、ノードの色付けに使用するメトリクスを選択できます。

クラスターマップ上の円やグループをクリックして詳細パネルを表示し、リソースを調査します。

情報パネル

テーブルの行またはクラスターマップのオブジェクトをクリックすると、サイドパネルで特定のリソースに関する情報を表示できます。

サイドパネルの YAML タブには、リソースの完全な定義が表示されます。Agent バージョン 7.44.0 以降では、7 日間の定義の履歴も含まれます。時間の経過に伴う変更や、異なるバージョン間での変更を比較できます。表示される時刻は、リソースに変更が適用されたおおよその時刻です。

関連性のない変更が大量に表示されるのを防ぐため、次のフィールドのみに影響する更新は無視されます。

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

その他のタブには、選択したリソースのトラブルシューティングに役立つ詳細情報が表示されます。

• Logs (ログ): コンテナまたはリソースのログが表示されます。ログをクリックすると、関連するログが Log Explorer で表示されます。
• APM: 日付、サービス、期間、メソッド、ステータスコードなど、コンテナまたはリソースのトレースが表示されます。
• Metrics (メトリクス): コンテナまたはリソースのライブメトリクスが表示されます。このタブでは、グラフを全画面表示し、そのスナップショットを共有したりエクスポートしたりできます。
• Processes: このリソースのコンテナで実行されているすべてのプロセスが表示されます。
• Network: 送信元、送信先、送受信ボリューム、スループットのフィールドなど、コンテナまたはリソースのネットワークパフォーマンスが表示されます。Destination フィールドを使用して DNS や ip_type のようなタグで検索するか、このビューの Group by フィルターを使用して pod_name や service のようなタグごとにネットワークデータをグループ化します。
• Events (イベント): リソースのすべての Kubernetes イベントが表示されます。
• Monitors: このリソースに対してタグ付け、スコープ設定、またはグループ化されたモニターが表示されます。

このリソースの詳細なダッシュボードを表示するには、このパネルの右上隅にある [View Dashboard] (ダッシュボードの表示) をクリックします。

リソース使用状況

_リソース使用状況_ページについては、こちらをご覧ください。

Kubernetes Explorer タブ内で、各種のリソース使用状況メトリクスを参照できます。

これらの列はすべて並べ替えに対応しており、リソース使用状況に基づいて個々のワークロードを特定するのに役立ちます。

クエリフィルターの詳細

ページ左上の [Filter by] (フィルターの基準) 検索バーにクエリを入力することで、表示されるリソースを絞り込むことができます。

構文

クエリフィルターは条件と演算子で構成されます。例:

条件

利用可能な条件のタイプは複数あります。

注: 同じキーと値のペアがタグとラベル (またはアノテーション) の両方として見つかる場合があります。これはクラスターの構成方法に依存します。

次のリソース属性は、任意の文字列一致でサポートされています。

• metadata.name
• metadata.uid
• 検出された IP アドレス:
  • Pod
  • ノード (内部および外部)
  • サービス (クラスター、外部、およびロードバランサーの IP)

名前または IP でリソースを検索する場合、キーを指定する必要はありません。文字列検索に特定の特殊文字が含まれていない限り、引用符は不要です。

比較演算子

すべての条件で : 等価演算子がサポートされています。メトリクス値の条件では、数値比較もサポートされます。

• :> より大きい (例: metric#cpu_usage_avg15:>0.9)
• :>= 以上
• :< より小さい
• :<= 以下

演算子

複合クエリで複数の条件を組み合わせるには、大文字と小文字を区別する次のブール演算子を使用します。

OR の値の省略

同じキーを共有する複数の条件で、すべてが OR 演算子を使用している場合、単一の条件にまとめることができます。たとえば、次のクエリがあるとします。

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

次のように短縮できます。

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

ワイルドカード

* ワイルドカードを条件の一部として使用し、値とキーの両方で部分一致によるフィルタリングを行うことができます。以下はその例です。

• kube_job:stats-*: stats- で始まる kube_deployment タグ値を持つすべてのリソースを検索します。
• pod_name:*canary: canary で終わる pod_name 値を持つすべてのリソースを検索します。
• label#release:*: ラベルの値に関係なく、release ラベルを持つすべてのリソースを検索します。
• -label#*.datadoghq.com/*: Datadog のスコープ設定されたラベルを持たないリソースを検索します。
• kube_*:*stats*canary: 関連するリソースタグ (kube_*) を持ち、値の途中に stats が含まれ、canary で終わるリソースを検索します。

抽出されるタグ

ユーザーが Datadog エージェント内で設定したタグに加えて、Datadog はリソース属性に基づいて生成されたタグを挿入します。これは、検索やグループ化のニーズに役立ちます。これらのタグは、関連がある場合に条件付きでリソースに追加されます。

すべてのリソース

すべてのリソースに kube_cluster_name タグがあり、名前空間があるリソースにはさらに kube_namespace タグが追加されます。

さらに、リソースには kube_<api_kind>:<metadata.name> タグが含まれます。たとえば、web-server-2 という名前の Deployment には kube_deployment:web-server-2 タグが自動的に追加されます。

注: このパターンにはいくつかの例外があります。

• Pod には pod_name が代わりに使用されます。
• VPA: verticalpodautoscaler。
• HPA: horizontalpodautoscaler。
• Persistent Volume Claim: persistentvolumeclaim。

リソースに付与されたラベルに基づいて、次のタグも抽出されます。

リレーションシップ

関連するリソースには互いのタグが付与されます。以下はその例です。

• 「XYZ」Deployment の一部である Pod には、kube_deployment:xyz タグが付与されます。
• Service「A」を指すイングレスには、kube_service:a タグが付与されます。

「親」リソースから生成されたリソース (Pod や Job など) には、kube_ownerref_kind タグと kube_ownerref_name タグが付与されます。

ヒント: フィルタークエリのオートコンプリート機能を利用すると、利用可能な関連リソースタグを確認できます。kube_ と入力して、どのような結果が提案されるかを確認してください。

Pod

Pod には次のタグが付与されます。

• pod_name
• pod_phase (マニフェストから抽出)
• pod_status (kubectl と同様に計算)

ワークロード

ワークロードリソース (Pod、Deployment、StatefulSet など) には、リソース使用状況ページでの対応状況を示す次のタグが付与されます。

• resource_utilization (supported または unsupported)
• missing_cpu_requests
• missing_cpu_limits
• missing_memory_requests
• missing_memory_limits

条件

一部のリソースについては、特定の条件がタグとして抽出されます。たとえば、Deployment には kube_condition_available タグがあります。タグの形式は常に kube_condition_<name> で、値は true または false です。

ヒント: オートコンプリート機能を使用し、kube_condition と入力して結果を確認することで、特定のリソースタイプで利用可能な条件を見つけることができます。

リソース固有のタグ

一部のリソースには、クラスターの環境に基づいて抽出される固有のタグがあります。上記の共有タグに加えて、次のタグが利用可能です。

リソース使用状況フィルター

次のワークロードリソースには、リソース使用状況メトリクスが付加されます。

• クラスター
• ノード
• Pod

これらのメトリクスは、収集時に過去 15 分間の平均値に基づいて計算されます。metric#<metric_name><comparator><numeric_value> の形式を使用してメトリクス値でフィルタリングできます。

• metric_nameは利用可能なメトリクス (下記を参照)
• comparator はサポートされている比較演算子
• numeric_value は浮動小数点値

Pod については、次のメトリクスが利用可能です。

さらに、クラスターおよびノードでは、次のメトリクスが利用可能です。

• cpu_usage_pct_alloc_avg15
• cpu_requests_pct_alloc_avg15
• mem_usage_pct_alloc_avg15
• mem_requests_pct_alloc_avg15

メトリクスの単位

CPU メトリクスはコア数として保存されます。

メモリメトリクスはバイト数として保存されます。

パーセント (*_pct_*) は浮動小数点数として保存され、0.0 は 0%、1.0 は 100% となります。値は、示された 2 つのメトリクスの比率です。たとえば、cpu_usage_pct_limits_avg15 は usage / limits の値です。メトリクスの値は、リクエストの CPU 使用率 (パーセント) のように、100% を超える場合があります。

注意点と既知の問題

• データは一定の間隔で自動的に更新されます。
• 1000 個以上の Deployment または ReplicaSet があるクラスターでは、Cluster Agent による CPU 使用率の上昇が見られる場合があります。Helm チャートには、コンテナのスクラビングを無効にするオプションがあります。詳細については、Helm チャートリポジトリを参照してください。

参考資料

役立つドキュメント、リンク、記事:

Kubernetes オペレーターをモニターしてアプリケーションがスムーズに動作するようにするブログ Kubernetes Observability の開始ラーニングセンター