次の方法で共有

Azure Blob Storage コンテナーをマウントするときのエラー

この記事では、Azure Blob Storage コンテナーのマウントが失敗する原因となるエラーの考えられる原因と解決策について説明します。

現象

Azure Kubernetes Service (AKS) 環境に、デプロイや StatefulSet などの Kubernetes リソースをデプロイします。 デプロイでは、Azure BLOB Storage コンテナーを参照する PersistentVolumeClaim (PVC) をマウントするポッドが作成されます。

ただし、ポッドは ContainerCreating 状態のままです。 kubectl describe pods コマンドを実行すると、コマンド出力に次のいずれかのエラーが表示され、マウント操作が失敗することがあります。

Note

Azure Blob Storage コンテナーでは、BlobFuse またはネットワーク ファイル システム (NFS) バージョン 3.0 プロトコルを使用できます。 BlobFuse と NFS 3.0 のシナリオについては、この記事で別途説明します。

考えられる原因と解決方法については、以下のセクションを参照してください。

Note

問題の原因は一部のシナリオで似ていますが、BlobFuse プロトコルと NFS 3.0 プロトコルの性質が異なるため、エラーが異なる場合があります。

BlobFuse エラー 1: 終了状態 255 blobfuse を開始できません。errno=404、認証または接続の問題により blobfuse を開始できません

原因: BLOB コンテナーが存在しない

BLOB コンテナーが存在するかどうかを確認するには、以下の手順を実行します。

  1. Azure portal で Storage アカウントを検索し、ストレージ アカウントにアクセスします。

    ストレージ アカウントを検索する方法を示すスクリーンショット。

  2. ストレージ アカウントの [Data storage で Containers を選択し、関連付けられている PersistentVolume (PV) が Containers に存在するかどうかを確認します。 永続ボリューム (PV) を確認するには、YAML ファイルでポッドに関連付けられた永続ボリューム要求 (PVC) を確認し、その PVC にどの PV が関連付けられているかを確認します。

    コンテナーの永続ボリューム要求を示すスクリーンショット。

解決策: コンテナーが存在することを確認する

この問題を解決するには、PV/PVC に関連付けられた BLOB コンテナーが存在することを確認します。

BlobFuse エラー 2: 終了状態 255 blobfuse を開始できません。errno=403、認証または接続の問題により blobfuse を開始できません

このエラーの原因として、次のことが考えられます。

原因 1: Kubernetes のシークレットが正しいストレージ アカウント名またはキーを参照していない

Blob Storage コンテナーが 動的に作成場合、"azure-storage-account-<storage-account-name>-secret" という名前の Kubernetes シークレット リソースが自動的に作成されます。

BLOB ストレージ コンテナーを手動で作成した場合は、Kubernetes シークレット リソースを手動で作成する必要があります。

作成方法に関係なく、Kubernetes シークレットで参照されるストレージ アカウント名やキーが実際の値と異なる場合、マウント操作は "アクセス許可が拒否されました" エラーで失敗します。

不一致の考えられる原因

  • Kubernetes シークレットを手動で作成した場合、作成時に入力ミスが発生する可能性があります。

  • ストレージ アカウント レベルで "キーのローテーション" 操作を実行した場合、その変更は Kubernetes のシークレット レベルには反映されません。 その結果、ストレージ アカウント レベルのキー値と Kubernetes シークレット レベルの値は一致しなくなります。

    "キーのローテーション" 操作が発生した場合、ストレージ アカウントの [アクティビティ ログ] に "ストレージ アカウント キーの再生成" という操作が表示されます。 90 日という [アクティビティ ログ] の保持期間に注意してください。

不一致を確認する

不一致を確認するには、以下の手順を実行します。

  1. Azure portal でストレージ アカウントを検索してアクセスします。 ストレージ アカウントで Access キー>Show キー を選択します。 ストレージ アカウント名とそれに関連付けられたキーが表示されます。

    ストレージ アカウント名と関連付けられているキーを示すスクリーンショット。

  2. AKS クラスターに移動し、 Configuration>Secrets を選択し、関連付けられているシークレットを検索してアクセスします。

    関連付けられているシークレットを示すスクリーンショット。

  3. Show (目のアイコン) を選択し、ストレージ アカウント名と関連付けられているキーの値を手順 1 の値と比較します。

    ストレージ アカウント名と関連付けられているキーの値を示すスクリーンショット。

    Show を選択する前に、ストレージ アカウント名と関連付けられているキーの値が base64 文字列にエンコードされます。 Showを選択すると、値がデコードされます。

Azure portal で AKS クラスターにアクセスできない場合は、kubectl レベルで手順 2 を実行します。

  1. Kubernetes シークレットの YAML ファイルを取得し、次のコマンドを実行して、ストレージ アカウント名とキーの値を出力から取得します。

    kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>

  2. echo コマンドを使って、ストレージ アカウント名とキーの値をデコードし、ストレージ アカウント レベルの値と比較します。

    ストレージ アカウント名をデコードする例を次に示します。

    echo -n '<storage account name>' | base64 --decode ;echo

    ストレージ アカウント名をデコードするコマンドのスクリーンショット。

解決策: Kubernetes シークレットを調整し、ポッドを再作成する

Kubernetes シークレットのストレージ アカウント名またはキーの値がストレージ アカウントの Access キー の値と一致しない場合は、次のコマンドを実行して Kubernetes シークレット レベルで Kubernetes シークレットを調整します。

kubectl edit secret <secret-name> -n <secret-namespace>

Kubernetes シークレット構成で追加したストレージ アカウント名またはキーの値は、base64 でエンコードされた値である必要があります。 エンコードされた値を取得するには、echo コマンドを使います。

ストレージ アカウント名をエンコードする例を次に示します。

echo -n '<storage account name>'| base64 | tr -d '\n' ; echo

詳細については、「Managing Secrets using kubectl」(kubectl を使ったシークレットの管理) を参照してください。

Kubernetes シークレット azure-storage-account-<storage-account-name>-secret に正しい値が設定されたら、ポッドを再作成します。 そうしないと、有効ではない古い値をそれらのポッドが使い続けることになります。

原因 2: このストレージ アカウントに AKS の VNET とサブネットは許可されていない

ストレージ アカウントのネットワークを選んだネットワークに限定している場合、その選んだネットワークに AKS クラスターの VNET とサブネットを追加していないと、マウント操作は失敗します。

解決策: ストレージ アカウントに AKS の VNET とサブネットを許可する

  1. 次のコマンドを実行して、障害のあるポッドをホストするノードを特定します。

    kubectl get pod <pod-name> -n <namespace> -o wide

    コマンド出力のノードを確認します。

    ノードと出力を識別できるコマンドのスクリーンショット。

  2. Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソース グループを選択し、ノードに関連付けられている仮想マシン スケール セット (VMSS) にアクセスしてから、 仮想ネットワーク/サブネット を確認して、VNET とサブネットを特定します。

    VNET とサブネットのスクリーンショット。

  3. Azure portal でストレージ アカウントにアクセスし、 Networking を選択します。 パブリック ネットワーク アクセス選択した仮想ネットワークから有効に設定されている場合または Disabled 接続がプライベート エンドポイント経由でない場合は、AKS クラスターの VNET とサブネットが Firewalls と仮想ネットワークで許可されているかどうかを確認。

    ファイアウォールと仮想ネットワークの設定のスクリーンショット。

    AKS クラスターの VNET とサブネットが追加されていない場合は、 既存の仮想ネットワークの追加を選択します。 ネットワークの追加 ページで、AKS クラスターの VNET とサブネットを入力し、追加>保存を選択します。

    [ネットワークの追加] ダイアログのスクリーンショット。

    変更が有効になるまでに数分かかる場合があります。 VNET とサブネットが追加されたら、ポッドの状態が ContainerCreating から Running に変わるかどうかを確認します。

    ポッドの状態が

BlobFuse エラー 3: コンテキストの期限を超えました/指定されたボリューム ID <を持つ操作。...> は既に存在します

このエラーの原因として、次のことが考えられます。

BlobFuse エラー 3 の初期トラブルシューティング

Azure Blob BlobFuse はポート 443 に依存しています。 ポート 443 とストレージ アカウントの IP アドレスがブロックされていないことを確認します。

ストレージ アカウントの IP アドレスを確認するには、nslookup、dig、host などのドメイン ネーム システム (DNS) コマンドを実行します。 例えば次が挙げられます。

nslookup <storage-account-name>.blob.core.windows.net

AKS クラスターとストレージ アカウント間に接続があるかどうかを確認するには、ノードまたはポッド内に移動し、次の nc または telnet コマンドを実行します。

nc -v -w 2 <storage-account-name>.blob.core.windows.net 443

telnet <storage-account-name>.blob.core.windows.net 443

原因 1: ネットワーク セキュリティ グループが AKS とストレージ アカウント間のトラフィックをブロックしている

BlobFuse エラー 3 のInitial トラブルシューティングのセクションで説明されているncまたはtelnet コマンドの出力確認します。 タイムアウトが表示された場合は、ネットワーク セキュリティ グループ (NSG) を確認し、ストレージ アカウントの IP アドレスがブロックされていないことを確認します。

NSG がストレージ アカウントの IP アドレスをブロックしているかどうかを確認するには、以下の手順を実行します。

  1. Azure portal で、 Network Watcher に移動し NSG 診断 選択。

  2. フィールドに次の値を入力します。

    • プロトコル: TCP
    • 方向: 送信
    • ソースの種類: IPv4 アドレス/CIDR
    • IPv4 アドレス/CIDR: AKS ノードに関連付けられているインスタンスの IP アドレス
    • 宛先 IP アドレス: ストレージ アカウントの IP アドレス
    • 宛先ポート: 443 (BlobFuse を使用している場合) と 111/2048 (NFS を使用している場合)

  3. Check ボタンを選択し、Traffic 状態を確認します。

Trafficの状態は、AllowedまたはDeniedできます。 Denied状態は、NSG が AKS クラスターとストレージ アカウント間のトラフィックをブロックしていることを意味します。 状態が Denied の場合、NSG 名が表示されます。

解決策: AKS とストレージ アカウント間の接続を許可する

この問題を解決するには、NSG レベルで適宜変更を加えて、ポート 443 での AKS クラスターとストレージ アカウント間の接続を許可します。

原因 2: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックをブロックしている

仮想アプライアンス (通常はファイアウォール) を使って AKS クラスターの送信トラフィックを制御している場合 (たとえば、仮想アプライアンスには AKS クラスターのサブネットで適用されるルート テーブルがあり、ルート テーブルには仮想アプライアンスに向けてトラフィックを送信するルートがある)、仮想アプライアンスは AKS クラスターとストレージ アカウント間のトラフィックをブロックする可能性があります。

問題を切り分けるために、ストレージ アカウントの IP アドレスのルート テーブルに、トラフィックをインターネットに送信するルートを追加します。

どのルート テーブルが AKS クラスターのトラフィックを制御しているかを確認するために、以下の手順を実行します。

  1. Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソース グループを選択します。
  2. VMSS または可用性セット内の仮想マシン (VM) (そのような VM セットの種類を使っている場合) にアクセスします。
  3. 仮想ネットワーク/サブネット>Subnets を選択し、AKS クラスターのサブネットを識別します。 右側にルート テーブルが表示されます。

ルート テーブルにルートを追加するには、「ルートの作成」の手順に従って次のフィールドに入力します。

  • アドレス プレフィックス: <storage-account's-public-IP>/32
  • 次ホップの種類:インターネット

このルートからは、AKS クラスターとストレージ アカウント間のすべてのトラフィックがパブリック インターネットを介して送信されます。

このルートを追加したら、nc または telnet コマンドを使って接続をテストし、マウント操作をもう一度実行します。

解決策: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックを許可していることを確認する

マウント操作に成功した場合は、ネットワーク チームに相談して、仮想アプライアンスがポート 443 で AKS クラスターとストレージ アカウント間のトラフィックを許可できることを確認することをお勧めします。

NFS 3.0 エラー 1: 終了ステータス 32。 を開けませんでした 原因: ファイルまたはディレクトリが存在しません

原因: BLOB コンテナーが存在しない

BLOB コンテナーが存在するかどうかを確認するには、以下の手順を実行します。

  1. Azure portal で Storage アカウント を検索し、ストレージ アカウントにアクセスします。

    ストレージ アカウントを検索する方法を示すスクリーンショット。

  2. ストレージ アカウントの [Data storage で Containers を選択し、関連付けられている PersistentVolume (PV) が Containers に存在するかどうかを確認します。 永続ボリューム (PV) を確認するには、YAML ファイルでポッドに関連付けられた永続ボリューム要求 (PVC) を確認し、その PVC にどの PV が関連付けられているかを確認します。

    永続ボリューム要求 (PVC) を示すスクリーンショット。

解決策: BLOB コンテナーが存在することを確認する

この問題を解決するには、PV/PVC に関連付けられた BLOB コンテナーが存在することを確認します。

NFS 3.0 エラー 2: 終了状態 32、マウント中にサーバーによってアクセスが拒否されました

原因: このストレージ アカウントに AKS の VNET とサブネットは許可されていない

ストレージ アカウントのネットワークを選んだネットワークに限定している場合、その選んだネットワークに AKS クラスターの VNET とサブネットを追加していないと、マウント操作は失敗します。

解決策: ストレージ アカウントに AKS の VNET とサブネットを許可する

  1. 次のコマンドを実行して、障害のあるポッドをホストするノードを特定します。

    kubectl get pod <pod-name> -n <namespace> -o wide

    コマンド出力のノードを確認します。

  2. Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソース グループを選択しノードに関連付けられている VMSS にアクセスし、 仮想ネットワーク/サブネット を確認して、VNET とサブネットを識別します。

    VNET とサブネットのスクリーンショット。

  3. Azure portal でストレージ アカウントにアクセスし、 Networking を選択します。 パブリック ネットワーク アクセス選択した仮想ネットワークから有効に設定されている場合または Disabled 接続がプライベート エンドポイント経由でない場合は、AKS クラスターの VNET とサブネットが Firewalls と仮想ネットワークで許可されているかどうかを確認。

    [ファイアウォールと仮想ネットワーク] の設定のスクリーンショット。

    AKS クラスターの VNET とサブネットが追加されていない場合は、 既存の仮想ネットワークの追加を選択します。 ネットワークの追加 ページで、AKS クラスターの VNET とサブネットを入力し、追加>保存を選択します。

    [ネットワークの追加] ダイアログのスクリーンショット。

    変更が有効になるまでに数分かかる場合があります。 VNET とサブネットが追加されたら、ポッドの状態が ContainerCreating から Running に変わるかどうかを確認します。

    ポッドの状態のスクリーンショット。

NFS 3.0 エラー 3: コンテキストの期限を超えました/指定されたボリューム ID <...> を持つ操作が既に存在します

このエラーの原因として、次のことが考えられます。

NFS 3.0 エラー 3 の初期トラブルシューティング

Azure Blob NFS 3.0 は、ポート 111 と 2049に依存しています。 ポート 111 と 2049、またはストレージ アカウントの IP アドレスがブロックされていないことを確認します。

ストレージ アカウントの IP アドレスを確認するには、nslookup、dig、host などのドメイン ネーム システム (DNS) コマンドを実行します。 例えば次が挙げられます。

nslookup <storage-account-name>.blob.core.windows.net

AKS クラスターとストレージ アカウント間に接続があるかどうかを確認するには、ノードまたはポッド内に移動し、次の nc または telnet コマンドを実行します。

nc -v -w 2 <storage-account-name>.blob.core.windows.net 111

nc -v -w 2 <storage-account-name>.blob.core.windows.net 2049

telnet <storage-account-name>.blob.core.windows.net 111

telnet <storage-account-name>.blob.core.windows.net 2049

原因 1: ネットワーク セキュリティ グループが AKS とストレージ アカウント間のトラフィックをブロックしている

NFS 3.0 エラー 3 のInitial トラブルシューティングのセクションで説明されているncまたはtelnetコマンドの出力確認します。 タイムアウトが表示された場合は、ネットワーク セキュリティ グループ (NSG) を確認し、ストレージ アカウントの IP アドレスがブロックされていないことを確認します。

NSG がストレージ アカウントの IP アドレスをブロックしているかどうかを確認するには、以下の手順を実行します。

  1. Azure portal で、 Network Watcher に移動し NSG 診断 選択。

  2. フィールドに次の値を入力します。

    • プロトコル: TCP
    • 方向: 送信
    • ソースの種類: IPv4 アドレス/CIDR
    • IPv4 アドレス/CIDR: AKS ノードに関連付けられているインスタンスの IP アドレス
    • 宛先 IP アドレス: ストレージ アカウントの IP アドレス
    • 宛先ポート: 111、2048

  3. Check ボタンを選択し、Traffic 状態を確認します。

Trafficの状態は、AllowedまたはDeniedできます。 Denied状態は、NSG が AKS クラスターとストレージ アカウント間のトラフィックをブロックしていることを意味します。 状態が Denied の場合、NSG 名が表示されます。

解決策: AKS とストレージ アカウント間の接続を許可する

この問題を解決するには、NSG レベルで適宜変更を加えて、ポート 111/2048 での AKS クラスターとストレージ アカウント間の接続を許可します。

原因 2: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックをブロックしている

仮想アプライアンス (通常はファイアウォール) を使って AKS クラスターの送信トラフィックを制御している場合 (たとえば、仮想アプライアンスには AKS クラスターのサブネットで適用されるルート テーブルがあり、ルート テーブルには仮想アプライアンスに向けてトラフィックを送信するルートがある)、仮想アプライアンスは AKS クラスターとストレージ アカウント間のトラフィックをブロックする可能性があります。

問題を切り分けるために、ストレージ アカウントの IP アドレスのルート テーブルに、トラフィックをインターネットに送信するルートを追加します。

どのルート テーブルが AKS クラスターのトラフィックを制御しているかを確認するために、以下の手順を実行します。

  1. Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソース グループを選択します。

  2. 仮想マシン スケール セット (VMSS) または可用性セット内の VM (そのような VM セットの種類を使っている場合) にアクセスします。

  3. 仮想ネットワーク/サブネット>Subnets を選択し、AKS クラスターのサブネットを識別します。 右側にルート テーブルが表示されます。

ルート テーブルにルートを追加するには、「ルートの作成」の手順に従って次のフィールドに入力します。

  • アドレス プレフィックス: <storage-account's-public-IP>/32
  • 次ホップの種類: インターネット

このルートからは、AKS クラスターとストレージ アカウント間のすべてのトラフィックがパブリック インターネットを介して送信されます。

このルートを追加したら、nc または telnet コマンドを使って接続をテストし、マウント操作をもう一度実行します。

解決策: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックを許可していることを確認する

マウント操作が成功した場合は、ネットワーク チームに問い合わせて、AKS クラスターとポート 111 と 2049 のストレージ アカウント間のトラフィックを仮想アプライアンスが許可できることを確認することをお勧めします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。