編集

次の方法で共有


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

適用対象: AKS on Azure Local、AKS on Windows Server このトピックを使用すると、AKS Arc に関するネットワーク関連の問題のトラブルシューティングと解決に役立ちます。

エラー: "フェールオーバー クラスターでクラウド エージェント 汎用クラスター サービスを開始できませんでした。 クラスター リソース グループが "失敗" 状態です。

パス名とスペースを使用すると、クラウド エージェントが正常に起動しない場合があります。

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 のようにします。

Arc 接続クラスターに空の JSON "ディストリビューション" プロパティがある

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が正しく設定されていることを確認します。

WSSDAgent サービスが起動中にスタックし、クラウド エージェントへの接続に失敗する

症状:

  • 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 ポッドが証明書の更新に失敗する

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

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

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

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

kubectl delete pod pod-name

Set-AksHciConfig が WinRM エラーで失敗するが、WinRM が正しく構成されていることを示す

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" プロビジョニング状態でスタックしている

この問題により、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 を削除するように、コントロール プレーン ノードの状態に手動で修正プログラムを適用するようにサポートにお問い合わせください。

ワークロード クラスターが見つかりません

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

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

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.

Note

クラスター名は異なります。

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

Get-AksHCIClusterNetwork に IP アドレスの現在の割り当てが表示されない

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

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

  1. グループを取得するために、次のコマンドを実行します。
Get-MocGroup -location MocLocation
  1. 現在使用されている IP アドレスのリストと、使用可能または使用されている仮想 IP アドレスのリストを取得するために、次のコマンドを実行します。
Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
  1. 次のコマンドを使用して、現在使用されている仮想 IP アドレスのリストを表示します。
Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

"クラスター IP アドレス x.x.x.x" が失敗する

クラスター 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"
    

正しく構成されていないネットワークを使用して Azure Local に AKS をデプロイすると、さまざまな時点でデプロイがタイムアウトしました

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. 接続がタイムアウトした場合は、データ パスにブレークが発生する可能性があります。 詳細については、プロキシ設定の確認に関するページを参照してください。 または、リターン パスに改行がある可能性があるので、ファイアウォール規則を確認する必要があります。

NTP 時間に依存するアプリケーションは、何百もの誤ったアラートをトリガーします

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

回避策

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

前提条件

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

手順

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

    kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide
    
  2. 次の kubectl コマンドを実行して、前のコマンドのノード名をワークロード クラスターの nodepool ノードに関連付けます。 前のコマンドの出力から関連する 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. アプリケーションが時刻を自動的に更新しない場合は、ポッドを再起動します。