13 · consolidation 후보 선별과 심사

1. 전체 처리 흐름

1.1 Disruption Controller 안에서의 위치

consolidation에는 전용 컨트롤러가 없습니다. Disruption Controller 하나가 다섯 개의 method를 등록해 두고 순서대로 물어봅니다.

consolidationPolicy를 읽는 method는 4번과 5번뿐입니다. 그래서 정책을 WhenEmpty로 바꿔도 drift는 그대로 돌고 Balanced로 바꿔도 빈 노드는 채점 없이 지워집니다. 이 글의 범위는 1·4·5번입니다. drift가 왜 걸리고 어떻게 되돌리는지는 다루지 않습니다.

2번과 3번은 서로 배타적입니다. StaticDrift는 spec.replicas가 지정된 NodePool의 노드만, Drift는 그렇지 않은 노드만 봅니다.

1.2 한 바퀴

• 등록 순서대로 method를 시도하고 처음으로 커맨드를 만든 method에서 그 라운드가 끝납니다. 뒤에 남은 method는 아예 돌지 않습니다.
• 한 라운드에 한 액션이 아니라 한 라운드에 한 method입니다. 한 method가 커맨드를 여러 개 만들면 모두 한꺼번에 큐에 들어갑니다.
• 아무 method도 움직이지 않으면 10초 뒤에 다시 돕니다. 어느 하나가 성공하면 즉시 재큐되므로 실제 주기는 **“최대 10초”**입니다. 10초 고정이 아닙니다.

2. 후보 선별과 제외 조건

2.1 두 단계로 걸러진다

후보 목록은 한 번에 만들어지지 않습니다. 클러스터의 모든 노드마다 먼저 Candidate를 만들어 보고 그다음 method별 필터가 한 번 더 걸러냅니다.

1차에서 걸리는 대표적인 조건입니다.

2차 조건은 method마다 다릅니다. consolidation 계열은 consolidateAfter가 Never인 NodePool, static NodePool, 인스턴스 타입이나 zone·capacity-type 라벨이 없는 노드, 그리고 빈 노드를 뺍니다. 빈 노드를 빼는 까닭은 예산 회계를 Emptiness가 전담하도록 역할을 나눠 놓았기 때문입니다.

2.2 disruption cost — 노드 하나를 지울 때 치르는 대가

1차를 통과한 노드는 Candidate가 되고 이때 이후 판단에 쓸 값이 함께 계산됩니다. 실제로 쓰이는 것은 넷입니다.

RescheduleDisruptionCost는 노드 한 대를 지울 때 치르는 대가에 가중치를 매긴 값입니다.

// controllers/disruption/types.go:136-141
cost := PerNodeBaseDisruptionCost          // = 1.0
for _, p := range reschedulablePods {
    cost += math.Max(0, disruptionutils.EvictionCost(ctx, p))
}

base 1.0은 cordon·drain·대체 노드 기동 지연 그 자체의 비용입니다. max(0, ·)가 합계가 아니라 파드 하나하나에 걸리므로 음수 항이 합계를 깎지 못합니다. 그래서 이 값은 어떤 경우에도 1.0 아래로 내려가지 않습니다.

파드별 비용은 기본 1.0에 pod-deletion-cost / 2²⁷과 priority / 2²⁵를 더하고 [-10, 10]으로 자릅니다. 나누는 수가 워낙 커서 실무에서는 **disruptionCost ≈ 1 + 재스케줄 대상 파드 수**로 읽어도 대체로 맞습니다.

정렬 기준도 여기서 나옵니다.

SavingsRatio = Price ÷ RescheduleDisruptionCost — 파드 하나를 옮기는 대가로 시간당 얼마를 아끼는가. 이 값이 큰 순서로 후보를 훑으므로 비싸면서 한산한 노드가 먼저 정리됩니다.

시간 가중치는 없습니다. LifetimeRemaining이 곱해지는 필드는 따로 있지만 읽는 코드가 없어 “만료가 임박한 노드가 먼저 지워진다"는 설명은 v1.14 기준으로 성립하지 않습니다.

3. 제거 사유 — Empty · Drifted · Underutilized

1차와 2차를 통과했다는 것은 “손대도 되는 노드"라는 뜻일 뿐, 아직 지울 이유는 없습니다. 이유는 어느 method가 그 노드를 집었는지로 정해집니다.

Drifted는 consolidation의 하위 분류가 아닙니다. 세 Reason이 한 줄에 놓여 같은 알고리즘의 세 갈래처럼 보이지만 drift는 정책을 읽지 않고 스코어도 받지 않는 별개의 경로입니다. consolidationPolicy로는 끌 수 없습니다. 막으려면 예산에 reasons: [Drifted]를 걸어야 합니다.

Empty 판정은 파드 개수가 아니라 비용을 봅니다. RescheduleDisruptionCost가 1.0 이하이기만 하면 빈 노드입니다. 파드가 떠 있어도 그 파드들의 축출 비용이 전부 0으로 깎이면 Empty가 됩니다. 직관과 조금 다른 대목이고 이 성질이 뒤에서 함정 하나를 만듭니다(§8.2).

4. Underutilized 처리 — MultiNode와 SingleNode

Underutilized만 안에서 두 단계로 나뉩니다. 둘 다 SavingsRatio로 정렬한 같은 후보 목록을 받아 시작하고 다른 것은 그 목록에서 몇 대를 집느냐뿐입니다.

아래 두 도식은 같은 규칙으로 읽습니다. 집는 순간 비용 합계가 확정되고(옅은 칸), 파드를 옮기면서 그 값을 치릅니다(진한 칸). 옮기면서 계산하는 값이 아닙니다. 후보를 만들 때 이미 정해집니다.

SingleNode는 앞에서부터 한 대씩 집어 봅니다. 그 노드의 파드를 다른 곳으로 옮길 수 있는지 확인하고 실패하면 다음 후보로 내려갑니다. 처음 성공한 노드로 커맨드를 만들고 빠져나옵니다.

한 대만 집으니 비용도 그 노드 몫뿐입니다. 그래서 옮길 파드가 적은 노드가 먼저 통과합니다.

MultiNode는 앞에서부터 여러 대를 한꺼번에 집습니다. 묶은 만큼 비용도 합쳐지지만 한 대씩 봐서는 나오지 않을 조합이 여기서 나옵니다.

4.1 실행 순서는 설명 순서의 반대다

개념이 쉬워 SingleNode를 먼저 놓았지만 실제로는 MultiNode가 먼저 돕니다. MultiNode가 커맨드를 하나라도 만들면 그 라운드는 거기서 끝나고 SingleNode는 MultiNode가 빈손일 때만 내려옵니다.

두 경로는 성격이 꽤 다릅니다.

“작은 배치부터 키워 간다"는 오해가 특히 잦습니다. 후보가 101개 이상이면 첫 시뮬레이션이 51대짜리이고 2대짜리 배치는 탐색이 끝까지 좁혀졌을 때만 시도됩니다.

SingleNode의 순회 순서도 정렬 결과 그대로가 아닙니다. SavingsRatio로 정렬한 뒤 NodePool별로 묶어 번갈아 가며 훑으므로 최종 순서는 “풀 안에서는 비율 내림차순, 풀 사이에서는 교대"입니다.

5. 삭제와 교체의 갈림목

결과는 셋 중 하나입니다 — 아무것도 하지 않거나(no-op), 그냥 지우거나(delete), 대신 한 대를 띄우고 지우거나(replace). 이를 가르는 것은 판정식 여러 개가 아닙니다. 시뮬레이션 한 번입니다.

5.1 시뮬레이션이 세는 것

후보 노드를 클러스터에서 가상으로 지우고 그 위의 파드를 다시 스케줄해 본 뒤 새로 띄워야 할 노드가 몇 대인가를 셉니다.

새 NodeClaim이 0개면 그 자리에서 반환하고 가격 필터에 도달하지 않습니다. 그래서 가격 조회에 실패해 Price가 0인 노드도 그냥 삭제됩니다 — 삭제형에는 가격 검사가 없는데 이 점을 자주 놓칩니다. 이 이야기는 WhenEmptyOrUnderutilized에 한합니다. Balanced 풀에서는 Price가 0이면 스코어가 0이 되어 삭제가 거부됩니다.

가격 필터가 요구하는 것은 부등식 하나입니다.

새로 띄울 노드가 지울 노드들의 가격 합보다 엄격히 싸야 합니다.

여기서 쓰는 “새 노드 가격"은 최저가가 아니라 최악가입니다. 후보 인스턴스 타입이 살아남으려면 가능한 오퍼링 중 가장 비싼 것조차 기존 합계보다 싸야 합니다.

그래서 삭제와 교체는 대등한 두 개념이 아닙니다. 둘 다 Command라는 지시서 한 장이고 Replacements가 비었는지에서 형태가 달라질 뿐입니다. 이 제약은 커맨드를 만들 때와 15초 뒤 재검증 때 두 번 걸립니다.

// controllers/disruption/validation.go:326-329
// we need more than one replacement node which is never valid
// currently (all of our node replacement is m->1, never m->n)

5.2 시뮬레이션이 실패하는 실제 이유

시뮬레이션은 파드 하나가 실패했다고 곧바로 멈추지 않습니다. 실패한 파드를 큐에 다시 넣고 선호 조건을 한 단계씩 완화해 가며 끝까지 재시도합니다. 포기할지는 시뮬레이션이 끝난 뒤에 정합니다 — 그 시점까지도 자리를 못 찾은 파드가 하나라도 남아 있으면 통합을 접습니다.

파드가 갈 곳을 못 찾는 사유는 실무에서 대개 이 범위 안에 있습니다.

반대로 원래부터 Pending이던 파드는 통합을 막지 못합니다. 통합 전에도 스케줄되지 않던 파드는 오류 집합에서 제외됩니다.

5.3 분류가 결과를 정하지는 않는다

“이 노드는 drift로 처리되나 교체로 처리되나"는 성립하지 않는 질문입니다. 둘은 서로 다른 축이고 배타적 선택지가 아닙니다.

시뮬레이션을 거치는 두 갈래에서는 네 조합이 전부 나옵니다.

가격 검사 열만 값이 다릅니다. drift는 스펙을 맞추는 것이 목적이라 가격 필터를 아예 타지 않습니다. 가격 부등식은 통합 전용입니다.

Empty만 판별을 받지 않아 결과가 고정됩니다 — 옮길 파드가 없으니 대체를 요구할 일 자체가 없기 때문입니다.

6. 세 정책의 차이

세 정책이 서로 달라지는 곳은 딱 한 군데입니다.

빈 노드 열이 셋 다 같은 것은 그 일을 맡은 Emptiness가 consolidationPolicy를 아예 읽지 않기 때문입니다. 정책을 무엇으로 두든 빈 노드는 똑같이 지워지고 실제로 달라지는 것은 가운데 열 하나뿐입니다.

세 정책은 “정책의 강도"가 아니라 승인 조건의 포함 관계로 이해하는 편이 정확합니다.

• WhenEmpty가 승인하는 것은 Balanced도 전부 승인합니다. WhenEmpty는 빈 노드만 지우는데, Balanced도 빈 노드는 채점 없이 지우기 때문입니다.
• Balanced가 승인하는 것은 WhenEmptyOrUnderutilized도 전부 승인합니다. Balanced는 새 통합을 만들지 않고 앞 경로의 결과를 거부만 하기 때문입니다.

그래서 Balanced로 바꾸면 통합은 반드시 줄어듭니다. 물어야 할 것은 “더 될까"가 아니라 **“무엇이 덜 될까”**입니다.

7. Balanced 심층 분석

7.1 기준선 — WhenEmptyOrUnderutilized가 하는 일

게이트가 둘뿐입니다 — “모든 파드가 다른 데 들어가는가”, 그리고 교체라면 “엄격히 더 싼가”. 절감의 규모를 묻는 곳이 없어서 “10원 아끼려고 파드 40개를 옮긴다"가 여기서 나옵니다.

7.2 Balanced가 얹는 게이트

Balanced가 묻는 것을 말로 옮기면 이렇습니다.

이 통합이 NodePool의 평균 비용 효율보다 충분히 좋은가. 후보가 절감하는 시간당 비용을 파드 이동 비용으로 나누고 그 값을 NodePool 전체의 평균 비용 효율과 비교합니다. 절반에 못 미치면 거부합니다.

식으로는 이렇게 됩니다.

score = ( savings ÷ disruptionCost ) ÷ ( TotalCost ÷ TotalDisruptionCost ) ≥ 1/k = 0.5

분자는 이 액션의 효율, 분모는 풀의 평균 효율입니다. 분모가 풀 전체라 풀 크기는 약분되어 영향이 없습니다. 한산하고 비싼 노드가 많은 풀일수록 기준선이 높아 통과가 어려워집니다.

7.3 숫자를 넣어 보면

노드 10대짜리 NodePool을 가정합니다. 총비용은 시간당 $10이고 노드마다 파드가 4개씩 떠 있습니다.

• 노드 한 대의 disruption cost = 1.0(노드 몫) + 4(파드 4개) = 5
• 풀 전체 disruption cost = 5 × 10 = 50
• 풀의 평균 효율 = $10 ÷ 50 = 0.2 (파괴 1단위당 시간당 달러)

이제 시간당 $1.00짜리 노드 한 대(파드 4개)를 후보로 잡고 세 경우를 봅니다.

파드 밀도가 풀 평균과 같은 노드에서는 score가 절감률과 그대로 같아집니다. 그래서 “평균적인 노드는 50% 이상 싸지는 교체만 통과한다"가 됩니다.

밀도가 어긋나면 결과가 달라집니다. 같은 40% 절감이라도 파드가 1개뿐인 노드라면 disruption cost가 2로 줄어 score가 1.0이 되어 통과합니다. 파드 밀도가 분모에 들어 있어 한산한 노드는 쉬워지고 빽빽한 노드는 보호됩니다.

한 건이 심사를 받는 과정입니다.

7.4 사전 컷 — 시뮬레이션조차 건너뛰는 경우

심사가 시뮬레이션 뒤에만 도는 것은 아닙니다. 교체는 새 노드 값을 빼야 하니 삭제보다 절감이 작을 수밖에 없습니다. 후보의 최선인 “그냥 삭제"조차 임계를 넘지 못하면 더 볼 것이 없어 시뮬레이션 자체를 건너뜁니다.

이 사전 컷에는 조건이 둘 붙습니다.

• Balanced 풀에만 걸립니다. 다른 정책에서는 무조건 통과합니다.
• SingleNode 경로에만 있습니다. MultiNode에는 없어서 멀티 노드 통합은 시뮬레이션을 다 돌린 뒤에야 거부됩니다.

7.5 “거부만 한다"의 예외

Balanced가 새 통합을 만들지 않는다는 것은 맞습니다. 그런데 MultiNode 경로에서는 거부가 단순한 veto로 끝나지 않습니다.

이진 탐색 도중 어떤 배치가 거부되면 탐색 창이 그만큼 좁혀집니다. 그 결과 더 작은 배치가 대신 채택될 수 있습니다. 5대를 묶는 통합이 거부되고 3대를 묶는 통합이 선택되는 식입니다. 승인 집합이 넓어지는 것은 아니지만 “어떤 크기의 배치가 뽑히는가"는 바뀝니다.

한 가지 더 — Balanced 도입은 모든 정책의 MultiNode 후보 정렬을 바꿨습니다. 예전에는 disruption cost 오름차순이었는데 지금은 Price / RescheduleDisruptionCost 내림차순입니다. WhenEmptyOrUnderutilized를 쓰고 있어도 v1.14로 올리면 묶이는 조합이 달라질 수 있습니다.

7.6 여러 NodePool에 걸친 커맨드

한 커맨드가 여러 NodePool의 노드를 건드리면 savings를 각 풀의 비용 비율로 안분해 풀마다 따로 심사합니다. 한 풀이라도 미달이면 커맨드 전체가 거부됩니다.

단 심사 대상은 정책이 Balanced인 풀뿐입니다. WhenEmptyOrUnderutilized 풀의 노드는 안분 분모에는 들어가지만 채점은 받지 않습니다. 커맨드에 Balanced 풀이 하나도 없으면 무조건 승인됩니다.

7.7 k는 바꿀 수 없다

// apis/v1/nodepool.go:167-171
// BalancedK is the scoring parameter for the Balanced policy. A move is
// approved when score >= 1/k = 0.5. k=2 is the smallest value where
// within-family replaces pass, with 4-step max churn.
const BalancedK int32 = 2

Go const이고 호출부 두 곳 모두 상수를 그대로 넘깁니다. NodePool 필드도, 플래그도, feature gate도 없습니다.

선택 근거는 주석에 적혀 있습니다 — 같은 패밀리에서 한 단계 다운사이징(4xlarge → 2xlarge)이 딱 50% 절감이라 그 교체가 겨우 통과하는 값이 k=2입니다. 임계를 조절할 수 없으니 손댈 수 있는 것은 분모인 pod-deletion-cost뿐입니다.

7.8 흔한 오해 둘

“세 정책은 같은 스코어식에 다른 k를 넣은 것입니다” — 앞의 포함 관계는 맞지만 식은 그렇게 되어 있지 않습니다. WhenEmpty의 판정은 비율이 아니라 원시 비용에 걸린 절대 임계입니다. IsEmpty()는 RescheduleDisruptionCost <= 1.0이고 분모도 savings도 등장하지 않습니다. k→0으로 표현할 수도 없습니다. 임계 1/k가 무한대가 되어 score가 +Inf여야 통과하는데 앞에서 봤듯 비용은 절대 0이 되지 않습니다. k→0은 “빈 노드를 지운다"가 아니라 **“아무것도 지우지 않는다”**에 수렴합니다.

"Balanced니까 AZ나 spot 분산을 맞춰 주겠지” — 이름과 달리 그런 일은 하지 않습니다. 스코어에 들어가는 것은 가격과 disruption cost뿐이고 AZ 균형, spot과 on-demand 비율, 인스턴스 세대는 어느 항에도 등장하지 않습니다. 여기서 말하는 균형은 “절감과 churn 사이의 균형"입니다.

7.9 언제 효과가 없나

가운데 셋이 중요합니다. “노드가 자꾸 교체된다"의 원인이 통합이 아니면 Balanced는 아무것도 바꾸지 않습니다. 원인부터 짚고 판단해야 합니다.

7.10 켜기

spec:
  disruption:
    consolidationPolicy: Balanced
    consolidateAfter: 1m

feature gate가 없습니다. 설계 RFC는 BalancedConsolidation 게이트로 옵트인한다고 적었지만 구현에는 들어가지 않았습니다. 코어 v1.14.0이 최초이고 그 이하 버전에서는 enum에 없어 admission에서 거부됩니다.

8. 운영자의 개입 수단

개입 수단은 저마다 다른 축을 제어합니다. 섞어서 이해하면 엉뚱한 곳을 만집니다.

8.1 consolidateAfter — 후보 자격의 대기 시간

노드가 Consolidatable 상태가 되기까지 기다리는 시간입니다. Never로 두면 Empty와 Underutilized 양쪽이 모두 꺼집니다. drift에는 걸리지 않습니다.

8.2 pod-deletion-cost로 비용을 조절한다

값을 키우면 그 파드의 축출 비용이 올라 노드의 disruption cost가 오릅니다. 알아야 할 것이 셋입니다.

• Balanced에서만 보호로 작동합니다. 다른 두 정책은 스코어 게이트가 없어 삭제 여부가 바뀌지 않고 바뀌는 것은 정렬 순서뿐입니다.
• 제로섬입니다. 올린 점수는 노드 A에만 쌓이지 않습니다. 풀 전체 합계에도 그대로 더해집니다. A는 점수가 내려가 보호되지만 그만큼 풀 기준선이 낮아져 같은 풀의 B는 오히려 지워지기 쉬워집니다. “이 파드를 보호하면 끝"이 아니라 “압력을 옆으로 옮긴다"가 정확합니다.

아무 설정도 하지 않으면 파드별 비용이 전부 1.0이라 스코어는 사실상 “절감 비율 대 파드 개수 비율” 비교로 축퇴합니다.

8.3 예산으로 실행량을 조인다

정책은 후보를 만들지 말지를, 예산은 몇 대나 실행할지를 정합니다. 예산의 reasons로 쓸 수 있는 값은 Empty · Underutilized · Drifted 셋입니다.

예산은 실행 속도만 조이지 않습니다. 후보 풀 자체를 자릅니다. MultiNode는 탐색 전에 예산이 0인 NodePool의 후보를 건너뛰고 후보를 넣을 때마다 그 풀의 예산을 하나씩 깎습니다. 그런데 MultiNode는 후보가 2개 미만이면 즉시 빈 커맨드를 반환합니다.

또 하나, 예산 차감은 reason을 가리지 않습니다. 진행 중인 disruption을 전부 세어 각 reason의 몫에서 빼기 때문에 통합 한 건이 빈 노드 삭제의 예산을 잡아먹을 수 있습니다. 기본 예산은 10%라 10노드 풀에서 1입니다.

막는 방법에 따라 흔적이 다릅니다. consolidationPolicy: WhenEmpty로 막으면 후보 단계에서 탈락해 이벤트가 남지 않습니다. 예산 0으로 막으면 후보는 만들어지고 실행만 차단되어 DisruptionBlocked가 쌓입니다. 진단하기에는 예산 쪽이 낫습니다 — 막힌 흔적이 이벤트로 남기 때문입니다.

9. 관측과 문제 해결

9.1 확인 순서

“노드가 안 줄어든다” 또는 “노드가 너무 자주 갈린다"를 만나면 이 순서로 좁히는 편이 가장 빠릅니다.

1. 원인이 무엇인가 — karpenter_nodeclaims_disrupted_total{reason}으로 Empty·Underutilized·Drifted 중 어느 쪽인지 먼저 가릅니다. 통합이 아니면 정책을 만져도 소용이 없습니다.
2. 예산이 막고 있나 — karpenter_nodepools_allowed_disruptions{reason}이 0이면 여기서 끝입니다.
3. 후보가 왜 떨어졌나 — 노드에 붙은 Unconsolidatable 이벤트 message를 봅니다.
4. Balanced 풀이라면 스코어는 얼마였나 — karpenter_consolidation_score를 봅니다.
5. 그래도 모르겠으면 — --log-level debug의 판정 로그를 켭니다.

9.2 이벤트

Unconsolidatable 이벤트의 message가 사유를 그대로 말합니다.

9.3 메트릭

Balanced는 승인만 이벤트를 남기고 거부는 메트릭만 남깁니다. 거부량이 많아 승인이 파묻히는 것을 막으려는 설계입니다. 그래서 “왜 거부됐나"는 karpenter_consolidation_score와 debug 로그의 consolidation score 줄로만 확인할 수 있습니다.

거부율은 이 정도면 충분합니다.

# Balanced 풀에서 임계 미달로 거부된 비율
sum(rate(karpenter_consolidation_moves_total{decision="rejected"}[30m]))
  / sum(rate(karpenter_consolidation_moves_total[30m]))

메트릭 이름과 라벨 구성은 코어가 내보내는 karpenter_* 60여 개 중 일부입니다. 전량은 pkg/metrics/와 각 컨트롤러의 metrics.go에 정의돼 있습니다.

10. 정리

• consolidation은 네 단계짜리 파이프라인입니다. 후보 선별 → 사유 판정 → 시뮬레이션 → 수행. 단계마다 다른 이유로 후보가 떨어지므로, “왜 이 노드가 안 지워지나"는 어느 단계에서 걸렸는지부터 물어야 합니다.
• 삭제와 교체를 가르는 것은 시뮬레이션이 요구한 새 노드 대수 하나입니다. 0대면 삭제, 1대면 가격을 보고 교체, 2대 이상이면 아무것도 하지 않습니다. 대체 노드는 언제나 최대 1대입니다.
• Drift는 consolidation이 아닙니다. 정책으로 끌 수 없고 스코어도 받지 않습니다. “노드가 자꾸 갈린다"의 원인부터 reason 라벨로 가르고 시작하십시오.
• Balanced는 거부만 하는 층입니다. 통합이 늘어나는 일은 없고 빈 노드와 drift에는 개입하지 않습니다. 임계 k=2는 상수라 바꿀 수 없습니다. AZ나 spot 분산과는 무관합니다.
• 예산 1은 “천천히"가 아니라 “MultiNode 끄기"에 가깝습니다. 노드 수를 줄이는 것이 목적이라면 최소 2 이상이 나오도록 잡아야 합니다.

11. 코드와 문서 근거

kubernetes-sigs/karpenter v1.14.0 로컬 체크아웃(v1.14.0-6-gac7a021e). 경로는 pkg/ 기준이고 별도 표기가 없으면 controllers/disruption/입니다.

확인하지 못한 것

• controller.kubernetes.io/pod-deletion-cost의 상수 원문은 k8s.io/api 모듈 소스가 로컬에 없어 확인하지 못했습니다.
• 이 체크아웃에는 upstream 태그에서 확인되지 않는 요소가 섞여 있을 수 있습니다. Emptiness의 buffer 파드 가드와 static NodePool 가드가 그 후보입니다. 자기 클러스터에서 확인할 때는 라인번호가 아니라 함수명과 식별자로 검색하십시오.