コンテンツにスキップ

VolumeScaler — Automatic Scaling for k8s volumes

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

Kubernetes の PersistentVolumeClaim を使用率に応じて自動拡張する OSS controller、VolumeScaler の紹介記事。 PVC の過小見積もりは容量不足と停止につながり、過大見積もりはコスト浪費になる。 VolumeScaler は CRD でしきい値、拡張量、最大サイズを定義し、ノード上の使用量を監視して PVC を patch する。

本文

Kubernetes で stateful workload を運用すると、PVC の容量設計が難しい。 小さく作りすぎると、ディスク不足でアプリケーションが止まる。 大きく作りすぎると、使っていないストレージにコストを払い続ける。

手作業で監視し、容量が足りなくなったら PVC を拡張する運用もできるが、対応が遅れると障害になる。 そこで紹介されるのが VolumeScaler。

VolumeScaler の役割

VolumeScaler は Kubernetes controller として動作し、PVC の使用率を監視して、条件を満たしたら PVC の容量を拡張する。 AWS EBS のように online volume expansion をサポートする CSI driver と組み合わせれば、Pod を止めずに容量を増やせる。

VolumeScaler の特徴は次の通り。

  • PVC 使用率に基づく自動拡張。
  • 固定サイズまたはパーセンテージでの拡張。
  • しきい値、拡張量、最大サイズをカスタマイズ可能。
  • ノードレベルでマウントされた PVC の使用量を監視。
  • CRD による Kubernetes-native な設定。

アーキテクチャ

構成要素は大きく分けて、CRD、controller、node-level monitoring、storage provider integration。

CRD は、どの PVC を、どの条件で、どこまで拡張するかを定義する。 VolumeScaler resource に PVC 名、しきい値、拡張方式、最大サイズを書く。

Controller は CRD を監視し、現在の使用率と設定を比較する。 しきい値を超えていれば、PVC の spec.resources.requests.storage を増やす patch を Kubernetes API に送る。

Node-level monitoring は、実際に Pod に mount されている volume の使用量を取得する。 記事では df のような仕組みで使用率を確認する説明になっている。

Storage provider integration は、Kubernetes の PVC 拡張と CSI driver、クラウドストレージ側の拡張をつなぐ。 PVC を patch した後、Kubernetes と CSI driver が実際の volume resize を進める。

インストール

VolumeScaler は Helm chart で導入できる。

helm repo add sample-volumeScaler https://aws-samples.github.io/sample-volumeScaler
helm repo update
helm upgrade --install volumescaler sample-volumeScaler/volumescaler

インストール後、controller と DaemonSet がクラスタ内で動き、CRD を見ながら PVC を監視する。

設定例

PVC を 70% 使用したら、現在サイズの 30% 分を追加し、最大 10Gi まで拡張する例。

apiVersion: autoscaling.storage.k8s.io/v1alpha1
kind: VolumeScaler
metadata:
  name: example-pvc
  namespace: default
spec:
  pvcName: example-pvc
  threshold: "70%"
  scaleType: "percentage"
  scale: "30%"
  maxSize: "10Gi"

scaleType は percentage または fixed。 percentage は現在サイズに対する割合で増やす。 fixed は毎回一定量を増やす。

最大サイズを設定することで、想定外に拡張し続けてコストが増えることを防ぐ。

実行フロー

  1. ユーザーが VolumeScaler CR を作成する。
  2. VolumeScaler controller が CR を監視する。
  3. DaemonSet がノード上で PVC のディスク使用率を確認する。
  4. 使用率が threshold を超える。
  5. Controller が PVC の request storage を増やす。
  6. Kubernetes と CSI driver が volume resize を実行する。
  7. CR の status に最後の拡張時刻、履歴、最大サイズ到達などを記録する。

この流れにより、人間が kubectl で PVC を編集する前に、自動で拡張される。

得られる効果

記事では、最大 40% のコスト削減、ストレージ容量不足による停止ゼロ、手作業の 90% 削減といった効果が示されている。 実際の効果は workload とストレージ価格に依存するが、過剰な初期容量を持たせず、必要になったら拡張する方針はコスト最適化につながる。

ベストプラクティス

最初は保守的なしきい値から始める。 たとえば 80% 付近で拡張し、アプリケーションの書き込み速度や resize にかかる時間を見ながら調整する。

必ず最大サイズを設定する。 バグや異常書き込みで volume が拡張し続けると、コストやストレージ上限の問題になる。

不規則な workload には percentage 拡張、予測しやすい workload には fixed 拡張が向く。 イベント、ログ、status を監視し、いつどの PVC が拡張されたかを追跡できるようにする。

StorageClass 側で volume expansion が有効か、CSI driver が online expansion に対応しているかも確認する。 対応していない場合、PVC を patch しても期待どおりに拡張されない。

要点

  • PVC 容量は小さすぎると停止、大きすぎるとコスト浪費になる。
  • VolumeScaler は PVC 使用率を監視し、条件を満たすと自動で容量を増やす。
  • CRD で PVC 名、しきい値、拡張方式、最大サイズを定義する。
  • Helm で導入でき、controller と DaemonSet が動く。
  • online expansion には CSI driver と StorageClass の対応が必要。
  • 最大サイズと監視を必ず設定し、無制限な拡張を避ける。

タグ

kubernetes #pvc #storage #autoscaling #helm