AWS EKS本番運用 Vol4｜Auto Mode×Hybrid Nodes×Karpenter v1

なぜ EKS本番運用 Vol4 か — 四部作概観 + Re:Invent 2024 新機能総覧

Vol1-3 で EKS の「作る・観る・流す」3軸を確立した。
Re:Invent 2024 では AWS がこれらの運用設計に直結する4機能を投入した。本記事はその4機能を本番運用に組み込む設計ガイドである。

本記事の対象読者は EKS の本番運用経験がある Cloud Architect / Platform Engineer / SRE だ。Kubernetes 基礎 (Pod / Service / Deployment) と AWS 基礎 (VPC / IAM / EC2) は習得済みであることを前提とする。EKS のバージョンは Kubernetes 1.31 以上 を前提としており、Auto Mode・Hybrid Nodes は 1.31 から利用可能だ。

Vol1-3 で獲得した設計力の再確認

Vol4 はこの基盤の上に 2024-2025 新機能レイヤ を重ねる。Vol1-3 の前提知識があると設計意図がより明確になるが、各章は独立して読める構成にしている。Vol3 までで構築した「クラスタが動いている」状態から、Vol4 で「より自動化・拡張されたクラスタを運用できる」状態にステップアップする。

2024-2025 Re:Invent 新機能 総覧

Re:Invent 2024 (2024年11-12月) で発表・GA となった EKS 関連機能のうち、本番運用設計に直結する4機能を本記事で扱う。

EKS Auto Mode (§2) は 2024-12 一般提供開始。従来 Vol1 で自前構築していた Karpenter・Pod Identity・Load Balancer Controller・EBS CSI Driver・Block Storage Controller を AWS が一括マネージドする。運営工数と詳細制御のトレードオフが設計の焦点になる。

EKS Hybrid Nodes (§3) は EKS コントロールプレーンをクラウドに置きつつ、オンプレミス・他クラウドの Linux ノードをデータプレーンとして参加させる。エッジ処理・レガシー DB 近接配置・段階移行ユースケースで採用が進む。

Karpenter v1.0 (§4) は Container本番運用 Vol3 §3 で NodePool / EC2NodeClass / Spot 最適化 / Consolidation の基本を習得済みであることを前提とする。本記事 §4 は v1.0 新機能のみ — Disruption Budgets / Drift detection / TerminationGracePeriod / WhenEmptyOrUnderutilized — に限定する。

VPC CNI Network Policy (§5) は aws-node DaemonSet 内の Network Policy Engine (eBPF) が Kubernetes NetworkPolicy CRD をネイティブ実行する。Calico・Cilium と異なり EKS Add-on として追加コストなしで導入できる。VPC CNI Network Policy の有効化後は Pod 間通信のデフォルト拒否設定が可能になり、最小権限の通信ポリシーを宣言的に管理できる。

これら4機能はそれぞれ独立して導入できる。既存クラスタに段階的に組み込む場合も、機能ごとに評価・導入計画を立てることができる。本記事では各機能の本番運用設計を章ごとに独立して解説している。

EKS本番運用 四部作 統合概観 (Mermaid01)

graph LR
 subgraph vol_series["EKS本番運用シリーズ 四部作"]
  Vol1["Vol1\n作る\nCluster基盤\nManaged NG / IRSA / ALB"] -->|Observabilityを重ねる| Vol2
  Vol2["Vol2\n観る\nObservability\nFluentBit / ADOT / CW"] -->|GitOpsを重ねる| Vol3
  Vol3["Vol3\n流す\nGitOps\nArgoCD / ApplicationSet"] -->|2024-2025新機能を重ねる| Vol4
  Vol4["Vol4 本記事\n組み込む\nAuto Mode / Hybrid Nodes\nKarpenter v1 / Network Policy"]
 end

 ContVol3["Container Vol3\nKarpenter基本\nNodePool / Spot最適化"] -.->|v1新機能のみ本記事§4| Vol4

 style Vol1 fill:#4a90d9,color:#fff,stroke:#2c6fad
 style Vol2 fill:#7b68ee,color:#fff,stroke:#5b48ce
 style Vol3 fill:#5cb85c,color:#fff,stroke:#3c983c
 style Vol4 fill:#e67e22,color:#fff,stroke:#c65d02
 style ContVol3 fill:#95a5a6,color:#fff,stroke:#7f8c8d

四部作はそれぞれ独立した記事でありながら、設計レイヤを積み重ねる構造を持つ。Vol1 の Cluster 基盤の上に Vol2 の観測可能性を重ね、Vol3 の GitOps で宣言的デリバリを確立し、Vol4 で 2024-2025 新機能を組み込む。図中の ContVol3 は Container本番運用 Vol3 を示し、Karpenter の基本設計は Vol3 §3 で担保されている。

本シリーズが対象とする読者は EKS を本番環境で日常的に運用する Cloud Architect / Platform Engineer / SRE だ。Kubernetes の基本 (Pod / Service / Deployment) は習得済みであり、AWS の基本サービス (VPC / IAM / EC2) を使いこなせることを前提としている。EKS のバージョンは Kubernetes 1.31 以上 を前提としており、Auto Mode・Hybrid Nodes は 1.31 から利用可能だ。

本記事で獲得できる設計力

本記事を読み終えた時点で以下の6つの設計力が身につく。

• (a) EKS Auto Mode で「Karpenter + Pod Identity + Load Balancer Controller + EBS CSI + Block Storage Controller」を AWS マネージドで一括導入する判断軸を獲得する
• (b) EKS Hybrid Nodes でオンプレミス・他クラウドのノードを EKS コントロールプレーンに接続するアーキテクチャを設計できる
• (c) Karpenter v1.0 Disruption Budgets / Drift detection / TerminationGracePeriod / WhenEmptyOrUnderutilized で「ノード入れ替えの制御性」を本番品質まで引き上げる
• (d) VPC CNI Network Policy で Pod 間トラフィック制御を Kubernetes NetworkPolicy ネイティブ実装できる
• (e) 詰まり7選 + アンチパターン演習5問で 2024-2025 新機能の運用判断力を体得する
• (f) Vol1-4 統合アーキテクチャ + 機能選定フローチャートで四部作の使い分けを設計できる

第28軸目 四部作完成 / 65→66記事化達成

本記事の公開により EKS本番運用シリーズ Vol1-4 の四部作が完成 し、第28軸目が揃う。AWS ハンズオン解説記事は 65 本から 66 本 に達する節目である。

各記事は単独でも活用できるが、4本を通読することで Re:Invent 2024 以降の EKS 本番運用設計の全体像が把握できる構成になっている。

第28軸目が揃うことで、EKS を取り巻く主要な設計領域 (Cluster基盤 / Observability / GitOps / 2024-2025新機能) を体系的に学習できるリソースが完成する。AWS ハンズオン解説記事 66 本の中で EKS 本番運用シリーズは特に実践的な本番設計知識を提供する軸として位置づけられている。

Container Vol3 との位置関係

Container本番運用 Vol3 §3 では Karpenter の NodePool / EC2NodeClass / Spot 最適化 / Consolidation の基本を詳述している。本記事 §4 は Karpenter v1.0 (2024-10 GA) で新規・強化された Disruption 機能のみ に限定し、基礎の重複説明は行わない。

Container Vol3 §3 の対象範囲: NodePool の定義・EC2NodeClass の設定・Spot インスタンス戦略・基本的な Consolidation (WhenEmpty / WhenUnderutilized)。これらは本記事 §4 では前提知識として扱う。

Container Vol3 §3 を読了済みの読者はそのまま §4 の内容を v1 アップグレード知識として活用できる。未読の場合は先に Container Vol3 §3 でノードプロビジョニングの基礎を習得してから戻ることを推奨する。

EKS Auto Mode 本番運用 — 全自動マネージド範囲 / 既存Vol1構成からの移行判断 / Auto Mode専用 NodePool

EKS Auto Mode は AWS がクラスタのデータプレーン管理コンポーネントを一括マネージドするモードで、2024年11月にプレビュー、2024年12月に一般提供が開始された。

Auto Mode を有効化すると、従来は運営チームが個別にインストール・バージョン管理・ヘルスチェックを担っていた以下のコンポーネントを AWS が完全に管理する。

• Karpenter: ノードのプロビジョニング・スケールイン・入れ替え制御
• Pod Identity エージェント: Pod アイデンティティ (IRSA の後継) の自動インストール
• AWS Load Balancer Controller: ALB / NLB の自動プロビジョニング
• Amazon EBS CSI Driver: EBS ボリュームの動的プロビジョニング
• Amazon EBS Block Storage Controller: ブロックストレージ管理

これらのコンポーネントは Auto Mode 有効化とともに自動でインストールされ、AWS がパッチ・バージョンアップ・ヘルスチェックを担当する。「Karpenter のバージョンを上げたら Helm chart の API が変わった」「EBS CSI Driver のアップデートでノードが再起動した」という問題から運営チームが解放される。Vol1 の構成 (Managed Node Group + 自前 Karpenter + 自前 Load Balancer Controller) から Auto Mode への移行は「運営工数 vs 詳細制御」のトレードオフを正確に評価した上で判断する必要がある。fig01 は Auto Mode のアーキテクチャ全体像を示している。

Auto Mode の全自動マネージド範囲

Auto Mode では上記コンポーネントの インストール・バージョン管理・ヘルスチェック・自動修復 をすべて AWS が担当する。運営チームが定義するのは NodePool の要件 (インスタンスファミリー・Spot/On-Demand 比率) と ワークロードの Pod spec のみになる。

既存 Vol1 構成からの移行判断軸

Auto Mode 移行が推奨されるケース: 新規クラスタの立ち上げ・運営工数削減が最優先・Karpenter バージョン追跡に疲弊している場合。

Auto Mode 移行を見送るべきケース: 自前 Karpenter の Disruption Budgets を細粒度にカスタマイズしている・カスタム Webhook が Auto Mode の制約に抵触する・IRSA から Pod Identity への移行コストが高い場合。

既存クラスタを段階的に移行する場合、まず新しいクラスタを Auto Mode で構築し、ワークロードを順次移行する Blue/Green 戦略が最も安全だ。既存クラスタを直接 Auto Mode に切り替えると Karpenter 設定が消失するリスクがある (§6 詰まり1 参照)。

判断軸の整理が終わったら、次に IAM/VPC 前提要件の充足確認に進む。これらの前提を満たさずに Auto Mode を有効化すると、ノードが起動しない・Pod が Pending になる等の問題が発生する。特にサブネットタグの設定漏れは本番環境で最も頻繁に見られる落とし穴だ。

IAM/VPC 前提要件

1. Pod Identity の有効化

Auto Mode は IRSA ではなく EKS Pod Identity を前提とする。クラスタに Pod Identity エージェントがインストールされていない場合、Auto Mode の有効化時に自動でインストールされる。

# eksctl で Auto Mode クラスタを作成する場合の cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-eks-cluster
  region: ap-northeast-1
  version: "1.31"
autoModeConfig:
  enabled: true
  nodePools:
 - system
 - general-purpose

2. VPC サブネットタグ条件

Auto Mode で Karpenter がノードをプロビジョニングするサブネットには以下のタグが必須だ。タグが不足していると Pod が Pending 状態になる最頻出の問題が発生する。

# プライベートサブネットへのタグ付与
aws ec2 create-tags \
  --resources subnet-xxxxxxxxxxxxxxxxx \
  --tags \
 Key=kubernetes.io/cluster/my-eks-cluster,Value=owned \
 Key=kubernetes.io/role/internal-elb,Value=1

可用性確保のためサブネットは最低3つのアベイラビリティゾーンに分散して用意する。パブリックサブネットに ALB をプロビジョニングする場合は kubernetes.io/role/elb: "1" タグも追加する。

3. クラスタ IAM Role の権限

Auto Mode の Karpenter がインスタンスを起動するために、クラスタの IAM ロールに EC2 操作権限が必要だ。eksctl で Auto Mode クラスタを作成する場合は自動付与される。手動で設定する場合は以下の権限を付与する。

{
  "Effect": "Allow",
  "Action": [
 "ec2:RunInstances",
 "ec2:TerminateInstances",
 "ec2:DescribeInstances",
 "ec2:DescribeInstanceTypes",
 "ec2:DescribeSubnets",
 "ec2:DescribeSecurityGroups",
 "ec2:CreateFleet",
 "ec2:CreateLaunchTemplate",
 "ec2:DeleteLaunchTemplate"
  ],
  "Resource": "*"
}

4. 既存クラスタへの Auto Mode 有効化 (AWS CLI)

実行前に現在の Karpenter 設定・EBS CSI 設定のバックアップを必ず取得すること。

aws eks update-cluster-config \
  --name my-eks-cluster \
  --region ap-northeast-1 \
  --compute-config \
 '{"enabled":true,"nodePools":["system","general-purpose"],"nodeRoleArn":"arn:aws:iam::123456789012:role/AmazonEKSAutoNodeRole"}'

nodeRoleArn には EC2 インスタンスが引き受ける IAM ロールを指定する。このロールには AmazonEKSWorkerNodeMinimalPolicy と AmazonEC2ContainerRegistryPullOnly のポリシーをアタッチしておく。

Auto Mode 専用 NodePool

Auto Mode では Karpenter の NodePool が system / general-purpose の2種類で事前定義されており、クラスタ作成時にデフォルトで有効化される。

system NodePool

system NodePool は kube-system 名前空間のコアコンポーネント (CoreDNS・kube-proxy・Auto Mode コンポーネント自身) を収容するために予約されたノードプールだ。

# system NodePool の概略 (Auto Mode が自動管理)
spec:
  template:
 spec:
taints:
  - key: CriticalAddonsOnly
 value: "true"
 effect: NoSchedule
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 1m

CriticalAddonsOnly: NoSchedule テイントにより、通常のワークロード Pod はスケジュールされない。CoreDNS 等のシステム Pod は tolerations でこのテイントを許容している。

general-purpose NodePool

general-purpose NodePool は汎用ワークロード向けのデフォルトノードプールだ。指定がない Pod はすべてこのプールにスケジュールされる。

# general-purpose NodePool の概略
spec:
  template:
 spec:
requirements:
  - key: karpenter.k8s.aws/instance-category
 operator: In
 values: ["c", "m", "r"]
  - key: karpenter.sh/capacity-type
 operator: In
 values: ["spot", "on-demand"]
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 30s
 budgets:
- nodes: "10%"

デフォルトの consolidateAfter: 30s は低負荷時に頻繁なノード入替を引き起こすことがある。本番環境では 5m 以上への延長と Disruption Budgets の設定を推奨する。Disruption Budgets の詳細は §4 で解説する。

カスタム NodePool の追加

system / general-purpose の2種類では要件を満たせない場合 (GPU ノード・特定インスタンスファミリーの固定・専用ノードの分離等) は、カスタム NodePool を追加定義できる。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-workloads
spec:
  template:
 metadata:
labels:
  node-type: gpu
 spec:
requirements:
  - key: karpenter.k8s.aws/instance-category
 operator: In
 values: ["g", "p"]
  - key: karpenter.sh/capacity-type
 operator: In
 values: ["on-demand"]
taints:
  - key: nvidia.com/gpu
 value: "true"
 effect: NoSchedule
  limits:
 cpu: 1000
 memory: 4000Gi
  disruption:
 consolidationPolicy: WhenEmpty
 consolidateAfter: 5m
 budgets:
- nodes: "0"
  schedule: "0 9 * * 1-5"
  duration: 8h

カスタム NodePool では karpenter.sh/v1 API を使用する。limits で CPU と Memory の上限を設定し、想定外のスケールアウトによるコスト超過を防ぐことを強く推奨する。

コスト構造

Auto Mode のコストは EC2 インスタンス料金 と Auto Mode 管理料金 の2本立てになる。

EC2 インスタンス料金

ノードとして起動される EC2 インスタンスの料金は通常の EC2 料金と同一だ。general-purpose NodePool はデフォルトで Spot/On-Demand 両方を対象としており、利用可能な場合は Spot を優先する。

Auto Mode 管理料金

例として m5.xlarge (4 vCPU / 16 GiB) を On-Demand で 720 時間稼働させた場合:
– vCPU: 4 × $0.00817 × 720 ≈ $23.5
– Memory: 16 × $0.001 × 720 ≈ $11.5
– 合計追加料金 ≈ $35 / 月 (インスタンス本体の料金に加算)

コスト最適化のポイント

• Spot インスタンス活用: general-purpose NodePool の Spot 比率を高めることで EC2 コストを 60-90% 削減できる
• Consolidation の積極活用: WhenEmptyOrUnderutilized ポリシーで不要ノードを積極的に削減する
• NodePool の limits 設定: CPU/Memory の上限を設定し、想定外のスケールアウトを防ぐ
• Savings Plans の活用: ベースライン負荷分はリザーブドまたは Savings Plans で固定コスト化する

管理料金は小規模クラスタでは Karpenter 自前管理のエンジニアリングコスト (作業時間) と比較して割安になることが多い。大規模クラスタ (100 ノード超) では試算した上で採用を判断することを推奨する。

コスト見積もりには AWS Pricing Calculator を活用し、EC2 コスト + 管理料金を既存構成の EC2 コスト + エンジニアリング工数コストと比較する形で評価する。Spot インスタンス混在の場合と On-Demand のみの場合でそれぞれ試算し、コスト感を把握してから移行判断を行うことを推奨する。

制約事項

特に cgroup v2 必須 は見落としやすい制約だ。Java アプリケーションで cgroup v2 未対応の JVM バージョン (OpenJDK 11 以前) を使用している場合、メモリ制限の検出に問題が発生することがある。Auto Mode 移行前に cgroup バージョンの互換性を必ず確認すること。

本番運用 キーポイント表

# サブネットタグ確認
aws ec2 describe-subnets \
  --filters "Name=tag-key,Values=kubernetes.io/cluster/my-eks-cluster" \
  --query "Subnets[*].{ID:SubnetId,Tags:Tags}" \
  --output table

EKS Hybrid Nodes 本番運用 — オンプレ/他クラウドノード接続 / Direct Connect併用 / 制約事項

EKS Hybrid Nodes とは何か

EKS Hybrid Nodes は 2024年11月に GA となった機能で、オンプレミスや他クラウドの Linux ノードを AWS が管理する EKS コントロールプレーンに接続し、単一の Kubernetes クラスタとして運用する機能だ。従来、ハイブリッド構成には EKS Anywhere や自前の Kubernetes 構築が必要だったが、EKS Hybrid Nodes を使えば AWS 側のコントロールプレーン（マネージド etcd / API Server）をそのまま利用しながら、自社データセンターや他クラウドのノードをワーカーとして組み込める。

コントロールプレーンは AWS リージョン内の EKS マネージドサービスとして稼働し続ける。ワーカーノードだけがオンプレミスや他クラウドに存在する、という非対称なアーキテクチャが Hybrid Nodes の本質だ。

代表的なユースケース:

接続要件

EKS Hybrid Nodes を利用するには、ノード側で以下の要件を満たす必要がある。

ノード OS / カーネル要件:

ネットワーク要件:

オンプレミスノードから EKS コントロールプレーン API Server エンドポイント (TCP 443) への到達性が必須となる。この接続には AWS Direct Connect または AWS Site-to-Site VPN の使用が推奨されており、インターネット経由での接続はセキュリティと信頼性の観点から本番環境では推奨されない。

# 接続確認コマンド (オンプレノードから実行)
curl -k https://<eks-endpoint>/healthz
# 期待レスポンス: ok

CNI 制限:

Hybrid Nodes では VPC CNI の代わりにオンプレ対応の CNI プラグインを使用する必要がある。AWS が公式にサポートする CNI は Cilium と Calico だ。VPC CNI はノードが VPC 内に存在することを前提とした設計のため、Hybrid Nodes では利用できない。

# Cilium インストール (Hybrid Nodes 向け)
helm install cilium cilium/cilium --version 1.15.x \
  --namespace kube-system \
  --set k8sServiceHost=<eks-api-endpoint> \
  --set k8sServicePort=443 \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true

ネットワーク設計

Direct Connect 構成

本番環境での Hybrid Nodes は Direct Connect による専用線接続が基本となる。帯域要件はノード数とワークロードのトラフィックに依存するが、EKS API Server とのコントロールプレーン通信だけでなく、Pod 間通信やサービスメッシュのトラフィックも Direct Connect を通過することを考慮した設計が必要だ。

MTU 設計

Hybrid Nodes 環境では MTU の設定が通信品質に大きく影響する。Direct Connect 経由のパスでは、VPN カプセル化によるオーバーヘッドを考慮した MTU 設定が必要だ。

# ノードの MTU 確認
ip link show eth0 | grep mtu

# MTU 設定 (Direct Connect 経由の場合: 1500 を基本とするが環境依存)
ip link set eth0 mtu 1500

# CNI の MTU 設定 (Cilium の場合)
# helm upgrade cilium cilium/cilium --set mtu=1500 ...

Direct Connect + VGW 構成の Routing 設計:

オンプレノード ── Direct Connect ── VGW ── VPC ── EKS Control Plane
 (10.0.0.0/16)  (172.16.0.0/16)

Pod CIDR レンジ (例: 192.168.0.0/16) はオンプレルーターに対して BGP アドバタイズが必要となる。EKS クラスタの Service CIDR (デフォルト: 10.100.0.0/16) も同様にルーティングの対象となるため、オンプレ側のルーティングテーブル設計を事前に確定しておく必要がある。

オンプレノード登録手順

EKS Hybrid Nodes へのノード登録は nodeadm ツールを使用する。nodeadm は EKS コントロールプレーンへの認証・登録・設定を一括して行うツールで、2024年11月の Hybrid Nodes GA と同時にリリースされた。

nodeadm のインストール

# Amazon Linux 2023 の場合
sudo dnf install -y nodeadm

# Ubuntu / Debian 系の場合
curl -sSL https://distro.eks.amazonaws.com/nodeadm/latest/linux/amd64/nodeadm -o /usr/local/bin/nodeadm
chmod +x /usr/local/bin/nodeadm

nodeadm 設定ファイルの作成

# /etc/nodeadm/config.yaml
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
 name: my-eks-cluster
 region: ap-northeast-1
  hybrid:
 ssm:
activationId: <activation-id>
activationCode: <activation-code>
  kubelet:
 config:
maxPods: 110
 flags:
- --node-labels=node.kubernetes.io/location=on-premises

ノード登録の実行

# nodeadm init でノードを EKS クラスタに参加させる
sudo nodeadm init --config /etc/nodeadm/config.yaml

# 登録後の確認 (EKS クラスタ側から)
kubectl get nodes -l node.kubernetes.io/location=on-premises

eksctl による Hybrid Nodes の事前設定

# cluster-config.yaml (eksctl 用)
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-eks-cluster
  region: ap-northeast-1
  version: "1.31"

hybridNodeGroups:
  - name: on-premises-nodes
 nodeLabels:
location: on-premises
 remoteNetworkConfig:
remoteNodeNetworks:
  - cidrs: ["10.0.0.0/16"]# オンプレノードの CIDR
remotePodNetworks:
  - cidrs: ["192.168.0.0/16"] # Pod CIDR (CNI に一致させる)

# eksctl でクラスタを作成 (または既存クラスタへの Hybrid Nodes 追加)
eksctl create cluster -f cluster-config.yaml

IAM Roles Anywhere によるノード認証

Hybrid Nodes のノード認証には IAM Roles Anywhere を使用する。IAM Roles Anywhere は PKI (X.509 証明書) ベースの認証により、AWS IAM ロールを AWS 外部のシステムに対して発行できる仕組みだ。

ノードがオンプレにあるため EC2 の Instance Profile が使えない状況でも、TrustAnchor に登録した CA が発行した証明書を持つノードであれば AWS IAM の一時クレデンシャルを取得できる。

設定手順

# 1. TrustAnchor の作成 (自社 CA の証明書を登録)
aws rolesanywhere create-trust-anchor \
  --name eks-hybrid-nodes-trust-anchor \
  --source sourceType=CERTIFICATE_BUNDLE,sourceData={x509CertificateData="$(cat ca-cert.pem | base64 -w0)"} \
  --enabled

# 2. Profile の作成 (ノードが引き受ける IAM Role を紐付け)
aws rolesanywhere create-profile \
  --name eks-hybrid-nodes-profile \
  --role-arns "arn:aws:iam::123456789012:role/EKSHybridNodeRole" \
  --enabled

# 3. IAM Role にアタッチするポリシー (最小権限)
# AmazonEKSWorkerNodePolicy + AmazonEC2ContainerRegistryReadOnly + AmazonEKS_CNI_Policy

ノード証明書の管理

各ノードには個別の証明書を発行し、証明書の有効期限管理と定期ローテーションを仕組み化する必要がある。証明書の有効期限切れはノードの認証失敗に直結するため、有効期限の 30 日前にはアラートを上げる運用が推奨される。

# IAM Role 信頼ポリシー (Roles Anywhere 向け)
{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "Service": "rolesanywhere.amazonaws.com"
},
"Action": [
  "sts:AssumeRole",
  "sts:TagSession",
  "sts:SetSourceIdentity"
],
"Condition": {
  "ArnEquals": {
 "aws:SourceArn": "arn:aws:rolesanywhere:ap-northeast-1:123456789012:trust-anchor/<anchor-id>"
  }
}
 }
  ]
}

制約事項

EKS Hybrid Nodes は 2024年11月 GA の機能であり、いくつかの重要な制約事項がある。本番導入前に必ずこれらを確認し、ユースケースに適合するかを評価すること。

本番運用キーポイント

# StatefulSet の nodeAffinity 設定例
spec:
  template:
 spec:
affinity:
  nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
  - key: node.kubernetes.io/location
 operator: NotIn
 values:
 - on-premises  # オンプレノードには配置しない

Karpenter v1 Disruption 本番運用 — Budgets / Drift / TerminationGracePeriod / WhenEmptyOrUnderutilized (★Container Vol3との差別化必須)

Container本番運用 Vol3 §3 で Karpenter NodePool / EC2NodeClass / Spot最適化 / Consolidation の基本は既出。本節は Karpenter v1.0 (2024-10 GA) で新規・強化された Disruption 制御機能に厳密に限定する。

Karpenter v1 Disruption の全体像

Karpenter v1.0 は 2024年10月に GA となり、Disruption 制御周りで v0 系から大きく刷新された。v0 系では「Consolidation を有効化したら予期せず多数のノードが同時に入れ替わった」「メンテナンス時間外にノードが削除された」といった運用上の課題があったが、v1.0 では Disruption Budgets / Drift detection の正式 GA / TerminationGracePeriod / WhenEmptyOrUnderutilized policy が導入され、ノード入れ替えの制御性が本番品質に達した。

v0 系と v1.0 の Disruption 関連差分:

Disruption Budgets

Disruption Budgets は NodePool の spec.disruption.budgets フィールドで設定する。Kubernetes の PodDisruptionBudget と同様の考え方だが、ノードレベルの Disruption (Consolidation / Drift / Empty) を対象としている。

基本構文

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production-nodepool
spec:
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 30s
 budgets:
 - nodes: "20%" # 同時に Disrupt できるノード数を全体の 20% に制限
 - nodes: "5"# 絶対数指定 (20% と 5 のどちらか小さい方が有効)
reasons:
- Underutilized # Underutilized による Disruption のみに制限を適用

schedule / duration による時間帯制御

メンテナンスウィンドウ外は Disruption を抑制したい場合に schedule と duration フィールドを使用する。schedule は cron 式、duration は抑制の継続時間を指定する。

spec:
  disruption:
 budgets:
 # 平日 8:00-22:00 JST は Disruption を最大 10% に制限
 - nodes: "10%"
schedule: "0 23 * * 0-4"  # UTC 23:00 = JST 8:00 (月-金)
duration: 14h
 # 土日は Disruption ゼロ (nodes: "0" でノード入替を完全停止)
 - nodes: "0"
schedule: "0 23 * * 5" # UTC 23:00 金曜 = JST 土曜 8:00
duration: 48h
 # それ以外 (深夜) は 40% まで許容して高速 Consolidation
 - nodes: "40%"

スケジュールの適用ルール: 複数の budgets エントリが同時に有効な場合、最も厳しい制限 (nodes の値が小さい方) が適用される。

reasons による選択的制御

reasons フィールドで Disruption の原因ごとに Budget を個別設定できる。

spec:
  disruption:
 budgets:
 # Drift による入替は慎重に (5% のみ)
 - nodes: "5%"
reasons:
- Drifted
 # Underutilized / Empty は積極的に (30%)
 - nodes: "30%"
reasons:
- Underutilized
- Empty

reasons に指定できる値は Underutilized / Empty / Drifted の 3 種類。指定なしの場合はすべての理由に Budget が適用される。

Drift detection

Drift detection は v1.0 で正式 GA となった機能で、NodePool や EC2NodeClass の定義が変更されたときに既存ノードを自動検知して入れ替える仕組みだ。

Drift が発生するトリガー

Drift の検知メカニズム

Karpenter は Node の spec と対応する NodePool/EC2NodeClass の定義を定期的に照合する。差分を検知するとノードに Drifted の Disruption 条件を付与し、Disruption Budget の制限内でノードの入れ替えをスケジュールする。

# Drift 状態の確認
kubectl get nodes -o custom-columns=\
  "NAME:.metadata.name,\
  DISRUPTION:.metadata.annotations['karpenter\.sh/disruption']"

# NodeClaim の状態確認
kubectl get nodeclaims -o wide
# REASON 列に "Drifted" が表示されていれば Drift が検知されている

Drift と Disruption Budget の連携

Drift によるノード入替は Disruption Budget の reasons: [Drifted] で制御できる。AMI のローリング更新時には Drift Budget を小さく設定し、段階的なノード更新を実現する。

spec:
  disruption:
 budgets:
 # AMI 更新時の Drift は 1 ノードずつ入れ替え
 - nodes: "1"
reasons:
- Drifted
 # Underutilized/Empty は通常通り
 - nodes: "20%"
reasons:
- Underutilized
- Empty

Drift の一時停止

大規模なメンテナンス中に Drift による意図しない入替を防ぐには、nodes: "0" を設定するか、karpenter.sh/do-not-disrupt: "true" アノテーションをノードに付与する。

# 特定ノードの Disruption を一時停止
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt=true

# 解除
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

TerminationGracePeriod

TerminationGracePeriod は v1.0 で新たに追加された機能で、Disruption 対象となったノード上の Pod が PDB (PodDisruptionBudget) を遵守しながら正常終了しない場合に、最大待機時間を保証する仕組みだ。

背景と目的

v0 系では PDB が常に満たされない状況 (例: Pending Pod がいて Budget を消費できない状態) や、Graceful Termination が長時間かかる Pod が存在する場合に、Karpenter がノード削除を永久に待ち続けるという問題があった。TerminationGracePeriod はこの問題を解決し、「最大でもこの時間内にノードを削除する」という上限を保証する。

設定

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production-nodepool
spec:
  template:
 spec:
terminationGracePeriod: 48h  # 最大 48 時間待機後に強制削除
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 budgets:
 - nodes: "10%"

terminationGracePeriod の値はワークロードの特性に合わせて設定する。

TerminationGracePeriod の挙動フロー

1. Disruption 対象ノードを選定
2. ノード上の Pod に対して Eviction を開始
3. PDB を遵守しながら Pod のドレインを試みる
4. terminationGracePeriod が経過したら:
→ 残っている Pod を強制削除
→ ノードを削除

重要: TerminationGracePeriod を超えた強制削除はデータ損失リスクを伴う。StatefulSet ワークロードには十分な余裕を持たせた値を設定し、実際に強制削除が発生しないよう PDB の設定と組み合わせて運用する。

Consolidation policy: WhenEmptyOrUnderutilized

v1.0 では Consolidation policy が刷新された。v0 系の WhenEmpty と WhenUnderutilized が別々のフィールドだったが、v1.0 では WhenEmptyOrUnderutilized として統合された。

v0 系と v1.0 の比較

# v0 系 (karpenter.sh/v1beta1)
spec:
  disruption:
 consolidateAfter: 30s
 consolidationPolicy: WhenUnderutilized
# WhenEmpty は consolidateAfter: Never で実質 WhenEmpty のみにする回避策が必要だった

# v1.0 (karpenter.sh/v1)
spec:
  disruption:
 consolidateAfter: 30s
 consolidationPolicy: WhenEmptyOrUnderutilized  # 統合された単一フィールド

WhenEmptyOrUnderutilized の挙動

consolidateAfter の設定指針

spec:
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 1m# 1 分間 Underutilized 状態が続いたら Consolidation 開始

consolidateAfter の値を小さくするほど Consolidation が積極的になりコストが下がるが、頻繁なノード入れ替えによる Pod Eviction が増える。本番環境では 30s〜5m の範囲で調整し、Disruption Budget と組み合わせて制御する。

Underutilized による Consolidation のみを停止したい場合は、Budget で reasons: [Underutilized] に nodes: "0" を設定することで WhenEmpty のみの動作を実現できる。

NodePool weight

v1.0 で追加された weight フィールドにより、複数 NodePool 間の優先度を制御できる。Karpenter は新しいノードをプロビジョニングする際、weight が高い NodePool を優先して選択する。

# 本番ワークロード向け NodePool (高優先)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production-optimized
spec:
  weight: 100  # 高優先度
  template:
 spec:
requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values: ["on-demand"]
- key: node.kubernetes.io/instance-type
  operator: In
  values: ["m6i.xlarge", "m6i.2xlarge", "m7i.xlarge"]
---
# フォールバック NodePool (低優先)
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: fallback-spot
spec:
  weight: 10# 低優先度 — production-optimized で対応できない場合に使用
  template:
 spec:
requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values: ["spot"]

weight の活用パターン:

本番運用キーポイント

# NG: Budgets 未設定
spec:
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized

# OK: Budgets で同時入替数を制限
spec:
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 budgets:
 - nodes: "10%"
reasons:
- Drifted
 - nodes: "20%"
reasons:
- Underutilized
- Empty

VPC CNI Network Policy 本番運用 — Policy Engine / eBPF / Calico/Cilium比較

VPC CNI Network Policy (2024 GA) は、EKS にネイティブ統合された Kubernetes NetworkPolicy 実装。従来は Calico や Cilium などのサードパーティ CNI プラグインを別途インストールして NetworkPolicy を実現していたが、VPC CNI Network Policy では vpc-cni アドオンが直接 eBPF を使用して Linux カーネルレベルで処理する。EKS Auto Mode との相性が最良で、追加コスト・追加インストール不要で Pod 間トラフィック制御を本番品質で実現できる。

VPC CNI Network Policy の設計思想

EKS 1.27+ で利用可能な本機能は以下の構成要素で成り立つ。

構成要素:

動作フロー:
1. 管理者が NetworkPolicy リソースを Kubernetes API Server に apply
2. aws-network-policy-agent が変更を検知
3. eBPF プログラムを生成してノードのカーネルにロード
4. 対象 Pod の veth interface レベルでパケットをフィルタリング
5. 許可・拒否の判定をカーネル空間で高速実行

有効化手順 — EKS アドオン経由

AWS CLI による有効化 (推奨):

aws eks update-addon \
  --cluster-name my-eks-cluster \
  --addon-name vpc-cni \
  --configuration-values '{"enableNetworkPolicy":"true"}' \
  --resolve-conflicts OVERWRITE

有効化後、kube-system Namespace に aws-network-policy-agent DaemonSet が自動デプロイされる。

# 有効化確認
kubectl get daemonset -n kube-system aws-network-policy-agent
# NAME  DESIREDCURRENTREADY
# aws-network-policy-agent333

kubectl get pods -n kube-system \
  -l app.kubernetes.io/name=aws-network-policy-agent

Network Policy ログも同時に有効化 (本番推奨):

aws eks update-addon \
  --cluster-name my-eks-cluster \
  --addon-name vpc-cni \
  --configuration-values '{
 "enableNetworkPolicy":"true",
 "nodeAgent":{
"enablePolicyEventLogs":"true",
"enableCloudWatchLogs":"true"
 }
  }' \
  --resolve-conflicts OVERWRITE

eksctl での有効化 (クラスタ作成時・IaC 管理):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-eks-cluster
  region: ap-northeast-1
  version: "1.31"
addons:
  - name: vpc-cni
 version: latest
 attachPolicyARNs:
- arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
 configurationValues: |
{
  "enableNetworkPolicy": "true",
  "nodeAgent": {
 "enablePolicyEventLogs": "true"
  }
}

既存クラスタへの後付け有効化 — 注意点:

有効化直後は NetworkPolicy リソースが存在しないためトラフィックは全許可のまま。NetworkPolicy を一つでも作成した瞬間から、対象 Pod への明示的な許可以外はデフォルトで拒否となる。既存クラスタに後付けする場合は以下の手順を踏む。

1. 全 Namespace のトラフィックマップを作成 (どの Pod がどの Pod と通信しているか)
2. テスト Namespace でデフォルト deny + 許可 NetworkPolicy を適用・疎通確認
3. 本番 Namespace へ Namespace 単位で段階適用 (問題発生時に切り戻しやすい粒度)
4. 全 Namespace への適用完了後に拒否ログで抜け漏れを確認

NetworkPolicy CRD 設計 — デフォルト deny + 必要トラフィック明示

Namespace 単位でのデフォルト deny (基本パターン):

# 全トラフィック拒否 (Namespace全体)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
 - Ingress
 - Egress

podSelector: {} は Namespace 内の全 Pod を対象にする。policyTypes に Ingress と Egress の両方を明示することで全方向を拒否する。

DNS 解決 (kube-dns) の Egress 許可 (必須セット):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
 - Egress
  egress:
 - to:
  - namespaceSelector:
matchLabels:
  kubernetes.io/metadata.name: kube-system
  - podSelector:
matchLabels:
  k8s-app: kube-dns
ports:
  - protocol: UDP
 port: 53
  - protocol: TCP
 port: 53

デフォルト deny 適用後に DNS 解決が失敗する事故が最頻発。default-deny-all と必ずセットで適用する。

アプリケーション間の明示的許可:

# フロントエンド → バックエンド のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
 matchLabels:
app: backend
  policyTypes:
 - Ingress
  ingress:
 - from:
  - podSelector:
matchLabels:
  app: frontend
ports:
  - protocol: TCP
 port: 8080

# バックエンド → データベース のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: production
spec:
  podSelector:
 matchLabels:
app: database
  policyTypes:
 - Ingress
  ingress:
 - from:
  - podSelector:
matchLabels:
  app: backend
ports:
  - protocol: TCP
 port: 5432

ALB Ingress Controller → Pod の Ingress 許可 (EKS Auto Mode / ALB Ingress 利用時):

# kube-system → 本番 Namespace への Ingress 許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-alb-ingress
  namespace: production
spec:
  podSelector:
 matchLabels:
app: frontend
  policyTypes:
 - Ingress
  ingress:
 - from:
  - namespaceSelector:
matchLabels:
  kubernetes.io/metadata.name: kube-system

既存 Calico / Cilium との比較

選定フロー:

EKS Auto Mode を使用 / 標準 NetworkPolicy で十分
  → VPC CNI Network Policy (追加コスト無し・AWS マネージド)

既存 Calico 環境 / GlobalNetworkPolicy 必要
  → Calico (既存運用継続・高機能 CRD 活用)

L7 フィルタリング / Hubble Observability / Service Mesh
  → Cilium (高機能・高運用工数を許容する場合)

監査・トラブルシュート

Network Policy ログの収集確認:

# aws-network-policy-agent ログ (直近5分)
kubectl logs -n kube-system \
  -l app.kubernetes.io/name=aws-network-policy-agent \
  --since=5m --prefix

# 拒否イベントの抽出
kubectl logs -n kube-system \
  -l app.kubernetes.io/name=aws-network-policy-agent \
  | grep -i "deny\|drop\|reject"

NetworkPolicy 適用状態の確認:

# Namespace 内の全 NetworkPolicy 一覧
kubectl get networkpolicy -n production

# 特定 NetworkPolicy の詳細確認
kubectl describe networkpolicy default-deny-all -n production

# Pod に適用されている NetworkPolicy 確認
kubectl get networkpolicy -n production -o yaml \
  | grep -A5 "podSelector"

通信テスト (疎通確認):

# デバッグ用 Pod を起動して通信テスト
kubectl run debug-pod \
  --image=busybox:latest \
  --restart=Never \
  --namespace=production \
  -- sleep 3600

# backend への疎通確認
kubectl exec -n production debug-pod \
  -- nc -zv backend-svc 8080

# DNS 解決確認
kubectl exec -n production debug-pod \
  -- nslookup backend-svc.production.svc.cluster.local

# デバッグ完了後に削除
kubectl delete pod debug-pod -n production

よくある拒否原因:

パフォーマンス特性

eBPF vs iptables のスケール特性:

iptables はルール数に比例してルックアップコストが増加 (O(n)) するが、eBPF ハッシュマップは O(1) でルックアップが完了する。Pod 密度が高い環境では VPC CNI Network Policy の eBPF 実装が CPU 消費面で優位になる。

メモリ使用量:
aws-network-policy-agent の基本メモリは約 50-80MB/ノード。NetworkPolicy ルール数が増加しても eBPF マップの効率的な管理により、通常運用では 200MB/ノード 未満に収まる。

本番推奨: 1 ノードあたり Pod 100 個を超える高密度配置では VPC CNI Network Policy の eBPF 実装が特に有効。

本番運用キーポイント表

kubectl logs -n kube-system \
  -l app.kubernetes.io/name=aws-network-policy-agent \
  | grep -i "deny"

詰まりポイント7選 + アンチパターン → 正解パターン変換

2024-2025 年に GA となった EKS 新機能 (Auto Mode / Hybrid Nodes / Karpenter v1 / VPC CNI Network Policy) は機能が多岐にわたるため、本番導入時に特定のパターンで詰まりやすい。以下に頻出の 7 パターンと、設計レベルで回避できるアンチパターン演習を示す。

詰まり 1: Auto Mode 移行で既存 Karpenter 設定が消失

詰まり 2: Hybrid Nodes 接続後に LoadBalancer Service が動かない

詰まり 3: Karpenter v1 Disruption Budgets 未設定で本番ノード一斉入替

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production
spec:
  disruption:
 budgets:
- nodes: "20%"  # 最大20%のノードのみ同時入替許可
- schedule: "0 8 * * 1-5"
  duration: 14h
  nodes: "0" # 平日業務時間帯は入替禁止
 consolidationPolicy: WhenEmptyOrUnderutilized

詰まり 4: Karpenter v1 Drift detection で意図せず全ノード入替

# AMI を固定バージョンで指定 (予測可能な入替タイミング)
amiSelectorTerms:
  - alias: "al2023@v20241201"

# または AMI ID で直接固定
amiSelectorTerms:
  - id: "ami-0123456789abcdef0"

詰まり 5: VPC CNI Network Policy 有効化で既存 Pod 通信が遮断

# 適用順序が重要: まずこれを apply してから default-deny-all を apply
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
 - Egress
  egress:
 - ports:
  - protocol: UDP
 port: 53
  - protocol: TCP
 port: 53

詰まり 6: Auto Mode 専用 NodePool で Custom Controller が動かない

詰まり 7: Hybrid Nodes の EBS 制約を知らずに StatefulSet を配置失敗

アンチパターン → 正解パターン変換

2024-2025 EKS 新機能の導入で繰り返されるアンチパターンを 5 つのパターンに集約し、正解設計を示す。

アンチパターン 1: Auto Mode 直接切替

アンチパターン: 稼働中の本番クラスタで Karpenter + Managed Node Group の構成から EKS Auto Mode へ一括切替

問題: Auto Mode 有効化により既存 Karpenter 設定が競合・無効化。ノードが予期しないタイミングで入れ替わり、ワークロードの一時的なダウンが発生しやすい。

正解パターン: 並走期間を設けた段階的移行

# Step 1: 非重要ワークロード専用の Auto Mode NodePool を追加
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: auto-mode-migration
spec:
  template:
 spec:
nodeClassRef:
  name: default
taints:
  - key: migration-phase
 value: "stage1"
 effect: NoSchedule
# Step 2: 対象 Pod に toleration を追加して段階移行
# Step 3: 監視・検証後に重要ワークロードを移行
# Step 4: 既存 Karpenter をクリーンアップしてから Auto Mode に統一

アンチパターン 2: Disruption Budgets 全 NodePool 共通設定

アンチパターン: 全ての NodePool に同一の budgets を設定

問題: 開発用 NodePool と本番用 NodePool が同じ budgets を持つと、本番で過剰な制約 (or 過剰な入替許可) が生じる。

正解パターン: ワークロード別 Budgets

# 本番 NodePool — 業務時間帯は入替禁止
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production
spec:
  disruption:
 budgets:
- nodes: "10%"
- schedule: "0 8 * * 1-5"
  duration: 14h
  nodes: "0"
---
# 開発 NodePool — 積極的にコスト最適化
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: development
spec:
  disruption:
 budgets:
- nodes: "50%"
 consolidationPolicy: WhenEmptyOrUnderutilized

アンチパターン 3: VPC CNI Network Policy 全許可で開始

アンチパターン: Network Policy を有効化したが全トラフィックを許可した状態のまま本番運用

問題: NetworkPolicy の目的は Pod 間通信制御。全許可のままでは有効化の意味がなく、後から deny ポリシーを追加する際に影響範囲が把握しづらい。

正解パターン: デフォルト deny + 必要トラフィック明示

# Namespace 全体のデフォルト deny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
 - Ingress
 - Egress
# → 許可ポリシーを個別に追加していく設計

アンチパターン 4: Hybrid Nodes 全機能想定

アンチパターン: EKS Hybrid Nodes に接続したオンプレノードで EKS の全機能が使えると想定して設計

問題: EBS / ALB / EFS Direct Mount は AWS ノード専用。Hybrid Nodes では LoadBalancer Service も含めて複数の主要機能が非対応。

正解パターン: 制約事項リスト確認 + 機能マトリクスでスコープ確定

Hybrid Nodes 非対応機能 (設計除外リスト):
  - EBS ボリューム (PersistentVolume)
  - LoadBalancer Service (ELB/ALB)
  - EFS Direct Mount (EFS CSI Driver)
  - Auto Mode 自動スケール

Hybrid Nodes 対応機能:
  - ローカルストレージ (hostPath / local StorageClass)
  - NodePort Service
  - ConfigMap / Secret
  - Kubernetes スケジューリング全般
  - DaemonSet / Deployment / StatefulSet (ローカル PV 使用時)

アンチパターン 5: Auto Mode + 自前 Karpenter 並存

アンチパターン: EKS Auto Mode を有効化しつつ、既存の自前 Karpenter も停止せずに並走させる

問題: Auto Mode 内蔵の Karpenter と自前の Karpenter Controller が同一クラスタ内で競合。NodePool 設定が互いに干渉し、ノードのプロビジョニング動作が予測不能になる。特定 Pod が意図しない NodePool にスケジュールされる事故が発生しやすい。

正解パターン: どちらか一方に統一 (混在禁止)

# Auto Mode への移行を選択した場合:
# 1. 既存 Karpenter NodePool を全て削除
kubectl delete nodepools --all

# 2. 既存 Karpenter Helm Release を削除
helm uninstall karpenter -n kube-system

# 3. Karpenter CRD を削除 (Auto Mode は独自 CRD を使用)
kubectl delete crd nodepools.karpenter.sh
kubectl delete crd ec2nodeclasses.karpenter.k8s.aws

# 4. EKS Auto Mode NodePool を設定して完全移行

EKS Vol1-4 統合アーキテクチャ + 機能選定フローチャート

EKS本番運用 四部作は「基盤 → 観測 → 自動化 → 2024-2025 新機能」の4軸で構成される。各Volが独立しているように見えて、実際の本番運用では4軸が連動して初めて完全体となる。本節では四部作を統合アーキテクチャとして俯瞰し、新機能の選定フローチャートで使い分けを整理する。

EKS本番運用 四部作 統合マップ

Vol1 (基盤): EKSクラスタの骨格を担う。Managed Node GroupによるワーカーNode管理、IRSAによるPodへのIAMロール付与、ALB Ingress ControllerによるHTTP/HTTPS負荷分散が中心。
→ EKS本番運用 Vol1 (Cluster設計 / IRSA / ALB Ingress) を読む

Vol2 (観測): 本番クラスタに不可欠な可視性を担う。FluentBitでPodログをCloudWatch Logsに転送、Container InsightsでNode/Podメトリクスを収集、ADOTでOpenTelemetry準拠のトレース・メトリクスパイプラインを構築する。
→ EKS本番運用 Vol2 (Observability / FluentBit / Container Insights / ADOT) を読む

Vol3 (GitOps): 継続的デリバリーの信頼性を担う。ArgoCD ApplicationでGitリポジトリをソース・オブ・トゥルースとし、ApplicationSetで複数クラスタ・複数環境を宣言的管理、AppProjectで権限境界を設計する。
→ EKS本番運用 Vol3 (GitOps × ArgoCD) を読む

Vol4 (2024-2025新機能): 2024年のre:Inventで発表・GAした4機能を本番運用設計に組み込む。Auto Modeでインフラ運用を最小化し、Hybrid Nodesでオンプレとクラウドを統合し、Karpenter v1でノード入替制御を強化し、VPC CNI Network PolicyでPod間通信を制御する。

Mermaid02: EKS新機能 機能選定フローチャート

flowchart TD
 START([EKSクラスタ構築・拡張の検討]) --> Q1{新規クラスタ構築?}
 Q1 -->|Yes| Q2{運用最小化を最優先?}
 Q1 -->|No 既存クラスタ| Q3{Karpenter基本は設定済?}

 Q2 -->|Yes| AUTO_MODE[EKS Auto Mode 採用
Karpenter + Pod Identity +
LB Controller + EBS CSI
をAWSが一括管理]
 Q2 -->|No 詳細制御優先| MANUAL[Vol1: Managed Node Group +
自前 Karpenter 構成
IRSA / ALB Ingress]

 Q3 -->|No| CONTAINER_VOL3[Container本番運用 Vol3 参照
NodePool / EC2NodeClass /
Spot最適化 / Consolidation基本]
 Q3 -->|Yes| Q4{Karpenter v1 Disruption
Budgets/Driftが未設定?}

 Q4 -->|Yes| KARPENTER_V1[§4: Karpenter v1 Disruption
Budgets / Drift detection /
TerminationGracePeriod /
WhenEmptyOrUnderutilized]
 Q4 -->|No| Q5{オンプレ/他クラウドの
ノード接続が必要?}

 AUTO_MODE --> Q5
 MANUAL --> Q5
 KARPENTER_V1 --> Q5

 Q5 -->|Yes| HYBRID[§3: EKS Hybrid Nodes
Direct Connect/VPN +
IAM Roles Anywhere +
オンプレ Linux Node登録]
 Q5 -->|No| Q6{Pod間通信の
制御が必要?}

 HYBRID --> Q6

 Q6 -->|Yes| NETPOL[§5: VPC CNI Network Policy
Network Policy Engine 有効化 +
eBPF実装 + NetworkPolicy CRD]
 Q6 -->|No| Q7{可視性が不足?}

 NETPOL --> Q7

 Q7 -->|Yes| OBS[Vol2 参照: Observability
FluentBit / Container Insights / ADOT]
 Q7 -->|No| Q8{デプロイ自動化が
未整備?}

 OBS --> Q8

 Q8 -->|Yes| GITOPS[Vol3 参照: GitOps × ArgoCD
App / ApplicationSet / AppProject]
 Q8 -->|No| DONE([本番運用 四部作 完全適用完了])

 GITOPS --> DONE

 style AUTO_MODE fill:#4CAF50,color:#fff
 style HYBRID fill:#2196F3,color:#fff
 style KARPENTER_V1 fill:#FF9800,color:#fff
 style NETPOL fill:#9C27B0,color:#fff
 style DONE fill:#F44336,color:#fff

統合移行プロジェクトの典型フェーズ

Phase 3-A/B/Cは並行可能だが、Phase 0→1→2は順序依存。Auto Mode移行は既存クラスタへの上書きではなく、新規クラスタ構築 + ワークロード移行を推奨する。Hybrid NodesはDirect Connect/VPN敷設という外部依存があるため、Phase 3-Cのタイムラインは物理インフラに依存する。

四部作間の技術的依存関係と相互補完

各Volは独立した設計軸を持ちながらも、技術的な依存・補完関係がある。理解を深めるために以下に整理する。

Vol1 → Vol4 の技術継承

Vol1で確立したIRSA (IAM Roles for Service Accounts) は、Vol4の各機能の認証基盤と接続している。Auto Modeが採用するPod IdentityはIRSAの後継だが、IRSAの概念 (PodへのIAMロール付与・最小権限設計) を理解していないとPod Identityの設計判断ができない。Vol1のALB Ingress ControllerはAuto Mode環境でも引き続き動作するが、Auto ModeではLoad Balancer Controllerとして一括管理される点を理解しておく必要がある。

Vol2 → Vol4 の観測可能性継承

Vol2で構築したFluentBit + Container Insights + ADOTのパイプラインは、Vol4の全機能と連動する。Karpenter v1のDisruption BudgetsトリガーをContainer Insightsでメトリクス化し、VPC CNI Network PolicyのeBPFパケットフィルタリングのヒット率をADOTで収集する構成が本番品質の観測可能性を実現する。Hybrid NodesのオンプレノードもFluentBitエージェントを導入してCloudWatch Logsに統合することで、ハイブリッド環境全体の一元的なログ管理が実現する。

Vol3 → Vol4 のGitOps継承

Vol3で確立したArgoCD App-of-Apps パターンは、Vol4の設定管理に直接活用できる。Karpenter v1のNodePool / EC2NodeClass YAMLをArgoCDで管理することで、Disruption BudgetsやDrift detectionの設定変更がGitPull Requestベースになる。VPC CNI Network PolicyのNetworkPolicy CRDもArgoCD ApplicationSetで複数Namespaceに一括展開できる。Auto Modeのカスタム NodePool設定もHelmチャート化してArgoCDで管理することで、環境間の設定差分をGitで可視化できる。

四部作の統合設計がもたらすアーキテクチャ成熟度

Vol1〜Vol4を統合した本番EKSクラスタは、以下の特性を同時に満たす「成熟したコンテナプラットフォーム」となる。自己修復性 (Auto ModeによるNode自動補充 + Karpenter v1 Drift detectionによる設定追従)、完全な可視性 (Vol2 Observabilityによるログ・メトリクス・トレースの3本柱)、宣言的管理 (Vol3 GitOpsによる設定変更の完全な監査証跡)、ゼロトラスト通信 (VPC CNI Network PolicyによるPod間通信の明示的許可制) の4特性が揃って初めて「本番品質のEKSプラットフォーム」と言える。

統合パターン別 設計指針

四部作技術選定の最終判断フレームワーク

実際のプロジェクトで「Vol4のどの機能を採用すべきか」を判断する際の最終フレームワークを示す。技術選定の迷いを減らし、意思決定を加速させるための指針だ。

Auto Mode採用の判断基準 (3条件の全てをYesにできる場合のみ採用)

Hybrid Nodes採用の判断基準 (データ主権・レイテンシ・コンプライアンスの3軸)

Hybrid Nodesは「コスト最適化」のための技術ではない。オンプレミスに留まる理由が「データ主権・レイテンシ要件・コンプライアンス規制」のいずれかに該当する場合のみ採用を検討する。AWS上のワークロードを単純にコスト削減するためにオンプレへ移動するユースケースには、Hybrid Nodesではなくアーキテクチャの見直しを推奨する。

Karpenter v1 Disruption設定の優先度マトリクス

VPC CNI Network Policy展開の安全順序

VPC CNI Network Policyの展開で最も多い失敗は「全許可のままEngine有効化 → 突然全体にdefault-denyを適用してサービス断」だ。以下の安全な展開順序を必ず守ること。

1. Engine有効化 + 全Namespaceで実際の通信フローを記録 (7〜14日間の観測期間)
2. 非本番の1 Namespaceにdefault-denyを適用し、エラーログで必要な許可ルールを把握
3. 本番のPodSelector/NamespaceSelector最小単位でNetworkPolicy CRDを適用
4. 全本番Namespaceへの展開 (フィーチャーフラグ的に段階展開)
5. 本番完全適用後に Egress / Ingress ルールの監査ログで月次レビュー

まとめ — EKS本番運用 四部作完成 + 全軸クロスリンク + 66記事化告知

§8-1: 四部作完成宣言

EKS本番運用 Vol4 をもって、第28軸目「EKS本番運用」四部作が完成した。

EKS本番運用 四部作 完全体

Vol1で基盤を作り、Vol2で見え、Vol3で流し、Vol4で2024-2025の進化を取り込む。この四部作を完走することで、Cloud Architect / Platform Engineer / SREとして本番EKSクラスタの全側面を設計・運用できる実力が身につく。

第28軸目「EKS本番運用」四部作完成により、本シリーズは 65→66記事 に到達した。引き続き複数の軸を深化させ、AWS本番運用の体系的な知識ベースを構築していく。

四部作を通じて共通しているのは「AWSマネージドサービスの上で詳細制御を諦めない」という姿勢だ。Vol1のIRSAはPod認証の細粒度制御を実現し、Vol2のADOTはOpenTelemetry準拠でベンダーロックインを防ぎ、Vol3のArgoCDはGitを唯一の真実源として運用の再現性を高め、Vol4のAuto ModeとVPC CNI Network Policyは「AWSが管理する範囲を最大化しつつ、通信制御は宣言的に手元に置く」バランスを体現する。

Vol1〜Vol3が既読の方には、本記事のAuto Mode / Hybrid Nodes / Karpenter v1 / VPC CNI Network Policyが「次のステップ」として機能する。Vol1〜Vol3が未読の方は、Vol1から順に読み進めることで四部作の設計意図を完全に理解できる。

四部作 設計進化の軌跡

四部作が生まれた背景には、EKSの技術進化がある。2020〜2021年にKubernetesのマルチノード管理が本番導入フェーズに入り、Vol1が基盤を提示した。2021〜2022年にAWS Container Insightsが正式GAし、OpenTelemetryの台頭と合わせてVol2が観測可能性の指針を示した。2022〜2023年にArgoCDがCNCF Graduated Projectとなり、Platform Engineering概念の普及とともにVol3がGitOps実装の標準化を担った。そして2024年re:Inventで、Auto Mode・Hybrid Nodes・Karpenter v1 GA・VPC CNI Network Policyの4技術が同時代に揃い、Vol4がその統合設計を担う。

四部作は「点」の技術解説ではなく「面」の運用設計だ。各Volは前のVolの知識を前提にしながら、同時に独立した設計判断軸を持つ。この構造が、Cloud Architectが組織のEKS成熟度に応じた「次の一手」を選べる指針となっている。

四部作 読者成長マップ

§8-2: 学習達成サマリ

§8-3: 4機能 重要設定一覧表

Auto Mode 本番運用 重要設定一覧表

Hybrid Nodes 本番運用 重要設定一覧表

Karpenter v1 Disruption 本番運用 重要設定一覧表

VPC CNI Network Policy 本番運用 重要設定一覧表

§8-4: 全軸クロスリンク

本記事と関連性の高い記事を以下に整理する。四部作の相互理解を深め、AWS本番運用の体系的な知識獲得に活用されたい。

関連性: 最高 — EKS本番運用シリーズ (四部作)

EKS本番運用 Vol1 (Cluster設計 / IRSA / ALB Ingress)
本記事の前提知識。Managed Node GroupとIRSAを理解した上でAuto ModeとPod Identityを比較する。
→ EKS本番運用 Vol1 を読む

EKS本番運用 Vol2 (Observability / FluentBit / Container Insights / ADOT)
Auto ModeクラスタへのObservabilityスタック導入はVol2が補完する。FluentBit DaemonSetはAuto Mode NodePoolでも稼働可能。
→ EKS本番運用 Vol2 を読む

EKS本番運用 Vol3 (GitOps × ArgoCD)
Karpenter v1 Disruption設定YAMLのGitOps管理はVol3が補完する。ArgoCD ApplicationSetでNodePool設定をマルチクラスタに展開する構成と組み合わせると効果大。
→ EKS本番運用 Vol3 を読む

関連性: 高 — Container本番運用シリーズ

Container本番運用 Vol3 (Pod Identity × Karpenter × Service Connect)
KarpenterのNodePool / EC2NodeClass / Spot最適化 / Consolidation の基本はこちら。本記事はv1.0新機能のみを扱うため、基本から学ぶ場合はこちらを先に読むこと。

Container本番運用 Vol2 (ArgoCD × Kustomize × Argo Rollouts)
GitOpsとProgressive Deliveryの組み合わせ。Karpenter v1のDrift detectionとArgo Rolloutsを組み合わせた構成はこちらと本記事の横断知識が必要。

関連性: 中 — ネットワーク・ストレージ軸

VPCネットワーク設計 / AWS PrivateLink 軸
Hybrid NodesのDirect Connect / VPN設計は、VPCルーティングとCIDR設計の知識が前提。ネットワーク軸の記事でサブネット分割・ルートテーブル設計を確認すること。

EBSストレージ / EBS CSI Driver詳細 軸
Auto ModeはEBS CSI Driverを内包するが、StorageClass / PersistentVolumeClaimの詳細設定はEBS軸の記事が補完する。Hybrid Nodes環境のStatefulSet設計でEFS活用を検討する場合も同様。

本記事で触れなかった関連領域 (別記事で深掘り予定)

• EKS Fargate Profile: Hybrid Nodesとは対極の「フルサーバーレスPod実行」モデル。StatefulSetとの相性・コスト構造は別軸で整理する。
• EKS Anywhere: オンプレ完結のKubernetesクラスタ管理。Hybrid Nodesとは設計レイヤが異なる (EKS Anywhereはコントロールプレーンもオンプレ)。
• Multi-cluster Federation: 複数EKSクラスタをArgoCD + Cluster APIで統合管理する構成は、Vol3 GitOps軸の次ステップとして別記事で扱う。
• FinOps for EKS: Auto ModeのNodePool別コスト可視化・Karpenter v1のSpot混在コスト最適化・Hybrid Nodesの専用線コスト配賦は、コスト最適化軸で統合的に整理する。

§8-5: 結びとシリーズインデックス

EKS本番運用 四部作は「基盤 → 観測 → 自動化 → 2024-2025新機能」の4軸を完走することで、本番EKSクラスタの全側面を設計できる実力を体系的に獲得できる構成になっている。

Vol4で学んだAuto Modeのインフラ運用最小化・Hybrid Nodesのマルチロケーション拡張・Karpenter v1のノード入替精密制御・VPC CNI Network PolicyのPod間通信ゼロトラスト化は、それぞれが独立した技術でありながら、組み合わせることで「自己修復・自動スケール・セキュアなEKS本番クラスタ」というアーキテクチャが実現する。

四部作のどの巻からでも読み始められるが、最も学習効率が高い順序はVol1 → Vol2 → Vol3 → Vol4だ。基盤を理解してから観測・自動化・新機能と積み上げることで、各機能の「なぜそう設計するのか」が明確になる。

四部作を完走した読者へ — 次の設計課題

四部作完走後の次の設計課題として、以下の領域が実践的な発展先となる。

1. マルチクラスタ戦略の設計: EKS Auto ModeクラスタとHybrid Nodesクラスタを並列運用するマルチクラスタアーキテクチャ。ArgoCD ApplicationSetのClusterシェルでCluster APIと連携する構成。
2. コスト最適化の精緻化: Auto Mode + Karpenter v1のSpot混在率最適化。Disruption Budgetsによる夜間コンソリデーションの時間帯設計。NodePool別コスト配賦とFinOps連携。
3. Platform Engineering基盤化: Vol3 GitOps + Vol4 Auto Modeを組み合わせたセルフサービスクラスタプロビジョニング。開発チームがYAMLを送るだけでEKS環境が払い出されるPlatform as a Productの設計。
4. オブザービリティの深化: Auto Modeノードへのカスタムメトリクス収集・Karpenter v1のDisruption Budgetsトリガーイベントの可視化・VPC CNI Network Policyの拒否ルールヒット率ダッシュボード化。

次の軸では、EKS本番運用シリーズで培ったコンテナプラットフォームの知識を、他のAWSサービスとの統合やマルチクラウドへと展開していく。今後の記事にもぜひご注目いただきたい。

Vol4の4機能は「それぞれが単独でも価値を持ちながら、組み合わせることで相乗効果を発揮する」設計になっている。Auto Mode + VPC CNI Network Policyの組み合わせは「自動スケールしながらゼロトラスト通信を維持する」クラスタを実現し、Karpenter v1 Disruption Budgets + Hybrid Nodesの組み合わせは「オンプレへの段階的ワークロード移行の安全性を担保する」設計になる。四部作の技術を組み合わせて、あなたの本番EKSクラスタを次のレベルへと引き上げていただきたい。