AKS Arc에서 Kubernetes 관리 및 워크로드 클러스터 문제 해결

Remove-ClusterNode 명령을 실행할 때 노드는 장애 조치(failover) 클러스터에서 제거되지만 나중에 Remove-AksHciNode가 실행되지 않으면 CloudAgent에 노드가 계속 존재합니다.

노드가 클러스터에서 제거되었지만 CloudAgent에서 제거되지 않았기 때문에 VHD를 사용하여 새 노드를 만드는 경우 "파일을 찾을 수 없음" 오류가 나타납니다. 이 문제는 VHD가 공유 스토리지에 있고 제거된 노드에 액세스할 수 없기 때문에 발생합니다.

이 문제를 resolve 클러스터에서 물리적 노드를 제거한 다음 다음 단계를 수행합니다.

1. 를 실행 Remove-AksHciNode 하여 CloudAgent에서 노드 등록을 해제합니다.
2. 컴퓨터 다시 이미징과 같은 일상적인 유지 관리를 수행합니다.
3. 노드를 클러스터에 다시 추가합니다.
4. 를 실행 Add-AksHciNode 하여 CloudAgent에 노드를 등록합니다.

큰 클러스터에서 명령은 예외를 Get-AksHciLogs throw하거나 노드를 열거하지 못하거나 c:\wssd\wssdlogs.zip 출력 파일을 생성하지 않을 수 있습니다.

'Compress-Archive' 파일을 압축하는 PowerShell 명령의 출력 파일 크기 제한은 2GB이기 때문입니다.

워크로드 클러스터를 업그레이드하거나 확장한 후 Pod는 파일 위치에서 /etc/Kubernetes/pki인증서 문신 YAML 파일을 예상하므로 인증서 갱신 Pod가 크래시 루프 상태가 되었습니다.

이 문제는 컨트롤 플레인 VM에 있지만 작업자 노드 VM에는 없는 구성 파일 때문일 수 있습니다.

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

1. 워크로드 클러스터의 컨트롤 플레인 VM에서 호스트 머신의 현재 디렉터리로 YAML 파일을 복사합니다.

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단계를 반복합니다.

Aks-Hci PowerShell 명령은 Kubernetes 노드를 만들기 전에 호스트 서버에서 사용 가능한 메모리의 유효성을 검사하지 않습니다. 이 문제는 메모리 소모 및 시작되지 않는 가상 머신으로 이어질 수 있습니다.

이 오류는 현재 정상적으로 처리되지 않으며 명확한 오류 메시지 없이 배포가 응답하지 않습니다. 응답을 중지하는 배포가 있는 경우 이벤트 뷰어 열고 VM을 시작할 메모리가 충분하지 않음을 나타내는 Hyper-V 관련 오류 메시지에 대한 검사.

Get-AksHciCluster를 실행하여 Windows Admin Center AKS Arc 설치의 상태 확인할 때 출력에 "버전 1.0.3.10818이 있는 릴리스를 찾을 수 없습니다."라는 오류가 표시됩니다. 그러나 Get-AksHciVersion을 실행할 때 동일한 버전이 설치된 것으로 나타났습니다. 이 오류는 빌드가 만료되었음을 나타냅니다.

이 문제를 resolve 을 실행Uninstall-AksHci한 다음, 새 AKS Arc 빌드를 실행합니다.

클러스터 관리 도구를 사용하여 Azure Stack HCI 클러스터의 한 노드(노드 A)에서 다른 노드(노드 B)로 VM을 이동하는 경우 VM이 새 노드에서 시작되지 않을 수 있습니다. VM을 원래 노드로 다시 이동한 후에도 VM이 시작되지 않습니다.

이 문제는 첫 번째 마이그레이션을 클린 논리가 비동기적으로 실행되므로 발생합니다. 결과적으로 Azure Kubernetes Service "VM 위치 업데이트" 논리는 노드 A의 원래 Hyper-V에서 VM을 찾아 등록 취소하는 대신 삭제합니다.

이 문제를 해결하려면 VM이 원래 노드로 다시 이동하기 전에 새 노드에서 성공적으로 시작되었는지 확인합니다.

PowerShell을 사용하여 고정 IP 주소가 있는 클러스터를 만든 다음 워크로드 클러스터의 작업자 노드 수를 늘리려고 하면 설치가 "컨트롤 플레인 수 2에서 여전히 원하는 상태를 기다리는 중: 3"에 중단됩니다. 일정 시간이 지나면 "오류: 조건 대기 시간이 초과되었습니다."라는 오류 메시지가 나타납니다.

Get-AksHciCluster가 실행되었을 때 컨트롤 플레인 노드가 만들어지고 프로비전되었으며 준비 상태인 것으로 나타났습니다. 그러나 kubectl get nodes 가 실행되면 컨트롤 플레인 노드가 만들어졌지만 프로비전되지 않았으며 준비 상태가 아닌 것으로 나타났습니다.

이 오류가 발생하면 Hyper-V 관리자 또는 PowerShell을 사용하여 만든 노드에 IP 주소가 할당되었는지 확인합니다.

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

그런 다음, 네트워크 설정을 확인하여 더 많은 VM을 만들기 위해 풀에 충분한 IP 주소가 남아 있는지 확인합니다.

, , Update-AksHciCertificatesUpdate-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. 다음 명령을 실행하여 노드를 삭제합니다.

kubectl delete node <node-name>

4. 다음 명령을 실행하여 노드 목록을 반환합니다.

kubectl get nodes

제거된 노드는 출력에 나열되지 않습니다. 5. 관리자 권한으로 PowerShell 창을 열고 다음 명령을 실행합니다.

get-vm

제거된 노드는 여전히 나열됩니다.

이 오류로 인해 시스템에서 노드가 누락된 것을 인식하지 못하므로 새 노드가 스핀업되지 않습니다.

관리 또는 워크로드 클러스터를 60일 이상 사용하지 않으면 인증서가 만료되고 AKS Arc를 업그레이드하기 전에 갱신해야 합니다. AKS 클러스터가 60일 이내에 업그레이드되지 않으면 KMS 플러그 인 토큰과 인증서가 모두 60일 이내에 만료됩니다. 클러스터는 여전히 작동합니다. 그러나 60일이 지났으므로 업그레이드하려면 Microsoft 지원에 전화해야 합니다. 이 기간 이후에 클러스터가 다시 부팅되면 비기능 상태로 유지됩니다.

이 문제를 resolve 다음 단계를 실행합니다.

1. 토큰을 수동으로 회전하여 관리 클러스터 인증서를 복구한 다음 KMS 플러그 인 및 컨테이너를 다시 시작합니다.
2. 를 mocctl 실행 Repair-MocLogin하여 인증서를 복구합니다.
3. 토큰을 수동으로 회전하여 워크로드 클러스터 인증서 를 복구한 다음 KMS 플러그 인 및 컨테이너를 다시 시작합니다.

Azure Stack HCI 배포에서 두 AKS의 IP 주소 풀이 동일하거나 겹치는 경우 워크로드 클러스터를 찾을 수 없습니다. 두 AKS 호스트를 배포하고 둘 다에 대해 동일한 구성을 사용하는 경우 API 서버에 두 클러스터에 동일한 AksHciNetworkSetting IP 주소가 할당되어 충돌이 발생하므로 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 액세스하고 진행 상황을 모니터링합니다.

며칠 Kubectl 후 Azure Stack HCI 배포에서 AKS를 가져오려고 할 때 명령을 실행하지 않았습니다. 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 cmdlet이 실패합니다. Azure Stack HCI의 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이 있는 Azure Stack HCI의 AKS 설치에서 관리 클러스터는 PowerShell을 사용하여 설정되었으며 Windows Admin Center 사용하여 워크로드 클러스터를 배포하려고 했습니다. 컴퓨터 중 하나에 PowerShell 모듈 버전 1.0.2가 설치되어 있고 다른 컴퓨터에는 PowerShell 모듈 1.1.3이 설치되어 있습니다. "매개 변수 이름 'nodePoolName'과 일치하는 매개 변수를 찾을 수 없습니다." 오류와 함께 워크로드 클러스터를 배포하지 못했습니다. 버전 불일치로 인해 이 오류가 발생했을 수 있습니다. PowerShell 버전 1.1.0 -nodePoolName <String> 부터 매개 변수가 New-AksHciCluster cmdlet에 추가되었으며, 기본적으로 이 매개 변수는 이제 Windows Admin Center 확장 버전 1.82.0을 사용할 때 필수입니다.

이 문제를 해결하려면 다음 중 하나를 수행합니다.

• PowerShell을 사용하여 워크로드 클러스터를 버전 1.1.0 이상으로 수동으로 업데이트합니다.
• Windows Admin Center 사용하여 클러스터를 버전 1.1.0 또는 최신 PowerShell 버전으로 업데이트합니다.

이 문제는 최신 PowerShell 모듈이 이미 설치되어 있으므로 Windows Admin Center 사용하여 관리 클러스터를 배포하는 경우 발생하지 않습니다.

Azure Stack HCI에 AKS를 배포한 다음 를 실행 kubectl get pods하면 동일한 노드의 Pod가 종료 중 상태로 중단됩니다. 노드에 높은 메모리 수요가 발생할 가능성이 높기 때문에 컴퓨터에서 SSH 연결을 거부합니다. 이 문제는 Windows 노드가 과도하게 프로비전되고 핵심 구성 요소에 대한 예약이 없기 때문에 발생합니다.

이러한 상황을 방지하려면 CPU 및 메모리에 대한 리소스 제한 및 리소스 요청을 Pod 사양에 추가하여 노드가 과도하게 프로비전되지 않도록 합니다. Windows 노드는 리소스 제한에 따라 제거를 지원하지 않으므로 컨테이너가 사용할 양을 예측한 다음 노드에 충분한 CPU 및 메모리 양이 있는지 확인해야 합니다. 시스템 요구 사항에서 자세한 정보를 찾을 수 있습니다.

AKS 호스트 관리 클러스터에서 다음 Azure 정책을 사용하면 클러스터 자동 크기 조정이 실패할 수 있습니다. "Kubernetes 클러스터는 기본 네임스페이스를 사용하면 안 됩니다." 이는 AKS 호스트 관리 클러스터에서 구현된 정책이 기본 네임스페이스에서 자동 크기 조정기 프로필 생성을 차단하기 때문에 발생합니다. 이 문제를 해결하려면 다음 옵션 중 하나를 선택합니다.

• AKS 호스트 관리 클러스터에서 Azure Policy 확장을 제거합니다. 여기에서 Azure Policy 확장을 제거하는 방법에 대해 자세히 알아보세요.
• AKS 호스트 관리 클러스터를 제외하도록 Azure 정책의 scope 변경합니다. 여기에서 Azure Policy 범위에 대해 자세히 알아보세요.
• AKS 호스트 관리 클러스터에 대한 정책 적용 모드를 "사용 안 함"으로 설정합니다. 여기에서 적용 모드에 대해 자세히 알아보세요.

이는 Azure Stack HCI의 AKS 7월 업데이트(버전 1.0.2.10723)의 알려진 문제입니다. 이 오류는 시스템의 여러 클러스터 공유 볼륨에서 가상 머신을 배포하는 동안 CloudAgent 서비스가 시간 초과되었기 때문에 발생합니다.

이 문제를 resolve Azure Stack HCI 릴리스의 최신 AKS로 업그레이드해야 합니다.

Linux 또는 Windows 노드가 없는 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 것입니다. 이는 스케일 아웃 작업을 수행하거나 노드에서 를 다시 시작한 후 새 Kubernetes 클러스터를 만들 때 노드 풀을 만들어 생성되는 wssdagent 새 VM에 대해서만 작동합니다. 그러나 장애 조치(failover) 클러스터에 기존 VM을 수동으로 추가해야 합니다.

클러스터를 축소하면 VM이 제거되는 동안 고가용성 클러스터 리소스가 실패 상태입니다. 이 문제의 해결 방법은 실패한 리소스를 수동으로 제거하는 것입니다.

Azure VM에 배포된 AKS 클러스터는 이전에 제대로 작동했지만 AKS 호스트가 며칠 동안 꺼진 후 명령이 Kubectl 작동하지 않았습니다. 또는 Kubectl get services 명령을 실행한 Kubectl get nodes 후 이 오류 메시지가 나타났습니다Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

이 문제는 AKS 호스트가 4일 이상 꺼져 인증서가 만료되었기 때문에 발생했습니다. 인증서는 4일 주기로 자주 회전됩니다. Repair-AksHciClusterCerts를 실행하여 인증서 만료 문제를 해결합니다.

고정 IP 주소와 Windows 노드가 있는 워크로드 클러스터에서 노드의 모든 Pod(Pod 포함 daemonset )는 ContainerCreating 상태로 중단됩니다. SSH를 사용하여 해당 노드에 연결하려고 하면 연결이 실패하고 오류가 발생합니다 Connection timed out .

이 문제를 resolve Hyper-V 관리자 또는 장애 조치(failover) 클러스터 관리자를 사용하여 해당 노드의 VM을 끕니다. 5~10분 후에 모든 Pod가 실행되는 상태에서 노드를 다시 만들어야 합니다.

kubelet이 디스크 압력을 받고 있는 경우 일시 중지 이미지를 포함할 수 있는 사용되지 않는 컨테이너 이미지를 수집하며, 이 경우 ContainerD는 이미지를 끌어올 수 없습니다.

이 문제를 resolve 다음 단계를 실행합니다.

1. SSH를 사용하여 영향을 받는 노드에 연결하고 다음 명령을 실행합니다.

sudo su

2. 이미지를 끌어오려면 다음 명령을 실행합니다.

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

다음 단계

• 문제 해결 개요
• 네트워킹 문제 및 오류
• 스토리지 알려진 문제