クラスター
ワークロードが単一マシンで安定して処理できる範囲を超えた場合、またはノード間スケジューリング、フェイルオーバー、分散ストレージが必要な場合、通常必要なのは単一のサーバーではなく、クラスターです。
クラスターは複数の Kubernetes ノードで構成された実行環境であり、高可用性、水平スケーリング、分散ストレージを必要とするサービスアーキテクチャに適しています。
クラスターが必要な理由
サーバーは、すべてのサービスを単一ノードで実行する場合に適しています。アーキテクチャがシンプルで、コストが予測しやすく、運用負荷が低いです。しかし、システムが以下の機能を必要とし始めた場合、クラスターがより適切な選択肢になります：
- マルチノードスケジューリング：異なるサービスとレプリカを複数のマシンに分散させ、すべてのワークロードが単一のホストに集中するのを避けます。
- ノード障害の耐性：単一ノードがオフラインになった際、ワークロードを他の正常なノードに再スケジュールし、全体的な停止リスクを軽減します。
- 分散ストレージ：複数ノード環境でデータを永続的にマウント・移行する必要がある場合、分散ボリュームは単一マシンのローカルディスクより適しています。
- より高いスケール柔軟性：単一ホストを垂直にアップグレードするだけでなく、ノードを追加することで容量を拡張できます。
要するに、**サーバーは「単一マシンの専有リソース」**を解決し、**クラスターは「マルチマシン連携と高可用性」**を解決します。
サーバーとクラスターの違い
| 項目 | サーバー | クラスター |
|---|---|---|
| ノード数 | 単一ノード | 複数の Kubernetes ノード |
| コンピューティングモデル | 単一マシンデプロイ | ノード間スケジューリング |
| ストレージ | 主に単一マシンのローカルボリューム | ノード間でワークロードに追随できる分散ボリューム |
| 障害の影響 | 障害ノード上のサービスが影響を受ける | ワークロードを他のノードに移行でき、単一障害点の影響を軽減 |
| スケール方法 | 主に単一ホストのスペックアップ | 水平的にノードを追加可能 |
| 最適なユースケース | 中小規模サービス、モノリシックアプリ、安定したワークロード | 高可用性要件、マルチレプリカサービス、分散システム |
固定リソースと単一データノードのみが必要な場合、通常はサーバーで十分です。ノード障害時にサービスが自動的にフェイルオーバーするか、真のマルチノードアーキテクチャが必要な場合は、クラスターを選択してください。
はじめに
- Zeabur から直接新しいクラスターを作成する場合は、クラスターを購入するを参照してください。
- すでに独自の Kubernetes クラスターをお持ちの場合は、既存のクラスターを接続するを参照してください。
- 単一マシンオプションについては、サーバーを参照してください。