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 に継続的に参加しようとすると、ホスト上のポートの供給が使い果たされる可能性があります。 次のコマンドの状態は Starting です。

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 は、wssdcloudagent.exe バージョンが May ビルドがインストールされていることを示している間に、6 月のビルドがインストールされていることを示します。

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. Repeat.

予期される動作 クラスターの状態は正常である必要があります。 すべての 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 を実行すると、アップグレード プロセスがストールします。

次のコマンドを実行して、アップグレードする以前のバージョンの Kubernetes を実行している PHASE 削除しているマシンがあるかどうかを確認します。

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

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

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

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

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

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 年 2 月の更新プログラムから 2022 年 4 月の更新プログラムにクラスターをアップグレードすると、無期限に更新プログラムのアップグレードが停止する可能性があります。 Terminating状態またはCrashLoopBackoff状態でポッドがスタックしている可能性があります。

AksHci CSI アドオン リソースの一部が不足していることがわかります。 これらのリソース ポッドは、 csi-akshcicsi-controller を使用して、または csi-akshcicsi-node デーモンセットからデプロイされます。

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 を使用してバグを報告できます。