追記: 2022-10 移行、無料条件が変わったので Artifact Registry を使うのがよいです
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。
- 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