jpskill.com
📦 その他 コミュニティ

eks-troubleshooting

EKS(Amazon Kubernetes Service)環境で発生するPodの異常、ネットワーク問題、パフォーマンス低下などのトラブルシューティングやデバッグを支援し、クラスタの健全性を分析して問題解決を迅速化するSkill。

📜 元の英語説明(参考)

EKS troubleshooting and debugging guide covering pod failures, cluster issues, networking problems, and performance diagnostics. Use when diagnosing cluster issues, debugging pod failures (CrashLoopBackOff, Pending, OOMKilled), resolving networking problems, investigating performance issues, troubleshooting IAM/IRSA permissions, fixing image pull errors, or analyzing EKS cluster health.

🇯🇵 日本人クリエイター向け解説

一言でいうと

EKS(Amazon Kubernetes Service)環境で発生するPodの異常、ネットワーク問題、パフォーマンス低下などのトラブルシューティングやデバッグを支援し、クラスタの健全性を分析して問題解決を迅速化するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o eks-troubleshooting.zip https://jpskill.com/download/9418.zip && unzip -o eks-troubleshooting.zip && rm eks-troubleshooting.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9418.zip -OutFile "$d\eks-troubleshooting.zip"; Expand-Archive "$d\eks-troubleshooting.zip" -DestinationPath $d -Force; ri "$d\eks-troubleshooting.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して eks-troubleshooting.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → eks-troubleshooting フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

EKS トラブルシューティングガイド

概要

Amazon EKS クラスタの包括的なトラブルシューティングガイドです。コントロールプレーンの問題、ノードの問題、Pod の障害、ネットワーク、ストレージ、セキュリティ、およびパフォーマンスの診断について解説します。2025 年の AWS ベストプラクティスに基づいています。

キーワード: EKS, Kubernetes, kubectl, デバッグ, トラブルシューティング, pod failure, node issues, networking, DNS, AWS, diagnostics

この Skill を使用する場面

Pod の問題:

  • Pod が Pending、CrashLoopBackOff、ImagePullBackOff の状態から抜け出せない
  • OOMKilled コンテナまたは CPU スロットリング
  • Pod の削除または予期しない終了
  • コンテナログにおけるアプリケーションエラー

クラスタの問題:

  • ノードが NotReady ステータスを示す
  • コントロールプレーン API サーバーのタイムアウト
  • クラスタオートスケーリングの失敗
  • etcd のパフォーマンス問題

ネットワークの問題:

  • DNS 解決の失敗
  • サービス接続の問題
  • ロードバランサーのプロビジョニングエラー
  • クロス AZ トラフィックの問題
  • VPC CNI IP アドレスの枯渇

セキュリティと権限:

  • IAM/IRSA 権限拒否エラー
  • RBAC アクセスの問題
  • イメージプル認証の失敗
  • サービスアカウントの問題

パフォーマンスの問題:

  • Pod の起動時間の遅延
  • 高いメモリ/CPU 使用率
  • リソース競合
  • ネットワークレイテンシ

クイック診断ワークフロー

1. 初期トリアージ (最初の 60 秒)

# クラスタへのアクセス可能性を確認
kubectl cluster-info

# クラスタ全体のステータスを取得
kubectl get nodes
kubectl get pods --all-namespaces | grep -v Running

# 最近のイベントを確認
kubectl get events --all-namespaces --sort-by='.lastTimestamp' | tail -20

# コントロールプレーンコンポーネントを確認
kubectl get --raw /healthz
kubectl get componentstatuses  # 1.19 以降では非推奨ですが、まだ役立ちます

2. 問題領域の特定

Pod の問題:

# Pod のステータスを取得
kubectl get pods -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous  # 以前のコンテナログ

ノードの問題:

# ノードのステータスを確認
kubectl get nodes -o wide
kubectl describe node <node-name>
kubectl top nodes  # metrics-server が必要

クラスタ全体の問題:

# すべてのリソースを確認
kubectl get all --all-namespaces
kubectl get events --all-namespaces --sort-by='.lastTimestamp'

# EKS クラスタのヘルスチェック (AWS CLI)
aws eks describe-cluster --name <cluster-name> --query 'cluster.health'

3. 詳細な調査 (リファレンスガイドを参照)

  • Pod/ワークロードの問題references/workload-issues.md
  • ノード/クラスタの問題references/cluster-issues.md
  • ネットワークの問題references/networking-issues.md

一般的な Pod の障害パターン

Pending Pods

症状:

  • Pod が Pending 状態から抜け出せない
  • コンテナが実行されていない

クイックチェック:

kubectl describe pod <pod-name> -n <namespace> | grep -A 10 Events

一般的な原因:

  1. リソース不足: 利用可能な CPU/メモリを持つノードがない
  2. ノードセレクターの不一致: Pod が存在しないノードラベルを必要とする
  3. PVC が利用不可: Persistent volume claim がバインドされていない
  4. Taints/Tolerations: Pod がノードの taint を許容できない

クイックフィックス:

# リソース要求を確認
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 5 resources

# ノードの容量を確認
kubectl describe nodes | grep -A 5 "Allocated resources"

# Karpenter クラスタの場合 - プロビジョナーのログを確認
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter

CrashLoopBackOff

症状:

  • Pod が繰り返しクラッシュして再起動する
  • 再起動回数が増え続ける

クイックチェック:

# 現在のログを表示
kubectl logs <pod-name> -n <namespace>

# 以前のコンテナログを表示 (最も役立ちます)
kubectl logs <pod-name> -n <namespace> --previous

# 終了コードを取得
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

一般的な終了コード:

  • 0: 成功 (クラッシュしないはず)
  • 1: アプリケーションエラー
  • 137: SIGKILL (OOMKilled - メモリ不足)
  • 139: SIGSEGV (セグメンテーションフォルト)
  • 143: SIGTERM (終了)

クイックフィックス:

# OOMKilled を確認
kubectl describe pod <pod-name> -n <namespace> | grep -i oom

# メモリ制限を増やす
kubectl set resources deployment <deployment-name> \
  -c <container-name> \
  --limits=memory=512Mi

# liveness/readiness プローブを確認
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 Probe

ImagePullBackOff

症状:

  • Pod がコンテナイメージをプルできない
  • ErrImagePull または ImagePullBackOff ステータス

クイックチェック:

kubectl describe pod <pod-name> -n <namespace> | grep -A 5 "Failed to pull image"

一般的な原因:

  1. ECR 認証: サービスアカウントに ECR プル権限がない
  2. イメージが存在しない: リポジトリ、タグ、またはリージョンが間違っている
  3. レート制限: Docker Hub のレート制限を超過した
  4. レジストリに到達できない: ネットワーク接続の問題

クイックフィックス:

# イメージが存在するか確認 (ECR の場合)
aws ecr describe-images --repository-name <repo-name> --image-ids imageTag=<tag>

# IRSA ロールに ECR 権限があることを確認
kubectl describe serviceaccount <sa-name> -n <namespace> | grep Annotations

# ECR の場合 - IAM ロールに次のポリシーがあることを確認:
# AmazonEC2ContainerRegistryReadOnly または ecr:GetAuthorizationToken, ecr:BatchGetImage

# ノードでイメージプルを手動でテスト
kubectl debug node/<node-name> -it --image=busybox
# 次に: docker pull <image>

OOMKilled

症状:

  • メモリ不足によりコンテナが強制終了された
  • 終了コード 137
  • Last State に "OOMKilled" と表示される

クイックチェック:

# メモリ制限を確認
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 3 "limits:"

# 実際のメモリ使用量を確認
kubectl top pod <pod-name> -n <namespace>

クイックフィックス:

# メモリ制限を増やす
kubectl set resources deployment <deployment-name> \
  --limits=memory=1Gi \
  --requests=memory=512Mi

一般的なノードの問題

Node NotReady

クイックチェック:

kubectl get nodes
kubectl describe node <node-name> | grep -A 10 Conditions

一般的な原因:

  1. ディスクプレッシャー: ノードの実行 o
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

EKS Troubleshooting Guide

Overview

Comprehensive troubleshooting guide for Amazon EKS clusters covering control plane issues, node problems, pod failures, networking, storage, security, and performance diagnostics. Based on 2025 AWS best practices.

Keywords: EKS, Kubernetes, kubectl, debugging, troubleshooting, pod failure, node issues, networking, DNS, AWS, diagnostics

When to Use This Skill

Pod Issues:

  • Pods stuck in Pending, CrashLoopBackOff, ImagePullBackOff
  • OOMKilled containers or CPU throttling
  • Pod evictions or unexpected terminations
  • Application errors in container logs

Cluster Issues:

  • Nodes showing NotReady status
  • Control plane API server timeouts
  • Cluster autoscaling failures
  • etcd performance problems

Networking Problems:

  • DNS resolution failures
  • Service connectivity issues
  • Load balancer provisioning errors
  • Cross-AZ traffic problems
  • VPC CNI IP exhaustion

Security & Permissions:

  • IAM/IRSA permission denied errors
  • RBAC access issues
  • Image pull authentication failures
  • Service account problems

Performance Issues:

  • Slow pod startup times
  • High memory/CPU usage
  • Resource contention
  • Network latency

Quick Diagnostic Workflow

1. Initial Triage (First 60 Seconds)

# Check cluster accessibility
kubectl cluster-info

# Get overall cluster status
kubectl get nodes
kubectl get pods --all-namespaces | grep -v Running

# Check recent events
kubectl get events --all-namespaces --sort-by='.lastTimestamp' | tail -20

# Check control plane components
kubectl get --raw /healthz
kubectl get componentstatuses  # Deprecated in 1.19+ but still useful

2. Identify Problem Area

Pod Issues:

# Get pod status
kubectl get pods -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous  # Previous container logs

Node Issues:

# Check node status
kubectl get nodes -o wide
kubectl describe node <node-name>
kubectl top nodes  # Requires metrics-server

Cluster-Wide Issues:

# Check all resources
kubectl get all --all-namespaces
kubectl get events --all-namespaces --sort-by='.lastTimestamp'

# Check EKS cluster health (AWS CLI)
aws eks describe-cluster --name <cluster-name> --query 'cluster.health'

3. Deep Dive (See Reference Guides)

  • Pod/Workload Issuesreferences/workload-issues.md
  • Node/Cluster Issuesreferences/cluster-issues.md
  • Networking Issuesreferences/networking-issues.md

Common Pod Failure Patterns

Pending Pods

Symptoms:

  • Pod stuck in Pending state indefinitely
  • No containers running

Quick Check:

kubectl describe pod <pod-name> -n <namespace> | grep -A 10 Events

Common Causes:

  1. Insufficient Resources: No nodes with available CPU/memory
  2. Node Selector Mismatch: Pod requires node labels that don't exist
  3. PVC Not Available: Persistent volume claim not bound
  4. Taints/Tolerations: Pod can't tolerate node taints

Quick Fixes:

# Check resource requests
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 5 resources

# Check node capacity
kubectl describe nodes | grep -A 5 "Allocated resources"

# For Karpenter clusters - check provisioner logs
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter

CrashLoopBackOff

Symptoms:

  • Pod repeatedly crashing and restarting
  • Restart count keeps increasing

Quick Check:

# View current logs
kubectl logs <pod-name> -n <namespace>

# View previous container logs (most useful)
kubectl logs <pod-name> -n <namespace> --previous

# Get exit code
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

Common Exit Codes:

  • 0: Success (shouldn't crash)
  • 1: Application error
  • 137: SIGKILL (OOMKilled - out of memory)
  • 139: SIGSEGV (segmentation fault)
  • 143: SIGTERM (terminated)

Quick Fixes:

# Check for OOMKilled
kubectl describe pod <pod-name> -n <namespace> | grep -i oom

# Increase memory limit
kubectl set resources deployment <deployment-name> \
  -c <container-name> \
  --limits=memory=512Mi

# Check liveness/readiness probes
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 Probe

ImagePullBackOff

Symptoms:

  • Pod can't pull container image
  • ErrImagePull or ImagePullBackOff status

Quick Check:

kubectl describe pod <pod-name> -n <namespace> | grep -A 5 "Failed to pull image"

Common Causes:

  1. ECR Authentication: Service account lacks ECR pull permissions
  2. Image Doesn't Exist: Wrong repository, tag, or region
  3. Rate Limiting: Docker Hub rate limits exceeded
  4. Registry Unreachable: Network connectivity issues

Quick Fixes:

# Check if image exists (for ECR)
aws ecr describe-images --repository-name <repo-name> --image-ids imageTag=<tag>

# Verify IRSA role has ECR permissions
kubectl describe serviceaccount <sa-name> -n <namespace> | grep Annotations

# For ECR - ensure IAM role has this policy:
# AmazonEC2ContainerRegistryReadOnly or ecr:GetAuthorizationToken, ecr:BatchGetImage

# Test image pull manually on node
kubectl debug node/<node-name> -it --image=busybox
# Then: docker pull <image>

OOMKilled

Symptoms:

  • Container killed due to out of memory
  • Exit code 137
  • Last State shows "OOMKilled"

Quick Check:

# Check memory limits
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 3 "limits:"

# Check actual memory usage
kubectl top pod <pod-name> -n <namespace>

Quick Fix:

# Increase memory limit
kubectl set resources deployment <deployment-name> \
  --limits=memory=1Gi \
  --requests=memory=512Mi

Common Node Issues

Node NotReady

Quick Check:

kubectl get nodes
kubectl describe node <node-name> | grep -A 10 Conditions

Common Causes:

  1. Disk Pressure: Node running out of disk space
  2. Memory Pressure: Node running out of memory
  3. Network Issues: kubelet can't reach API server
  4. Kubelet Issues: kubelet service crashed or unhealthy

Quick Fixes:

# Check node conditions
kubectl describe node <node-name> | grep -E "MemoryPressure|DiskPressure|PIDPressure"

# For EKS managed nodes - check EC2 instance health
aws ec2 describe-instance-status --instance-ids <instance-id>

# Drain and delete node (if managed node group - ASG will replace)
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
kubectl delete node <node-name>

IP Address Exhaustion

Symptoms:

  • Pods can't get IP addresses
  • Nodes showing high ENI usage
  • CNI errors in logs

Quick Check:

# Check VPC CNI logs
kubectl logs -n kube-system -l k8s-app=aws-node --tail=100

# Check IP addresses per node
kubectl get nodes -o custom-columns=NAME:.metadata.name,ADDRESSES:.status.addresses[*].address

# Check ENI usage
aws ec2 describe-instances --instance-ids <instance-id> \
  --query 'Reservations[].Instances[].NetworkInterfaces[].PrivateIpAddresses'

Quick Fixes:

# Enable prefix delegation (for new nodes)
kubectl set env daemonset aws-node \
  -n kube-system \
  ENABLE_PREFIX_DELEGATION=true

# Increase warm pool targets
kubectl set env daemonset aws-node \
  -n kube-system \
  WARM_IP_TARGET=5

Essential kubectl Commands

Information Gathering

# Pod debugging
kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --tail=100 -f
kubectl logs <pod-name> -n <namespace> -c <container-name>  # Multi-container pods
kubectl logs <pod-name> -n <namespace> --previous  # Previous crash logs

# Node debugging
kubectl get nodes -o wide
kubectl describe node <node-name>
kubectl top nodes
kubectl top pods -n <namespace>

# Events (VERY useful)
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
kubectl get events --all-namespaces --sort-by='.lastTimestamp' | tail -50

# Resource usage
kubectl top pods -n <namespace> --containers
kubectl describe node <node-name> | grep -A 5 "Allocated resources"

Advanced Debugging

# Execute command in running pod
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh

# Port forward for local testing
kubectl port-forward <pod-name> -n <namespace> 8080:80

# Debug with ephemeral container (K8s 1.23+)
kubectl debug <pod-name> -n <namespace> -it --image=busybox

# Debug node issues
kubectl debug node/<node-name> -it --image=ubuntu

# Copy files from pod
kubectl cp <namespace>/<pod-name>:/path/to/file ./local-file

# Get pod YAML
kubectl get pod <pod-name> -n <namespace> -o yaml

# Get all resources in namespace
kubectl get all -n <namespace>
kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <namespace>

Filtering & Formatting

# Get pods not running
kubectl get pods --all-namespaces --field-selector=status.phase!=Running

# Get pods by label
kubectl get pods -n <namespace> -l app=myapp

# Custom columns
kubectl get pods -n <namespace> -o custom-columns=\
NAME:.metadata.name,\
STATUS:.status.phase,\
NODE:.spec.nodeName,\
IP:.status.podIP

# JSONPath queries
kubectl get pods -n <namespace> -o jsonpath='{.items[*].metadata.name}'

# Get pod restart count
kubectl get pods -n <namespace> -o jsonpath=\
'{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[0].restartCount}{"\n"}{end}'

AWS-Specific Troubleshooting

EKS Cluster Health

# Check EKS cluster status
aws eks describe-cluster --name <cluster-name> \
  --query 'cluster.{Status:status,Health:health,Version:version}'

# List all EKS clusters
aws eks list-clusters

# Check addon status
aws eks list-addons --cluster-name <cluster-name>
aws eks describe-addon --cluster-name <cluster-name> --addon-name vpc-cni

# Update kubeconfig
aws eks update-kubeconfig --name <cluster-name> --region <region>

IAM/IRSA Troubleshooting

# Check service account IRSA annotation
kubectl get sa <sa-name> -n <namespace> -o yaml | grep eks.amazonaws.com/role-arn

# Verify pod has correct service account
kubectl get pod <pod-name> -n <namespace> -o yaml | grep serviceAccountName

# Check if pod has AWS credentials
kubectl exec <pod-name> -n <namespace> -- env | grep AWS

# Test IAM permissions from pod
kubectl exec <pod-name> -n <namespace> -- aws sts get-caller-identity
kubectl exec <pod-name> -n <namespace> -- aws s3 ls  # Test S3 access

ECR Authentication

# Get ECR login password
aws ecr get-login-password --region <region>

# Test ECR access
aws ecr describe-repositories --region <region>

# Check if IAM role/user has ECR permissions
aws iam get-role --role-name <role-name>
aws iam list-attached-role-policies --role-name <role-name>

Karpenter Troubleshooting

# Check Karpenter logs
kubectl logs -n karpenter -l app.kubernetes.io/name=karpenter --tail=100 -f

# Check provisioner configuration
kubectl get provisioner -o yaml

# Check Karpenter controller status
kubectl get pods -n karpenter

# Debug why nodes not provisioning
kubectl describe provisioner default
kubectl get events -n karpenter --sort-by='.lastTimestamp'

Performance Diagnostics

Resource Contention

# Check node resource usage
kubectl top nodes

# Check pod resource usage
kubectl top pods -n <namespace> --sort-by=memory
kubectl top pods -n <namespace> --sort-by=cpu

# Check resource requests vs limits
kubectl get pods -n <namespace> -o custom-columns=\
NAME:.metadata.name,\
CPU_REQ:.spec.containers[*].resources.requests.cpu,\
CPU_LIM:.spec.containers[*].resources.limits.cpu,\
MEM_REQ:.spec.containers[*].resources.requests.memory,\
MEM_LIM:.spec.containers[*].resources.limits.memory

Application Performance

# Check pod readiness/liveness probes
kubectl get pods -n <namespace> -o yaml | grep -A 10 Probe

# Check pod startup time
kubectl describe pod <pod-name> -n <namespace> | grep Started

# Profile application in pod
kubectl exec <pod-name> -n <namespace> -- top
kubectl exec <pod-name> -n <namespace> -- netstat -tuln

Log Analysis

CloudWatch Container Insights

# Enable Container Insights (if not enabled)
# Via AWS CLI:
aws eks update-cluster-config \
  --name <cluster-name> \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

# Check control plane logs in CloudWatch
# Log groups:
# - /aws/eks/<cluster-name>/cluster
# - /aws/containerinsights/<cluster-name>/application
# - /aws/containerinsights/<cluster-name>/host
# - /aws/containerinsights/<cluster-name>/dataplane

Fluent Bit Logs

# Check Fluent Bit daemonset
kubectl get pods -n amazon-cloudwatch -l k8s-app=fluent-bit

# Check Fluent Bit logs
kubectl logs -n amazon-cloudwatch -l k8s-app=fluent-bit --tail=50

Emergency Procedures

Pod Stuck Terminating

# Force delete pod
kubectl delete pod <pod-name> -n <namespace> --grace-period=0 --force

# If still stuck, remove finalizers
kubectl patch pod <pod-name> -n <namespace> -p '{"metadata":{"finalizers":null}}'

Node Stuck Draining

# Force drain
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force

# If still stuck, delete pods directly
kubectl delete pods -n <namespace> --field-selector spec.nodeName=<node-name> --force --grace-period=0

Cluster Unresponsive

# Check API server health
kubectl get --raw /healthz

# Check control plane logs (CloudWatch)
aws logs tail /aws/eks/<cluster-name>/cluster --follow

# Restart coredns if DNS issues
kubectl rollout restart deployment coredns -n kube-system

# Check etcd health (EKS manages this, but can check API responsiveness)
time kubectl get nodes  # Should be < 1 second

Prevention Best Practices

Resource Management

# Always set resource requests and limits
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"  # CPU limits optional, can cause throttling

Health Checks

# Implement probes for all applications
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 3

startupProbe:  # For slow-starting apps
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

High Availability

# Pod disruption budgets
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Reference Guides

For detailed troubleshooting of specific areas:

Additional Resources

AWS Documentation:

Kubernetes Documentation:

Tools:


Quick Start: Use diagnostic workflow above → Identify issue type → Jump to relevant reference guide Last Updated: November 27, 2025 (2025 AWS Best Practices)