ADR 0001: 병원 현장 dgx-spark Kubernetes 클러스터에 RKE2 사용¶

1. 상태¶

Accepted

2. 결정 요약¶

dgx-spark에 설치할 병원 현장 workload cluster의 Kubernetes distribution으로 RKE2를 사용한다.

기존 k3s cluster는 Argo CD를 실행하는 management/bootstrap cluster로 유지한다. dgx-spark의 RKE2 cluster는 Argo CD가 배포 대상으로 등록하고 관리하는 workload cluster로 둔다.

GPU node라는 성격은 디렉터리 구조로 나누지 않고, Kubernetes node labels와 taints 같은 metadata로 표현한다. GPU enablement는 RKE2 bootstrap 이후 별도 결정으로 다룬다.

Kubernetes container runtime은 RKE2가 관리하는 containerd로 단일화한다. DGX Spark에 Docker나 NVIDIA Container Runtime이 이미 설치되어 있더라도, RKE2 kubelet이 사용할 runtime 경로와 host-local container 실행 경로를 섞지 않는다.

CNI는 Cilium을 우선 후보로 검토한다. 병원 현장 cluster에서는 단순 Pod networking뿐 아니라 network policy, 관찰 가능성, 향후 eBPF 기반 기능을 고려해야 하기 때문이다.

3. 배경¶

tirosh-home은 현재 단일 VM 위의 k3s cluster를 사용해 Argo CD를 bootstrap한다. 이 cluster의 목적은 가볍고 빠르게 GitOps control plane을 준비하는 것이다.

다음 단계의 dgx-spark는 성격이 다르다. dgx-spark는 GPU-capable machine이지만, 이 결정에서 더 중요한 점은 이 장비가 병원 현장 내부망에 설치될 Kubernetes workload cluster의 시작점이라는 것이다. 즉 단순 실험용 node가 아니라, 향후 병원 환경에서 AI/ML workload를 실행할 수 있는 운영 대상이다.

따라서 Kubernetes distribution 선택 기준도 "가볍게 설치되는가"보다 "병원 현장에서 통제 가능하게 운영할 수 있는가"에 더 가깝다.

기존 cluster와 새 cluster의 역할은 다음처럼 분리한다.

argocd의 k3s cluster: Argo CD를 위한 management/bootstrap cluster
dgx-spark의 RKE2 cluster: 병원 현장 workload cluster
Argo CD: RKE2 cluster를 등록하고 배포 대상으로 사용
GPU enablement: Kubernetes bootstrap 이후 별도 platform add-on으로 구성

4. 선택 기준¶

이 결정에서 중요하게 본 기준은 다음과 같다.

병원 현장 운영에 필요한 보안성과 통제성
재설치, 업그레이드, 장애 대응이 가능한 운영 모델
설치와 설정 변경 이력을 Ansible, Make target, site vars로 남길 수 있는 감사 가능성
Argo CD가 일반 Kubernetes cluster로 등록하고 관리할 수 있는 호환성
Kubernetes container runtime 경계가 명확한 구조
병원 내부망에서 traffic visibility와 policy enforcement를 확장할 수 있는 CNI
향후 NVIDIA runtime, GPU Operator, monitoring, workload scheduling을 얹을 수 있는 확장성
현재 저장소의 site 중심 운영 모델과 충돌하지 않는 단순한 구조

5. 결정¶

dgx-spark에는 RKE2 기반 Kubernetes cluster를 설치한다.

site 구조는 지금 단계에서 단순하게 유지한다.

sites/
  tirosh-home/
    rke2/
      vars.yml
      kubeconfig.yml

장비 모델명은 cluster name이나 inventory alias에 직접 반영하지 않는다. 제조사가 다른 GPU node가 추가될 수 있으므로 운영 alias는 gpu-01, gpu-02처럼 역할 중심으로 부여하고, 모델명은 inventory metadata와 Kubernetes node label로 표현한다.

tirosh-home/rke2/gpu

예상 변수 형태는 다음과 같다.

rke2_cluster_name: gpu
rke2_target_name: gpu-01
rke2_context_name: tirosh-home/rke2/gpu

rke2_node_labels:
  - node.tirosh.ai/role=gpu
  - node.tirosh.ai/workload=ai
  - node.tirosh.ai/model=dgx-spark
  - nvidia.com/gpu.present=true

rke2_node_taints: []

아직 sites/tirosh-home/rke2/gpu/ 같은 중첩 경로는 만들지 않는다. 현재 RKE2 cluster는 하나뿐이고, GPU 여부는 cluster directory를 나눌 이유라기보다 node attribute에 가깝다. RKE2 cluster가 여러 개로 늘어나면 그때 cluster별 directory 구조를 다시 검토한다.

5-1. Container runtime 경계¶

RKE2 cluster의 Kubernetes runtime은 RKE2가 관리하는 containerd로 단일화한다.

DGX Spark에는 NVIDIA driver, NVIDIA Container Toolkit, Docker integration, NVIDIA Container Runtime 등이 이미 준비되어 있을 수 있다. 이것은 host-local container 실행이나 DGX OS 기본 사용성에는 유용하지만, RKE2 kubelet이 사용할 Kubernetes CRI runtime과 섞어서는 안 된다.

운영 원칙은 다음과 같다.

RKE2는 자체 containerd를 기준으로 설치하고 운영한다.
Kubernetes workload는 RKE2 containerd 경로에서 실행한다.
Docker daemon은 Kubernetes runtime으로 사용하지 않는다.
Ansible playbook은 별도의 containerd를 추가 설치하거나 Docker runtime을 kubelet에 연결하지 않는다.
GPU enablement는 RKE2 containerd에 맞는 Kubernetes add-on 흐름으로 검증한다.

이 원칙을 두는 이유는 runtime이 중복되면 장애 지점이 늘어나고, GPU가 어느 runtime에 연결되어 있는지 추적하기 어려워지기 때문이다. 병원 현장에서는 이런 모호성이 장애 대응과 감사 가능성을 떨어뜨린다.

5-2. CNI 방향: Cilium 우선 검토¶

CNI는 Cilium을 우선 후보로 검토한다.

RKE2의 기본 CNI는 Canal이지만, RKE2는 Canal, Cilium, Calico, Flannel을 bundled CNI로 제공하고 cni 설정으로 선택할 수 있다. dgx-spark는 병원 현장 workload cluster이므로 단순 Pod networking만이 아니라 network policy, traffic visibility, 향후 보안 정책 확장을 고려해야 한다.

Cilium을 우선 검토하는 이유는 다음과 같다.

eBPF 기반 datapath를 통해 Kubernetes networking, security, observability를 같은 계열의 도구로 다룰 수 있다.
Cilium Network Policy와 Cilium Clusterwide Network Policy를 통해 Kubernetes NetworkPolicy보다 세밀한 정책 확장 여지를 가진다.
Hubble을 통해 service map, flow visibility, DNS-aware filtering 같은 network observability를 제공할 수 있다.
병원 내부망에서 workload 간 통신 흐름을 설명하고 문제를 추적하기 쉬워진다.
향후 kube-proxy replacement, WireGuard encryption, advanced load balancing 같은 기능을 검토할 수 있다.

다만 Cilium의 고급 기능을 처음부터 모두 켜지는 않는다. 첫 구현에서는 RKE2 cluster bootstrap 안정성을 우선하고, Cilium 사용 여부와 최소 설정을 sites/tirosh-home/rke2/vars.yml에 명시한다. kube-proxy replacement, Hubble UI, WireGuard encryption 등은 kernel version, 병원 네트워크 정책, 운영 복잡도를 확인한 뒤 단계적으로 켠다.

초기 설정 후보는 다음과 같다.

rke2_cni: cilium
rke2_disable_kube_proxy: false

rke2_cilium:
  hubble_enabled: false
  kube_proxy_replacement: false
  wireguard_enabled: false

최종 적용 형태는 RKE2의 config.yaml과 rke2-cilium HelmChartConfig로 표현한다.

6. RKE2를 선택한 이유¶

RKE2를 선택한 가장 큰 이유는 dgx-spark가 병원 현장에 설치될 workload cluster이기 때문이다.

GPU 자체가 RKE2 선택의 주된 이유는 아니다. GPU workload는 NVIDIA driver, NVIDIA container runtime, NVIDIA GPU Operator, device plugin 같은 후속 구성으로 가능해진다. RKE2는 그 위에 올라갈 Kubernetes 기반을 더 운영 친화적으로 제공하기 때문에 선택한다.

6-1. 병원 현장 운영 적합성¶

병원 내부망에 설치되는 cluster는 실험용 cluster보다 보수적인 운영 기준이 필요하다. 구성 파일, systemd service, kubeconfig, API endpoint, node metadata를 명시적으로 관리할 수 있어야 하고, 장애 상황에서 확인해야 할 지점도 분명해야 한다.

RKE2는 rke2 server, rke2 agent, systemd service, config file 중심의 운영 모델을 제공한다. 이 구조는 Ansible로 설치와 상태 확인을 자동화하기 좋고, 병원별 설치 상태를 site vars로 남기기에도 적합하다.

6-2. 보안 기준선¶

RKE2는 보안을 중요한 설계 기준으로 둔 Kubernetes distribution이다. production installation을 위한 hardening guide를 제공하고, Kubernetes CIS control을 기준으로 cluster를 강화하는 흐름을 문서화한다.

병원 환경에서는 초기 설치 기준선이 명확한 것이 중요하다. 지금 당장 모든 hardening option을 켜지 않더라도, 나중에 병원별 요구 수준에 맞춰 CIS profile, node-level security option, kube-apiserver 설정 등을 site vars와 playbook에 반영할 수 있어야 한다.

6-3. 감사 가능성¶

이 저장소는 인프라 변경을 Make target, Ansible playbook, site vars로 표현한다. RKE2도 같은 방식으로 설치와 설정을 코드화하면 병원별 설치 상태, 설정 변경, 운영 의도를 추적하기 쉽다.

특히 병원 현장에서는 "누가 어떤 명령을 실행했는가"보다 "어떤 선언적 설정을 기준으로 설치됐는가"가 더 중요해질 수 있다. RKE2의 config file 중심 운영 방식은 이 저장소의 운영 모델과 잘 맞는다.

6-4. k3s와의 역할 분리¶

k3s는 Argo CD bootstrap에 적합하다. 빠르게 설치할 수 있고 단일 VM 위에서 management cluster 역할을 수행하기에 충분하다.

하지만 dgx-spark까지 k3s로 구성하면 management cluster와 workload cluster의 경계가 흐려진다. dgx-spark는 Argo CD가 바라볼 배포 대상이므로, RKE2를 사용해 workload cluster family로 분리하는 편이 역할과 책임이 더 명확하다.

6-5. 확장 경로¶

시작은 single-node일 수 있다. 그러나 병원 현장 cluster는 시간이 지나며 node 추가, upgrade policy, monitoring, backup, GPU workload scheduling 같은 요구가 생길 수 있다.

RKE2는 k3s보다 무겁지만, 이런 운영 요구를 수용하기 위한 명시적 구성 표면을 제공한다. 이 점은 작은 bootstrap cluster보다 workload cluster에 더 잘 맞는다.

6-6. GPU 구성과의 관계¶

RKE2가 GPU workload를 자동으로 해결해주는 것은 아니다. GPU 사용을 위해서는 NVIDIA driver, NVIDIA container runtime, NVIDIA GPU Operator, device plugin, workload toleration 등이 별도로 필요하다.

이 ADR의 결정은 "GPU 구성을 RKE2로 해결한다"가 아니다. "병원 현장 workload cluster의 Kubernetes 기반으로 RKE2를 선택하고, GPU enablement는 Kubernetes 표준 방식으로 그 위에 얹는다"가 정확한 의미다.

DGX Spark의 host OS에 NVIDIA Container Toolkit이 준비되어 있더라도, Kubernetes workload는 RKE2 containerd와의 연동을 기준으로 검증해야 한다. NVIDIA GPU Operator를 기본 GPU enablement 방식으로 선택한 결정은 ADR 0002에서 다룬다.

7. RKE2의 특징¶

RKE2를 선택한 이유는 단순히 "k3s보다 무거운 Kubernetes"라서가 아니다. 병원 현장에 설치될 cluster에 필요한 보안, 통제, 감사 가능성을 Kubernetes distribution 차원에서 더 잘 제공하기 때문이다.

Hardened by default
RKE2는 production installation을 위한 hardening guide를 제공하고, 기본 설치 상태에서도 Kubernetes CIS control의 상당 부분을 만족하도록 설계되어 있다.
CIS profile과 hardening 문서화
RKE2는 CIS benchmark를 기준으로 cluster를 강화하는 절차를 문서화한다. 이 저장소의 Ansible playbook과 site vars에 hardening 설정을 반영하면 병원별 설치 상태를 재현 가능하게 유지할 수 있다.
FIPS 지원 경로
RKE2는 FIPS validated cryptographic libraries를 사용하는 배포 경로를 제공한다. 지금 당장 모든 병원 설치에서 FIPS mode를 요구하지 않더라도, 의료기관이나 공공 성격의 배포에서 보안 요구가 강화될 때 선택지를 남길 수 있다.
Hardened images
RKE2는 취약점 스캔과 hardened minimal base image를 전제로 한 hardened image 흐름을 제공한다. 병원 내부망에서는 image provenance와 취약점 대응 근거가 중요해질 수 있으므로, 이 특성은 운영 문서와 audit trail에 도움이 된다.
containerd 기반 운영
RKE2는 Docker daemon에 의존하지 않고 containerd 기반으로 Kubernetes node를 운영한다. GPU runtime 연동도 Kubernetes/containerd 경로에서 다루게 되므로, 후속 NVIDIA runtime 구성과 방향이 맞다.
SELinux와 node-level 보안 옵션
RKE2는 containerd에서 SELinux를 활성화하는 옵션 등 node-level 보안 구성을 제공한다. 병원별 OS baseline이 강화될 경우, 이러한 설정을 site vars로 명시할 수 있다.
명시적인 server/agent 운영 모델
RKE2는 rke2 server, rke2 agent, systemd service, config file 중심의 운영 모델을 제공한다. 이 구조는 설치 자동화와 장애 대응 문서화에 유리하다.
Cilium을 bundled CNI로 선택 가능
RKE2는 Cilium을 bundled CNI 중 하나로 제공한다. Cilium은 eBPF 기반 networking, policy, observability를 제공하므로 병원 현장 workload cluster의 traffic visibility와 policy enforcement 요구를 단계적으로 수용하기 좋다.

8. 대안¶

8-1. k3s¶

k3s는 이미 Argo CD management cluster에 사용 중이고 운영이 단순하다. 가볍고 빠르게 설치할 수 있어 bootstrap cluster에는 잘 맞는다.

하지만 dgx-spark까지 k3s로 가면 management cluster와 workload cluster의 경계가 흐려진다. 병원 현장 workload cluster에는 조금 더 명시적인 운영 모델을 갖는 RKE2가 더 적합하다고 판단했다.

결정: dgx-spark에는 사용하지 않고, Argo CD bootstrap 용도로 유지한다.

8-2. kubeadm¶

kubeadm은 upstream Kubernetes에 가깝고 널리 알려져 있다.

하지만 이 저장소 입장에서는 package lifecycle, container runtime, kubelet, upgrade, kubeconfig, service management를 더 많이 직접 결정해야 한다. 병원 현장 자동화의 첫 단계에서는 RKE2처럼 패키징된 운영 모델이 더 적합하다.

결정: 지금 단계에서는 사용하지 않는다.

8-3. MicroK8s¶

MicroK8s는 local 또는 작은 single-node cluster에 편리하다.

하지만 이 저장소에는 이미 lightweight bootstrap 용도로 k3s가 있다. 또 다른 lightweight distribution을 추가하면 운영 선택지가 늘어나는 대신 역할 경계가 흐려진다.

결정: 사용하지 않는다.

9. 결과¶

긍정적 영향:

병원 현장 workload cluster라는 의도가 명확해진다.
k3s management cluster와 RKE2 workload cluster의 역할이 분리된다.
RKE2 install/status/kubeconfig target을 k3s와 비슷한 UX로 만들 수 있다.
Argo CD cluster registration 흐름을 명확하게 추가할 수 있다.
Kubernetes runtime을 RKE2 containerd로 단일화하여 장애 지점과 운영 모호성을 줄인다.
Cilium을 통해 병원 내부망 workload traffic에 대한 policy와 observability 확장 경로를 확보한다.
GPU 구성은 후속 단계로 분리하면서도, labels/taints로 node 성격을 먼저 표현할 수 있다.
향후 보안 요구가 강화될 때 CIS profile, FIPS, SELinux 같은 RKE2 특성을 검토할 수 있다.

부정적 영향:

RKE2는 k3s보다 무겁다.
설정 표면이 더 넓어서 playbook과 vars 설계가 더 중요하다.
k3s playbook을 그대로 재사용하기보다는 RKE2 전용 Ansible/Make 흐름이 필요하다.
Cilium을 선택하면 Canal/Flannel보다 검토해야 할 kernel, HelmChartConfig, observability 설정이 늘어난다.
RKE2의 보안 기능을 실제로 활용하려면 병원별 OS baseline, network policy, image policy도 함께 정리해야 한다.

중립적 영향:

RKE2를 선택해도 NVIDIA driver/runtime/operator 작업은 별도로 필요하다.
지금은 single-node로 시작하지만, HA나 multi-node는 이 ADR의 직접 범위가 아니다.
병원별 네트워크, DNS, 인증서, 방화벽 정책은 site vars에서 별도로 다뤄야 한다.
Cilium의 kube-proxy replacement, Hubble, WireGuard는 초기 bootstrap 범위가 아니라 단계적 enablement 대상이다.

10. 후속 작업¶

sites/tirosh-home/rke2/vars.yml을 추가한다.
RKE2 install, status, kubeconfig fetch를 위한 Ansible playbook을 추가한다.
make rke2/* target을 추가한다.
RKE2 containerd를 Kubernetes runtime 기준으로 고정하고, host-local Docker/NVIDIA runtime과 섞이지 않도록 검증한다.
Cilium CNI 적용 여부와 초기 HelmChartConfig 값을 sites/tirosh-home/rke2/vars.yml에 표현한다.
Argo CD cluster registration target을 추가한다.
tirosh-home/rke2/gpu cluster를 Argo CD에 등록한다.
NVIDIA GPU Operator, runtime configuration, GPU workload validation은 ADR 0002와 후속 작업에서 다룬다.