エンジニアは全員おうちKubernetesをやるべし【Part 2：どうやるのか】

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

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

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

ハード面

1台構成 or 複数台構成

複数台構成を取るメリットは大きいものだと以下があります。

• 1台が不調でも残りのサーバーで処理を継続できる（可用性が高まる）
• 大量のアクセスを捌ける

前者は、自宅サーバーでは気にしても仕方がないというか、停電やネット回線の障害で簡単に落ちるため、過度に可用性を気にする必要はないと思います。逆に言えば、可用性を気にする場合には、そもそも自宅サーバーはあまり向いていません。電源やネットを普段使いとは別のものを用意して可用性を確保する「ヤバい人」もいますが、そういう人については一旦忘れることにします。
後者に関しては、最初に書いた通り、このシリーズでは考えないことにしています。

と言うわけで、1台構成がお勧めです。

サーバースペック

体感ではメモリは4GBだとギリギリで、ほとんどの人にとって最適なのは6~8GBになると思います。16GBあった方が安心だとは思いますが、メモリヘビーなPodをいくつも動かさない限りは6GBあれば大丈夫だと思います。

緩くやるなら、普段使いしているデスクトップPCの余剰スペックを使ってサーバーを運用するのも全然アリだと思います。少なくとも僕の観測範囲内では、業務ではMacBookを使い、プライベートではWindowsデスクトップを使っているエンジニアが多いです。業務時間中にWindowsデスクトップのスペックを有効活用できるため、かなり有力な選択肢になると思います。
この使い方をする場合はメモリは16GBだと少ししんどいかもしれません。Kubernetesと、それを載せるためのWSLがそこそこメモリを喰うので、32GB以上メモリを搭載したデスクトップPCを持っている人向けです。

ある程度の可用性を確保したいという場合にはミニPCがお勧めです。N100/16GB/500GBのものが2万円程度で買えます。また、場所も取らず、省電力です。火事が怖い場合にはファンレスのミニPCもあったりします。

おうちKubernetesといえばRasberry Piのイメージがあるかもしれませんが、1台構成の場合はCPU性能がギリギリで、特にCI/CDをKubernetesクラスター上でやる場合にはかなり重くなってしまう気がしています（要検証）。可用性を気にする必要はないと書きましたが、Rasberry Piだけで複数台構成にする場合には価格的なデメリットもあまりないのでアリかもしれません。

ストレージ

おうちKubernetes用にスペックを揃えると、ストレージは256GB~512GBのものを選ぶことになると思います。しかし、Dropbox代替アプリのようなものを運用したい場合には、数TBの容量が必要になってきます。

外付けSSD/HDDを1つだけ取り付けると故障したタイミングで詰んでしまうので、なんらかの予防をしておいた方が良いと思います。
予算に余裕がある場合にはHDD/SSDのRAIDケースを使って、RAID1構成でストレージを拡張するのがお勧めです。
予算を抑えたい場合はBUFFALOの「みまもり合図」対応の外付けHDDを使うことで、ある程度ではありますが安心して使用できます。

ソフト面

Kubernetesディストリビューション

kubeadmという公式のディストリビューションを使うか、K3s等の軽量ディストリビューションを使うかの大きく2つの選択肢があります。どちらも起動してしまえば操作感はほとんど変わらないため、どちらでも大丈夫だと思います。

強いて言えばK3sの方が雑にクラスタを全削除して再作成しやすいので、慣れない内はK3sの方が簡単かもしれません。

CI/CD

Part 1で書いた通り、CDはArgoCD一択です。
また、ArgoCD Image Updaterも採用すべきです。これはコンテナレジストリを監視して、コンテナイメージが更新されればKubernetesマニフェストを更新するというPull型のCD補助ツールです。これがあることで、マニフェストの更新だけでなくコンテナイメージの更新に対してもPull型自動デプロイが可能になります。

CI（自動テストからコンテナレジストリにpushするまで）とコンテナレジストリには選択肢がいくつかあります。

	CI	コンテナレジストリ	価格
1	GitHub Actions	Harbor	無料
2	GitLab CI/CD	GitLab Container Registry	無料
3	Dockerhub Automated builds	Docker Hub	$7.00/月

1が一番バランスが取れた構成ですが、Harbor(OSS)の設定に少し時間がかかるかもしれません。2は個人的に一番好きな構成で、一つのサービス内にCI/CDとコンテナレジストリがあるOSSとして最もクオリティが高い一方、GitHubに草を生やしたい場合には両方にPushする設定が必要で少し手間かもしれません。3は有料ですが、設定がかなり簡単なため、一旦3から初めて時間に余裕ができたら1か2に乗り換えるというのはありかもしれません。

GitLabには他にも多くの機能があるため、それらの機能を使いたいのであれば2、そうでなければ1の構成を目指すのがお勧めです。

サービスの公開

そのままポートを公開してしまうとDDoS攻撃された時になすすべなく終わってしまうので、Cloudflare Zero TrustのTunnelsを使って公開するのがお勧めです。これはCloudflareのサーバーと自宅サーバーをWebSocketで繋ぐことで、自宅ポートを公開することなく、インターネットからCloudflareサーバー経由で自宅サーバー上のアプリケーションに接続することができるSaaSです。CloudflareなのでDDoS対策はデフォルトで付いていますし、何より無料なので使わない手はありません。

また、細かい話ですが、CLIでTunnelsを作成するとサブドメインにワイルドカードが指定できるため、サブドメインによって違うアプリを表示する挙動も簡単に実現できます。

ドメインの取得

CloudflareのTunnelsを使う場合にはCloudflareで管理しているドメインしか使えないため、Cloudflareで取得します。原価で買えるので最安でもあります。

静的ページとCDN

静的ページはCloudflare Pagesに上げ放題なので、Cloudflare Pagesを使いましょう。静的ページもおうちKubernetesから配信しようと思うと、Nginx等のコンテナが乱立する（あるいは設定ファイルが複雑になる）ため、あまりお勧めしません。ここまでくるとその他のCDNも、Cloudflareにしておくと管理が非常に簡単になります。

その他

Knativeを使うとCloud Runのようにアクセスがない時はPod数を0にできるため、余裕があれば試してみても良いかもしれません。

まとめ

• サーバー台数はメモリ8Gのが1台でOK
  • デスクトップPCがあるならそれでついでに動かす感じでもOK
• ストレージは必要なら故障対策をした外付けを追加
• Kubernetesディストリビューションは何でもいい
• CI/CDはGitHub Actions+HarborかGitLabを使うと安く済む
• 公開,ドメインの取得,CDNは全部Cloudflareに乗っかるとラク

最後にお勧めの書籍を紹介して終わりにします。

• Kubernetes完全ガイド
  • Kubernetesについて学ぶならまずこれだと思います
• Kubernetes CI/CDパイプラインの実装
  • ArgoCDと、今回紹介しなかったTekton Pipelinesを使ったCI/CDパイプラインの実装方法が学べます
• Knative実践ガイド
  • Knativeに特化した唯一の日本語書籍です