실제 Kubernetes 클러스터에서 Node Agent를 안전하게 검증하기

Kind에서 통과했다고 실제 노드에서도 동작하는 것은 아니다

Node Agent는 /proc, /var/log, runtime socket과 CNI 설정처럼 노드마다 다른 자원을 읽는다. 단위 테스트와 Kind는 API 계약을 빠르게 확인하는 데 유용하지만 다음 차이를 모두 재현하기 어렵다.

• RKE2, K3s, kubeadm의 서비스와 파일 경로
• containerd와 embedded runtime socket 위치
• systemd journal 접근 가능 여부
• Cilium과 Flannel의 CNI 구성
• amd64와 arm64 이미지·도구 차이
• 실제 Kubernetes Event와 node condition

그래서 실제 클러스터 검증을 별도 절차로 만들었다. 가장 중요한 원칙은 검증 중에도 Node Agent의 read-only 경계를 유지하는 것이었다.

먼저 배포하지 않고 확인하기

real-cluster-readiness-check.py는 다음 항목을 한 번에 확인한다.

kubectl 접근
  → Node Ready/Pressure 상태
  → 최근 Warning Event
  → Helm lint와 render
  → Agent manifest server dry-run
  → 선택적 local collector 실행

기본 실행은 실제 리소스를 만들지 않는다. Host Collector까지 확인할 때만 --agent-local을 사용하고 14개 Collector를 로컬에서 읽기 전용으로 실행한다.

DaemonSet 밖에서는 in-cluster ServiceAccount가 없기 때문에 Kubernetes Collector가 api_error를 반환할 수 있다. 이 경우 local collect 전체를 실패시키지 않고 제한된 환경이라는 신호로 기록한다. 수집 환경의 제약과 실제 클러스터 장애를 구분하기 위해서다.

실제 canary도 범위를 고정하기

적용형 검증이 필요한 경우에는 단일 Ready node와 격리 namespace를 사용한다. Agent 등록, heartbeat, Evidence Request, Report, Incident와 Evidence bundle을 확인한 뒤 검증용 리소스를 정리한다.

금지한 작업은 명확하다.

• 노드 재부팅
• kubelet 또는 container runtime 재시작
• 운영 Workload 삭제·재배포
• 네트워크 설정 변경
• 승인 Action 실행 활성화

검증 결과가 좋지 않더라도 Agent가 노드를 고치지 않는다. 필요한 조치는 runbook이나 GitOps 흐름으로만 안내한다.

실제 클러스터에서 발견한 것

초기 RKE2 환경에서는 다음 신호를 확인했다.

• control-plane peer 포트 연결 실패
• RKE2 node certificate expiration warning
• Cilium Agent restart 증가
• Metrics API의 <unknown> 응답
• 정상 disk, inode, memory, conntrack 상태

이 결과를 바탕으로 Kubernetes API Collector와 Rule을 보강했다.

• Node condition과 Pressure
• Pod 및 CNI restart
• Metrics API 상태
• API Server readyz
• RKE2 server/agent systemd 상태
• control-plane peer TCP probe
• 인증서 경고와 CNI restart Detector

실제 환경에서 중요한 것은 “수집 명령이 실행됐다”가 아니라 Collector가 어떤 제한 상태를 보고했는지였다. 파일 기반 journal이 없는 노드는 limited로 남기고 다른 Evidence를 계속 수집하도록 했다.

결과 artifact에서도 식별자를 줄이기

검증 artifact에 원본 kubeconfig, Platform URL, node 이름과 Evidence 원문을 넣지 않았다. 기본 결과는 fingerprint, check 결과, warning과 cleanup 상태를 담은 attestation으로 제한했다.

Managed cluster canary에서도 성공 횟수만으로 지원 완료를 표시하지 않는다. Platform owner와 Security owner가 artifact를 검토한 뒤 별도 PR로 compatibility matrix를 변경해야 한다.

이 절차를 만든 이유

실클러스터 테스트는 정확도를 높이지만 잘못 설계하면 테스트 자체가 장애 원인이 된다. 그래서 다음 순서를 지켰다.

read-only preflight
  → manifest server dry-run
  → 제한된 canary 승인
  → 단일 노드 관측
  → Report와 bundle 검증
  → cleanup 검증
  → 결과 검토 후 수동 승격

“실제 환경에서 테스트했다”는 문장보다 어떤 환경에서 무엇을 했고 무엇을 하지 않았는지 기록하는 것이 더 중요했다.

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