なぜ自宅に Kubernetes クラスタを持つのか —— 本番相当に運用して得られる学び（前編）

1. はじめに

前回のコラムでは、 Kubernetes を深く理解するために役立つ技術書を紹介しました。書籍から得られる体系的な知識は、複雑なエコシステムを紐解くための強力な武器になります。

levtech.jp levtech.jp

今回の連載（全2回）では、その一歩先として、学んだ知識を実務で活かせるスキルに変えていくための「実践の場」についてお話します。題材とするのは、私が自宅で数年にわたり運用し続けている Kubernetes クラスタです。

前編となる今回は、そもそもなぜ自宅に Kubernetes クラスタを持つのかという動機や、趣味の環境であってもあえて「本番相当」に扱うことで得られる学びについて紹介します。続く後編では、そのクラスタを具体的にどう運用しているのか、採用しているアドオンや省力化の仕組みを掘り下げます。

自宅クラスタを構築すること自体は、いまやそれほど難しいことではありません。しかし、それを「継続的な運用対象」として育てていくプロセスには、単なる構築手順を超えた、インフラエンジニアや SRE としての面白さが詰まっています。

2. なぜ自宅クラスタを運用するのか

Kubernetes を試すだけなら、手元の PC 上に Docker などを使ってクラスタを構築できる kind や minikube といったツールを使い、一時的な環境を作るのが最も手軽です。あるいは、パブリッククラウドのマネージドサービスを利用して、インフラ管理の手間を省きつつアプリケーションの開発・運用に集中する選択肢もあります。

それでもなお、あえて自宅に実機を並べてクラスタを構築し、運用し続けるのには理由があります。

業務では試しにくい構成を、自分の責任範囲で試せる

何よりも自分の責任で自由に試せることです。 業務で扱うクラスタには、当然ながら可用性やセキュリティに対する厳しい要件があり、歴史的な経緯や予算の制約も無視できません。新しいツールや実験的な構成を試したいと思っても、影響範囲や責任を考えると二の足を踏んでしまうことも少なくないでしょう。

一方で、自宅クラスタは自分自身の責任範囲で、文字通り何をしてもよい自由な環境です。

• Rook Ceph¹ などの分散ストレージを自律的に動かし、ハードウェア故障からの復旧を試す
• 本番環境では採用判断が難しい、とがった機能を持つアドオンを試験導入してみる
• VXLAN などの導入が容易な方式ではなく、あえてネットワーク機器との連携が必要な BGP ルーティングを組んでみる

こうした「業務ではハードルが高い挑戦」を、誰に気兼ねすることもなく実行できるのが自宅クラスタの魅力です。

自宅クラスタは「盆栽」のようなもの

私はよく、自宅クラスタのことを「盆栽」にたとえます。盆栽は、一度完成させて終わりではありません。日々、枝ぶりを整え、土を替え、長い時間をかけて自分の理想とする形に近付いていくものです。

自宅クラスタも同様で、どのような構成を目指すか、どこまで可用性にこだわるか、どのように運用を楽にするかといった問いに正解はありません。自分の興味や価値観に合わせて少しずつ手を入れ、育てていく対象です。

また、盆栽である以上、このクラスタで特定の「実用的なアプリケーション」を安定稼働させること自体は主目的ではありません。例えば実験的なアドオンを入れたことで、クラスタ全体が一時的に不安定になることもあるでしょう。そのため、私の場合、自宅内で絶対に落としたくない重要なアプリケーションは別の Raspberry Pi 単体で動かすといった使い分けをしています。あくまで、インフラそのものを楽しみ、育てるための場所として扱っています。

単なる「使い捨ての実験場」ではなく、自分とともに成長していく継続的な運用対象。そう捉えることで、自宅クラスタはエンジニアとしての好奇心を形にしていける、自分だけの環境になります。

3. 「壊せる環境」で終わらせない

自宅クラスタのメリットとして「気軽に壊せること」がよく挙げられます。たしかに、設定を間違えてクラスタが再起不能になったとしても、業務への影響はありません。 OS を再インストールしてゼロからやり直せば済みます。

しかし、私はあえて「壊れたら作り直す」だけで終わらせないことを意識しています。

復旧と再発防止のプロセスに学びがある

クラスタが不調に陥ったとき、安易に再構築するのではなく、なぜ壊れたのかを調査し、復旧を試み、同じ問題を二度と起こさないための対策を講じる。このプロセスこそが、実務に近い、あるいは実務を超える運用経験をもたらしてくれます。

たとえば、ある日突然、一部の Pod が起動しなくなったとします。ログを追い、メトリクスを確認し、リソースの競合や設定の不備を特定する。時にはアップストリームのイシューやソースコードまで潜り込む必要があるかもしれません。こうしたトラブルシューティングの経験は、実際に手を動かして直面しなければ、なかなか得られないものです。

「壊れてもよい環境」だからこそ、あえて「本気で直す」ことに挑む。 その積み重ねが、いざ業務でトラブルに直面した際の判断力や、堅牢なシステムを設計するための洞察力へとつながっていきます。

趣味の環境であっても、あえて実務のように向き合ってみる。それが私の考える自宅クラスタ運用の面白さです。

4. 本番相当に扱うための監視と障害対応

自宅クラスタを「本番相当」に扱うための具体的な取り組みとして、私は監視と障害対応のプロセスを特に重視しています。

自宅クラスタで最も避けたいのは、クラスタが壊れていることに気付かず、気付いたときには修復が面倒な状態になってしまっていて、つい放置してしまう、という事態です。構築自体は簡単ですが、それを健全な状態で維持し続けるためには、監視によって状態を可視化することが何よりも重要になります。

私は、 Prometheus² や Alertmanager³ を用いた監視基盤を構築し、アラートが発生した際には自動的に GitHub Issue として起票し、対応の過程をすべてコメントに残す運用を行っています。ここで本質的に重要なのは、Issue の自動起票という「手段」そのものではなく、オペレーションの過程をありのままに「記録」しておくこと自体にあります。

というのも、私には「人間がドキュメントを継続的に維持管理することは根本的に難しい」という考えがあるからです。作業の後に設計書や手順書（Runbook）を更新し続けることは、人間にとって非常にハードルの高い作業です。しかし、生の作業ログやその時の判断さえ残っていれば、現代なら AI エージェントに情報の整理を任せることで、「人間の意志の強さや運用の徹底」に頼らず、Runbook の継続的な維持管理が可能になります。

こうしたドキュメント管理に対する私の思想は、自宅クラスタの話とは少しズレるかもしれませんが、自由な実験場だからこその試みだと考えています。記録さえあれば AI が知識を整理してくれる時代だからこそ、まずは「記録を残すこと」に最大の価値を置く。そんな運用を楽しみながら続けています。

これは後になって知ったことですが、このドキュメント管理方法は Andrej Karpathy 氏が提唱する「LLMWiki」⁴の概念にも通じるアプローチでした。AI が生の記録（一次情報）を読み込み、自律的に Markdown の Wiki を整理・更新し続ける。自宅クラスタを、こうした新しい運用の形を試す場としても活用しています。

こうした「障害対応をどう記録し、次に生かすか」という仕組みづくりも、継続運用するクラスタならではの楽しみです。

5. 自宅クラスタの全体像

ここで、題材としている私の自宅クラスタの全体像を簡単に紹介します。

写真は私の自宅で稼働している実際のクラスタですが、実はこれ、玄関の下駄箱の中に配置しています。

当然、そのままでは熱がこもってしまうため、発熱の少ない省電力な機器を選定した上で、下駄箱の扉を常時半開きにして通気性を確保する運用をとっています。

限られた生活空間の中で、家族の理解を得つつ運用を続けるための工夫でもありますが、こうした物理的な制約と向き合うのも自宅クラスタならではの面白さです。

構成のコンセプトは「高可用性」と「省力運用」です。 コントロールプレーンが壊れてクラスタごと放置してしまう事態を防ぐため、業務環境と同様に冗長化を意識しています。

物理的には、 Raspberry Pi 4 を6台（コントロールプレーン3台、ワーカノード3台）並べ、 PoE⁵ 給電で稼働させています。 Raspberry Pi の標準ストレージは microSD カードですが、読み書きの遅さや寿命の問題が懸念されるため、私の環境では M.2 SATA SSD を使用できる専用のモジュールを組み合わせて運用しています。

コントロールプレーンを3台構成にしているのは、 Kubernetes の状態を管理する etcd のクオーラム（合意形成に必要な最小限のノード数）を維持するためです。クオーラムを失うと、クラスタの操作や更新が一切できなくなってしまうため、安定運用の要となる部分です。この構成をとることで、 OS のアップデートや Kubernetes のバージョンアップを行う際にも、1台ずつ順番に実施することでクラスタの機能を停止させることなくメンテナンスが可能になります。

これもクラスタを安易に落とさないために必要な仕組みですが、昨今の円安や物価高の影響により、ミニ PC やメモリなどの機材価格は上昇傾向にあります。最初から3台そろえるのはハードルが高い場合も多いため、まずはコントロールプレーン1台の最小構成から始めて、必要に応じて拡張していくのも現実的な選択肢でしょう。

論理的な構成としては、分散ストレージとして Rook Ceph を採用し、負荷分散には BGP を用いた MetalLB⁶ を組み込んでいます。 また、継続的な構成管理のために Flux⁷ を用いた GitOps を導入しています。

本番相当に運用することで見えてくる課題もあります。印象に残っているのは「ホストの高負荷」への対策です。 Kubernetes では、 Pod に割り当てるリソースだけでなく、 OS や kubelet などノード自身が消費するリソースも考慮しなければなりません。私は過去にホストのリソース枯渇による障害を経験し、その後 kubelet 設定の system_reserved/kube_reserved の設定⁸をチューニングしてホストが使用するリソースを適切に確保する対策を行いました。

こうしたチューニングの必要性に気付けるのも、物理マシンを用いて本番に近い構成を組んでいるからこそと言えます。

6. 費用感と現実的な始め方

「自宅に本番相当のクラスタを組む」となると、気になるのはコストです。 過去の購入額ではなく、現時点の価格感でゼロから同等の構成をそろえようとした場合、どこにどれくらいのコストがかかるのかを表に整理しました。

項目	私の環境での採用例	概要・コスト感
ノード本体	Raspberry Pi 4 (4GB/8GB), PoE HAT	SBC（シングルボードコンピュータ）やミニ PC など。メモリ 8GB 以上のモデルを複数台そろえる場合、数万円〜十数万円の初期投資になります。
ストレージ	M.2 SATA SSD + 専用モジュール	OS インストール用の SSD など。分散ストレージ（Rook Ceph）を構成する場合、専用のディスクを用意するか、ルートボリュームを LVM などで切り出して使用します。
ネットワーク機器	EdgeRouter X, TP-Link 製 PoE ハブ	BGP や VLAN などを喋れる L2/L3 スイッチ、および PoE ハブなど。数千円〜数万円程度。
電気代・設置場所	-	24時間365日稼働させるためのランニングコスト。ノード数に比例して電気代と物理的な占有スペースが増加します。

7. おわりに

本記事では、自宅に Kubernetes クラスタを持つ意義について、「盆栽のように育てる」という視点からお話しました。

自宅クラスタは、単なる一時的な実験環境でもなければ、業務環境の完全な代替でもありません。自分の関心に合わせて少しずつ構成を見直し、壊れたら原因を究明して堅牢にしていく。その継続的なプロセスを通じて、運用の「勘所」を養い、システム全体を深く理解するための場所です。

次回（後編）では、この自宅クラスタを「どう運用し続けているのか」に焦点を当てます。ネットワーク、ストレージ、 GitOps 、監視、更新管理など、クラスタの維持に必要な領域ごとに、どのようなアドオンを採用し、どのような運用を自動化・省力化しているのかを具体的に紹介します。