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

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

같은 containerd를 써도 RKE2, K3s, kubeadm의 socket, systemd unit, CNI와 로그 경로는 달랐다. Node Agent가 환경에 맞는 경로를 선택하는지 확인할 필요가 있었다.

다음 환경에서 검증했다.

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

환경 차이로 수집하지 못한 정보를 서비스 장애로 오판하는지 확인하려고 했다.

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라면 Agent의 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가 잘못 실패할 수 있었다.

실제 경로 후보를 탐지하고 선택한 source를 Evidence metadata에 남겼다. systemd와 kubelet 정보도 사용할 수 있는 file fallback을 구분했다.

kubeadm 환경을 별도로 만든 이유

격리된 Ubuntu VM에는 kubeadm, containerd, Flannel을 구성했다. RKE2와 K3s의 편의 기능에 의존한 부분이 있는지 확인하려는 시험이었다.

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와 권한 모델이 다름

환경을 탐지하는 코드와 그 환경에서 Collector를 검증한 기록을 나눠 관리했다.

이 검증을 통해 배운 점

환경별 오류를 모두 무시하면 빠진 근거를 알 수 없다. 수집 결과에 다음 상태를 구분해 남기도록 했다.

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

일부 Collector가 제한돼도 나머지 Evidence로 Report를 만들 수 있고, 어느 근거가 빠졌는지도 확인할 수 있도록 했다.

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