インフラストラクチャ Kubernetes

Dynatrace DQL を使用して Kubernetes インフラストラクチャを監視・分析します。クラスタリソースのクエリ、 ワークロードヘルスの監視、ポッド配置の分析、コスト最適化、セキュリティ体勢の評価を行います。

このスキルを使用する場合

• Kubernetes クラスタのヘルスと容量の監視
• ポッドとコンテナのリソース利用率の分析
• ポッド障害、OOMKill、削除、またはクラッシュループの調査
• 劣化したデプロイメント、スタックしたロールアウト、またはノード圧力のデバッグ
• Kubernetes リソースコストの最適化
• セキュリティ体勢とコンプライアンスの評価
• ワークロード スケジュール配置と配置のトラブルシューティング
• イングレスルーティングとネットワークポリシーの監査

ナレッジベース構造

コア監視 (ここからスタート)

1. クラスタインベントリ → references/cluster-inventory.md - クラスタ、 名前空間、リソース分配
2. ノード監視 - ノード容量、CPU/メモリ使用量、ポッド密度
3. ポッド監視 - ポッド CPU、メモリ、ライフサイクルイベント
4. ワークロード監視 - Deployment、StatefulSet、DaemonSet リソース

高度なトピック

1. 構成分析 → references/labels-annotations.md - k8s.object、ラベル、 アノテーションの解析
2. スケジュール配置 → references/pod-node-placement.md - ノードセレクタ、 アフィニティ、テイント、HA
3. コスト最適化 - 適切なサイジング、廃棄検出、効率スコアリング
4. セキュリティとコンプライアンス - 特権コンテナ、セキュリティコンテキスト

主要な概念

エンティティタイプ

ワークロード: K8S_DEPLOYMENT、K8S_STATEFULSET、K8S_DAEMONSET、 K8S_JOB、K8S_CRONJOB、K8S_HORIZONTALPODAUTOSCALER
インフラストラクチャ: K8S_CLUSTER、K8S_NAMESPACE、K8S_NODE、K8S_POD
構成: K8S_SERVICE、K8S_CONFIGMAP、K8S_SECRET、 K8S_PERSISTENTVOLUMECLAIM、K8S_PERSISTENTVOLUME、K8S_INGRESS、 K8S_NETWORKPOLICY

クエリタイプ

smartscapeNodes - K8s エンティティのクエリ:

smartscapeNodes K8S_POD
| filter k8s.namespace.name == "production"
| fields k8s.cluster.name, k8s.pod.name

timeseries - メトリクスを時系列で監視:

timeseries cpu = sum(dt.kubernetes.container.cpu_usage),
  by: {k8s.pod.name, k8s.namespace.name}
| fieldsAdd avg_cpu = arrayAvg(cpu)

fetch logs - ログイベントを分析:

fetch logs
| filter k8s.namespace.name == "production" and loglevel == "ERROR"

コアフィールド

• k8s.cluster.name、k8s.namespace.name、k8s.pod.name、k8s.node.name
• k8s.workload.name、k8s.workload.kind、k8s.container.name
• k8s.object - 深い検査のための完全な JSON 構成
• tags[label] - ラベルとアノテーションへのアクセス

利用可能なメトリクス

CPU: dt.kubernetes.container.cpu_usage、cpu_throttled、limits_cpu、 requests_cpu
メモリ: dt.kubernetes.container.memory_working_set、limits_memory、 requests_memory
オペレーション: dt.kubernetes.container.restarts、oom_kills
ノード: dt.kubernetes.node.pods_allocatable、cpu_allocatable、 memory_allocatable、dt.kubernetes.pods

エンティティの曖昧さ解消

K8S_POD と CONTAINER は Dynatrace の異なるエンティティタイプです。

• K8S_POD — k8s.object JSON、スケジュール状態、条件、K8s メトリクスを備えた K8s ネイティブエンティティ。このスキルを使用してください。
• CONTAINER — ホストレベルのコンテナインベントリ (イメージ、ライフタイム、ホスト割り当て)。代わりに dt-obs-hosts スキルを使用してください。

smartscape エッジは CONTAINER --(is_part_of)--> K8S_POD です。ポッドからコンテナに到達するには、逆方向に移動します:

smartscapeNodes K8S_POD
| filter k8s.namespace.name == "<namespace>"
| traverse edgeTypes: {is_part_of}, targetTypes: {CONTAINER}, direction: backward, fieldsKeep: {id}
| fields k8s.cluster.name, k8s.namespace.name, k8s.pod.name, container.id=id

Service → K8S_POD 相関

SERVICE と K8S_POD の間に直接的な smartscape エッジは存在しません。相関キーは共有ディメンション k8s.workload.name です。references/pod-debugging.md の Service → Pod Drill-Down で完全な2段階パターンを参照してください。

一般的なワークフロー

1. クラスタヘルスチェック

すべてのクラスタを一覧表示:

smartscapeNodes K8S_CLUSTER
| fields k8s.cluster.name, k8s.cluster.version, k8s.cluster.distribution

ノード容量を確認:

timeseries {
  current_pods = avg(dt.kubernetes.pods),
  max_pods = avg(dt.kubernetes.node.pods_allocatable)
}, by: {k8s.node.name, k8s.cluster.name}
| fieldsAdd pod_capacity_pct = (arrayAvg(current_pods) / arrayAvg(max_pods)) * 100
| filter pod_capacity_pct > 80

Running 以外の状態のポッドを識別:

smartscapeNodes K8S_POD
| parse k8s.object, "JSON:config"
| fieldsAdd phase = config[status][phase]
| filter phase != "Running"
| fields k8s.cluster.name, k8s.namespace.name, k8s.pod.name, phase

2. リソース最適化

オーバープロビジョニングされたポッドを検出 (使用量 < 30%):

timeseries {
  cpu_usage = sum(dt.kubernetes.container.cpu_usage),
  cpu_requests = avg(dt.kubernetes.container.requests_cpu)
}, by: {k8s.pod.name, k8s.namespace.name, k8s.cluster.name}
| fieldsAdd usage_pct = (arrayAvg(cpu_usage) / arrayAvg(cpu_requests)) * 100
| filter usage_pct < 30 and arrayAvg(cpu_requests) > 0

リソースリミットのないコンテナを識別:

smartscapeNodes K8S_POD
| parse k8s.object, "JSON:config"
| expand container = config[spec][containers]
| fieldsAdd
    container_name = container[name],
    cpu_limit = container[resources][limits][cpu],
    memory_limit = container[resources][limits][memory]
| filter isNull(cpu_limit) or isNull(memory_limit)

3. ポッドの問題のトラブルシューティング

ポッドのトラブルシューティングは メトリクス (timeseries) と Kubernetes イベント (イベントストリーム) を組み合わせることで、完全な概要が得られます。

メトリクスベースのトラブルシューティング

OOMKill が発生したポッドを検出:

timeseries oom_kills = sum(dt.kubernetes.container.oom_kills),
  by: {k8s.pod.name, k8s.namespace.name, k8s.cluster.name}
| filter arraySum(oom_kills) > 0
| fieldsAdd total_oom_kills = arraySum(oom_kills)
| sort total_oom_kills desc

ポッド再起動パターンを分析:

timeseries restarts = sum(dt.kubernetes.container.restarts),
  by: {k8s.pod.name, k8s.namespace.name, k8s.cluster.name}
| fieldsAdd total_restarts = arraySum(restarts)
| filter total_restarts > 5

イベントベースのトラブルシューティング

オペレーショナルイベント (ポッド再起動、OOMKill、削除、スケジュール失敗) については、 Kubernetes イベントはメトリクスだけでは得られない豊かなコンテキストを提供します — イベント理由、メッセージ、タイムスタンプを含みます。

Kubernetes イベントをメトリクスの代わりに使用する場合:

• ユーザーが最近のオペレーショナルイベントについて質問した場合 ("ポッド再起動イベントを表示")
• ユーザーが理由やメッセージなどのイベント詳細を望んでいる場合
• ユーザーが特定の時間ウィンドウ内のイベントについて質問した場合 ("過去48時間")
• ユーザーがイベントを根本原因と相関させたい場合

Kubernetes イベント は get-events-for-kubernetes-cluster ツールを通じて利用可能です。ユーザーが OOM イベント、ポッド再起動、 削除、またはクラスタ全体のイベント履歴について質問した場合は、このツールを優先してください。

重要: 結果をフィルタリングするときはイベントタイプを区別してください。 Kubernetes イベントは多くのカテゴリをカバーしています。ユーザーが特定のイベントタイプについて質問した場合、結果を適切にフィルタリングしてください — 関連のないイベントは報告しないでください:

ユーザーが質問する内容	関連するイベント理由	関連していない
ポッド再起動	BackOff、CrashLoopBackOff、Killing	Readiness プローブの失敗、CPU スロットリング
OOM イベント	OOMKilling、OOMKilled	メモリ圧力警告
削除	Evicted、Preempting	ノード圧力
スケジュール失敗	FailedScheduling、Unschedulable	リソースクォータ

完全な回答のために、両方のアプローチを組み合わせます:

1. イベントツール を使用してイベント詳細を取得 (何が起こったか、いつ、なぜ)
2. timeseries メトリクス を使用して定量的な影響を表示 (再起動回数、 時系列上の OOMKill カウント)

DQL を介した Kubernetes イベントの取得

ポッド再起動とオペレーショナルイベントは、イベントテーブルから DQL 経由でクエリできます:

fetch events
| filter event.kind == "K8S_EVENT"
| filter event.type == "Warning"
| fields timestamp, k8s.cluster.name, k8s.namespace.name, k8s.pod.name,
    event.reason, event.message
| sort timestamp desc
| limit 50

特定のイベント理由でフィルタリング:

fetch events
| filter event.kind == "K8S_EVENT"
| filter in(event.reason, {"OOMKilling", "BackOff", "Evicted", "FailedScheduling"})
| fields timestamp, k8s.cluster.name, k8s.namespace.name, k8s.pod.name,
    event.reason, event.message
| sort timestamp desc

fetch events のフィールド名: event.reason と event.message を使用してください — dt.kubernetes.event.reason ではありません。dt.kubernetes.* プレフィックスは timeseries メトリクス用で、イベントテーブル用ではありません。間違ったプレフィックスを使用するクエリは結果を返しません。

4. セキュリティ評価

特権コンテナを識別:

smartscapeNodes K8S_POD
| parse k8s.object, "JSON:config"
| expand container = config[spec][containers]
| fieldsAdd
    container_name = container[name],
    privileged = container[securityContext][privileged]
| filter privileged == true

root として実行されているコンテナを検出:

smartscapeNodes K8S_POD
| parse k8s.object, "JSON:config"
| expand container = config[spec][containers]
| fieldsAdd
    container_name = container[name],
    run_as_user = container[securityContext][runAsUser],
    run_as_non_root = container[securityContext][runAsNonRoot]
| filter (isNull(run_as_user) or run_as_user == 0) and run_as_non_root != true

5. スケジュール分析

ポッド分配を検証 (HA コンプライアンス):

smartscapeNodes K8S_POD
| filter k8s.workload.kind == "deployment"
| summarize pod_count = count(),
            node_count = countDistinct(k8s.node.name),
            by: {k8s.cluster.name, k8s.namespace.name, k8s.workload.name}
| fieldsAdd ha_compliant = node_count > 1
| filter pod_count >= 2 and not ha_compliant

6. K8s エンティティに影響を与える DAVIS の問題

K8s エンティティに影響を与えるアクティブな DAVIS 問題を検出:

fetch dt.davis.problems, from:now() - 2h
| filter not(dt.davis.is_duplicate) and event.status == "ACTIVE"
| filter matchesPhrase(smartscape.affected_entity.types, "K8S_")
| fields display_id, event.name, event.category, smartscape.affected_entity.ids

エントリ smartscape.affected_entity.ids (Smartscape ID の配列) を使用して、Smartscape ID を使用して影響を受けたエンティティを検索します。

ベストプラクティス

適切なデータソースの選択

ユーザーの質問	ベストなアプローチ	理由
"OOM イベントを表示"	イベントツール + メトリクス	イベントは理由/メッセージを提供、メトリクスはトレンドを表示
"ポッド再起動イベントを表示"	イベントツール + timeseries メトリクス	イベントは理由を明らかに (BackOff、Killing、CrashLoopBackOff)、dt.kubernetes.container.restarts メトリクスは実際の再起動カウント を提供
"ポッド再起動の数は?"	Timeseries メトリクス	時系列上の定量的データ
"過去48時間、ポッドに何が起こったか?"	イベントツール	コンテキスト付きのオペレーショナルイベント履歴
"最も CPU を使用しているポッドは?"	Timeseries メトリクス	リソース利用率分析
"すべてのクラスタ/名前空間を一覧表示"	smartscapeNodes	エンティティ検出とインベントリ
"スケジュール失敗はあるか?"	イベントツール	イベント理由が失敗の理由を説明

クエリパフォーマンス

1. 早期にフィルタリング - クラスタ/名前空間フィルタをすぐに適用
2. 特定のエンティティタイプを使用 - ワイルドカードを避ける
3. 結果セットを制限 - 探索に limit を使用
4. クラスタリストをキャッシュ - 変数に保存

監視の推奨事項

1. すべてのコンテナにリソースリミットを設定
2. OOMKill を監視し、メモリリミットを調整
3. CPU スロットリングを追跡し、CPU リミットを調整
4. リソース効率を定期的にレビュー (70-80% が目標)
5. セキュリティベストプラクティスを実装 (非root、読み取り専用ファイルシステム)
6. 特定のイメージタグを使用 (:latest は避ける)

構成標準

1. 組織用ラベルを使用 (app、environment、team)
2. リソースリクエストとリミットを設定
3. ヘルスチェックを構成 (liveness/readiness プローブ)
4. すべてのイングレスリソースに TLS を使用
5. アノテーションでドキュメント化

トラブルシューティング

問題	原因	ソリューション
ポッドデータが返されない	不正なエンティティタイプまたはクラスタフィルタの欠落	K8S_POD を使用 (POD ではない)、k8s.cluster.name フィルタを追加
k8s.object パースエラー	複雑な JSON 構造	parse k8s.object, "JSON:config" を使用してから、ネストされたフィールドにアクセス
ポッドネットワークメトリクスが利用不可	Grail で利用できない	サービスメッシュメトリクスまたはホストレベルのネットワークメトリクスを使用
大きな結果セット	時間範囲またはクラスタフィルタの欠落	時間範囲を追加し、早期にクラスタ/名前空間でフィルタリング
出力にラベルが不足	ラベルへのアクセス方法が不正	tags[label_name] を使用してラベルにアクセス

制限事項

利用不可のメトリクス:

• ポッドネットワークメトリクス (rx_bytes、tx_bytes) は Grail では利用できません
• 回避策: サービスメッシュメトリクスまたはホストレベルのネットワークメトリクスを使用

クエリの考慮事項:

• 結果セットのサイズを最小化: 必要がない場合は k8s.object フィールドを含めない
• 結果セットをできるだけシンプルに: k8s.object の解析はクエリの複雑さを増加させる
• 大規模なクラスタはページング分割または時間範囲リミットが必要な場合があります
• 一部の K8s ステータスフィールドは非同期に更新されます

参照をロードする場合

cluster-inventory.md をロードする場合:

• クラスタ、名前空間、またはリソース分配分析を実行
• クラスタ全体のワークロード数を監査

→ references/cluster-inventory.md

labels-annotations.md をロードする場合:

• ラベルまたはアノテーションでフィルタリング
• 詳細な構成検査のために k8s.object を解析

→ references/labels-annotations.md

pod-node-placement.md をロードする場合:

• スケジュール制約 (アフィニティ、テイント、容認) を分析
• HA コンプライアンスとポッド分配を検証

→ references/pod-node-placement.md

pod-debugging.md をロードする場合:

• ポッド終了コード、クラッシュループ、またはイニシャルコンテナの失敗を調査
• イメージプルエラーまたはサービス間ポッド接続の問題を診断
• サービスの問題からポッドレベルの詳細にドリルダウン

→ references/pod-debugging.md

workload-health.md をロードする場合:

• 劣化したデプロイメントまたはスタックしたロールアウトを調査
• ノード条件、CPU スロットリング、または HPA スケーリングを確認
• StatefulSet 順序付けまたは DaemonSet カバレッジを分析

→ references/workload-health.md

pv-pvc.md をロードする場合:

• 永続的なストレージ (PVC/PV ライフサイクル、孤立したボリューム) を処理
• StorageClass 構成を確認

→ references/pv-pvc.md

ingress.md をロードする場合:

• イングレスルーティングルールまたは TLS 証明書を分析
• イングレスコントローラの構成を監査

→ references/ingress.md

network-policies.md をロードする場合:

• ネットワークポリシーを一覧表示または監査
• 名前空間分離構成を確認

→ references/network-policies.md

参考資料

• cluster-inventory.md — クラスタ、名前空間、リソース分配分析
• labels-annotations.md — ラベル/アノテーションフィルタリングと k8s.object 解析
• pod-node-placement.md — スケジュール、アフィニティ、テイント、HA パターン
• pod-debugging.md — 終了コード、ポッド条件、イニシャルコンテナ、イメージプルエラー、ログ、サービス間ポッドドリルダウン
• workload-health.md — 劣化したデプロイメント、スタックしたロールアウト、ノード条件、CPU スロットリング、HPA、StatefulSet 順序付け
• pv-pvc.md — PVC/PV ライフサイクル、フェーズ参照、孤立したボリューム、StorageClass
• ingress.md — ルーティングルール解析、TLS 監査
• network-policies.md — ポリシーリスト、名前空間分離監査

関連スキル

• dt-obs-problems — Kubernetes クラスタに関連する問題用 (dt.smartscape_source.id を K8S_ プレフィックスフィルタ付きで使用)
• dt-dql-essentials — コア DQL シンタックスとクエリ構造
• dt-obs-hosts — K8s ノード用のホストレベルメトリクス