Kubernetesヘルスモニタリング

​

シナリオ

Kubernetesの手動トラブルシューティングの課題

​

ウォークスルー

1

Kai をクラスターに接続する

2

Kubernetes接続ガイドに従い、Kai にEKSクラスターへのアクセス権を付与します。接続がConnectedと表示されたら、Kai はクラスターを直接クエリできます。

3

ポッドのリソース使用率を分析する

4

@kai #report analyze pod resource utilization in production namespace

5

6

ポッドリソース使用率分析

7

8

パフォーマンス推奨事項を伴うポッド分析の可視化

9

Kai は3つの知見を表面化します。auth-serviceとnotification-workerは過剰プロビジョニング（CPU使用率18〜21%）、api-gatewayとcache-redisは適切なサイズ、そしてpayment-processorはCPU 80〜86%・メモリ 88〜94%と危険なほど過小プロビジョニングされており、OOMキルとサービス障害の高リスク状態にあります。

10

活用不足のノードを特定する

11

@kai #chart identify nodes with <30% CPU utilization

12

13

活用不足のインスタンスを示すノードCPU使用率分析

14

Kai は平均CPU使用率が30%未満（最低12〜15%のものもある）の5つのノードを発見し、月額約573ドルを無駄にしていることを特定します。軽量ワークロードで動作する過大サイズのt3.xlargeインスタンスと不適切なポッドスケジューリングの組み合わせにより、一部のノードにはポッドが2〜3個しかない一方、他のノードには8〜9個が集中しています。

15

HPA推奨事項を取得する

16

@kai #recommend HPA policies for web deployments

17

18

オートスケーリングのためのHPAポリシー推奨事項

19

Kai はpayment-processorをクリティカルリスクとして特定します——レプリカが2つのみでCPU使用率は80〜86%、オートスケーリングは未設定です。api-gatewayにはトラフィックスパイクに対応するHPAの追加を推奨し、user-serviceとauth-serviceからは余剰キャパシティの削除を推奨します。

​

成果の要因

• Kai がクラスターAPIを直接クエリし、手動の kubectl セッションとツール切り替えを置き換えます。
• クロスレイヤー相関により、ポッドの使用率・ノードキャパシティ・スケジューリングパターンを単一の分析パスでリンクします。
• #report と #chart が、Kai が知見を表面化する前に推論できる構造化された出力を生成します。
• #recommend が生のメトリクスダンプではなく、実行可能なHPAポリシー変更を生成します。
• CloudKeepers がこの分析をスケジュール実行することで、オンコールエンジニアがページを受け取る前に知見が届きます。

​

試してみる

Kai エージェントリファレンス

KubernetesエンジニアエージェントKai の全機能

Kubernetes接続

CloudThinkerをEKSクラスターに接続するステップバイステップガイド

Topology Explorer

Kubernetesサービスの依存関係をマップし、インシデントの根本原因分析を迅速化

CloudKeepers

Kubernetesワークロード全体で継続的なヘルスチェックを自動実行