MENU

AKSでBlobFuseのバージョン確認とアップグレード完全ガイド｜BlobFuse2移行とノードイメージ更新の実践手順

Azure

Azure から「2026年9月30日までに BlobFuse を最新化せよ」という通知が届くと、AKS ではどこをどう見ればよいのか迷いがちです。本記事は“いまクラスタが何を使っているのか”“どうアップグレードするのが安全か”“v1→v2（fuse→fuse2）切り替えは何をすればよいか”を、現場でそのまま使えるコマンドと運用ノウハウで解説します。

目次

AKS における BlobFuse の正体と管理主体

ポイントは、AKS では BlobFuse が「Azure Blob CSI ドライバー」に内包されており、実体は kube-system の DaemonSet（csi-blob-node）に載ったコンテナ内のバイナリだということです。多くのケースでノード OS に手動インストールはされていません。よって、Linux ノードに SSH して blobfuse2 --version を直接叩いても見つからないのは正常です。確認は Pod 内で行います。

いま使っているのは v1（fuse）か v2（fuse2）かを素早く判定する

最短距離で「どのプロトコルでマウントしているか」を掴むには、StorageClass と CSI ノード Pod を見るのが定石です。

方法A：StorageClass の parameters で判定

AKS の Azure Blob 用 StorageClass は provisioner: blob.csi.azure.com を持ち、parameters.protocol に fuse（v1）または fuse2（v2）が設定されます。記載が無い場合は既定（多くは v1 互換）として扱われます。

# Blob 用 StorageClass を探す
kubectl get sc -o wide | grep -E '(azureblob|blob\.csi\.azure\.com)'

# 具体的な内容を確認（<SC_NAME> を差し替え）

kubectl describe sc <SC_NAME>

# parameters: protocol: fuse2 なら v2、fuse または無記載なら v1 系として扱われます

方法B：CSI ノード Pod 内でバイナリのバージョンを確認

kube-system の csi-blob-node DaemonSet の Pod に入って blobfuse / blobfuse2 を確認します。

# Pod を特定
kubectl -n kube-system get pods -l app=csi-blob-node -o wide

# 先頭の Pod 名を環境変数に格納

export BLOB_NODE=$(kubectl -n kube-system get pods -l app=csi-blob-node 
-o jsonpath='{.items[0].metadata.name}')

# どのコンテナにバイナリが入っているかを確認

kubectl -n kube-system get pod $BLOB_NODE -o jsonpath='{.spec.containers[*].name}'; echo

# （例）最初のコンテナで確認。必要に応じて -c  を付け替え

kubectl -n kube-system exec -it $BLOB_NODE -- sh -lc '
command -v blobfuse2 && blobfuse2 --version || true; 
command -v blobfuse  && blobfuse  --version  || true'

上の出力で blobfuse2 のバージョンが表示されれば v2 が展開済みです。blobfuse のみなら v1。

方法C：実マウントの状態をワークロード Pod 側で確認

既に Blob をマウントしている Pod から見ても判定できます。マウント文字列に blobfuse2 と出ていれば v2 です。

# 対象 Pod の中で
mount | grep -E 'blobfuse'
# または
cat /proc/mounts | grep -E 'blobfuse'

早見表：どの方法をいつ使う？

目的見る場所代表コマンド判断ポイント
クラスタのデフォルト挙動を知るStorageClasskubectl describe sc <SC>protocol: fuse2 なら v2
実際の実装バージョンを知るkube-system の csi-blob-node Podblobfuse2 --versionバイナリのメジャー/マイナーを直接確認
ワークロード影響の最終確認アプリ Podmount | grep blobfuseマウント実態が v1/v2 のいずれかを確認

推奨：最小労力で最新を維持するアップグレード戦略

AKS では、クラスタ（制御プレーン）とノードイメージのアップグレードで CSI ドライバー群と同梱コンポーネントが更新されます。BlobFuse の更新だけを狙い撃ちするより、AKS 標準のアップグレード手順に乗せる方が安全かつ再現性が高いです。

手順1：利用可能なバージョンの確認

az aks get-upgrades -g &lt;RESOURCE_GROUP&gt; -n &lt;AKS_NAME&gt; -o table

手順2：クラスタ（制御プレーン）のアップグレード

az aks upgrade -g &lt;RESOURCE_GROUP&gt; -n &lt;AKS_NAME&gt; \
  --kubernetes-version &lt;ターゲット版&gt; --yes

この操作はコントロールプレーンのみを更新します。アプリの Pod は引き続きノード上で動き続けます。

手順3：ノードプールのアップグレード

# Kubernetes バージョンも合わせて上げる場合
az aks nodepool upgrade -g <RESOURCE_GROUP> --cluster-name <AKS_NAME> \
  --name <NODEPOOL_NAME> --kubernetes-version <同上> --yes

# 既存の K8s 版を維持しつつ、最新ノードイメージ（含：CSI/BlobFuse）だけ取り込む場合

az aks nodepool upgrade -g  --cluster-name  
--name  --node-image-only --yes

node-image-only は実運用で重宝します。Kubernetes のメジャー／マイナーを据え置きながら、ノード OS やアドオンを最新化できるため、BlobFuse の通知対応だけを手早く終わらせたいときに有効です。

ローリングの影響と事前準備

  • AKS はノードを cordon → drain しながら順次更新します。PodDisruptionBudget を適切に設定し、同時退避数を制御します。
  • StatefulSet は既定で順次更新です。必要なら maxUnavailable・minReadySeconds・readinessProbe の条件を見直します。
  • DaemonSet でノードローカルにキャッシュしている設計は、退避時の再同期時間を考慮します。

BlobFuse v1（fuse）から v2（fuse2）へ「使い分け」or「移行」する

新規から v2 を使う：StorageClass で明示

v2 を強制したい場合は、専用の StorageClass を作り protocol: fuse2 を指定します。以後、この StorageClass を参照する新規 PVC は v2 経由でマウントされます。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azureblob-fuse2
provisioner: blob.csi.azure.com
parameters:
  protocol: fuse2
  # 例: 既定のコンテナ名やアカウント指定など、環境に応じて追記
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

既存ワークロードの切替え方

  1. 上記の azureblob-fuse2 StorageClass を作る。
  2. 対象アプリのマニフェストを新しい PVC（SC: azureblob-fuse2）に切り替える。
  3. ローリング再起動で新しいボリュームをマウントして起動する。

注意：Blob は外部サービスのオブジェクトストレージであり、PV/PVC 自体にデータを保持しているわけではありません。「fuse → fuse2」への切替えでデータ移行は不要です。ただし、マウントオプションやキャッシュ動作が変わるため、性能や一時ファイルの扱いは事前に検証しましょう。

強制的に v2 バイナリを使いたい（上級）

標準のノードイメージ更新を待たずに v2 の特定バージョンを使いたい要件がある場合、csi-blob-node DaemonSet に initContainer を注入し、ノード上にバイナリを配置する設計もあります（Change 管理を厳格に）。以下は概念例です。

# 例：DaemonSet に initContainer を追加するパッチ（概念）
kubectl -n kube-system patch daemonset csi-blob-node --type merge -p '{
  "spec": {
    "template": {
      "spec": {
        "initContainers": [{
          "name": "install-blobfuse2",
          "image": "ubuntu:22.04",
          "securityContext": {"runAsUser": 0},
          "command": ["sh","-lc"],
          "args": [
            "set -e; \
             mkdir -p /host/usr/local/bin; \
             # ここで社内アーティファクトから blobfuse2 の検証済みバイナリを取得する処理に置換 \
             cp /opt/blobfuse2/blobfuse2 /host/usr/local/bin/blobfuse2; \
             chmod 0755 /host/usr/local/bin/blobfuse2"
          ],
          "volumeMounts": [{
            "name": "usr-local-bin",
            "mountPath": "/host/usr/local/bin"
          }]
        }],
        "volumes": [{
          "name": "usr-local-bin",
          "hostPath": {"path": "/usr/local/bin", "type": "Directory"}
        }]
      }
    }
  }
}'

この方式は、サプライチェーン管理・署名・復旧手順まで含めて運用できる組織でのみ採用してください。通常は AKS の更新サイクルに乗せる方が安全です。

アップグレード手段の比較

手段作業量安全性BlobFuse更新の確実さ適した状況
クラスタ & ノードプール標準アップグレード低高高標準運用、定期メンテで最新化したい
node-image-only低高高K8s 版は据え置きつつ通知対応だけ急ぎたい
DaemonSet への initContainer 追加中〜高中（設計次第）高（狙った版を使用可能）バイナリ版を固定した社内標準がある

運用に効くチェックリスト

  • StorageClass に protocol: fuse2 を指定した v2 用 SC を用意したか。
  • kube-system の csi-blob-node で blobfuse2 --version を採取したか（証跡保全）。
  • 主要ワークロードで mount の文字列に blobfuse2 が出るかを確認したか。
  • ノードプールの node-image-only 実行履歴（日時・実施者・対象）を残しているか。
  • PodDisruptionBudget・readinessProbe・再試行戦略（restartPolicy）が妥当か。

検証（ステージング）から本番へ：実行手順テンプレート

  1. ステージングで node-image-only を実施し、csi-blob-node のバージョンと StorageClass の挙動を確認。
  2. v2 用 StorageClass（protocol: fuse2）を作成。
  3. 代表ワークロードを v2 SC で起動し、I/O テスト（ランダム read/write、並列度、キャッシュ設定）を記録。
  4. 本番で PDB を確認し、段階的にノードプールを更新（1プールずつ）。
  5. ロールアウト後に mount の確認とアプリ観点の SLA/SLO をモニタリング。

性能・チューニング観点（v1→v2 での体感差）

  • ディレクトリリスト性能：v2 の方がメタデータ処理が効率的で、ファイル数が多いコンテナで効果が出やすい。
  • キャッシュ：v2 はキャッシュの粒度とクリア条件が整理されており、読み取り偏重ワークロードで安定することが多い。
  • マウントオプション：allow_other 等の一部挙動が v1 と異なる場合があるため、セキュリティポリシー（Kata/SELinux/AppArmor 等）と合わせて検証する。

トラブルシュート（よく遭遇する症状と初動）

症状考えられる要因初動コマンド対処の方向性
Pod 起動時にマウント失敗資格情報不一致、ネットワーク疎通、マウントオプション不正kubectl logs -n kube-system <blob-node-pod> --tail=200Secret/Managed Identity の再確認、protocol の見直し
高負荷時に 429/5xxスロットリング、同時接続過多、キャッシュ未最適化アプリ Pod のログ、メトリクス（レイテンシ/エラー率）同時 I/O 低減、バックオフ、キャッシュ調整
ノード更新で一時的にSLO悪化PDB/レプリカ数不足、Readiness 遅延kubectl get pdb / kubectl get hpaレプリカ増・PDB 調整・ウォームアップ導入

セキュリティと資格情報の扱い（再確認）

  • 資格情報は Secret で持たず、可能なら Managed Identity / Workload Identity を使う構成へ移行する。
  • Pod の権限は最小化（runAsUser、fsGroup、readOnlyRootFilesystem）。
  • 監査観点では、どの StorageClass/PVC が v1/v2 かを定期レポート化するとよい（kubectl get pvc -A -o json を整形）。

実務で使えるコマンド集（コピー＆ペースト可）

v1/v2 の実態把握（一覧）

# すべての Blob 系 StorageClass と protocol を一覧
kubectl get sc -o json | jq -r '
  .items[] | select(.provisioner == "blob.csi.azure.com") |
  .metadata.name + "\tprotocol=" + (.parameters.protocol // "default")'

# すべての PVC -> 参照している StorageClass を一覧

kubectl get pvc -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.storageClassName}{"\n"}{end}'

CSI ノードのバージョン採取

# csi-blob-node のコンテナイメージ（タグ）を一覧
kubectl -n kube-system get ds csi-blob-node -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\t"}{.image}{"\n"}{end}'

# 代表 Pod から blobfuse2 / blobfuse のバージョン

export BLOB_NODE=$(kubectl -n kube-system get pods -l app=csi-blob-node -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system exec -it $BLOB_NODE -- sh -lc 'blobfuse2 --version || true; blobfuse --version || true'

ノードイメージのみ更新

az aks nodepool upgrade -g &lt;RG&gt; --cluster-name &lt;AKS&gt; \
  --name &lt;POOL&gt; --node-image-only --yes

v2 専用 StorageClass のサンプル

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azureblob-fuse2
provisioner: blob.csi.azure.com
parameters:
  protocol: fuse2
  # 必要に応じて container, secretName 等を追加
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

よくある誤解と解消法

  • 誤解：ノードに SSH して blobfuse2 --check すればよい。
    解消：AKS ではドライバーは Pod 内にあり、ノード OS に直接は無いのが普通。kube-system の Pod で確認します。
  • 誤解：v1→v2 は「データ移行」が必要。
    解消：Blob は外部のオブジェクトストレージ。PV/PVC の切替え（StorageClass）とマウントオプション見直しが中心です。
  • 誤解：既存 PV は自動で v2 に切り替わる。
    解消：既存 PV/PVC は作成時の定義に従います。新規 PVC を v2 SC で作るか、アプリを切替える必要があります。

コンプライアンス通知（2026/09/30 期日）への実務対応例

  1. 現状把握（1〜2日）：全 StorageClass / PVC の棚卸し、csi-blob-node のバージョン採取。
  2. 是正方針決定（1日）：標準は node-image-only の定期化。移行設計は「新規 v2 SC」「既存は順次置換」。
  3. ステージング検証（2〜3日）：機能・性能・キャッシュ・フォールト注入。
  4. 本番適用（1スプリント）：ノードプール単位の段階適用、メトリクス監視。
  5. 証跡化：実行コマンド、日時、対象、バージョン画面出力を保全。

まとめ：最終的な指針

  • AKS を定期アップグレード（または node-image-only の定期運用）していれば、BlobFuse を含む CSI 周辺は基本的にサポート対象バージョンに保たれます。
  • 現時点で v1 と v2 が並存していても、通知は「古い v1 か、古い v2」への是正要請という理解で OK。ノードイメージ更新で解消するのが王道です。
  • 積極的に v2 を使いたい場合は、protocol: fuse2 の StorageClassを作成し、新規 PVC から v2 を適用。既存 PV は自動では切り替わらないため、アプリ側の切替え計画を立てましょう。

付録：運用ドキュメント雛形（そのまま社内 Wiki に流用可）

目的

AKS 上の BlobFuse をサポート対象バージョンに維持し、2026/09/30 の期日までに是正を完了する。

対象

  • AKS すべてのノードプール（Linux）
  • Azure Blob CSI ドライバー（csi-blob-node）
  • Blob マウントを用いるワークロード（有無・数を棚卸し）

作業

  1. 現状採取：kubectl describe sc、blobfuse2 --version、mount。
  2. 是正：az aks nodepool upgrade --node-image-only（本番は段階的）。
  3. 切替：v2 用 StorageClass へ新規 PVC を切替え、ワークロードをローリング。
  4. 検証：I/O・レイテンシ・エラー率・起動時間を比較。
  5. 証跡：全ログと実行者・日時をチケットに添付。

ロールバック

  • アップグレード前のノードプールの スケールアウト + 優先スケジュール で即時復旧可能な体制を用意。
  • v2 SC 切替え後に問題があれば、旧 PVC を参照する manifest へ戻しローリング。

結論：AKS では BlobFuse は CSI ドライバーに内包されており、ノードイメージ更新＝BlobFuse 更新が基本動作です。
「どのプロトコルでマウントしているか」を StorageClass と実マウントで確かめ、node-image-only を定期運用しつつ、v2 を積極採用したい領域から protocol: fuse2 を適用していけば、期限内に無理なく完了できます。

Azure
Azure AKS Azure Blob CSI StorageClass BlobFuse

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次