こんにちは。おうちKubernetesを勧めるためにやってきました。

このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。

この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。

エンジニアは全員おうちKubernetesをやるべき絶対的な理由

自己研鑽のために

（鑽←この字「研鑽」と「大鑽井盆地」でしか見ない）

企業がKubernetesを採用する場合、ほとんどがEKSやGKEといったクラウド上で動作するマネージドKubernetesサービスを使用すると思います。ただ、Kubernetesであればコマンドやマニフェストファイルの書き方は共通なので、おうちKubernetesで学んだことがそのまま業務に活かせます。

他のメリットも享受しながら、業務に必要な知識を身につけられるおうちKubernetesは必ずやるべきです。

サブスク費の節約のために

大抵のSaaSには、それの代替OSSが存在します。機能が足りていないことも往々にしてありますが、OSSなので自由に付け加えることが出来ます。
例えば、Dropboxは2TBで年間24400円ですが、おうちKubernetesでファイルの保存・共有をやる場合には2TBの外付けSSDがあれば十分です。2TBの外付けSSDは安いものであれば2万円以下で買うことができ、数年以上は安心して使えるため、トータルの金額で言うと10万円以上節約できるかもしれません。

後述しますが、こういったOSSを実行する場所としておうちKubernetesはベストですので、必ずやるべきです。

自分用・身内用アプリのデプロイ先として

自分や身内しか使わないようなアプリ、つまり「常時起動していてほしいがそこまで負荷が高くならないアプリ」のデプロイ先として、無料で使える自宅サーバーを選択するメリットは言わずもがなですが、その中でもおうちKubernetesは特にCI/CDの構築は群を抜いて簡単です。枯れているOSSをデプロイするならまだしも、自作アプリは使っているうちに問題点が気になりすぐに修正したくなるものなので、GithubにPushするだけでテストからデプロイまで自動で完了するCI/CD Pipelineを簡単に構築できるおうちKubernetesは必ずやるべきです。

ちなみに、複数台構成(+α)にすることでおうちKubernetesでも不特定多数のアクセスに耐えうる構成にはできますが、そちらの道は沼に通づるためお勧めはしません。

エンジニアは全員おうちKubernetesをやるべき相対的な理由

他の技術と比較した時に「なぜおうちなのか」「なぜKubernetesなのか」について解説します。

なぜおうちなのか

Amazon EKS

クラスタを起動しているだけで 0.10 USD/時の料金がかかります。これは1ドル150円換算だと1万円/月を超えます。おうちKubernetesを使うメリットの1つとして、前述の通り「節約」があります。節約目的の場合にEKSを使わない方が良いのは自明でしょう。

GKE,AKS

クラスタを起動しているだけでかかる料金はありませんが、Podの起動に対してそこそこの料金がかかります。まともに運用しようと思うと、1アプリ+DB系（Kubernetesにホスト）で2~3千円/月くらいになると思います。節約目的の場合には少し高く感じると思います。

ただしGKEの場合には、KubernetesのCronJobという定期実行機能+FireStoreという構成のアプリだけを運用したい場合には数百円以内/月で運用できることもあります。
詳しくは以下の記事が参考になります。

とはいえこの構成だけでは、3つ挙げたおうちKubenetesの目的のうち「自分用・身内用アプリのデプロイ先として」しか達成できないため、やはりおうちKubernetesは（並行してでも）必ずやるべきです。

VPSにKubernetesを入れる

VPSは有力な選択肢ですが、Kubernetesをまともに動かそうと思うと3000円/月くらいのスペックのインスタンスが必要です。1年で3万6千円なので、例えばおうちKubernetes用にミニPCを買ったとしても1年以内に逆転します。

なぜKubernetesなのか

これの答えはCD（CI/CDのCIじゃない方）です。

自宅サーバーは停電やネット回線の不具合等で簡単に落ちます。
そのため、自宅サーバーが落ちていても問題ないようなCDツールを採用しなければなりません。つまりPull型のCDツールを採用すべし、ということです。

Push型とPull型の違いは「誰がCDを発火させるか」です。Githubを使う場合、GithubがCDを発火させていればPush型で、そうでなければPull型です。

例えばJenkinsのWebhookを使った自動デプロイは、GithubがWebhookを叩いて発火させているのでPush型になります。Github Actionsを使って自宅サーバーにSSHしてデプロイコマンドを実行する場合もPush型ですね。
Pull型は、自宅サーバー上で動いているツールがGithubレポジトリを監視し、変更があればGithubから新しいコードを引っ張ってくるようなものです。

Pull型のCDツールを探してみると、ArgoCD等のKubernetes用のCDツールしかまともなものは見つからず、Kubernetesをやるしかないというところに行き着きます。

なぜおうちKubernetesなのか

最後におうちでもKubernetesでもない競合との比較をします。節約のためというのをずっと言ってきているので、選択肢は以下になると思います。

Lambda
App Runner
Cloud Run
fly.ioやrender.comといった格安PaaS

どれを使うにしても、DBは無料枠の広いDBaaSを使うことでだいたい対応できると思います。Lambdaや格安PaaSだけでやりくりするのは、可搬性の低い知識だけが溜まっていくことになるためあまりお勧めしませんが、1~2個のアプリを手っ取り早く動かしたいという場合にはありだと思います。

App Runnerはほぼゼロ知識でコンテナを実行できるため、知識習得に時間を取られないという意味でLambdaや格安PaaSよりは良いでしょう。Cloud Runは実務レベルで広く使われているため、勉強のためだとしても使う価値はあると思います。
ただどちらも1アプリあたり数百円/月は想定した方がよく、アプリ数が増えれば増えるほど料金も増えていく点には注意が必要です。

やはりCPU/メモリが耐えられる内はアプリ数がどれだけ増えても無料で運用できるおうちKubernetesは必ずやるべきなのかもしれません。

追記（2023-11-22）

Qiita以外のいろんな場所で来てたコメントにせっかくなので回答します。

おうちKubernetesは勉強にはなるかもしれないけど可用性がないから、費用対効果（時間対効果）的に割に合わない気がする。仕事で自前でKubernetesを建てることもないだろうし。。(;^_^A

これはPart1の方に書いておけば良かった話なんですが、可用性は諦めて自分・身内用（つまり気づいた時に復旧すれば問題ない）アプリの運用を想定しています。「自己研鑽のために」の箇所で書いた通り、仕事で自前で建てることはなくても仕事に役に立つと思っています。

Azure container apps 入れたげて

あんまり使ったことがないのでボロを出さないようにこっそり省きました。許して欲しいとは言いませんが、娘の命だけは取らないでください。

主語がでかい

僕もそう思います。

主語広いのは「扇情的なタイトルを付けたい」という僕の気持ちと、Qiitaのタイトルの文字数制限がせめぎ合った結果です
ソフトウェアエンジニアにすら限定できていなくてかなり無理はあるので「読者たち、良い感じに汲み取ってくれ！」という信頼の気持ちでこのまま投稿しました https://t.co/CXBlbvDv1u
— もりた (@takumi3488) November 22, 2023

“ArgoCDというKubernetes用のCDツールしかまともなものは見つからず” そうか？別にfluxでもJenkinsXでもSipnnakerでも良くね．全部k8sだけど．

「ArgoCD等のKubernetes用のCDツールしか」と書いて後でArgoCDに限定していくつもりが間違えてました。一旦ArgoCDに限定していく部分は除いて修正しています。ご指摘感謝します。

自分で書いちゃってるけどクリティカルな理由がなければサブスク3000円くらいのサーバー借りたほうが問題は少なそう。※ただし自宅サーバの電気代は無料とする。みたいな隠された条件がね。

コメント欄で書きましたが、機体選びを頑張れば電気代は月100円以下程度で抑えられるので、金額差はデカいと思います。

精神論だけどいろいろ新しいことを試す用のマシンは目に見える場所に実機があったほうがいじってて楽しいしアイデアが浮かぶんだよな。いや精神論だけど。

精神論なので書かなかったんですけど、これは本当にそうなんですよね。あとテンションも上がるのでモチベも湧きます。いや精神論だけど。

自宅サーバーは数年後、落雷で逝ってからが本番。バックアップ取ってないの？構築内容ドキュメント化してないの？　雷は落ちるぞ。

これは本文に書かなかったんですが、GitHubで管理しているYAMLファイルを元にインフラを自動構築できるのがKubernetesやGitOpsの良いところなので、それ以外の自宅サーバーよりはこの心配はマシだったりします。KubernetesやArgoCD自体のインストールも、シェルスクリプトファイルを書いて1コマンドで出来るようにした方がラクだと思うので、そうすると自動的にGitHubで管理することになって消失の心配はなくなります。
後はオブジェクトストレージやデータベースの心配をどこまでするかですが、定期的にS3 Glacier Deep Archiveにバックアップすると2TBでも年間400円以下なので、やるならそれくらいでしょうか。

最後に

あくまでこのシリーズでは、以降も「低負荷だけど常時使える状態ではあってほしいようなアプリを無料で運用しつつ、業務でも役立つ知見を深める」ということを目的として進めていきます。「大量のアクセスがあるアプリを大手クラウドよりも格安で運用する」ことは想定していないためご認識ください。

それでは、みなさんもおうちKubernetesを始めましょう。