はじめに
Kubernetes クラスターの運用において、コンテナやノードのメトリクスを可視化することは非常に重要です。Amazon EKS を使用している場合、CloudWatch Container Insights を活用することで、クラスターの状態を簡単に監視できます。特に「Amazon CloudWatch Observability EKS アドオン」を使用すると、EKS クラスターのオブザーバビリティを強化できます[1]。
この記事では、Amazon EKS クラスターで CloudWatch Observability EKS アドオンを有効化し、Container Insights ダッシュボードでメトリクスを確認する方法を実際に検証した結果をご紹介します。権限設定のトラブルシューティングも含めて、実装手順を詳しく解説します。
対象読者
- Amazon EKS クラスターを運用している方
- コンテナ環境のモニタリングを強化したい方
- CloudWatch Container Insights の導入を検討している方
検証環境
- Amazon EKS 1.31
- マネージドノードグループ (MNG) を使用したクラスター
- kubectl 1.31.x
前提条件
必要なAWSアカウント権限
- Amazon EKS クラスターの管理権限
- IAM ロールとポリシーの作成・編集権限
- CloudWatch の閲覧・設定権限
必要なサービスやツール
- Amazon EKS クラスター（稼働中）
- kubectl（設定済み）
- AWS CLI（設定済み）
注意事項
- Fargateでは利用不可: Amazon EKS 向けにオブザーバビリティが強化された Container Insights は、Fargate ではサポートされていません[1]。
- 追加コスト: CloudWatch Container Insights の使用には追加コストが発生します。詳細は CloudWatch 料金ページを参照してください。
Amazon CloudWatch Observability EKS アドオンの概要
Amazon CloudWatch Observability EKS アドオンは、EKS クラスターに CloudWatch エージェントと Fluent Bit を自動的にインストールし、インフラストラクチャメトリクスとコンテナログの収集を可能にします[2]。
このアドオンを使用することで、以下の機能が有効になります：
- CloudWatch エージェント: クラスターノードからインフラストラクチャメトリクスを送信
- Fluent Bit: コンテナログを CloudWatch Logs に送信
- CloudWatch Application Signals: アプリケーションパフォーマンステレメトリの送信（オプション）
主な機能と利点
- 詳細なメトリクス収集: CPU、メモリ、ディスク、ネットワークなどのリソース使用状況を詳細に把握
- コンテナログの一元管理: すべてのコンテナログを CloudWatch Logs で一元管理
- アラート設定: 異常検知やしきい値ベースのアラートを設定可能
- ダッシュボード: 直感的なダッシュボードでクラスターの状態を可視化
実装手順
STEP1: 現状確認とアドオンの有効化
まずは現在の EKS クラスターの状態を確認し、CloudWatch Observability EKS アドオンを有効化します。
1-1. 現在のPodを確認
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-7b968d67d8-5hmhz 1/1 Running 0 11d
kube-system coredns-7b968d67d8-d4nf6 1/1 Running 0 11d
現時点では、kube-system ネームスペースに coreDNS の Pod のみが実行されています。
1-2. CloudWatch Observability EKS アドオンの有効化
EKS コンソールからアドオンを有効化します。
- [Amazon EKS コンソール]を開く
- 対象のクラスターを選択
- 「アドオン」タブを選択
- 「アドオンの取得」をクリック
- 「Amazon CloudWatch Observability」を選択し、「次へ」をクリック
- バージョンは最新を選択し、「作成」をクリック
1-3. アドオン有効化後の Pod を確認
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
amazon-cloudwatch amazon-cloudwatch-observability-controller-manager-99c7ff6dg6w4 1/1 Running 0 2m20s
kube-system coredns-7b968d67d8-5hmhz 1/1 Running 0 11d
kube-system coredns-7b968d67d8-d4nf6 1/1 Running 0 11d
amazon-cloudwatch ネームスペースにコントローラーマネージャーのPodが作成され、Running 状態になりました。
STEP2: テストアプリケーションのデプロイとトラブルシューティング
2-1. テスト用 Nginx のデプロイ
$ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-85b98978db-5v9xz 1/1 Running 0 45s
2-2. CloudWatch Container Insights ダッシュボードの確認
この時点で CloudWatch コンソールの Container Insights ダッシュボードを確認しましたが、メトリクスが表示されていませんでした。
2-3. トラブルシューティング
Fluent Bit Pod のログを確認すると、権限エラーが発生していることがわかります。(本来は CloudWatch エージェントのログを見るべきですが、ここでは Fluent Bit のログを確認しています。)
[2025/03/04 04:58:14] [error] [output:cloudwatch_logs:cloudwatch_logs.0] CreateLogStream API responded with error='AccessDeniedException'
[2025/03/04 04:58:14] [error] [output:cloudwatch_logs:cloudwatch_logs.0] Failed to create log stream
[2025/03/04 04:58:14] [error] [output:cloudwatch_logs:cloudwatch_logs.0] Failed to send events
AccessDeniedException が発生していました。
改めて AWS 公式ドキュメントを確認すると、前提条件として、CloudWatch にメトリクスとログを送信するための権限設定が必要であることがわかります[3]：
Amazon EKS ワーカーノードが CloudWatch にメトリクスとログを送信できるようにするには、IAM にもアクセス許可を付与する必要があります。次の 2 通りの方法があります。
- ワーカーノードの IAM ロールにポリシーをアタッチします。これは、Amazon EKS クラスターと他の Kubernetes クラスターの両方に有効です。
- クラスターでサービスアカウントの IAM ロールを使用し、このロールにポリシーをアタッチします。これは Amazon EKS クラスターでのみ機能します。
ワーカーノードの IAM ロールか IRSA 等を使用する必要がありそうですが、今回は、EKS Pod Identity を使用して、サービスアカウントに IAM ロールを関連付ける方法を選択します。
STEP3: EKS Pod Identit yの設定と権限付与
3-1. EKS Pod Identity アドオンの有効化
EKS コンソールから「クラスター」→ 対象クラスターを選択 → 「アドオン」タブ → 「アドオンをさらに追加」から「EKS Pod Identity Agent」を選択して有効化します。
3-2. CloudWatchAgentServerPolicy を持つ IAM ロールの作成
必要なポリシーは CloudWatchAgentServerPolicy です。
AWS CLI または IAM コンソールを使用して、CloudWatchAgentServerPolicy をアタッチした IAM ロールを作成します。
# IAM ロールの作成（信頼ポリシーは適切に設定）
$ aws iam create-role --role-name pod-identity-role --assume-role-policy-document file://trust-policy.json
# CloudWatchAgentServerPolicyをアタッチ
$ aws iam attach-role-policy --role-name pod-identity-role --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
3-3. Pod Identity 関連付けの設定
EKS コンソールで「アクセス」→ 「Pod Identity の関連付け」から新しい関連付けを作成します：
- IAM ロール: 作成した CloudWatchAgentServerPolicy を持つロール（pod-identity-role）
- Kubernetes 名前空間: amazon-cloudwatch
- Kubernetes サービスアカウント: cloudwatch-agent
3-4. cloudwatch-agent Pod の再作成
既存の Pod を削除して再作成します：
$ kubectl -n amazon-cloudwatch delete pod -l app=cloudwatch-agent
pod "cloudwatch-agent-xxxxx" deleted
# しばらく待つとPodが自動的に再作成されます
$ kubectl -n amazon-cloudwatch get pods
NAME READY STATUS RESTARTS AGE
cloudwatch-agent-yyyyy 1/1 Running 0 45s
Pod のログを確認して、権限エラーが解消されていることを確認します：
$ kubectl -n amazon-cloudwatch logs cloudwatch-agent-yyyyy
2025-03-04T05:14:31Z I! {"caller":"kubernetes/kubernetes.go:331","msg":"Using pod service account via in-cluster config","kind":"receiver","name":"awscontainerinsightreceiver","data_type":"metrics","discovery":"kubernetes","config":"containerInsightsNeuronMonitorScraper"}
エラーメッセージが出なくなり、正常に動作していることがわかります。
検証結果
CloudWatch Container Insights ダッシュボードの確認
権限設定を適切に行った後、CloudWatch コンソールの Container Insights ダッシュボードを確認すると、EKS クラスターのメトリクスが表示されるようになりました。
収集されるメトリクス
Amazon CloudWatch Observability EKS アドオンを使用すると、以下のようなメトリクスが収集されます[4]：
- クラスターレベルのメトリクス: クラスター全体の CPU、メモリ、ディスク、ネットワーク使用率
- ノードレベルのメトリクス: 各ノードのリソース使用状況
- Pod レベルのメトリクス: 各 Pod のリソース使用状況
- サービスレベルのメトリクス: Kubernetes サービスのパフォーマンス
まとめ
Amazon CloudWatch Observability EKS アドオンを使用することで、EKS クラスターのモニタリングを簡単に強化できることがわかりました。
今回の検証では、以下の点が明らかになりました：
- 簡単な導入: EKS コンソールからアドオンを有効化するだけで、基本的な設定が完了します。
- 権限設定の重要性: CloudWatch にメトリクスとログを送信するための適切な権限設定が必要です。EKS Pod Identity を使用すると、セキュアな権限管理が可能です。
- 包括的なモニタリング: クラスター、ノード、Pod、サービスレベルの詳細なメトリクスを収集できます。
-
ダッシュボードの活用: 収集したメトリクスは Container Insights ダッシュボードで直感的に確認できます。
EKS クラスターの運用において、CloudWatch Observability EKS アドオンは強力なモニタリングツールとなります。特に大規模なクラスターや本番環境では、問題の早期発見や容量計画に役立つと思います。
最後までお読みいただきありがとうございました。