その夜、ディスク使用率は99%を超えていた
監視ダッシュボードのディスク使用率が99%に張り付いている。K3sのlocal-path-provisionerが使うボリュームか、それともコンテナイメージのキャッシュか。原因はどうあれ、やることは一つしかない。Proxmoxのストレージを拡張することだ。
Proxmox VEでのストレージ拡張は、公式ドキュメントを読む限り単純な作業に見える。VMを止めずにディスクを大きくし、ゲストOS側でファイルシステムを広げるだけだ。しかし本番のK3sクラスタでこの作業をやったことがあるエンジニアなら、「拡張したはずなのに反映されない」という経験に心当たりがあるはずだ。
この記事では、Proxmoxで本番運用中のK3s/Kuboクラスタのストレージを拡張する際に実際に起きる落とし穴と、単一VMでは足りない場合にCephで無停止拡張する方法、そしてその作業がK3sのetcd(クォーラム)に与える影響までを、公式ドキュメントのレベルで具体的に整理する。こうした運用の細部を自社で背負うか、KuboのようなマネージドK3s基盤に任せるかは、後述する落とし穴の深さを知ってから判断しても遅くない。
「無停止で拡張できるはず」が裏切られた理由 — コントローラという見落とし
Proxmoxの公式Wikiが示すディスク拡張手順自体はシンプルだ。qm resizeコマンド、またはGUIの Hardware > Hard Disk > Disk Action > Resize でディスクサイズを変更し、ゲスト側でpartedによるパーティション拡張、その後pvresize/lvresize（LVM構成の場合）やresize2fsでファイルシステムを広げる、という3段階だ。
ところがこの手順がすんなり通るかどうかは、VMにアタッチされているディスクコントローラの種類に左右される。Proxmox公式ドキュメントのQEMU/KVM仮想マシンの章では、ディスクコントローラとしてIDE・SATA・SCSI・VirtIO Blockの4種類が説明されているが、パフォーマンスと機能面で推奨されているのは一貫して「VirtIO SCSI single」タイプのSCSIコントローラだ。IDEは1984年設計、SATAも2003年設計と、いずれも古い規格をベースにしており、Proxmox VE 7.3以降でLinux VMの新規作成時にデフォルトになっているのもVirtIO SCSI singleである。
qm.confのマニュアルを見ると、scsihwパラメータにはlsi・lsi53c810・megasas・pvscsi・virtio-scsi-pci・virtio-scsi-singleが指定できるが、パフォーマンスを重視するならIO Threadを有効にしたvirtio-scsi-singleが推奨されている。古い構成のまま残っているVM、あるいは他のハイパーバイザーからP2V移行してきたVMでは、意識しないままSATAやIDEコントローラが使われ続けているケースが少なくない。
拡張作業に入る前に、対象のK3sノードVMがどのコントローラ種別を使っているかをqm config <vmid>で必ず確認すること。もしSATAやIDEであれば、ディスクの拡張よりも先に、VMを一度停止してコントローラをSCSI(VirtIO SCSI single)に変更する作業が必要になる。つまり「無停止で拡張するはずだった作業」に、想定外の再起動が挟まることになる。
正しい拡張手順 — qm resizeからファイルシステムまで
# 1. Proxmoxホスト側でディスクを拡張(VM実行中でも可、SCSI/VirtIOコントローラの場合)
qm resize <vmid> scsi0 +50G
# 2. ゲストOS内でパーティションを拡張(parted)
parted /dev/sda ---pretend-input-tty resizepart 1 100%
# 3a. LVM構成の場合: 物理ボリューム→論理ボリューム→ファイルシステムを一括拡張
pvresize /dev/sda1
lvresize --extents +100%FREE --resizefs /dev/mapper/vg-root
# 3b. LVMなしの場合: ファイルシステムを直接拡張
resize2fs /dev/sda1
ディスクの縮小はサポートされていないため、あらかじめファイルシステムとパーティションのサイズを小さくしてからでないと縮小できない点にも注意したい。
ノード単位では足りない時 — Cephで無停止にディスク/ノードを足す
単一VMのディスク拡張では追いつかないほど容量が逼迫している場合、選択肢になるのがCephによるストレージプールの拡張だ。ProxmoxはHyper-Converged Ceph ClusterとしてCephをネイティブに統合しており、稼働中のクラスタにノードやOSD(Object Storage Daemon、物理ディスク1台に対応)を追加できる。
Ceph公式ドキュメントが示す手順は、新規OSDの作成・メタデータディレクトリの初期化・認証キーの登録・CRUSHマップへの追加という流れになる。Proxmoxの管理画面からであれば、対象ノードでディスクを選び「Ceph → OSD → Create」を実行するだけで、この一連の処理がGUI越しに実行される。
OSDを追加すると、Cephは自動的にデータの再配置(リバランス)を開始する。Ceph公式ドキュメントによれば、この間プレースメントグループ(PG)の状態はactive+cleanからactive, some degradedのような一時的な状態に遷移し、リバランス完了後にactive+cleanへ戻る。この進捗はceph -wやwatch ceph statusで監視できる。重要なのは、このリバランス中も既存のK3sノードVMは通常どおり稼働を継続できるという点だ。単一ディスクの容量が尽きた時とは異なり、クラスタ全体としての無停止性を維持できるのがCephの最大の利点である。
ただしCeph公式ドキュメントは、クラスタがfull ratio(デフォルトで容量の95%程度)に達する前に拡張作業を始めるよう強く警告している。容量が逼迫しきってからOSDを追加しようとすると、リバランス自体がI/O帯域を圧迫し、状況を悪化させかねない。
拡張中、K3sのetcdは何を見ているか
ここまでの手順は、Proxmoxホスト・Cephクラスタというインフラ層の話だった。しかし本番のK3sクラスタをHA(High Availability)構成で運用している場合、ストレージ拡張作業はもう一段上のレイヤー、つまりK3sのコントロールプレーンにも影響しうる。
K3sのHA構成では、既定でSQLiteではなくembedded etcdがデータストアとして使われる。K3s公式ドキュメントは、HA embedded etcdクラスタは奇数個のサーバーノード(最低3台)で構成する必要があり、クォーラム(過半数合意)を維持するにはn台中n/2+1台が生きている必要があると説明している。同ドキュメントは「Raspberry PiのSDカードのような低速ディスクでは、embedded etcd(HA)がパフォーマンス問題を起こすことがある」とも明記しており、ディスク性能への感度の高さを裏付けている。
この感度の根拠は、etcdそのものの設計にある。etcd公式のハードウェア推奨事項では、負荷の高いクラスタではローカルSSD相当の500 IOPS以上のシーケンシャル書き込み性能が推奨されており、「書き込みが遅すぎるとハートビートがタイムアウトし、選挙が発生してクラスタの安定性が損なわれる」と警告されている。Kubernetes公式ドキュメントも同様に、etcdはネットワークとディスクI/Oの両方に敏感であり、リソース枯渇がハートビートタイムアウトとクラスタ不安定化につながると警告している。etcd公式FAQが示す目安は明確で、fsync遅延の99パーセンタイル値が10ms未満であることが安定運用の条件とされている。
つまり、Cephのリバランスやディスクコントローラ変更のためのVM再起動といった作業中は、embedded etcdを動かしているサーバーノードのディスクI/Oが一時的に競合し、fsyncレイテンシが跳ね上がるリスクがある。レイテンシがしきい値を超えれば、ネットワーク的には正常でもリーダーが「実質的に到達不能」と判定され、新しいリーダー選挙が発生しうる。拡張作業そのものは無停止でも、その裏でK3sのコントロールプレーンが不安定化するという間接的な影響が起こりうるということだ。
対策としては、embedded etcdを持つサーバーノードから作業を始めない、拡張作業中はetcd_disk_wal_fsync_duration_seconds相当の指標(Prometheusで収集している場合)を監視する、可能であればetcdのデータディレクトリだけは専用の高速ディスクに分離しておく、といった対応が有効だ。Kubo CloudはPrometheus+Grafanaを標準搭載しており、こうしたetcdクォーラムの健全性監視をゼロから構築せずに始められる。
まとめ — 拡張前にチェックすべき3点
Proxmox上でK3s/Kuboクラスタのストレージ容量が逼迫した時、慌てて拡張作業に入る前に確認しておきたいのは次の3点だ。
- ディスクコントローラはSCSI(VirtIO SCSI single)か:
qm config <vmid>で確認し、SATA/IDEであれば先にコントローラ変更(要停止)を計画する - ノード単位かクラスタ全体かで手段を選ぶ: 単一VMのディスク拡張で足りるのか、Cephでのノード/OSD追加が必要な規模なのかを見極める
- 拡張作業中はetcdのfsyncレイテンシを監視する: embedded etcdを使うHA構成では、ディスクI/O競合がコントロールプレーンの安定性に波及しうる
こうした「本番運用中の落とし穴」は、Proxmoxひとつ、K3sひとつを個別に見ていても気づきにくい。インフラ層とコントロールプレーン層の両方を横断して設計・監視する体制が必要になる。
Kubo On-Premiseは、Proxmoxのような自社インフラ上でK3sベースのフルマネージドKubernetesを構築できるサービスだ。ディスクコントローラの選定からetcdクォーラムの監視まで、こうした運用の細部をKuboの標準構成が引き受ける。データを外に出せない金融・医療・製造業の現場でも、Air-Gapped環境での完全自社管理が可能になる。
ストレージ拡張のたびに「今回もちゃんと反映されるか」と冷や汗をかく運用から抜け出したいなら、お問い合わせからKubo On-Premiseの無料相談を検討してみてほしい。EKS/AKSのようなクラウド依存のマネージドK8sとは異なり、自社ハードウェアの上でフルマネージドの運用体験を実現できる。