AKS Arc のインストール中の問題とエラーを解決する

このエラーメッセージは Install-AksHci の実行後に表示されます。

Private Link を使用していない場合、この問題を解決するには、次の手順を使用します。

1. PowerShell を開き、Uninstall-AksHci を実行します。
2. Azure portal を開き、Install-AksHci の実行時に使用したリソース グループに移動します。
3. [切断] 状態で表示される接続済みのクラスター リソースを確認し、ランダムに生成された GUID として表示される名前を含めます。
4. これらのクラスター リソースを削除します。
5. PowerShell セッションを閉じ、新しいセッションを開いてから、Install-AksHci をもう一度実行します。

このエラーは、インストール プロセスが、Azure Arc オンボード プロセス中に提供された Azure サブスクリプションまたはリソース グループに設定されている Azure ポリシーに違反しようとしたことが原因で発生する可能性があります。 このエラーは、サブスクリプションまたはリソース グループ レベルで Azure ポリシーを定義した後、Azure Policy に違反する AKS を Azure Local にインストールしようとしたユーザーに対して発生する可能性があります。

この問題を解決するには、エラー メッセージを読んで、Azure 管理者によって設定された Azure Policy が違反したことを理解し、Azure ポリシーの例外を作成して Azure ポリシーを変更します。 Policy の例外の詳細については、「Azure Policy 適用除外の構造」を参照してください。

以前にインストールされた機能が失敗した状態のままであり、クリアされていません。 次のエラーがに表示される場合があります。

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

または、次のエラーが表示されることがあります。

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

この問題を解決するには、クラスター ロールを手動でクリーンアップします。 フェールオーバー クラスター マネージャーからリソースを削除するには、次の PowerShell コマンドレットを実行します: Remove-ClusterResource -name <resource name>。

Install-AksHci コマンドレットは、"API 呼び出しによって返される GetRelease エラー: ファイル ダウンロード エラー: ハッシュの不一致" で失敗します。

1. PowerShell を開いて、Uninstall-AksHci を実行します。
2. インストールを再試行します。
3. 問題が解決しない場合は、Set-AksHciConfig -concurrentDownloads パラメーターを使用しインストールを再試行する前に、既定値の 10 より小さい数値に設定します。 同時ダウンロードの数を減らすと、機密性の高いネットワークが大きなファイルのダウンロードを正常に完了するのに役立つ場合があります。 このパラメーターはプレビュー機能です。

デプロイ後、Azure ローカル ノードを再起動すると、AKS レポートに課金の失敗した状態が表示されます。

この問題を解決するには、手動でトークンをローテーションし、KMS プラグインを再起動する手順に従います。

Install-AksHci を実行した後、インストールが停止し、以下のエラー メッセージが表示されました。

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
connectex: A connection attempt failed because the connected party 
did not properly respond after a period of time, or established connection 
failed because connected host has failed to respond.]

waiting for API server というエラーでインストールが失敗する理由は複数あります。

次のセクションでは、このエラーの考えられる原因と解決策について説明します。

理由 1: IP ゲートウェイの構成が正しくありません 静的 IP アドレスを使用していて、次のエラー メッセージが表示された場合は、IP アドレスとゲートウェイの構成が正しいことを確認します。

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

IP アドレスとゲートウェイに適切な構成があるかどうかを確認するには、次のコマンドを実行します。

ipconfig /all

表示される構成設定で、構成を確認します。 IP ゲートウェイと DNS サーバーに対して ping を試行することもできます。

ping <DNS server>

これらのメソッドが機能しない場合は、 New-AksHciNetworkSetting を使用して構成を変更します。

理由 2: DNS サーバーが正しくありません 静的 IP アドレスを使用している場合は、DNS サーバーが正しく構成されていることを確認します。 ホストの DNS サーバーのアドレスを確認するには、次のコマンドを使用します。

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

次のコマンドを実行して、DNS サーバーのアドレスが、New-AksHciNetworkSetting の実行時に使用されるアドレスと同じであることを確認します。

Get-MocConfig

DNS サーバーが正しく構成されていない場合は、正しい DNS サーバーを使用して Azure Local に AKS を再インストールします。 詳細については、「 Azure Kubernetes Service on Azure Local での Azure Kubernetes Service の再開始、削除、または再インストール」を参照してください。

この問題は、構成を削除し、新しい構成で VM を再起動した後に解決されました。

Install-AksHci がこのエラーで失敗するのは、別のプロセスが mocstack.cab にアクセスしているためです。

この問題を解決するには、開いているすべての PowerShell ウィンドウを閉じてから、新しい PowerShell ウィンドウを再度開きます。

ファイルは別のプロセスで使用されているため、アクセスすることはできません。

この問題は、PowerShell セッションを再起動することで解決できます。 PowerShell ウィンドウを閉じて、Install-AksHci をもう一度試します。

Install-AksHci AKS on Azure Local 構成で指定された IP プールの範囲が CIDR で 1 オフになり、CloudAgent がクラッシュする可能性があるため、このエラーで失敗しました。 たとえば、アドレス範囲 10.0.0.0 - 10.0.7.255 のサブネット 10.0.0.0/21 があり、10.0.0.1 の開始アドレスまたは 10.0.7.254 の終了アドレスを使用した場合、CloudAgent のクラッシュが発生します。

この問題を回避するには、 New-AksHciNetworkSetting を実行し、VIP プールと Kubernetes ノード プールに対して他の有効な IP アドレス範囲を使用します。 使用する値が、アドレス範囲の先頭または末尾に 1 ずつオフにされていないことを確認します。

単一ノード セットアップで Install-AksHci を実行する場合、インストールは機能しますが、フェールオーバー クラスターを設定すると、インストールが失敗しエラー メッセージが表示されます。 ただし、クラウド エージェントに対して ping を実行すると、CloudAgent に到達可能であると示されます。

すべてのノードが CloudAgent の DNS を解決できることを確認するために、各ノードで次のコマンドを実行します。

Resolve-DnsName <FQDN of cloudagent>

上記の手順がノードで成功したら、ノードが CloudAgent ポートに到達できることを確認し、プロキシによってこの接続のブロックが試行されないこと、およびポートが開いていることを確認します。 これを行うには、各ノードで次のコマンドを実行します。

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

エラーは、ダウンロード時のエラーに起因します。

このエラーが発生した場合は、Microsoft Edge または Google Chrome の最新バージョンを使用して、もう一度お試しください。

このエラーは、AKS on Azure Local インストールで Set-AksHciRegistration を実行した後に表示されます。 このエラーは、Kubernetes リソース プロバイダーが、現在ログインしているテナントに登録されていないことを示します。

この問題を解決するには、下の Azure CLI または PowerShell の手順を実行します。

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

登録が完了するまで約 10 分かかります。 登録プロセスを監視するには、次のコマンドを使用します。

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci は、次の場合に、タイムアウトする前に Waiting for azure-arc-onboarding to complete でハングします。

• サービス プリンシパルは、AKS on Azure Local Registration (Set-AksHciRegistration) で使用されます。
• Az.Accounts PowerShell モジュールのバージョン (2.7.x) がインストールされている。

Az.Accounts 2.7.xバージョンでは、AKS on Azure Local for Azure Arc オンボードで使用される PSAzureRmAccount のServicePrincipalSecretとCertificatePasswordが削除されます。

再現方法:

1. Az.Accounts PowerShell モジュールのバージョン (2.7.0 以上) をインストールします。
2. サービス プリンシパルを使用して Set-AksHciRegistration を実行します。
3. Install-AksHci.

想定される動作:

1. AKS on Azure Local のインストールは、 Waiting for azure-arc-onboarding to completeでハングします。
2. Azure-arc-onboarding ポッドがクラッシュ ループに入ります。
3. Azure-arc-onboarding ポッドで次のエラーが発生します。
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

この問題を解決するには、次の手順を実行します。

バージョン 2.7.x の Az.Accounts モジュールをアンインストールします。次のコマンドレットを実行します。

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

このエラーは、Azure Local がポリシー外の場合に発生します。 クラスターでは接続状態が接続中と表示される場合がありますが、イベント ログには次のような警告メッセージが記録されています: Azure Local's subscription is expired, run Sync-AzureStackHCI to renew the subscription。

このエラーを解決するには、お使いのコンピューターで使用可能な Get-AzureStackHCI PowerShell コマンドレットを使用して、クラスターが Azure に登録されていることを確認します。 Windows Admin Center ダッシュボードにも、クラスターの Azure 登録に関する状態情報が表示されます。

クラスターが既に登録されている場合は、Get-AzureStackHCI の出力で LastConnected フィールドを確認する必要があります。 そのフィールドで 30 日以上経過していることが示されている場合は、Sync-AzureStackHCI コマンドレットを使用して、状況の解決を試みる必要があります。

次のコマンドレットを使用して、クラスターの各ノードに必要なライセンスがあるかどうかを検証することもできます。

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Local             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Sync-AzureStackHCI コマンドレットを実行しても問題が解決しない場合は、Microsoft サポートにご連絡ください。

この問題が発生するのは、インストールの失敗により、再インストールする前にクリーンアップする必要のあるリソースのリークが発生する場合があるためです。

Install-AksHci を使用してインストールが失敗した場合は、Install-AksHci をもう一度実行する前に、Uninstall-AksHci を実行する必要があります。

これらのエラーは、Set-AksHciConfig を最初に実行せずにInstall-AksHciを実行するときにトリガーできます。

このエラーを解決するには、uninstall-akshci を実行してすべての PowerShell ウィンドウを閉じます。 新しい PowerShell セッションを開き、 PowerShell を使用して Azure Local に AKS をインストールに従って、AKS on Azure Local のインストール プロセスを再起動します。

Set-AksHciConfig PowerShell コマンドレットは、次のエラーで失敗します。

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

プロキシ サーバーで AKS を使用している場合は、必要な HTTPS プロキシ URL 値を設定するときに間違った URL を使用している可能性があります。 プロキシ サーバーで AKS を構成する場合は、HTTP プロキシ URL と HTTPS プロキシ URL の値の両方が必要ですが、同じ HTTP プレフィックス付き URL を共有するには両方の値が必要になるのが一般的です。

ご利用の環境でこのような場合は、次の軽減手順を試してください。

1. PowerShell ウィンドウを閉じて、新しいウィンドウを開きます。
2. New-AksHciNetworkSettingを実行し、コマンドレットをもう一度New-AksHciProxySettingします。 New-AksHciProxySettingを実行する場合は、-httpに設定したのと同じ HTTP プレフィックス付き URL 値を使用して、-https パラメーターを設定します。
3. Set-AksHciConfigを実行して続行します。

Azure Local に AKS をデプロイすると、構成ミスが発生した場所に応じて、プロセスのさまざまな時点でデプロイがタイムアウトすることがあります。 エラー メッセージを確認して、原因と発生した場所を特定する必要があります。

たとえば次のエラーでは、構成の誤りが発生したポイントが Get-DownloadSdkRelease -Name "mocstack-stable" にあります。

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

これは、物理 Azure ローカル ノードがダウンロード URL の名前 ( msk8s.api.cdp.microsoft.com) を解決できるが、ノードがターゲット サーバーに接続できないことを示します。

この問題を解決するには、接続フローでブレークダウンが発生した場所を確認する必要があります。 物理クラスター ノードから問題を解決するには、次の手順を実行します。

1. 宛先の DNS 名を ping します: ping msk8s.api.cdp.microsoft.com
2. 応答が返されタイムアウトがない場合は、基本的なネットワーク パスが機能しています。
3. 接続がタイムアウトした場合は、データ パスにブレークが発生する可能性があります。 詳細については、プロキシ設定の確認に関するページを参照してください。 または、リターン パスに改行がある可能性があるので、ファイアウォール規則を確認する必要があります。

Set-AksHciConfigを実行すると、次のエラーが発生する場合があります。

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

通常、このエラーは、ユーザーのセキュリティ トークンが変更された (グループのメンバーシップが変更されたことが原因)、パスワードが変更された、またはパスワードの有効期限が切れた、という結果として発生します。 ほとんどの場合、この問題は、コンピューターからログオフしてから再度ログインすることで修復できます。 それでも問題が解決しない場合は、 GitHub AKS Azure Local の問題で問題を提出できます。

Moc エージェントは、最後の 100 個のエージェント ログのみを保持することが想定されています。 古いログは削除されるはずです。 しかし、ログのローテーションが行われず、ログが蓄積してディスク領域を圧迫しています。

再現方法: Install AksHci を実行してクラスターを起動し、エージェント ログの数が 100 を超えるまで実行します。 N 番目のログの作成時に、エージェントは N - 100 番目のログが存在する場合は削除します。

この問題を解決するには:

1. クラウド エージェントとノード エージェントの logconf ファイルを変更します。 クラウド エージェントの logconfig は次の場所にあります。
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   ノード エージェントの logconfig は次の場所にあります。
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Limit の値を 100 に、Slots を100に変更し、構成ファイルを保存します。

3. クラウド エージェントとノード エージェントを再起動して、これらの変更を登録します。

これらの手順により、エージェントの再起動から新しいログが 100 個作成された後にのみ、ログのローテーションが開始されます。 再起動時に既に N 個のエージェント ログがある場合、ログ ローテーションは N + 100 個のログが生成された後にのみ開始されます。

Set-AksHciConfig を使用する際に、D:\Cloud Share\AKS HCI などの空白文字を含むパス名で -imageDir、-workingDir、-cloudConfigLocation、または -nodeConfigLocation パラメーターを指定すると、クラウド エージェント クラスター サービスは起動に失敗し、次の (または同様の) エラー メッセージが表示されます。

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

この問題を回避するには、スペースを含まないパスを使用します。たとえば、C:\CloudShare\AKS-HCI のようにします。

このエラーは、インフラストラクチャの構成に誤りがある場合に、発生する可能性があります。

このエラーを解決するには、次の手順のようにします。

1. ホスト DNS サーバーの構成とゲートウェイの設定を確認します。

   1. DNS サーバーが正しく構成されていることを確認します。 ホストの DNS サーバーのアドレスを調べるには、次のコマンドを実行します:

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. IP アドレスとゲートウェイの構成が正しいかどうかを調べるには、ipconfig/all コマンドを実行します。
   3. IP ゲートウェイと DNS サーバーに対して ping を試します。

2. CloudAgent サービスを調べて、実行されていることを確認します。

   1. CloudAgent サービスに対して ping を実行し、到達可能であることを確認します。
   2. 各ノードで次のコマンドを実行して、すべてのノードが CloudAgent の DNS を解決できることを確認します。

      Resolve-DnsName <FQDN of cloudagent>
      

   3. ノードで上のステップが成功したら、ノードが CloudAgent ポートに到達できることを調べて、プロキシがこの接続をブロックしようとしていないこと、およびポートが開いていることを確認します。 これを行うには、各ノードで次のコマンドを実行します:

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. クラスター サービスがフェールオーバー クラスターで実行されているかどうかを確認するには、次のコマンドを実行することもできます。

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

これは通常、Active Directory ドメイン Services (AD DS) の基になるフェールオーバー クラスターを表すクラスター名オブジェクト (CNO) に、組織単位 (OU) またはクラスターが存在するコンテナーに仮想コンピューター オブジェクト (VCO) を作成するためのアクセス許可がないことを示します。

ドメイン管理者でない場合は、OU に対する CNO アクセス許可を に付与するか クラウド エージェント 汎用クラスター サービスの VCO を に設定するように依頼。

ドメイン管理者の場合でも、OU またはコンテナーに必要なアクセス許可がない可能性があります。 たとえば、 KB5008383で導入された強制モードは、Active Directory で有効にすることができます。 再インストールを試みる前に、次の手順を試してください。

1. Active Directory ユーザーとコンピューターに移動します。
2. クラスターが存在する OU またはコンテナーを右クリックします。
3. Delegate Control... を選択して、コントロールの削除ウィザードを開きます。
4. [次へ ] をクリック> [追加]... をクリックして、[ユーザー、コンピューター、またはグループの 選択 ウィンドウを開きます。
5. コントロールを委任するグループまたはユーザーの選択 > クリック OK。
6. [委任するカスタム タスクを作成する] を選択> [次へ] をクリックActive Directory オブジェクトの種類 ページに移動します。
7. フォルダー内の次のオブジェクトをオンにします> Computer オブジェクトを選択>このフォルダー内の選択したオブジェクト作成しこのフォルダー内の選択したオブジェクトを削除>次のに移動するには、[ 次へをクリックします] ページに移動します。
8. [すべての子オブジェクトの作成]選択しすべての子オブジェクトを削除しますアクセス許可の一覧からクリック >次へ>Finish

再インストールが失敗した場合は、手順 7 と 8 に次の変更を加えて上記を再試行してください。

• 手順 7: このフォルダー、このフォルダー内の既存のオブジェクト、およびこのフォルダー内の新しいオブジェクトの作成を選択します> 次へ] をクリック。
• 手順 8: アクセス許可の一覧から Read、Write、すべての子オブジェクトの作成、および すべての子オブジェクトの削除>次へをクリック> Finish をクリックします。

このエラーは、 Install-AksHci の実行時に発生する可能性があります。

詳細については、 $error = Install-AksHci を実行してから $error[0].Exception.InnerExceptionします。

PowerShell コマンド Aks-Hci では、Kubernetes ノードを作成する前に、ホスト サーバーで使用可能なメモリが確認されません。 この問題により、メモリ不足に至り、仮想マシンが起動しなくなる可能性があります。 このエラーは、現在正しく処理されておらず、明確なエラー メッセージを示さずにデプロイが応答しなくなります。

デプロイが応答しなくなった場合は、イベント ビューアーを開き、VM を起動するのに十分なメモリがないことを示す Hyper-V 関連のエラー メッセージがないか調べます。

このエラーは、Azure アカウントに複数のテナントがある場合に発生することがあります。

$tenantId = (Get-AzContext).Tenant.Id を使用して、適切なテナントを設定します。 次に、Set-AksHciRegistration の実行中に、このテナントをパラメーターとして含めます。

Azure VM に AKS クラスターをデプロイしようとすると、インストールが Waiting for pod 'Cloud Operator' to be ready...で停止し、2 時間後に失敗してタイムアウトしました。 トラブルシューティングでゲートウェイと DNS サーバーを確認してみましたが、正常に動作していました。 IP アドレスまたは MAC アドレスの競合が見つからなかったかどうかを確認します。 ログに VIP プールが表示されませんでした。 sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 を使用してコンテナー イメージをプルする際、"権限がありません" の代わりに、トランスポート層セキュリティ (TLS) のタイムアウトが返されるという制限がありました。

この問題を解決するには、次の手順を実行します。

1. クラスターのデプロイを開始します。
2. クラスターがデプロイされたら、次に示すように、SSH 経由で管理クラスター VM に接続します。

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. 最大転送単位 (MTU) 設定を変更します。 変更を行うことをお気軽にお問い合わせ下さい。変更を遅くした場合、デプロイは失敗します。 MTU 設定を変更すると、コンテナー イメージ プルのブロックが解除されます。

sudo ifconfig eth0 mtu 1300

4. コンテナーの状態を表示するために、次のコマンドを実行します。

sudo docker ps -a

これらの手順を実行した後、コンテナー イメージのプルのブロックを解除する必要があります。

このエラーは、クラウド サービスの IP アドレスがクラスター ネットワークの一部ではなく、client and cluster communication ロールが有効になっているどのクラスター ネットワークとも一致しないことを示します。

この問題を解決するには、Role が ClusterAndClient である場所で Get-ClusterNetwork を実行します。 次に、いずれかのクラスター ノードで、名前、アドレス、アドレス マスクを選択して、New-AksHciNetworkSetting の -cloudServiceIP パラメーターに指定した IP アドレスが、表示されたネットワークのいずれかと一致することを確認します。

Enable-AksHciArcConnection は AKS クラスターを Azure に接続できますが、顧客が認証にサービス プリンシパルを使用すると、次の警告が表示されます。

WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS on Azure Local cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

Arc オンボードの現在の動作は、既定でカスタムの場所を有効にすることです。 カスタムの場所を有効にするには、ログインしている Azure ユーザーのコンテキストで GetServicePrincipals アクションが実行されます。 ユーザー (または SPN) にこれを実行できる十分なアクセス許可がない場合、コマンドは、これらのアクセス許可が存在しないため、カスタムの場所機能が有効にならないという警告を発行します。

カスタムの場所を有効にしない場合は、Arc へのクラスターオンボードには影響しないため、この警告は無視しても問題ありません。一方、カスタムの場所を有効にする必要がある場合は、ユーザー (または SPN) に必要なアクセス許可を付与する必要があります。

次のステップ

• トラブルシューティングの概要
• Windows Admin Center の既知の問題
• Kubernetes クラスターのトラブルシューティング

AKS Arc を使用しているときに問題が引き続き発生する場合は、 GitHub を使用してバグを報告できます。