쿠버네티스에서 노드가 추가될 때마다 슬랙 알람 쏘기

Kubernetes의 Event 리소스와 Watch API를 이용해 Cluster Autoscaler가 노드를 추가하거나 제거할 때 알림을 보내는 경량 프로그램을 만드는 과정이다. 이벤트 스키마와 TTL의 한계를 짚고, Go watcher를 컨테이너화해 ServiceAccount·RBAC·kubectl proxy sidecar와 함께 클러스터에 배포한다.

핵심 포인트

`events.k8s.io/v1` Event는 type, regarding, reason, note로 사건을 표현하며 core v1 Event와 필드가 다르다.
노드 생성·삭제는 kubelet의 NodeReady·NodeNotReady 이벤트로, HPA 변경은 SuccessfulRescale로 관찰할 수 있다.
Event의 기본 TTL은 Kubernetes 1.24 기준 1시간이므로 영구 감사나 강한 일관성이 필요한 로직의 진실 소스로 쓰면 안 된다.
Watch API는 polling 없이 ADDED·MODIFIED 이벤트를 HTTP stream으로 전달해 알림 프로그램을 단순화한다.
watcher pod에는 events를 get·watch·list할 최소 RBAC와 API 접근 경로가 필요하며, 같은 pod의 kubectl proxy sidecar를 사용할 수 있다.

상세 정리

문제: 관리형 Kubernetes와 Cluster Autoscaler는 파드 수요에 따라 노드를 자동 생성하므로 운영자가 모르는 비용 증가를 빠르게 감지하고 싶었다.
Event 개념: `kubectl describe` 하단의 Events는 Kubernetes에서 발생한 사건이며 Event 자체도 JSON으로 조회 가능한 리소스다.
API 버전: core `v1`에는 involvedObject가 있지만 `events.k8s.io/v1`에는 regarding이 있다. 이 글은 Kubernetes 1.19 이상 후자만 사용한다.
주요 필드: type은 Normal·Warning, regarding은 관련 객체, reason은 짧은 PascalCase 원인, note는 사람이 읽는 상세 메시지다.
코드 기반 탐색: 어떤 상황에 어떤 Event가 나오는지는 중앙 문서보다 각 controller와 kubelet 소스에 정의돼 있어 정확한 목록은 코드를 봐야 한다.
노드 수명주기: kubelet은 노드가 파드를 받을 준비가 되면 NodeReady, 준비 상태를 잃으면 NodeNotReady를 기록한다.
파드·배포 이벤트: 컨테이너 Created·Started·Killing, ReplicaSet의 SuccessfulCreate·Delete, Deployment의 ScalingReplicaSet도 확장 상황을 보여준다.
TTL 제약: 대량 이벤트가 etcd에 쌓이지 않도록 오래된 객체가 삭제된다. 특정 이벤트의 존재 여부로 업무 상태를 판정하면 안 된다.
Watch 호출: Event endpoint에 `watch=true`를 붙이면 연결을 유지하며 각 변경을 한 줄 JSON으로 받는다.
Go 구현: bufio로 stream을 한 줄씩 읽고 WatchPayload로 역직렬화한 뒤 ADDED만 처리하고 regarding.kind와 reason으로 NodeReady·NotReady를 거른다.
중복 주의: 최초 연결에서 과거 이벤트가 함께 올 수 있으므로 resourceVersion이나 creationTimestamp로 이미 처리한 이벤트를 제외해야 한다.
재연결 전략: API 연결이 끊겨 프로세스가 종료되면 Kubernetes Deployment의 self-healing으로 다시 띄우도록 컨테이너화했다.
권한 설정: ServiceAccount에 전체 namespace의 events를 get·watch·list하는 ClusterRole과 ClusterRoleBinding을 연결한다.
API 접근: 같은 pod에 `kubectl proxy --port=8001` sidecar를 두면 네트워크 namespace를 공유해 watcher가 localhost로 API를 호출할 수 있다.
활용 범위: 소규모 개발 클러스터의 노드·배포 Slack 알림에는 유용하지만, 하루 수백 파드가 바뀌는 환경은 노이즈와 별도 내구성 설계를 고려해야 한다.