はじめに

Harvesterを自宅Labや検証環境で使う場合、まず試したくなるのが：

NUC
ミニPC
単一サーバー

などを使ったシングルノード構成です。

しかしそのままVMを作成すると、Longhorn由来の：

Replica scheduling failure
Volume Degraded

のような警告に遭遇することがあります。

この記事では、

「Harvesterインストール後に」

StorageClassを追加・変更することで、シングルノード向けにReplica数を調整する方法を整理します。

なお、Harvesterにはインストール時点でSingle Node Clusterとして設定する方法もありますが、今回は：

後から調整するケース

を扱います。

なぜシングルノードで問題が起きるのか

Harvesterの永続ストレージは内部的にLonghornを利用しています。

Longhornは本来：

複数ノードにReplicaを配置
ノード障害時にもVolume維持

するHA前提の設計です。

そのためデフォルトでは：

Replica Count = 3

になっていることが一般的です。

しかしシングルノードでは：

ノード数 = 1
Replica要求 = 3

となり、Replicaを配置できません。

結果として：

VolumeがDegraded
Scheduling failure
Warning表示

になります。

「ISOはActiveなのに？」となる理由

ここは少し混乱しやすいポイントです。

たとえば：

Windows Server ISO
Ubuntu ISO

などをImage登録すると：

State = Active

になります。

しかしこれは：

「ISOファイルが利用可能になった」

だけです。

まだVMディスクは作成されていません。

問題はVMディスク作成時に発生する

実際にReplica設定が効くのは：

VM Disk (Longhorn Volume)

が作成されるタイミングです。

つまり：

ISO登録
  ↓
問題なし

VM作成
  ↓
PVC / Longhorn Volume生成
  ↓
Replica不足発覚

という流れになります。

特に：

VMDK
qcow2
raw image

などは、即Volumeとして利用されるため問題が見えやすいです。

対策：Replica=1 の StorageClassを作成する

シングルノードでは：

Replica=1

にするのが基本になります。

Harvester UIからStorageClassを作成

メニュー：

Advanced > Storage Classes

から新規作成します。

デフォルトの状態。

右上の「Create」押下し表示される設定画面。

Number of Replicaを１に変更。

右下の「Create」を押下。

注：ここでNetwork Errorが表示される場合があります。その場合Web UIから一度ログアウトしログインし直すことで解決する場合はほとんどです。

追加を確認し、デフォルトに設定。

イメージを利用してVMを作成。

Longhornでの見え方（https:///k8s/clusters/local/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/#/dashboard）

ダメな例

YAML例

YAMLでは以下のような形になる（イメージ）。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: harvester-single-replica
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "30"
  fsType: "ext4"

重要なのは：

numberOfReplicas: "1"

です。

Default StorageClass に設定する

かなり重要です。

StorageClassを作っただけでは、既存Defaultが使われ続けます。

既存VMには反映されない

ここも重要です。

StorageClass変更は：

既存Volumeには自動適用されません

つまり：

既存VM
既存PVC
既存Volume

は古いReplica設定を持ち続けます。

必要に応じて：

新規VM作成
Disk再作成
データ移行

が必要です。

動作確認

Longhorn Volume画面で：

Replica Count = 1
State = Healthy

を確認します。

もし：

State = Degraded

なら、古いStorageClassが使われている可能性があります。

注意点：これはHAではない

当然ですが：

Replica=1

は高可用性ではありません。

つまり：

ノード障害
SSD故障

でVolumeを失う可能性があります。

これは：

「Lab・検証環境向け」

として理解する必要があります。

シングルノード構成でもHarvesterはかなり学べる

面白い点として、シングルノード構成でも：

Longhorn
StorageClass
PVC
KubeVirt
Volume lifecycle

など、

Kubernetesベース仮想化の理解がかなり深まります。

特に：

「ISOはActiveなのにVMで失敗する」

という体験は、

Kubernetesストレージが「いつ実際に確保されるのか」

を理解する良い教材になります。

利用

悪い例

イメージレベルでは問題ないのがわかりづらいところ。

３レプリカになっている。

デフォルトを変えた後で、登録

１レプリカになっている。

まとめ

Harvesterをシングルノードで運用する場合、

デフォルトの：

Replica=3

ではLonghornが正常配置できず、

Degraded
Replica scheduling failure

が発生することがあります。

その場合は、

Replica=1 の StorageClass

を後から作成し、Default化することで調整可能です。

ただし：

既存Volumeには反映されない
HAではない

点には注意が必要です。

とはいえ、自宅Labとしては：

Harvester
Longhorn
Kubernetes Storage

を理解する非常に良い環境になります。