Kubernetes プロビジョナー
Kubernetes プロビジョナーを使うと、いくつかのガイド付きステップで、すぐに使える Kubernetes クラスターを Cockpit から作成できます。Cockpit が仮想マシンを構築し、軽量で完全互換の Kubernetes ディストリビューション（k3s）をインストールし、ネットワークとストレージを設定して、標準の kubectl ツールで接続できるクラスターを提供します。
サーバーを準備したり、インストーラーを実行したり、参加（join）コマンドを手作業でコピーしたりする必要はありません。クラスターの規模と稼働場所を指定するだけで、残りは Cockpit がバックグラウンドで処理し、その間もあなたは作業を続けられます。
このガイドの対象者
このガイドは、Kubernetes クラスターを運用したい方（アプリケーションチーム、プラットフォーム運用者、管理者）向けです。Cockpit の画面で行う操作と、作成後のクラスターの使い方に焦点を当てています。
はじめる前に
最初のクラスターを作成する前に、2 つの条件が整っている必要があります。管理者が環境をすでに準備済みであれば、クラスターを作成するに進んでかまいません。
- クラスターテンプレート。 Cockpit は用意された Ubuntu のテンプレートイメージから各ノードをクローンします。通常はあらかじめ提供されており、ウィザードに選択肢として自動的に表示されます。
- 適切なネットワーク。 クラスター内の各ノードは、互いに到達でき、かつインターネットに到達できる必要があります（初回起動時に Kubernetes コンポーネントをダウンロードするため）。選び方はネットワークの選択を参照してください。
クラスターを作成する
- 左側のインベントリツリーで、Cluster を右クリックします。
- Kubernetes → New Cluster を選択します。
- Kubernetes プロビジョニングウィザードが 5 つの短いステップで開きます。
ウィザードを完了すると、Cockpit はバックグラウンドでクラスターの構築を開始します。ウィザードは閉じてかまいません。進捗は Tasks パネルで確認できます。クラスターはインベントリに表示され、provisioning から、使用可能になると active へと状態が変わります。
ステップ 1 — 識別情報とバージョン
| 項目 | 役割 |
|---|---|
| クラスター名 | クラスターの分かりやすい名前。インベントリやダウンロードする設定ファイルで使われます。 |
| 説明 | 任意のメモ（自分用の参考）。 |
| ネットワーク | ノードが接続する仮想ネットワーク。ネットワークの選択を参照。 |
| Kubernetes バージョン | インストールする k3s のバージョン。一覧は常に最新に保たれます。特に理由がなければ最新を選びましょう。 |
| ネットワークプラグイン（CNI） | Pod 同士の通信方式。ネットワークプラグインを参照。迷ったら Flannel のままで。 |
ステップ 2 — コントロールプレーン
コントロールプレーンはクラスターの「頭脳」です。どの程度の耐障害性が必要かを選びます。
- シングル（1 ノード） — 最もシンプルで軽量。開発・検証に適します。この 1 ノードが失われると、復旧するまでクラスターは利用できません。
- 高可用性（High Availability、3 ノード） — 本番環境に推奨。コントロールプレーンノードの 1 台が障害を起こしてもクラスターは動き続けます。
各コントロールプレーンノードの CPU、メモリ、データストア、ディスクサイズに加え、**配置（Placement）**も設定します。
- Auto-Distribute（自動分散） （推奨） — Cockpit が 3 台の HA ノードを3 つの異なる物理ホストに自動的に分散配置するため、1 台のホスト障害でコントロールプレーン全体が停止することはありません。
- Manual（手動） — 各ノードを稼働させるホストを自分で指定します。
ステップ 3 — ワーカーノード
ワーカーは実際のアプリケーションを実行します。開始時の台数と、各ノードの CPU、メモリ、データストア、ディスクサイズを設定します。ワーカー数は後からいつでも変更できます — クラスターをスケールするを参照。
配置はコントロールプレーンと同様です。Auto-Distribute はワーカーをホスト間で均等に配置し、Manual は特定のホストにワーカーを固定します（GPU など特殊なハードウェアを持つホストがある場合に便利）。
ステップ 4 — アクセスとストレージ
- SSH 公開鍵 — 任意。トラブルシューティングのためにノード VM へ直接 SSH 接続したい場合に、公開鍵を貼り付けます。クラスターの利用には必須ではありません。
- ストレージ階層（CSI） — アプリケーションが永続ストレージを得る方法を選びます。複数を有効にできます。アプリケーション用のストレージを参照。
ステップ 5 — 確認と作成
概要（クラスターの規模、使用するリソース、各ノードが配置されるホスト）を確認します。Provision をクリックすると開始されます。ウィザードが閉じ、タスクが始まります。
ネットワークの選択
ステップ 1 で選ぶネットワークは、クラスターが正しく形成できるかどうかに最も大きく影響するため、少し検討する価値があります。
各ノードは同じ到達可能なネットワーク上にあり、IP アドレスを自動（DHCP）で取得し、セットアップ中にインターネットへ到達できる必要があります。よくある 2 つのケース:
- ホストをまたいで広がる共有／ルーテッドネットワーク — ノードを複数の物理ホストに分散しても互いに通信できます。ホスト障害に耐える高可用性クラスターには、これが正しい選択です。
- ホストローカルの NAT ネットワーク — この種のネットワークは 1 台のホスト上にのみ存在します。これを選ぶと、ノード同士が通信できるように、Cockpit は自動的にクラスターのすべてのノードをそのホストに配置します。開発や自己完結型クラスターには問題ありませんが、クラスターの運命はそのホストと一蓮托生になります。
WARNING
ホストをまたぐ共有アドレスを持たず同一ホスト上の VM のみを接続する分離ネットワークや、インターネットにアクセスできないネットワークは避けてください。そのようなネットワーク上のノードは互いを見つけられず、Kubernetes コンポーネントもダウンロードできないため、クラスターのプロビジョニングが完了しません。
どのネットワークを使うべきか分からない場合は、Kubernetes 用に想定されているネットワークを管理者に確認してください。
ネットワークプラグイン（CNI）
ネットワークプラグインは、Pod 同士の通信方式と、ネットワークセキュリティポリシーを適用できるかどうかを制御します。ステップ 1 で一度だけ選択します。
| プラグイン | 適した用途 | 備考 |
|---|---|---|
| Flannel （デフォルト） | ほとんどのクラスター、開発、シンプルな構成 | 軽量で信頼性が高い。ネットワークポリシーはなし。 |
| Calico | テナント分離が必要な本番環境 | Kubernetes NetworkPolicy に対応し、Pod 間トラフィックを制御できます。 |
| Cilium | 高性能・高度なネットワーク | eBPF ベースで、豊富な L3〜L7 ポリシーとトラフィック可視化を提供します。 |
特別な要件がなければ、Flannel が安全なデフォルトです。
アプリケーション用のストレージ
データを保持する必要のあるアプリケーション（データベース、ファイルアップロードなど）は、**ストレージ階層（storage tier）**を通じてストレージを要求します。必要な階層をステップ 4 で有効にします。複数を有効にでき、アプリケーションごとに使う階層を選べます。
| 階層 | 得られるもの | 使いどころ |
|---|---|---|
| Local Path （デフォルトで有効） | Pod が稼働するノード上の高速ストレージ | シンプルで高速。データは 1 ノードに留まるため、Pod が別ノードへ移動すると利用できません。 |
| 共有（NFS） | 多数の Pod が同時に共有でき、ノード間で利用可能なストレージ | Pod がファイルを共有する場合や、ノード間を移動してもデータを保持したい場合。 |
| レプリケーション（Longhorn） | ノード間で複製される高可用ブロックストレージ | ノード障害に耐える必要があるデータベースなどのステートフルなワークロード。 |
**共有（NFS）**では、Cockpit にすでに登録済みの NFS データストアを指定するか、外部 NFS サーバーのアドレスを入力できます。Cockpit は開始前にサーバーへ到達できるかを確認するため、入力ミスはプロビジョニングの途中ではなく早い段階で検知されます。
クラスターに接続する
クラスターの状態が active になると、標準の Kubernetes コマンドラインツール kubectl で接続できます。
クラスターの詳細ページで Download Kubeconfig をクリックします。Cockpit は正しいサーバーアドレスがすでに設定された、すぐ使えるファイルを提供します。
保存して
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コントロールプレーンとワーカーの各ノードが Ready と表示されるはずです。
TIP
毎回 KUBECONFIG を設定しなくて済むように、export 行をシェルのプロファイル（~/.bashrc または ~/.zshrc）に追記しておきましょう。
クラスターをスケールする
クラスターを作り直すことなく、ワーカーノードの数をいつでも増減できます。
- クラスターを開き、ワーカーノードプールを見つけます。
- 新しい希望ワーカー数を設定して確定します。
スケールアップは新しいワーカー VM を追加し、自動的にクラスターへ参加させます。新しいノードが Ready になると、ワークロードの受け入れを開始します。
スケールダウンは丁寧に行われます。ノードを削除する前に、Cockpit はそのノードを**ドレイン（drain）**し — 実行中のワークロードを残りのノードへ移して — アプリケーションを動かし続けます。その後で初めて VM が削除され、リソースが解放されます。
ノードの追加に失敗した場合
新しいワーカーを作成できない場合（例: 選んだホストが一時的に容量不足）でも、Cockpit は未完成のノードを自動的に片付け、実際に到達した台数にプールを調整します。もう一度スケールアップを実行すれば残りを再試行できます。中途半端なノードが残ることはありません。
クラスターをアップグレードする
Cockpit はローリングアップグレードを行い、アプリケーションを稼働させたまま、クラスターを新しい Kubernetes バージョンへ 1 ノードずつ移行します。
- クラスターを開き、Upgrade を選択します。
- 一覧から対象バージョンを選びます。
- 確定します。Cockpit はまずコントロールプレーンを、次にワーカーを、1 ノードずつアップグレードします。
アップグレード中、各ノードはドレインされ、更新され、次のノードに進む前にサービスへ戻されます。進捗は Tasks パネルで確認できます。
クラスターの健全性を監視する
クラスターが active になると、Cockpit はそれを監視し続け、クラスターページに健全性ステータスを表示します。
- Healthy（正常） — すべてのノードが存在し、Ready です。
- Degraded（低下） — 1 つ以上のノードが Ready ではありません（例: ノードが停止した、ネットワークを失った）。クラスターは稼働していますが、容量や耐障害性が低下しています。
健全性はノードの復旧・障害に応じて自動更新されるため、対応が必要かどうかが一目で分かります。
トラブルシューティング
クラスターが「provisioning」のまま active にならない。 最もよくある原因はネットワークです。選んだネットワークが各ノードに IP アドレスを自動で付与し、インターネットアクセスがあることを確認してください。ノードをホスト間に分散している場合は、そのネットワークが実際に該当ホストをまたいでいることを確認します。ネットワークの選択を参照。
ノードが「NotReady」、またはクラスターが「Degraded」と表示される。 そのノードの VM が稼働しているか確認してください（停止された、またはホストがダウンしている可能性があります）。VM が復帰してネットワークに再接続すると、ノードは自動的に再参加し、健全性は自然に Healthy へ戻ります。
kubeconfig をダウンロードしても kubectl が接続できない。KUBECONFIG がダウンロードしたファイルを指しており、お使いのマシンがネットワーク上でコントロールプレーンノードのアドレスに到達できることを確認してください。クラスターのアドレスが変わった場合は kubeconfig を再ダウンロードします。
Pod が別ノードへ移動した後、アプリケーションのデータが消えた。 これは Local Path ストレージ階層で発生します（データを 1 ノードに保持するため）。アプリケーションに追従すべきデータには、**共有（NFS）またはレプリケーション（Longhorn）**階層を使ってください。アプリケーション用のストレージを参照。
関連トピック
- Distributed Resource Scheduler（DRS）と高可用性 — Cockpit がノード VM をホスト間でどのように配置・分散するか。
- 仮想ネットワーク — クラスターノードが接続するネットワーク。
- ストレージとデータストア — クラスターをホストをまたいで実行可能にする共有データストア。