EKS入門と落とし穴 — 最初に知るべき勘所

EKSは「Kubernetesが動く」だけでは本番に乗りません。ノード選定、Pod単位のIAM、IP設計、アップグレード運用という4つの勘所を、最初から押さえておくと後戻りが激減します。本記事は実務で最初に踏む落とし穴を先回りで整理します。

01EKSは何を預かり、何を任せてくるのか

Amazon EKSは、Kubernetesの「コントロールプレーン」をAWSがマネージドで運用してくれるサービスです。APIサーバー、etcd、スケジューラといった管理コンポーネントはAWSが冗長化・パッチ適用まで面倒を見ます。一方で、実際にPodが動く「データプレーン」、つまりワーカーノード(EC2やFargate)は、原則として利用者側の責任範囲に残ります。ここの境界を最初に正しく認識しておくことが、EKS運用の出発点です。

よくある誤解が「EKSにすればKubernetesの運用から解放される」というものです。実際には、ノードのOS更新、アドオン(VPC CNI、CoreDNS、kube-proxy)のバージョン管理、ワークロードのアップグレード追従など、利用者が手を動かす領域は相応に残ります。マネージドなのはあくまで管理層であり、下回りとアプリの整合は自分たちで守る、という前提で設計してください。

02ノードをどう供給するか — 3つの選択肢

データプレーンの供給方式は大きく3つです。それぞれ得意領域が異なり、1つのクラスタで併用することも珍しくありません。

• マネージドノードグループ：EC2インスタンスをEKSが管理するAuto Scalingグループとして払い出します。ノードのプロビジョニングとライフサイクルを自動化しつつ、EC2の柔軟性（インスタンスタイプ、GPU、ローカルストレージ)を保てます。負荷が比較的一定・静的なワークロードに向きます。
• Fargate：Podごとにサーバーレスでコンピュートを払い出します。ノードのOS管理から解放される反面、DaemonSetが使えない、Podあたりのリソース上限があるなどの制約があります。add-onや常駐エージェントの前提が崩れやすい点に注意です。
• Karpenter：スケジュール待ちのPodを見て、必要なインスタンスを動的に選定・起動するオープンソースのオートスケーラです。スパイクの大きいワークロードや多様なインスタンス要件に強く、集約効率（ビンパッキング)を高めやすいのが利点です。

実務では「システム系Pod（CoreDNSやコントローラ)は小さなマネージドノードグループに、アプリのワークロードはKarpenterに」という併用が現実的な落とし所になることが多いです。AWSのベストプラクティスガイドも、静的なワークロードにはマネージドノードグループ、スパイキーで多様な要件にはKarpenterを推奨しています。ノード単位のインスタンスタイプ選定はEC2インスタンスタイプ選定も併せて確認してください。

03ノード選定の判断軸

迷ったときのために、判断軸を決定表に落とします。あくまで出発点であり、実際には併用が前提です。

Fargateは「DaemonSetが動かない」点が実務で効いてきます。ログ収集エージェントやセキュリティエージェントをDaemonSetで配る前提の運用設計だと、Fargateだけでは組めません。この違いはFargate と EC2 起動タイプでも掘り下げています。ECSとの棲み分けから検討する場合はECS と EKS の選定を参照してください。

04Pod単位でIAM権限を渡す — IRSAとEKS Pod Identity

EKSでアプリがAWS APIを叩く際、ノードのIAMロールを共用すると「同じノードのPodが互いの権限を使えてしまう」最小権限違反に陥ります。これを避けるのが、Pod（正確にはService Account)単位でIAMロールを紐づける仕組みです。方式は2つあります。

• IRSA（IAM Roles for Service Accounts)：クラスタごとのOIDCプロバイダを使い、IAMロールの信頼ポリシーでService Accountを指定します。歴史が長く実績が豊富ですが、クラスタごとにOIDCプロバイダの作成と、ロールごとの信頼ポリシー設定が必要です。
• EKS Pod Identity：OIDCを使わず、EKS側で「ロールとService Accountの対応付け（association)」を管理する新しい方式です。ノード上のエージェント(DaemonSet)が認証情報を配布します。信頼ポリシーはpods.eks.amazonaws.comを principal に置くだけで、複数クラスタで同一ロールを再利用できます。

AWS公式は、Pod IdentityをIRSAより「シンプルな方式」と位置づけています。OIDCプロバイダの管理が不要で、クラスタ横断でロールを使い回せるため、新規構築なら第一候補として検討する価値があります。ただし現時点でFargate上のPodでは使えないなどの制約があるため、ノード構成と合わせて確認してください（対応範囲はバージョン依存なので公式で最新を確認)。IAM設計全体の考え方はIAM最小権限の現実も参考になります。

05外部公開の要 — AWS Load Balancer Controller

EKS上のワークロードをALB/NLBで公開する定番が、AWS Load Balancer Controllerです。KubernetesのIngressリソースを作ると、コントローラがALBをプロビジョニングし、ターゲットグループとリスナーを構成し、PodのIPまたはノードをターゲットとして登録します。Service（type: LoadBalancer)からNLBを作ることもできます。

導入時によく詰まるのがサブネットのタグ付けです。コントローラはVPCサブネットのタグを見てALB配置先を自動検出します。パブリック用・プライベート用の適切なタグ（kubernetes.io/role/elbなど)が付いていないと、ALBが作られない、あるいは意図しないサブネットに出てしまいます。もう一点、コントローラ自身がAWS APIを叩くため、前述のIRSAまたはPod Identityで専用のIAM権限を渡す必要があります。ここを飛ばすと権限エラーで動きません。

06最大の落とし穴 — VPC CNIとIPアドレス枯渇

EKSの標準ネットワークであるAmazon VPC CNIは、各PodにVPCのCIDRからIPアドレスを1つ割り当てます。PodがVPCの一級市民になり通信がシンプルになる反面、Podを大量に動かすとVPC内のIPv4アドレスをあっという間に食い潰します。これはEKS導入で最も多く踏まれる設計上の落とし穴です。

特に、既存のオンプレ連携で小さめのサブネットしか切れない、あるいは他システムとIP空間を共有している環境では、Podの増加でInsufficientFreeAddressesInSubnetのようなエラーに直面します。対策は主に次の3つです。

• プレフィックス委任（Prefix Delegation)：ENIに個別IPを割り当てる代わりに、/28（16IP)のプレフィックスをまとめて割り当てます。Nitro世代インスタンスでノードあたりのPod密度を大きく引き上げられます。
• セカンダリCIDRの追加：VPCに非ルーティング可能なセカンダリCIDRを足し、カスタムネットワーキングでPod用IPをそこから払い出します。AWSが最も一般的な手法として挙げているアプローチです。
• IPv6クラスタ：クラスタをIPv6で構成し、IPv4枯渇そのものを回避します。ただし周辺システムのIPv6対応が前提になります。

いずれも後付けで切り替えるのは手戻りが大きいため、VPC・サブネットのサイジングは「成長を見込んで」最初に大きめに取るのが鉄則です。数値上限（プレフィックスのIP数やインスタンスタイプ別の割当上限)はバージョン・インスタンス依存なので、公式のIP最適化ガイドで最新を確認してください。NAT経由の外向き通信コストが絡む場合はNAT Gateway コスト設計も併読を。

07止まらない宿題 — アップグレード運用

Kubernetesは年に複数回マイナーバージョンが上がり、EKSもこれに追従します。EKSでは各マイナーバージョンが標準サポートで一定期間、その後は追加費用のかかる延長サポートに移行します（サポート期間の月数はバージョン依存なので公式で最新を確認)。放置すると延長サポートのコストが発生し、さらに期間を過ぎると自動アップグレードの対象になります。「上げない」という選択肢は事実上ありません。

ここで重要な落とし穴が、コントロールプレーンを上げてもノードは自動では上がらない点です。マネージドノードグループのEC2インスタンスは、コントロールプレーン更新に連動して自動更新されません。利用者がノードグループの更新を明示的に実行する必要があります。コントロールプレーンとkubeletのバージョン差(スキュー)には許容範囲があるため、順序としては「コントロールプレーン → ノード → アドオン → ワークロード」の流れで、差が開きすぎないうちに進めます。

もう一つ、非推奨APIの廃止が地雷です。マイナーバージョンアップでKubernetes APIが削除されると、それを使うマニフェストやコントローラが動かなくなります。アップグレード前に廃止APIの利用を洗い出し、マニフェストを追従させておくことが必須です。なお、インプレースアップグレードは完了後の一定期間内であれば前のマイナーバージョンへロールバックできる仕組みもあります（条件・期間は公式で最新を確認)。CI/CDでマニフェストとアドオンのバージョンを管理する運用はIaC CI/CDパイプラインが参考になります。

08入門者が最初に踏みやすい落とし穴まとめ

ここまでの内容を、着手前チェックリストとして整理します。

• 責任分界の誤認：ノード・アドオン・アプリの運用は残る。フルマネージドと誤解しない。
• ノード方式の思い込み：Fargateでは DaemonSet が動かない。ログ/セキュリティエージェント前提の設計と衝突する。
• IAMのPod単位化を後回し：ノードロール共用は最小権限違反。IRSAかPod Identityを最初から組み込む。
• サブネットタグ漏れ：Load Balancer Controllerがサブネットを検出できずALBが出ない。
• IPサイジング不足：VPC CNIはPodごとにVPCのIPを消費する。小さいサブネットは即枯渇する。
• アップグレード放置：ノードは自動で上がらない。廃止APIとアドオン互換を事前に潰す。

Kubernetesの運用に不慣れな組織でも、この6点を最初に押さえるだけで、本番移行後のトラブルは大きく減ります。マルチアカウント環境でのクラスタ配置やガードレールについてはマルチアカウント統制も併せてご検討ください。

—まとめ

EKSは強力なマネージドKubernetesですが、「動かす」と「本番で運用する」の間には、ノード選定・Pod単位IAM・IP設計・アップグレードという4つの勘所があります。いずれも後付けが効きにくく、最初の設計で決まってしまう論点です。逆に言えば、着手前にこの4点を押さえておけば、EKSの運用は十分に見通しの立つものになります。EMWでは、こうした構成レビューから本番移行の伴走まで実務目線で支援しています。ご相談はお問い合わせから、導入の実例は導入事例をご覧ください。

—参考(一次情報)

• Learn how EKS Pod Identity grants pods access to AWS services — Amazon EKS User Guide
• IAM roles for service accounts — Amazon EKS User Guide
• Optimizing IP Address Utilization — Amazon EKS Best Practices
• Assign more IP addresses to Amazon EKS nodes with prefixes — Amazon EKS User Guide
• Route internet traffic with AWS Load Balancer Controller — Amazon EKS User Guide
• Understand the Kubernetes version lifecycle on EKS — Amazon EKS User Guide
• Karpenter — Amazon EKS Best Practices