EKS を OSS の組み合わせとして読む

EKS 上のアプリから AWS のデータを読みたい。ディスクを使いたいし、ロードバランサーで外へ公開したい。こうした要求を、Kubernetes の設定から AWS の機能へつなぐ部品がいくつもあります。

この章では、認証、ネットワーク、ストレージなど、やりたいことごとに担当を整理します。 EKS を 1 つのサービスとして使いながらも、問題が起きたときにどの部品を確認するかが分かるよう、接続関係を図で見ます。

GOAL この章のゴール

EKS と AWS の各機能をつなぐ部品を見分けられる
利用者の認証と、Pod が AWS にアクセスする認証を区別できる
ノードの運用を任せる動作モードで、管理範囲がどう変わるか分かる

EKS を構成する部品と拡張点

Part 4 で見た通り、Kubernetes は本体の外に部品を差し込む前提で作られています。認証は webhook、ネットワークは CNI、ストレージは CSI、LB は Service / Ingress の controller、ノードの増減も controller です。 EKS は、この差し込み口のそれぞれに AWS の機能を繋ぐ部品を差し込んだものです。

図 1中央が Kubernetes、外周が AWS の機能、間に居るのが OSS。どれも github.com で読める。

主な部品を、AWS の機能と対応づけて並べます。

AWS の機能	OSS	拡張点
IAM	`kubernetes-sigs/aws-iam-authenticator`、EKS Pod Identity Agent	認証 webhook / ServiceAccount
VPC / ENI	`aws/amazon-vpc-cni-k8s` (`aws-node` DaemonSet)	CNI
EBS / EFS / FSx	`kubernetes-sigs/aws-ebs-csi-driver` ほか	CSI
ALB / NLB	`kubernetes-sigs/aws-load-balancer-controller`	Ingress / Service / Gateway controller
Route 53	`kubernetes-sigs/external-dns`	Service / Ingress を watch する controller
EC2 (ノードの増減)	`kubernetes-sigs/karpenter` (`aws/karpenter-provider-aws`)、`kubernetes/autoscaler`	Pending の Pod を watch する controller
EC2 (AMI)	`awslabs/amazon-eks-ami`、Bottlerocket	ノードの OS
CloudFormation	`eksctl-io/eksctl`、`kubernetes-sigs/cluster-api-provider-aws`	クラスタ自体の作成

ネットワーク: VPC CNI

EKS のノードの ENI を見ると、セカンダリ IP がいくつも付いています。この IP を Pod に配っているのが Amazon VPC CNI で、kube-system の aws-node DaemonSet として動いています。

やっていることは Part 2 で見た CNI の仕事 (Pod に IP を配り、veth で Pod の netns をつなぎ、経路を用意する) そのものですが、IP の出どころが AWS 固有です。リポジトリの説明によると、aws-node の中の ipamd がノードの ENI にセカンダリ IP をあらかじめ複数確保しておき、Pod が作られるたびに 1 つを割り当て、CNI のバイナリが veth で Pod の netns に繋ぎます。 Pod の IP が VPC のサブネットから直接配られるので、VPC 内のどこからでも Pod に届き、Security Group や Network ACL が Pod にも効きます。ノード間の経路は VPC が持っているので、VXLAN も BGP も要りません。

この方式の代償は IP アドレスの消費です。インスタンスタイプごとに ENI の数とセカンダリ IP の数に上限があり、それが「このノードに置ける Pod の最大数」になります。 prefix delegation (ENI に /28 のプレフィックスを付ける) を有効にすると、この上限を緩められます。

認証: IAM との 2 つの接点

EKS のクラスタに最初に kubectl を通すとき、aws eks update-kubeconfig を実行します。 Pod から S3 を読みたいときは、ServiceAccount に IAM ロールを紐付けます。この 2 つが、EKS と IAM の接点です。

図 2上: 人の IAM 認証情報を Kubernetes のユーザーに変換する。下: Pod の ServiceAccount を IAM ロールに変換する。

人から Kubernetes API への経路では、update-kubeconfig が書く kubeconfig に aws eks get-token を exec する設定が入っています。 aws-iam-authenticator のリポジトリによると、この exec は STS の GetCallerIdentity に対する署名済みリクエストをトークンに詰め、apiserver はそれを認証 webhook で authenticator のサーバーに渡し、サーバーは STS で署名を検証して IAM principal を Kubernetes のユーザーとグループに対応づけます。対応表は現在 access entries (EKS の API で管理) が推奨で、aws-auth ConfigMap は旧方式です。サーバー側は EKS のコントロールプレーンで動いていて、利用者からは見えません。

Pod から AWS API への経路では、ノードの IAM ロール (インスタンスプロファイル) より狭い権限を Pod ごとに渡すために、ServiceAccount と IAM ロールを紐付けます。

2026 年現在

2026 年現在、AWS が勧めるのは EKS Pod Identity です。各ノードの eks-pod-identity-agent (DaemonSet、hostNetwork でリンクローカルアドレス 169.254.170.23 を待ち受け) が、Pod の ServiceAccount に対応する IAM ロールの一時クレデンシャルを EKS Auth API (AssumeRoleForPodIdentity) から取り、Pod の中の SDK に渡します。Pod には環境変数と projected token が自動で差し込まれます。IAM ロールの信頼ポリシーには pods.eks.amazonaws.com を書くだけで、クラスタごとの OIDC provider は要りません。EKS Auto Mode では agent の導入も不要です。

旧方式の IRSA (IAM Roles for Service Accounts) は、ServiceAccount の projected token (OIDC の JWT) を STS の AssumeRoleWithWebIdentity で IAM ロールに交換します。クラスタごとに OIDC provider を IAM に登録する必要があります。Pod Identity は Fargate の Pod、Windows ノード、EKS Anywhere では使えないので、そこでは今も IRSA を使います。

入口と名前: Load Balancer Controller と external-dns

前の章で見た通り、type: LoadBalancer を見て NLB を作るのは AWS Load Balancer Controller です。同じ controller が Ingress から ALB を作り、Gateway API のリソースも扱います。 ALB のリスナールール、ターゲットグループ、Security Group を Kubernetes のオブジェクトから reconcile し、TargetGroupBinding という CRD で既存のターゲットグループに Pod を登録することもできます。

external-dns は Service と Ingress を watch して、annotation に書かれたホスト名を Route 53 のレコードにします。 Cloud DNS や Azure DNS、Cloudflare にも対応した汎用の controller です。

ノードの増減: Karpenter

Pending の Pod を見てノードを増やす仕組みには 2 世代あります。

図 3Cluster Autoscaler は node group の台数を動かす。Karpenter は Pod の要求から型を選んで EC2 を直接起動する。

Cluster Autoscaler (kubernetes/autoscaler) は、node group (EKS では Auto Scaling Group) 単位で台数を増減させます。 GPU が要る Pod のために GPU の node group を事前に作っておく、といった設計が必要です。

は kubernetes-sigs のプロジェクトで、AWS 向けの実装が aws/karpenter-provider-aws にあります。ドキュメントによると、Karpenter は scheduler が Unschedulable と印を付けた Pod を見て、その制約を評価し、node group のような仕組みを介さずにインスタンスを直接起動します。利用者は NodePool (インスタンスファミリー、Spot / On-Demand、アーキテクチャ、ゾーンなどの制約) と、クラウド固有の NodeClass (AWS では EC2NodeClass に AMI、サブネット、Security Group) を書きます。使用率の低いノードの Pod は他のノードに寄せて空いたノードを削除し (consolidation)、設定した寿命を過ぎたノードは expired として入れ替えます。 EKS Auto Mode のスケーリングはこの Karpenter です。

EKS Auto Mode: 境界線の移動

は 2024 年 12 月に始まりました。前の章の ManagedBoundary で見た「あなたが入れる」の層が、まとめて AWS 側に移ります。

図 4標準モードで add-on だったものが、Auto Mode ではコア機能になる。ノードは SSH できないアプライアンス。

Auto Mode のノードには SSH でも SSM でも入れず、SELinux は enforcing、ルートファイルシステムは読み取り専用で、最長 21 日 (短くもできる) で新しい AMI のノードに入れ替わります。利用者が中身を触らない前提にしたことで、AWS は OS の設定を固定した AMI だけを配り、短い周期でノードを作り直してパッチを行き渡らせられます。入れ替えは Pod Disruption Budget を尊重して行われます。既定の NodePool と NodeClass は編集せず、必要なら別の NodePool / NodeClass を追加し、ノードに常駐させたいもの (監視など) は DaemonSet で入れます。内蔵の controller 群は AWS 所有の基盤で動くので、VPC CNI や EBS CSI の Pod は利用者のアカウントには見えません。この方向は次の章の Fargate と同じです。

コミュニティとの付き合い方

EKS の部品は OSS なので、開発の流れが見えます。 Kubernetes 本体では SIG Cloud Provider の下に provider-aws のサブプロジェクトがあり、cloud-provider-aws や aws-load-balancer-controller はそこで議論されます。 AWS 側の計画は aws/containers-roadmap リポジトリの issue で公開されていて、EKS と ECS の今後の機能が「We’re working on it」「Shipped」のラベル付きで見られます。欲しい機能があれば issue に賛成票を入れるのが、AWS に届く一番確実な方法です。

ふりかえり

QEKS で Pod に VPC のサブネットの IP が直接付くのはなぜ?

aws-node DaemonSet (amazon-vpc-cni-k8s) の ipamd が ENI にセカンダリ IP を確保し、Pod 作成時に 1 つを割り当てて veth を差します。ルートテーブルは使いません (VPC が経路を持っています)。

QEKS Pod Identity が IRSA と違う点は?

IRSA は ServiceAccount の OIDC トークンを STS で交換するためクラスタごとに OIDC provider が要ります。Pod Identity は eks-pod-identity-agent が EKS Auth から取ったクレデンシャルを配り、信頼ポリシーは pods.eks.amazonaws.com 1 つで済みます。Fargate では逆に Pod Identity が使えません。

QEKS Auto Mode で「利用者の責任」として残るものは?

Auto Mode ではノード、CSI、LB 連携、スケーリングが AWS 側に移ります。アプリ、VPC、クラスタ設定、Kubernetes のバージョン選択は引き続き利用者の責任です。

参考

次の章へFargate はタスクをどこで動かしているのか