GKE AutoPilotの有用性について考察
モチベーション
GKE AutoPilotについて、出来ること/出来ない事が不明だったので、これを機に調べて見ました。
基本的なことは他記事に記載されているため、個人的になるほど、と思ったことを書いていきます。
GCPが謡っている、AutoPilotの用途
以下に利点が記載されていました。 その中で気になったのが、
柔軟な管理: ワークロードに特定のハードウェアまたはリソース（高使用率の CPU やメモリなど）の要件が存在する場合について、Autopilot にはそのようなワークロードに合わせて構築され事前構成されたコンピューティング クラスが用意されています。カスタマイズされたマシンタイプとハードウェアに基づく新しいノードを手動で作成することなく、デプロイでコンピューティング クラスをリクエストします。GPU を選択して、バッチ アプリケーションや AI/ML アプリケーションなどのワークロードを高速化することもできます。
という利点です。
つまり、AutoPilotは1podの起動時間あたりの課金なので、バッチ処理や機械学習に向いているよね、という話です。
気になる点
バッチ処理の罠
この記事を見ると、バッチ2重起動について言及されていました。
バッチ2重起動には、ノードのスケールインなどでjobリソースがevictされ、新しいノードにデプロイされたときに再度jobリソースが動作してしまう、というものです。
AutoPilotでは、v1.21から"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"でpodのevictを制御できない仕様となっています。
issueにも記載されていますが、今も解決していません。
そのため、これが解決するまでにはバッチ処理用としてAutoPilotを導入するのは危険だと感じました。
kube-system namespaceに関与できない
以下の記事で気になる文章が。
セキュリティ対策として、Autopilot では GKE が管理する名前空間（kube-system など）にワークロードをデプロイできません。
つまり、エコシステムによってはAutoPilotにデプロイする事が出来ない？
セキュリティスキャン系のOSSは特に導入が厳しいのではないでしょうか。
有用性
やはり細かく設定できないケースがあるため、今のところは小規模なクラスタの管理を楽にしたいというケース以外は思い浮かびませんでした。
今後に期待です。
Discussion