AKS Arc でネットワークを構成するときの既知の問題とエラーを修正する

スペースを含むパス名を使用すると、クラウド エージェントを正常に開始できない場合があります。

Set-AksHciConfig を使用する際に、D:\Cloud Share\AKS HCI などの空白文字を含むパス名で 、-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 のようにします。

Azure Arc for Kubernetes に接続されたクラスターでは、JSON プロパティ distribution の値を空の文字列に設定できます。 AKS Arc 接続クラスターの場合、この値は初期インストール時に設定され、デプロイの有効期間中は変更されません。

問題を再現するには、Azure PowerShell ウィンドウを開き、次のコマンドを実行します。

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

このコマンドからの出力例を次に示します。

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

この問題を解決するには

JSON distribution プロパティの出力で空の文字列が返される場合は、次の手順に従ってクラスターにパッチを適用します。

1. 次の構成を patchBody.json という名前のファイルにコピーします。

   {
      "properties": {
        "distribution": "aks_management"
      }
   }
   

   重要

   クラスターが AKS 管理クラスターの場合、値は に設定する aks_management必要があります。 ワークロード クラスターの場合は、 に設定する aks_workload必要があります。

2. 上記で取得した JSON 出力から、接続されているクラスター ID をコピーします。 次の形式の長い文字列として表示されます。

   "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

3. 次のコマンドを実行して、クラスターにパッチを適用します。 値は <cc_arm_id> 、手順 2 で取得した ID である必要があります。

   az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"
   

4. を実行 az connectedk8s show -g <rg_name> -n <cc_name> してクラスターに正常にパッチが適用されていることを確認し、JSON プロパティ distribution が正しく設定されていることを確認します。

症状:

• AKS Arc でプロキシが有効になっています。WSSDAgent サービスが状態でスタックしています starting 。 次のように表示されます。
• Test-NetConnection -ComputerName <computer IP/Name> -Port <port> ノード エージェントが障害が発生しているノードからクラウド エージェントがシステム上で正常に動作している (wssdagent が起動に失敗した場合でも)
• エージェントが失敗しているノードからクラウド エージェントに向かって Curl.exe すると、問題が再現され、スタックしています。 curl.exe https://<computerIP>:6500
• この問題を解決するには、 フラグを --noproxy curl.exe に渡します。 curl は wssdcloudagent からエラーを返します。 curl は GRPC クライアントではないため、これは予想されます。 フラグを送信 --noproxy しても Curl が待機しなくなったりすることはありません。 そのため、ここでエラーを返すのは成功と見なされます。

curl.exe --noproxy '*' https://<computerIP>:65000

プロキシ設定がホスト上の障害のあるプロキシに変更された可能性があります。 AKS Arc のプロキシ設定は、ホスト上の親プロセスから継承される環境変数です。 これらの設定は、新しいサービスが開始されたとき、または古いサービスが更新または再起動されたときにのみ反映されます。 障害のあるプロキシ設定がホストで設定され、更新または再起動後に WSSDAgent に反映され、WSSDAgent が失敗した可能性があります。

マシン上の環境変数を変更して、プロキシ設定を修正する必要があります。 マシンで、次のコマンドを使用して変数を変更します。

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

サービス マネージャーと WSSDAgent が固定プロキシを取得できるように、マシンを再起動します。

このエラーは、CAPH ポッドが起動されるたびに cloudagent へのログインが試行され、証明書が一時ストレージ ボリュームに格納され、ポッドの再起動時にクリーンされるために発生します。 そのため、ポッドが再起動されるたびに、証明書が破棄され、新しいログイン試行が行われます。

ログイン試行によって更新ルーチンが開始され、有効期限が近付いたときに証明書が更新されます。 CAPH ポッドは、証明書が使用可能かどうかに関してログインが必要かどうかを判断します。 証明書が使用可能な場合、更新ルーチンが既に存在すると仮定して、ログインは試行されません。

ただし、コンテナーの再起動時に一時ディレクトリはクリーンアップされないため、ファイルは保持されたままでログイン試行が行われず、更新ルーチンが開始されません。 これにより、証明書の有効期限が切れになります。

この問題を軽減するには、次のコマンドを使用して CAPH ポッドを再起動します。

kubectl delete pod pod-name

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.

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

この問題により、AKS Arc クラスターが ScalingControlPlane 状態のまま長期間続きます。

再現方法

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

この問題は、最近の AKS Arc バージョンで修正されています。 AKS Arc クラスターを最新リリースに更新することをお勧めします。

この問題を軽減するには、サポートに問い合わせて、コントロール プレーン ノードの状態に手動で修正プログラムを適用し、kubectl を使用してマシンの状態から MachineOwnerRemediatedCondition という条件を削除します。

2 つの AKS on Azure Stack HCI デプロイの IP アドレス プールが同じであるか重複している場合、ワークロード クラスターが見つからない可能性があります。 2 つの AKS ホストをデプロイし、両方に同じAksHciNetworkSetting構成を使用すると、PowerShell と Windows Admin Center は、両方のクラスターで同じ IP アドレスが割り当てられるため、ワークロード クラスターを見つけることができない可能性があります。その結果、競合が発生します。

受信したエラーメッセージは、次に示す例のようになります。

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

この問題を解決するには、いずれかのクラスターを削除し、他のクラスターと重複しないネットワークを持つ新しい AKS クラスター ネットワーク設定を作成します。

Get-AksHciClusterNetwork コマンドを実行すると、すべての仮想ネットワーク構成のリストが提供されます。 ただし、このコマンドでは IP アドレスの現在の割り当ては表示されません。

仮想ネットワークで現在使用されている IP アドレスを確認するには、次の手順を使用します。

1. グループを取得するために、次のコマンドを実行します。

Get-MocGroup -location MocLocation

2. 現在使用されている IP アドレスのリストと、使用可能または使用されている仮想 IP アドレスのリストを取得するために、次のコマンドを実行します。

Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10

3. 次のコマンドを使用して、現在使用されている仮想 IP アドレスのリストを表示します。

Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

クラスターの IP アドレスは、事前チェック中に "Failed" と表示されます。 この事前チェックでは、すべての IPv4 アドレスと DNS ネットワーク名がオンラインで到達可能であることをテストします。 たとえば、IPv4 またはネットワーク名が失敗すると、このテストが失敗する可能性があります。

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

1. 次のコマンドを実行します。

   Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource
   

2. すべてのネットワーク名と IP アドレスがオンライン状態であることを確認します。

3. 次の 2 つのコマンドを実行します。

   Stop-ClusterResource -name "Cluster IP Address x.x.x.x"
   

   それから

   Start-ClusterResource -name "Cluster IP Address x.x.x.x"
   

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

たとえば次のエラーでは、構成の誤りが発生したポイントが 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 Stack HCI ノードがダウンロード URL msk8s.api.cdp.microsoft.com の名前を解決できるが、 ノードが対象サーバーに接続できないことを示します。

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

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

NTP 時間に依存するアプリケーションでは、時間の同期が間違っていると、何百もの誤ったアラートがトリガーされる可能性があります。クラスターがプロキシ環境で実行されている場合、ノードプールは、プロキシまたはファイアウォールを介して既定の NTP サーバー (time.windows.com) と通信できない可能性があります。

回避策

この問題を回避するには、各ノードプール ノードの NTP サーバー構成を更新してクロックを同期します。 これにより、各アプリケーション ポッドのクロックも設定されます。

前提条件

• 各ノードプール ノードでアクセスできる NTP サーバーのアドレス。
• ワークロード クラスター kubeconfig ファイルへのアクセス。
• 管理クラスター kubeconfig へのアクセス。

手順

1. ワークロード クラスター kubeconfig を使用して次kubectlのコマンドを実行して、その中のノードの一覧を取得します。

   kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
   

2. 次 kubectl のコマンドを実行して、前のコマンドのノード名をワークロード クラスターのノード プール ノードに関連付けます。 前のコマンドの出力から関連する IP アドレスをメモしておきます。

   kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>
   

3. 前の手順の出力を使用して、NTP 構成を更新する必要があるノードプール ノードごとに次の手順を実行します。

   1. ノードプール ノード VM に SSH 接続します。

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>
      

   2. 構成された NTP サーバーに到達できないかどうかを確認します。

      sudo timedatectl timesync-status
      

      出力がこのように見える場合は、NTP サーバーに到達できないので、変更する必要があります。

      Server: n/a (time.windows.com)
      Poll interval: 0 (min: 32s; max 34min 8s)
      Packet count: 0
      

   3. NTP サーバーを更新するには、次のコマンドを実行して、timesync 構成ファイル内の NTP サーバーを nodepool VM からアクセスできるサーバーに設定します。

      # make a backup of the config file
      sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak
      
      # update the ntp server
      NTPSERVER="NEW_NTP_SERVER_ADDRESS"
      sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf
      
      # verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
      sudo cat /etc/systemd/timesyncd.conf 
      

   4. timesync サービスを再起動します。

      sudo systemctl restart systemd-timesyncd.service
      

   5. NTP サーバーにアクセス可能であることを確認します。

      sudo timedatectl timesync-status
      

   6. クロックに正しい時刻が表示されていることを確認します。

      date
      

4. 手順 3.f のコマンドを実行して、各 nodepool ノードに同じ時刻が表示されていることを確認します。

5. アプリケーションが時刻を自動的に更新しない場合は、ポッドを再起動します。

次の手順

• トラブルシューティングの概要
• インストールに関する問題とエラー
• ストレージに関する既知の問題