편집

AKS Arc에서 네트워크를 구성할 때 알려진 문제 및 오류 해결

  • FAQ

적용 대상: Azure Stack HCI의 AKS, Windows Server의 AKS 이 항목을 사용하여 AKS Arc에서 네트워킹 관련 문제를 해결하고 resolve 수 있습니다.

오류: '장애 조치(failover) 클러스터에서 클라우드 에이전트 일반 클러스터 서비스를 시작하지 못했습니다. 클러스터 리소스 그룹이 '실패' 상태입니다.

클라우드 에이전트는 공백이 있는 경로 이름을 사용할 때 성공적으로 시작하지 못할 수 있습니다.

Set-AksHciConfig를 사용하여 와 같은 D:\Cloud Share\AKS HCI공백 문자가 포함된 경로 이름을 가진 , -workingDir, -cloudConfigLocation또는 -nodeConfigLocation 매개 변수를 지정-imageDir하는 경우 클라우드 에이전트 클러스터 서비스는 다음(또는 이와 유사한) 오류 메시지로 시작하지 못합니다.

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

이 문제를 해결하려면 공백을 포함하지 않는 경로(예 C:\CloudShare\AKS-HCI: )를 사용합니다.

Arc 연결 클러스터에는 빈 JSON "배포" 속성이 있습니다.

Kubernetes에 연결된 클러스터용 Azure Arc는 JSON 속성 distribution 의 값을 빈 문자열로 설정할 수 있습니다. AKS Arc 연결 클러스터의 경우 이 값은 초기 설치 중에 설정되며 배포 수명 동안 변경되지 않습니다.

문제를 재현하려면 Azure PowerShell 창을 열고 다음 명령을 실행합니다.

az login
az account set --subscription <sub_id>
az connectedk8s show -g <rg_name> -n

다음은 이 명령의 출력 예제입니다.

{
"agentPublicKeyCertificate": <value>
"agentVersion": "1.8.14",
"azureHybridBenefit": "NotApplicable",
"connectivityStatus": "Connected",
"distribution": "",
"distributionVersion": null,
"id": "/subscriptions/<subscription>/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",
"identity": {
  "principalId": "<principal id>",
  "tenantId": "<tenant id>",
  "type": "SystemAssigned"
},
"infrastructure": "azure_stack_hci",
"kubernetesVersion": "1.23.12",
"lastConnectivityTime": "2022-11-04T14:59:59.050000+00:00",
"location": "eastus",
"managedIdentityCertificateExpirationTime": "2023-02-02T14:24:00+00:00",
"miscellaneousProperties": null,
"name": "mgmt-cluster",
"offering": "AzureStackHCI_AKS_Management",
"privateLinkScopeResourceId": null,
"privateLinkState": "Disabled",
"provisioningState": "Succeeded",
"resourceGroup": "<resource group>",
"systemData": {
  "createdAt": "2022-11-04T14:29:17.680060+00:00",
  "createdBy": "<>",
  "createdByType": "Application",
  "lastModifiedAt": "2022-11-04T15:00:01.830067+00:00",
  "lastModifiedBy": "64b12d6e-6549-484c-8cc6-6281839ba394",
  "lastModifiedByType": "Application"
},
"tags": {},
"totalCoreCount": 4,
"totalNodeCount": 1,
"type": "microsoft.kubernetes/connectedclusters"
}

문제를 resolve

JSON distribution 속성의 출력이 빈 문자열을 반환하는 경우 다음 지침에 따라 클러스터를 패치합니다.

  1. 다음 구성을 patchBody.json 라는 파일에 복사합니다.

    {
   "properties": {
     "distribution": "aks_management"
   }
}

    중요

    클러스터가 AKS 관리 클러스터인 경우 값을 로 aks_management설정해야 합니다. 워크로드 클러스터인 경우 로 설정 aks_workload해야 합니다.

  2. 위에서 얻은 JSON 출력에서 연결된 클러스터 ID를 복사합니다. 다음 형식으로 긴 문자열로 표시됩니다.

    "/subscriptions/<subscription >/resourceGroups/<resource group>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>",

  3. 다음 명령을 실행하여 클러스터를 패치합니다. 값은 <cc_arm_id> 2단계에서 가져온 ID여야 합니다.

    az rest -m patch -u "<cc_arm_id>?api-version=2022-10-01-preview" -b "@patchBody.json"

  4. 를 실행 az connectedk8s show -g <rg_name> -n <cc_name> 하여 클러스터가 성공적으로 패치되었는지 확인하여 JSON 속성 distribution 이 올바르게 설정되었는지 확인합니다.

WSSDAgent 서비스가 시작하는 동안 중단되고 클라우드 에이전트에 연결하지 못함

증상:

  • AKS Arc에서 프록시를 사용하도록 설정했습니다. WSSDAgent 서비스가 상태에서 중단되었습니다 starting . 다음으로 표시됩니다.
  • Test-NetConnection -ComputerName <computer IP/Name> -Port <port> 노드 에이전트가 클라우드 에이전트에 실패하는 노드에서 시스템에서 제대로 작동합니다(wssdagent가 시작되지 않은 경우에도).
  • 에이전트가 클라우드 에이전트에 실패하는 노드에서 Curl.exe 문제를 재현하고 중단됩니다. curl.exe https://<computerIP>:6500
  • 문제를 해결하려면 플래그를 --noproxy curl.exe 전달합니다. Curl은 wssdcloudagent에서 오류를 반환합니다. curl이 GRPC 클라이언트가 아니므로 이 값이 필요합니다. 플래그를 보낼 --noproxy 때 Curl이 기다리지 않습니다. 따라서 오류를 반환하는 것은 여기에서 성공으로 간주됩니다.
curl.exe --noproxy '*' https://<computerIP>:65000

프록시 설정이 호스트의 잘못된 프록시로 변경되었을 수 있습니다. AKS Arc의 프록시 설정은 호스트의 부모 프로세스에서 상속되는 환경 변수입니다. 이러한 설정은 새 서비스가 시작되거나 이전 서비스가 업데이트되거나 다시 부팅될 때만 전파됩니다. 호스트에서 잘못된 프록시 설정이 설정되었고 업데이트 또는 다시 부팅 후 WSSDAgent로 전파되어 WSSDAgent가 실패할 수 있습니다.

컴퓨터에서 환경 변수를 변경하여 프록시 설정을 수정해야 합니다. 컴퓨터에서 다음 명령을 사용하여 변수를 변경합니다.

  [Environment]::SetEnvironmentVariable("https_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("http_proxy", <Value>, "Machine")
  [Environment]::SetEnvironmentVariable("no_proxy", <Value>, "Machine")

서비스 관리자와 WSSDAgent가 고정 프록시를 선택하게 컴퓨터를 다시 부팅합니다.

CAPH Pod가 인증서를 갱신하지 못함

이 오류는 CAPH Pod가 시작될 때마다 cloudagent에 대한 로그인이 시도되고 인증서가 임시 스토리지 볼륨에 저장되어 Pod 다시 시작 시 클린 때문에 발생합니다. 따라서 Pod가 다시 시작될 때마다 인증서가 삭제되고 새 로그인 시도가 이루어집니다.

로그인 시도는 갱신 루틴을 시작하여 만료가 임박한 경우 인증서를 갱신합니다. CAPH Pod는 인증서를 사용할 수 있는지 여부를 로그인해야 하는지 여부를 결정합니다. 인증서를 사용할 수 있는 경우 갱신 루틴이 이미 있다고 가정하여 로그인을 시도하지 않습니다.

그러나 컨테이너를 다시 시작할 때 임시 디렉터리가 정리되지 않으므로 파일이 계속 유지되고 로그인 시도가 수행되지 않아 갱신 루틴이 시작되지 않습니다. 이로 인해 인증서 만료가 발생합니다.

이 문제를 완화하려면 다음 명령을 사용하여 CAPH Pod를 다시 시작합니다.

kubectl delete pod pod-name

WinRM 오류로 인해 Set-AksHciConfig 실패하지만 WinRM이 올바르게 구성되었음을 표시합니다.

Set-AksHciConfig를 실행할 때 다음 오류가 발생할 수 있습니다.

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

대부분의 경우 이 오류는 사용자의 보안 토큰 변경(그룹 멤버 자격 변경), 암호 변경 또는 만료된 암호로 인해 발생합니다. 대부분의 경우 컴퓨터에서 로그오프했다가 다시 로그인하여 문제를 수정할 수 있습니다. 오류가 계속 발생하는 경우 Azure Portal 통해 지원 티켓을 만들 수 있습니다.

AKS Arc 클러스터가 "ScalingControlPlane" 프로비저닝 상태에서 중단됨

이 문제로 인해 AKS Arc 클러스터가 장기간 ScalingControlPlane 상태로 유지됩니다.

재현하려면

Get-AksHciCluster -Name <cluster name> | select *

Status                : {ProvisioningState, Details}
ProvisioningState     : ScalingControlPlane
KubernetesVersion     : v1.22.6
PackageVersion        : v1.22.6-kvapkg.0
NodePools             : {nodepoolA, nodepoolB}
WindowsNodeCount      : 0
LinuxNodeCount        : 1
ControlPlaneNodeCount : 1
ControlPlaneVmSize    : Standard_D4s_v3
AutoScalerEnabled     : False
AutoScalerProfile     :
Name                  : <cluster name>

이 문제는 최근 AKS Arc 버전에서 해결되었습니다. AKS Arc 클러스터를 최신 릴리스로 업데이트하는 것이 좋습니다.

이 문제를 완화하려면 지원팀에 문의하여 컨트롤 플레인 노드의 상태 수동으로 패치하여 kubectl을 통해 컴퓨터 상태 MachineOwnerRemediatedCondition 조건을 제거합니다.

워크로드 클러스터를 찾을 수 없습니다.

Azure Stack HCI 배포에서 두 AKS의 IP 주소 풀이 동일하거나 겹치는 경우 워크로드 클러스터를 찾을 수 없습니다. 두 AKS 호스트를 배포하고 둘 다에 대해 동일한 AksHciNetworkSetting 구성을 사용하는 경우 API 서버에 두 클러스터에 동일한 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.

참고

클러스터 이름은 다릅니다.

문제를 resolve 클러스터 중 하나를 삭제하고 다른 클러스터와 겹치지 않는 네트워크가 있는 새 AKS 클러스터 네트워크 설정을 만듭니다.

Get-AksHCIClusterNetwork IP 주소의 현재 할당을 표시하지 않습니다.

Get-AksHciClusterNetwork 명령을 실행하면 모든 가상 네트워크 구성 목록이 제공됩니다. 그러나 명령은 IP 주소의 현재 할당을 표시하지 않습니다.

가상 네트워크에서 현재 사용 중인 IP 주소를 확인하려면 아래 단계를 사용합니다.

  1. 그룹을 얻으려면 다음 명령을 실행합니다.
Get-MocGroup -location MocLocation
  1. 현재 사용 중인 IP 주소 목록과 사용 가능하거나 사용된 가상 IP 주소 목록을 얻으려면 다음 명령을 실행합니다.
Get-MocNetworkInterface -Group <groupName> | ConvertTo-Json -depth 10
  1. 다음 명령을 사용하여 현재 사용 중인 가상 IP 주소 목록을 봅니다.
Get-MocLoadBalancer -Group <groupName> | ConvertTo-Json -depth 10

"클러스터 IP 주소 x.x.x.x"가 실패함

사전 검사 중에 클러스터 IP 주소가 "실패"로 표시됩니다. 이 사전 검사는 모든 IPv4 주소 및 DNS 네트워크 이름이 온라인이고 연결할 수 있는지 테스트합니다. 예를 들어 실패한 IPv4 또는 네트워크 이름으로 인해 이 테스트가 실패할 수 있습니다.

이를 resolve 다음 단계를 수행합니다.

  1. 다음 명령 실행:

    Get-ClusterGroup -name "Cluster Group" | Get-ClusterResource

  2. 모든 네트워크 이름 및 IP 주소가 온라인 상태인지 확인합니다.

  3. 다음 두 명령을 실행합니다.

    Stop-ClusterResource -name "Cluster IP Address x.x.x.x"

    그런 다음

    Start-ClusterResource -name "Cluster IP Address x.x.x.x"

잘못 구성된 네트워크를 사용하여 Azure Stack HCI에 AKS를 배포하는 경우 배포 시간이 여러 지점에서 초과되었습니다.

Azure Stack HCI에 AKS를 배포하는 경우 잘못된 구성이 발생한 위치에 따라 프로세스의 다른 지점에서 배포 시간이 초과될 수 있습니다. 오류 메시지를 검토하여 원인과 발생 위치를 확인해야 합니다.

예를 들어 다음 오류에서 잘못된 구성이 발생한 지점은 에 있습니다.Get-DownloadSdkRelease -Name "mocstack-stable"

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

이는 물리적 Azure Stack HCI 노드가 다운로드 URLmsk8s.api.cdp.microsoft.com의 이름을 resolve 수 있지만 노드가 대상 서버에 연결할 수 없음을 나타냅니다.

이 문제를 resolve 연결 흐름에서 분석이 발생한 위치를 결정해야 합니다. 다음은 물리적 클러스터 노드에서 문제를 resolve 몇 가지 단계입니다.

  1. 대상 DNS 이름 Ping: ping msk8s.api.cdp.microsoft.com.
  2. 응답을 다시 받고 시간 초과가 없으면 기본 네트워크 경로가 작동합니다.
  3. 연결 시간이 초과되면 데이터 경로에 중단이 있을 수 있습니다. 자세한 내용은 프록시 설정 검사 참조하세요. 또는 반환 경로에 중단이 있을 수 있으므로 방화벽 규칙을 검사 합니다.

NTP 시간 종속 트리거 수백 개의 거짓 경고인 애플리케이션

NTP 시간 종속 애플리케이션은 시간 동기화가 부족할 때 수백 개의 거짓 경고를 트리거할 수 있습니다. 클러스터가 프록시 환경에서 실행되는 경우 nodepools가 프록시 또는 방화벽을 통해 기본 NTP 서버( time.windows.com)와 통신하지 못할 수 있습니다.

해결 방법

이 문제를 해결하려면 각 노드 풀 노드에서 NTP 서버 구성을 업데이트하여 클록을 동기화합니다. 이렇게 하면 각 애플리케이션 Pod의 클록도 설정됩니다.

사전 요구 사항

  • 각 노드 풀 노드에서 액세스할 수 있는 NTP 서버의 주소입니다.
  • 워크로드 클러스터 kubeconfig 파일에 액세스합니다.
  • 관리 클러스터 kubeconfig에 대한 액세스.

단계

  1. 워크로드 클러스터 kubeconfig를 사용하여 다음 kubectl 명령을 실행하여 노드 목록을 가져옵니다.

    kubectl --kubeconfig <PATH TO KUBECONFIG> get nodes -owide

  2. 다음 kubectl 명령을 실행하여 이전 명령의 노드 이름을 워크로드 클러스터의 nodepool 노드와 상호 연결합니다. 이전 명령의 출력에서 관련 IP 주소를 기록해 둡니다.

    kubectl --kubeconfig (Get-KvaConfig).kubeconfig get machine -l cluster.x-k8s.io/cluster-name=<WORKLOAD_CLUSTER_NAME>

  3. 이전 단계의 출력을 사용하여 NTP 구성이 업데이트되어야 하는 각 nodepool 노드에 대해 다음 단계를 실행합니다.

    1. 노드 풀 노드 VM에 대한 SSH:

      ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<NODEPOOL_IP>

    2. 구성된 NTP 서버에 연결할 수 없는지 확인합니다.

      sudo timedatectl timesync-status

      출력이 다음과 같으면 NTP 서버에 연결할 수 없으며 다음을 변경해야 합니다.

      Server: n/a (time.windows.com)
Poll interval: 0 (min: 32s; max 34min 8s)
Packet count: 0

    3. NTP 서버를 업데이트하려면 다음 명령을 실행하여 timesync 구성 파일의 NTP 서버를 nodepool VM에서 액세스할 수 있는 서버로 설정합니다.

      # make a backup of the config file
sudo cp /etc/systemd/timesyncd.conf ~/timesyncd.conf.bak

# update the ntp server
NTPSERVER="NEW_NTP_SERVER_ADDRESS"
sudo sed -i -E "s|^(NTP=)(.*)$|\1$NTPSERVER|g" /etc/systemd/timesyncd.conf

# verify that the NTP server is updated correctly - check the value for the field that starts with "NTP="
sudo cat /etc/systemd/timesyncd.conf

    4. 시간 동기화 서비스를 다시 시작합니다.

      sudo systemctl restart systemd-timesyncd.service

    5. NTP 서버에 액세스할 수 있는지 확인합니다.

      sudo timedatectl timesync-status

    6. 시계에 올바른 시간이 표시되는지 확인합니다.

      date

  4. 3.f단계에서 명령을 실행하여 각 nodepool 노드가 동일한 시간을 표시하는지 확인합니다.

  5. 애플리케이션이 시간을 자동으로 업데이트하지 않으면 Pod를 다시 시작합니다.

다음 단계