AKS Arc をアップグレードするときの問題を解決する

以前のバージョンの PowerShell は削除されません。

この問題を回避するには、 このスクリプトを実行して古い PowerShell バージョンをアンインストールします。

ターゲット クラスターをアップグレードまたはスケールアップした後、証明書更新ポッドはクラッシュ ループ状態になります。 パス /etc/Kubernetes/pki の cert tattoo yaml ファイルが必要です。 構成ファイルはコントロール プレーン ノード VM に存在しますが、ワーカー ノード VM には存在しません。

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

1. コントロール プレーン 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 works)
   scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\
   

2. このファイルをホスト コンピューターからワーカー ノード VM にコピーします。

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

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

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

4. ワーカー ノードごとに手順 2 と 3 を繰り返します。

クラスターが 60 日を超えてアップグレードされていない場合、ノード エージェントの再起動中に、トークンの有効期限が切れたため、ノード エージェントの起動に失敗します。 このエラーにより、エージェントは開始フェーズになります。 cloudagent に継続的に参加しようとすると、ホスト上のポートの供給が使い果たされる可能性があります。 次のコマンドの状態は [開始中] です。

Get-Service wssdagent | Select-Object -Property Name, Status

想定される動作: ノード エージェントは開始フェーズにある必要があります。これは常にクラウド エージェントへの参加を試み、ポートを使い果たします。

この問題を解決するには、wssdagent の実行を停止します。 サービスは開始フェーズであるため、サービスを停止できないことがあります。 その場合は、サービスを停止する前にプロセスを強制終了します。

1. wssdagent が開始中フェーズにあることを確認します。

   Get-Service wssdagent | Select-Object -Property Name, Status
   

2. プロセスを中止します。

   kill -Name wssdagent -Force
   

3. サービスを停止します。

   Stop-Service wssdagent -Force
   

Get-Process -Name wssdagent

PS C:\WINDOWs\system32 Get-process -Name wssdagent 
Get-process : Cannot find a process with the name "wssdaqent". Verify the process name and call the cmdlet again.
At line: 1 char: 1 
+ Get-process -Name wssdagent
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + Categorylnfo          : ObjectNotFound: (wssdagent:String) [Get-Process], ProcessCommandException 
    + FullyQua1ifiedErrorId : NoProcess FoundForGivenName , Microsoft.PowerShell.Commands.Getprocesscommand

1. この問題が発生している HCI クラスターの各ノードで、手順 1、2、3 を繰り返します。

2. wssdagent が実行されていないことを確認したら、cloudagent が実行されていない場合は起動します。

Start-ClusterGroup -Name (Get-MocConfig).clusterRoleName

1. cloudagent が稼働していることを確認します。

   Get-ClusterGroup -Name (Get-MocConfig).clusterRoleName
   

2. wssdagent を修正するには、次のコマンドを実行します。

   Repair-Moc
   

3. このコマンドが完了すると、wssdagent は実行中の状態になっているはずです。

   Get-Service wssdagent | Select-Object -Property Name, Status
   

AKS-HCI が 5 月のリリースから 6 月のリリースにアップグレードできない場合、AKS-HCI は 5 月のリリースに戻し、引き続き機能する必要があります。 ただし、MOC エージェントは停止状態になり、エージェントを手動で起動してもアクティブ化されません。

再現手順

1. AKS-HCI PowerShell モジュール バージョン 1.1.36 をインストールします。
2. AKS-HCI をアップグレードします。 アップグレードに失敗した場合、AKS-HCI は 5 月にフォールバックしますが、MOC エージェントはダウンしています。

正しい動作

Aks-Hci アップグレードが失敗した場合、AksHci は以前のリリースに戻り、問題なく引き続き機能します。

現象

Aks-Hci バージョンと MOC バージョンの不一致

• Get-AksHciVersion: 1.0.10.10513
• Get-MocVersion: 1.0.11.10707

Get-MocVersion と wssdcloudagent.exe バージョンの不一致

Get-MocVersion は、6 月のビルドがインストールされていることを示し、wssdcloudagent.exe バージョンは 5 月のビルドがインストールされていることを示します。

MOC エージェント サービスのイメージ パスにデプロイ ID パラメーターがある

次のコマンドを実行して、クラウド エージェントのイメージ パスを表示します。

reg query "HKLM\System\CurrentControlSet\Services\wssdcloudagent"

出力例

"C:\Program Files\AksHci\wssdcloudagent.exe" --service --basedir "base dir" --cloudagentfqdn "cloudagent fqdn" --dotfolderpath "dot folder path" --objectdatastore "data store" --clusterresourcename "cluster name" --certificatevalidityfactor 1 --deploymentid "deployment id"

ノード エージェントのイメージ パスを表示するには、次のコマンドを使用します。 reg クエリ "HKLM\System\CurrentControlSet\Services\wssdagent"

出力例

"C:\Program Files\AksHci\wssdagent.exe" --service --basedir "base dir" --cloudloginfile "cloud login file path" --dotfolderpath "dotfolder path" --nodeagentfqdn "node fqdn" --objectdatastore "object data store" --wssdproviderspec "provider spec" --deploymentid "deployment id"

この問題を軽減するには、次の PowerShell コマンドレットを実行します。

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdcloudagent" -Name ImagePath -Value 'above cloud agent image path without the deployment id'
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\wssdagent" -Name ImagePath -Value 'above node agent image path without the deployment id'

アップグレード時に、ワーカー ノードに追加したカスタムのテイント、ロール、ラベルがすべて失われることがあります。 AKS はマネージド サービスであるため、提供されている PowerShell コマンドレットまたはWindows Admin Centerの外部で実行された場合にカスタム テイント、ラベル、ロールを追加することはサポートされていません。

この問題を回避するには、New-AksHciNodePool コマンドレットを実行して、ワーカー ノードのテイントを含むノード プールを正しく作成します。

管理クラスターを作成したが、最初の 60 日間にワークロード クラスターをデプロイしていない場合は、ポリシー外になったため、作成がブロックされます。 この状況では、Update-AksHci を実行すると、更新プロセスがブロックされ、"デプロイ 'AksHci Billing Operator' が準備完了になるのを待機中です" というエラーが表示されます。 Sync-AksHciBilling を実行すると、正常な出力が返されます。 ただし、 Get-AksHciBillingStatus を実行すると、接続の状態は OutofPolicy になります。

ワークロード クラスターを 60 日以内にデプロイしていない場合、課金がポリシー違反になります。

この問題を解決する唯一の方法は、クリーン インストールで再デプロイすることです。

Azure Stack HCI ノードが 1 つずつ再起動されると、一部の仮想マシンは接続されている vNIC を失います。 この vNIC の損失により、VM はネットワーク接続を失い、クラスターは不適切な状態になります。

再現方法

1. 1 つの Azure Stack HCI ノードを再起動します。
2. ノードが再起動を完了するまで待ちます。 フェールオーバー クラスターでノードをマーク Up する必要があります。
3. 他のノードを再起動します。
4. 反復

予期される動作 クラスターの状態は正常である必要があります。 すべての VM に NIC がアタッチされている必要があります。

この問題を解決するには、MOC コマンドを使用して vNIC を VM に追加します。

1. VM の vNIC 名を取得します。

(Get-MocVirtualMachine -group <group> -name <vmname>).virtualmachineproperties.networkprofile.networkinterfaces

または

mocctl.exe compute vm get --name <vmname> --group <group>

2. vNIC を VM に接続します。

Connect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

または

mocctl.exe compute vm nic add --name <vnicname> --vm-name <vmname> --group <group>

3. vNIC connect コマンドが失敗した場合は、切断してからもう一度接続してください。 vNIC 切断のコマンドを次に示します。

Disconnect-MocNetworkInterface -name <vnicname> -group <group> -virtualMachineName <vmname>

または

mocctl.exe compute vm nic remove --name <vnicname> --vm-name <vmname> --group <group>

ポッドは、 静的ポッドが準備完了状態になるまで待機中にスタックします。

ポッドを解放してこの問題を解決するには、kubelet を再起動する必要があります。 静的ポッドのある NotReady ノードを表示するには、次のコマンドを実行します。

kubectl get nodes -o wide

障害が発生しているノードの詳細情報を取得するには、次のコマンドを実行します。

kubectl describe node <IP of the node>

次のコマンドを実行し、SSH を使用して NotReady ノードにログインします。

ssh -i <path of the private key file> administrator@<IP of the node>

その後、kubelet を再起動するには、次のコマンドを実行します。

/etc/.../kubelet restart

Windows Admin Center でアップグレードを実行するときに、次のエラーが発生します。

Error occurred while fetching platform upgrade information. RemoteException: No match was found for the specified search criteria and module name 'AksHci'. Try Get-PSRepository to see all available registered module repositories.

通常、このエラー メッセージは、プロキシが構成されている環境に AKS on Azure Stack HCI がデプロイされる場合に発生します。 現在、Windows Admin Center では、プロキシ環境へのモジュールのインストールをサポートしていません。

このエラーを解決するには、プロキシの PowerShell コマンドを使用して AKS on Azure Stack HCI を設定します。

OPA GateKeeper などの Open Policy Agent (OPA) を使用して Kubernetes クラスターをアップグレードすると、プロセスがハングし、完了できないことがあります。 この問題は、プライベート レジストリからのコンテナー イメージのプルを防止するようにポリシー エージェントが構成されている場合に発生する可能性があります。

この問題を解決するには、OPA と共にデプロイされたクラスターをアップグレードする場合、Azure Container Registry からのイメージのプルがポリシーで許可されていることを確認してください。 AKS on Azure Stack HCI のアップグレードの場合は、ポリシーの一覧にエンドポイント ecpacr.azurecr.io を追加する必要があります。

AKS on Azure Stack HCI デプロイがあるホスト上で OS 更新プログラムを実行すると、デプロイが正しくない状態になり、2 日目の操作に失敗することがあります。 MOC NodeAgent サービスは、更新されたホスト上で起動に失敗する場合があります。 ノードに対するすべての MOC 呼び出しが失敗します。

再現するには:HCI から HCIv2 への既存の AKS デプロイを使用してクラスターを更新すると、 などの New-AksHciCluster AKS 操作が失敗する可能性があります。 エラー メッセージは、MOC ノードが OutOfCapacity であることを示します。 次に例を示します。

System.Collections.Hashtable.generic_non_zero1 [Error: failed to create nic test-load-balancer-whceb-nic for machinetest-load-balancer-whceb: unable to create VM network interface: failed to create network interface test-load-balancer-whceb-nic in resource group clustergroup-test: rpc error: code = Unknown desc = Location 'MocLocation' doesn't expose any nodes to create VNIC 'test-load-balancer-whceb-nic' on: OutOfCapacity]

この問題を解決するには、影響を受けるノードで wssdagent Moc NodeAgent サービスを開始します。 これにより、問題が解決され、デプロイが良好な状態に戻ります。 次のコマンドを実行します。

Get-ClusterNode -ErrorAction Stop | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { Start-Service wssdagent -WarningAction:SilentlyContinue } }

Update-AksHciCluster を実行すると、アップグレード プロセスが停止します。

次のコマンドを実行して、アップグレード元のPHASE以前の Kubernetes バージョンを実行しているマシンが削除されている場合にチェックします。

kubectl get machines -o wide --kubeconfig (Get-KvaConfig).kubeconfig

以前の Kubernetes バージョンを削除してVERSION一致するマシンPHASEがある場合は、次の手順に進みます。

この問題に対処するには、次の情報が必要です。

1. ワークロード クラスターをアップグレードする Kubernetes バージョン。
2. スタックしているノードの IP アドレス。

この情報を見つけるには、次のコマンドレットとコマンドを実行します。 既定では、コマンドレット Get-AksHciCredential は kubeconfig を に ~/.kube/config書き込みます。 を呼び出 Get-AksHciCredentialすときにワークロード クラスター kubeconfig に別の場所を指定する場合は、その場所を kubectl に別の引数として指定する必要があります。 たとえば、「 kubectl get nodes -o wide --kubeconfig <path to workload cluster kubeconfig> 」のように入力します。

Get-AksHciCredential -name <workload cluster name>
kubectl get nodes -o wide

修正する必要があるノードには、 が表示 STATUSReady,SchedulingDisabledされます。 この状態のノードが表示される場合は、次のコマンドの IP アドレス値としてこのノードの を使用 INTERNAL-IP します。 アップグレード先の Kubernetes バージョンをバージョン値として使用します。これは、 ノードの VERSION 値と と ROLEScontrol-plane,master一致する必要があります。 Kubernetes バージョンの完全な値 (などv1.22.6) をv含めるようにしてください。

ssh -i (Get-MocConfig).sshPrivateKey -o StrictHostKeyChecking=no  clouduser@<IP address> sudo crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

この ssh コマンドを実行すると、古い Kubernetes バージョンの残りのノードが削除され、アップグレードが続行されます。

AKS on Azure Stack HCI デプロイを使用してホストで OS 更新プログラムを実行すると、デプロイが不適切な状態になる可能性があります。これにより、管理クラスターの API サーバーに到達できず、2 日目の操作が失敗します。 ポッドは kube-vip インターフェイスに VIP 構成を適用できないため、VIP に到達できません。

再現するには:HCI から HCIv2 への既存の AKS HCI デプロイでクラスターを更新します。 次に、 などの Get-AksHciCluster管理クラスターに到達しようとするコマンドを実行してみてください。 管理クラスターに到達しようとする操作は、次のようなエラーで失敗します。

PS C:\Users\wolfpack> Get-AksHciCluster
C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9
attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)]
At C:\Program Files\WindowsPowerShell\Modules\Kva\1.0.22\Common.psm1:2164 char:9
+         throw $errMessage
+         ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (C:\Program File...iting headers)]:String) [], RuntimeException
    + FullyQualifiedErrorId : C:\Program Files\AksHci\kvactl.exe cluster list --kubeconfig="C:\ClusterStorage\Volume1\Msk8s\WorkingDir\1.0.8.10223\kubeconfig-mgmt" System.Collections.Hashtable.generic_non_zero 1 [Error: failed to connect to the cluster: action failed after 9 attempts: Get "https://10.193.237.5:6443/api?timeout=10s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)]

この問題を解決するには、kube-vip コンテナーを再起動して、デプロイを良好な状態に戻します。

1. kube-vip コンテナーの ID を取得します。

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl ls | grep 'kube-vip'"

出力は次のようになります。コンテナー ID は最初の値 4a49a5158a5f8 です。 次に例を示します。

4a49a5158a5f8       7751a28bb5ce1       28 minutes ago      Running             kube-vip                         1                   cf9681f921a55

1. コンテナーを再起動します。

ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo crictl stop <Container ID>"

このステータス メッセージは、Update-AksHci PowerShell コマンドレットを実行するときに表示されます。

この問題を解決するには、次の根本原因を確認します。

• 理由 1: AksHci 課金オペレーターの更新中に、オペレーターが誤って自身をポリシー外としてマークしました。 この問題を解決するには、新しい PowerShell ウィンドウを開き、 Sync-AksHciBilling を実行します。 課金操作は、その後 20 から 30 分以内に続行されます。

• 理由 2: 管理クラスター VM がメモリ不足になっている可能性があります。これにより、API サーバーに到達できなくなるため、 Get-AksHciCluster からのすべてのコマンド、課金、更新、タイムアウトが発生します。回避策として、Hyper-V で管理クラスター VM を 32 GB に設定し、再起動します。

• 理由 3: AksHci Billing Operator で記憶域スペースが不足している可能性があります。これは、Microsoft SQL 構成設定のバグが原因です。 記憶域スペースの不足により、アップグレードからの応答が停止する可能性があります。 この問題を回避するには、次の手順を使用して課金ポッド pvc のサイズを手動で変更します。

  1. 次のコマンドを実行して、ポッドの設定を編集します。

     kubectl edit pvc mssql-data-claim --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

  2. メモ帳または別のエディターで YAML ファイルが開いたら、ストレージの行を 100Mi から 5Gi に編集します。

     spec:
       resources:
         requests:
           **storage: 5Gi**
     

  3. 次のコマンドを使用して、請求デプロイの状態を確認します。

     kubectl get deployments/billing-manager-deployment --kubeconfig (Get-AksHciConfig).Kva.kubeconfig -n azure-arc
     

AKS on Azure Stack HCI 2022 Update から 2022 年 4 月の更新プログラムにクラスターをアップグレードすると、無期限に更新プログラムのアップグレードが停止する可能性があります。 または 状態でTerminatingCrashLoopBackoffポッドがスタックしている可能性があります。

AksHci CSI アドオン リソースの一部が見つからない場合があります。 デーモンセットから csi-akshcicsi-node または を使用してcsi-akshcicsi-controllerデプロイされたこれらのリソース ポッド。

2022 年 2 月の更新プログラムの AksHci CSI アドオンには、アップグレード中にアドオンのリソースが応答しない状態になる場合がある CSI ドライバー 仕様の変更が含まれていました。 CSI ドライバーは .spec.fsGroupPolicy 、変更できないフィールドであっても、新しい値に設定されました。 フィールドは不変であるため、ドライバー スペックは更新されません。 その結果、他の AksHci CSI アドオン リソースが完全には調整されない可能性があります。 すべての CSI リソースが再作成されます。

問題を手動で解決するには、CSI ドライバーを手動で削除します。 削除すると、クラウド オペレーターは 10 分以内に AksHci CSI アドオンを調整し、不足しているアドオン リソースの残りの部分と共にドライバーを再作成します。

kubectl --kubeconfig $(Get-AksHciConfig).Kva.kubeconfig delete csidriver disk.csi.akshci.com`

アップグレードが成功した後も、Windows Admin Center更新ダッシュボードには以前のバージョンが表示されます。

この問題を解決するには、ブラウザーを最新の情報に更新します。

AKS on Azure Stack HCI の 6 月の 1.0.1.10628 ビルドでは、クラスターに過剰な数の Kubernetes 構成クラスターが作成されます。 6 月の 1.0.1.10628 リリースから 7 月の 1.0.2.10723 リリースへのアップグレード パスが改善され、余分な Kubernetes シークレットがクリーン アップされます。 ただし、場合によっては、アップグレード中にシークレットがクリーン アップされないため、アップグレード プロセスが失敗します。

この問題が発生した場合は、次の手順を実行します。

1. 下のスクリプトを fix_leaked_secrets.ps1 という名前のファイルとして保存します。

   upgparam (
   [Parameter(Mandatory=$true)]
   [string] $ClusterName,
   [Parameter(Mandatory=$true)]
   [string] $ManagementKubeConfigPath
   )
   
   $ControlPlaneHostName = kubectl get nodes --kubeconfig $ManagementKubeConfigPath -o=jsonpath='{.items[0].metadata.name}'
   "Hostname is: $ControlPlaneHostName"
   
   $leakedSecretPath1 = "$ClusterName-template-secret-akshci-cc"
   $leakedSecretPath2 = "$ClusterName-moc-kms-plugin"
   $leakedSecretPath3 = "$ClusterName-kube-vip"
   $leakedSecretPath4 = "$ClusterName-template-secret-akshc"
   $leakedSecretPath5 = "$ClusterName-linux-template-secret-akshci-cc"
   $leakedSecretPath6 = "$ClusterName-windows-template-secret-akshci-cc"
   
   $leakedSecretNameList = New-Object -TypeName 'System.Collections.ArrayList';
   $leakedSecretNameList.Add($leakedSecretPath1) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath2) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath3) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath4) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath5) | Out-Null
   $leakedSecretNameList.Add($leakedSecretPath6) | Out-Null
   
   foreach ($leakedSecretName in $leakedSecretNameList)
   {
   "Deleting secrets with the prefix $leakedSecretName"
   $output = kubectl --kubeconfig $ManagementKubeConfigPath exec etcd-$ControlPlaneHostName -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl --cacert /etc/kubernetes/pki/etcd/ca.crt --key /etc/kubernetes/pki/etcd/server.key --cert /etc/kubernetes/pki/etcd/server.crt del /registry/secrets/default/$leakedSecretName --prefix=true"
   "Deleted: $output"
   }
   

2. 次に、保存した fix_secret_leak.ps1 ファイルを使用して次のコマンドを実行します。

      .\fix_secret_leak.ps1 -ClusterName (Get-AksHciConfig).Kva.KvaName -ManagementKubeConfigPath (Get-AksHciConfig).Kva.Kubeconfig
   

3. 最後に、次の PowerShell コマンドを使用してアップグレード プロセスを繰り返します。

      Update-AksHci
   

次の手順

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

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