Oracle Kubernetes Engineをケチって使おうとして挫折した話
前提
- 非業務、個人の趣味クラスタとして使おうとしました（業務の場合は話がだいぶ変わる）
- できる限りAlways Freeリソースで使うことを狙いました（Paidアカウントにはしています）
- なので、課金が発生するポイントはできるだけ親切に書こうと思ってます。
- 挫折したけど、割とお安いと思います。
- 挫折した理由と、その間に得られたTipsをメモしておきたくて記事化しました。
結論 & tl;dr;
挫折した理由は最終的にBlock Volumeの課金が避けられないことでした。
Block Volumeは最小50GBなので、単価 $0.0255 x 50 = $1.275/mo の課金がPV1個につき発生します。
ちなみに、File Storageを使えば使った分だけ課金($0.3/GB)になると思われますが、こちらにはAlways Free枠はありません。
例えば、Mastodonを動かそうとすると PostgreSQLのPVが一個、動かすならElasticSearchがPV 1個 で50GB*2個。Boot Volumeも50GBなのでこれだけでAlways Free枠は使い切ります。
あと、Block VolumeにはPerformance Unitという課金もあります（金額はちょっとですけど。）
じゃあ、全部をFile Storageで賄えばいいじゃないか ($0.3/GB) というのもアリですが、100GB使ったら$30とかになってしまうのでうーん。という感じです。
事情があって今回は断念していますが、金額として個人では無理な額かというと、そういう感じではないとは思いました。正直、50GBがミニマムではなくて1GBからにしてほしいなーとは思います。
前置き
OKEとは
マネージドなkubernetesです。k8sを構成するControl Planeを無料で面倒みてくれます。
では、Worker Nodeはどうなるかというと、Computeのインスタンスが立ちます。ComputeのインスタンスなのでAmpere（VM.Standard.A1.Flex）を選べば、Always Free枠の対象となります。
蛇足
ノードは普通のComputeなので管理は自分でやる必要があります。OSのアップデートとかを面倒見てくれるわけではありません。
蛇足２
じゃあ、ComputeでControl-Plane含めて自前でやれば… というのはなくはない。
と言いたいけれども、メリットがない。OKEを使えばControl-Planeは無料で持ってくれるし、OCIのサービスと自動で連携する部分が結構あるので…
構築
ついに構築時の話を書いていきます。
ここでポイントが一つ。kubernetesクラスタは独立したCompartmentに入れておいたほうが管理上楽になります（他のリソースとのやり取りがあるのであれば別かもですが）。Compartmentを先に作っておくことをおすすめします。
さて、OKEは、Developer Services属に含まれます。Web UIからクラスタを作成できます。
以下は手順をさらっと流しながらポイントだけ記述していきます。
create cluster / custom
- 特にこだわりがなければQuick createで良いと思います。
Quick create cluster
ほぼデフォルト値でOK
- Compartmentは独立したものを選んだ方がいい。作ってないならここでは作れないのでキャンセルして。
- kubernetes versionは最新を選べばOK
- Endpointは Public Endpoint でよさそう。[^1]
- Kubernetes worker nodes は Private workers[^2] を選択
- Shape は VM.Standard.A1.Flex にする（Always Free枠を使いたいので）
- Number of nodes は… 悩みどころ。 2…か？ [^3]
[^1]: 要するに、kubectlをインターネット上から使えるようにするか、もしくは踏み台を必要とするか。ということだと思う。後段でkube/configを生成する段があるが、oci-cli(これもインストールが必要）を使って認証してるのでPublicでいいんじゃないかなぁと思っている。心配ならBastion（踏み台サーバー）もAlways FreeなのでPrivateを選んでもいいと思う
[^2]: workerを外から触れるSubnetに置くかどうか。置く意味がないのでPrivateでいいと思います。
[^3]: この数だけComputeのインスタンスが立ち上がる。ということは、Block Volumeが50GBずつ消費されることになる。
知見
ここからは構築後に得た知見をランダムに書いていく
ingress（インターネットからのアクセス）
外向きに見せたいPodは、Serviceに type: LoadBalancer を指定して作成すると
自動的にOCI上にLoad Balancerが作成されて外向きのIPアドレスが振られる。
・・・ということは、適当なServiceを作ると課金される。ということに。
LoadBalancerは2種類（執筆時点ではdeprecatedなのも入れると3種類）
- Dynamic Load Balancer(deprecated, デフォルト, 有料)
- Flex Load Balancer(有料)
- Network Load Balancer (無料, 以下nlb)
ケチケチ路線としては当然nlbを使うわけですが、これはLBというより普通にパケットが飛んでくるだけ。SSL終端とかはない。ので、ingress-nginx-controller（正攻法）や、普通にnginx pod を動かしてよしなに扱えばOK。
Serviceファイルの書き方
Load Balancerの種類やパラメタは、metadata -> annotationsに記述する。
1 | metadata: |
有料なのであんまりかかないが、Flex Load Balancerを使う場合は、10Mbpsに制限しないとAlways Free枠を外れるので注意。 annotationの書き方
ちなみに、annotaionsを書かないとdynamic load balancerが生成されてしまってもう、なんというか…となる。（Web UIに警告が出る）
なお、Serviceを削除すると対応するOCIのLoad Balancerは自動的に削除される。
Serviceファイルに関する蛇足
kubectl get serviceをして、EXTERNAL-IP が表示されていないのであれば、作成中かなにかしくじっているkubectl describeすると、annotaionsにエラーがあった場合ログが出ている。- 執筆時点では、Network Load Balancerは１個までという制限になっていた。（全体で１個かどうかはわからない）
- annotationsに間違った記述があると中途半端な状態になることがある。この場合、手動でWeb UIからLoadBalancerを削除して、serviceも削除するとやり直せる。
ノード数変更
Web UI の Node pools から変更する。 kubectl delete node して対応するComputeを削除しても大丈夫だとは思うけれども、何かの拍子に Node poolsで設定されたノード数になるように作成／削除されてしまう可能性がある。
大蛇足
ここからは読まなくていいです。
どうやってアクセスを受付ようとしていたか
- 一個だけ、nlbを指定したServiceでnginxを動かす
- nginx Podに1GBのストレージを割当する
- nginx Podには、certbotとvimを入れておく
- 設定変更等はvimを使ってコンテナ内でやってしまう
- 他のサービスはserviceの type:ClusterIPを指定しておく
- nginxでclusterIPに大してproxyする
why ?
- ingress-nginxを使うのが王道だが、規模に大して大げさだったため
- configとかはconfigMapを使えば入れれるのはわかるが、
nginx -tに相当する動作が多分ないので設定ミスがダウンにつながってしまう。 - 証明書はsecretとかを使って更新かけるのがよい気がするが、そのたびにPod再起動するの…めんどいなぁとなったため。
多分、設定変更や証明書変更のたびにnginx Podを追加で起動して、Healthyになったら古いnginx Podを終了させるようにすればほとんどの懸念は解決できる気がする。（Rolling Updateして maxSurge=1 を指定しとけばそうなるはず）。多分、ここらへんはkustomize を使うといいと思う
…けど、nginx -tで間違ってないかテスト出来たほうがいいよねぇという感じはする。
問題点
1GBのストレージ を割り当てるのは OCI File Storageを使えば $0.30/mo で済む。が。有料ではある。
次の手は？
k3sを使ってとりあえずkubernetesっぽい感じにしようかなぁと思ってます。
蛇足
k3sを使ってとりあえずkubernetesぽい感じにしました。色々苦労はあったのですがそれはまた別の記事で…
