Kubernetes プロビジョナー
Kubernetes プロビジョナーを使うと、いくつかのガイド付きステップで、すぐに使える Kubernetes クラスターを Cockpit から作成できます。Cockpit が仮想マシンを構築し、軽量で完全互換の Kubernetes ディストリビューション（k3s）をインストールし、ネットワークとストレージを設定して、標準の kubectl ツールで接続できるクラスターを提供します。
サーバーを準備したり、インストーラーを実行したり、参加（join）コマンドを手作業でコピーしたりする必要はありません。クラスターの規模、ノードの構成形状、稼働場所を指定するだけで、残りは Cockpit がバックグラウンドで処理し、その間もあなたは作業を続けられます。
このガイドの対象者
このガイドは、Kubernetes クラスターを運用したい方（アプリケーションチーム、プラットフォーム運用者、管理者）向けです。Cockpit の画面で行う操作と、作成後のクラスターの使い方に焦点を当てています。
ライセンス
Kubernetes プロビジョナーを使用するには、Cockpit ライセンスに Kubernetes の権利（エンタイトルメント）が必要です。ライセンスに含まれていない場合は、サブスクリプションに追加して更新されたライセンスをインポートしてから開始してください。このガイドで説明するすべての機能（クラスターの作成、複数のワーカーノードプール、カスタム CPU およびノード構成、プールの追加と削除、スケーリング、アップグレード）は、この 1 つの権利でカバーされます。
はじめる前に
最初のクラスターを作成する前に、2 つの条件が整っている必要があります。管理者が環境をすでに準備済みであれば、クラスターを作成するに進んでかまいません。
- クラスターテンプレート。 Cockpit は準備された Ubuntu テンプレートイメージから各ノードをクローンします。テンプレートには作成時のバージョンに対応する Kubernetes コンポーネントが同梱されているため、ノードは起動時に何もダウンロードすることなく迅速にインストールされます。ウィザードに選択肢として自動的に表示されます。
- 適切なネットワーク。 すべてのノードは、コンピュートクラスター内の物理ホストにまたがる分散ネットワーク上に配置される必要があります。これにより、異なるホストに配置されたノード同士が相互に通信できます。ネットワークの選択を参照してください。
クラスターを作成する
- 左側のインベントリツリーで、コンピュート Cluster（またはそれが属する Datacenter）を右クリックします。
- Kubernetes → New Cluster を選択します。
- Kubernetes プロビジョニングウィザードが 5 つの短いステップで開きます。
インベントリ内の特定の場所から起動したため、ウィザードは対象のデータセンターとコンピュートクラスターを自動的に認識しています。すべてのノード配置はそのコンピュートクラスターのホストに限定されます — ノードが別のデータセンターのホストに配置されることはありません。
ウィザードを完了すると、Cockpit はバックグラウンドでクラスターの構築を開始します。ウィザードは閉じてかまいません。進捗は Tasks パネルで確認できます。クラスターはインベントリに表示され、provisioning から、使用可能になると active へと遷移します。
ステップ 1 — 基本設定
| 項目 | 役割 |
|---|---|
| クラスター名 | クラスターの分かりやすい名前。インベントリ、ノード名、ダウンロードする設定ファイルで使用されます。 |
| ターゲットネットワーク | ノードが接続する分散ネットワーク。分散ネットワークのみが提示されます。ネットワークの選択を参照。 |
| ノード IP アドレス指定 | DHCP（デフォルト）はネットワークからアドレスを自動取得します。Static（静的）はクラスター用に固定範囲を予約できます — 静的ノードアドレスを参照。 |
| Kubernetes バージョン | インストールする k3s のバージョン。テンプレートに組み込まれたバージョンが最速でインストールされます。特に理由がなければ最新を選びましょう。 |
| ネットワークプラグイン（CNI） | Pod 同士の通信方式。ネットワークプラグインを参照。迷ったら Flannel のままで。 |
ステップ 2 — コントロールプレーン
コントロールプレーンはクラスターの「頭脳」です。どの程度の耐障害性が必要かを選びます。
- シングル（1 ノード） — 最もシンプルで軽量。開発・検証に適します。この 1 ノードが失われると、復旧するまでクラスターは利用できません。
- 高可用性（High Availability、3 ノード） — 本番環境に推奨。コントロールプレーンノードの 1 台が障害を起こしてもクラスターは動き続けます。
各コントロールプレーンノードの CPU、メモリ、データストア、ディスクサイズに加え、**配置（Placement）**も設定します。
- Auto-Distribute（自動分散） （推奨） — Cockpit が 3 台の HA ノードを3 つの異なる物理ホストに自動的に分散配置するため、1 台のホスト障害でコントロールプレーン全体が停止することはありません。
- Manual（手動） — コンピュートクラスター内のホストから、各ノードを稼働させるホストを自分で指定します。
2 つの高度な設定セクションはデフォルトで折りたたまれており、ほとんどのクラスターでは初期値のままで構いません。
- CPU モードとトポロジー — 仮想 CPU をノードにどのように提示するか。CPU モードとトポロジーを参照。
- ノードラベルとテイント — コントロールプレーンノードに適用される Kubernetes メタデータ。ノードラベルとテイントを参照。一般的な用途として、通常のアプリケーション Pod がコントロールプレーンに配置されないよう
NoScheduleテイントを追加します。
ステップ 3 — ワーカー
ワーカーは実際のアプリケーションを実行します。クラスターは1 つ以上のワーカーノードプールを持つことができます。各プールは、独自の名前、規模、ハードウェア構成、配置、Kubernetes メタデータを持つ同一構成ノードのグループです。複数プールが必要なケースについては、ワーカーノードプールを参照してください。
各プールで以下を設定します。
| 項目 | 役割 |
|---|---|
| プール名 | プールの短い名前。ノード名はこの名前から生成されます: クラスター prod、プール gpu → ノード名 prod-gpu-1、prod-gpu-2 など。命名規則を参照。 |
| ノード数 | 開始時のノード数。後からいつでも変更できます。 |
| CPU、メモリ、データストア、ディスクサイズ | このプールの全ノードに対するリソース割り当て。 |
| 配置 | Auto-Distribute はコンピュートクラスター内のホスト間でノードを均等分散し、Manual は特定のホストにノードを固定します（GPU などの特殊ハードウェアを搭載したホストに固定する場合に便利です）。 |
| CPU モードとトポロジー （高度） | CPU モードとトポロジーを参照。 |
| ノードラベルとテイント （高度） | ノードラベルとテイントを参照。 |
Add Node Pool をクリックして、異なる設定のプールを追加定義できます。最初のプール名は、名前を変更しない限り workers になります。
ステップ 4 — 認証情報と CSI
- SSH 公開鍵 — 任意。トラブルシューティングのためにノード VM への直接 SSH アクセスが必要な場合は、ここに公開鍵を貼り付けます。クラスターの使用に必須ではありません。Cockpit はクラスター専用のキーペアも自動生成し、クラスターページからダウンロードできます。
- ストレージ階層（CSI） — アプリケーションが永続ストレージを取得する方法を選択します。複数有効にできます。アプリケーション用ストレージを参照。
ステップ 5 — 確認
クラスターの規模、各プールとその設定、使用リソース、各ノードが配置されるホストなどの概要を確認します。Provision をクリックして開始します。ウィザードが閉じ、タスクが開始されます。
ネットワークの選択
ステップ 1 で選択するネットワークは、クラスターが正常に作成できるかどうかに最も大きな影響を与えるため、慎重な検討が必要です。
すべてのノードが互いに到達でき、テンプレートに含まれていないコンポーネントがある場合はセットアップ中にインターネットに到達できる必要があります。Cockpit はコンピュートクラスター内の物理ホスト間でノードを分散配置するため、ネットワークはそれらのホストにまたがっている必要があります — ウィザードが分散ネットワークのみを提示するのはこのためです。単一ホスト上にしか存在しないネットワークは異なるホスト上のノードを接続できないため、一覧には表示されません。
WARNING
ネットワークのゲートウェイは、単にトラフィックを転送するだけでなく、ノードに実際のインターネットアクセスを提供する必要があります。パケットをルーティングするだけでアドレス変換（NAT）を行わないゲートウェイでは、ノードが起動して ping に応答してもダウンロードが失敗し、クラスターのプロビジョニングが完了しません。Kubernetes 用にどのネットワークを使用すべきか不明な場合は、管理者にお問い合わせください。
静的ノードアドレス
デフォルトでは、ノードは DHCP からアドレスを取得します。ネットワークに DHCP サーバーがない場合や、クラスターのアドレスを固定・予測可能にしたい場合は、ステップ 1 で Static を選択し、以下を入力します。
| 項目 | 例 |
|---|---|
| サブネット | 192.168.1.0/24 |
| ゲートウェイ | 192.168.1.1 |
| ネームサーバー | 8.8.8.8, 1.1.1.1 |
| IP 範囲 | 192.168.1.100 – 192.168.1.120 |
Cockpit は範囲内の空いている先頭アドレスから順に各ノードに割り当て、ノードの存続期間中それを維持します。この範囲には、コントロールプレーン、すべてのワーカープール、および将来追加する予定のノードすべてを収容できる十分な空きが必要です。後からのスケールアップや新しいプール追加によって範囲が枯渇する場合、Cockpit は中途半端なノードを残さず、明確なメッセージとともに事前に要求を拒否します。
ネットワークプラグイン（CNI）
ネットワークプラグインは、Pod 同士の通信方式やネットワークセキュリティポリシーの適用可否を制御します。ステップ 1 で一度だけ選択します。
| プラグイン | 最適な用途 | 備考 |
|---|---|---|
| Flannel （デフォルト） | 大半のクラスター、開発環境、シンプルな構成 | 軽量で信頼性が高い。ネットワークポリシー非対応。 |
| Calico | テナント分離を伴う本番環境 | Pod 間トラフィックを制御する Kubernetes NetworkPolicy をサポート。 |
| Cilium | 高性能・高度なネットワーキング | eBPF ベースで、高度な L3〜L7 ポリシーとトラフィック可視性を提供。 |
特定の要件がなければ、Flannel が安全で確実な選択肢です。
ワーカーノードプール
ノードプールとは、同一の設定を共有するワーカーノードのグループです。小規模なクラスターの多くは 1 つのプールで十分ですが、ワークロードごとに異なるマシンスペックが必要な場合は複数のプールを作成します。
- 一般的な
workersプールの隣に、大容量メモリと高速データストアを備えたdatabaseプール。 - GPU 搭載ホストに固定され、GPU ワークロードのみが配置されるようにテイントを設定した
gpuプール。 - クラスターの他の部分がスケールしても小さく安定して維持される、Ingress コントローラーが選択するラベル付きの
ingressプール。
各プールは独自の名前、ノード数、CPU / メモリ / ディスク / データストア、配置、CPU モードとトポロジー、およびラベルとテイントを持ちます。プールは作成後、クラスターの Node Pool タブから管理できます — ノードプールの管理を参照。
命名規則
プール名は各ノードの名前の一部となるため、Kubernetes のホスト名規則に従う必要があります。
- 小文字の英数字と
-。先頭と末尾は英数字であること。最大 40 文字。 - クラスター内で一意であること。
worker、master、control-planeという名前は予約されています（これらを使用すると、デフォルトのワーカープールやコントロールプレーンと名前が衝突するためです）。デフォルトプールにはworkersを、その他のプールにはinfraやcomputeなどの区別しやすい名前を使用してください。
CPU モードとトポロジー
デフォルトでは、各ノードには汎用仮想 CPU が割り当てられます。各プールの CPU モードとトポロジー セクションを使用すると、プロセッサをノードにどのように見せるかを変更できます。これは、プロセッサ命令を検査するワークロードや、ソケット単位でライセンスされるソフトウェアにとって重要です。
CPU モード
| モード | ノードに見える CPU | 使用する場面 |
|---|---|---|
| Host Model | 物理ホストのモデルに一致する CPU | パフォーマンスと可搬性の優れたバランス。 |
| Host Passthrough | 物理ホストの CPU そのもの（すべての拡張機能含む） | 最大のパフォーマンス。特定の CPU 命令を必要とするワークロード。ノードは同一 CPU を持つホスト上に留まる必要があります。 |
| Custom Named Model | 指定した特定の CPU モデル（例: Broadwell-IBRS） | 異なる物理プロセッサを持つホスト間で、同一の CPU 機能を統一したい場合。 |
トポロジーでは、vCPU を ソケット × ダイ × コア × スレッド に細分化できます。これらの積はプールの vCPU 数と一致する必要があります（ウィザードは入力中に計算式を表示し、一致しない場合は先へ進めません）。たとえば 4 vCPU の場合、1 × 1 × 4 × 1（1 ソケット、4 コア）または 2 × 1 × 2 × 1（2 ソケット、各 2 コア）に設定でき、ソケット単位ライセンスのカウント数が変化します。
デフォルトを受け入れる場合はセクションを折りたたんだままにしてください。設定されたモードとトポロジーは、作成後に Node Pool タブでプールごとに確認できます。
ノードラベルとテイント
ラベルは、nodeSelector やノードアフィニティによってワークロードを特定のノードへ誘導するためのキー・バリュータグです。テイントはその逆で、ワークロードが明示的にテイントを許容（tolerate）しない限り、ワークロードをノードから締め出します。これらを組み合わせることで、Kubernetes のスケジューラーに対して「GPU マシンのプール」などの役割を正しく理解させることができます。
各プールの Node Labels & Taints セクションで設定します。
| 設定項目 | フォーマット | 例 |
|---|---|---|
| Label | キー = 値 | tier = database |
| Taint | キー=値:Effect（Effect は NoSchedule、PreferNoSchedule、または NoExecute） | dedicated=gpu:NoSchedule |
ウィザードは入力中に形式を検証します。入力ミスの Effect や不正なキーは構築前に拒否されるため、テイントが欠落したノードが意図せず作成されるのを防ぎます。
作成時に適用
ラベルとテイントは、各ノードがクラスターに初めて参加したときに付与され、後からスケーリングや新規プールによって追加されたノードにも同様に付与されます。既存のプールに対して Cockpit からこれらを変更することはできません。既存ノードのラベルやテイントを変更するには、kubectl label および kubectl taint を使用するか、希望の設定で新しいプールを作成して古いプールを削除してください。
ワークロード側からは、以下のようにプールを指定します。
spec:
nodeSelector:
tier: database
tolerations:
- key: dedicated
operator: Equal
value: gpu
effect: NoScheduleアプリケーションをコントロールプレーンから隔離する
k3s はコントロールプレーンノードにデフォルトでテイントを付与しないため、通常の Pod がスケジューリングされる可能性があります。本番環境のクラスターでは、ステップ 2 でコントロールプレーンに dedicated=control-plane:NoSchedule などのテイントを追加してください。クラスターのシステムコンポーネントは必要な場所に稼働し、アプリケーションはワーカーノードにのみ配置されるようになります。
kubernetes.io/ および k8s.io/ プレフィックス配下のキー（node-role.kubernetes.io/ を含む）は Kubernetes 自身のために予約されており、ここでは設定できません。独自のキーを使用してください。
アプリケーション用ストレージ
データを保持する必要があるアプリケーション（データベース、ファイルアップロードなど）は、**ストレージ階層（Storage tier）**を通じてストレージを要求します。ステップ 4 で必要な階層を有効にします。複数有効にしてアプリケーションごとに使い分けることができます。
| 階層 | 提供される機能 | 使用する場面 |
|---|---|---|
| Local Path （デフォルトで有効） | Pod が稼働するノード上の高速ストレージ | シンプルで高速なストレージ。データは単一ノードに留まるため、Pod が別のノードへ移動すると利用できません。 |
| 共有（NFS） | 多数の Pod が同時に共有でき、ノードをまたいで利用可能 | Pod 間でファイルを共有する必要がある場合（ReadWriteMany）、またはノード間を移動してもデータを維持したい場合。 |
| レプリケーション（Longhorn） | ノード間で複製される高可用性ブロックストレージ | ノード障害に耐える必要があるデータベースなどのステートフルなワークロード。 |
共有（NFS）。 Cockpit に登録済みの NFS データストアを選択すると、サーバーアドレスとエクスポートパスが自動入力されます。外部の NFS サーバーを手動で入力することも可能です。Cockpit はドライバーをインストールする前に、すべてのマウントが行われるクラスター自身のネットワークからサーバーに到達できるかを検証し、クラスターが active と宣言される前に各ノードでドライバーが動作していることを確認します。
レプリケーション（Longhorn）。 レプリカ数（Longhorn が保持する各ボリュームのコピー数、それぞれ異なるワーカー上に配置）を設定します。デフォルトの 3 は、2 台のワーカー障害に耐えられます。レプリカ数はワーカーノード数を超えることはできません。クラスターが満たせないレプリカ数はウィザードによって拒否されます（ボリュームが恒久的に degraded 状態になるのを防ぐためです）。Longhorn はワーカーノード上のみにレプリカを配置し、コントロールプレーンには配置しないよう構成されます。
ストレージの後からの追加
ストレージ階層は作成時に選択します。後からワーカーノードを Longhorn レプリカ数未満に減らすと、十分なワーカーが確保されるまでボリュームは degraded 状態になります。完全な冗長性を回復するにはスケールアップしてください。
クラスターへの接続
クラスターのステータスが active になったら、Kubernetes 標準のコマンドラインツールである kubectl を使用して接続できます。
クラスターの詳細ページを開き、Download Kubeconfig をクリックします。正しいサーバーアドレスが事前に入力された設定ファイルが取得できます。
ファイルを保存し、
kubectlに指定します。bashmkdir -p ~/.kube mv ~/Downloads/kubeconfig-my-cluster.yaml ~/.kube/config-my-cluster chmod 600 ~/.kube/config-my-cluster export KUBECONFIG=~/.kube/config-my-cluster動作を確認します。
bashkubectl get nodes --show-labelsコントロールプレーンノードとワーカーノードが Ready として一覧表示され、各プールに応じたラベルが付与されていることが確認できます。
TIP
毎回 KUBECONFIG を設定する手間を省くには、シェルのプロファイル（~/.bashrc または ~/.zshrc）に export 行を追加してください。
ノードプールの管理
クラスターを開き、Node Pool タブを選択します。各プールはテーブルの行として表示され、名前、ロール、ノード数（うち Ready の数）、各ノードの vCPU / メモリ / ディスク / データストア、および CPU 構成、ラベル、テイントが確認できます。コントロールプレーンプールは参考用として一覧に表示され、Locked とマークされています（ここではスケールや削除はできません）。
各ワーカープールの行には Scale と Remove のアクションがあり、タブには Add Pool ボタンがあります。これら 3 つのアクションは、クラスターが active の間のみ利用可能です。変更処理中は操作の競合を防ぐためアクションが無効化されます。すべての変更はクラスターの Tasks タブおよび Tasks パネルに表示されます。
プールのスケール
- プールの行にある Scale をクリックします。
- 新しい**希望ノード数（Desired node count）**を設定して確定します。
スケールアップは、プールの正確な構成（リソース、CPU モード、ラベル、テイント）を持つ新しいノード VM を追加し、クラスターに自動参加させます。新しいノードが Ready と表示されると、ワークロードの受け入れを開始します。
スケールダウンは安全に（gracefully）実行されます。ノードが削除される前に、Cockpit はまずボリュームの冗長性を維持するためにノード上の Longhorn レプリカを退避し、次にノードを**ドレイン（drain）**して稼働中のワークロードを残りのノードへ移動します。その後初めて VM が削除され、リソースが解放されます。
ノードの追加に失敗した場合
新しいノードを作成できない場合（選択したホストの容量が一時的に不足している場合など）、Cockpit は不完全なノードを自動的にクリーンアップし、プールを実際に到達したノード数に調整します。中途半端なノードが残ることはないため、再度スケールアップを実行して再試行してください。
稼働中のクラスターにプールを追加する
新しいクラスのノードを追加するためにクラスターを再構築する必要はありません。
- Node Pool タブで Add Pool をクリックします。
- ウィザードのステップ 3 と同じ設定（名前、ノード数、リソース、データストア、配置、および任意の CPU モードとラベル/テイント）を入力します。
- 確定します。新しいノードがプロビジョニングされて参加し、プールが新しい行として表示されます。
作成時と同じルールが適用されます: 名前は命名規則に従う必要があり、重複せず、静的アドレスのクラスターでは新しいノードに十分な空きアドレスが必要です。Cockpit は何かを作成する前にこれらすべてを検証します。
プールの削除
- プールの行の Remove をクリックして確定します（削除するとプールのノードは破棄され、元に戻せません）。
- 各ノードはスケールダウンと同様に処理されます: Longhorn レプリカが最初に退避され、ワークロードがドレインされ、その後 VM が破棄されます。最後のノードが消えると、プールはテーブルから消去されます。
最後のワーカープールは保持されます
クラスターは常に少なくとも 1 つのワーカープールを保持します。唯一残っているプールでは Remove アクションは利用できず、API は要求を拒否します。クラスターのワーカーを 0 にしたい場合はそのプールをスケールダウンし、クラスター自体を破棄したい場合はクラスターを削除してください。
クラスターのアップグレード
Cockpit はローリングアップグレードを実行し、アプリケーションの可用性を維持しながら、クラスターを新しい Kubernetes バージョンへ 1 ノードずつ移行します。
- クラスターを開き、Upgrade を選択します。
- 一覧から移行先バージョンを選択します。
- 確定します。Cockpit はまずコントロールプレーンをアップグレードし、次にワーカーを 1 ノードずつアップグレードします。
アップグレード中、各ノードはドレインされ、更新され、稼働状態に戻されてから次のノードの処理が開始されます。アップグレードが完了するまで、クラスターには現在のバージョンと並んで移行先バージョンが表示されます。
進捗はクラスターの Tasks タブに表示されます。タスクの下にある Node Upgrade Jobs リストには、クラスター内のアップグレードコントローラーが処理を進めるノードごとの進捗が表示されます。ノードの View log をクリックすると、そのノードで何が起きたかを正確に確認できます。単一のノードが停止した場合は、このログを確認してください。タスク全体ではノード完了と表示されていても、何を実行したかを正確に把握できるのはログだけです。
クラスター健全性の監視
クラスターが active になると、Cockpit はそれを継続的に監視し、クラスターページに健全性ステータスを表示します。
- Healthy — すべてのノードが存在し、Ready 状態です。
- Degraded — 1 つ以上のノードが Ready ではありません（ノードが停止した、ネットワークが切断されたなど）。クラスターは稼働を続けていますが、容量や耐障害性が低下しています。
ノードの復旧や障害に応じて健全性は自動的に更新されるため、対応が必要かどうかを一目で把握できます。
トラブルシューティング
クラスターが "provisioning" のまま active にならない。 最も一般的な原因はネットワークです。選択したネットワークがコンピュートクラスター内のホストにまたがっており、そのゲートウェイがノードに単なる転送ではなく実際のインターネットアクセスを提供していることを確認してください。起動して ping には応答するもののインストールが完了しないノードは、ほとんどの場合、外部への有効なルーティングがありません。ネットワークの選択を参照してください。
ウィザードでプール名が拒否される。 名前は小文字の英数字と - で構成されている必要があり、worker、master、control-plane は予約語です。命名規則を参照してください。
プールの追加またはスケールアップが "static IP pool is exhausted" で拒否される。 クラスターの静的アドレス範囲に、新しいノード用のアドレスの空きがありません。メッセージには空き数と必要数が表示されます。他のノードを先にスケールダウンするか、より広い範囲で新しいクラスターを作成してください（既存クラスターのアドレス範囲を後から拡張することはできません）。
ウィザードで CPU トポロジーから先へ進めない。 ソケット × ダイ × コア × スレッドの積が、プールの vCPU 数と等しくなる必要があります。ウィザードに表示される計算式が一致するよう、トポロジーまたは vCPU 数を調整してください。
ラベルまたはテイントが拒否された。 テイントは キー=値:Effect 形式で、Effect は厳密に NoSchedule、PreferNoSchedule、または NoExecute のいずれかである必要があります。ラベルのキーと値は Kubernetes の規則（最大 63 文字、英数字、-、_、.）に従う必要があり、kubernetes.io/ または k8s.io/ 配下のキーは予約されています。ウィザードはどの入力が間違っているかを明示します。
ワーカープールの Remove がグレーアウトしている。 それがクラスター唯一のワーカープールであり、クラスターは常に最低 1 つのワーカープールを保持します。置き換える場合は先に別のプールを追加し、ノード数を減らす場合はスケールダウンし、不要な場合はクラスター自体を削除してください。
Longhorn ボリュームが "degraded" と表示される。 ワーカーノード数がレプリカ数よりも少なくなっているため、Longhorn が各コピーを別々のノードに配置できません。ワーカー数が少なくともレプリカ数以上になるまでワーカープールをスケールアップすると、ボリュームは自動的に回復します。
NFS 階層でサーバーが到達不能と報告される。 マウント処理はクラスターのネットワークから行われるため、検証は Cockpit ではなくクラスターのネットワークから実行されます。NFS サーバーがノードから到達可能なアドレスでリッスンしており、そのエクスポートがノードのサブネットを許可していることを確認してください。手元の端末からは到達可能でも、管理インターフェースにしかバインドされていないサーバーはこのチェックに失敗します。
ノードが "NotReady" と表示される、またはクラスターが "Degraded" になる。 ノードの VM が稼働しているか確認してください（停止しているか、ホストがダウンしている可能性があります）。VM が復旧してネットワークに再接続されると、ノードは自動的に再参加し、健全性ステータスも自動的に Healthy に戻ります。
kubeconfig をダウンロードしたのに kubectl が接続できない。KUBECONFIG がダウンロードしたファイルを指していること、およびお使いのマシンがネットワーク経由でコントロールプレーンノードのアドレスに到達できることを確認してください。クラスターのアドレスが変更された場合は、kubeconfig を再ダウンロードしてください。
Pod が別のノードへ移動した後、アプリケーションのデータが失われた。 これは、単一ノードにのみデータを保持する Local Path ストレージ階層で発生します。アプリケーションの移動に追従させる必要があるデータには、共有（NFS） または レプリケーション（Longhorn） 階層を使用してください。アプリケーション用ストレージを参照してください。
関連トピック
- 分散リソーススケジューラー（DRS）と高可用性（HA） — Cockpit がノード VM をホスト間で配置およびバランシングする仕組み。
- 仮想ネットワーク — クラスターノードが接続する分散ネットワーク。
- ストレージとデータストア — クラスターがホストをまたいで稼働できるようにする共有データストア。