adr k3s vs greengrass

ADR - K3s vs Greengrass

메타데이터	값
상태	accepted
결정일	2026-05-09 (통합 아키텍처 기준 문서화일)
현재 유효 여부	유효
Superseded 관계	없음. Greengrass는 재검토 가능한 미래 대안
구현 근거	charts/aegis-spoke/, `envs/factory-a
검증 근거	docs/ops/09_failover_failback_test_results.md, factory-b/c testbed 운영 문서

Wiki ADR 파일명은 유지한다. 숫자 prefix가 있는 통합 변경 기록의 충돌은 docs/changes/README.md와 파일명별 이력으로 식별한다.

---

결정

Factory Spoke의 workload runtime과 배포 단위는 AWS IoT Greengrass가 아니라 K3s + Helm + ArgoCD로 유지한다.

adapter/generator + edge-iot-publisher
  -> K3s workload
  -> AWS IoT Core

IoT Core 연동을 위해 Greengrass runtime을 추가하지 않는다.

---

배경과 대안

Factory A는 Raspberry Pi 3-node K3s에서 scheduler, affinity/toleration, Longhorn, failover/failback을 이미 검증했다. Greengrass를 동시에 도입하면 Pod/Helm/ArgoCD와 Component/Greengrass Deployment라는 두 운영 모델을 관리해야 한다.

기준	K3s	Greengrass
기존 workload/Helm 재사용	높음	재설계 필요
Hub ArgoCD GitOps	현재 구현	별도 deployment model 필요
노드 장애 재스케줄	현재 검증	component lifecycle로 재설계
IoT Core publish	publisher Pod가 담당	기본 통합 강점
오프라인/fleet 기능	직접 구현 필요	강점

---

결과

• Factory A/B/C는 K3s Spoke다.
• 공장별 adapter/generator와 공통 publisher를 분리한다.
• Hub ArgoCD가 Tailscale을 통해 GitOps를 관리한다.
• Greengrass는 장시간 오프라인 버퍼링이나 fleet component 관리가 실제 요구가 될 때 별도 ADR로 재평가한다.

이 결정은 K3s 전체가 고가용이라는 뜻이 아니다. Factory A의 특정 workload failover만 실측되었고, snapshot uploader 같은 단일 worker2 구성은 별도 제약을 가진다.