1台のホームサーバーでProxmox、Kubernetesのラボ、ネットワークストレージを同時に運用できる？

はい。ストレージが安定したハードウェア経路を管理し、ラボのリソースを制限して破棄可能な状態にしておけば、1台のホームサーバーでProxmox、Kubernetesのラボ、ネットワークストレージを運用できます。

この設計は、学習や重要度の低いホームサービスに最適であり、自動的な高可用性には向きません。物理ホストはProxmoxに管理させ、ストレージの役割を明確にし、Kubernetesの実験によって家族のデータやバックアップの唯一のコピーが制御されないようにします。

各ハードウェア経路の所有者を1つにする

CPU、メモリ、NIC、起動デバイス、仮想化はProxmoxに管理させます。ストレージをホスト上で動かすのか、コントローラーをパススルーした専用VMで動かすのか、別のアプライアンスの役割として運用するのかを決めます。

包括的な単一サーバーのProxmoxおよびKubernetesホームラボは、1台のホストでVM、Kubernetes、ストレージ、GitOps、プライベートアクセスを組み合わせられることを示しますが、同時に物理サーバーが共通の障害境界になることも意味します。

ホストとストレージVMの両方で同じディスクを管理しないでください。コントローラーとファイルシステムの所有者を明確にする必要があります。

安定したサービスとラボを分離する

DNS、ストレージ管理、バックアップ、重要なホームサービスは、Kubernetesラボの外部、または安定したVMグループ内に置きます。Kubernetesノード、Ingressの実験、テスト用ワークロードは再構築できるようにします。

CPU、メモリ、I/O、ストレージのクォータを設定し、暴走したPodがファイルサービスを圧迫したり、プールを使い切ったりしないようにします。ラボに割り当てる容量を決める前に、ハイパーバイザーとストレージスタック用のメモリを確保します。

障害の連鎖や権限の観点から複雑さに見合う場合は、管理、ストレージ、サービス、実験用に異なるブリッジまたはVLANを使用します。

ホスト内のストレージ役割を分離する

Proxmoxのバックアップを、ゲストと同じプールや筐体にだけ保存してはいけません。コントローラーまたはホストに障害が発生すると、復元元と復元先の両方が失われます。

クライアントで使うプロトコルは個別に選びましょう。SMBとNFSのガイドを参考に、家庭内の共有とLinuxインフラ用のマウントを分けておきましょう。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

起動と復旧の順序を計画する

再起動後は、ファイルサービス、Kubernetesの永続ボリューム、依存するアプリケーションの起動前に、ストレージが正常な状態になる必要があります。ラボサービスが停止している間も、DNSと管理用アクセスは利用可能な状態を保つ必要があります。

別の小規模なProxmoxストレージ分析では、企業らしさだけを理由にCephを追加せず、ホームサーバーでローカルストレージ、バックアップサーバー、NAS容量を活用できる理由を紹介しています。

Kubernetes VM、ストレージサービス、Proxmoxの起動ディスクを失うケースを、それぞれ別々にテストしましょう。各ケースについて、次に行うことを文書化しておく必要があります。

拡張と停止の境界を設定する

ラボのスケジュールによってメモリーが逼迫するならメモリーを増設し、VMのレイテンシーが上昇するなら高速ストレージを追加しましょう。Proxmoxのメンテナンス中も家族のデータを利用できる状態にしておく必要がある場合は、ストレージを別のホストに分けましょう。

ダウンタイムを許容でき、共有された障害ドメインより学習効果が大きい場合は、サーバーを1台に保ちましょう。実験的な再起動、パススルー設定の変更、容量関連の作業によって家庭でのアクセスに支障が出る場合は、役割を分けましょう。

この設計を高可用性と呼ぶのはやめましょう。サービスをVM内で分離していても、1台の筐体、マザーボード、PSU、管理者の境界は、1つの物理的な障害ドメインのままです。

最終構成のルール

すべてのサービスに明確な役割があり、状態が保護され、アクセス経路が制御され、復元がテスト済みで、トポロジーを分割または拡張するための測定可能な基準があれば、この構成は合格です。