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 ビルドを実行します。

クラスター管理ツールを使用して、あるノード (ノード A) から Azure ローカル クラスター内の別のノード (ノード 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-AksHci、Update-AksHciCertificates、Update-AksHciClusterCertificates、管理クラスターとのすべての対話などのコマンドは、"エラー: サーバーにログインする必要があります (Unauthorized)" を返すことができます。

このエラーは、 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 ファイルを Azure ローカル ホストにコピーします。

• 管理コントロール プレーン 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 プラグインとコンテナーを再起動します。

Azure ローカル デプロイ上の 2 つの AKS の 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 コマンドを使用してクラスターにアクセスし進行状況を監視します。

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

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

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

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

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

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

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

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

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

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

Linux または Windows ノードが 0 個の Azure Local に 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 ローカル ノードで 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>

次のステップ

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