EKS クラスターをマネコンで構築し、Pod / Deployment / Service など k8s の基本操作を一通り学ぶ
このハンズオンでは、Amazon EKS（Elastic Kubernetes Service）クラスターをマネジメントコンソールで構築し、kubectl から Kubernetes の基本リソース（Pod / Deployment / Service）を操作します。コンテナオーケストレーションの中核である k8s の概念と操作を、実際に手を動かしながら習得します。
| 項目 | 内容 |
|---|---|
| 所要時間 | 90〜120 分（クラスター作成の待ち時間含む） |
| 難易度 | 中級 |
| 主要サービス | Amazon EKS、EC2（マネージドノード）、IAM、kubectl |
| 構築方法 | マネジメントコンソール操作（eksctl は使用しない） |
| 前提リソース | デフォルト VPC（または 2 AZ 以上のサブネットを持つ VPC） |
EKS クラスターは稼働中 1 クラスターあたり $0.10/時間（約 $73/月）の固定料金がかかります。さらにマネージドノードの EC2 料金（t3.medium × 2 台など）と、Service(LoadBalancer) で作成される ELB の料金が加算されます。ハンズオン完了後は必ずすべて削除してください。放置すると 1 日で数百円規模の課金になります。
| リソース | 役割 |
|---|---|
| Pod | コンテナを動かす最小単位。1 つ以上のコンテナをまとめたもの |
| Deployment | Pod の数（レプリカ）を維持・更新する。自己修復・ローリング更新を担う |
| Service | Pod 群への安定したアクセス先（IP/DNS）を提供。負荷分散も行う |
| Node | Pod が実際に動作するワーカー（EKS ではマネージドノードの EC2） |
| Namespace | リソースを論理的に分離する単位（default / kube-system など） |
EKS では コントロールプレーン（k8s の頭脳）を AWS が完全管理します。利用者は データプレーン（Pod が動くノード）を用意します。このハンズオンではデータプレーンに「マネージドノードグループ」（EC2）を使います。
EKS クラスターを作成した IAM プリンシパル（ユーザー/ロール）には、自動的にクラスター管理者権限（access entry）が付与されます。後で kubectl を実行する CloudShell も、クラスター作成時と同じ IAM ユーザーで操作してください。異なるプリンシパルだと kubectl で認証エラーになります。
CloudShell に kubectl が無い場合は以下でインストールします（公式の安定版を取得）。
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
mkdir -p ~/bin && mv kubectl ~/bin/
export PATH=~/bin:$PATH
kubectl version --client
kubectl はクラスターの Kubernetes バージョンと ±1 マイナーバージョン以内であれば動作します。最新の安定版を入れておけば、本ハンズオンで作成するクラスター（最新マイナス 1〜2 程度）と問題なく通信できます。
EKS には「クラスター用ロール」と「ノード用ロール」の 2 つの IAM ロールが必要です。
AmazonEKSClusterPolicy が自動で付与される → 「次へ」handson-eks-cluster-role → 「ロールを作成」| ポリシー | 役割 |
|---|---|
| AmazonEKSWorkerNodePolicy | ノードがクラスターに参加するための権限 |
| AmazonEKS_CNI_Policy | Pod ネットワーク（VPC CNI）の権限 |
| AmazonEC2ContainerRegistryReadOnly | ECR からコンテナイメージを取得する権限 |
handson-eks-node-role → 「ロールを作成」クラスターロールは EKS コントロールプレーンが AWS リソースを管理するために使います（信頼先は eks.amazonaws.com）。ノードロールは EC2 ワーカーノードがクラスターに参加し ECR からイメージを取得するために使います（信頼先は ec2.amazonaws.com）。
EKS はコントロールプレーンの冗長化のため、異なる 2 つ以上の AZのサブネットを要求します。1 AZ しか選べない場合は作成に失敗します。デフォルト VPC なら各 AZ にサブネットがあるので 2 つ以上選択してください。
kube-proxy / CoreDNS / Amazon VPC CNI をそのまま有効化 → 「次へ」ステータスが「作成中」→「アクティブ」に変わるまで待ちます。この間に次のステップの準備（CloudShell で kubectl インストール）を進められますが、ノードグループ作成（ステップ 3）はクラスターがアクティブになってからです。
クラスターが「アクティブ」になったら、Pod を動かすワーカーノード（EC2）を追加します。
EKS では各ノードで動かせる Pod 数が ENI（ネットワークインターフェイス）数に依存します。t3.micro/small は IP 数が少なく、システム Pod（CoreDNS など）でほぼ埋まってしまうため、t3.medium 以上を推奨します。
「コンピューティング」タブにノードグループが「アクティブ」で表示され、ノード（EC2）2 台が作成されれば成功です。
CloudShell から kubectl がクラスターと通信できるよう設定します。
aws eks update-kubeconfig \
--region ap-northeast-1 \
--name handson-eks-cluster
これで ~/.kube/config にクラスターの接続情報が書き込まれます。
kubectl get nodes
NAME STATUS ROLES AGE VERSION ip-172-31-xx-xx.ap-northeast-1.compute.internal Ready <none> 3m v1.31.x ip-172-31-yy-yy.ap-northeast-1.compute.internal Ready <none> 3m v1.31.x
2 台のノードが Ready で表示されれば接続成功です。
# システム Pod（CoreDNS, kube-proxy, aws-node）の確認
kubectl get pods -n kube-system
# 全 namespace の確認
kubectl get namespaces
error: You must be logged in to the server (Unauthorized) が出たらkubectl を実行している IAM プリンシパルがクラスター作成者と異なる場合に発生します。CloudShell が想定の IAM ユーザーで動いているか aws sts get-caller-identity で確認してください。別ユーザーで作成した場合は EKS の「アクセス」タブからアクセスエントリを追加します。
まずは単一の Pod を起動して、k8s の最も基本的な操作を体験します。
kubectl run nginx-pod --image=nginx:latest
# 一覧表示
kubectl get pods
# 詳細表示（イベント・割り当てノードなど）
kubectl describe pod nginx-pod
# より詳しい情報（IP・ノード名を列に追加）
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE nginx-pod 1/1 Running 0 30s
STATUS が Running、READY が 1/1 になれば Pod 起動成功です。ContainerCreating の場合は数十秒待ちます。
# Pod（コンテナ）のログを表示
kubectl logs nginx-pod
# Pod 内でコマンドを実行
kubectl exec nginx-pod -- nginx -v
# Pod 内のシェルに入る（対話）
kubectl exec -it nginx-pod -- /bin/bash
# → コンテナ内に入る。`exit` で抜ける
# ローカル(CloudShell)の 8080 を Pod の 80 に転送
kubectl port-forward nginx-pod 8080:80 &
curl http://localhost:8080
# → Nginx の "Welcome to nginx!" HTML が返る
# 確認後: kill %1 でフォワードを停止
kubectl delete pod nginx-pod
kubectl run で作った単体 Pod は、削除されると自動で復活しません。ノード障害で消えても再作成されません。本番では次のステップの Deployment で Pod を管理し、自己修復・冗長化を実現します。
Deployment は指定した数の Pod（レプリカ）を維持し、自己修復とローリング更新を担うリソースです。マニフェスト（YAML）で宣言的に管理します。
CloudShell で以下のファイルを作成します（cat > ... << 'EOF' で貼り付け）。
cat > nginx-deployment.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
EOF
kubectl apply -f nginx-deployment.yaml
# Deployment の確認
kubectl get deployments
# Pod が 3 つ作られたことを確認
kubectl get pods -l app=nginx
# ReplicaSet（Deployment が内部で作る Pod 管理単位）
kubectl get replicasets
NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 40s
3/3 で 3 つの Pod が動いていれば成功です。
Pod を 1 つ手動削除しても、Deployment が即座に新しい Pod を作り直します。
# Pod 名を 1 つコピーして削除
kubectl get pods -l app=nginx
kubectl delete pod <Pod 名の 1 つ>
# すぐに確認 → 新しい Pod が作られ常に 3 つに保たれる
kubectl get pods -l app=nginx
削除した Pod の代わりに新しい Pod（AGE が数秒）が自動生成され、合計 3 つが維持されます。これが Deployment の自己修復（self-healing）です。
Pod は再作成のたびに IP が変わります。Service は Pod 群への安定したアクセス先を提供し、負荷分散します。LoadBalancer タイプにすると AWS の ELB が自動作成され、インターネットから到達できます。
| タイプ | 用途 |
|---|---|
| ClusterIP（デフォルト） | クラスター内部のみからアクセス可能 |
| NodePort | 各ノードの特定ポートで公開（<NodeIP>:<Port>） |
| LoadBalancer | クラウドの LB（AWS では ELB）を自動作成して外部公開 |
cat > nginx-service.yaml << 'EOF'
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
EOF
selector: app: nginx によって、Deployment が作った 3 つの Pod へトラフィックが振り分けられます。
kubectl apply -f nginx-service.yaml
kubectl get service nginx-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) nginx-service LoadBalancer 10.100.xx.xx xxxx.ap-northeast-1.elb.amazonaws.com 80:31234/TCP
EXTERNAL-IP 列に ELB の DNS 名が表示されます（プロビジョニングに 2〜3 分かかり、最初は <pending> です）。
# EXTERNAL-IP の DNS 名にアクセス
curl http://<EXTERNAL-IP の DNS 名>/
Nginx の "Welcome to nginx!" HTML が返れば、インターネット → ELB → Service → Pod の経路が完成です。ブラウザでも同じ URL にアクセスして確認できます。
<pending> のまま / アクセスできないELB の作成には数分かかります。また、サブネットに ELB 作成用のタグ（kubernetes.io/role/elb）が必要な場合があります。デフォルト VPC のパブリックサブネットなら通常は自動で作成されます。数分待っても pending の場合は kubectl describe service nginx-service のイベントを確認してください。
# 3 → 5 にスケールアウト
kubectl scale deployment nginx-deployment --replicas=5
kubectl get pods -l app=nginx
# 5 → 2 にスケールイン
kubectl scale deployment nginx-deployment --replicas=2
Service の selector が自動で増減後の Pod を追従するため、設定変更なしで負荷分散先が更新されます。
# nginx 1.27 → 1.28 へ更新
kubectl set image deployment/nginx-deployment nginx=nginx:1.28
# 更新の進捗を確認（古い Pod を停止しつつ新 Pod を起動）
kubectl rollout status deployment/nginx-deployment
Deployment は新バージョンの Pod を少しずつ起動し、古い Pod を段階的に停止します。これによりダウンタイムなしでアプリを更新できます。
# 更新履歴の確認
kubectl rollout history deployment/nginx-deployment
# 1 つ前のバージョンにロールバック
kubectl rollout undo deployment/nginx-deployment
# イメージが戻ったことを確認
kubectl describe deployment nginx-deployment | grep Image
スケール・ローリング更新・ロールバックが kubectl コマンドだけで完結することを体験できました。これが Kubernetes の宣言的な運用の強みです。
EKS クラスター（$0.10/時）+ EC2 ノード + ELB が課金され続けます。削除は順序が重要です（Service → ノードグループ → クラスター）。
kubectl delete service nginx-service
kubectl delete deployment nginx-deployment
Service を削除せずにクラスターを消すと、ELB が「みなしご」リソースとして残ることがあります。クリーンアップ後、EC2 コンソール →「ロードバランサー」に Service 由来の ELB が残っていないか確認し、あれば手動削除してください。
EKS のクラスター一覧が空になり、EC2 のインスタンスとロードバランサーに handson 関連リソースが残っていなければ完了です。課金が停止します。