inductor's blog

nothing but self note :)

EKS FargateとGKE Autopilotの違いを外野から解説してみる

はじめに

GoogleのマネージドKubernetesディストロであるGKEの新機能（厳密には新しい種類のクラスターといったほうがユーザーにとっては正しい説明になると思いますが）、GKE Autopilotが先週大きく話題になりました。

  • ノードがGoogle Cloudによるマネージド
  • Podごとの課金体系
  • ノードへのSSHが使えない

といった特徴が大きく取り上げられており、ぱっと見AWSのEKS Fargateと非常に似ているように見えます。が、(少なくとも、user facingな部分においては)技術的には全くやっていることが違うと思います。なぜならFargateはEC2とは全く異なるVM技術がベースになっているのに対して、Autopilotは通常のGCEを応用した機能として提供されているからです。

※まあ、GCEは実はコンテナで動いてるみたいなちょっとした裏話もあったりするんで、本当に裏のところまで見ると似てるところはもっとあるような気もしますが、今回はuser-facingな話なのでなしで・・・。裏のこと僕もわからないし。

僕はAWS、GCPどちらにも所属しない、ちょっとコンテナが好きなエンジニアですが、これらの違いを僕の知ってる範囲で解説してみようと思います。

Autopilotについて

上述もしてますが、基本的にAutopilotはGCEと同じ普通のマシンを使っています。E2という最近増えた安いインスタンスをCluster autoscalerによる自動スケーリングと自動ノードプロビジョニングという、「ワークロードに最適なマシン」を自動的に選択して割り当てるGKEの機能の組み合わせによって実現されている、という話はKazuuさんのMedium記事や、GKEの公式ドキュメントにも以下のように書かれています。

Node は Pod のスケジューリングに合わせて必要量が自動的にプロビジョニングされます、ユーザー自身で Node を 直接作成したり、追加したり、削除したり出来ません。GKE Autopilot では Cluster autoscaler 及び Node auto provisioning がデフォルトで有効になっています。(無効化できません)

medium.com

With Autopilot clusters, you don't need to worry about provisioning nodes or managing node pools because node pools are automatically provisioned through node auto-provisioning, and are automatically scaled to meet the requirements of your workloads.

cloud.google.com

つまり、この時点でFargateとは全く異質な「実際にノードはいるんだけど、見えない」という状態になっていることがわかります。

Fargateと挙動が異なる根拠として、Autopilotは「ワークロードに最適なマシン」を自動的に選択して割り当てるだけなので、例えば既存のAutopilot nodeの中でリソースに余裕がある場合は、そのノードに新しいPodをスケジュールする場合があります。また、PodとNodeの関係性に特別な成約はないので、DaemonSetも通常の構成と同じように動きます。

f:id:inductor:20210307002541p:plain

上図の通り、既存のスケジューリングによって既に配置されているPodやNodeの関係性がN:Mになる可能性は十分ありますし、DaemonSetの配置によってもリソースの状況が変わってきます。そのへんをいい感じにしてくれるのがAutopilot、もといその裏で動くNAP(Node Auto-provisioning)というのが私の理解です。違っていたら誰か教えてほしいです。

なお、インスタンスタイプはE2シリーズなので、共有コアタイプのe2-mediumなどのほか、e2-standard-32(16コア、64GB)やe2-highcpu-32などといったタイプも払い出すことは可能そうですが、以下のような成約がPod specに課せられるので注意が必要だと思います。（※私はまだこのへんちゃんと試してないので、雑に説明しています。間違っていたら教えて下さい）

CPU は 0.25 vCPU 単位でインクリメントされます。
中途半端な値を指定すると自動で是正されるので注意してください。
※ Pod anti-affinity を使った場合は0.5 vCPU 刻みになります。
e.g. 0.66 vCPU >> 0.75 vCPU
CPU と Memory は 1 対 6.5 の割合以内に収まっている必要があります。
こちらもルールに則っていないと自動で是正されます。
e.g.1vCPU & 7 G Memory>> 1.25 vCPU & 7 GB Memory

この辺はお作法に則っていないPod specを取り締まるGatekeeperがうまく働いている感じがして面白いですね。

Fargateについて

Fargateについては、オタク諸君詳しい人達の調査によって、(EKS、ECSそれぞれでどうかは全く不明ですが)Firecrackerベースの基盤とXenベースの基盤が存在していることがわかっていますが、詳しい割合や割当の基準が判明しているわけではありません。そこで、オープンに技術として公開されているMicroVM技術であるFirecrackerをベースにFargateの挙動について解説してみようと思います。

なお、今回の記事の趣旨ではないのでFirecrackerがなにかについては解説を割愛しています。知りたい方は僕がコンテナランタイムミートアップで発表した初心者向けの資料などを見るとよいかもしれません。

www.publickey1.jp

EKSにおけるFargateは、EC2と完全に対立した存在になっています。

※ちなみにもうちょっと厳密な話を入れると、FargateのVMが立つ環境の下にはベアメタルEC2がいるわけですが、今回はVMの話をしているのでベアメタルのEC2については目をつむってくだい。

f:id:inductor:20210307004131p:plain

具体的な使い方で言えば、Fargateに対するProfileをJSON形式で指定して、特定のnamespaceやラベルに一致するマニフェストが適用された場合にFargateの環境でワークロードが動くように設定します。

なお、ノードグループとしてはFargateとEC2は両立が可能なので、同一クラスターが両方の基盤で動くワークロードを管理するという状況が起こりえます。これはAutopilotでは現状できないため、一つ大きな違いになりそうです。下記のようにGKEではAutopilot用のクラスターは別で用意する必要があります。

f:id:inductor:20210307004848p:plain
GKEではStandardかAutopilotかを選ぶ必要がある

一方で、Fargateの場合は同じクラスターの中にEC2とFargateを混在するように設定が入れられます。

f:id:inductor:20210307005046p:plain
EKSでは同一クラスター内にFargateとEC2が混在できる

※ちなみにこれは別に公開しても良い名前のクラスターなのでご安心を

Fargateについては出たばかりのときに青山くんが書いた以下のブログや

amsy810.hateblo.jp

mumoshuさんのQiita記事なんかもありましたね。

qiita.com

図がないとわかりにくそうなので頑張って図を書きます。

f:id:inductor:20210307010509p:plain

FargateはNodeごとに割り当たるPodが1に制限されており、DaemonSetが入りません（まあ、Namespaceで分けてるのでそこは頭いいなとは思いました）。

細かい計算は忘れてしまったので@toriclsなどに聞いてほしいですが（スライドもどっかにありましたね）、PodとFargate microVMのリソース関係は実際には完全に同一ではなく、kubeletなどが動く分だけすこし追加でリソースが割当たります。今は雑に図を書いたので実際のところは公式のドキュメントをどこかでよんでくださ～～い。

なんかそれっぽい比較表

種別 Fargate Autopilot
マネージド？ はい はい
SSH できない できない
カーネルパラメータ いじれない いじれない
DaemonSet つかえない つかえる
IaaSとの混在 できる できない
Node spec vs Pod spec ぴったり NAPの粒度まで

他にもいろいろ掘れそうなところはありますが、技術的には全然やっていることが違うことがわかってもらえると嬉しいなと思います。

最後に、HPEではこんな内容とは全く関係ないけどクラウドネイティブな技術をエンプラで広めたいというエンジニアを募集しています！少なくとも2021年においては全くこの知識は使わないと思いますがよろしくお願いします！