Azure SQL Database
Azure リレーショナル データベース サービス。
AKSの永続ボリューム要求イベントでLinkedAuthorizationFailedが発生
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(99.2, 75%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET%3C/text%3E%3C/svg%3E)
TA
0
評価のポイント
前提
AKSに対し、下記①②の操作を行いました。
①Kubernetes バージョン1.31.3 から 1.32.4 にアップグレード
→podは全起動しました
②定義の再リリース
→一部のpodが起動しない状態となっております。
→②を複数回行っても現象は同じです
同構成の環境で同様の操作をしておりますが、現象が発生しているのは１環境のみです。
②での永続ボリューム要求で発生しているWarningイベント内のメッセージは下記となります。
failed to provision volume with StorageClass "<ストレージクラス１>": rpc error: code = Internal desc = update service endpoints failed with error: failed to update the subnet <サブネット２> under vnet <仮想ネットワーク１>: PUT http://localhost:7788/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ１>/providers/Microsoft.Network/virtualNetworks/<仮想ネットワーク１>/subnets/<サブネット２>
--------------------------------------------------------------------------------
RESPONSE 403: 403 Forbidden
ERROR CODE: LinkedAuthorizationFailed
--------------------------------------------------------------------------------
{
"error": {
"code": "LinkedAuthorizationFailed",
"message": "The client 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' with object id 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' has permission to perform action 'Microsoft.Network/virtualNetworks/subnets/write' on scope '/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ１>/providers/Microsoft.Network/virtualNetworks/<仮想ネットワーク１>/subnets/<サブネット２>'; however, it does not have permission to perform action(s) 'Microsoft.Network/routeTables/join/action' on the linked scope(s) '/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ２（名称は mc_リソースグループ１_サブネット２_リージョン の組み合わせ）>/providers/Microsoft.Network/routeTables/aks-agentpool-XXXXXXXX-routetable' (respectively) or the linked scope(s) are invalid."
}
}
LinkedAuthorizationFailedとありますが、メッセージ内に、対象AKSとは別環境となるサブネットが記載されておりました。元々接続を想定していないサブネットとなります。
定義内容を確認しましたが、 永続ボリューム要求、永続ボリューム、ストレージクラスのYAMLでは サブネットの設定項目はありませんでした。
またストレージ関連が同構成の別環境では問題が発生しておりません。
kubernetes masterに何か問題が発生しているのではないかと考えております。
確認事項
現象を確認いただき、原因のご教示およびAzure内部の問題であれば復旧をお願いいたします。
また、こちらで対応可能な事項がございましたらご教示をお願いいたします。
※本質問の「子タグ」の「Azure SQL Database」は単一選択肢の必須項目のため指定しております。
Azure SQL Database
{count} 件の投票
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 65%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAM%3C/text%3E%3C/svg%3E)
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター2025-06-13T12:05:38.4033333+00:00 こんにちは TA
2 回目の操作で、AKS は StorageClass を使用して永続ボリュームのプロビジョニングを試みましたが、特定の環境で失敗しています。
この問題は、AKS がサブネットを更新してルートテーブルをアタッチしようとしていることに関連しているようです。サブネットを変更する権限はありますが、そのサブネットにルートテーブルを関連付けるために必要な権限がありません。
この環境では、必要な権限が不足しているようです。具体的には、サブネットがマネージド クラスター リソース グループに属し、AKS クラスターが別のリソース グループに属している場合、AKS マネージド ID にはネットワーク共同作成者ロールが必要です。
AKS がボリュームをプロビジョニングする際に、サブネット構成の更新が必要になる場合があります。サブネットがルートテーブルに関連付けられている場合、AKS はそのルートテーブルに参加するための権限も必要です。この権限がないと、サブネットの更新は失敗し、ボリュームのプロビジョニングがブロックされます。
この問題を解決するには、AKS マネージド ID にルートテーブルに対する Microsoft.Network/routeTables/join/action 権限が付与されていることを確認してください。
こちらのドキュメントをご参照ください。
https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/error-codes/linkedauthorizationfailed-error他にご質問がございましたら、お知らせください。情報がお役に立てば、「賛成票」をクリックしてください。
ありがとうございます。
-
TA 0 評価のポイント
2025-06-16T04:43:18.06+00:00 ご連絡ありがとうございます。 補足説明させていただきます。
発生していること：
(1) 永続ボリューム要求にて対象AKSに関連しないサブネットおよびルートテーブルに接続試行（想定しない動作）
(2) (1)によりLinkedAuthorizationFailedが発生実現したいこと：
(1) で対象AKSに関連するサブネット及びルートテーブルに接続することで(2)を解消する以上、よろしくお願いいたします。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-16T16:10:12.59+00:00 こんにちは TA
こちらが日本語訳です：
元のサブネットではなく、PVCが異なるサブネットとその関連するルートテーブルに接続しようとしていることを理解しています。
エラー「LinkedAuthorizationFailed」に基づくと、問題はKubernetesマスターにはないことがわかります。
ストレージクラスを確認してください：
kubectl get storageclass -o yaml
ストレージクラス内で、次のようなパラメータ（networkResourceGroup、subnet）を確認してください：例：
parameters:networkResourceGroup: "<your-network-resource-group>"
subnetName: "<your-subnet-name>"
プライベートエンドポイントを使用している場合：
ストレージや他のリソースが間違ったサブネットを使用している可能性があるため、プライベートエンドポイントを確認してください。
az network private-endpoint list --resource-group <your-rg> --output tableAKSノードプールのサブネット関連付けを確認してください：
az aks show --resource-group <aks-rg> --name <aks-cluster-name> --query "agentPoolProfiles[].vnetSubnetId"AKSノードプールが正しいサブネットにあることを確認してください。
ルートテーブルの関連付けを確認してください：
az network vnet subnet show \--vnet-name <vnetname> \
--name <subnetname> \
--resource-group <resourcegroup> \
--query "routeTable | {id: id, resourceGroup: resourceGroup}"
ポッドのイベントとログを共有してください。
質問があれば、お気軽にお問い合わせください。お手伝いさせていただきます。
-
TA 0 評価のポイント
2025-06-17T07:01:13.2533333+00:00 ご対応ありがとうございます。
以下、回答いたします。> ストレージクラスを確認してください： kubectl get storageclass -o yaml出力結果に networkResourceGroup、subnet の記載は存在しませんでした。
ストレージや他のリソースが間違ったサブネットを使用している可能性があるため、プライベートエンドポイントを確認してください。
> az network private-endpoint list --resource-group <リソースグループ１> --output table CustomNetworkInterfaceName Location Name ProvisioningState ResourceGroup ---------------------------- ---------- -------------------- ------------------- --------------- japaneast ＜エンドポイント１＞ Succeeded <リソースグループ１> japaneast ＜エンドポイント２＞ Succeeded <リソースグループ１> japanwest ＜エンドポイント３＞ Succeeded <リソースグループ１>※エンドポイント１，２、３は対象AKSおよびエラー出力のものとは異なる、ストレージ用のサブネットと紐づきます。
※エンドポイント３のみリージョンが異なりますAKSノードプールのサブネット関連付けを確認してください：
> az aks show --resource-group <リソースグループ１> --name ＜対象AKS＞ --query "agentPoolProfiles[].vnetSubnetId" [ "/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ１>/providers/Microsoft.Network/virtualNetworks/<仮想ネットワーク１>/subnets/<サブネット１>" ]※正しい内容となります。
※エラーで出力されているものとは異なるサブネットです。ルートテーブルの関連付けを確認してください：
> az network vnet subnet show ` >> --vnet-name <仮想ネットワーク１> ` >> --name <サブネット１> ` >> --resource-group <リソースグループ１> ` >> --query "routeTable | {id: id, resourceGroup: resourceGroup}" { "id": "/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ３（名称は：mc_リソースグループ１_サブネット１_リージョン の組み合わせ）>/providers/Microsoft.Network/routeTables/aks-agentpool-YYYYYYY-routetable", "resourceGroup": "<リソースグループ３（名称は：mc_リソースグループ１_サブネット１_リージョン の組み合わせ）>" }※正しい内容となります。
※エラーで出力されているものとは異なるリソースグループおよびルートテーブルです。ポッドのイベントとログを共有してください。
以下、抜粋となります。（時系列順）
＜イベント１＞ reason: NotTriggerScaleUp message: 'pod didn''t trigger scale-up: ' source: component: cluster-autoscaler type: Normal ＜イベント２＞ reason: FailedScheduling message: no nodes available to schedule pods source: component: default-scheduler type: Warning ＜イベント３＞ reason: NotTriggerScaleUp message: 'pod didn''t trigger scale-up: 1 not ready for scale-up' source: component: cluster-autoscaler type: Normal ＜イベント４＞ reason: FailedScheduling message: >- 0/4 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/4 nodes are available: 4 Preemption is not helpful for scheduling. source: component: default-scheduler type: Warning ＜イベント５＞ reason: FailedScheduling message: >- 0/5 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/5 nodes are available: 5 Preemption is not helpful for scheduling. source: component: default-scheduler type: Warning ＜イベント６＞ reason: NotTriggerScaleUp message: >- pod didn't trigger scale-up: 1 pod has unbound immediate PersistentVolumeClaims source: component: cluster-autoscaler type: Normal ＜イベント７＞ reason: FailedScheduling message: >- 0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/6 nodes are available: 6 Preemption is not helpful for scheduling. source: component: default-scheduler type: Warningよろしくお願いいたします。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-17T14:18:59+00:00 こんにちは TA
エラーログに従って
PVCの状態を確認する
kubectl get pvcPVCが「Bound」状態であることを確認してください。もし「Pending」の場合は、適切なPVを待機している可能性があります。
PVの確認
kubectl get pvPVCに必要なストレージクラスとサイズに一致するPVが利用可能かを確認してください。
ストレージクラスの問題
PVCがストレージクラスを指定している場合、そのストレージクラスに対応するPVが存在するか、または動的プロビジョニングが正しく設定されているかを確認してください。
ノードアフィニティとトレランス
もしポッドに特定のノードアフィニティ（タイント/トレランス）がある場合、それに適したノードが利用可能かを確認してください。
質問がある場合は、どうぞご連絡ください。お手伝いさせていただきます。
-
TA 0 評価のポイント
2025-06-18T07:14:42.7166667+00:00 ご対応ありがとうございます。
以下、確認結果を連携いたします。PVCの状態を確認する
PendingとなっているPVCが存在します。（イベント内でLinkedAuthorizationFailedが発生しているPVCとなります。）
PVの確認
PVCがPendingとなっているためPVが存在しません。（同ストレージクラスに対応する別のPVCによるPVは存在します）
ストレージクラスの問題
・PVCはストレージクラスを指定しています
・PVCがPendingとなっているためPVが存在しません。（同ストレージクラスに対応する別のPVCによるPVは存在します）
・ストレージクラスの動的プロビジョニングに不備は見られませんノードアフィニティとトレランス
Tolerations：起動済みノード全てのTaintsは「none」となっているため、関連するTolerationsはありません
nodeAffinity：定義がありません以上、よろしくお願いいたします。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-19T07:20:21.46+00:00 こんにちは TA
Azureでのストレージのプロビジョニングにおいて、KubernetesはCSI（Container Storage Interface）ドライバーを使用してPVC（Persistent Volume Claim）を作成しようとします。もしクラスターのマネージドIDがストレージがプロビジョニングされるAzureリソースグループに十分な権限を持っていない場合、問題が発生することがあります。
トラブルシューティングのために、次のコマンドを実行してStorageClassのイベントを確認します:
kubectl describe storageclass <storageclassname>動的プロビジョニングが無効になっている場合、それを有効にします。プロビジョナーは、Kubernetesに対して自動的にPV（Persistent Volume）を作成するよう指示します。
また、次のコマンドでPVCのイベントを確認してください:
kubectl describe pvc <pvcname>これにより、PVCがPVにバインドされない理由がわかります。一般的な原因としては以下が考えられます:
一致するPVがない
PVのストレージ容量が不足している
アクセスモードやストレージクラス名が一致していない
ノードリソースグループにディスクが作成されるため、マネージドIDに「Contributor」ロールを割り当てることを確認してください。
最後に、PVCの作成を再試行します。テストの一環であれば、古いPVCを削除してからPVCマニフェストを再適用することを検討してください。
関連する問題については、こちらのドキュメントを参照してください。
https://stackoverflow.com/questions/44120612/kubernetes-pvc-not-binding-the-nfs-pv
質問がある場合は、どうぞご連絡ください。お手伝いさせていただきます。
-
TA 0 評価のポイント
2025-06-19T13:22:51.64+00:00 ご対応ありがとうございます。
トラブルシューティングのために、次のコマンドを実行してStorageClassのイベントを確認します: kubectl describe storageclass <storageclassname>
イベントの抜粋となります。
> kubectl describe storageclass ＜対象のストレージクラス＞ ： Events: <none>また、次のコマンドでPVCのイベントを確認してください: kubectl describe pvc <pvcname>
イベントの抜粋となります。
WarningイベントのMessageは最初の質問に記載したものと同一になります。> kubectl describe pvc ＜対象の永続ボリューム要求＞ ： Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Provisioning 5m22s (x10 over 13m) file.csi.azure.com_csi-azurefile-controller-XXXXXXXXX-XXXXX_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX External provisioner is provisioning volume for claim "default/＜対象の永続ボリューム要求＞" Warning ProvisioningFailed 5m22s (x10 over 13m) file.csi.azure.com_csi-azurefile-controller-XXXXXXXXX-XXXXX_XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX failed to provision volume with StorageClass ""<ストレージクラス１>"": rpc error: code = Internal desc = update service endpoints failed with error: failed to update the subnet <サブネット２> under vnet <仮想ネットワーク１>: PUT http://localhost:7788/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ１>/providers/Microsoft.Network/virtualNetworks/<仮想ネットワーク１>/subnets/<サブネット２>" -------------------------------------------------------------------------------- RESPONSE 403: 403 Forbidden ERROR CODE: LinkedAuthorizationFailed -------------------------------------------------------------------------------- { "error": { "code": "LinkedAuthorizationFailed", "message": "The client 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' with object id 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' has permission to perform action 'Microsoft.Network/virtualNetworks/subnets/write' on scope '/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ１>/providers/Microsoft.Network/virtualNetworks/<仮想ネットワーク１>/subnets/<サブネット２>'; however, it does not have permission to perform action(s) 'Microsoft.Network/routeTables/join/action' on the linked scope(s) '/subscriptions/<サブスクリプション１のID>/resourceGroups/<リソースグループ２（名称は：mc_リソースグループ１_サブネット２_リージョン の組み合わせ）>/providers/Microsoft.Network/routeTables/aks-agentpool-XXXXXXXX-routetable' (respectively) or the linked scope(s) are invalid." } } -------------------------------------------------------------------------------- Normal ExternalProvisioning 3m54s (x42 over 13m) persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'file.csi.azure.com' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.ノードリソースグループにディスクが作成されるため、マネージドIDに「Contributor」ロールを割り当てることを確認してください。
Warningイベント記載のルートテーブルが存在する＜リソースグループ２＞には対象のAKSクラスター名のマネージドIDのロールは割り当てられておりません。（元々接続が予定されておりません）
本来、ストレージがプロビジョニングされる想定のリソースグループに、対象のAKSクラスター名のマネージドIDが「Contributor」（共同作成者）ロールで割り当てられていることを確認しました。
最後に、PVCの作成を再試行します。テストの一環であれば、古いPVCを削除してからPVCマニフェストを再適用することを検討してください。
最初の質問での「②定義の再リリース」にて実施済みの作業となります。
以上、よろしくお願いいたします。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-20T12:17:16.8133333+00:00 こんにちは TA
サービスエンドポイントの問題:Azure では、サブネットが Azure サービス（ストレージアカウントなど）に接続できるように、サービスエンドポイントを設定する必要があります。これは、Azure サービスが相互に直接通信するための「安全な扉」を開くようなものです。
アクセス許可の問題:
このエラーには、クライアント（ユーザーまたはサービス ID）に別のリソースグループのルートテーブルを変更する権限がないことも記載されています。
ルートテーブルはネットワーク内のトラフィックフローを制御するもので、権限がないために接続が停止しています。
Azure Storage のサービスエンドポイントが構成されていることを確認してください。
Azure Portal で仮想ネットワークを開き、サブネットを選択して [サービスエンドポイント] をクリックします。Kubernetes クラスターが Azure Storage にアクセスできるようにするには、サブネット上の Microsoft.Storage エンドポイントを有効にする必要があります。
ルートテーブルへのアクセス許可を付与するには、Kubernetes が使用しているユーザーまたはマネージド ID にネットワーク共同作成者ロールを割り当てることができます。
これらの変更を行った後、永続ボリュームのプロビジョニングを再度試してください。
質問がある場合は、どうぞご連絡ください。お手伝いさせていただきます。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-23T07:26:39.4633333+00:00 こんにちは TA
ご質問に対する回答をご確認いただけましたでしょうか？
ご不明な点がございましたら、いつでもお気軽にご連絡ください。
もしご回答がお役に立ちましたら、「アップボート」をクリックしていただき、回答を承認していただけると幸いです。ありがとうございます。
-
TA 0 評価のポイント
2025-06-23T09:49:04.98+00:00 ご対応ありがとうございます。
Azure Storage のサービスエンドポイントが構成されていることを確認してください
サブネットのサービスエンドポイントには Microsoft.Storage が設定されている状態となっておりました。
ルートテーブルへのアクセス許可を付与するには、Kubernetes が使用しているユーザーまたはマネージド ID にネットワーク共同作成者ロールを割り当てることができます。
こちら、付与対象はルートテーブルということでしょうか？
以上、よろしくお願いいたします。
-
Aslam Mohammad 405 評価のポイント Microsoft 外部スタッフ モデレーター
2025-06-23T16:41:52.01+00:00 こんにちは TA
いいえ、あなたが言及しているのはルートテーブルではなく、Azureのサブネット上のサービスエンドポイント構成です。
-
TA 0 評価のポイント
2025-06-24T10:21:36.6733333+00:00 ご対応ありがとうございます。
ルートテーブルへのアクセス許可を付与するには、Kubernetes が使用しているユーザーまたはマネージド ID にネットワーク共同作成者ロールを割り当てることができます。
ルートテーブルに関連付けられているサブネットを持つ仮想ネットワークに対して、Kubernetes が使用しているマネージド ID がネットワーク共同作成者ロールとして付与されておりました。
他、確認する項目はございますでしょうか。
よろしくお願いいたします。
サインインしてコメントする