AWS EKSでKubernetesクラスターを起動する方法（eksctlで作成・動作確認・削除まで）

AWS EKS で Kubernetes を起動するいちばん手堅い方法は、eksctl に設定ファイルを渡してクラスターとマネージドノードグループを一度に作り、kubectl でノードとテスト用 Pod が動くことを確かめてから、使い終わったら同じ設定ファイルで削除する流れです。この記事では、検証用のクラスターを東京リージョンに立ち上げ、つまずきやすいエラーの読み方と後片付けまでを順に説明します。WordPress を本番で EKS に載せる前の「まず動かしてみる」段階を想定しています。

始める前に知っておきたいこと

EKS は Kubernetes のコントロールプレーン（API サーバーや etcd）を AWS が運用し、利用者はワーカーノード側とアプリケーションを管理するサービスです。手軽に見えますが、クラスターを作った時点からコントロールプレーン、EC2 ノード、NAT ゲートウェイ、EBS などが課金対象になります。料金は変わるため本記事では触れませんが、検証が終わったら当日中に削除する前提で進めてください。

また、WordPress を EKS で動かす場合は、アップロードファイルを複数 Pod で共有するストレージ（Amazon EFS など）や、データベースを Pod の外に置く構成（Amazon RDS など）が別途必要になります。小規模なサイトなら EC2 1台や Lightsail のほうが運用負担は小さいことも多いので、EKS が本当に必要かは先に検討しておくと無駄がありません。

必要なツールと IAM の準備

作業用 PC（または CloudShell）に次の3つを用意します。

• AWS CLI v2：認証情報の確認と kubeconfig の生成に使います
• kubectl：クラスターの操作に使います。クラスターの Kubernetes バージョンとマイナーバージョンが1つ以内の差に収まるものを選ぶのが基本です
• eksctl：EKS クラスターを作成・削除するための公式 CLI です（GitHub の eksctl-io/eksctl で開発されています）

インストール後、バージョンと「いま誰として AWS を操作しているか」を確認します。

aws --version
kubectl version --client
eksctl version

# 操作している IAM ユーザー／ロールを確認
aws sts get-caller-identity

get-caller-identity に表示される ARN は後で重要になります。EKS では、クラスターを作成した IAM 主体にクラスター管理者の権限が与えられるのが既定の動きです。チームで別のロールを使う予定なら、どの主体で作成するかを先に決めておくと「作った本人しか kubectl を使えない」状態を避けられます。

作成に使う IAM 主体には、EKS・EC2・CloudFormation・IAM（ロール作成）などの広い権限が必要です。検証用アカウントで行い、本番アカウントでは権限を絞ったロールを用意するのが安全です。

設定ファイルを書いてクラスターを作成する

eksctl はコマンドのオプションだけでもクラスターを作れますが、設定ファイルにしておくと削除や再作成のときに同じ内容を再現でき、レビューもしやすくなります。

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: wp-test
  region: ap-northeast-1

iam:
  withOIDC: true

managedNodeGroups:
  - name: ng-general
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 3
    volumeSize: 20
    privateNetworking: true

ポイントは次のとおりです。

• metadata.version を省略すると、eksctl がその時点の既定バージョンを選びます。特定のバージョンで検証したい場合は version: "1.xx" の形で指定します。EKS が対応するバージョンは定期的に入れ替わるため、AWS のドキュメントで確認してから決めてください。標準サポート期間を過ぎたバージョンは延長サポート扱いになり、追加料金がかかる仕組みです（2026年10月現在）
• withOIDC: true は IAM ロールを Pod に割り当てる仕組み（IRSA）の前提です。後から AWS Load Balancer Controller や EBS CSI ドライバーを入れるときに必要になります
• privateNetworking: true にするとノードはプライベートサブネットに置かれ、インターネットへは NAT ゲートウェイ経由で出ます。eksctl は VPC を指定しない場合、専用の VPC とサブネットを自動で作ります
• t3.medium は検証向けの例です。インスタンスタイプごとに配置できる Pod 数の上限（ENI と IP アドレスの数で決まる）が異なる点は覚えておくとトラブル時に役立ちます

準備ができたら作成します。

eksctl create cluster -f cluster.yaml

eksctl は裏側で CloudFormation スタックを作り、コントロールプレーン、VPC、ノードグループの順に構築します。環境によって十数分から20分程度かかることがあるので、途中で Ctrl+C を押さずに待ちます。完了すると ~/.kube/config にクラスターへの接続情報が書き込まれます。

kubeconfig と接続を確認する

別の端末から操作する場合や、kubeconfig を作り直したい場合は AWS CLI で生成できます。

aws eks update-kubeconfig --region ap-northeast-1 --name wp-test

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods -n kube-system

kubectl get nodes で2台のノードが Ready になっていれば、クラスターは起動しています。kube-system には VPC CNI（aws-node）、CoreDNS、kube-proxy などの Pod が並び、すべて Running になっているのが正常な状態です。CoreDNS が Pending のままならノードが準備できていない、CrashLoopBackOff ならネットワークやアドオン側の問題を疑います。

テスト用の Pod を動かして確認する

ノードが Ready でも、実際にコンテナが起動してイメージを取得できるかは別問題です。nginx を2つ起動して確かめます。

kubectl create deployment hello --image=nginx --replicas=2
kubectl rollout status deployment/hello
kubectl get pods -l app=hello -o wide

# ロードバランサーを作らずに手元から接続を確認
kubectl port-forward deployment/hello 8080:80
# 別ターミナルで
curl -I http://localhost:8080

ここではあえて type: LoadBalancer の Service を使わず、port-forward で確認しています。LoadBalancer の Service を作ると AWS 側にロードバランサーが作成されて課金が増えるうえ、削除の順番を誤ると VPC が消せなくなる原因になるためです。外部公開は、AWS Load Balancer Controller と Ingress を導入する段階で改めて設計するのが無難です。

HTTP/1.1 200 OK が返れば、イメージの取得（NAT 経由のインターネット接続）、Pod の起動、kubectl からの接続がひととおり動いていることになります。

つまずきやすいエラーと確認方法

eksctl の作成が途中で失敗する

eksctl のログに CloudFormation スタック名が表示されます。AWS コンソールの CloudFormation で該当スタックの「イベント」を開き、最初に失敗したリソースの理由を読みます。よくある原因は次の順です。

1. サービスクォータ不足：VPC 数、Elastic IP 数、EC2 の vCPU 上限などに達している
2. インスタンスタイプが選んだアベイラビリティゾーンで使えない
3. IAM 権限不足：ロールの作成やタグ付けが拒否されている

失敗した場合、eksctl が途中まで作ったスタックが残ることがあります。eksctl delete cluster -f cluster.yaml で消してから作り直してください。

kubectl で Unauthorized や認証エラーになる

「You must be logged in to the server (Unauthorized)」などのエラーは、kubectl が使っている IAM 主体にクラスターへのアクセス権が無いことを示します。まず aws sts get-caller-identity で、クラスターを作成したときと同じ ARN かを確認します。別のロールに切り替えている場合は、EKS のアクセスエントリーで権限を付与します。

aws eks list-access-entries --cluster-name wp-test --region ap-northeast-1

アクセスエントリーの追加（aws eks create-access-entry と aws eks associate-access-policy）は、付与する権限の範囲をよく確認してから行ってください。古い手順では aws-auth ConfigMap を編集する方法が紹介されていますが、現在はアクセスエントリーを使う方法が AWS の推奨になっています。

Pod が Pending のまま動かない

kubectl describe pod <Pod名> の末尾にある Events を読みます。「Insufficient cpu」「Insufficient memory」ならノードの資源不足、「Too many pods」ならインスタンスタイプごとの Pod 数上限に達しています。ノードグループの台数を増やすか、インスタンスタイプを見直します。イメージ取得に失敗している場合は「ErrImagePull」と表示され、NAT ゲートウェイやイメージ名の誤りを確認します。

使い終わったら削除する

検証用クラスターは放置すると課金が続きます。削除の前に、LoadBalancer 型の Service や Ingress が残っていないかを確認します。これらが作ったロードバランサーやセキュリティグループが残っていると、VPC の削除が失敗する原因になります。

kubectl delete deployment hello
kubectl get svc -A
kubectl get ingress -A

eksctl delete cluster -f cluster.yaml --wait

--wait を付けると CloudFormation スタックの削除完了まで待ちます。最後に CloudFormation コンソールで eksctl-wp-test- で始まるスタックが残っていないか、EC2 コンソールでロードバランサーや EBS ボリュームが残っていないかを目で確認しておくと安心です。

本番運用に進む前に考えること

検証で起動できたら、本番に向けて次の点を設計します。

• Kubernetes バージョンの更新計画：EKS はバージョンごとにサポート期間があり、定期的なアップグレードが前提です
• ノードの管理方法：マネージドノードグループのほか、ノード管理を AWS に任せる EKS Auto Mode や Karpenter といった選択肢もあります。機能や対応状況は更新が多いので、採用前に最新のドキュメントで確認してください
• WordPress の構成：DB は RDS、メディアは EFS や S3 に分け、Pod は使い捨てにできる状態にします
• 権限：アクセスエントリーと IRSA（または EKS Pod Identity）で、人とアプリの権限を分けます

まとめ

• EKS の起動は、eksctl の設定ファイルでクラスターとマネージドノードグループを作るのが再現性が高い方法です
• 作成後は kubectl get nodes と kube-system の Pod、テスト用 Deployment の port-forward で、ノード・ネットワーク・接続を順に確認します
• 作成の失敗は CloudFormation のイベント、認証エラーは IAM 主体とアクセスエントリー、Pending は kubectl describe pod の Events から原因を絞ります
• 検証が終わったら LoadBalancer や Ingress を消してから eksctl delete cluster で削除し、残ったリソースがないか確認します

• KubernetesのDeploymentの使い方
• KubernetesのPodが起動しないときのデバッグ方法