다음을 통해 공유

정상 노드의 준비되지 않은 상태 문제 해결

  • 아티클

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

필수 구성 요소

증상

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

kubectl describe nodes

원인

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

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

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

이러한 명령을 실행한 후 디먼 로그 파일을 검사하여 오류에 대한 세부 정보를 확인합니다.

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

모든 클러스터 노드가 준비되지 않음 상태 회귀된 경우 네트워크 수준에서 변경이 발생했는지 여부를 검사. 네트워크 수준 변경의 예로는 다음 항목이 포함됩니다.

  • DNS(도메인 이름 시스템) 변경 내용
  • 방화벽 포트 변경
  • NSG(네트워크 보안 그룹) 추가됨

네트워크 수준에서 변경이 있는 경우 필요한 사항을 수정합니다. 문제를 해결한 후 실행 중인 노드를 중지하고 다시 시작합니다. 이러한 수정 후 노드가 정상 상태로 유지되는 경우 나머지 단계를 안전하게 건너뛸 수 있습니다.

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

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

  • 노드 오류
  • SNAT(원본 네트워크 주소 변환) 오류
  • 노드 IOPS(초당 노드 입력/출력 작업) 성능 문제
  • 기타 문제

진단 기본 문제를 검색하지 않으면 나머지 단계를 안전하게 건너뛸 수 있습니다.

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

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

  • 연결이 오랫동안 유휴 상태로 유지되는지 확인하고 기본 유휴 시간 제한에 의존하여 포트를 해제합니다. 연결에 이 동작이 표시되는 경우 기본 제한 시간을 30분으로 줄여야 할 수 있습니다.

  • 애플리케이션이 아웃바운드 연결을 만드는 방법을 결정합니다. 예를 들어 코드 검토 또는 패킷 캡처를 사용하나요?

  • 이 활동이 예상 동작을 나타내는지 여부를 확인합니다. 대신 애플리케이션이 잘못 동작하고 있음을 보여 줍니다. Azure Monitor의 메트릭 및 로그를 사용하여 결과를 입증합니다. 예를 들어 실패한 범주를 SNAT Connections 메트릭으로 사용할 수 있습니다.

  • 적절한 패턴을 따르는지 여부를 평가합니다.

  • 추가 아웃바운드 IP 주소 및 더 많은 할당된 아웃바운드 포트를 사용하여 SNAT 포트 소모를 완화해야 하는지 여부를 평가합니다. 자세한 내용은 관리형 아웃바운드 공용 IP 수 크기 조정 및 할당된 아웃바운드 포트 구성을 참조하세요.

4단계: IOPS 성능 문제 해결

AKS에서 IOPS 성능을 줄이는 문제를 발견할 진단 있는 경우 다음 작업 중 일부를 적절하게 수행합니다.

  • VM(가상 머신) 확장 집합에서 IOPS를 늘리려면 새 노드 풀을 배포하여 디스크 크기를 변경합니다.

  • 더 많은 메모리 및 CPU 처리 기능을 위해 노드 SKU 크기를 늘입니다.

  • 임시 OS를 사용하는 것이 좋습니다.

  • Pod의 CPU 및 메모리 사용량을 제한합니다. 이러한 제한은 노드 CPU 사용량 및 메모리 부족 상황을 방지하는 데 도움이 됩니다.

  • 일정 토폴로지 메서드를 사용하여 더 많은 노드를 추가하고 노드 간에 부하를 분산합니다. 자세한 내용은 Pod 토폴로지 분산 제약 조건을 참조하세요.

5단계: 스레딩 문제 해결

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

  • 노드가 준비되지 않음으로 변경될 상태 있지만 수정자가 다시 시작하고 복구할 수 있습니다.

  • /var/log/messages 및 /var/log/syslog 로그 파일에는 다음과 같은 오류 항목이 반복적으로 발생합니다.

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

    인용되는 프로세스에는 컨테이너 및 kubelet이 포함됩니다.

  • 노드 상태 오류 항목이 로그 파일에 기록된 직후 pthread_create 에 준비되지 않음으로 변경됩니다.

프로세스 ID(PID)는 스레드를 나타냅니다. Pod에서 사용할 수 있는 기본 PID 수는 운영 체제에 따라 달라질 수 있습니다. 그러나 기본 번호는 32,768 이상입니다. 이 크기는 대부분의 상황에서 충분한 PID보다 큽니다. 더 높은 PID 리소스에 대한 알려진 애플리케이션 요구 사항이 있나요? 그렇지 않은 경우 262,144개의 PID로 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 소모를 관리하는 두 가지 방법을 제공합니다.

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

  2. PID 기반 제거를 구성합니다.

참고

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

6단계: 상위 서비스 계층 사용

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

추가 정보