2026年8月29日

Amazon EKSでKubernetesクラスターを構築する方法｜eksctlの設定ファイル・権限・アドオン・削除まで

Docker・コンテナ

Amazon EKS（Elastic Kubernetes Service）のクラスターは、eksctl の設定ファイルを1つ書いて作るのが手堅い方法です。マネジメントコンソールで画面を順にたどるより、何を作ったかがファイルに残り、作り直しや削除も同じファイルで行えます。この記事では、作業前に用意するもの、eksctl でのクラスター作成、kubectl からの接続確認、権限（アクセスエントリー）の考え方、最初に入れておくアドオン、WordPressを載せるときの構成、後片付けまでを順に説明します。

EKSは機能の追加や画面の変更が多いサービスです。ここでの説明は執筆時点（2026年10月現在）の情報をもとにしていますが、コマンドのオプションや既定値は版によって変わるため、実行前に eksctl とAWSの公式ドキュメントで確認してください。

作業前に決めること・用意するもの

最初に決めておきたいのは、リージョン、Kubernetesのバージョン、ノードの持ち方の3つです。

リージョン：東京なら ap-northeast-1。データベースなど関連するサービスと同じリージョンにそろえます。
バージョン：EKSがその時点で提供している版から選びます。古い版は標準サポートが終わると延長サポート扱いになり、追加の料金がかかります。新規に作るなら、提供されている中で新しめの版を選ぶと、次のアップグレードまでの猶予が長くなります。
ノード：自分でEC2のノードグループを管理するか、Fargate や EKS Auto Mode のようにAWS側に任せる範囲を広げるかを選びます。この記事では、仕組みが見えやすいマネージドノードグループで説明します。

手元のPCには次のツールを入れます。

AWS CLI（認証情報を設定済みのもの）
eksctl
kubectl（クラスターの版との差が1マイナーバージョン以内のもの）
Helm（アドオンの導入に使います）

作業に使うIAMユーザーまたはロールには、EKS・EC2・VPC・IAM・CloudFormationを操作できる権限が必要です。eksctl は内部でCloudFormationのスタックを作るため、権限が足りないと途中で止まり、スタックだけが中途半端に残ることがあります。

eksctl の設定ファイルを書く

コマンドの引数だけでも作れますが、設定ファイルにしておくと後から見返せます。

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

metadata:
  name: wp-cluster
  region: ap-northeast-1
  version: "1.33"   # 例。作成時点でEKSが提供している版を指定する

accessConfig:
  authenticationMode: API_AND_CONFIG_MAP

iam:
  withOIDC: true

managedNodeGroups:
  - name: ng-general
    instanceType: m6i.large
    minSize: 2
    desiredCapacity: 2
    maxSize: 4
    privateNetworking: true
    volumeSize: 30
    labels:
      role: general

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy
  - name: eks-pod-identity-agent
  - name: aws-ebs-csi-driver

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

version は文字列として引用符で囲みます。囲まないと 1.30 が 1.3 と解釈されるような事故が起きます。
privateNetworking: true にすると、ノードはプライベートサブネットに置かれ、インターネットへの出口はNATゲートウェイ経由になります。ノードに直接パブリックIPを持たせない構成です。
VPCを指定しなければ、eksctl がパブリックサブネットとプライベートサブネットを含むVPCを新しく作ります。既存のVPCに入れたい場合は vpc.subnets でサブネットを指定します。既存のサブネットを使うときは、ロードバランサーの配置に使うタグ（パブリックに kubernetes.io/role/elb、プライベートに kubernetes.io/role/internal-elb）が付いているかも確認してください。
minSize を2以上にし、ノードを複数のアベイラビリティーゾーンに散らしておくと、1台が落ちてもサービスが止まりにくくなります。

クラスターを作成して接続を確かめる

eksctl create cluster -f cluster.yaml

作成には十数分から20分程度かかります。途中でエラーになった場合は、AWSコンソールのCloudFormationで eksctl-wp-cluster-... という名前のスタックのイベントを見ると、どのリソースで失敗したかが分かります。よくある原因は、IAMの権限不足、リージョンでのインスタンスタイプの在庫や上限（サービスクォータ）、Elastic IPやVPCの数の上限です。

完了すると、eksctl が kubeconfig にクラスターの接続情報を書き込みます。別のPCから接続するときは次のコマンドで追加します。

aws eks update-kubeconfig --region ap-northeast-1 --name wp-cluster
kubectl get nodes -o wide
kubectl get pods -n kube-system

ノードが Ready になり、kube-system 名前空間の coredns や aws-node（VPC CNI）のPodが Running なら、クラスターとしては動いています。ノードが NotReady のままなら、VPC CNI のPodのログ（kubectl logs -n kube-system -l k8s-app=aws-node）を見ると、サブネットのIPアドレス不足などの原因が出ていることが多いです。

誰がクラスターを操作できるか（アクセスエントリー）

EKSでは、IAMの誰がKubernetesの中でどの権限を持つかを結び付ける必要があります。以前は kube-system の aws-auth というConfigMapを手で編集していましたが、現在はEKSのAPIで管理する「アクセスエントリー」が使えます。上の設定で authenticationMode: API_AND_CONFIG_MAP にしているのは、新しい方式を使いつつ、古い方式も読める状態にしておくためです。

クラスターを作ったIAMの主体には、既定で管理者の権限が付きます。ほかのメンバーやCI/CDのロールに権限を渡すときは、アクセスエントリーを作ってアクセスポリシーを関連付けます。

aws eks create-access-entry \
  --cluster-name wp-cluster \
  --principal-arn arn:aws:iam::123456789012:role/your-deploy-role

aws eks associate-access-policy \
  --cluster-name wp-cluster \
  --principal-arn arn:aws:iam::123456789012:role/your-deploy-role \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=wordpress

ここでつまずきやすいのは、作成者のIAMユーザーを削除したり、作業用のロールを切り替えたりして、誰も管理者として入れなくなることです。管理者の権限を持つ主体を2つ以上登録しておくと、こうした締め出しを防げます。アカウントIDやロール名は例なので、自分の環境の値に置き換えてください。

最初に入れておくアドオン

設定ファイルの addons で入れたものの役割は次のとおりです。

vpc-cni / coredns / kube-proxy：Podのネットワーク、クラスター内の名前解決、Serviceの振り分けを担う基本の部品です。
eks-pod-identity-agent：Podに個別のIAMロールを渡す「EKS Pod Identity」を使うためのエージェントです。Podの中にアクセスキーを置かずにS3などへアクセスできます。
aws-ebs-csi-driver：EBSボリュームを永続ボリュームとして使うためのドライバーです。これが無いと、PersistentVolumeClaim を作ってもボリュームが割り当てられず、Podが Pending のまま止まります。ドライバー自体にもEBSを操作するIAMの権限が必要なので、Pod Identity かIRSA（withOIDC: true で使えるOIDC連携）で権限を渡します。

外部からHTTPで受け付けるには、AWS Load Balancer Controller を Helm で入れ、Ingress から ALB を作らせる構成が一般的です。コントローラーにもIAMポリシーが必要で、導入手順とポリシーの内容はコントローラーの版ごとに公式の手順書で更新されています。手順書の版と、入れるHelmチャートの版を合わせてください。

WordPressを載せるときの構成

EKSにWordPressを載せる場合、データベースとアップロードファイルの置き場をどうするかが要点です。

データベース：クラスター内のMySQLのPodより、Amazon RDS（MySQLまたはMariaDB）を使うほうが、バックアップや障害時の切り替えをAWSに任せられます。接続パスワードはKubernetesのSecretか、AWS Secrets Managerから渡し、イメージやYAMLに直接書かないようにします。
wp-content/uploads：EBSは基本的に1つのノードからしかマウントできず（ReadWriteOnce）、アベイラビリティーゾーンもまたげません。WordPressのPodを複数台にするなら、複数のPodから同時に読み書きできるAmazon EFS（EFS CSI ドライバー経由）を使うか、メディアをS3に置くプラグインを使う構成にします。
キャッシュ：オブジェクトキャッシュにはElastiCache（RedisまたはValkey）が使えます。

1台構成のWordPressなら、EKSよりEC2やLightsailのほうが運用は軽く済みます。EKSは、複数のアプリをまとめて動かす、負荷に合わせて台数を増減させるといった要件があるときに向いています。

費用がかかる部分と後片付け

EKSでは、ノードのEC2とは別に、クラスター（コントロールプレーン）自体に時間単位の料金がかかります。ほかにもNATゲートウェイ、ロードバランサー、EBSボリューム、データ転送が積み上がります。具体的な金額は変わるため、AWSの料金ページと料金計算ツールで確認してください。検証用のクラスターは、使い終わったら削除しておくのが無難です。

削除の前に、type: LoadBalancer のServiceやIngressを先に消しておきます。これらが作ったロードバランサーはKubernetes側のコントローラーが管理しているため、クラスターだけを消すとAWS上に残り、料金がかかり続けることがあります。

kubectl get svc -A | grep LoadBalancer
kubectl get ingress -A
# 上で表示されたものを削除してから
eksctl delete cluster -f cluster.yaml

削除後は、EC2のロードバランサー、EBSボリューム、CloudFormationのスタックが残っていないかをコンソールで確認します。動的に作られたEBSボリュームは、StorageClass の回収ポリシーによってはクラスター削除後も残ります。必要なデータは削除前にスナップショットなどで退避してください。

まとめ

EKSのクラスターは eksctl の設定ファイルで作ると、作り直しと削除を同じファイルで管理できる。
作成に失敗したらCloudFormationのスタックのイベントを見る。権限不足とサービスクォータが多い原因。
権限はアクセスエントリーで管理し、管理者を2つ以上登録して締め出しを防ぐ。
永続ボリュームには EBS CSI ドライバー、複数のPodで共有するファイルにはEFSかS3を使う。WordPressのデータベースはRDSに分けると運用が軽い。
削除前にLoadBalancerのServiceとIngressを消し、削除後に残ったリソースを確認する。