こんにちは。
本記事はJapan AWS Top Engineers Advent Calendar 2024の六日目の記事です！
今年のre:Inventもわくわくする発表ばかりですね。個人的には特にEKS Auto Modeが気になっているのですが、EKS on Fargateとは実際何が違うのかうまく説明できなさそうなので調べてみました。
概要
EKS Auto Modeとは
2024/11に発表されたEKSの機能。ノードのコンピューティングやストレージ、ネットワークをAWSが責任をもって管理してくれるのでより簡単にk8sクラスタを運用することができます。
EKS on Fargateとは
Fargateがノードを管理してくれるので簡単にk8sクラスタを運用できます。詳しくは当時のブログをどうぞ。
比較サマリ
早速ですがサマリの表です!
| 項目 | EKS Auto Mode | EKS Fargate |
|---|---|---|
| コントロールプレーンのバージョンアップ | マニュアル | マニュアル |
| ノードのバージョンアップ | 不要（コントロールプレーンの後に自動実行） | 不要（Podの再起動は必要） |
| ノードへのSSH | × | × |
| イメージのキャッシュ | 〇（ノードにあれば） | × |
| GPUノードの利用 | 〇 | × |
| Windowsノードの利用 | × | × |
| Security Group for Pods | × | 〇 |
| Public IPを持つPod | 〇 | × |
| DaemonSetの作成 | 〇 | × |
| 特権コンテナの実行 | 〇 | × |
| HostPort, HostNetwork | 〇 | × |
| 課金（クラスタ以外） | インスタンス単位 | Pod単位 |
| Spotインスタンスの利用 | 〇 | × |
| RI/SavingsPlanの利用 | RI/SP | SP |
| GuardDuty runtime monitoring対応 | 〇 | × |
各項目について
コントロールプレーンのバージョンアップ
コントロールプレーンのバージョンアップはどちらも利用者が明示的に開始する必要があります
ノードのバージョンアップ
Auto Modeはコントロールプレーンのバージョンアップ後、ノードのバージョンアップを自動で開始します。CoreDNSやkube-proxyなどのコンポーネントは一緒に更新してくれますが以下のものは自身でアップデートする必要があります。
- クラスタ内のアプリやワークロード
- 自製のアドオンやコントローラ
- Amazon EKS アドオン
Managed Nodeと比較してバージョンアップの考慮範囲が減るのは嬉しいですね。Blue/Greenによるクラスタアップグレード戦略をもともと採用していた場合、In-Place戦略に変えるほどのうれしさではない気もしますが。
一方、FargateはPodを削除->起動すればバージョンアップされたノードで起動してきます。
Fargate ノードを更新するには、そのノードが表すポッドを削除します。次にコントロールプレーンを更新し、ポッドを再デプロイします。Fargate で起動する新しいポッドには、クラスターのバージョンと一致する kubelet バージョンがあります。既存の Fargate ポッドは変更されません。
ノードへのSSH
EKS Auto NodeのノードはEC2のサービスコンソールからも目視できますがSSH（Session Manager含む）はできません。
これはEKS Auto Modeが管理責任がAWS側にあるManaged Instanceというインスタンスを利用しているためです。
EC2 Instances created by EKS Auto Mode are different from other EC2 Instances, they are managed instances. These managed instances are owned by EKS and are more restricted. You can’t directly access or install software on instances managed by EKS Auto Mode
なお、管理責任はAWS側にある一方でノードのログはPUT可能なHTTPのURLを利用者側で用意することで出力できるようです。
一方、Fargateには接続できるEC2インスタンスがないためSSHはできません。（EKS execとかいつか出ませんかね...）
イメージのキャッシュ
Auto Modeは新しくPodを立ち上げる際に、イメージのキャッシュが効くことが期待できます。Fargateは全く効きません。
GPUノードの利用
Auto Modeは起動するノードのインスタンスタイプを指定することはできませんが、NodePoolでインスタンスタイプを制限できます。サポートされているインスタンスタイプにはGPU搭載のものも含まれています。
一方、FargateはGPU未サポートです。
Windowsノードの利用
両方未サポートです。
Security Group for Pods
Auto ModeではPod単位のセキュリティグループはサポートされていません。ノード単位のセキュリティグループを利用できます。
一方、FargateはPod単位のセキュリティグループを利用できます。
EKS on Fargateも最初はPod単位のセキュリティグループサポートしていなかった覚えがあるので時間の問題かもしれません。
Public IPを持つPod
Auto ModeではPodにPublic IPを付与できます。Fargateは未サポートです。
DaemonSetの作成
Auto Modeでは作成可能でした。Fargateは未サポートです。
$ kubectl get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
fluentd 1 1 1 1 1 <none> 54m
特権コンテナの実行
Auto Mode、priviledged: trueの特権コンテナ作れました（何か認識違いがなければ...）。作れるということを認識しておく必要がありますね。なお、Fargateは未サポートです。
実施した手順
# privileged:trueのマニフェストを用意
cat << EOF > privileged.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
name: test-app-deployment
name: test-app-deployment
spec:
replicas: 1
selector:
matchLabels:
app: test-app
template:
metadata:
labels:
app: test-app
spec:
containers:
- image: nginx:latest
name: test-app-container
securityContext:
privileged: true
EOF
# 適用する。できた。。
$ k apply -f privileged.yaml
deployment.apps/test-app-deployment created
# 以下、ホストのディレクトリ見れるか確認
# Pod一覧の確認
$ k get po
NAME READY STATUS RESTARTS AGE
fluentd-s2l4x 1/1 Running 0 30m
nginx-deployment-d556bf558-lnzhj 1/1 Running 0 30m
nginx-deployment-d556bf558-n28r4 1/1 Running 0 30m
nginx-deployment-d556bf558-whrg9 1/1 Running 0 30m
test-app-deployment-58c4dcb56d-sc6c6 1/1 Running 0 28m
# マウント先の作成
k exec test-app-deployment-58c4dcb56d-sc6c6 -- mkdir -p /mnt/hoge
# ホストをマウント
$k exec test-app-deployment-58c4dcb56d-sc6c6 -- mount /dev/nvme1n1p1 /mnt/hoge
# マウントできてそう
$ k exec test-app-deployment-58c4dcb56d-sc6c6 -- ls /mnt/hoge
mnt
opt
var
# 他のコンテナのログディレクトリが見れる。やはり特権モードで実行できている模様
$ k exec test-app-deployment-58c4dcb56d-sc6c6 -- ls /mnt/hoge/var/log/containers
fluentd-s2l4x_default_fluentd-elasticsearch-b1b8edbcd9b1e0bd2641dfc14c690f220b0de77f5c66bec62fa6793e0ad9bb3d.log
nginx-deployment-d556bf558-lnzhj_default_nginx-3dff4d994e57dc86b04c3468f1c436a37e8ce008f827ec192b873a1ec3cab5c6.log
nginx-deployment-d556bf558-n28r4_default_nginx-62bb0e40317470e34a586a7b41a3cfb1a3aad08f2be46bb4d92f48f4eec43c41.log
nginx-deployment-d556bf558-whrg9_default_nginx-faf13f5b1837a1b57ab466f1f63b17875e314c19d74e87a9fb9dbe3f9d12c0a8.log
test-app-deployment-58c4dcb56d-sc6c6_default_test-app-container-b173c35bb9a383e995ac683f7bf3eba4fe3454b9328928ba69eae09cfed64897.log
HostPort, HostNetwork
Auto Modeではサポートされています。FargateはPodがノードのホストネットワークに直接アタッチされる形態なのでサポートされていません。
課金
Auto Modeはインスタンスタイプに応じて課金されます。
一方、Fargateはタスクまたはポッドのために要求された vCPU、メモリ、オペレーティングシステム、CPU アーキテクチャ、およびストレージリソースに基づいて課金されます。
Spotインスタンスの利用
Auto Modeではサポートされています。Fargateは未サポートです。
RI/SPの利用
Auto ModeではRI/Savings Plansがサポートされています。Karpenterを利用しているので、ROIを最大化するという観点ではインスタンスタイプに自由度があるSavings Planのほうがよさそうでしょうか。FargateではSavings Planのみサポートされています。
GuardDuty Runtime Monitoring対応
GuardDuty Runtime Monitoringはコンテナランタイムの脅威検知をおこなう機能で、コンテナの権限昇格や不正なプロセス実行を検知できます。
Auto Modeはサポート、EKS Fargateは未サポートです。
Runtime Monitoring supports Amazon EKS clusters running on Amazon EC2 instances and Amazon EKS Auto Mode.
Runtime Monitoring doesn't support Amazon EKS clusters with Amazon EKS Hybrid Nodes, and those running on AWS Fargate.
まとめ
- EKS on Fargateでは難しかったGPUノードやDeamonSetの利用ができるのはとてもよいですね！また、キャッシュ効くのもよいです
- 逆にEKS on Fargateのユースケースが限定的になりそうですね。小規模な利用ならノード管理の手間考えるとFargateのほうがよいかな？
-
Security Group for PodsはEKS on Fargateでも当初サポートされていなかったような。。そのうちサポートされるのかな。 - Auto Modeで特権コンテナ実行できるのは予想外でした。注意が必要ですね。（何か誤ってたら指摘ください
）
おわりに
EKS Auto ModeとFargateの違いについてまとめてみました！
何かのお役に立てば幸いです。