AKS 클러스터 확장을 배포할 때 발생하는 오류 문제 해결
이 문서에서는 AKS(Microsoft Azure Kubernetes Service)용 클러스터 확장을 배포할 때 발생하는 오류를 해결하는 방법을 설명합니다.
확장 만들기 오류
오류: 에이전트로부터 제 시간에 응답을 가져올 수 없음
이 오류는 Azure 서비스가 클러스터 확장 에이전트로부터 응답을 받지 못하는 경우에 발생합니다. AKS 클러스터가 Azure와의 연결을 설정할 수 없기 때문에 이 상황이 발생할 수 있습니다.
원인 1: 클러스터 확장 에이전트 및 관리자 Pod가 초기화되지 않음
클러스터 확장 에이전트 및 관리자는 Kubernetes 애플리케이션의 수명 주기를 관리하는 중요한 시스템 구성 요소입니다. 다음 문제로 인해 클러스터 확장 에이전트 및 관리자 Pod의 초기화가 실패할 수 있습니다.
- 리소스 제한
- 정책 제한 사항
- 노드 테인트(예:
NoSchedule
솔루션 1: 클러스터 확장 에이전트 및 관리자 Pod가 올바르게 작동하는지 확인
이 문제를 해결하려면 클러스터 확장 에이전트 및 관리자 Pod가 올바르게 예약되어 있고 시작할 수 있는지 확인합니다. Pod가 준비되지 않은 상태에서 중단된 경우 다음 kubectl describe pod 명령을 실행하여 Pod 설명을 확인하여 기본 문제에 대한 자세한 내용을 확인합니다(예: 예약, 메모리 부족 또는 정책 제한을 방지하는 taints).
kubectl describe pod -n kube-system extension-operator-{id}
명령 출력 샘플은 다음과 같습니다.
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
ARC 연결 클러스터의 경우 다음 명령을 실행하여 Pod 설명을 확인합니다.
kubectl describe pod -n azure-arc extension-manager-{id}
명령 출력 샘플은 다음과 같습니다.
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
클러스터 확장 에이전트 및 관리자 Pod가 작동하고 정상이면 Azure 서비스와 통신하여 Kubernetes 애플리케이션을 설치하고 관리합니다.
원인 2: 문제가 송신 블록 또는 방화벽에 영향을 줍니다.
클러스터 확장 에이전트 및 관리자 Pod가 정상이고 "에이전트로부터 응답을 받을 수 없음" 오류가 계속 발생하는 경우 송신 블록 또는 방화벽 문제가 있을 수 있습니다. 이 문제는 클러스터 확장 에이전트 및 관리자 Pod가 Azure와 통신하지 못하도록 차단할 수 있습니다.
해결 방법 2: 네트워킹 필수 구성 요소가 충족되는지 확인
이 문제를 해결하려면 아웃바운드 네트워크 및 AKS(Azure Kubernetes Service) 클러스터에 대한 FQDN 규칙에 설명된 네트워킹 필수 구성 요소를 따라야 합니다.
원인 3: 트래픽에 권한이 없음
확장 에이전트가 데이터 평면 서비스 엔드포인트에 <region>.dp.kubernetesconfiguration.azure.com 대한 호출을 시도하지 못했습니다. 이 오류는 확장 에이전트 Pod 로그에 "Errorcode: 403, Message This traffic is not authorized" 항목을 생성합니다.
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
이 오류는 Azure Arc 지원 Kubernetes에 대한 확장의 데이터 평면에 기존 PrivateLinkScope가 있고 가상 네트워크(또는 프라이빗 DNS 서버)가 Azure Arc 지원 Kubernetes와 AKS 관리형 클러스터 간에 공유되는 경우에 발생합니다. 이 네트워킹 구성을 사용하면 확장 데이터 평면의 AKS 아웃바운드 트래픽도 공용 IP 주소를 통하지 않고 동일한 개인 IP 주소를 통해 라우팅됩니다.
AKS 클러스터에서 다음 nslookup 명령을 실행하여 데이터 평면 엔드포인트가 확인하는 특정 개인 IP 주소를 검색합니다.
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
Azure Portal에서 개인 IP 주소를 검색할 때 검색 결과는 가상 네트워크, 프라이빗 DNS 영역, 프라이빗 DNS 서버 등 정확한 리소스를 가리킵니다. 이 리소스에는 Azure Arc 지원 Kubernetes에 대한 확장 데이터 평면에 대해 구성된 프라이빗 엔드포인트가 있습니다.
솔루션 3.1: (권장) 별도의 가상 네트워크 만들기
이 문제를 해결하려면 Azure Arc 지원 Kubernetes 및 AKS 컴퓨팅을 위한 별도의 가상 네트워크를 만드는 것이 좋습니다.
솔루션 3.2: CoreDNS 재정의 만들기
사용자 상황에서 권장 솔루션을 사용할 수 없는 경우 확장 데이터 평면 엔드포인트가 공용 네트워크를 통해 이동하도록 CoreDNS 재정의를 만듭니다. CoreDNS 를 사용자 지정하는 방법에 대한 자세한 내용은 "Azure Kubernetes Service를 사용하여 CoreDNS 사용자 지정"의 "호스트 플러그 인" 섹션을 참조하세요.
CoreDNS 재정의를 만들려면 다음 단계를 수행합니다.
명령을 실행하여 확장 데이터 평면 엔드포인트의 공용 IP 주소를 찾습니다
nslookup. AKS 클러스터의 위치에 따라 지역(예eastus2euap: )을 변경해야 합니다.nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.net기존 coreDNS 구성의 백업을 만듭니다.
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yaml지역(예
eastus2euap: ) 데이터 평면 엔드포인트에 대한 매핑을 공용 IP 주소로 재정의합니다. 이렇게 하려면 corednsms.yaml이라는 YAML 파일을 만든 다음, 다음 예제 구성을 새 파일에 복사합니다. (사용자 환경에 대한 값을 사용하여 주소 및 호스트 이름을 업데이트해야 합니다.)apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }ConfigMap을 만들려면 YAML 매니페스트 파일의 이름을 지정하여 명령을 실행
kubectl apply합니다.kubectl apply -f corednsms.yamlConfigMap을 다시 로드하고 Kubernetes Scheduler가 가동 중지 시간 없이 CoreDNS를 다시 시작하도록 하려면 kubectl 롤아웃 다시 시작 명령을 실행합니다.
kubectl -n kube-system rollout restart deployment corednsnslookup명령을 다시 실행하여 데이터 평면 엔드포인트가 제공된 공용 IP 주소로 확인되도록 합니다.kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
확장 에이전트 Pod 로그는 더 이상 "Errorcode: 403, 이 트래픽에 권한이 없음 메시지" 오류 항목을 기록하지 않아야 합니다. 대신 로그에 "200" 응답 코드가 포함되어야 합니다.
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
오류: 클러스터의 모든 노드 풀이 "CriticalAddonsOnly"로 오염된 경우 확장 Pod를 예약할 수 없습니다.
이 오류가 발생하면 확장 에이전트 로그에 다음 항목이 기록됩니다.
확장 Pod 오류: 0/2 노드를 사용할 수 있습니다. 2개 노드에 설명되지 않은 taint {CriticalAddonsOnly: true}가 있습니다. 선점: 0/2 노드를 사용할 수 있습니다. 2 선점은 예약에 유용하지 않습니다.
원인
이 오류는 노드 풀이 오염된 AKS 클러스터 CriticalAddonsOnly 에서 확장(예: DAPR(분산 애플리케이션 런타임))을 사용하도록 설정하려고 할 때 발생합니다. 이 경우 확장 Pod는 이러한 taint에 대한 내화가 없기 때문에 노드에서 예약되지 않습니다.
오류 상황을 보려면 확장 Pod를 검사하여 보류 중인 상태에 있는지 확인합니다.
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Pod를 설명하여 지원되지 않는 taint로 인해 예약할 수 없음을 확인합니다.
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
참고 항목
애플리케이션 워크로드에 필요한 경우가 아니면 오염된 노드 풀에
CriticalAddOnsOnly확장을 설치하지 않는 것이 좋습니다.단일 노드 풀 클러스터에서 taint를
CriticalAddOnsOnly사용하지 않는 것이 좋습니다. 노드 풀이 하나뿐인 클러스터에서 해당 taint를 사용하는 경우 클러스터에서 애플리케이션 Pod를 예약할 수 없습니다. 클러스터에서 하나 이상의 노드 풀에 이 taint가 없는지 확인합니다. 주석을CriticalAddonsOnly사용해야 하는 시기에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 시스템 노드 풀 관리를 참조하세요.
솔루션 1: 클러스터에 노드 풀 추가
이 문제를 해결하려면 taint가 없는 노드 풀을 CriticalAddonsOnly 하나 더 추가합니다. 이 작업을 수행하면 확장 Pod가 새 노드 풀에서 예약됩니다.
해결 방법 2: "CriticalAddonsOnly" taint 제거
가능하고 실용적인 경우 클러스터에 CriticalAddonsOnly 확장을 설치하기 위해 taint를 제거할 수 있습니다.
Helm 오류
다음 Helm 관련 오류가 발생할 수 있습니다.
- 리소스 준비를 위한 대기 시간 초과
- 리포지토리 URL에서 Helm 차트를 다운로드할 수 없음
- 지정된 값을 사용한 Helm 차트 렌더링에 실패
- 사용자 클러스터에 리소스가 이미 있음
- Helm에 대한 작업이 이미 진행 중입니다.
오류: 리소스 준비 대기 시간이 초과됨
Kubernetes 애플리케이션 설치가 실패하고 다음 오류 메시지가 표시됩니다.
작업 실패: BackoffLimitExceeded
리소스가 준비/완료된 상태로 전환될 때까지 기다리는 시간이 초과되었습니다.
원인
이 문제에는 다음과 같은 일반적인 원인이 있습니다.
리소스 제약 조건: 클러스터 내의 메모리 또는 CPU 리소스가 부족하면 Pod, 작업 또는 기타 Kubernetes 리소스를 성공적으로 초기화하지 못할 수 있습니다. 결국 이 상황으로 인해 설치 시간이 초과됩니다. 정책 제약 조건 또는 노드 taint(예:
NoSchedule)는 리소스 초기화를 차단할 수도 있습니다.아키텍처 불일치: Windows 기반 노드에서 Linux 기반 애플리케이션을 예약하려고 하면(또는 그 반대의 경우도 마찬가지) Kubernetes 리소스 초기화에 오류가 발생할 수 있습니다.
잘못된 구성 설정: 잘못된 구성 설정으로 인해 Pod가 시작되지 않습니다.
솔루션
이 문제를 해결하려면 다음 단계를 수행합니다.
리소스 확인: Kubernetes 클러스터에 충분한 리소스가 있고 노드에서 Pod 예약이 허용되는지 확인합니다(taint를 고려해야 합니다). 메모리 및 CPU 리소스가 요구 사항을 충족하는지 확인합니다.
이벤트 검사: Kubernetes 네임스페이스 내의 이벤트를 확인하여 Pod, 작업 또는 기타 Kubernetes 리소스가 준비 상태에 도달하지 못할 수 있는 잠재적인 문제를 식별합니다.
Helm 차트 및 구성 확인: 많은 Kubernetes 애플리케이션은 Helm 차트를 사용하여 클러스터에 리소스를 배포합니다. 일부 애플리케이션은 구성 설정을 통해 사용자 입력이 필요할 수 있습니다. 제공된 모든 구성 값이 정확하고 설치 요구 사항을 충족하는지 확인합니다.
오류: 리포지토리 URL에서 Helm 차트를 다운로드할 수 없음
이 오류는 송신 차단 문제 외에도 클러스터와 방화벽 간에 발생하는 연결 문제로 인해 발생합니다. 이 문제를 해결하려면 AKS(Azure Kubernetes Service) 클러스터에 대한 아웃바운드 네트워크 및 FQDN 규칙을 참조 하세요.
오류: 지정된 값으로 Helm 차트 렌더링 실패
이 오류는 Kubernetes 애플리케이션이 Helm 차트를 사용하여 Kubernetes 클러스터 내에 리소스를 배포하는 경우에 발생합니다. 이러한 애플리케이션에는 설치 중에 Helm 값으로 전달되는 구성 설정을 통해 제공되는 사용자 입력이 필요할 수 있습니다. 이러한 중요한 구성 설정이 없거나 올바르지 않으면 Helm 차트가 렌더링되지 않을 수 있습니다.
이 문제를 해결하려면 확장 또는 애플리케이션 설명서를 확인하여 애플리케이션 설치 중에 필수 값을 생략했는지 또는 잘못된 값을 제공했는지 확인합니다. 이러한 지침은 누락되거나 부정확한 구성 값으로 인해 발생하는 Helm 차트 렌더링 문제를 해결하는 데 도움이 될 수 있습니다.
오류: 클러스터에 리소스가 이미 있습니다.
이 오류는 클러스터 내의 Kubernetes 리소스와 애플리케이션이 설치하려는 Kubernetes 리소스 간에 충돌이 발생하는 경우에 발생합니다. 오류 메시지는 일반적으로 충돌하는 리소스의 이름을 지정합니다.
충돌하는 리소스가 필수이고 바꿀 수 없는 경우 애플리케이션을 설치하지 못할 수 있습니다. 리소스가 중요하지 않고 제거할 수 있는 경우 충돌하는 리소스를 삭제한 다음 설치를 다시 시도합니다.
오류: Helm에 대한 작업이 이미 진행 중입니다.
이 오류는 특정 릴리스에 대해 이미 진행 중인 작업이 있는 경우에 발생합니다. 이 문제를 해결하려면 10분 동안 기다린 다음 작업을 다시 시도합니다.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.