GKE Autopilot で節約のために asia.gcr.io を使う

GKE Autopilot に移行してみたところ、意外と費用がかかっていた。
調べたところ、Cloud Storage の egress が支配的で、GCR からのコンテナイメージ転送量が原因だった。
費用を抑えるにはクラスタのロケーションに合わせた GCR レジストリを使うのがよい。

原因

GCR のイメージレジストリには gcr.io と、ホストされるロケーションが付いた us.gcr.io, eu.gcr.io, asia.gcr.io がある。
近いロケーションを選んでも pull の時間に差があまりないという話もあって、短い方がかっこいいし、gcr.io にイメージを保存していた。内部的には US にホストされており、asia-northeast1クラスタへ pull する際には US からの storage egress の費用がかかる。

Standard の GKE クラスタではノードとなる GCE インスタンスを確保するので pull されたイメージはインスタンス内で使い回されてキャッシュとして働く。 ノード管理が要らない Autopilot では実行ごとに同じインスタンスに当たるとは限らない(当たることもある)。

Cloud Logging 上では以下のようなログで pull されたか判別できる - Pulling image "..." - Container image "..." already present on machine

解決

GCP 内の同ロケーションでの Cloud Storage データの移動は無料!! なのでクラスタのリージョンに合わせた GCR ロケーションにイメージを置いて利用することでこの費用はゼロになる。

ネットワーク - 料金  |  Cloud Storage  |  Google Cloud

今回 GKE Autopilot へお試し移行したサービスは CronJob ばかり実行するシステムで、継続的にインスタンスが確保されにくく高頻度でイメージを pull していた。 $100/month 程度のインフラ費用を見込んでいた小規模なサービスだったけど、無料枠を超えたところから storage egress に $10/day 払う羽目になっていたので急いで対処した。

おまけ

挙動確認のために 30分おきに起動する CronJob を動かしたプロジェクトの費用、クラスタは asia-northeast1。

f:id:pokutuna:20210820063248p:plain
Cloud Storage 費用

  • 7/30 ~ 8/2 は gcr.io
  • 8/2 ~ 8/4 は asia.gcr.io → 費用なし

7/31 の24時間の間 gcr.io を使った CronJob が動いていた 7/31 の転送量は 3.1 Gibibyte

docker image の転送サイズ(イメージサイズではなく圧縮されたもの)を調べるには
$ docker manifest inspect IMAGE | jq '[.layers[].size] | add'

今回使ったイメージのサイズは 69285060 byte, このイメージを 24*2 回 pull していて 69285060 * 24 * 2 / 2**30.to_f => 3.0972835421562195 なので 3.1Gibibyte と一致する。よかったですね。

リンク

GKE Autopilot のご紹介: マネージド Kubernetes における革命 | Google Cloud Blog

レジストリ - Container Registry の概要  |  Container Registry のドキュメント  |  Google Cloud