ホームラボ用に最適な Kubernetes ディストリビューションはどれですか？

家庭用ラボ向けの最適な Kubernetes ディストリビューションは K3s または MicroK8s です。

3ノードホームラボ向けのKubernetesディストリビューション比較

家庭用ラボ用に最適なKubernetesのバージョンを選ぶ

私は、Ubuntuベースのホームラボで3ノード（16GB RAM、各4コア）に適した、インストールとメンテナンスが簡単で、永続ボリュームとロードバランサーをサポートする自己ホスト型Kubernetesのバリエーションを比較しています。

シナリオ: ホームラボに3つのUbuntuノード（16GB RAM、各4CPUコア）があります。高可用性（HA）やARMサポートは優先順位ではありません。私たちは、インストールが簡単でメンテナンスが容易なKubernetesクラスター（単一ノードまたは3ノード）を望んでいます。これは、**永続ボリューム（PV）やロードバランサー（LB）**サービスをサポートしており、ストレージや外部IPが必要なクラウドネイティブアプリがスムーズに動作するようにする必要があります。HAやARM CPUの互換性要件は不要な3ノードクラスターのオプションに集中します。

kubernetes homelab

以下では、人気のある軽量な [Kubernetes(https://www.glukhov.org/ja/post/2024/10/kubernetes-cheatsheet/ “最も頻繁に使用されるk8sコマンドのリストと説明 - k8sチートシート”) ディストリビューション – K3s、MicroK8s、Minikube、および kubeadm（バニラKubernetes） – とそれらが主要な基準（機能、インストール/メンテナンス、PV/LBサポート、リソース要件、クラスター構築、およびツール）でどう対応しているかを比較します。また、ホームラボのシナリオに基づいてどのディストリビューションを選ぶべきかのいくつかの推奨もあります。

K3s（Rancherの軽量Kubernetes）

主な特徴: K3sは、CNCF認定のKubernetesディストリビューションで、最小限のリソース使用を設計しています（512MB RAMでも動作します）。K3sは、Kubernetesのコントロールプレーン全体を1つのバイナリとプロセスにパッケージ化し、軽量コンポーネント（例：SQLiteデータストアを使用し、etcdではなく、flannelを使用してネットワークを構成）を使用しています。K3sには、ビルトインのイングレスコントローラー（Traefik）やシンプルなサービスロードバランサーなどの合理的なデフォルトが含まれています。K3sは、不要な機能を削除してボリュームを減らすためにレガシーやアルファ機能を削除しています。

インストールとメンテナンスの容易さ: 非常に簡単です – 1行のスクリプト（curl ... | sh）でインストールできます。または、K3supなどのツールを使用することもできます。サーバーはデフォルトのコンポーネントで起動します。ノードを追加するには、サーバーから取得したトークンを使用してK3sエージェントを実行するだけです。アップグレードも簡単です（バイナリを置き換えるか、新しいバージョンのインストールスクリプトを使用します）。別途etcdの設定は不要です（マルチマスターHA構成を選択しない限り）。K3sは、インストール後、最小限の手間で動作するように設計されており、IoTやホームラボで人気があります。
永続ボリュームサポート: ビルトイン。 K3sは、デフォルトでRancherのlocal-path StorageClassを搭載しており、各PVCに対してホストファイルシステム上のPVを動的にプロビジョニングします。つまり、任意のPVCが自動的にノード上のhostPathボリュームを作成して満たされます。これは、単一ノードストレージソリューション（各ボリュームは1つのノードのディスク上）ですが、ステートフルアプリケーションに対してはデフォルトで動作します。より高度なストレージが必要な場合は、RancherのLonghorn（分散ブロックストレージ）などのものを追加することもできますが、ホームラボではデフォルトのlocal-pathプロビジョーナーが通常十分です。
ロードバランサーのサポート: ビルトイン。 K3sには、ServiceLB（以前は“Klipper LB”）という軽量なコントローラーが含まれており、外部クラウドプロバイダーなしでLoadBalancerタイプのサービスにホスト上のIP/ポートを割り当てることができます。LoadBalancerサービスを作成すると、K3sは各ノードにsvc-...という小さなLBポッド（DaemonSet）をデプロイし、ホストポートを使用してトラフィックをサービスに転送します。つまり、K3sはノードのIP（内部または外部）を再利用してLB IPとして使用し、LBポッド内でiptablesルーティングを使用してトラフィックをサービスのClusterIPに送信します。これはゼロ構成で動作します – サービスが「pending」状態になることはありません（バニラK8sでは裸金属上ではそうなります）。トレードオフは、LBの外部IPがノードのIPの1つ（またはすべて）になることです。ポートが空いていることを確認する必要があります。ホームラボの一般的な用途（HTTP/HTTPSポートでいくつかのサービスを公開する）では、これは完全に問題ありません。必要であれば、ビルトインのLBを無効にしてMetalLBを手動でインストールすることもできますが、ほとんどのユーザーは便利なデフォルトを使用します。
リソース要件: 非常に低く、K3sは低性能のハードウェアでも動作します。公式には、サーバーノードに512MB RAMと数百MBのディスクが十分です。実際には、小さなクラスターではコントロールプレーンに数百MBのメモリが使用されることがあります。そのバイナリは100MB未満です。CPUのオーバーヘッドは最小限（K3sはアイドル状態ではMicroK8sよりもわずかに多くのCPUを使用しますが、大きな差はありません）。私たちのノード（各16GB）はK3sを快適に動作させるために十分です。
単一ノード vs マルチノード: どちらにも適しています。 K3sは単一ノード（すべてのコントロールプレーンとワークロードが1台のマシン上に）またはマルチノードで動作できます。3ノード構成では、1つのサーバー（マスター）と2つのエージェントを実行するか、すべての3つのサーバーをHA構成にすることもできます（HAは不要なのでここでは不要）。エージェントの参加はトークンで簡単にできます。K3sのデフォルトSQLiteデータストアは単一サーバーに適しており、マルチサーバーHAでは埋め込みetcdに切り替えることができます（K3sは複数のサーバーノードを起動するときに自動的にこれを行います）。
CLIとUIツール: K3sは他のKubernetesと同様にkubectlを使用して操作します。K3sには独自のkubectl構築が含まれており、k3s kubectl ...を実行するか、K3sのkubeconfigを指す標準のkubectlを使用することもできます。インストールコマンド以外にK3s固有のCLIは存在しません。これは意図的にミニマリスムです。ビルトインのウェブUIは含まれていません（上流のDashboardはデフォルトではインストールされていません）。ただし、K3s上でKubernetes Dashboardや他のツールを手動でデプロイすることもできます。Rancher（同じ会社が提供するGUI管理ツール）もK3s上にインストールできますが、K3s自体には含まれていません。つまり、K3sはコアk8s APIを提供し、必要に応じて追加機能（イングレス、ストレージなど）を追加します（一部はすでにバンドルされています）。

MicroK8s（Canonicalの低メンテナンスKubernetes）

主な特徴: MicroK8sは、Canonicalが提供する軽量なKubernetesディストリビューションで、snapパッケージとして配布されます。これは、単一のコマンドで完全なコンプライアンスKubernetesクラスター（上流バイナリ）をインストールし、単一のマシンまたは小規模クラスターでの使用が簡単（「低メンテナンス」）に設計されています。これは「バッテリーが内蔵されている」アプローチを強調しており、簡単なコマンドで多くのオプション機能を有効にできます。MicroK8sはデフォルトでバニラKubernetesの体験（すべての標準API）を提供しますが、一般的なニーズに合わせた便利なアドオンも含まれています。これは、単一ノードとマルチノードのデプロイメント（ノードを「参加」させることでクラスターを形成）をサポートし、コントロールプレーンにHAモード（3つのマスターでDqlite – 分散SQLite – を使用）も提供しています。

インストールとメンテナンスの容易さ: 同じく非常に簡単です – Ubuntuマシンでsnap install microk8s --classicを実行するだけでKubernetesノードがセットアップされます。これは、すべてのコンポーネントを含む1つのパッケージです。MicroK8sはUbuntuのsnapシステムによって管理されており、これはアップデートが原子的で自動的（Kubernetesバージョンのチャネルを追跡）です。この自動アップデート機能は、他のオプションの中ではユニークです – セキュリティパッチやマイナーバージョンアップグレードをsnap refreshで取得できます。MicroK8sの管理はmicrok8sコマンドを使用して行い、これは機能の有効/無効を切り替えるサブコマンドを持っています。全体的に非常に低摩擦です：コンテナやVMを管理する必要がなく（ホスト上にネイティブに動作）、外部のetcdを構成する必要もありません（内部データストアを使用）。メンテナンスは、必要に応じてsnapを更新し、microk8s.statusでモニタリングすることだけです。
永続ボリュームサポート: アドオン経由で利用可能。 デフォルトでは、MicroK8sは**「hostpath-storage」アドオンを有効にしない限り、PVを自動的にプロビジョニングしません。このアドオンを有効にすると（microk8s enable hostpath-storage）、ホスト上のディレクトリからボリュームを割り当てるデフォルトのStorageClassが作成されます。これは、K3sのlocal-pathと概念的に類似した動的なhostPathプロビジョーナーです。有効にした後、任意のPVCはMicroK8sノード上のhostpath PVにバインドされます。（マルチノードMicroK8sクラスターでは、hostpath PVは1つのノード上に存在します – テストやホームラボ用途には適していますが、分散ストレージには不向きです）。MicroK8sは、ノード間でより高度なストレージを提供するMayastor**や他のストレージアドオンも提供していますが、単純性の観点からhostpathストレージが適しています。注意: アドオンはデフォルトでは有効になっていません（軽量を維持するため）ので、PVCを動作させるために有効にする必要があります。Canonicalは、これは生産用HAには適していない（複製されていない）と述べていますが、ホームラボでは完璧です。
ロードバランサーのサポート: アドオン経由で利用可能。 MicroK8sはデフォルトでロードバランサーをバンドルしていませんが、MetalLBを簡単にアドオンとして提供しています。microk8s enable metallb:<start-IP>-<end-IP>を実行すると、MetalLBがレイヤ2モードでデプロイされ、LAN上のIPプールを指定してLoadBalancerサービスに使用できます。有効にした後、LoadBalancerタイプのサービスは自動的にその範囲からIPを取得し（MicroK8sはLAN上でARP経由でそれをアドバタイズします）、これは裸金属上でのクラウドのような体験を提供します。（MetalLBを有効にしない場合、LoadBalancerサービスは「pending」状態のままになります – MicroK8s自体はロードバランサーを実装していないからです – 上流のKubernetesと同じです）。ホームラボでは、MetalLBは簡単に使用でき、ローカルネットワーク上のサービスにアクセスできます。ネットワーク内で空いているサブネットまたはIP範囲を選択する必要があります。MicroK8sのenableコマンドはセットアップを簡単に行いますが、これは別途のステップです。（K3sはLBで即座に動作しますが、ノードのIP/ポートを使用するという制限があります）。多くのMicroK8sユーザーは、機能的なLBを構築するためにMetalLBを初期設定時に有効にします。
リソース要件: MicroK8sは比較的軽量ですが、K3sよりもやや大きいです。これは、すべてのコアサービス（APIサーバー、コントローラー、スケジューラー、kubelet、etcdまたはDqlite）をネイティブに実行します。アイドル時の使用量は、有効にされたアドオンに応じて通常は~~500–600MB RAMです。Canonicalは~~540MBのメモリを基準としています。アイドル時のCPU使用量は低く、私たちの16GBノードには十分な余裕があります。ディスクスペースの要件は小さく（snap ~200MB＋etcdデータ）。要するに、MicroK8sは中程度のハードウェアでも動作し（ラズベリーパイにも提供されています）、私たちのシナリオではマシンが簡単にそれを収容します。複数のアドオン（ダッシュボード、モニタリングなど）を有効にした場合、リソース使用量はそれに応じて増加します。
単一ノード vs マルチノード: MicroK8sはどちらにも適しています。 単一ノードクラスター（開発マシンや1台のサーバー上）に使用することもでき、ノードを「参加」させることでマルチノードクラスターを作成することもできます。MicroK8sのドキュメントには、ノードを追加するためのコマンドが提供されており（最初のノードからjoinトークンを取得し、他のノードで使用します）。HAなしのマルチノード構成では、1つのノードがプライマリコントロールプレーンになります。3ノードでは、ha-clusterモードを有効にすることもできます（3ノード上でDqliteを使用してコントロールプレーンをHA化します）が、私たちの場合はHAは不要です。単一ノードでも3ノードでも、Kubernetes APIの体験は同じです。マルチノードMicroK8sはK3sのアプローチよりもやや新しいですが、現在は非常に安定しています。Ubuntuのいくつかのボックス上でk8sを最小限の労力で動作させる「マイクロクラウド」を望む場合、これは良い選択肢です。
CLIとUIツール: MicroK8sには**microk8sという非常に使いやすいコマンドラインツールが含まれています。例えば、microk8s enable <addon>はDNS、イングレス、ストレージ、metallb、ダッシュボードなどのさまざまなサービスを切り替え、microk8s statusは何が動作しているかを表示します。また、埋め込みのkubectlも含まれており、microk8s kubectl ...（またはエイリアス）を使用してクラスターに接続できます – これはkubeconfigを設定する必要がないため非常に便利です。UIに関しては、MicroK8sはKubernetes Dashboardをアドオンとして提供します（microk8s enable dashboard）で、標準のウェブUIがデプロイされます。有効にした後、10443ポートまたはプロキシ経由でアクセスできます。MicroK8sには独自のGUIはなく、Kubernetes Dashboardや他のツールに依存していますが、有効化が簡単な点は利点です。要するに、MicroK8sは一般的なタスクに対して1コマンドでの体験を強調し、「ただ動作する」哲学を採用しており、多くの複雑さを抽象化しています（ただし、一部の内部構造は隠されています）。これは、各コンポーネントを手動で設定せずにKubernetesクラスターを構築したいユーザーにとって非常に**ホームラボに適しています。

K3sとMicroK8sの対比: 両者は目標や機能面で非常に似ています – 軽量で簡単で、マルチノード対応。K3sは、追加機能を導入する際にはやや「DIY」傾向があり（Helmチャートや手動のマニフェストに依存）、一方でMicroK8sはCLI経由でビルトインのアドオンを提供します。MicroK8sは、内部的にはより「バニラ」なKubernetes（上流コンポーネント、snapパッケージとしてだけ）であり、K3sはカスタムバイナリとすべてを1つのサービスに統合しています。両者はホームラボに適した選択肢ですが、選択は通常、好みに依存します：Ubuntu/snapと統合された感覚が好まれる場合はMicroK8sが良いですが、より最小限のアプローチでやや手動のコントロールを好む場合はK3sが優れています。（最後に推奨を提供します）。

Minikube（単一ノードのローカルK8s）

主な特徴: Minikubeは、通常開発者PCやノートPC上でローカルでKubernetesを実行するためのツールであり、複数のマシンにまたがる伝統的なクラスターではなく、単一ノードのKubernetesクラスターをVMまたはコンテナで作成します。Minikubeは、Linux、macOS、Windowsをサポートし、さまざまなハイパーバイザ（VirtualBox、KVM、Hyper-V、Dockerドライバなど）をサポートしています。Kubernetes SIGsによってメンテナンスされており、テストや学習に頻繁に使用されます。Minikubeは複数ノード構成にも対応できますが、基本的に単一ノードクラスター用に設計されており（Minikubeの「複数ノード」モードは、同じホスト上でコンテナランタイムを使用して複数ノードを起動するだけで、物理的に別のマシン上に実行するものではありません）。

インストールと使用の容易さ: Minikubeは、単一マシン上で非常に簡単に始められます。minikubeバイナリをインストールし、VMドライバ（またはDocker）が用意されていることを確認し、minikube startを実行するだけで、ローカルのVM/コンテナをセットアップし、その中にKubernetesを起動します。これは、Kubernetesクラスターを初めて起動する際の最も簡単な方法です。CLI（minikube）は、VM（起動、停止、削除）とアドオンを有効にするためのコマンドを提供します。Minikubeはローカル使用に設計されているため、「長時間稼働するデーモン」ではなく、必要に応じて起動し、終了するように使用するのが一般的です（必要に応じてホームラボサーバー上で継続的に稼働させることも可能です）。メンテナンスやアップグレードは簡単です：minikubeのバージョンを更新し、クラスターを再起動するだけです（minikubeは、フラグを使用してKubernetesのバージョンを更新することもできます）。ただし、Minikubeは設計上単一ノードであり、ノードを追加するには同じホスト上で追加のVMインスタンスを起動する必要があります（物理的に別のホストに接続するわけではありません）。したがって、3つの物理ノード上でMinikubeを使用する場合、実質的に3つの独立した単一ノードクラスターを実行することになり、これはおそらく望ましくありません。Minikubeは開発およびテストに最適ですが、複数の物理サーバーにまたがるクラスターを管理するためには意図されていません。
永続ボリュームサポート: 組み込み（hostPath）。Minikubeクラスターは、デフォルトのStorageClassを自動的に含み、hostPathプロビジョナを使用します。実際、Minikubeは、PVCが要求されたときにVM内でhostPath PVを動的に作成する小さなコントローラーを実行しています。これは、PersistentVolumeClaimを作成し、それらがMinikube VMのファイルシステム（通常/tmp/hostpath-provisionerまたは類似の場所）上のストレージを使用して満たされるようにします。これは、基本的なPV使用に必要な設定は不要で、すぐに使用可能になります。たとえば、Minikubeのデフォルトの「standard」StorageClassは、ノード上のhostPathストレージにマッピングされます。ただし、注意点として、Minikube VMを再起動または削除すると、hostPathボリュームが失われる可能性があります（Minikubeは、/data、/var/lib/minikube、/tmp/hostpath*などのディレクトリを再起動時に保持しようとします）。ただし、非生産環境ではこれは問題ありません。より多くのシミュレーションが必要な場合は、MinikubeにはCSI hostpathドライバーアドオンも用意されており、スナップショットをサポートし、マルチノードモードでも動作しますが、これは主に実験用です。結論として、MinikubeはデフォルトでhostPath経由でPVをサポートしており、ステートフルアプリのホームラボテストには十分です。
LoadBalancerサポート: トンネリング（またはMetalLBアドオン）経由でサポート。クラウドでは、LoadBalancerサービスはクラウドLBと外部IPを取得します。Minikubeでは、クラウドプロバイダーがないため、Minikubeは次の2つのメカニズムを提供します：
- Minikubeトンネル: minikube tunnelを別のプロセスで実行することで、ホスト上にネットワークルートを作成し、LoadBalancerサービスにIPを割り当てることができます。これは、ホストを「外部LB」として使用しています。LoadBalancerサービスを作成すると、Minikubeは「外部IP」（通常クラスタのサブネットから）を表示し、minikube tunnelプロセスがそのIPをサービスにルーティングします。これは、トンネルプロセスを継続的に実行する必要があり（通常ルート作成にはroot権限が必要）、手動のステップですが、LoadBalancerサービスがトンネルなしで実行されている場合、Minikubeは「External-IP pending」というリマインダーを出力します（トンネルを開始するまで）。
- MetalLBアドオン: Minikubeの新しいバージョンには、MetalLBアドオンも含まれています。minikube addons enable metallbを実行し、IP範囲を設定（Minikubeは私たちにプロンプトします）することで、MetalLBをMinikubeクラスター内でデプロイできます。これにより、LoadBalancerサービスは、裸金属Kubernetesと同様に処理されます。これは、初期設定後、別途トンネルプロセスを必要としない「クラスタ内」のソリューションです。
両方のオプションは動作し、どちらを使用するかは私たち次第です。1つのサービスを迅速に公開するには、minikube tunnelが迅速で一時的です。より永続的な設定が必要な場合は、MetalLBアドオンを有効にしてLBが実際のIPを取得できるようにします（たとえば、ブリッジネットワークを持つMinikubeに10.0.0.240-250のような範囲を割り当てることができます）。Minikubeは通常単一ノードなので、実質的に「ロードバランサー」は複数ノード間でロードバランシングを行っていません。単一ノードのサービスへの外部アクセスを提供しているだけです。これは開発には問題ありません。ホームラボで、ノードの1つだけを使用し、そのノード上でMinikubeを実行している場合、これらを使用してアプリにアクセスできます。ただし、3つのノードすべてを活用したい場合は、MinikubeのLBアプローチはそのシナリオには意図されていません。
リソース要件: Minikube自体は軽量ですが、通常はVM内でフルな単一ノードKubernetesを実行するため、リソース使用量は通常の小さなクラスターと同様です。VMの最小推奨は2GB RAMと2CPUです。デフォルトでは、Minikubeは通常VMに2GB RAMを割り当てます。私たちの場合、1マシンあたり16GBなので、これは軽いです。アイドル状態のMinikube（Kubernetes）は、約600MBメモリを使用する可能性があります。考慮すべき点は、Minikubeが私たちのOSの上に実行されること（ハイパーバイザ経由のVMまたはDockerコンテナとして）で、これにより若干のオーバーヘッドが発生します。ホームラボサーバーでは、“none"ドライバを使用してMinikubeを実行することもできます（これは、ホストに直接Kubernetesコンポーネントをインストールします）。ただし、“none”（いわゆるbare-metal）ドライバは、kubeadmを使用するノードに非常に似ており、手動のクリーンアップが必要なので、あまり人気ではありません。大多数はVMまたはDockerドライバを使用します。要約すると、私たちのホームラボノードのいずれもMinikubeを簡単に実行できます。唯一の制限は、Minikubeがすべての3つのノードのリソースを使用しない点です（実験的な1ホスト内でのマルチノードを使用しない限り、単一ホストに限定されます）。
単一ノードとマルチノード: 主に単一ノード。Minikubeは、1台のマシン上の単一ノードクラスターに最適です。複数ノードをシミュレートする機能もあります（例：minikube start --nodes 3でDockerドライバを使用すると、1台のホスト上で3つのKubernetesノードをコンテナとして起動します）。ただし、これはテスト用にのみです。Minikubeを使用して、3台の物理サーバーにまたがる実際のマルチノードクラスターを作成することはできません。3台のマシンがある場合は、3つの独立したMinikubeインスタンス（1つのクラスター内ではなく）を実行する必要があります。これは、実際のクラスター体験とは異なります（ノード同士はお互いに認識しません）。したがって、3つのノードを1つのKubernetesクラスターで使用したい場合は、Minikubeは推奨されません。1台のマシン（PCまたは1台のサーバー）のみを使用し、その上にK8sを実行したい場合に最適です。Kubernetesの基本を学ぶことやローカル開発にも非常に適しています。
CLIおよびUIツール: minikube CLIが主なインターフェースです。クラスターの起動/停止に使用し、minikube dashboardはKubernetesダッシュボードを有効にし、ブラウザで開きます。minikube addons enable <addon>は、イングリス、メタラブ、メトリクスサーバーなどのオプションコンポーネントを有効にします。Minikubeは、kubectlへのアクセスを自動的に設定します（minikubeというコンテキストをkubeconfigに設定します）。UIについては、前述の通り、dashboardコマンドでKubernetesダッシュボードに簡単にアクセスできます。Minikubeには独自のウェブUIはなく、標準ツールに依存しています。デバッグも簡単です。必要に応じてminikube sshでノードVMにアクセスできます。全体的に、単一ノードのシナリオでは非常に使いやすいツールが提供されています。

Kubeadm（私たちのノード上のVanilla Kubernetes）

主な特徴: Kubeadmは「ディストリビューション」ではなく、Kubernetesクラスターをからっさで作成するための公式ツールキットです。Kubeadmを使用すると、私たちのマシン上で標準のアップストリームKubernetesコンポーネントをデプロイします。これは、ディストリビューションが含む余分な機能を除いて、ベストプラクティスに従って「自分たちでクラスターを構築」する方法です。Kubeadmは、制御プレーンノード（etcd、APIサーバー、コントローラーマネージャー、スケジューラーを実行）を設定し、ワーカーノードをそれに参加させます。結果として、クラウドVM上で得られるものと同様の完全な標準Kubernetesクラスターが得られます。このアプローチは、ネットワークプラグイン、ストレージプロビジョナーなどの選択肢を含め、完全な制御と柔軟性を提供しますが、初期の手動作業と知識も最も多く必要とします。これは、生産環境やKubernetes内部の理解を学ぶために頻繁に使用されます。

インストールとメンテナンスの容易さ: 他のものと比較して、kubeadmは最も手間がかかるです。各ノードで依存関係（コンテナランタイム、kubeadm、kubelet、kubectlなど）を手動でインストールする必要があります。その後、マスター上でkubeadm initを実行し、ワーカー上でkubeadm joinを実行します（トークンが与えられます）。また、初期化後にはCNI（ネットワークプラグイン）を設定する必要があります（Calico、Flannelなど）（kubeadmはデフォルトでインストールしません）。これらすべての手順はよく文書化されており（プロセスは難しくはないが、多くのステップがあります）、kubeadmは私たちにクラスターの初期設定を提供しますが、アドオンの管理は私たちに期待されます。メンテナンスに関しては、アップグレード（kubeadmにはアップグレードコマンドがありますが、ノードをドレインし、バイナリを更新するなど、手動で行う必要があります）や、etcdの健康状態、証明書の更新なども私たちの責任です。要約すると、kubeadmは強力だが手動です。これは「難しい方法」と呼ばれることがありますが（ソースから構築するほどではありません）、ホームラボのハッカーとして学びを楽しむには、kubeadmはKubernetesを深く理解するための素晴らしい方法です。ただし、もし「簡単でメンテナンスが容易」が優先事項であれば、kubeadmはK3s/MicroK8sよりも手間がかかるでしょう。それぞれのアップグレードや変更には手作業が必要です。ただし、一度設定すれば、それは本格的なもの：標準Kubernetesクラスターで、隠れた抽象化はありません。
永続ボリュームサポート: デフォルトではなし（手動で追加する必要あり）。kubeadmでインストールされたクラスターは、ほぼ空白のKubernetesです。デフォルトのStorageClassや動的プロビジョナーは、デフォルトでは含まれていません。クラウド環境では、クラウドプロバイダーが通常デフォルトのStorageClass（AWS EBSなど）を提供しますが、ホームラボの裸金属環境では、私たち自身のソリューションをインストールする必要があります。一般的なアプローチ：
- hostPathプロビジョナー: K3s/Minikubeが行っていることと同様に、Rancher Local Pathプロビジョナー（小さなコントローラー＋StorageClassでhostPath PVを作成）をインストールできます。これは、単純なアドオン（YAMLマニフェストのみ）で、ローカル動的ストレージを提供します。
- NFSまたはNAS: 一部のホームラボユーザーは、NFSサーバー（またはNAS）を設定し、静的PVまたはNFS CSIドライバを使用してプロビジョニングします。
- OpenEBS/Longhorn/Ceph: 分散ストレージをノード間で実行したい場合は、LonghornやCeph RBDをRook経由でデプロイするなどの複雑なオプションもあります。これらは、より多くのリソースと複雑さを必要とします。
主なポイントは、kubeadmが「ストレージを解決」してくれるわけではないということです。私たちが決定し、設定する必要があります。もし容易さが優先事項であれば、最も簡単な方法は、hostPathプロビジョナーをデプロイするか、NFSを使用することです。たとえば、Rancherのlocal-pathプロビジョナーは、いくつかのkubectl applyコマンドでインストールでき、K3sの動作（/var/lib/rancher/以下のノードにボリュームを作成）を模倣します。ただし、これは手動のステップです。それを行うまでは、作成したPVCは常にPending状態に残ります（Kubernetesにデフォルトのプロビジョニングが存在しないからです）。したがって、kubeadmは確かに永続ボリュームをサポートします（これは完全なKubernetesです）が、動的PVのサポートは私たちが設定にかける努力に応じて良いだけです。
LoadBalancerサポート: デフォルトではなし（手動で追加する必要あり）。ここも同様の話です：伝統的なオンプレミスクラスターでは、組み込みのLoadBalancer実装はありません。通常のkubeadmクラスター上でLoadBalancerタイプのサービスを作成すると、コントローラーをデプロイするまでずっとpending状態のままです。一般的な解決策は、MetalLBを自分でインストールすることです。MetalLBはマニフェストまたはHelmチャート経由でインストールできます。IP範囲を設定し、それらのIPをLoadBalancerサービスに割り当てます（MicroK8sと同様に）。kubeadmクラスターにMetalLBをインストールするためのガイドは多数存在します。また、一部のユーザーはkube-vipを使用して、制御プレーンVIPとサービスLBを設定しますが、MetalLBはサービスにシンプルです。本質的に、kubeadmでは、私たちのニーズに合ったロードバランシングメカニズムを設定する自由（または負担）があります。何も設定しない場合、外部アクセスにはNodePortサービスに限定されます。ホームラボでは、MetalLBのインストールが強く推奨されます。これは簡単で、クラウドのようなサービスIP機能を提供します。ただし、これはまた、私たちが行う必要のある追加のステップです（K3sはデフォルトで動作し、MicroK8sは単純な有効化で動作します）。
リソース要件: 標準Kubernetesは、カットダウンされたバージョンよりも若干重いです。各ノードはkubeletとkube-proxyを実行し、マスターはetcdと制御プレーンコンポーネントを実行します。単一の制御プレーンノードは2GB RAMでも動作しますが、その上にポッドを実行する場合、少し余裕があると快適です。Padokガイドでは、マスターに2GB、ワーカーに2GBが最小限とされています。私たちのシナリオ（ノードあたり16GB）では、これは問題ありません。アイドル状態のetcdとAPIサーバーは、それぞれ数百MBのメモリを使用する可能性があります。kubeadmクラスターとMicroK8sの実行時の違いは大きくありません。MicroK8sは、実質的に同じコンポーネントです。違いは、デフォルトで何が実行されているかです（MicroK8sはDNSやストレージをデフォルトで有効にしている可能性がありますが、kubeadmではそれらをインストールする必要があります）。リソース面では、kubeadmは私たちが設定するように、非常にスリムまたは重い状態に設定できます。何も追加でインストールしない場合、非常にスリムな状態になります。典型的な設定（CoreDNS、ダッシュボードなどを追加）では、システムオーバーヘッドで約1GBが使用されることが予想されます。私たちは十分なRAMを持っているため、リソースは問題ではありません。これは、CPU/RAMではなく、管理に必要な人間の時間とリソースの問題です。
単一ノードとマルチノード: Kubeadmはどちらも行え、完全な柔軟性があります。単一ノードクラスターを初期化し（マスターがワークロードを実行できるように、kubeadmにマスターをアンタインティングするように指示することもできます）、または1つのマスターと2つのワーカー（一般的な3ノード構成）を持つこともできます。3つのマスターと3つのワーカーを設定することも可能です。私たちのケースでは、HAが不要なので、1つの制御プレーンノードと2つのワーカーを持つkubeadm構成が可能性が高いです。これは、機能的な3ノードクラスターを提供します。マルチノードのプロセスはよく文書化されており、本質的にはすべてのノードにKubernetesをインストールし、1つを初期化し、他のノードを参加させるだけです。結果は、管理されたクラスターまたは他のディストリビューションが提供するものと同様です：私たちの3つのノードはkubectl get nodesなどで表示されます。したがって、kubeadmは「3つのノードすべてを使用できる」要件を満たしています。
CLIおよびUIツール: kubeadmでは、kubeadm自体が唯一の特別なCLIであり、セットアップおよび（後で）アップグレードステップに使用されます。日常的な運用では、kubectlを使用してクラスターを管理します。Kubernetesが提供するもの以外の統合管理CLIはありません。UIに関しては、デフォルトでは何も含まれていません。Kubernetesダッシュボードや他のツールを手動でデプロイできます（他のクラスターと同じように）。本質的に、kubeadmは私たちに空白のKubernetesキャンバスを提供します。私たちがその上に描くことが必要です。これは、ダッシュボード、イングリスコントローラー、ストレージクラスなどの便利なものをインストールすることを含みます。Lens、Octantなどの多くのサードパーティのダッシュボードも、GUI管理体験を希望する場合、kubeadmクラスターに接続できますが、これらは外部ツールです。要約すると、kubeadmでは、純粋なKubernetes環境が得られ、最大の柔軟性がありますが、すべてを設定する必要があるという点で、生産クラスターのように扱う必要があります。
Kubespray また、KubernetesをKubesprayでインストールする方法も参照してください。

サイドバイサイド比較表

以下は、4つのオプションを主要なポイントで比較した概要です：

項目	K3s (軽量なRancher K8s)	MicroK8s (Canonicalの「低運用負荷」K8s)	Minikube (単一ノード開発用K8s)	Kubeadm (純粋なKubernetes)
インストール	1行のインストールスクリプト（単一バイナリ）。システムサービスとして動作。非常に迅速なセットアップ。	Ubuntuでのsnap経由のワンコマンドインストール。すべてのコンポーネントが含まれている。`microk8s join`でクラスタリングが容易。	minikube CLIをインストールした後、`minikube start`でローカルVM/コンテナを起動。クロスプラットフォームで初心者向け。	各ノードにkubeadm、kubeletなどを手動でインストール。`kubeadm init` + `kubeadm join`を実行し、前提条件を満たす必要があります。複数のステップ（ランタイム、ネットワークプラグインなど）が含まれます。
メンテナンスとアップグレード	手動でのアップグレード（バイナリを置き換えるか、インストールスクリプトで新しいバージョンを使用）。単一のバイナリなので簡単で、管理すべきことはほとんどない。自動アップデートはなし。	snap refreshで更新（自動化可能）。アドオンやクラスタサービスは`microk8s` CLIで管理可能。通常は低運用負荷で、自動アップグレードが利用可能。	開発用にクラスタを削除/再作成するのが簡単。minikubeバージョンを更新しクラスタを再起動することでアップグレード。一時的な使用に適しており、インプレースアップグレードの耐久性にはあまり焦点を当てていない。	ユーザー自身がすべてのアップグレードを担当。`kubeadm upgrade`を使用するが、ノードをドレインし、etcdのバックアップなどを処理する必要がある。完全なコントロールが可能だが、すべての作業はユーザー自身が行う（自動更新はなし）。
K8sバージョン	上流にほぼ追随（エッジリリースでよく使用）。CNCF準拠。一部の機能はデフォルトで無効（アルファ/レガシ）。	上流リリースに追随（1.27、1.28などのsnapチャネル）。CNCF準拠。本質的に vanilla K8sバイナリ。	起動時にKubernetesバージョンを選択可能（例: `minikube start --kubernetes-version=v1.27`）。デフォルトは最新の安定版。	任意のバージョンをインストール可能（特定のkubeadm/kubeletバージョンをインストール）。完全な上流Kubernetes – バージョンとアップグレードタイミングはユーザー自身が決定。
デフォルトの機能	デフォルトでバンドル: Flannel CNI、CoreDNS、Traefik ingress、サービスLB、ローカルストレージクラス、metrics-serverなど（必要なければすべて無効化可能）。機能するために必要な最小限の設定。	デフォルトは最小限: DNSは通常有効、他の機能はオプション。ingress（NGINX）、MetalLB、hostpathストレージ、ダッシュボードなどの1コマンドでアドオンを追加可能。3ノード以上でHAモードを有効化可能。	VMにバンドル: 通常はDocker/containerdランタイム、Kubernetesとデフォルトのアドオン（StorageProvisioner、DNSなど）が含まれる。ingress、ダッシュボードなどのオプションアドオンはCLIで切り替え可能。デフォルトではマルチノードはサポートしない。	ボトムアップ: コアKubernetes以外のものは何も含まれていない。ingress、デフォルトストレージやLB、ダッシュボードはインストールするまでない。CNIプラグインを選択（インストールする必要がある）。本質的にはDIYクラスタ。
永続ボリュームサポート	はい – オールインワン。 Rancherの local-path ダイナミックプロビジョナが含まれており、任意のPVCに対してノード上のhostPath PVを作成する。デフォルトのStorageClass “local-path” はローカルディスクを自動的に使用する。	はい – シンプルなアドオン。 `hostpath-storage`を有効化することで、hostPathを使用したダイナミックPVのデフォルトStorageClassが得られる。有効化するまではデフォルトのPVプロビジョナは存在しない。アドオンはマルチノード生産には不向きだが、ホームラボでは問題ない。	はい – オールインワン。デフォルトStorageClassはminikube VM内でのhostPathプロビジョナを使用。PVCは単純なコントローラーによってノードのファイルシステム上にhostPath PVを作成し、データは再起動時に特定のディレクトリに保存される。	いいえ（手動）。デフォルトのプロビジョナは存在しない – クラスタには最初にStorageClassが存在しない。ユーザーはストレージソリューション（例: local pathプロビジョナ、NFS、Cephなど）をインストールする必要がある。基本的なアプローチ: hostPathプロビジョナのYAMLを適用してK3s/Minikubeが行っていることと同様の動作を模倣。それまではPVCは保留状態。
ロードバランサーのサポート	はい – 内蔵されたServiceLB。 K3sの servicelb コントローラー（Klipper）は、LoadBalancerサービスを監視し、ノード上でポッドを展開してそれらを公開する。ノードのIPとホストポートを使用してトラフィックを転送。設定不要で即座に動作。小さなクラスタに適しており、ノードの内部/外部IPを使用してサービスを公開。	はい – MetalLBアドオン経由。 IP範囲を指定して`metallb`を有効化することで、bare metalでの真のレイヤ2ロードバランサーが提供される。デフォルトでは有効化されていない。有効化後、各LoadBalancerサービスは私たちのプールからユニークなIPを取得する。初期設定（IP範囲）が必要。	はい – tunnelまたはMetalLB経由。クラウドLBは存在しないが、`minikube tunnel`を実行してLoadBalancerサービスに外部IPを割り当てることも可能（ホスト上にルートを作成）。または、minikubeでMetalLBアドオンを有効化して自動LB IPを割り当てることも可能。デフォルトではLBサービスは「保留」状態になるまで、これらの方法のいずれかを使用する必要がある。	いいえ（手動）。内蔵されたLBは存在しない。通常はMetalLBを手動でインストールしてbare metal LB機能を提供する。MetalLB（または他のLBコントローラー）をセットアップ後、LoadBalancerサービスが動作する。それがないとLBサービスは永遠に保留状態のまま。
ネットワーク（CNI）	デフォルト = Flannel（オーバーレイネットワーク）。K3sは必要に応じてCNIを置き換えることも可能。CoreDNSがデプロイされてクラスタDNSが提供される。Traefik ingressはデフォルトで含まれている（無効化可能）。	デフォルト = Calico（HAモードの最近のバージョンでは）または単純なデフォルト。（MicroK8sは歴史的にflannelを使用していたが、現在はCalicoを使用して厳密な制限をかける傾向にある）。CoreDNSはデフォルトで有効。NGINX ingressはアドオン経由で利用可能（`microk8s enable ingress`）。	デフォルト = kubenet/bridge（ドライバに依存；通常は単純なNATネットワークを使用）。CoreDNSはデフォルトで動作。必要に応じてNGINX ingressアドオンを有効化可能。ネットワークは単一VMに限定され、NodePortは`minikube ip`経由でアクセス可能。	CNIの選択。 KubeadmはどのCNIプラグインもインストールしない – 我々は1つをデプロイする必要がある（Calico、Flannel、Weaveなど）。我々は完全なコントロールを持つ。多くのガイドでは、kubeadm init後、CalicoのYAMLを適用している。CoreDNSはkubeadmによってデフォルトでクラスタDNSとしてインストールされる。Ingressコントローラー – 自分で選択しインストールする（例: NGINXまたはTraefikをマニフェスト/Helm経由で）。
マルチノードクラスタリング	はい。マルチノード向けに設計。トークンで簡単に参加可能。外部DBまたは埋め込みetcdを使用してマルチマスターを構成可能。2-3ノード以上のホームラボに最適。追加の依存関係は必要なし – K3sには独自のクラスタリングが内蔵されている。	はい。複数のMicroK8sノードをクラスタリング（`microk8s join`で）。3以上のマスターでHAを有効化（Dqlite）。非常に簡単にクラスタを構成可能、特にすべてのノードがUbuntu + snapを実行している場合。	いいえ（物理的）。単一ノードで設計。1台のマシン上で複数ノードをシミュレート（Dockerコンテナ内での複数ノード）可能だが、1つのクラスタで複数の物理ホストを跨ぐことはできない。別のMinikubeインスタンスを使用して別のクラスタを構成する必要がある。	はい。マルチノードを完全にサポート（それが目的）。1マスター + 複数ワーカー、または複数マスター（ただしkubeadmのHA構成は複雑）を持つことも可能。クラスタサイズに組み込みの制限はない。
リソースオーバーヘッド	非常に低。コントロールプレーンはアイドル時で~<0.5 GBメモリ。コントロールプレーンは単一プロセスで、小さなフットプリント。CPU効率は良好（ただし、いくつかのレポートによると、MicroK8sよりアイドル時に若干多くのCPUを使用する可能性がある）。低電力環境や多くの余剰容量がある環境に最適。	低。コントロールプレーンアイドル時で~0.5–0.6 GBメモリ。K3sよりやや高いベースメモリだが安定している。Ubuntu snapを使用（多少のオーバーヘッドがある可能性あり）。フルKubernetesに比べて依然として軽量。	中程度。VMデフォルトは2 GB割り当て（アイドル時で~0.6 GB使用）。フルの単一ノードKubernetesとVMレイヤーが動作。16 GBシステムでは問題ないが、1台のマシン上で小さなクラスタのリソースを消費している。	中程度。1マスター + 1ワーカーで通常のアドオンを追加した後、アイドル時で~1 GB使用。各追加ノードはわずかなオーバーヘッド（kubelet、プロキシのみ）を追加。クラウドVMで同等のサイズのVMを実行するのと同様。3ノードで16 GB各ノードの場合、オーバーヘッドは文脈上無視できる。
CLIツール	`k3s`を使用してインストールおよび`kubectl`のラッパーとして使用（または標準の`kubectl`を使用）。別途の管理CLIは存在しない（K3sは主に「セットして忘れる」）。いくつかのヘルパースクリプト（例: `k3s-killall.sh`）。RancherのGUIを別途追加することも可能。	リッチな`microk8s` CLI: 例: `microk8s enable/disable <addon>`、`microk8s status`。また`microk8s kubectl`も含まれる。基本的なタスクを簡略化するために設計されており、システムマニフェストの直接編集は必要ない。	`minikube` CLIを使用してクラスタの起動/停止、設定とアドオンの管理、情報を取得（IP、サービスURL、ログなど）。また`minikube dashboard`などの便利コマンドも提供。クラスタへのアクセスは`kubectl`を使用（minikubeコンテキストの設定は自動で行われる）。	初期設定とアップグレードには`kubeadm`のみを使用。日常的な運用は標準の`kubectl`および他のKubernetesツールを使用。ディストリビューション固有のCLIはブートストラップ以外には存在しない。`kubectl`やOSツールを使用してメンテナンスを行う。
UI / ダッシュボード	デフォルトでは含まれていない。Kubernetesダッシュボードを手動でインストールしたり、外部ツールを使用したりする（Rancher固有のものでない限り）。K3sはヘッドレス操作に焦点を当てている。	デフォルトでは含まれていないが、1コマンドで利用可能: `microk8s enable dashboard`で標準のダッシュボードUIをデプロイ。`microk8s dashboard-proxy`でクラスタに簡単にアクセス可能。CanonicalのLens GUIと統合することも可能（LensはMicroK8sに直接アクセス可能）。	デフォルトでは有効化されていないが、`minikube dashboard`コマンドでダッシュボードのWeb UIをデプロイして開くことができる。これはローカル開発のための便利な機能 – 1コマンドでGUIでワークロードを確認できる。	含まれていない。ダッシュボードをインストールしたい場合はYAMLを適用する必要がある。それ以外はCLIまたはサードパーティのダッシュボードアプリを使用する。ホームラボでは、ダッシュボードをインストールし、NodePortを作成するか、`kubectl proxy`を使用して表示することもある。KubeadmはUIについては関与しない。

出典: 上記のデータは、公式ドキュメントおよびユーザーガイドから統合されたものです。例えば、メモリフットプリントはMicroK8s自身の比較から、K3sのデフォルトストレージはK3sドキュメントから、K3sのサービスLBの動作はK3sドキュメントから、MicroK8sのアドオン詳細はCanonicalドキュメントから、MinikubeのPVとtunnelはKubernetesドキュメントから、そして一般的な経験レポートから。詳細な引用については「参考文献」をご覧ください。

3ノードホームラボ向けのKubernetesディストリビューション比較

K3s（Rancherの軽量Kubernetes）

MicroK8s（Canonicalの低メンテナンスKubernetes）

Minikube（単一ノードのローカルK8s）

Kubeadm（私たちのノード上のVanilla Kubernetes）

サイドバイサイド比較表

おすすめ

Kubernetesディストリビューションの公式サイト

その他の役に立つリンク