정상 노드에서 준비되지 않음 상태로 변경 문제 해결

아티클
10/15/2024

이 문서에서는 노드가 일정 시간 동안 정상 상태인 후 AKS(Azure Kubernetes Service) 클러스터 노드의 상태가 준비되지 않음으로 변경되는 시나리오에 대해 설명합니다. 이 문서에서는 특정 원인을 간략하게 설명하고 가능한 솔루션을 제공합니다.

필수 조건

Kubernetes kubectl 도구입니다. Azure CLI를 사용하여 kubectl을 설치하려면 az aks install-cli 명령을 실행합니다.
Kubernetes kubelet 도구입니다.
Kubernetes 컨테이너 도구입니다 .
다음 Linux 도구:
- awk
- head
- journalctl
- ps
- sort
- watch

증상

정상 상태(실행 중인 모든 서비스)가 있는 클러스터 노드의 상태가 예기치 않게 준비되지 않음으로 변경됩니다. 노드의 상태를 보려면 다음 kubectl describe 명령을 실행합니다.

kubectl describe nodes

원인

kubelet이 준비 상태 게시를 중지했습니다.

명령의 출력을 kubectl describe nodes 검사하여 조건 필드와 용량 및 할당 가능한 블록을 찾습니다. 이러한 필드의 내용이 예상대로 표시될까요? (예: 조건 필드, 속성에 message "kubelet 준비 상태 게시 중" 문자열이 포함되어 있나요?) 이 경우 노드에 대한 직접 SSH(Secure Shell) 액세스 권한이 있는 경우 최근 이벤트를 확인하여 오류를 이해합니다. /var/log/messages 파일 내에서 확인합니다. 또는 다음 셸 명령을 실행하여 kubelet 및 컨테이너 디먼 로그 파일을 생성합니다.

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

이러한 명령을 실행한 후 메시지 및 디먼 로그 파일을 검사하여 오류에 대한 자세한 내용을 확인합니다.

솔루션

1단계: 네트워크 수준의 변경 내용 확인

모든 클러스터 노드가 준비되지 않음 상태로 회귀된 경우 네트워크 수준에서 변경이 발생했는지 확인합니다. 네트워크 수준 변경의 예는 다음과 같습니다.

DNS(Domain Name System) 변경 내용
포트, FQDN(정규화된 도메인 이름) 등과 같은 방화벽 규칙 변경
추가된 NSG(네트워크 보안 그룹)
AKS 트래픽에 대해 적용되거나 변경된 경로 테이블 구성

네트워크 수준에서 변경된 경우 필요한 사항을 수정합니다. 노드에 대한 직접 SSH(Secure Shell) 액세스 권한이 있는 경우 또는 명령을 사용하여 curl AKS 아웃바운드 요구 사항에 대한 연결을 확인할 수 있습니다.telnet 문제를 해결한 후 노드를 중지하고 다시 시작합니다. 이러한 수정 후 노드가 정상 상태로 유지되면 나머지 단계를 안전하게 건너뛸 수 있습니다.

2단계: 노드 중지 및 다시 시작

일부 노드만 준비되지 않음 상태로 회귀된 경우 노드를 중지하고 다시 시작하면 됩니다. 이 작업만으로도 노드를 정상 상태로 되돌릴 수 있습니다. 그런 다음, Azure Kubernetes Service 진단 개요를 확인하여 다음과 같은 문제가 있는지 확인합니다.

노드 오류
SNAT(Source Network Address Translation) 실패
노드 IOPS(초당 노드 입력/출력 작업) 성능 문제
기타 문제

진단에서 기본 문제를 검색하지 못하고 노드가 준비 상태로 반환되는 경우 나머지 단계를 안전하게 건너뛸 수 있습니다.

3단계: 공용 AKS API 클러스터에 대한 SNAT 문제 해결

AKS 진단에서 SNAT 문제를 발견했나요? 그렇다면 다음 작업 중 일부를 적절하게 수행합니다.

연결이 오랫동안 유휴 상태로 유지되고 기본 유휴 시간 제한에 의존하여 포트를 해제하는지 확인합니다. 연결에 이 동작이 표시되는 경우 기본 제한 시간을 30분으로 줄여야 할 수 있습니다.
애플리케이션이 아웃바운드 연결을 만드는 방법을 결정합니다. 예를 들어 코드 검토 또는 패킷 캡처를 사용하나요?
이 작업이 예상된 동작을 나타내는지 여부를 확인합니다. 대신 애플리케이션이 잘못 실행되고 있음을 보여 줍니다. Azure Monitor에서 메트릭 및 로그를 사용하여 검색 결과를 구체화합니다. 예를 들어 실패한 범주를 SNAT 연결 메트릭으로 사용할 수 있습니다.
적절한 패턴을 따르는지 여부를 평가합니다.
추가 아웃바운드 IP 주소와 더 많은 할당된 아웃바운드 포트를 사용하여 SNAT 포트 고갈을 완화해야 하는지 평가합니다. 자세한 내용은 관리되는 아웃바운드 공용 IP 의 수 크기 조정 및 할당된 아웃바운드 포트 구성을 참조하세요.

SNAT 포트 해제 문제를 해결하는 방법에 대한 자세한 내용은 AKS 노드에서 SNAT 포트 고갈 문제를 참조하세요.

4단계: IOPS 성능 문제 해결

AKS 진단에서 IOPS 성능을 저하시키는 문제를 발견하면 다음 작업 중 일부를 적절하게 수행합니다.

VM(가상 머신) 확장 집합에서 IOPS를 늘리려면 새 노드 풀을 배포하여 더 나은 IOPS 성능을 제공하는 더 큰 디스크 크기를 선택합니다. 직접 크기 조정 VMSS는 지원되지 않습니다. 노드 풀 크기 조정에 대한 자세한 내용은 AKS(Azure Kubernetes Service)의 노드 풀 크기 조정을 참조하세요.
더 많은 메모리 및 CPU 처리 기능을 위해 노드 SKU 크기를 늘립니다.
임시 OS를 사용하는 것이 좋습니다.
Pod의 CPU 및 메모리 사용량을 제한합니다. 이러한 제한은 노드 CPU 소비 및 메모리 부족 상황을 방지하는 데 도움이 됩니다.
스케줄링 토폴로지 메서드를 사용하여 더 많은 노드를 추가하고 노드 간에 로드를 분산시킵니다. 자세한 내용은 Pod 토폴로지 스프레드 제약 조건을 참조 하세요.

5단계: 스레딩 문제 해결

kubelets 및 컨테이너된 런타임과 같은 Kubernetes 구성 요소는 스레딩에 크게 의존하며 정기적으로 새 스레드를 생성합니다. 새 스레드 할당에 실패하면 다음과 같이 서비스 준비 상태에 영향을 미칠 수 있습니다.

노드 상태가 준비되지 않음으로 변경되지만 수정자가 다시 시작하여 복구할 수 있습니다.
/var/log/messages 및 /var/log/syslog 로그 파일에는 다음과 같은 오류 항목이 반복적으로 발생합니다.

pthread_create 실패: 다양한 프로세스에서 리소스를 일시적으로 사용할 수 없습니다.

인용된 프로세스에는 containerd와 kubelet이 포함됩니다.
실패 항목이 로그 파일에 기록된 직후 pthread_create 노드 상태가 준비되지 않음으로 변경됩니다.

프로세스 ID(PID)는 스레드를 나타냅니다. Pod에서 사용할 수 있는 기본 PID 수는 운영 체제에 따라 다를 수 있습니다. 그러나 기본 수는 32,768 이상입니다. 이는 대부분의 상황에서 PID를 충분히 초과하는 양입니다. 더 높은 PID 리소스에 대한 알려진 애플리케이션 요구 사항이 있나요? 그렇지 않은 경우 PID를 262,144개로 8배 늘려도 리소스가 많은 애플리케이션을 수용하기에 충분하지 않을 수 있습니다.

대신 문제가 되는 애플리케이션을 식별한 다음, 적절한 조치를 취합니다. VM 크기 늘리기 또는 AKS 업그레이드와 같은 다른 옵션을 고려합니다. 이러한 조치를 통해 문제를 일시적으로 완화할 수 있지만 문제가 다시 발생하지 않는다는 보장은 없습니다.

각 컨트롤 그룹(cgroup)에 대한 스레드 수를 모니터링하고 상위 8개 cgroup을 인쇄하려면 다음 셸 명령을 실행합니다.

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

자세한 내용은 프로세스 ID 제한 및 예약을 참조 하세요.

Kubernetes는 노드 수준에서 PID 고갈을 관리하는 두 가지 방법을 제공합니다.

매개 변수를 사용하여 --pod-max-pids kubelet 내의 Pod에서 허용되는 최대 PID 수를 구성합니다. 이 구성은 pids.max 각 Pod의 cgroup 내에서 설정을 설정합니다. 또한 해당 및 --kube-reserved 매개 변수를 --system-reserved 사용하여 시스템 및 kubelet 제한을 각각 구성할 수 있습니다.
PID 기반 제거를 구성합니다.

참고 항목

기본적으로 이 두 가지 방법 모두 설정되지 않습니다. 또한 현재 AKS 노드 풀에 노드 구성을 사용하여 두 방법 중 하나를 구성할 수 없습니다.

6단계: 더 높은 서비스 계층 사용

더 높은 서비스 계층을 사용하여 AKS API 서버에 고가용성이 있는지 확인할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service) 작동 시간 SLA를 참조하세요.

자세한 정보

AKS API 서버 및 kubelets의 상태 및 성능을 보려면 관리되는 AKS 구성 요소를 참조 하세요.
일반적인 문제 해결 단계는 준비되지 않은 노드 오류의 기본 문제 해결을 참조 하세요.

다음을 통해 공유