Azure Container Storage のトラブルシューティング
Azure Container Storage は、コンテナー用にネイティブに構築されたクラウドベースのボリューム管理、デプロイ、オーケストレーション サービスです。 この記事を使用して、Azure Container Storage の一般的な問題をトラブルシューティングし、問題の解決策を見つけます。
インストールの問題をトラブルシューティングする
Azure Container Storage のインストールに失敗しました
az aks create を実行した後、Azure Container Storage のインストールに失敗しました。AKS クラスターが作成されます。az aks update と --enable-azure-container-storage を実行して、Azure Container Storage を有効にしてください。
このメッセージは、Azure Container Storage がインストールされなかったことを意味しますが、AKS クラスターは正しく作成されています。
Azure Container Storage をクラスターにインストールしてストレージ プールを作成するには、次のコマンドを実行します。 <cluster-name> と <resource-group> を独自の値に置き換えます。 <storage-pool-type> を、azureDisk、ephemeraldisk、または elasticSan に置き換えます。
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
ストレージ プールの種類を NVMe に設定できない
仮想マシン (VM) SKU に NVMe ドライブがないクラスターに、Azure Container Storage をエフェメラル ディスク、特にローカル NVMe でインストールしようとすると、次のようなエラー メッセージが表示されます: どのノードプールもエフェメラル NVMe ディスクをサポートできないため、--storage-pool-option を NVMe として設定できません。
修復するには、NVMe ドライブを持つ VM SKU でノード プールを作成し、再試行してください。 ストレージ最適化 VM を参照してください。
ストレージ プールに関する問題のトラブルシューティング
ストレージ プールの状態を確認するには、kubectl describe sp <storage-pool-name> -n acstor を実行します。 発生する可能性のあるいくつかの問題を次に示します。
Azure Disks ストレージ プールを拡張しようとする際のエラー
既存のストレージ プールが 4 TiB (4,096 GiB) 未満の場合は、最大 4,095 GiB までしか拡張できません。 それを超えて拡張しようとすると、内部 PVC には次のようなエラー メッセージが表示されます: "4095 GB より大きいサイズのディスクでサポートされている Disk CachingType は 'None' だけです" または "サイズが 4096 GB (<=4096 GB) であるディスク 'xxx' は、実行中の VM にアタッチされた状態では 16384 GB (>4096 GB) にサイズ変更できません。 VM を停止するか、ディスクをデタッチして操作を再試行してください。"
エラーを回避するために、現在のストレージ プールが最初に 4 TiB (4,096 GiB) より小さい場合は、4,095 GiB を超えて拡張しようとすることは控えてください。 4 TiB より大きいストレージ プールは、利用可能な最大ストレージ容量まで拡張できます。
この制限が適用されるのは Premium_LRS、Standard_LRS、StandardSSD_LRS、Premium_ZRS、StandardSSD_ZRS のディスク SKU を使用する場合だけです。
Elastic SAN の作成に失敗する
Elastic SAN ストレージ プールを作成しようとしている場合、Azure Elastic SAN の作成に失敗する: サブスクリプションの Elastic SAN の最大可能数は既に作成されています。 これは、サブスクリプションごとにリージョンにデプロイできる Elastic SAN リソースの数が上限に達したことを意味します。 以下で制限を確認できます: Elastic SAN のスケーラビリティとパフォーマンスのターゲット。 サブスクリプションの既存の Elastic SAN リソースのうち、使用されていないものを削除するか、別のリージョンにストレージ プールを作成することを検討してください。
ブロック デバイスが見つかりません
このメッセージが表示された場合は、VM SKU に NVMe ドライブがないクラスター上でエフェメラル ディスク ストレージ プールを作成しようとしている可能性があります。
修復するには、NVMe ドライブを持つ VM SKU でノード プールを作成し、再試行してください。 「ストレージ最適化 VM」を参照してください。
ストレージ プールの種類は既に有効です
既に有効になっているストレージ プールの種類を有効にしようとすると、次のメッセージが表示されます: --enable-azure-container-storage 値が無効です。Azure Container Storage は、クラスター内のストレージ プールの種類 <storage-pool-type> で既に有効になっています。 kubectl get sp -n acstor を実行することで、既存のストレージ プールが作成されているかどうかを確認できます。
ストレージ プールの種類の無効化
az aks update --disable-azure-container-storage <storage-pool-type> を介してストレージ プールの種類を無効にする場合、または az aks update --disable-azure-container-storage all を介して Azure Container Storage をアンインストールする場合、その種類の既存のストレージ プールがあると、次のメッセージが表示されます。
ストレージ プールの種類 <storage-pool-type> の Azure Container Storage を無効にすると、同種のすべてのストレージ プールが強制的に削除され、これらのストレージ プールを使用しているアプリケーションに影響があります。 ストレージ プールを強制的に削除すると、消費されているストレージ リソースが流出する可能性もあります。 Azure Container Storage を無効にする前に、種類 <storage-pool-type> のストレージ プールが使用されているかどうかを検証する必要がありますか? (Y/n)
Y を選択すると、自動検証が実行され、ストレージ プールから作成された永続ボリュームがないことが確認されます。 n を選択すると、この検証がバイパスされ、ストレージ プールの種類が無効になり、既存のストレージ プールが削除され、アプリケーションに影響を与える可能性があります。
AKS クラスターを含むリソース グループを削除できない
Elastic SAN ストレージ プールを作成した場合、AKS クラスターが配置されているリソース グループを削除できない場合があります。
これを解決するには、Azure portal にサインインし、[リソース グループ] を選択します。 AKS によって作成されたリソース グループを探します (リソース グループ名が MC_ で始まります)。 そのリソース グループ内の SAN リソース オブジェクトを選択します。 すべてのボリュームとボリューム グループを手動で削除します。 次に、AKS クラスターを含むリソース グループの削除を再試行します。
ボリュームの問題のトラブルシューティング
エフェメラル ボリュームのサイズが空き容量を超えているため、ポッドの作成は保留されています
エフェメラル ボリュームは単一ノードに割り当てられます。 ポッドのエフェメラル ボリュームのサイズを構成する場合、そのサイズを単一ノードのエフェメラル ディスクの空き容量より小さくする必要があります。 それ以外の場合、ポッドの作成は保留状態になります。
次のコマンドを使用して、ポッドの作成が保留中の状態かどうかを確認します。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
この例で、ポッド fiopod は Pending 状態です。
次のコマンドを使用して、ポッドに persistentvolumeclaim 作成の警告イベントがあるかどうかを確認します。
$ kubectl describe pod fiopod
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s default-scheduler 0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..
この例では、ポッドには永続ボリューム要求 fiopod-ephemeralvolume の作成に関する警告イベントが表示されます。
次のコマンドを使用して、容量不足が原因で永続ボリューム要求のプロビジョニングに失敗するかどうかを確認します。
$ kubectl describe pvc fiopod-ephemeralvolume
...
Warning ProvisioningFailed 107s (x13 over 20m) containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")
この例では、ボリューム プロビジョニングの失敗の理由として Insufficient Storage が示されています。
次のコマンドを実行して、単一ノードのエフェメラル ディスクの空き容量を確認します。
$ kubectl get diskpool -n acstor
NAME CAPACITY AVAILABLE USED RESERVED READY AGE
ephemeraldisk-temp-diskpool-jaxwb 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-wzixx 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-xbtlj 75660001280 75031990272 628011008 560902144 True 21h
この例では、単一ノードの一時ディスクの空き容量は、75031990272 バイト (つまり 69 GiB) です。
ボリューム ストレージ サイズを空き容量未満に調整し、ポッドを再デプロイします。 「汎用エフェメラル ボリュームを使用してポッドをデプロイする」を参照してください。
メタデータ ストアがオフラインであるため、ボリュームがアタッチに失敗する
Azure コンテナー ストレージは、分散された信頼性の高いキーと値のストアである etcd を使用して、ボリュームのメタデータを保存して管理し、ボリューム オーケストレーション操作をサポートします。 高可用性と回復性のために、etcd は 3 つのポッド内で実行されます。 実行中の etcd インスタンスが 2 つ未満の場合、Azure コンテナー ストレージはボリューム オーケストレーション操作を停止しますが、ボリュームへのデータ アクセスは引き続き許可します。 Azure コンテナー ストレージは、etcd インスタンスがオフラインであることを自動的に検出し、それを復元します。 しかし、AKS クラスターの再起動後にボリューム オーケストレーション エラーが発生した場合は、etcd インスタンスが自動回復に失敗した可能性があります。 このセクションの手順に従って、etcd インスタンスの正常性状態を確認してください。
次のコマンドを実行して、ポッドの一覧を取得します。
kubectl get pods
次のような出力が表示されます。
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
次のようにポッドを describe します。
kubectl describe pod fiopod
メタデータ ストアがオフラインの場合は通常、ボリューム エラー メッセージが表示されます。 この例では、fiopod は ContainerCreating 状態であり、FailedAttachVolume 警告は、ボリューム アタッチ エラーが原因で作成が保留中であることを示します。
Name: fiopod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009
Warning FailedAttachVolume 3m8s (x6 over 23m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
次のコマンドを実行して、etcd インスタンスの状態を確認することもできます。
kubectl get pods -n acstor | grep "^etcd"
すべてのインスタンスが Running 状態となっている次のような出力が表示されるはずです。
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
Running 状態として表示されるインスタンスが 2 つ未満である場合は、メタデータ ストアがオフラインであることが原因でボリュームがアタッチに失敗しており、自動回復が成功しなかったと結論付けることができます。 これに該当する場合は、Azure サポートでサポート チケットを提出してください。