AKS Arc での Kubernetes 管理とワークロード クラスターに関する問題のトラブルシューティング

Remove-ClusterNode コマンドを実行すると、ノードはフェールオーバー クラスターから削除されますが、その後に Remove-AksHciNode を実行しなければ、そのノードは CloudAgent に存在したままになります。

ノードはクラスターから削除されましたが、CloudAgent からは削除されていないため、VHD を使用して新しいノードを作成すると、"ファイルが見つかりません" というエラーが表示されます。 この問題は、VHD が共有ストレージ内にあり、削除されたノードにアクセスできないために発生します。

この問題を解決するには、クラスターから物理ノードを削除し、次の手順に従います。

1. Remove-AksHciNode を実行して、CloudAgent からノードの登録を削除します。
2. マシンのイメージ再作成など、定期的なメンテナンスを実行します。
3. 再びクラスターにノードを追加します。
4. Add-AksHciNode を実行して、CloudAgent にノードを登録します。

大規模なクラスターでは、Get-AksHciLogs コマンドによって、例外がスローされたり、ノードの列挙に失敗したり、c:\wssd\wssdlogs.zip 出力ファイルが生成されないことがあります。

これは、ファイル 'Compress-Archive' を圧縮する PowerShell コマンドの出力ファイル サイズの制限が 2 GB であるためです。

ワークロード クラスターをアップグレードまたはスケールアップした後、ポッドはファイルの場所 /etc/Kubernetes/pki からの証明書タトゥー YAML ファイルを待っているため、証明書更新ポッドはクラッシュ ループ状態になっています。

この問題は、構成ファイルがコントロール プレーン VM には存在するが、ワーカー ノード VM には存在しないことが原因である可能性があります。

この問題を解決するには、証明書タトゥー YAML ファイルを、コントロール プレーン ノードからすべてのワーカー ノードに手動でコピーします。

1. YAML ファイルを、ワークロード クラスター上のコントロール プレーン VM から、ホスト コンピューターの現在のディレクトリにコピーします。

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. YAML ファイルを、ホスト コンピューターからワーカー ノード VM にコピーします。 ファイルをコピーする前に、YAML ファイル内のコンピューターの名前を、コピー先のノード名に変更する必要があります (これはワークロード クラスター コントロール プレーンのノード名です)。

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. YAML ファイルの所有者とグループの情報がルートにまだ設定されていない場合は、その情報をルートに設定します。

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. すべてのワーカー ノードについて、ステップ 2 と 3 を繰り返します。

PowerShell コマンド Aks-Hci では、Kubernetes ノードを作成する前に、ホスト サーバーで使用可能なメモリが確認されません。 この問題により、メモリ不足が生じて、仮想マシンが起動しなくなる可能性があります。

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

Get-AksHciCluster を実行して、Windows Admin Centerでの AKS Arc インストールの状態を確認すると、"バージョン 1.0.3.10818 のリリースが見つかりませんでした" というエラーが出力されます。ただし、Get-AksHciVersion を実行すると、同じバージョンがインストールされたことが示されました。 このエラーは、ビルドの有効期限が切れたことを示します。

この問題を解決するには、 を実行 Uninstall-AksHciし、新しい AKS Arc ビルドを実行します。

クラスター管理ツールを使用して、1 つのノード (ノード A) から Azure Stack HCI クラスターの別のノード (ノード B) に VM を移動すると、新しいノードで VM が起動に失敗することがあります。 その VM を元のノードに戻すと、そこでも起動に失敗します。

この問題は、最初の移行をクリーンアップするロジックが非同期に実行されるために発生します。 結果として、Azure Kubernetes Service の "VM の場所の更新" ロジックでは、ノード A 上の元の Hyper-V で VM が検出され、その VM は登録を解除する代わりに削除されます。

この問題を回避するには、新しいノードで VM が正常に起動したことを確認してから、VM を元のノードに戻します。

PowerShell を使用して静的 IP アドレスを持つクラスターを作成し、ワークロード クラスター内のワーカー ノードの数を増やそうとすると、インストールは "コントロール プレーン数が 2 で、目的の状態をまだ待機しています: 3" で停止します。一定の期間が経過すると、"エラー: 条件を待機中にタイムアウトしました" という別のエラー メッセージが表示されます。

Get-AksHciCluster が実行されたとき、コントロール プレーン ノードが作成およびプロビジョニングされ、準備完了状態になったことが示されました。 ただし、kubectl get nodes が実行されたとき、コントロール プレーン ノードが作成されてもプロビジョニングされず、準備完了状態にならなかったことが示されました。

このエラーが発生した場合は、Hyper-V マネージャーまたは PowerShell のいずれかを使用して、作成されたノードに IP アドレスが割り当てられていることを確認します。

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

次に、ネットワーク設定を確認して、プールに十分な数の IP アドレスが残っていることを確認して、さらに多くの VM を作成します。

、Update-AksHciCertificates、Update-AksHciClusterCertificates、および管理クラスターとのすべての操作などのUpdate-AksHciコマンドは、"エラー: サーバーにログインする必要があります (未承認) " を返すことができます。

このエラーは、 kubeconfig ファイルの有効期限が切れているときに発生する可能性があります。 期限切れになった場合にチェックするには、次のスクリプトを実行します。

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

このスクリプトに現在の日付より前の日付が表示される場合、 kubeconfig ファイルの有効期限が切れています。

この問題を軽減するには、管理コントロール プレーン VM 内にある admin.conf ファイルを HCI ホストにコピーします。

• 管理コントロール プレーン VM への SSH:

  • 管理コントロール プレーンの VM IP を取得します。

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • SSH で接続します。

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• clouduser の場所にファイルをコピーします。

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• clouduser へのアクセス権を付与する:

  sudo chown clouduser:clouduser admin.conf
  

• [省略可能] kubeconfig ファイルのバックアップを作成します。

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• ファイルをコピーします。

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Hyper-V マネージャーをオンにすると、管理クラスターに対する高い CPU およびメモリ要求が無視されます。 これは、ワークロード クラスターをプロビジョニングするときのコンピューティング リソースの使用量の急増に関連しています。

管理クラスターのメモリまたは CPU のサイズを増やすことは、大幅な改善を示すものではなく、無視しても安全です。

以下の手順に従うと、この問題が発生します。

1. Kubernetes クラスターを作成します。
2. クラスターを 3 つ以上のノードにスケーリングする。
3. 次のコマンドを実行してノードを削除します。

kubectl delete node <node-name>

4. 次のコマンドを実行してノードのリストを返します。

kubectl get nodes

削除されたノードは出力に一覧表示されません 5. 管理者特権で PowerShell ウィンドウを開き、次のコマンドを実行します。

get-vm

削除されたノードはまだ一覧表示されます。

この失敗のために、ノードがないことをシステムが認識できなくなるため、新しいノードはスピンアップされません。

管理クラスターまたはワークロード クラスターを 60 日を超えて使用しない場合は、証明書の有効期限が切れ、AKS Arc をアップグレードする前に証明書を更新する必要があります。AKS クラスターが 60 日以内にアップグレードされない場合、KMS プラグイン トークンと証明書の両方が 60 日以内に期限切れになります。 クラスターはまだ機能しています。 ただし、60 日を超えているので、アップグレードするには Microsoft サポートに連絡する必要があります。 この期間が経過した後にクラスターが再起動された場合、クラスターは非機能状態のままになります。

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

1. トークンを手動でローテーションして管理クラスター証明書 を修復し、KMS プラグインとコンテナーを再起動します。
2. Repair-MocLogin を実行して mocctl 証明書を修復します。
3. トークンを手動でローテーションしてワークロード クラスター証明書 を修復し、KMS プラグインとコンテナーを再起動します。

2 つの AKS on Azure Stack HCI デプロイの IP アドレス プールが同じであるか重複している場合、ワークロード クラスターが見つからない可能性があります。 2 つの AKS ホストをデプロイし、両方に同じ AksHciNetworkSetting 構成を使用した場合、両方のクラスターで同じ IP アドレスが API サーバーに割り当てられ、競合が発生するため、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.

大規模なクラスターのデプロイは、2 時間後にタイムアウトになる場合があります。 ただし、これは静的なタイムアウトです。

操作がバックグラウンドで実行されているため、このタイムアウトの発生は無視できます。 kubectl get nodes コマンドを使用してクラスターにアクセスし進行状況を監視します。

数日後に AKS on Azure Stack HCI デプロイを起動しようとしたときに、Kubectl のどのコマンドも実行されませんでした。 キー管理サービス (KMS) プラグイン ログに、エラー メッセージ rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificates が表示されます。

API サーバーがダウンしている場合、 Repair-AksHciClusterCerts コマンドレットは失敗します。 AKS on Azure Stack HCI が 60 日以上アップグレードされていない場合に、KMS プラグインを再起動しようとしても起動しません。 このエラーが発生すると、API サーバーも失敗します。

この問題を解決するには、手動でトークンをローテーションした後に、KMS プラグインとコンテナーを再起動して API サーバーのバックアップを取得する必要があります。 そのためには、次の手順を実行します。

1. 次のコマンドを実行して、トークンをローテーションします。

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. 次のコマンドを使用して、トークンを VM にコピーします。 下のコマンドの ip 設定は、AKS ホストのコントロール プレーンの IP アドレスを参照しています。

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. KMS プラグインとコンテナーを再起動する

   コンテナー ID を取得するには、次のコマンドを実行します。

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   出力には、次のフィールドが表示されます。

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   出力はこの例のようになります。

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. 最後に、次のコマンドを実行して、コンテナーを再起動します。

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

Windows Admin Center 拡張機能バージョン 1.82.0 を使用した AKS on Azure Stack HCI インストールで、PowerShell を使用して管理クラスターが設定され、Windows Admin Center を使用したワークロード クラスターのデプロイが試行されました。 1 台のマシンには PowerShell モジュール バージョン 1.0.2 がインストールされ、他のマシンには PowerShell モジュール 1.1.3 がインストールされました。 ワークロード クラスターをデプロイしようとしましたが、"パラメーター名 'nodePoolName' と一致するパラメーターが見つかりません" というエラーで失敗しました。このエラーは、バージョンの不一致が原因で発生した可能性があります。 PowerShell バージョン 1.1.0 より、-nodePoolName <String> パラメーターが -nodePoolName <String> コマンドレットに追加されました。設計上、Windows Admin Center 拡張機能バージョン 1.82.0 を使用する場合、このパラメーターは必須となります。

この問題を解決するには、次のいずれかを実行します。

• PowerShell を使用して、ワークロード クラスターをバージョン 1.1.0 以降に手動で更新します。
• Windows Admin Center を使用して、クラスターをバージョン 1.1.0 または最新の PowerShell バージョンに更新します。

管理クラスターを Windows Admin Center を使用してデプロイした場合は、最新の PowerShell モジュールが既にインストールされているため、この問題は発生しません。

AKS on Azure Stack HCI をデプロイしてから を実行 kubectl get podsすると、同じノード内のポッドが 終了 状態でスタックします。 ノードで高いメモリ要求が発生している可能性が高いため、マシンは SSH 接続を拒否します。 この問題は、Windows ノードが過剰にプロビジョニングされ、コア コンポーネント用の予約がないために発生します。

この状況を回避するには、CPU とメモリのリソース制限とリソース要求をポッド仕様に追加して、ノードが過剰にプロビジョニングされないようにします。 Windows ではリソース制限に基づく削除がサポートされないため、コンテナーで使用される量を見積もり、ノードに十分な量の CPU とメモリを確保する必要があります。 詳細については、システム要件に関するページを参照してください。

AKS ホスト管理クラスターで次の Azure ポリシーを使用すると、クラスターの自動スケーリングが失敗する可能性があります。"Kubernetes クラスターでは既定の名前空間を使用しないでください"。これは、ポリシーが AKS ホスト管理クラスターに実装されると、既定の名前空間での自動スケーラー プロファイルの作成をブロックするためです。 この問題を解決するには、次のいずれかのオプションを選択します。

• AKS ホスト管理クラスターでAzure Policy拡張機能をアンインストールします。 Azure Policy拡張機能のアンインストールの詳細については、こちらを参照してください。
• AKS ホスト管理クラスターを除外するように Azure ポリシーのスコープを変更します。 Azure Policyスコープの詳細については、こちらを参照してください。
• AKS ホスト管理クラスターのポリシー適用モードを "無効" に設定します。 強制モードの詳細については 、こちらを参照してください。

これは、AKS on Azure Stack HCI の 7 月の更新プログラム (バージョン 1.0.2.10723) に関する既知の問題です。 このエラーが発生するのは、システム内の複数のクラスター共有ボリュームに仮想マシンを配布している間に CloudAgent サービスがタイムアウトするためです。

この問題を解決するには、AKS on Azure Stack HCI の最新リリースにアップグレードする必要があります。

Linux または Windows ノードが 0 個の Azure Stack HCI で AKS クラスターをプロビジョニングする場合、 Get-AksHciCluster を実行すると、出力は空の文字列または null 値になります。

Null は、0 個のノードに対して予期される戻り値です。

管理クラスターまたはワークロード クラスターを 4 日より長くシャットダウンしたままにすると、証明書の有効期限が切れ、クラスターに到達できなくなります。 セキュリティ上の理由から、証明書は 3 日から 4 日ごとにローテーションされるため期限切れになります。

クラスターを再起動するには、クラスターの操作を実行する前に、証明書を手動で修復する必要があります。 証明書を修復するには、次の Repair-AksHciClusterCerts コマンドを実行します。

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

ワークロード クラスターをスケールアウトすると、対応する Linux および Windows VM はワーカー ノードとして追加されますが、高可用性 VM として構成されません。 Get-ClusterGroup コマンドを実行しても、新しく作成される Linux VM はクラスター グループとして構成されません。

これは既知の問題です。 再起動後、VM を高可用性として構成できない場合があります。 現在の対処法は、各 Azure Stack HCI ノードで wssdagent を再起動することです。 これは、スケールアウト操作を実行するとき、またはノードで を再起動 wssdagent した後に新しい Kubernetes クラスターを作成するときに、ノード プールを作成することによって生成される新しい VM に対してのみ機能します。 ただし、既存の VM をフェールオーバー クラスターに手動で追加する必要があります。

クラスターをスケール ダウンすると、VM が削除されている間、高可用性クラスター リソースは失敗状態になります。 この問題の対処法は、失敗したリソースを手動で削除することです。

Azure VM にデプロイされた AKS クラスターは以前は正常に動作していましたが、AKS ホストが数日間オフになった後、 Kubectl コマンドは機能しませんでした。 Kubectl get nodes コマンドまたは Kubectl get services コマンドを実行すると、次のエラー メッセージ Error from server (InternalError): an error on the server ("") has prevented the request from succeeding が表示されます。

この問題の原因は、AKS ホストがオフになっていた期間が 4 日を超えたために、証明書の有効期限が切れたことです。 証明書は、4 日間のサイクルで頻繁にローテーションされます。 Repair-AksHciClusterCerts を実行して、証明書の有効期限の問題を解決してください。

静的 IP アドレスと Windows ノードを持つワークロード クラスターでは、ノード (ポッドを含む daemonset ) 内のすべてのポッドが ContainerCreating 状態でスタックしています。 SSH を使用してそのノードに接続しようとすると、接続はエラーで Connection timed out 失敗します。

この問題を解決するには、Hyper-V マネージャーまたはフェールオーバー クラスター マネージャーを使用して、そのノードの VM をオフにします。 5 分から 10 分後に、ノードが再作成され、すべてのポッドが実行されているはずです。

kubelet がディスクの負荷にさらされている場合、未使用のコンテナー イメージが収集されます。これには一時停止イメージが含まれる可能性があり、その場合、ContainerD はイメージをプルできません。

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

1. SSH を使用して影響を受けるノードに接続し、次のコマンドを実行します。

sudo su

2. 次のコマンドを実行して、イメージをプルします。

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

次の手順

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