Amazon EKS MCP Server を使ったら自分要らなかった話

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

EKS 上であるサービスを起動させていたのですが、頻繁に HTTP 50x エラーを返しており少々困っていました。
AWS が大量の MCP Server を提供しており、そのなかに EKS 用の MCP Server があることを思い出し、試してみました。

https://awslabs.github.io/mcp/servers/eks-mcp-server/

Amazon Q CLI インストール

特に意味は無いのですが、AWS への認証が楽そうなのと AWS の知見が多そうという適当な理由で Q CLI を使うことにしました。
（結果的に認証も知見も関係なかったです。なのでお好きな AI クライアントで大丈夫です。）

インストールは Using Amazon Q Developer on the command line のまま実行です。

Q CLI の MCP Server 設定は ~/.aws/amazonq/mcp.json に書くと全てのワークスペースで使えるようです。

EKS MCP Server の設定は以下のように書きました。
それぞれのオプションの意味を引用します。本エントリのように MCP Server に設定変更を許可したい場合は --allow-write オプションを追加します。

--allow-write (optional)
Enables write access mode, which allows mutating operations (e.g., create, update, delete resources) for apply_yaml, generate_app_manifest, manage_k8s_resource, manage_eks_stacks, add_inline_policy tool operations.

Default: false (The server runs in read-only mode by default)
Example: Add --allow-write to the args list in your MCP server definition.

--allow-sensitive-data-access (optional)
Enables access to sensitive data such as logs, events, and Kubernetes Secrets. This flag is required for tools that access potentially sensitive information, such as get_pod_logs, get_k8s_events, get_cloudwatch_logs, and manage_k8s_resource (when used to read Kubernetes secrets).

Default: false (Access to sensitive data is restricted by default)
Example: Add --allow-sensitive-data-access to the args list in your MCP server definition.

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write",
        "--allow-sensitive-data-access"
      ],
      "env": {
        "AWS_PROFILE": "your-profile",
        "AWS_REGION": "us-west-2"
      }
    }
  }
}

やってみた

今回問題となっていた EKS クラスターは Self-host Langfuse です。

それでは q chat で Q CLI と会話しましょう。

$ q chat
✓ awslabseks_mcp_server loaded in 3.96 s
✓ 1 of 1 mcp servers initialized.


    ⢠⣶⣶⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣶⣿⣿⣿⣶⣦⡀⠀
 ⠀⠀⠀⣾⡿⢻⣿⡆⠀⠀⠀⢀⣄⡄⢀⣠⣤⣤⡀⢀⣠⣤⣤⡀⠀⠀⢀⣠⣤⣤⣤⣄⠀⠀⢀⣤⣤⣤⣤⣤⣤⡀⠀⠀⣀⣤⣤⣤⣀⠀⠀⠀⢠⣤⡀⣀⣤⣤⣄⡀⠀⠀⠀⠀⠀⠀⢠⣿⣿⠋⠀⠀⠀⠙⣿⣿⡆
 ⠀⠀⣼⣿⠇⠀⣿⣿⡄⠀⠀⢸⣿⣿⠛⠉⠻⣿⣿⠛⠉⠛⣿⣿⠀⠀⠘⠛⠉⠉⠻⣿⣧⠀⠈⠛⠛⠛⣻⣿⡿⠀⢀⣾⣿⠛⠉⠻⣿⣷⡀⠀⢸⣿⡟⠛⠉⢻⣿⣷⠀⠀⠀⠀⠀⠀⣼⣿⡏⠀⠀⠀⠀⠀⢸⣿⣿
 ⠀⢰⣿⣿⣤⣤⣼⣿⣷⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⢀⣴⣶⣶⣶⣿⣿⠀⠀⠀⣠⣾⡿⠋⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⡇⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⢹⣿⣇⠀⠀⠀⠀⠀⢸⣿⡿
 ⢀⣿⣿⠋⠉⠉⠉⢻⣿⣇⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⣿⣿⡀⠀⣠⣿⣿⠀⢀⣴⣿⣋⣀⣀⣀⡀⠘⣿⣿⣄⣀⣠⣿⣿⠃⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⠈⢿⣿⣦⣀⣀⣀⣴⣿⡿⠃
 ⠚⠛⠋⠀⠀⠀⠀⠘⠛⠛⠀⠘⠛⠛⠀⠀⠀⠛⠛⠀⠀⠀⠛⠛⠀⠀⠙⠻⠿⠟⠋⠛⠛⠀⠘⠛⠛⠛⠛⠛⠛⠃⠀⠈⠛⠿⠿⠿⠛⠁⠀⠀⠘⠛⠃⠀⠀⠘⠛⠛⠀⠀⠀⠀⠀⠀⠀⠀⠙⠛⠿⢿⣿⣿⣋⠀⠀
 ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠛⠿⢿⡧

╭─────────────────────────────── Did you know? ────────────────────────────────╮
│                                                                              │
│         Use /model to select the model to use for this conversation          │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

/help all commands  •  ctrl + j new lines  •  ctrl + s fuzzy search
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🤖 You are chatting with claude-3.7-sonnet

MCP Server もしっかり起動していますね。
EKS のトラブルシュートを開始します。
MCP Server の設定で AWS_PROFILE を指定しています。このプロファイルで認証してもらうために「まずはAWS認証して」と明示しています。
これを最初にやっておかないとうまく認証してもらえませんでした。

> EKSのトラブルシュートをしたい。まずはAWS認証して。
EKSのトラブルシューティングをお手伝いします。まずはAWS認証の状態を確認しましょう。

AWS CLIの認証状態を確認するために、以下のコマンドを実行します：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
aws sts get-caller-identity
 ⋮ 
 ↳ Purpose: AWS認証状態の確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
{
    "UserId": "SECRET",
    "Account": "SECRET",
    "Arn": "SECRET"
}

 ⋮ 
 ● Completed in 1.860s
AWS認証が正常に完了しています。現在、以下のIAMロールでAWSにアクセスしています：

• ユーザーID: SECRET
• アカウント: SECRET
• ARN: SECRET

AWSのAdministratorロールでログインしているため、EKSクラスターのトラブルシューティングに必要な権限は十分にあります。

次に、EKSクラスターの一覧を確認しましょうか？または特定のEKSクラスターについて調査したいですか？

認証できました。
Q は前のめりでトラブルシュートしてくれそうな勢いですねｗ

クラスター名を指定しつつ、困り事を Q へ伝えます。

> クラスター名 langfuse でWebサービスが頻繁にHTTP50xを返して困っている
クラスター名「langfuse」でWebサービスがHTTP 50xエラーを頻繁に返している問題を調査しましょう。まずはクラスターの状態を確認します。


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: eks
Operation name: describe-cluster
Parameters: 
- name: "langfuse"
Profile name: default
Region: ap-northeast-1
Label: EKSクラスター情報の取得
 ⋮ 
 ● Execution failed after 0.742s:

An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: langfuse.


「langfuse」という名前のEKSクラスターが見つかりませんでした。利用可能なEKSクラスターを確認してみましょう。


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: eks
Operation name: list-clusters
Parameters: 
Profile name: default
Region: ap-northeast-1
Label: 利用可能なEKSクラスターの一覧取得
 ⋮ 
 ● Completed in 0.722s
ap-northeast-1リージョンにはEKSクラスターが存在しないようです。他のリージョンも確認してみましょう。


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do echo "Region: $region"; aws eks list-clusters --region $region; done
 ⋮ 
 ↳ Purpose: 全リージョンのEKSクラスターを確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

MCP Server の設定で AWS_REGION を指定しているのですが、読み取ってくれませんでした。悲しい。
なので、リージョンを明示します。

>> リージョンはus-west-2
わかりました。us-west-2リージョンでEKSクラスター「langfuse」の状態を確認しましょう。


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: eks
Operation name: describe-cluster
Parameters: 
- name: "langfuse"
Profile name: default
Region: us-west-2
Label: EKSクラスター情報の取得
 ⋮ 
 ● Completed in 1.195s
EKSクラスター「langfuse」の情報を取得できました。クラスターは正常に動作しているようです（status: ACTIVE）。次に、このクラスターで実行されているWebサービスのPodを確認しましょう。

まず、クラスターへの接続設定を更新します：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
aws eks update-kubeconfig --name langfuse --region us-west-2
 ⋮ 
 ↳ Purpose: EKSクラスターのkubeconfigを更新


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
Updated context arn:aws:eks:us-west-2:SECRET:cluster/langfuse in /Users/ryo.yoshii/.kube/config

 ⋮ 
 ● Completed in 1.88s
kubeconfig設定が更新されました。次に、クラスター内のPodを確認します：


🛠️  Using tool: list_k8s_resources from mcp server awslabseks_mcp_server
 ⋮ 
 ● Running list_k8s_resources with the param:
 ⋮  {
 ⋮    "arguments": {
 ⋮      "api_version": "v1",
 ⋮      "cluster_name": "langfuse",
 ⋮      "kind": "Pod"
 ⋮    },
 ⋮    "name": "list_k8s_resources"
 ⋮  }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y

クラスターを発見してくれました。
Pod の調査に進むようです。

 ⋮ 
 ● Completed in 0.616s
SSO認証の問題が発生しているようです。AWS CLIを使用して直接Podを確認してみましょう：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl get pods --all-namespaces
 ⋮ 
 ↳ Purpose: kubectl経由でPodを確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
NAMESPACE     NAME                                            READY   STATUS    RESTARTS         AGE
kube-system   aws-load-balancer-controller-66b8664558-grjxw   1/1     Running   0                6d
kube-system   aws-load-balancer-controller-66b8664558-n6z7v   1/1     Running   0                6d
kube-system   coredns-f859cbf74-n28sw                         1/1     Running   0                5d23h
kube-system   coredns-f859cbf74-wf4z8                         1/1     Running   0                5d23h
langfuse      langfuse-clickhouse-shard0-0                    1/1     Running   0                5d23h
langfuse      langfuse-clickhouse-shard0-1                    1/1     Running   0                5d23h
langfuse      langfuse-clickhouse-shard0-2                    1/1     Running   0                5d23h
langfuse      langfuse-web-6746c87955-6qdbh                   1/1     Running   53 (30m ago)     5d23h
langfuse      langfuse-worker-6b6f69b847-g62t5                1/1     Running   0                5d23h
langfuse      langfuse-zookeeper-0                            1/1     Running   110 (87m ago)    5d23h
langfuse      langfuse-zookeeper-1                            1/1     Running   37 (118m ago)    5d23h
langfuse      langfuse-zookeeper-2                            1/1     Running   38 (3h54m ago)   5d23h

 ⋮ 
 ● Completed in 2.11s
Podの一覧が取得できました。langfuse-web-6746c87955-6qdbh Podが53回再起動しており、これがHTTP 50xエラーの原因かもしれません。このPodのログを確認しましょう：

問題のありそうな Pod を特定してくれました。
5d23h で 53回も再起動していました。これを放置していた自分はどうなんだという気持ちになります。

調査はログの確認へ進みます。

🛠️  Using tool: get_pod_logs from mcp server awslabseks_mcp_server
 ⋮ 
 ● Running get_pod_logs with the param:
 ⋮  {
 ⋮    "arguments": {
 ⋮      "cluster_name": "langfuse",
 ⋮      "namespace": "langfuse",
 ⋮      "pod_name": "langfuse-web-6746c87955-6qdbh",
 ⋮      "tail_lines": 200
 ⋮    },
 ⋮    "name": "get_pod_logs"
 ⋮  }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y

 ⋮ 
 ● Completed in 0.330s
SSO認証の問題が続いています。kubectl経由で直接ログを確認しましょう：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl logs -n langfuse langfuse-web-6746c87955-6qdbh --tail=100
 ⋮ 
 ↳ Purpose: langfuse-webのログを確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
Script executed successfully.
Prisma schema loaded from packages/shared/prisma/schema.prisma
Datasource "db": PostgreSQL database "langfuse", schema "public" at "langfuse-postgres.cluster-xxxx.us-west-2.rds.amazonaws.com:5432"

299 migrations found in prisma/migrations


No pending migrations to apply.
no change
  ▲ Next.js 14.2.26
  - Local:        http://localhost:3000
  - Network:      http://0.0.0.0:3000

 ✓ Starting...
Running init scripts...
 ✓ Ready in 24.9s

 ⋮ 
 ● Completed in 1.184s
現在のログでは問題が見つかりません。Podの再起動履歴を確認するために、イベントを確認しましょう：

ログでは問題が見つからなかったようです。
次にイベントを確認するようです。よくある手順ですね。

🛠️  Using tool: get_k8s_events from mcp server awslabseks_mcp_server
 ⋮ 
 ● Running get_k8s_events with the param:
 ⋮  {
 ⋮    "arguments": {
 ⋮      "cluster_name": "langfuse",
 ⋮      "kind": "Pod",
 ⋮      "name": "langfuse-web-6746c87955-6qdbh",
 ⋮      "namespace": "langfuse"
 ⋮    },
 ⋮    "name": "get_k8s_events"
 ⋮  }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y

 ⋮ 
 ● Completed in 0.325s
SSO認証の問題が続いています。kubectl経由で直接イベントを確認しましょう：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl describe pod -n langfuse langfuse-web-6746c87955-6qdbh
 ⋮ 
 ↳ Purpose: langfuse-webのイベントを確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
（省略）

Containers:
  langfuse-web:
    Container ID:   containerd://199a3545c6cf05a7b3d7026958759876cc46e4a4107fd5ffa7fbc4499d710c69
    Image:          langfuse/langfuse:3.55.0
    Image ID:       docker.io/langfuse/langfuse@sha256:c695e43c5b482f697fcad3efecd5e9b74e3b46f2647c29663fb599a892deffa1
    Port:           3000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 17 Jun 2025 10:08:19 +0900
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Tue, 17 Jun 2025 10:06:09 +0900
      Finished:     Tue, 17 Jun 2025 10:08:18 +0900
    Ready:          True
    Restart Count:  53
    Liveness:       http-get http://:http/api/public/health delay=60s timeout=5s period=10s #success=1 #failure=3
    Readiness:      http-get http://:http/api/public/ready delay=60s timeout=5s period=10s #success=1 #failure=3

（省略）

Events:
  Type     Reason     Age                    From     Message
  ----     ------     ----                   ----     -------
  Normal   Pulled     34m (x2 over 3d22h)    kubelet  Successfully pulled image "langfuse/langfuse:3.55.0" in 652ms (652ms including waiting). Image size: 257639675 bytes.
  Normal   Killing    31m (x36 over 5d18h)   kubelet  Container langfuse-web failed liveness probe, will be restarted
  Normal   Pulling    31m (x54 over 5d23h)   kubelet  Pulling image "langfuse/langfuse:3.55.0"
  Normal   Created    31m (x54 over 5d23h)   kubelet  Created container: langfuse-web
  Normal   Started    31m (x54 over 5d23h)   kubelet  Started container langfuse-web
  Normal   Pulled     31m                    kubelet  Successfully pulled image "langfuse/langfuse:3.55.0" in 709ms (709ms including waiting). Image size: 257639675 bytes.
  Warning  Unhealthy  30m (x166 over 5d18h)  kubelet  Liveness probe failed: Get "http://10.0.20.204:3000/api/public/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  30m (x175 over 5d23h)  kubelet  Readiness probe failed: Get "http://10.0.20.204:3000/api/public/ready": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

 ⋮ 
 ● Completed in 1.318s
問題の原因が見つかりました。Podの詳細情報から以下の重要な問題点が確認できます：

1. OOMKilled（メモリ不足による強制終了）:
  
   Last State: Terminated
   Reason: OOMKilled
   Exit Code: 137
   
  Podがメモリ制限を超えて強制終了されています。

2. リソース制限の問題:
  
   Annotations: CapacityProvisioned: 0.25vCPU 0.5GB
   
  Fargateプロファイルで割り当てられているメモリが0.5GBと非常に少ないです。

3. ヘルスチェック失敗:
  
   Warning Unhealthy 30m (x166 over 5d18h) kubelet Liveness probe failed: Get "http://10.0.20.204:3000/api/public/health": context deadline exceeded
   
  アプリケーションがヘルスチェックに応答できていません。

4. 再起動回数:
  
   Restart Count: 53
   
  Podが頻繁に再起動しています。

これらの問題から、Webサービスが頻繁にHTTP 50xエラーを返す主な原因は**メモリ不足**であると考えられます。Fargateプロファイルで割り当てられているメモリが0.5GBと非常に少なく、アプリケーショ
ンが必要とするメモリを確保できていません。

OOMKilled が原因であることがわかりました。ありがとう。
メモリ割り当てが 0.5GB と少なすぎるので、増やす必要があるという提案です。

解決策として、以下の対応を提案します：

1. Fargateプロファイルのリソース割り当てを増やす:
   • メモリを少なくとも1GB以上に増やす
   • CPUも0.5vCPU以上に増やすことを検討

2. Deploymentのリソース要求と制限を確認・修正:
  現在のDeployment設定を確認しましょう：

> y
Deploymentの設定を確認して、リソース割り当てを確認しましょう：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl get deployment -n langfuse langfuse-web -o yaml
 ⋮ 
 ↳ Purpose: langfuse-webのDeployment設定を確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
apiVersion: apps/v1
kind: Deployment
metadata:

（省略）

 ⋮ 
 ● Completed in 1.364s
次に、Fargateプロファイルの設定を確認しましょう：


🛠️  Using tool: use_aws (trusted)
 ⋮ 
 ● Running aws cli command:

Service name: eks
Operation name: describe-fargate-profile
Parameters: 
- clusterName: "langfuse"
- fargateProfileName: "langfuse-langfuse"
Profile name: default
Region: us-west-2
Label: Fargateプロファイルの確認
 ⋮ 
 ● Completed in 1.147s
問題点が明確になりました：

1. リソース要求が設定されていない:
  Deploymentの設定を見ると、resources: {}となっており、コンテナのリソース要求（requests）と制限（limits）が設定されていません。

2. Fargateの最小リソース割り当て:
  Fargateプロファイルでは、リソース要求が指定されていない場合、最小構成（0.25vCPU、0.5GB RAM）が割り当てられます。これがPodの詳細で見たCapacityProvisioned: 0.25vCPU 0.5GBの原因です。

3. OOMKilled:
  Langfuseアプリケーション（Next.js）は0.5GBのメモリでは動作できず、メモリ不足で強制終了されています。

なぜメモリ割り当てが少ないのかという原因を明確にしてくれました。

リソース要求が指定されていない場合、最小構成（0.25vCPU、0.5GB RAM）が割り当てられます

ネームスペースのデフォルトのメモリー要求と制限を設定する

Q は続いてメモリ割り当てを変更してくれるようです。

解決策として、Deploymentにリソース要求を追加し、適切なメモリとCPUを割り当てましょう：


🛠️  Using tool: fs_write
 ⋮ 
 ● Path: ./langfuse-web-patch.yaml

+     1: apiVersion: apps/v1
+     2: kind: Deployment
+     3: metadata:
+     4:   name: langfuse-web
+     5:   namespace: langfuse
+     6: spec:
+     7:   template:
+     8:     spec:
+     9:       containers:
+    10:       - name: langfuse-web
+    11:         resources:
+    12:           requests:
+    13:             memory: "2Gi"
+    14:             cpu: "1"
+    15:           limits:
+    16:             memory: "4Gi"
+    17:             cpu: "2"


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
Creating: ./langfuse-web-patch.yaml

 ⋮ 
 ● Completed in 0.1s
作成したパッチファイルをDeploymentに適用します：


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl patch deployment -n langfuse langfuse-web --patch-file ./langfuse-web-patch.yaml
 ⋮ 
 ↳ Purpose: リソース設定を更新


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
deployment.apps/langfuse-web patched

 ⋮ 
 ● Completed in 1.97s
Deploymentが更新されました。新しいPodが作成されるのを待ち、状態を確認しましょう：

CPU とメモリの割り当てを増やすために kubectl patch を実行してくれました。サンキューな。

🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl get pods -n langfuse -l app=web -w
 ⋮ 
 ↳ Purpose: Podの状態を確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
NAME                            READY   STATUS    RESTARTS       AGE
langfuse-web-6746c87955-6qdbh   1/1     Running   53 (34m ago)   5d23h
langfuse-web-7ddc8cb4d-sdx7p    0/1     Pending   0              22s
langfuse-web-7ddc8cb4d-sdx7p    0/1     Pending   0              44s
langfuse-web-7ddc8cb4d-sdx7p    0/1     ContainerCreating   0              44s
langfuse-web-7ddc8cb4d-sdx7p    0/1     Running             0              64s
langfuse-web-7ddc8cb4d-sdx7p    1/1     Running             0              2m9s
langfuse-web-6746c87955-6qdbh   1/1     Terminating         53 (36m ago)   5d23h
langfuse-web-6746c87955-6qdbh   0/1     Terminating         53 (37m ago)   5d23h
langfuse-web-6746c87955-6qdbh   0/1     Error               53             5d23h
langfuse-web-6746c87955-6qdbh   0/1     Error               53             5d23h
langfuse-web-6746c87955-6qdbh   0/1     Error               53             5d23h
^C

kubectl get pods の返りを待つところの処理がおかしいのか、だんまりしているので ctrl + c で中断しました。
別ターミナルで確認した結果を Q に伝えます。

> langfuse-web-7ddc8cb4d-sdx7p がRunningになっているよ
素晴らしいです！新しいPod langfuse-web-7ddc8cb4d-sdx7p が正常に起動しているようですね。リソース設定の変更が適用されたことを確認しましょう。


🛠️  Using tool: execute_bash
 ⋮ 
 ● I will run the following shell command: 
kubectl describe pod -n langfuse langfuse-web-7ddc8cb4d-sdx7p
 ⋮ 
 ↳ Purpose: 新しいPodの詳細を確認


Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
Name:                 langfuse-web-7ddc8cb4d-sdx7p
Namespace:            langfuse

 （省略）

 ⋮ 
 ● Completed in 1.197s
素晴らしい結果です！新しいPodの設定が正しく適用されています：

1. リソース割り当ての増加:
  
   CapacityProvisioned: 1vCPU 3GB
   
  以前の0.25vCPU 0.5GBから大幅に増加しています。

2. リソース要求と制限の設定:
  
   Limits:
     cpu:     2
     memory:  4Gi
   Requests:
     cpu:      1
     memory:   2Gi
   
  適切なリソース要求と制限が設定されています。

3. 再起動なし:
  
   Restart Count: 0
   
  新しいPodは再起動していません。

4. 正常なステータス:
  
   Ready: True
   
  Podが正常に動作しています。

5. QoSクラスの改善:
  
   QoS Class: Burstable
   
  以前のBestEffortからBurstableに改善されています。

これで、Webサービスが安定して動作するはずです。HTTP 50xエラーの問題は解決されたと考えられます。

サービスの状態を確認しましょう：

まとめ

MCP Server を使ってみたいタイミングでちょうど良い？問題が起きたので、EKS 上の Web サービスのトラブルシュートをしてもらいました。
OOMKilled という比較的見つけやすくパワープレイで解決できる問題ではありましたが、ほぼ人手を介さず解決まで導いてくれました。
これで SRE やインフラ担当が不要になると言われたらそれは違うとは思いますが、省エネ・効率化はできると思います。
むしろ、SRE やインフラ担当はこの方面のスキルが必要になっていくのではないでしょうか。

AWS に関わらずクラウドサービス系のベンダーが公式風味な MCP Server を提供してくれている現状にとても満足と感謝をしています。