이 페이지에서는 클러스터 자동 확장 처리가 Google Kubernetes Engine(GKE) 노드를 축소하지 못하게 하는 문제를 진단하고 해결하는 방법을 설명합니다.
이 페이지는 앱 또는 서비스의 예상치 못한 부정적인 상황을 해결하려는 애플리케이션 개발자와 제품 및 서비스 제공 중단을 방지하려는 플랫폼 관리자 및 운영자를 위해 작성되었습니다.
클러스터 자동 확장 처리가 노드를 축소하는 경우 이해
문제 해결 단계를 진행하기 전에 클러스터 자동 확장 처리가 노드를 축소하려고 시도하는 시점을 이해하는 것이 좋습니다. 클러스터 자동 확장 처리가 축소할 필요가 없어 축소하지 않았을 수 있습니다.
클러스터 자동 확장 처리는 사용률 계수를 계산하여 노드가 활용도가 낮고 축소할 수 있는지 확인합니다. 사용률 계수는 노드의 포드에서 요청한 vCPU와 메모리를 노드의 할당 가능한 vCPU와 메모리로 나눈 값으로 계산됩니다.
클러스터 자동 확장 처리는 10초마다 노드의 사용률 계수를 확인하여 필요한 기준점 미만인지 확인합니다. balanced
자동 확장 프로필을 사용하는 경우 사용률 요소 기준점은 0.5입니다. optimize-utilization 프로필을 사용하는 경우 사용률 요소는 다릅니다. 사용률 계수가 vCPU와 메모리 모두에 필요한 기준점보다 낮으면 클러스터 자동 확장 처리는 노드가 사용률이 낮은 것으로 간주합니다.
노드가 사용률이 낮으면 클러스터 자동 확장 처리는 노드를 삭제 대상으로 표시하고 다음 10분 동안 노드를 모니터링하여 사용률 요소가 필요한 기준점 아래에 유지되는지 확인합니다. 10분 후에도 노드의 사용률이 여전히 낮은 경우 클러스터 자동 확장 처리가 노드를 삭제해야 합니다.
예: 사용률 계산
클러스터 자동 확장 처리가 사용 설정된 클러스터가 있고 balanced 자동 확장 프로필을 사용하고 있습니다. 이 클러스터의 노드는 vCPU 4개와 메모리 16GB를 제공하는 e2-standard-4 머신 유형으로 프로비저닝됩니다. 이 노드의 포드는 0.5vCPU 및 10GB의 메모리를 요청하므로 클러스터 자동 확장 처리는 다음과 같은 사용률 요소를 계산합니다.
- vCPU 사용률 계수: 0.5vCPU / 4vCPU = 0.125
- 메모리 사용률 계수: 10GB / 16GB = 0.625
이 시나리오에서 클러스터 자동 확장 처리는 메모리 사용률 계수(0.625)가 0.5의 기준점을 초과하므로 이 노드를 사용률이 낮은 것으로 간주하지 않습니다. vCPU 사용률은 낮지만 메모리 사용량이 더 높아서 포드의 워크로드에 충분한 리소스를 계속 사용할 수 있도록 조정되지 않습니다.
제한사항으로 인한 문제인지 확인
10분 넘게 사용률이 낮은 클러스터가 관찰되지만 클러스터가 축소되지 않는 경우 클러스터 자동 확장 처리의 제한사항 중 하나로 인해 발생한 문제인지 확인합니다.
오류 보기
제한으로 인한 문제가 아닌 경우 오류 메시지를 확인하여 원인을 진단할 수 있습니다.
이미 오류 메시지가 표시된 경우 오류 메시지 표에서 오류 해결에 관한 도움말을 확인하세요.
아직 메시지가 표시되지 않으면 다음 옵션 중 하나를 사용하세요.
- 발생한 지 72시간이 지나지 않은 문제: Google Cloud 콘솔에서 오류 알림 보기
- 72시간이 지난 문제: Cloud Logging의 이벤트에서 오류 보기
알림에서 오류 보기
발견한 문제가 72시간 이내에 발생한 경우 Google Cloud 콘솔에서 오류에 관한 알림을 확인하세요. 이러한 알림은 클러스터 자동 확장 처리가 축소되지 않은 이유에 관한 유용한 정보를 제공하고 오류를 해결하고 추가 조사를 위해 관련 로그를 보는 방법에 관한 조언을 제공합니다.
Google Cloud 콘솔에서 알림을 보려면 다음 단계를 완료하세요.
Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.
알림 열을 검토합니다. 다음 알림은 축소 문제와 관련이 있습니다.
Can't scale down nodesScale down blocked by pod
관련 알림을 클릭하면 문제의 원인과 해결을 위한 권장 조치에 관한 세부정보가 포함된 창이 표시됩니다.
(선택사항) 이 이벤트의 로그를 보려면 로그를 클릭합니다. 이 작업을 수행하면 확장 이벤트를 추가로 조사하는 데 도움이 되는 미리 채워진 쿼리가 포함된 로그 탐색기로 이동합니다. 축소 이벤트의 작동 방식에 관한 자세한 내용은 클러스터 자동 확장 처리 이벤트 보기를 참고하세요.
알림의 조치를 검토한 후에도 문제가 계속 발생하면 오류 메시지 표에서 추가 도움말을 확인하세요.
이벤트에서 오류 보기
관찰된 문제가 72시간 이상 전에 발생한 경우 Cloud Logging에서 이벤트를 확인하세요. 오류가 발생하면 이벤트에 기록되는 경우가 많습니다.
Google Cloud 콘솔에서 클러스터 자동 확장 처리 로그를 보려면 다음 단계를 완료하세요.
Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.
조사하려는 클러스터의 이름을 선택하여 클러스터 세부정보 페이지를 엽니다.
클러스터 세부정보 페이지에서 로그 탭을 클릭합니다.
로그 탭에서 자동 확장 처리 로그 탭을 클릭하여 로그를 봅니다.
(선택사항) 고급 필터를 적용하여 결과의 범위를 좁히려면 페이지 오른쪽의 화살표가 있는 버튼을 클릭하여 로그 탐색기에서 로그를 봅니다.
축소 이벤트 작동 방식에 대한 자세한 내용은 클러스터 자동 확장 처리 이벤트 보기를 참고하세요. Cloud Logging을 사용하는 방법의 한 가지 예는 다음 문제 해결 예를 참고하세요.
예: 72시간이 지난 문제 해결
다음 예는 클러스터가 축소되지 않는 문제를 조사하고 해결하는 방법을 보여줍니다.
시나리오:
일주일 전 GKE Enterprise 대시보드를 확인한 결과 클러스터가 CPU와 메모리의 10%만 사용하고 있는 것을 확인했습니다. 사용률이 낮음에도 클러스터 자동 확장 처리는 이 노드를 예상대로 삭제하지 않았습니다. 이제 대시보드를 보면 문제가 해결된 것 같지만, 다시 발생하지 않도록 하기 위해 무슨 일이 있었는지 알아보기로 합니다.
조사:
- 문제가 발생한 지 72시간이 지났으므로 알림 메시지를 확인하는 대신 Cloud Logging을 사용하여 문제를 조사합니다.
- Cloud Logging에서 이벤트에서 오류 보기에 설명된 대로 클러스터 자동 확장 처리 이벤트의 로깅 세부정보를 확인할 수 있습니다.
nodesToBeRemoved필드에서 조사 중인 클러스터에 속한 노드가 포함된scaleDown이벤트를 검색합니다. 특정 JSON 필드 값으로 필터링을 비롯한 로그 항목 필터링이 가능합니다. 고급 로그 쿼리에서 자세히 알아보세요.scaleDown이벤트가 없습니다. 하지만scaleDown이벤트를 찾은 경우 연결된eventId가 포함된eventResult이벤트를 검색할 수 있습니다. 그런 다음errorMsg필드에서 오류를 검색할 수 있습니다.노드 필드에서 조사 중인 노드가 있는
noScaleDown이벤트를 검색하여 조사를 계속하기로 합니다.노드가 축소되지 않은 이유가 포함된
noScaleDown이벤트를 찾습니다. 메시지 ID는"no.scale.down.node.pod.not.backed.by.controller"이며 단일 매개변수"test-single-pod"가 있습니다.
해결 방법:
오류 메시지 표를 참고한 결과 이 메시지는 컨트롤러가 지원하지 않으므로 포드에서 축소를 차단하고 있음을 의미합니다. 포드에 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 주석을 추가하는 것이 해결책이라는 것을 알게 되었습니다. test-single-pod를 조사한 결과 동료가 주석을 추가했으며 주석을 적용한 후 클러스터 자동 확장 처리가 클러스터를 올바르게 축소한 것으로 확인됩니다. 문제가 다시 발생하지 않도록 안전하게 주석을 추가할 수 있는 다른 모든 포드에 주석을 추가하기로 합니다.
축소 오류 해결
오류를 파악한 후 다음 표를 사용하여 오류의 원인과 해결 방법을 알아보세요.
scaleDown 오류
scaleDown 이벤트의 오류 이벤트 메시지는 해당 eventResult 이벤트의 resultInfo.results[].errorMsg 필드에 있습니다.
| 이벤트 메시지 | 세부정보 | 매개변수 | 위험 완화 |
|---|---|---|---|
"scale.down.error.failed.to.mark.to.be.deleted" |
노드를 삭제하도록 표시할 수 없습니다. | 실패한 노드 이름 | 이 메시지는 일시적입니다. 문제가 계속되면 추가 조사를 위해 Cloud Customer Care에 문의하세요. |
"scale.down.error.failed.to.evict.pods" |
일부 포드를 노드에서 제거할 수 없어 클러스터 자동 확장 처리가 축소할 수 없습니다. | 실패한 노드 이름 | 포드의 PodDisruptionBudget을 검토하고 허용되는 경우 규칙에서 애플리케이션 복제본 제거를 허용하는지 확인합니다. 자세한 내용은 Kubernetes 문서의 애플리케이션에 중단 예산 지정을 참고하세요. |
"scale.down.error.failed.to.delete.node.min.size.reached" |
클러스터가 이미 최소 크기여서 노드를 삭제할 수 없기 때문에 클러스터 자동 확장 처리가 축소할 수 없습니다. | 실패한 노드 이름 | 노드 풀 자동 확장에 설정된 최솟값을 검토하고 필요한 경우 설정을 조정합니다. 자세한 내용은 오류: 클러스터의 노드가 최소 크기에 도달함을 참고하세요. |
noScaleDown 이벤트의 이유
noScaleDown 이벤트는 클러스터 자동 확장 처리에 의한 삭제가 차단된 노드가 있을 때 주기적으로 발생합니다. noScaleDown 이벤트는 최선의 방법이며 가능한 모든 사례를 포괄하지는 않습니다.
NoScaleDown 최상위 수준 이유
noScaleDown 이벤트의 최상위 수준 이유 메시지는 noDecisionStatus.noScaleDown.reason 필드에 표시됩니다. 메시지에는 클러스터 자동 확장 처리가 클러스터를 축소할 수 없는 최상위 수준 이유가 포함되어 있습니다.
| 이벤트 메시지 | 세부정보 | 위험 완화 |
|---|---|---|
"no.scale.down.in.backoff" |
축소가 백오프 기간에 있으므로(일시적으로 차단됨) 클러스터 자동 확장 처리가 축소할 수 없습니다. | 이 메시지는 일시적이어야 하며 최근 확장 이벤트가 있는 경우 발생할 수 있습니다. 메시지가 계속 표시되면 추가 조사를 위해 Cloud Customer Care에 문의하세요. |
"no.scale.down.in.progress" |
이전 축소가 아직 진행 중이기 때문에 클러스터 자동 확장 처리가 축소할 수 없습니다. |
포드가 결국 삭제되므로 이 메시지는 일시적이어야 합니다. 이 메시지가 자주 발생하면 축소를 차단하는 포드의 종료 유예 기간을 검토하세요. 해결 속도를 높이려면 포드가 더 이상 필요하지 않은 경우 삭제할 수도 있습니다. |
noScaleDown 노드 수준 이유
noScaleDown 이벤트의 노드 수준 이유 메시지는 noDecisionStatus.noScaleDown.nodes[].reason field에 표시됩니다. 메시지에는 클러스터 자동 확장 처리가 특정 노드를 삭제할 수 없는 이유가 포함되어 있습니다.
| 이벤트 메시지 | 세부정보 | 매개변수 | 위험 완화 |
|---|---|---|---|
"no.scale.down.node.scale.down.disabled.annotation" |
노드에 cluster-autoscaler.kubernetes.io/scale-down-disabled: true 주석이 추가되어 있으므로 클러스터 자동 확장 처리가 노드 풀에서 노드를 삭제할 수 없습니다.
|
해당 사항 없음 | 클러스터 자동 확장 처리는 사용률을 고려하지 않고 이 주석이 있는 노드를 건너뛰며 이 메시지는 노드의 사용률 요소와 관계없이 로깅됩니다. 클러스터 자동 확장 처리에서 이러한 노드를 축소하려면 주석을 삭제합니다. |
"no.scale.down.node.node.group.min.size.reached" |
노드 그룹 크기가 최소 크기 제한을 초과하면 클러스터 자동 확장 처리가 축소할 수 없습니다. 노드를 삭제하면 노드 자동 프로비저닝 설정에 정의된 클러스터 전체 최소 리소스 한도가 위반되기 때문에 이 문제가 발생합니다. |
해당 사항 없음 | 노드 풀 자동 확장에 설정된 최솟값을 검토합니다. 클러스터 자동 확장 처리에서 이 노드를 축소하려면 최솟값을 조정합니다. |
"no.scale.down.node.minimal.resource.limits.exceeded" |
클러스터 자동 확장 처리는 클러스터 차원의 최소 리소스 한도를 위반하므로 노드를 축소할 수 없습니다. 노드 자동 프로비저닝에 설정된 리소스 한도입니다. |
해당 사항 없음 | 메모리 및 vCPU 한도를 검토하고 클러스터 자동 확장 처리가 이 노드를 축소하도록 하려면 한도를 늘립니다. |
"no.scale.down.node.no.place.to.move.pods" |
포드를 이동할 위치가 없으므로 클러스터 자동 확장 처리가 축소할 수 없습니다. | 해당 사항 없음 | 포드 일정을 변경해야 할 것으로 예상되는 경우, 사용률이 낮은 노드에서 포드의 예약 요구사항을 검토하여 클러스터의 다른 노드로 이동할 수 있는지 확인합니다. 자세한 내용은 오류: 포드를 이동할 공간 없음을 참고하세요. |
"no.scale.down.node.pod.not.backed.by.controller" |
컨트롤러가 지원하지 않기 때문에 포드에서 축소를 차단하고 있습니다. 특히 인식된 컨트롤러가 없는 포드로 인해 클러스터 자동 확장 처리가 사용률이 낮은 노드를 축소할 수 없습니다. 허용되는 컨트롤러에는 ReplicationController, DaemonSet, Job, StatefulSet 또는 ReplicaSet가 있습니다. |
차단 포드의 이름입니다. | 포드에 주석 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"를 설정하거나 허용되는 컨트롤러를 정의합니다. |
"no.scale.down.node.pod.has.local.storage" |
로컬 스토리지가 있기 때문에 포드에서 축소를 차단하고 있습니다. | 차단 포드의 이름입니다. | 포드의 로컬 스토리지에 있는 데이터가 중요하지 않은 경우 포드에 대해 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 주석을 설정합니다.
이 오류는 1.22 이전 버전을 사용하는 클러스터에서만 발생합니다. |
"no.scale.down.node.pod.not.safe.to.evict.annotation" |
노드의 포드에 safe-to-evict=false 주석이 있습니다. |
차단 포드의 이름입니다. | 포드를 안전하게 제거할 수 있는 경우 포드의 매니페스트를 수정하고 주석을 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"로 업데이트합니다. |
"no.scale.down.node.pod.kube.system.unmovable" |
DaemonSet이 아니고 미러링되지 않으며 kube-system 네임스페이스에 PodDisruptionBudge가 없는 포드이기 때문에 포드에서 축소를 차단하고 있습니다. |
차단 포드의 이름입니다. | 기본적으로 이 문제를 해결하려면 |
"no.scale.down.node.pod.not.enough.pdb" |
PodDisruptionBudget이 충분하지 않기 때문에 포드에서 축소를 차단하고 있습니다. | 차단 포드의 이름입니다. | 포드의 PodDisruptionBudget을 검토하고 제한을 완화해 보세요. 자세한 내용은 오류: PodDisruptionBudget이 충분하지 않음을 참고하세요. |
"no.scale.down.node.pod.controller.not.found" |
컨트롤러(예: 배포 또는 ReplicaSet)를 찾을 수 없기 때문에 포드에서 축소를 차단하고 있습니다. | 해당 사항 없음 | 컨트롤러가 삭제된 후에도 포드가 실행되도록 한 작업을 확인하려면 로그를 검토합니다. 이 문제를 해결하려면 포드를 수동으로 삭제합니다. |
"no.scale.down.node.pod.unexpected.error" |
예상치 못한 오류로 인해 포드에서 축소를 차단하고 있습니다. | 해당 사항 없음 | 이 오류의 근본 원인은 알 수 없습니다. 추가 조사를 위해 Cloud Customer Care에 문의하세요. |
추가 조사 실시
다음 섹션에서는 로그 탐색기와 gcpdiag를 사용하여 오류에 대한 추가 통계를 얻는 방법을 안내합니다.
로그 탐색기에서 오류 조사
오류 메시지를 자세히 조사하려면 오류와 관련된 로그를 확인하세요.
Google Cloud 콘솔에서 로그 탐색기 페이지로 이동합니다.
쿼리 창에서 다음 쿼리를 입력합니다.
resource.type="k8s_cluster" log_id("container.googleapis.com/cluster-autoscaler-visibility") jsonPayload.resultInfo.results.errorMsg.messageId="ERROR_MESSAGE"ERROR_MESSAGE를 조사하려는 메시지로 바꿉니다. 예를 들면scale.down.error.failed.to.delete.node.min.size.reached입니다.쿼리 실행을 클릭합니다.
gcpdiag로 일부 오류 디버그
gcpdiag는 Google Cloud 기술 엔지니어의 지원을 받아 만든 오픈소스 도구입니다. 공식적으로 지원되는 Google Cloud 제품이 아닙니다.
다음 오류 메시지 중 하나가 표시되면 gcpdiag를 사용하여 문제를 해결할 수 있습니다.
scale.down.error.failed.to.evict.podsno.scale.down.node.node.group.min.size.reached
모든 gcpdiag 도구 플래그의 목록과 설명은 gcpdiag 사용 안내를 참조하세요.
복잡한 축소 오류 해결
다음 섹션에서는 완화에 여러 단계가 포함된 오류와 클러스터 자동 확장 처리 이벤트 메시지가 연결되지 않은 오류를 해결하는 방법을 안내합니다.
오류: 클러스터의 노드가 최소 크기에 도달함
다음 오류가 표시되면 클러스터의 노드 수가 이미 최소 크기이므로 클러스터 자동 확장 처리에서 노드를 삭제할 수 없습니다.
알림
클러스터 자동 확장 처리 최소 리소스 한도에 도달했기 때문에 사용률이 낮은 노드의 축소가 차단되었습니다.
이벤트
"scale.down.error.failed.to.delete.node.min.size.reached"
이 문제를 해결하려면 자동 확장의 최소 한도를 검토하고 업데이트하세요.
Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.
알림 또는 Cloud Logging에서 식별된 클러스터의 이름을 클릭합니다.
클러스터 세부정보 페이지에서 노드 탭으로 이동합니다.
노드 수 열의 값을 검토하고 자동 확장 열에 표시된 최소 노드 수와 비교합니다. 예를 들어 자동 확장 열에 4~6개의 노드가 표시되고 노드 풀의 노드 수가 4개이면 노드 풀 수가 이미 최소 크기와 같으므로 클러스터 자동 확장 처리에서 노드를 더 이상 축소할 수 없습니다.
구성이 올바르고 노드 수 값이 자동 확장에 정의된 최솟값과 같으면 클러스터 자동 확장 처리가 제대로 작동하는 것입니다. 최소 노드 수가 요구사항에 비해 너무 많은 경우 노드를 축소할 수 있도록 최소 크기를 줄입니다.
오류: 포드를 이동할 위치가 없음
클러스터 자동 확장 처리가 노드를 축소하려고 시도했지만 노드의 포드를 다른 노드로 이동할 수 없어 실패하면 다음 오류가 발생합니다.
알림
클러스터의 다른 노드로 이동할 수 없는 포드가 있기 때문에 사용률이 낮은 노드의 축소가 차단되었습니다.
이벤트
"no.scale.down.node.no.place.to.move.pods"
이 포드의 일정을 변경하고 싶지 않은 경우 이 메시지가 표시되며 변경사항이 필요하지 않습니다. 포드 일정을 변경하려면 포드 매니페스트의 pod.spec block에서 다음 정의를 조사합니다.
- NodeAffinity: 사용률이 낮은 노드에서 포드의 예약 요구사항을 검토합니다. 포드 매니페스트를 검사하고 NodeAffinity 또는 NodeSelector 규칙을 찾아 이러한 요구사항을 검토할 수 있습니다. 포드에 nodeSelector가 정의되어 있고 클러스터에 이 선택기와 일치하는 다른 노드(다른 노드 풀의 노드)가 없는 경우 클러스터 자동 확장 처리가 포드를 다른 노드로 이동할 수 없으므로 사용률이 낮은 노드를 삭제할 수 없습니다.
maxPodConstraint:maxPodConstraint가 기본값 110이 아닌 다른 숫자로 구성된 경우 의도한 변경사항인지 확인합니다. 이 값을 낮추면 문제가 발생할 가능성이 커집니다. 클러스터의 다른 모든 노드가 이미maxPodConstraint에 정의된 값에 도달하여 새 포드를 예약할 공간이 없는 경우 클러스터 자동 확장 처리는 포드를 다른 노드로 재예약할 수 없습니다.maxPodConstraint값을 늘리면 노드에 더 많은 포드를 예약할 수 있으며 클러스터 자동 확장 처리가 포드의 일정을 다시 예약하고 사용률이 낮은 노드를 축소할 수 있습니다.maxPodConstraint를 정의할 때는 각 노드에 약 10개의 시스템 포드가 있다는 점에 유의하세요.hostPort: 포드에hostPort를 지정하면 해당 노드에서 하나의 포드만 실행할 수 있습니다. 이렇게 하면 클러스터 자동 확장 처리가 노드 수를 줄이기 어려울 수 있습니다. 해당 노드의 포트가 이미 사용 중이면 포드가 다른 노드로 이동하지 못할 수 있기 때문입니다. 이는 정상적인 동작입니다.
오류: kube-system 포드를 이동할 수 없음
시스템 포드가 축소를 방해하면 다음과 같은 오류가 발생합니다.
알림
DaemonSet이 아니고 미러링되지 않으며
kube-system네임스페이스에 PodDisruptionBudget이 없는 포드이기 때문에 포드에서 축소를 차단하고 있습니다.
이벤트
"no.scale.down.node.pod.kube.system.unmovable"
kube-system 네임스페이스의 포드는 시스템 포드로 간주됩니다. 기본적으로 클러스터 자동 확장 처리는 kube-system 네임스페이스의 포드를 삭제하지 않습니다.
이 오류를 해결하려면 다음 해결 방법 중 하나를 선택하세요.
kube-system포드에 대해PodDisruptionBudget을 추가하세요.kube-system포드에 대해PodDisruptionBudget을 수동으로 추가하는 방법에 대한 상세 설명은 Kubernetes 클러스터 자동 확장 처리 FAQ를 참조하세요.PodDisruptionBudget을 만들면 시스템 워크로드의 가용성에 영향을 미쳐 클러스터의 다운타임이 발생할 수 있습니다. 클러스터 자동 확장 처리는 축소 프로세스 중에 이러한 시스템 워크로드를 다른 워커 노드에 재예약합니다.
노드 풀 taint 및 톨러레이션(toleration)을 조합하여
kube-system포드를 애플리케이션 포드와 분리합니다. 자세한 내용은 GKE의 노드 자동 프로비저닝을 참조하세요.
노드에 kube-system 포드가 있는지 확인
노드에서 kube-system 포드를 실행 중인지 확실하지 않고 이를 확인하려면 다음 단계를 완료하세요.
Google Cloud 콘솔의 로그 탐색기 페이지로 이동합니다.
쿼리 빌더를 클릭합니다.
다음 쿼리를 사용하여 모든 네트워크 정책 로그 기록을 찾습니다.
- resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_ID/logs/container.googleapis.com%2Fcluster-autoscaler-visibility" jsonPayload.noDecisionStatus.noScaleDown.nodes.node.mig.nodepool="NODE_POOL_NAME"다음을 바꿉니다.
CLUSTER_LOCATION: 클러스터가 있는 리전CLUSTER_NAME: 클러스터 이름PROJECT_ID: 클러스터가 속한 프로젝트의 IDNODE_POOL_NAME: 노드 풀의 이름
노드 풀에서
kube-system포드가 실행 중이면 출력은 다음과 같습니다."no.scale.down.node.pod.kube.system.unmovable"
오류: PodDisruptionBudget이 충분하지 않음
PodDisruptionBudget이 축소를 방지하면 다음 오류가 발생합니다.
알림
포드를 제거할 수 있을 만큼 충분한 포드 중단 예산이 없는 포드가 실행 중이기 때문에 사용률이 낮은 노드의 축소가 차단되었습니다.
이벤트
NoScaleDownNodePodNotEnoughPdb: "no.scale.down.node.pod.not.enough.pdb"
PodDisruptionBudget이 지나치게 제한적인지 확인하려면 설정을 검토하세요.
kubectl get pdb --all-namespaces
출력은 다음과 비슷합니다.
NAMESPACE NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
example-app-one one_pdb N/A 1 1 12d
example-app-two two_pdb N/A 0 0 12d
이 예시에서 two_pdb 라벨 선택기와 일치하는 포드는 클러스터 자동 확장 처리에 의해 제거되지 않습니다. 이 PodDisruptionBudget의 maxUnavailable: 0 설정은 모든 복제본을 항상 사용할 수 있어야 한다고 지정합니다. 또한 disruptionsAllowed: 0는 이러한 포드의 중단을 금지합니다. 따라서 이러한 포드를 실행하는 노드는 중단을 일으키고 PodDisruptionBudget을 위반하므로 축소할 수 없습니다.
PodDisruptionBudget이 원하는 방식으로 작동하는 경우 추가 작업이 필요하지 않습니다. 사용률이 낮은 노드의 포드를 이동할 수 있도록 PodDisruptionBudget을 조정하려면 PodDisruptionBudget의 매니페스트를 수정합니다.
예를 들어 maxUnavailable을 0으로 설정한 경우 클러스터 자동 확장 처리가 축소될 수 있도록 1로 변경할 수 있습니다.
문제: 노드가 차단된 상태로 유지되고 삭제되지 않음
Google 서비스 계정에 편집자 역할이 없으므로 클러스터 자동 확장 처리가 노드 풀 크기를 줄일 수 없는 경우 다음과 유사한 오류가 발생합니다.
Required 'compute.instanceGroups.update' permission for 'INSTANCE_GROUP_NAME'.
이 문제의 일반적인 증상은 클러스터 자동 확장 처리가 노드 풀 크기를 줄이려고 시도하지만 노드의 상태가 변경되지 않는 경우입니다.
이 문제를 해결하려면 기본 서비스 계정(PROJECT_NUMBER@cloudservices.gserviceaccount.com)에 프로젝트에 대한 편집자 역할(roles/editor)이 있는지 확인합니다. 서비스 계정에 이 역할이 없으면 추가합니다. GKE는 이 서비스 계정을 사용하여 프로젝트의 리소스를 관리합니다. 이 방법을 알아보려면 IAM 문서의 단일 역할 부여 또는 취소를 참고하세요.
다음 단계
Kubernetes 클러스터 자동 확장 처리 FAQ에서 다음 질문을 검토합니다.
추가 지원이 필요하면 Cloud Customer Care에 연락합니다.