MENU
技術系(Tips)
PR

Datadog Agent 7.52 から 7.77 への移行ガイド｜Helm chart 大幅アップグレード戦略

saratogax
記事内に商品プロモーションを含む場合があります

Spring Boot や Kubernetes 本体のアップグレード記事は多いですが、Datadog Agent のマイナーアップグレードに関する日本語の情報は意外と少ないのではないでしょうか。

この記事では、Datadog Agent を 7.52.x から 7.77.x にアップグレードする際に「何が変わるのか」「どこに注意すべきか」「どういう順番で進めるべきか」を実務者目線でまとめます。

25 マイナーバージョンのジャンプになるため、Breaking Changes の数はそれなりにあります。

ただし、結論から言うと、標準的な Kubernetes + Helm 構成であれば致命的なものは少なく、段階的に進めれば十分対応可能です。

Contents
  1. 前提条件
  2. 何が変わるのか
  3. 特に注意すべきポイント
  4. Helm chart のアップグレード
  5. アップグレードの進め方
  6. まとめ
  7. 参考リンク

前提条件

この記事は以下の構成を前提としています。

  • Kubernetes（EKS）上で Datadog Agent を DaemonSet として運用
  • Helm chart でデプロイ（datadog/datadog chart）
  • Agent と Cluster Agent のバージョンは chart デフォルトに追従

何が変わるのか

7.52 から 7.77 までの間で、特に影響の大きい変更をカテゴリごとに整理します。

Breaking Changes

バージョン変更内容影響度
7.56.0OTLP デフォルトバインドアドレスが 0.0.0.0 → localhost に変更中
7.60.0peer_tags_aggregation と compute_stats_by_span_kind がデフォルト有効（Inferred Services GA）。CPU/メモリ消費が増加する可能性中
7.61.0kubernetes.memory.working_set と kubernetes.memory.usage のメトリクス型が rate → gauge に変更大
7.62.0メトリクスのデフォルト圧縮が zlib → zstd に変更小
7.66.1K8s 1.33+ の allocatedResources JSON デシリアライズ非互換の修正大
7.67.0Agent が FQDN（末尾ドット付き *.datadoghq.com.）を使用するように変更中
7.69.0Oracle チェックの service タグが service_name に改名小
7.73.0Remote Agent Management がデフォルト有効中
7.74.0Kubelet Pod リストキャッシュがデフォルト無効に小
※表は横スクロールできます

デフォルト動作の変更

バージョン変更内容
7.54.0Kubelet コアチェックがデフォルト有効
7.57.0Orchestrator Explorer がデフォルト有効
7.62.0メトリクス・トレースのデフォルト圧縮が zstd に変更
7.65.0プロセスチェックがコア Agent 内で実行（Linux）
7.67.0ログのデフォルト圧縮も zstd に変更
7.69.0Go チェックローダーが Python より優先に
7.72.0組み込み Python が 3.12 → 3.13 に更新
7.73.0Go 版 disk/network チェックがデフォルト有効（Python 版を置換）
※表は横スクロールできます

削除された機能

バージョン削除内容
7.59.0otlp_config.debug.loglevel 設定
7.61.0runtime_security_config.policies.watch_dir
7.64.0logs.processed / logs.sent メトリクス
7.73.0SSI auto-instrumentation webhook v1
※表は横スクロールできます

特に注意すべきポイント

Breaking Changes の中でも、多くの環境で影響が出やすいものを詳しく解説します。

1. K8s 1.33+ での allocatedResources 非互換（影響度：大）

Kubernetes 1.33 で InPlacePodVerticalScaling フィーチャーゲートがベータに昇格し、デフォルト有効になりました。

これにより kubelet の /pods エンドポイントが allocatedResources フィールドをオブジェクト型で返すようになります。

しかし Agent 7.66.0 以前はこれを配列型として期待しているため、JSON デシリアライズに失敗します。

couldn’t fetch “podlist”: unable to unmarshal podlist, invalid or null:
kubelet.ContainerStatus.AllocatedResources: decode slice: expect [ or n, but found {

これは機能劣化ではなく、Pod リスト全体のパースが停止するハードエラーです。メトリクス収集やログ収集が止まります。

Agent 7.66.1 以降で修正されています（PR #36836）。

K8s 1.33 以上を使用している場合は、最低でも Agent 7.66.1 以上へのアップグレードが必須です。

なお、公式ドキュメントの互換表にもこの要件が記載されていますが、日本語版は英語版に追随できていない場合があるため、英語版も合わせて確認することを推奨します。

2. Kubernetes メモリメトリクスの型変更（影響度：大）

7.61.0 で kubernetes.memory.working_set と kubernetes.memory.usage のメトリクス型が rate から gauge に変更されました。

これらのメトリクスを使ったダッシュボードやモニターがある場合、クエリの挙動が変わる可能性があります。

確認すべきこと:

  • Datadog 上のモニターやダッシュボードで該当メトリクスを使用しているか検索する
  • avg や max で集約している場合は影響が少ないが、as_rate() や per_second() を使っている場合は修正が必要

3. FQDN 末尾ドット付き（影響度：中）

7.67.0 から、Agent が Datadog API へのリクエストで FQDN（末尾ドット付き *.datadoghq.com.）を使用するようになりました。

Agent から Datadog API に直接アクセスしている構成であれば問題ありません。

ただし、Proxy や Firewall を経由している場合は、末尾ドット付きのドメインが通過できるかルールの確認が必要です。

4. Remote Agent Management のデフォルト有効化（影響度：中）

7.73.0 から、Datadog の UI からリモートで Agent 設定を変更できる Remote Agent Management がデフォルト有効になりました。

意図しないリモート設定変更を防ぎたい場合は、明示的に無効化できます。

datadog:
  remoteConfiguration:
    enabled: false

Datadog は今後この機能をベースに運用改善を提供していく方向のため、まずは検証環境で有効のまま様子を見て判断するのもよいでしょう。

5. OTLP バインドアドレスの変更（影響度：中）

7.56.0 で、OTLP のデフォルトバインドアドレスが 0.0.0.0 から localhost に変更されました。

OTLP を使用していない場合は影響ありません。OTLP インジェストを外部から受け付けている場合は、明示的にバインドアドレスを設定する必要があります。

Helm chart のアップグレード

Agent のバージョンは Helm chart のバージョンに紐づいています。例えば chart 3.201.3 のデフォルトは Agent 7.77.1 です。

chart のバージョン差が大きい場合（例: 3.59.6 → 3.201.3）、chart 側にも Breaking Changes があります。

Helm chart の主な Breaking Changes

chart バージョン変更内容
3.135.1createPodDisruptionBudget が非推奨 → pdb ブロックに移行
3.149.0readOnlyRootFilesystem がデフォルト有効化 → 3.150.0 で revert
3.158.0datadog.processAgent.runInCoreAgent 非推奨
3.164.0datadogGenericResource / datadogSLO コントローラがデフォルト無効に
3.195.0〜3.197.1registryMigrationMode: "auto" 導入（イメージ取得元の変更）
※表は横スクロールできます

Datadog Operator の自動デプロイに注意

chart 3.201.3 では、Datadog Operator がデフォルトでデプロイされるようになっています。

Operator を使用しない場合は、values.yaml で明示的に無効化する必要があります。

datadog:
  operator:
    enabled: false

無効化しないと、CRD 5 つ + Operator の Deployment が新規作成されます。Operator 自体に実害はありませんが、不要なリソースが増えることになります。

なお、無効化のキーは datadog.operator.enabled です。operators.enabled のようなトップレベルキーでは効きません。

Helm は未知のキーを無視するため、タイポに気づきにくい点に注意してください。

Orchestrator Explorer との整合性

chart 3.201.3 では DD_ORCHESTRATOR_EXPLORER_KUBELET_CONFIG_CHECK_ENABLED=true がデフォルトで設定されます。

orchestratorExplorer.enabled: false にしている場合、以下のようなエラーログが出力されます。

Unable to load a check from instance of config ‘orchestrator_kubelet_config’:
Core Check Loader: refused to load the check instance: orchestrator kubelet_config check is enabled but the orchestration collection is disabled

解消するには、values.yaml で kubelet configuration check も無効化します。

datadog:
  orchestratorExplorer:
    enabled: false
    kubelet_configuration_check:
      enabled: false

キーは kubelet_configuration_check です。kubelet_check ではないので注意してください。

アップグレードの進め方

25 マイナーバージョンのジャンプを安全に行うための、段階的なアプローチを紹介します。

Phase 1: 事前調査

やること

  • Helm chart の CHANGELOG を確認し、現在の values.yaml に影響する Breaking Changes を特定する
  • Datadog 上のモニターやダッシュボードで kubernetes.memory.working_set / kubernetes.memory.usage を使用しているか検索する
  • Agent → Datadog API 間に Proxy や Firewall がある場合、FQDN 末尾ドットの通過を確認する
  • カスタム Python チェックを使用している場合、Python 3.13 との互換性をテストする（7.72.0 で組み込み Python が更新）
  • OTLP を使用している場合、datadog.* 属性から標準 OTel セマンティック規約への移行を計画する

Phase 2: 検証環境でのデプロイ

やること

  • Helm chart と Agent を一括でアップグレードする（chart バージョンを上げれば Agent は chart デフォルトが適用される）
  • デプロイ前に helm template や PipeCD の plan-preview などで差分を確認する
  • 特に、意図しない新規リソース（Datadog Operator 等）が追加されていないか確認する
  • デプロイ後、数日間は以下を重点的に監視する:
    • メトリクス収集の正常性
    • ログ収集の継続
    • APM トレースの到達
    • Agent Pod の安定性（CrashLoopBackOff がないか）
    • Agent のエラーログ

Phase 3: 本番環境への適用

やること

  • 検証環境での動作確認結果を元に、手順書を作成する
  • ステージング環境でリハーサルを行い、数日間様子を見る
  • 問題がなければ本番環境に適用する
  • DaemonSet のローリングアップデートにより、ノード単位で順次更新される

まとめ

Datadog Agent 7.52 から 7.77 へのアップグレードは、25 マイナーバージョンのジャンプですが、標準的な Kubernetes + Helm 構成であれば致命的な問題は少ないです。

  • K8s 1.33 以上なら必須 — allocatedResources の非互換があるため、最低でも Agent 7.66.1 以上が必要
  • Helm chart も一緒に上げる — Agent イメージだけ差し替えると、RBAC 権限や環境変数の不足で問題が起きる可能性がある
  • 段階的にデプロイする — 検証 → ステージング → 本番の順で、各環境で数日間の動作確認を挟む

chart のバージョン差が大きい場合は、helm template で出力される差分を事前にしっかり確認しましょう。意図しない新規リソースの追加や、values.yaml のキー名変更に気づけるかどうかがポイントです。

段階的に、着実に進めていきましょう。

参考リンク

ABOUT ME
saratoga
saratoga
フリーランスエンジニア
YouTube
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
Recommend
こんな記事も読まれています
記事URLをコピーしました