RKE2·K3s·kubeadm 검증으로 Collector 호환성 다듬기

Kubernetes 배포판이 바뀌면 Evidence 모양도 달라진다

Node Agent의 Collector는 Linux 명령 몇 개를 실행하는 스크립트가 아니다. 같은 containerd를 사용해도 RKE2, K3s와 kubeadm은 socket, systemd unit, CNI와 로그 경로가 다르다.

실제 검증 범위를 다음 환경으로 넓혔다.

• RKE2 5노드: amd64·arm64 혼합, containerd, Cilium
• K3s 1노드: openSUSE, embedded containerd, Flannel
• kubeadm 1노드: Ubuntu 24.04, containerd, Flannel

목표는 배포판 이름을 늘리는 것이 아니라, Collector가 환경 차이를 장애로 오판하지 않는지 확인하는 것이었다.

14개 Collector를 같은 기준으로 실행하기

Node Agent의 registry는 다음 Collector를 관리한다.

node, kubernetes, systemd, kernel, disk, inode, memory, process,
network, conntrack, runtime, kubelet, cni, dns

각 결과는 공통 envelope을 가진다.

success   수집 완료
partial   일부 필드만 수집
limited   환경 또는 권한 제약
failed    Collector 자체 실패

예를 들어 컨테이너 안에서 host journal을 읽지 못했다고 kubelet 장애라고 판단하면 안 된다. permission denied는 runtime unhealthy가 아니라 Evidence 접근 경계 문제일 수 있다.

RKE2에서 확인한 차이

RKE2는 rke2-server, rke2-agent 서비스와 embedded containerd를 사용한다. Cilium 환경에서는 CNI Agent restart와 health port도 함께 봐야 했다.

amd64와 arm64 노드를 각각 canary로 검증하면서 Agent 등록, heartbeat, 14개 Collector 요청, Report와 서명된 Evidence bundle까지 확인했다. 파일 기반 systemd 또는 kubelet 로그가 없는 경우는 실패가 아니라 limited로 보고됐다.

이 과정에서 control-plane peer connectivity, CNI restart, Metrics API unavailable, API readyz failure와 node certificate warning Rule을 보강했다.

K3s와 openSUSE에서 확인한 차이

K3s는 embedded runtime과 Flannel을 사용하고, openSUSE의 패키지·로그 환경도 Ubuntu와 다르다. 일반적인 /run/containerd/containerd.sock만 가정하면 runtime Collector가 잘못 실패할 수 있다.

K3s에서는 실제 경로 후보를 탐지하고 어떤 source를 선택했는지 Evidence metadata에 남기도록 했다. Systemd와 kubelet 정보도 사용 가능한 file fallback을 구분했다.

kubeadm 환경을 별도로 만든 이유

RKE2와 K3s만 통과하면 특정 배포판의 편의 기능에 의존한 구현인지 알기 어렵다. 격리된 Ubuntu VM에 kubeadm, containerd와 Flannel을 구성해 일반적인 upstream 형태에서도 검증했다.

Agent 등록과 heartbeat, 14개 Collector, Evidence 8건, RCA Report, Analysis Task, Incident, topology와 서명 bundle이 생성되는 것을 확인했다. 검증 후에는 namespace, 테스트 Cluster, VM과 임시 네트워크 자원을 정리했다.

지원 완료와 탐지를 구분하기

EKS, AKS, GKE와 OpenShift는 공식 문서에 기반한 contract fixture만 구현했다. 실제 managed canary가 끝나기 전에는 지원 완료로 표시하지 않는다.

Managed 환경에는 다음처럼 일반 노드와 다른 경계가 있다.

• EKS Fargate는 DaemonSet을 실행할 수 없음
• 일부 immutable OS는 host path 접근이 제한됨
• AKS Virtual Node와 Windows node는 대상이 아님
• OpenShift는 SCC와 권한 모델이 다름

Fingerprint를 탐지하는 코드가 있다는 것과 실제 Collector가 안전하게 동작한다는 것은 다르다.

이 검증을 통해 배운 점

호환성을 높이기 위해 모든 오류를 무시하면 오히려 RCA 품질이 낮아진다. 중요한 것은 환경별 예외를 숨기는 것이 아니라 구조화하는 것이다.

수집 성공
수집 제한
권한 부족
경로 없음
실제 서비스 장애

이 상태를 구분하면 일부 Collector가 제한돼도 나머지 Evidence로 Report를 만들 수 있고, 운영자는 어떤 근거가 빠졌는지 알 수 있다.

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