AKS Arc를 업그레이드할 때 발생하는 문제 해결

이전 버전의 PowerShell은 제거되지 않습니다.

이 문제를 해결하려면 이 스크립트를 실행하여 이전 PowerShell 버전을 제거할 수 있습니다.

대상 클러스터를 업그레이드하거나 확장한 후 인증서 갱신 Pod가 크래시 루프 상태가 되었습니다. 경로/etc/Kubernetes/pki에서 인증서 문신 yaml 파일이 예상됩니다. 구성 파일은 컨트롤 플레인 노드 VM에 있지만 작업자 노드 VM에는 없습니다.

이 문제를 resolve 컨트롤 플레인 노드의 인증서 문신 파일을 각 작업자 노드에 수동으로 복사합니다.

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. 이 파일의 소유자 및 그룹 정보를 루트로 아직 설정하지 않은 경우 루트로 다시 설정합니다.

   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

예상 동작: 노드 에이전트는 클라우드 에이전트에 지속적으로 조인하여 포트를 소진하는 시작 단계에 있어야 합니다.

문제를 resolve 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 버전이 5월 빌드가 설치되었음을 나타내는 동안 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 query "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 cmdlet을 실행합니다.

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'

업그레이드할 때 작업자 노드에 추가한 모든 사용자 지정 taint, 역할 및 레이블이 손실될 수 있습니다. AKS는 관리되는 서비스이므로 제공된 PowerShell cmdlet 또는 Windows Admin Center 외부에서 수행할 때 사용자 지정 taint, 레이블 및 역할을 추가하는 것은 지원되지 않습니다.

이 문제를 해결하려면 New-AksHciNodePool cmdlet을 실행하여 작업자 노드에 대한 taint가 있는 노드 풀을 올바르게 만듭니 다.

관리 클러스터를 만들었지만 처음 60일 동안 워크로드 클러스터를 배포하지 않은 경우 이제 정책에서 벗어났기 때문에 클러스터를 만들지 못하도록 차단됩니다. 이 경우 Update-AksHci를 실행하면 배포 'AksHci 청구 운영자'가 준비되기를 기다리는 중 오류로 업데이트 프로세스가 차단됩니다. Sync-AksHciBilling을 실행하면 성공적인 출력이 반환됩니다. 그러나 Get-AksHciBillingStatus를 실행하는 경우 연결 상태 OutofPolicy입니다.

60일 동안 워크로드 클러스터를 배포하지 않은 경우 청구는 정책에서 제외됩니다.

이 문제를 해결하는 유일한 방법은 클린 설치를 사용하여 다시 배포하는 것입니다.

Azure Stack HCI 노드가 하나씩 다시 부팅되면 일부 가상 머신은 연결된 vNIC를 잃게 됩니다. 이 vNIC 손실로 인해 VM이 네트워크 연결을 끊고 클러스터가 잘못된 상태가 됩니다.

재현

1. 하나의 Azure Stack HCI 노드를 다시 부팅합니다.
2. 노드가 다시 부팅을 완료할 때까지 기다립니다. 노드를 장애 조치(failover) 클러스터에 표시 Up 해야 합니다.
3. 다른 노드를 다시 부팅합니다.
4. DRY(반복 금지)

예상 동작 클러스터 상태는 정상이어야 합니다. 모든 VM에는 NIC가 연결되어 있어야 합니다.

문제를 resolve 위해 MOC 명령을 사용하여 VM에 vNIC를 추가합니다.

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 연결 명령이 실패하면 연결을 끊고 다시 연결합니다. 다음은 vNIC 연결 끊기를 위한 명령입니다.

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

또는

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

정적 Pod가 준비 상태가 될 때까지 대기하는 동안 Pod가 멈춤

Pod를 해제하고 이 문제를 resolve kubelet을 다시 시작해야 합니다. 정적 Pod를 사용하여 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.

이 오류 메시지는 일반적으로 Azure Stack HCI의 AKS가 프록시가 구성된 환경에 배포될 때 발생합니다. 현재 Windows Admin Center 프록시 환경에 모듈을 설치할 수 없습니다.

이 오류를 resolve 프록시 PowerShell 명령을 사용하여 Azure Stack HCI에서 AKS를 설정합니다.

OPA GateKeeper와 같은 OPA(Open Policy Agent)를 사용하여 Kubernetes 클러스터를 업그레이드할 때 프로세스가 중단되어 완료할 수 없습니다. 이 문제는 정책 에이전트가 프라이빗 레지스트리에서 컨테이너 이미지를 끌어 오는 것을 방지하도록 구성되어 있기 때문에 발생할 수 있습니다.

이 문제를 resolve 위해 OPA를 사용하여 배포된 클러스터를 업그레이드하는 경우 정책에서 Azure Container Registry 이미지를 끌어 올 수 있는지 확인합니다. Azure Stack HCI의 AKS 업그레이드의 경우 정책 목록에 ecpacr.azurecr.io 엔드포인트를 추가해야 합니다.

Azure Stack HCI 배포에서 AKS를 사용하여 호스트에서 OS 업데이트를 실행하면 배포가 잘못된 상태가 되어 2일째 작업이 실패할 수 있습니다. MOC NodeAgent 서비스가 업데이트된 호스트에서 시작되지 않을 수 있습니다. 노드에 대한 모든 MOC 호출이 실패합니다.

재현하려면: 기존 AKS 배포를 사용하여 클러스터를 HCI에서 HCIv2로 업데이트하는 경우 와 같은 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]

이 문제를 resolve 영향을 받는 노드에서 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 버전을 삭제하고 VERSION 일치하는 컴퓨터 PHASE 가 있는 경우 다음 단계를 진행합니다.

이 문제를 해결하려면 다음 정보가 필요합니다.

1. 워크로드 클러스터를 업그레이드하는 Kubernetes 버전입니다.
2. 중단된 노드의 IP 주소입니다.

이 정보를 찾으려면 다음 cmdlet 및 명령을 실행합니다. 기본적으로 cmdlet 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 버전을 버전 값으로 사용합니다. 노드의 값ROLEScontrol-plane,master과 VERSION 일치해야 합니다. 예를 들어 v1.22.6를 포함하여 vKubernetes 버전의 전체 값을 포함해야 합니다.

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

이 ssh 명령을 실행한 후 이전 Kubernetes 버전이 있는 나머지 노드를 삭제하고 업그레이드가 진행됩니다.

Azure Stack HCI 배포에서 AKS를 사용하여 호스트에서 OS 업데이트를 실행하면 배포가 잘못된 상태가 되어 관리 클러스터의 API 서버에 연결할 수 없게 되어 2일째 작업이 실패할 수 있습니다. Pod는 kube-vip 인터페이스에 VIP 구성을 적용할 수 없으므로 VIP에 연결할 수 없습니다.

재현하려면: 기존 AKS HCI 배포를 사용하여 클러스터를 HCI에서 HCIv2로 업데이트합니다. 그런 다음, 와 같은 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)]

이 문제를 resolve: 컨테이너를 kube-vip 다시 시작하여 배포를 양호한 상태로 되돌릴 수 있습니다.

1. 컨테이너 ID를 kube-vip 가져옵니다.

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 cmdlet을 실행할 때 나타납니다.

문제를 resolve 다음 근본 원인을 검토합니다.

• 이유 1: AksHci 청구 연산자를 업데이트하는 동안 운영자가 자신을 정책 외부로 잘못 표시했습니다. 이 문제를 resolve 새 PowerShell 창을 열고 Sync-AksHciBilling을 실행합니다. 청구 작업은 다음 20-30분 이내에 계속되어야 합니다.

• 이유 2: 관리 클러스터 VM의 메모리가 부족하여 API 서버에 연결할 수 없게 되고 Get-AksHciCluster의 모든 명령, 청구 및 업데이트, 시간 초과가 발생할 수 있습니다. 해결 방법으로 Hyper-V에서 관리 클러스터 VM을 32GB로 설정하고 다시 부팅합니다.

• 이유 3: AksHci 청구 운영자 가 Microsoft SQL 구성 설정의 버그로 인해 스토리지 공간이 부족할 수 있습니다. 스토리지 공간이 부족하여 업그레이드가 응답하지 않을 수 있습니다. 이 문제를 해결하려면 다음 단계를 사용하여 청구 Pod pvc 의 크기를 수동으로 조정합니다.

  1. 다음 명령을 실행하여 Pod 설정을 편집합니다.

     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
     

Azure Stack HCI의 AKS 2022년 2월 업데이트에서 2022년 4월 업데이트로 클러스터를 업그레이드하는 경우 업데이트가 무기한 업그레이드 중단될 수 있습니다. 또는 CrashLoopBackoff 상태에 Pod가 붙어 Terminating 있을 수 있습니다.

AksHci CSI 추가 기능 리소스 중 일부가 누락된 것을 볼 수 있습니다. 이러한 리소스 Pod는 디먼 세트에서 또는 를 csi-akshcicsi-node 사용하여 csi-akshcicsi-controller 배포됩니다.

2022년 2월 업데이트의 AksHci CSI 추가 기능에는 업그레이드 중에 때때로 추가 기능의 리소스를 응답하지 않는 상태로 둘 수 있는 CSI 드라이버 사양 변경 내용이 포함되어 있습니다. 변경할 수 없는 필드임에도 불구하고 CSI 드라이버 .spec.fsGroupPolicy 가 새 값으로 설정되었습니다. 필드가 변경할 수 없으므로 드라이버 사양이 업데이트되지 않습니다. 그 결과 다른 AksHci CSI 추가 기능 리소스가 완전히 조정되지 않을 수 있습니다. 모든 CSI 리소스가 다시 만들어질 것입니다.

문제를 수동으로 resolve 위해 CSI 드라이버를 수동으로 삭제할 수 있습니다. 제거한 후 클라우드 운영자는 10분 이내에 AksHci CSI 추가 기능을 조정하고 누락된 나머지 추가 기능 리소스와 함께 드라이버를 다시 만듭니다.

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

업그레이드가 성공하면 Windows Admin Center 업데이트 dashboard 여전히 이전 버전이 표시됩니다.

브라우저를 새로 고쳐 이 문제를 해결합니다.

Azure Stack HCI의 AKS 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를 통해 버그를 제출할 수 있습니다.