클러스터마다 다른 임계값과 운영 카탈로그를 분리하기

코드에 들어 있던 운영 기준을 밖으로 꺼내기

초기 RCA Rule에는 Collector 선택, 임계값, 권장 조치가 함께 들어 있었다. 운영 환경이 늘면서 설정만 바꾸려 해도 코드를 수정해야 하는 일이 생겼다.

• DiskPressure에서 어떤 Collector를 요청할지 바꾸려면 코드를 수정해야 했다.
• 특정 Detector를 canary 기간에만 끄기 어려웠다.
• 같은 디스크 사용률도 클러스터 성격에 따라 정상 기준이 달랐다.
• 권장 조치 문구와 정책을 변경할 때 애플리케이션 릴리스가 필요했다.
• 운영 변경이 코드 리뷰와 섞여 Audit 경계가 흐려졌다.

분석 코드는 신호 계산을 맡기고, 운영 기준은 Operational Catalog와 Cluster Threshold Override로 분리했다.

Operational Catalog의 세 영역

Catalog는 Collector, Action, Rule로 나눴다.

Collector Catalog

Collector의 의미와 활성화 여부, 필요한 permission mode를 정의했다. Alert별 Collector 조합도 Catalog에서 선택하게 했다.

DiskPressure
  → node
  → disk
  → inode
  → kernel
  → systemd

항상 모든 Collector를 실행하면 시간과 필요한 권한이 늘어난다. 증상에 필요한 근거부터 요청하고, 부족하면 다음 수집을 만들도록 했다.

Action Catalog

Signal에 연결할 확인 작업과 안내를 정의했다. plan.executable=false를 계약으로 유지해 외부 Catalog를 통해 host mutation이 실행되지 않도록 했다.

Rule Catalog

Detector별 활성화 여부를 관리했다. canary에서 disk-pressure Rule을 잠시 끄는 변경도 검증과 승인을 거치도록 했다.

잘못된 Catalog는 부팅 단계에서 막기

외부 JSON은 필요한 key만 기본 Catalog와 병합하게 했다. 다음 계약을 위반하면 시작 단계에서 실패하도록 했다.

• schema version이 맞는지
• 존재하지 않는 Collector를 참조하는지
• Action policy가 빠졌는지
• 필수 수동 조사 Action이 있는지
• 실행 가능한 Action plan이 포함됐는지

잘못된 설정을 무시하면 일부 Rule이 빠진 채 Report가 만들어질 수 있었다. 이를 시작 단계에서 발견하도록 한 것이다.

Platform Info API와 Console Settings에는 Catalog source, version, checksum, Collector·Action·Rule 개수를 읽기 전용으로 표시했다. 당시 분석에 쓰인 설정을 확인할 수 있도록 했다.

Preview와 승인 Draft

Override는 먼저 preview하도록 했다. JSON Pointer 기준 diff, 현재 값과 제안 값, 검증 결과를 반환하고 Audit event를 남겼다.

검증된 내용은 다음 상태를 갖는 Draft로 저장했다.

draft → approved | rejected | discarded

승인 후에도 현재 Platform 설정은 바로 바꾸지 않았다. Handoff나 GitOps PR로 외부 변경관리 절차에 넘기도록 했다.

클러스터별 Threshold Override

Catalog와 별도로 클러스터마다 임계값을 덮어쓸 수 있게 했다.

{
  "thresholds": {
    "disk.warning.percent": 93,
    "disk.critical.percent": 95
  },
  "reason": "staging storage pool has a higher normal baseline"
}

알 수 없는 key, 범위를 벗어난 percent, warning보다 낮은 critical 값은 저장하지 않도록 했다. 분석 시 effective threshold는 다음처럼 계산했다.

application default + cluster override

사용한 값은 Report의 derived signal에 남겼다. 같은 95%라도 클러스터에 적용된 기준에 따라 판단이 달라질 수 있기 때문이다.

이 구조를 선택한 이유

운영 기준을 외부 설정으로 옮기면서 변경 내용과 적용 기준을 확인할 장치도 함께 만들었다.

• schema와 fail-fast 검증
• checksum과 source 가시성
• preview와 diff
• 역할 기반 저장·승인
• Audit 기록
• 자동 적용 금지

설정값뿐 아니라 누가 어떤 이유로 변경을 요청하고 승인했는지 추적할 수 있도록 했다.

프로젝트 저장소: Kubernetes Cluster Infra RCA Platform