다음을 통해 공유


CSE 오류로 인해 노드 준비 안 됨 오류 문제 해결

이 문서는 MICROSOFT AKS(Azure Kubernetes Service) 클러스터가 상태가 아니며 Succeeded CSE(사용자 지정 스크립트 확장) 오류로 인해 AKS 노드가 노드 풀 내에서 준비되지 않은 시나리오를 해결하는 데 도움이 됩니다.

필수 조건

증상

CSE 오류로 인해 AKS 클러스터 노드는 노드 풀 내에서 준비되지 않으며 AKS 클러스터는 상태가 아닙니다 Succeeded .

원인

kubelet 및 기타 구성 요소를 프로비전할 때 노드 확장 배포가 실패하고 둘 이상의 오류 코드를 반환합니다. 이것이 오류의 가장 일반적인 원인입니다. kubelet을 프로비전할 때 노드 확장 배포가 실패하는지 확인하려면 다음 단계를 수행합니다.

  1. 클러스터의 현재 오류를 더 잘 이해하려면 az aks showaz resource update 명령을 실행하여 디버깅을 설정합니다.

    환경 변수를 설정하고 명령을 실행하여 클러스터의 상태를 보고 정보를 디버그합니다.

    export RG_NAME="my-aks-rg"
    export CLUSTER_NAME="myakscluster"
    clusterResourceId=$(az aks show \
        --resource-group $RG_NAME --name $CLUSTER_NAME --output tsv --query id)
    az resource update --debug --verbose --ids $clusterResourceId
    

    결과:

    {
      "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-aks-rg-xxx/providers/Microsoft.ContainerService/managedClusters/myaksclusterxxx",
      "name": "myaksclusterxxx",
      "type": "Microsoft.ContainerService/managedClusters",
      "location": "eastus2",
      "tags": null,
      "properties": {
        ...
      }
    }
    
  2. GitHub의 CSE 도우미az resource update대해 명령에서 받은 디버깅 출력 및 오류 메시지를 확인합니다.

kubelet의 CSE 배포와 관련된 오류가 있는 경우 여기에 설명된 시나리오가 노드 준비 안 됨 실패의 원인인지 확인했습니다.

일반적으로 종료 코드는 오류를 일으키는 특정 문제를 식별합니다. 예를 들어 "API 서버와 통신할 수 없음" 또는 "인터넷에 연결할 수 없음"과 같은 메시지가 표시됩니다. 또는 종료 코드는 API 네트워크 시간 제한 또는 교체가 필요한 노드 오류를 경고할 수 있습니다.

해결 방법 1: 사용자 지정 DNS 서버가 올바르게 구성되었는지 확인

이름 확인을 올바르게 수행할 수 있도록 사용자 지정 DNS(도메인 이름 시스템) 서버를 설정합니다. 다음 요구 사항을 충족하도록 서버를 구성해야 합니다.

  • 사용자 지정 DNS 서버를 사용하는 경우 서버가 정상이고 네트워크를 통해 연결할 수 있는지 확인합니다.

  • 사용자 지정 DNS 서버에 Azure DNS IP 주소(또는 해당 주소에 대한 전달자)에 필요한 조건부 전달자가 있는지 확인합니다.

  • 프라이빗 AKS DNS 영역이 Azure에서 호스트되는 경우 사용자 지정 DNS 가상 네트워크에 연결되어 있는지 확인합니다.

  • 사용자 지정 DNS 서버 IP 주소를 Azure DNS IP 주소로 사용하지 마십시오. 이 작업은 권장되지 않습니다.

  • DNS 설정에서 DNS 서버 대신 IP 주소를 사용하지 않습니다. Azure CLI 명령을 사용하여 Virtual Machine Scale Set 또는 가용성 집합에서 이 상황을 확인할 수 있습니다.

    • Virtual Machine Scale Set 노드의 경우 az vmss run-command invoke 명령을 사용합니다.

      중요하다: VM 확장 집합을 지정 --instance-id 해야 합니다. 여기서는 유효한 인스턴스 ID(예: 0) 및 AKS 노드 리소스 그룹의 VMSS에 대한 쿼리를 보여 줍니다. 사용자 환경에 맞게 값을 적절하게 업데이트합니다.

      export NODE_RESOURCE_GROUP=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
      export VMSS_NAME=$(az vmss list --resource-group $NODE_RESOURCE_GROUP --query "[0].name" -o tsv)
      export DNS_IP_ADDRESS="10.0.0.10"
      export INSTANCE_ID=$(az vmss list-instances --resource-group $NODE_RESOURCE_GROUP --name $VMSS_NAME --query "[0].instanceId" -o tsv)
      export API_FQDN=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query fqdn -o tsv)
      
      az vmss run-command invoke \
          --resource-group $NODE_RESOURCE_GROUP \
          --name $VMSS_NAME \
          --instance-id $INSTANCE_ID \
          --command-id RunShellScript \
          --output tsv \
          --query "value[0].message" \
          --scripts "telnet $DNS_IP_ADDRESS 53"
      az vmss run-command invoke \
          --resource-group $NODE_RESOURCE_GROUP \
          --name $VMSS_NAME \
          --instance-id $INSTANCE_ID \
          --command-id RunShellScript \
          --output tsv \
          --query "value[0].message" \
          --scripts "nslookup $API_FQDN $DNS_IP_ADDRESS"
      
    • VM 가용성 집합 노드의 경우 az vm run-command invoke 명령을 사용합니다.

      중요하다: 리소스 그룹의 가용성 집합에서 유효한 VM을 지정 --name 해야 합니다. 다음은 네트워크 검사를 실행하기 위한 템플릿입니다.

      az vm run-command invoke \
          --resource-group $RG_NAME \
          --name $AVAILABILITY_SET_VM \
          --command-id RunShellScript \
          --output tsv \
          --query "value[0].message" \
          --scripts "telnet $DNS_IP_ADDRESS 53"
      az vm run-command invoke \
          --resource-group $RG_NAME \
          --name $AVAILABILITY_SET_VM \
          --command-id RunShellScript \
          --output tsv \
          --query "value[0].message" \
          --scripts "nslookup $API_FQDN $DNS_IP_ADDRESS"
      

자세한 내용은 Azure 가상 네트워크 및 허브의 리소스 및 사용자 지정 DNS를 사용한 스포크에 대한 이름 확인을 참조하세요.

솔루션 2: API 네트워크 시간 제한 수정

API 서버에 연결할 수 있고 지연이 발생하지 않는지 확인합니다. 이렇게 하려면 다음 단계를 수행하세요.

  • AKS 서브넷을 확인하여 할당된 NSG(네트워크 보안 그룹)가 API 서버에 대한 송신 트래픽 포트 443을 차단하고 있는지 확인합니다.

  • 노드 자체를 확인하여 노드에 트래픽을 차단하는 다른 NSG가 있는지 확인합니다.

  • AKS 서브넷에서 할당된 경로 테이블을 확인합니다. 경로 테이블에 NVA(네트워크 가상 어플라이언스) 또는 방화벽이 있는 경우 송신 트래픽에 포트 443을 사용할 수 있는지 확인합니다. 자세한 내용은 AKS에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

  • DNS가 이름을 성공적으로 확인하고 API에 연결할 수 있지만 API 시간 제한으로 인해 노드 CSE가 실패한 경우 다음 표와 같이 적절한 작업을 수행합니다.

    형식 설정 작업
    VM 가용성 집합 kubectl delete 노드 명령을 사용하여 Azure Portal 및 AKS API에서 노드를 삭제 한 다음 클러스터를 다시 강화합니다.
    가상 머신 스케일 세트 (Virtual Machine Scale Set) Azure Portal에서 노드를 이미지로 다시 설치하거나 노드를 삭제한 다음 클러스터를 다시 강화합니다. 특정 노드를 삭제하려면 az aks nodepool delete-machines 명령을 사용합니다. 먼저 코드 및 드레이닝한 다음 노드를 삭제합니다.
  • AKS API 서버에서 요청을 제한하는 경우 더 높은 서비스 계층으로 업그레이드합니다. 자세한 내용은 AKS의 가격 책정 계층을 참조 하세요.

자세한 정보

  • 일반적인 문제 해결 단계는 노드 준비 안 됨 오류의 기본 문제 해결을 참조 하세요.