실제 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

그래서 실제 클러스터 검증 절차를 따로 만들었다. 검증 중에도 Agent가 호스트 상태를 바꾸지 않도록 범위를 제한했다.

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

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도 범위를 고정하기

실제 배포가 필요한 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 지원 표시는 Platform owner와 Security owner가 artifact를 검토한 뒤 별도 PR로 compatibility matrix를 바꾸도록 했다. canary 성공 횟수만으로 승격하지 않게 한 것이다.

이 절차를 만든 이유

실클러스터 검증 자체가 운영 상태를 바꾸지 않도록 다음 순서로 진행했다.

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

어느 환경에서 어떤 관측을 했고 무엇을 제외했는지, 테스트 자원은 정리됐는지까지 결과에 남겼다.

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