eks-workload-best-practice-assessment

EKS ワークロードのベストプラクティス評価

Amazon EKS 上の Kubernetes ワークロードを、K8s 公式ドキュメントおよび EKS Best Practices Guide のベストプラクティスに照らして評価します。ワークロード設定、セキュリティ、可観測性、ネットワーキング、ストレージ、EKS プラットフォームとの統合、CI/CD、イメージセキュリティの 8 つの観点を対象とします。

前提条件

このスキルには、以下が必要です。

• aws knowledge mcp server のツール：
  • aws___search_documentation — AWS ドキュメントを検索します
  • aws___read_documentation — ドキュメントページ全体を読み込みます
  • aws___recommend — 関連ドキュメントを取得します
• context7 MCP のツール：
  • context7_resolve-library-id — K8s ライブラリ ID を解決します
  • context7_query-docs — K8s ドキュメントを検索します
• AWS CLI（aws）— 対象の EKS クラスターおよび ECR への読み取りアクセス権限が設定されていること
• kubectl — 対象の EKS クラスターにアクセスできるよう設定されていること
• jq — AWS CLI および kubectl コマンドの JSON 出力を解析するために使用します

対象範囲の境界

このスキルでは、kubectl またはクラスター内の調査を必要とするワークロードレベルのチェックに重点を置きます。インフラストラクチャレイヤー（コントロールプレーン、ノードグループ、アドオンなど）を対象とする aws-best-practice-research を補完します。

このスキル（ワークロードレイヤー）	aws-best-practice-research（インフラレイヤー）
Pod のリソースリクエスト／制限	コントロールプレーンの設定
プローブ（liveness／readiness／startup）	ノードグループのサイズと AZ の分散
PDB、トポロジー制約	アドオンのバージョン
Pod のセキュリティコンテキスト、PSA	シークレットのエンベロープ暗号化
ネットワークポリシー	クラスターネットワーキング（VPC、サブネット）
サービスアカウント、RBAC	認証モード、アクセスエントリ
コンテナイメージのスキャン	GuardDuty EKS 保護
HPA／VPA／Karpenter のワークロード設定	Karpenter／CA のインフラ設定

ワークフロー

ステップ 1：評価範囲の確認

ユーザーの入力から、以下を確認します。

• クラスター名とAWS リージョン
• 評価範囲：
  • クラスター全体 — すべての名前空間を評価します（デフォルトでは kube-system、kube-public、kube-node-lease を除外）
  • 特定の名前空間 — ユーザーが指定したリスト
  • 特定のワークロード — ユーザーが指定した Deployment／StatefulSet
• インフラストラクチャレイヤーを含めますか？ — EKS インフラストラクチャレイヤーについても aws-best-practice-research を実行し、結果を統合するかどうか（デフォルト：はい）

ユーザーがクラスター名のみを指定した場合は、クラスター全体を評価します。

ステップ 2：環境の検出とバージョンの把握

環境を検出するため、以下のコマンドを実行します。

# Cluster info via AWS CLI
aws eks describe-cluster --name {CLUSTER} --region {REGION}

# K8s version
kubectl version --output=json

# Node distribution
kubectl get nodes -o wide --no-headers

以下を記録します。

• K8s サーバーバージョン（例：1.30）— バージョンに応じたフィルタリングに使用します
• EKS プラットフォームバージョン（例：eks.15）
• ノード数と AZ の分散
• ノードのインスタンスタイプ

バージョンに応じたフィルタリングルール（ステップ 3 で適用）：

• K8s >= 1.25：Pod Security Admission（PSA）を確認し、PodSecurityPolicy（PSP）はスキップします
• K8s < 1.25：PSP を確認し、PSA はアップグレードの推奨事項として記録します
• K8s >= 1.20：Startup Probe を確認します
• K8s >= 1.19：トポロジー分散制約を確認します
• K8s >= 1.29 + VPC CNI >= 1.21.1：Admin Network Policies を確認します
• Pod Identity を利用できる EKS では、IRSA より Pod Identity を優先します

ステップ 3：動的なベストプラクティスの調査

context7 と aws-knowledge-mcp-server を使用して、最新のベストプラクティスを調査します。 レート制限を回避するため、すべてのクエリを順番に（一度に 1 つずつ）実行してください。

8 つの評価ディメンションそれぞれについて、references/search-queries.md で定義された検索クエリを実行します。ディメンションごとの一般的な流れは次のとおりです。

1. context7（/websites/kubernetes_io）にクエリを実行して、K8s の公式ベストプラクティスを調べる
2. aws-knowledge-mcp-server にクエリを実行して、EKS 固有のベストプラクティスを調べる
3. 検索結果から主要なドキュメントページを読む（ディメンションごとに最大 2～3 ページ）
4. 具体的なしきい値と条件を含むチェック項目を抽出する

すべての調査が完了したら、ベースラインフレームワーク（references/check-dimensions.md）と結果を統合し、重要なディメンションが漏れていないことを確認します。

ステップ 2 のバージョン対応フィルタリングを適用して、該当しない項目を除外し、バージョン固有の推奨事項を追加します。

レート制限への対処：MCP リクエストで「Too many requests」が返された場合は、5 秒待ってから 1 回だけ再試行します。再度失敗した場合はスキップして続行します。順次実行は必須です。

ステップ 4：インフラストラクチャレイヤーの評価（任意）

インフラストラクチャレイヤーの評価を含める場合（デフォルト：含める）：

1. EKS クラスターに対して aws-best-practice-research スキルを呼び出す
2. インフラストラクチャレイヤーのチェックリストと評価結果を保存する
3. これらをステップ 7 で最終レポートに統合する

ユーザーが評価を希望しない場合は、このステップをスキップします。

ステップ 5：ワークロードデータの収集

kubectl を使用してワークロードの設定を収集します。独立したコマンドは並列実行できます（MCP のレート制限の対象ではありません）。

コマンドの全一覧については、references/kubectl-assessment-commands.md を参照してください。収集する主なデータは次のとおりです。

# Core workloads
kubectl get deployments,statefulsets,daemonsets,jobs,cronjobs --all-namespaces -o json

# Pod specifications (within workloads above)
# Already included in the -o json output

# Disruption and scaling
kubectl get pdb,hpa --all-namespaces -o json

# Networking
kubectl get networkpolicies,services,ingresses --all-namespaces -o json

# Security
kubectl get serviceaccounts --all-namespaces -o json
kubectl get clusterrolebindings,rolebindings -o json

# Storage
kubectl get pvc,storageclass -o json

# Namespace labels (for PSA)
kubectl get namespaces -o json

# Events (recent issues)
kubectl get events --all-namespaces --sort-by='.lastTimestamp' -o json

ECR イメージのスキャン（イメージが ECR 由来の場合）については、次を実行します。

# For each unique ECR image found in workloads
aws ecr describe-image-scan-findings --repository-name {REPO} --image-id imageTag={TAG}
aws ecr describe-repositories --repository-names {REPO}
aws ecr get-lifecycle-policy --repository-name {REPO}

収集したデータを評価対象の範囲（ステップ 1 で指定した名前空間／ワークロード）に絞り込みます。

ステップ 6：ディメンションごとの評価

調査フェーズ（ステップ 3）で得られた各チェック項目について、評価範囲内のすべてのワークロードを評価します。

ステータス	意味
PASS	ワークロードの設定が推奨事項を満たす、または上回っている
FAIL	ワークロードの設定が推奨事項を満たしていない
WARN	完全には検証できない、または推奨事項を部分的にしか満たしていない
N/A	チェックが該当しない（例：ステートレスワークロードに対するストレージチェック）

各検出結果について、次の項目を記録します。

• チェック項目の ID と名前
• ステータス（PASS/FAIL/WARN/N/A）
• 確認された実際の値（単に「未設定」ではなく）
• 影響を受ける具体的なワークロード
• バージョンとの関連に関する注記（該当する場合）

ステップ 7：レポートを作成してローカルファイルに保存する

references/output-template.md のテンプレートを使用して包括的なレポートを 1 つ作成し、ローカルの Markdown ファイルに直接書き込みます。

重要 — ファイル書き込みルール：

• レポートファイルの作成には Write/file ツールを使用します（bash の heredoc/echo/cat は使用しないでください）
• レポートが 1 回の書き込みで収まらない場合は、セクションに分割します。まず前半を書き込み、その後、追記／編集操作で残りのセクションを追加します
• レポート全体をターミナルに出力しないでください

次のファイル命名規則を使用します。

TIMESTAMP=$(TZ=Asia/Shanghai date +%Y-%m-%d-%H-%M-%S)
CLUSTER_SLUG=$(echo "{CLUSTER_NAME}" | tr '[:upper:]' '[:lower:]' | tr ' :/' '-')

評価レポート — references/output-template.md を参照

• クラスターの全体像
• 評価尺度、優先度の高い上位 3 項目、簡易統計を含むコンプライアンススコアカード
• ディメンションごとの評価テーブル
• ワークロードごとの詳細セクション
• 重大な問題と優先順位付けされた修正策
• データソースと参照リンク
• 保存先： ${TIMESTAMP}-${CLUSTER_SLUG}-assessment-report.md

ステップ 4 のインフラストラクチャレイヤーの結果がある場合は、レポートに統合します。

保存後、ターミナルには次の項目のみを含む簡潔な概要を出力します。

• 生成されたレポートのファイルパス
• 全体のコンプライアンススコア
• PASS / FAIL / WARN の検出件数

ステップ 8：修正のガイダンスと次のステップ

レポートを保存した後、次の項目を提示します。

• 「特定の FAIL 項目の修正をお手伝いできます。どの項目に対応しますか？」
• 「修正後に評価を再実行して、改善を確認できます。」

重大な問題（FAIL + 優先度が高い項目）について、次の内容を提示します。

• 具体的な修正コマンドまたはマニフェストの変更
• 修正にワークロードの再起動が必要か、稼働中に適用できるか
• 変更の影響評価

重要なガイドライン

• 網羅的に確認する：このスキルの価値は、徹底した確認にあります。確認項目を見落とすより、確認したうえで N/A とするほうが適切です。
• 必ず出典を明記する：すべての確認項目で、出典（EKS Best Practices Guide、K8s の公式ドキュメントなど）を参照してください。
• MCP クエリは順次実行する：context7 と aws-knowledge-mcp へのすべてのリクエストは順次実行してください。kubectl コマンドは並列実行できます。
• レート制限への対処：「Too many requests」が発生した場合は、5 秒待ってから 1 回だけ再試行してください。2 回目も失敗した場合はスキップしてください。
• バージョンを考慮する：検出した K8s/EKS のバージョンに合わせて、必ず確認項目を絞り込んでください。クラスターのバージョンで利用できない機能を推奨してはいけません。
• 検出結果には実際の値を記載する：「設定されていない」とだけ書くのではなく、実際に確認した内容を必ず報告してください。 良い例："resources.requests.memory: not set — コンテナにメモリーリクエストが設定されていません" 悪い例：「メモリーリクエストがありません」
• ワークロードごとに報告する：クラスター全体の要約だけでなく、個々の Deployment/StatefulSet ごとに検出結果を報告してください。
• デフォルトではシステム名前空間を除外する：ユーザーが明示的に指定しない限り、kube-system、kube-public、kube-node-lease はスキップしてください。
• 言語を尊重する：ユーザーとの会話と同じ言語で出力してください。
• インフラストラクチャとワークロードの境界を守る：aws-best-practice-research が行う確認を重複してはいけません。このスキルでは、kubectl／クラスター内へのアクセスが必要な項目のみを扱います。