Helm on ApexCaptain의 기술 블로그

k8s에 Ollama AI 서버 올려보기

Sun, 26 Oct 2025 00:00:00 +0900

들어가기 앞서

며칠 전에 “오프라인 환경에서 RAG 앱 동작시키기”라는 포스트를 올렸다.
마침 지난 금요일에 이 프로젝트가 마무리 되었는데 _{(포스팅 시간 기준으로는 이틀 전)}
대략적인 개요는 다음과 같다.

자체 인공지능 + VectorStore가 포함된 온전히 동작하는 RAG 서비스를 하나 만들어라
OS는 Windows 11 Pro이고
하드웨어는 8GB VRAM GPU가 장착된 노트북이다.
아, 그런데 이제 오프라인을 곁들인 _{(아예 와이파이 끊어버림)}

대략적인 시스템 구조

Windows, 노트북, 오프라인… 거를 타선이 없다.

그런데 결과는 의외로 잘 나와서 대표님도 만족하셨다.
그렇다고 마냥 기뻐하고 있을 수는 없다. 이런 걸 진행한 의도가 무엇인지 파악해야 한다.

듣자하니 추후 자체적인 AI 서버 도입을 희망하시는 듯 하다.
본래 예전부터 신기한 기술 나오면 눈에서 붉은 안광을 뿜으시긴 했는데,
이번엔 그게 AI인 모양이다.

고민이 깊어져 간다…

서비스를 만드는 건 그렇다 쳐도 "인공지능 인프라를 어떻게 구성해야 하는가"가 주요 과제다.
그리고 모든 이슈는 한 가지 단순한 사실로부터 시작되었다.

하드웨어 가격이 너무 비싸다

내가 회사 인프라를 관리하면서 가장 조심스러워 하는게 바로 비용 문제이다.
잘못되면 욕 먹기 제일 쉬운 분야라 눈에 불을 켜고 한 푼이라도 줄이기 위해 노력해야 한다.

인공지능을 제대로 동작시키기 위해선 고성능의 병렬 연산 장치가 필수적인데
GPU_{(그래픽 처리 장치)}건 NPU_{(신경 처리 장치)}건 이런 하드웨어들은 하나같이 무지하게 비싸다.

NPU는 나도 실물로 본 적이 없으니, GPU를 기준으로 생각해보면
데스크탑 PC 전체 가격의 심하면 50% 이상을 차지할 정도로 엄청난 몸값을 자랑한다.

모델

필요한 하드웨어 사양은 어떤 모델을 사용하는가에 따라 크게 달라진다.
마침 대표님이 눈독 들이고 있는 게 하나 있어 이를 예시로 쓰겠다.
얼마 전, 8월에 공개된 gpt-oss이다.

항목	gpt-oss-120b	gpt-oss-20b
모델 크기	120B	20B
성능	o4-mini와 매우 유사한 성능	o3-mini와 매우 유사한 성능
아키텍처	128개의 전문 모델 통합	32개의 전문 모델 통합
활성 영역	동작 시 5.1B 크기 영역 활성화	동작 시 3.6B 크기 영역 활성화
권장 VRAM	약 66GB	약 13GB
권장 하드웨어	H100 80GB 하드웨어 1대로 원활하게 동작	16GB VRAM 이상의 그래픽카드로 원활하게 동작

참고로 H100 1개당 가격은 작성일 기준 4,000만원정도 한다. 😱

노트북으로 먼저 테스트해보신 것으로 미루어 짐작하면, 여기선 gpt-oss-20b가 더욱 현실성이 있다.

상용 GPU 사용시

HuggingFace에 올라온 gpt-oss-20b의 모델 정보를 보면 16GB VRAM 이상의 그래픽 카드를 쓰면 원활하게 쓸 수 있다고 한다.

실제로는 Ollama뿐 아니라 Docling같이 보조 AI 서비스도 같이 올라갈 것으로 생각되기에,
넉넉하게 그 2배인 32GB VRAM을 생각하고 있다.

이러한 GPU는 1개당 대략 4~500만원 정도 나간다.

클라우드 사용시

AWS에서 32GB VRAM이 장착된 g5g.16xlarge 인스턴스의 작성일 기준 1달 평균 사용 비용은 다음과 같다.

온디맨드 : $2388.29

쓴 만큼 내기, 후불제, 기본가 _(최고가)
스팟 : $672.59

가장 저렴하긴 한데, 스팟을 쓰기엔 무리가 있다.

필요할 때만 잠깐 쓰는 머신러닝이나 Docling 문서 전처리 정도의 작업을 담당하는 거면 모르겠으나,
상용 서비스에는 부적합하다. _{저렴한 데는 이유가 있다.}

설마 그러겠냐만 한창 서비스중에 인스턴스가 종료되기라도 하면 인생이 아주 스펙타클 해질 것이다.
1년 예약 분할 지불 : $ 1559.73
1년 예약 일시불 : $ 1455.74
3년 예약 분할 지불: $ 1102.4
3년 예약 일시불 : $ 959.5

달러당 환율 1,400으로 계산하면 한달에 135만원이다.
3년 일시불이니 총 지출은 대략 4,800만원(!!)이다. _{그냥 H100 하나 사고 만다.}

전반적으로 보면 On-Premise 서버를 쓰는게 보다 합리적으로 보인다.
물론 클라우드에 올라가는 서버용 연산장치를 단순히 상용 GPU와 VRAM 크기가 같다고 동일선상에 두는 건 불합리하다.

더욱이 EC2의 인스턴스 타입은 CPU나 시스템 메모리 사이즈도 티셔츠마냥_{(large, x-large)} 모두 딱딱 정해진 값이다.
예시로 쓰인 g5g.16xlarge의 경우 Arm 64코어 CPU에 시스템 메모리 128GB가 적용된다.

그 비용도 포함된 가격임을 고려해봐야 한다.

클러스터 구성

앞서 H/W 가격과 이어지는 문제이다. 그렇다면 클러스터 구성을 어떻게 할 것인가?
포인트는 GPU가 포함된 Node의 위치이다.

싹 다 클라우드에 올리기 _{(상남자 스타일)}

문자 그대로의 의미이다.
대표님이 Microsoft Azure에 3년 예약 GPU 인스턴스가 저렴하다고 한 번 써보자고 하시는데…

개인적으로 가장 편한 방법이긴 하나,
GPU 사용료 비싼건 어느 클라우드를 쓰건 오십보백보라 그다지 추천하지는 않는다.
전부 IDC에서 운영

On-Premise에 모든 Node를 배치하는 방법이다.
IDC + 클라우드 — Istio 다중 클러스터 서비스 메시

클라우드에 k8s 하나, IDC에도 독립적인 On-Premise k8s 하나씩 두고 On-Premise에는 GPU Node들을 배치하는 방법이다.

이상적이긴 한데 Istio 구성이 다소 복잡해질 것으로 보인다.
EKS Hybrid Node

이건 나도 이번에 조사해보다가 알게 된 건데, AWS EKS에 외부 Node를 등록하는 방식이다.
요컨대 Control Plane은 여전히 AWS에 존재하고, Worker Node는 IDC에 둘 수 있다.

당연히 무료는 아니고, 등록한 Worker Node의 코어당 연결 시간에 비례해서 책정된다.
예를들어, 8 코어 16 쓰레드 CPU를 가지는 Node 1개를 연결하면 1달에 대략 33만원 정도가 나온다.
단순 연결하는데 쓰는 비용이 이렇다면 당장의 현실성은 없다.
그래도 이 접근방법의 개념은 되게 재밌어서 개인적으로 흥미가 많이 간다.

자세한 내용은 AWS 공식 문서를 참고해보자.

k8s에 Ollama 올려보기

고민거리를 늘어놓느라 서론이 길었는데, 결국 여태 내용 중 아직 확정된 것은 없다. _{(사실상 푸념)}
아무래도 큰 비용이 걸려있는 일이다보니 주말에 나 혼자 머리 싸맨다고 해결될 리 만무하다.

그래서 일단은 당장 할 수 있는 걸 해보기로 했다.
바로 내가 개인적으로 운영하는 On-Premise 클러스터에 Ollama 서비스를 올려보는 것이다.

사용할 GPU

이번에 고생해줄 GPU는 NVIDIA의 RTX 2080이다.

왕년에는 끗발 좀 날리던 녀석이었는데,
릴리스_{(디아블로 IV)}의 권능 앞에 무너져 새 GPU_{(RTX 4070)}에 자리를 내주고 쉬고 있었다.

그러다 몇 달 전에 Jellyfin이라는 서비스의 ffmpeg GPU 가속을 위해 싹 분해해서
먼지 청소도 해주고 써멀 패드도 갈아주고 팬도 전부 새걸로 바꿔 끼웠다.
분해 당시 부식이나 냉납도 없었다. 고로 사용하는데 지장은 없을 것이다.

대략적인 스펙은 다음과 같다.

항목	내용
NVIDIA 칩셋	RTX 2080
인터페이스	PCIe3.0×16
CUDA 프로세서	2944개
메모리 종류	GDDR6
메모리 용량	8GB

Nvidia GPU Operator 설치

Ollama에 GPU를 연결해야 하므로 Nvidia GPU Operator를 클러스터에 설치해줘야 한다.
AMD GPU를 사용한다면 AMD GPU Operator를 설치해야 하는데, 이번 포스트에서는 Nvidia를 기준으로 하겠다.

Nvidia Driver 설치

우선 GPU Node에 접속해서 Nvidia Driver부터 설치해야 한다.
OS나 CPU Architecture에 따라 방법이 천차만별인데, 일단 가장 보편적인 Ubuntu를 기준으로 하겠다.
환경별 설치 방법은 이 문서 참조.

1
2
3


sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
sudo ubuntu-drivers autoinstall

설치가 완료되면 시스템을 재부팅해준다.

1

sudo reboot

재부팅 후 다음의 명령어를 입력해보자.

1

nvidia-smi

다음과 같이 출력되면 정상이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


Mon Oct 27 01:57:28 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.195.03 Driver Version: 570.195.03 CUDA Version: 12.8 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 2080 Off | 00000000:29:00.0 Off | N/A |
| 0% 30C P8 2W / 240W | 1MiB / 8192MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+

네임스페이스 생성

1
2
3


kubectl create ns gpu-operator
kubectl label --overwrite ns gpu-operator pod-security.kubernetes.io/enforce=privileged
kubectl get ns --show-labels | grep gpu

Nvidia GPU Operator가 설치될 네임스페이스를 만든 후 네임스페이스 내 pod의 보안정책을 privileged로 설정해 GPU 접근을 허용해야 한다.

Helm Repository 추가

1
2


helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

values 설정

다음의 커맨드로 기본 차트 values 값을 가져와 로컬에 저장해보자.

1

helm show values nvidia/gpu-operator > nvidia-gpu-operator.yml

nvidia-gpu-operator.yml에 보면 여러 옵션들이 있는데, 몇 가지 수정해줘야 할 것이 있다.

Driver 설정 변경

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 위에서 이미 Nvidia Driver를 설치했으므로 제외
driver:
 enabled: false
# 이 아래 옵션은 H100 등에서만 사용 가능하다
migManager:
 enabled: false
vgpuDeviceManager:
 enabled: false
vfioManager:
 enabled: false

Toolkit 설정 변경

나는 containerd를 기본 Runtime으로 사용하고 있어서 다음과 같이 설정해주었다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


operator:
 defaultRuntime: containerd  # 기본 런타임을 containerd로 설정

toolkit:
 enabled: "true"
env:
 - name: CONTAINERD_CONFIG
 value: /etc/containerd/config.toml
 - name: CONTAINERD_SOCKET
 value: /run/containerd/containerd.sock
 - name: CONTAINERD_SET_AS_DEFAULT
 value: "1"

차트 배포

1
2
3


helm install gpu-operator nvidia/gpu-operator \
 -n gpu-operator \
 -f ./nvidia-gpu-operator.yml

Ollama 설치

Ollama도 Helm으로 설치할 수 있다.

네임스페이스 생성

1

kubectl create namespace ollama

AI 모델을 저장할 PVC 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# ollama-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: ollama-models-pvc
 namespace: ollama
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 30Gi

1

kubectl apply -f ollama-pvc.yaml

Helm Repository 추가

1
2


helm repo add ollama https://ollama.ai/kubernetes/ollama
helm repo update

values 설정

Nvidia GPU Operator와 마찬가지로 values를 가져와 살펴볼 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# ollama.yml
ollama:
 gpu:
 enabled: true # GPU 사용 여부

runtimeClassName: nvidia # nvidia runtime 사용 (Nvidia GPU Operator)

persistentVolume:
 enabled: true
 existingClaim: ollama-models-pvc

# (선택) GPU가 설치되어 있는 Node에만 파드가 스케쥴링 되도록 하기
affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: nvidia.com/gpu.present
 operator: Exists

여담으로 Helm Chart를 통해 AI Models를 관리하는 것도 가능하다.

예를 들어:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


ollama:
 models:
 pull:
 - deepseek-r1:8b # DeepSeek 모델을 다운로드
 run:
 - deepseek-r1:8b # 원하는 모델을 메모리에 상주

 # 혹은 다음과 같은 방식으로 커스텀 모델 생성도 가능
 create:
 - name: deepseek-r1-ctx32768
 template: |
 FROM deepseek-r1:8b
 PARAMETER num_ctx 32768

 clean: false # 이 값을 true로 하면 위에서 지정한 모델만 남기고 다 지운다

그런데 그다지 추천하지는 않는다.

AI 모델 변경이 의외로 자주 일어나는데 그때마다 Helm 차트를 다시 배포하는 건 꽤나 번거롭다.

차트 배포

1

helm install ollama ollama/ollama -f ollama.yml -n ollama

Open Web UI 설치

Ollama Chart는 오로지 Ollama만 설치해준다.
직접 테스트해볼 수 있게 UI도 별도 Chart로 배포했다.
기본적인 AI 인프라만 필요하다면 이 섹션은 무시해도 된다.

네임스페이스 생성

1

kubectl create namespace open-webui

환경 설정을 저장할 PVC 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# open-webui-pvc.yml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: open-webui-pvc
 namespace: open-webui
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 2Gi

1

kubectl apply -f open-webui-pvc.yaml

Helm Repository 추가

1
2


helm repo add open-webui https://open-webui.github.io/helm-charts
helm repo update

values 설정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


# open-webui-values.yml
ollama:
 enabled: false # Ollama 설치 안 함
 # 이 부분이 좀 의아할텐데 Open Web UI 차트에서는
 # 내부적으로 Ollama를 설치하는 것도 가능하다.
 # 여기에 위 Ollama 차트의 설정을 그대로 넣으면 가능하다.
 # 하지만 가급적 분리해서 배포하는 걸 추천한다.

# 자체 Ollama를 안 쓰기 때문에 UI가 연결할 Ollama의 URL을 지정해줘야 한다
# FQDN을 다 쓸 필요는 없고 http://<서비스>.<네임스페이스>:<포트>로 적으면 된다.
# 서비스와 네임스페이스는 모두 "ollama"이고 포트는 기본적으로 11434이다.
# 따라서 "http://ollama.ollama:11434"를 적어준다.
ollamaUrls:
 - http://ollama.ollama:11434

# (선택) Tika 설정
tika:
 enabled: true

# (선택) Health Check 설정
livenessProbe:
 httpGet:
 path: /health
 port: http
 failureThreshold: 1
 periodSeconds: 10

readinessProbe:
 httpGet:
 path: /health/db
 port: http
 failureThreshold: 1
 periodSeconds: 10

startupProbe:
 httpGet:
 path: /health
 port: http
 failureThreshold: 20
 periodSeconds: 5
 initialDelaySeconds: 30

# (선택) Ingress 설정
ingress:
 enabled: true
 class: nginx
 host: '<보유한 도메인 레코드, 가령 ai.example.com>'

# Persistence 설정
persistence:
 existingClaim: open-webui-pvc

차트 배포

1
2
3


helm install open-webui open-webui/open-webui \
 -f open-webui-values.yaml \
 -n open-webui

동작 테스트

ingress 설정을 해두었다면 설정한 domain으로, 별도 설정을 안 했다면
다음의 커맨드로 포트포워딩 후 localhost:8080으로 접속해보자.

1

kubectl port-forward -n open-webui svc/open-webui 8080:80

간단하게 관리자 설정을 마치고 로그인한 뒤
우측 상단의 프로필 클릭 -> 관리자 패널 -> 설정으로 들어가보자.
혹은 단순히 <Open Web UI Base URL>/admin/settings/general로 들어갈 수 있다.

굉장히 다양한 옵션이 있다.
우선 기본 동작 테스트를 해야하므로, 모델로 이동해 AI 모델 하나를 다운로드 받아보도록 하자.

Ollama.com 검색 페이지에 접속해서 원하는 모델을 찾아보자
AI 모델이 워낙 종류가 다양해서 뭐 하나 고르는 게 쉽지는 않다.
몇 가지 추천을 해보자면 다음과 같다.

하드웨어 사양과 취향에 맞춰 원하는 모델을 다운로드 받아보자.
내 경우 exaone-deep:7.8b란 모델을 다운로드 받았다.

모델 다운로드가 완료되면 간단하게 AI와 채팅해볼 수 있다.

마치며

이번 포스트에서는 Kubernetes 클러스터에 Ollama AI 서버를 구축하는 과정을 다뤄봤다.
Nvidia GPU Operator 설치부터 Ollama, Open Web UI 배포까지 전 과정을 Helm 차트를 통해 간단하게 구성할 수 있었다.

물론 실제 상용 환경에서는 앞서 언급한 비용 문제와 클러스터 구성 방식에 대한 고민이 필요하다.
특히 GPU 하드웨어의 높은 가격대와 클라우드 사용료는 여전히 큰 부담으로 남아있다.

하지만 이번 실험을 통해 얻은 경험은 향후 실제 AI 인프라 도입 시 큰 도움이 될 것 같다.
On-Premise 환경에서도 충분히 동작하는 것을 확인했으니, 비용 효율성을 고려한 하이브리드 구성도 충분히 검토해볼 만하다.

추후 계획

포스트에는 굳이 명시하지 않았는데, Ollama Chart 역시 별도의 Ingress 설정을 해주었다.

사용한 도메인 레코드는 ollama.ayteneve93.com.

OAuth2 Proxy를 보안 레이어로 감싸주고 Terraform이 랜덤하게
생성한 OAuth Bypass Key 헤더를 설정, 인증된 사용자라면 외부에서도 들어올 수 있게 환경을 마련하였다.

테스트로 설치한 Ollama지만 일단 자원을 잡아먹고는 있으니 이걸 앞으로 어떻게 활용할까도 생각해봐야 한다.

가령:

Cursor와 같은 인공지능 IDE와 연결한다거나
deepseek-coder 모델을 사용해서 코드 분석을 맡겨본다거나
llava 같은 Vision 모델을 사용해서 그림을 그리게 시킨다거나

또한 DCGM Exporter 차트를 배포해 Prometheus에서
GPU 사용량을 모니터링할 수 있도록 할 계획이다.

참고 자료

Nvidia GPU Operator 공식 문서

Ollama Kubernetes Helm Chart

Open Web UI Helm Chart

Nfs subdir external provisioner

Sat, 04 Oct 2025 00:00:00 +0900

연관 포스트

Oracle Cloud Infrastructure

문제의 시작

OCI Instance(Node)의 Boot Volume 최소값 제한

OCI Free Tier에 따르면 OKE에서 가용할 수 있는 자원은 다음과 같다.

CPU : 4개
메모리 : 24GB
블록 스토리지 : 200GB

이에 맞춰 Terraform으로 OKE 클러스터와 4개의 인스턴스를 가지는 ARM Node Pool을 생성했다.

각 Node는 1개의 CPU와 6GB의 메모리를 가진다.

스토리지의 경우 추후 PVC 생성을 위해서도 쓰이므로 최대한 작게 잡아주려고 했다.

Node에는 최소한의 용량만, 나머지 대부분은 PVC로 할당

그런데 실제로 생성된 Instance의 정보를 보니 Boot Volume이 비정상적으로 크게 만들어져 있다.

k8s Node의 역할을 하는 Oracle Instance 중 하나의 Boot Volume 정보

Boot Volume은 문자 그대로 Linux 시스템이 부팅하는데 필요한 기본 디스크로, 윈도우로 치면 C드라이브 같은 존재이다.

확인 결과, 다음과 같은 이슈가 발생했다.

Instance의 Boot Volume의 크기는 최소 47Gi (50GB) 이상 할당해줘야 한다.
당연히 이 용량은 Free Tier에서 제공되는 200GB에서 차감된다.
이러면 단순히 Node 4개를 만드는 것만으로도 Free Tier의 200GB를 다 써버리게 된다.

단 1개의 PVC도 생성할 수 없다.

Persistent Volume도 마찬가지

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: oci-bv #OCI에서 기본적으로 제공하는 Storage Class
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 100Mi 

이처럼 OKE k8s 클러스터에 pvc 하나를 만든다고 가정해보자.
oci-bv는 Oracle에서 기본적으로 제공되는 Storage class로 OCI Block Volume을 저장소로 쓴다.

약 100MB 정도의 크기를 가지는 작은 PVC이다. 그럼 실제 만들어지는 OCI Block Volume의 크기도 100MB 정도여야 하지 않을까?

어림도 없다. 여기도 크기 제약이 걸려있어서 최소 47Gi (50GB) 이상을 할당해줘야 한다.

극단적으로 Node를 1개만 쓴다고 가정해도, PVC는 3개가 한계이다. 각각 50GB씩… _{오라클, 보고 있나?}

PVC 자체도 50GB가 최소라 노드 1개 PVC 3개가 한계이다.

해결방안

NodePool의 스펙 및 수 조정

우선 Node에 50GB씩 기본 할당 되는 건 어쩔 도리가 없기 때문에 Node 수를 타협해야 한다.
클러스터로써 구색은 맞춰야 하므로 기존 4개에서 2개로 줄였다.
각각 CPU는 2개, 메모리는 12GB씩 할당해줬다.

이걸로 벌써 100GB가 날아갔다

시스템 구성 요소

NFS Subdir External Provisioner를 사용해서 별도의 StorageClass를 만들어줘야 한다.

NFS Storage, 즉 NFS 서버를 Source로 해서 StorageClass를 만들고, 해당 StorageClass를 통해 PVC를 생성하면 NFS 서버에 볼륨이 생성되고 데이터가 저장되는 구조이다.

주요 구성 요소를 배포 순서에 따라 나열하면 다음과 같다.

OCI Block Volume

앞서 Node 2개를 배치했으므로, 사용 가능한 용량 제한은 100GB이다.

남은 100GB를 모두 사용하는 OCI Block Volume 1개가 필요하다.
NFS Server

1에서 생성한 OCI Block Volume을 PVC로 매핑 받아 NFS Storage를 제공하는 서비스이다.
NFS Subdir External Provisioner

이번 포스트의 핵심으로, 2에서 생성한 NFS 서버를 Source로 StorageClass를 제공한다.
(선택) FileBrowser, SFTP Container

보다 편한 관리를 위한 것으로, 선택사항이다.
oci-bv가 제공하는 PVC는 ReadWriteOnce 모드만 제공되므로 반드시 하나의 Pod에 NFS Container와 함께 정의해줘야 한다.

사용하는 도구

Terraform: 인프라 자원 관리 (OCI 볼륨, 백업 정책)
Kubernetes Manifests: NFS 서버, File Browser, SFTP 서비스
Helm: NFS Subdir External Provisioner 설치

실제 구현은 CDKTF를 써서 하나의 Stack 파일로 구성했다.

GitHub 링크에서 확인 가능하다.

Terraform 인프라 구성

OCI 인프라 구성은 Terraform OCI Provider를 사용했다.

HCL 코드에 프로바이더를 연결하는 과정은 여기선 생략한다. (추후 별도 포스팅 예정)

OCI 블록 볼륨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# main.tf
resource "oci_core_volume" "nfs_core_volume" {
 compartment_id = var.compartment_id
 availability_domain = var.availability_domain
 size_in_gbs = 100
 display_name = "nfs-core-volume"

 lifecycle {
 prevent_destroy = true
 }
}

볼륨 백업 정책

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# backup_policy.tf
resource "oci_core_volume_backup_policy" "nfs_core_volume_backup_policy" {
 compartment_id = var.compartment_id
 display_name = "nfs-volume-backup-policy"

 schedules {
 backup_type = "INCREMENTAL"
 period = "ONE_WEEK"
 retention_seconds = 60 * 60 * 24 * 7 * 3 # 3주 보관
 day_of_week = "SUNDAY"
 hour_of_day = 2
 offset_seconds = 0
 offset_type = "STRUCTURED"
 time_zone = "REGIONAL_DATA_CENTER_TIME"
 }

 schedules {
 backup_type = "FULL"
 period = "ONE_MONTH"
 retention_seconds = 60 * 60 * 24 * 30 * 2 # 2개월 보관
 day_of_month = 1
 hour_of_day = 3
 offset_seconds = 0
 offset_type = "STRUCTURED"
 time_zone = "REGIONAL_DATA_CENTER_TIME"
 }
}

백업 스케줄:

증분(INCREMENTAL) 백업: 매주 일요일 2시, 3주 보관
전체(FULL) 백업: 매월 1일 3시, 2개월 보관

백업 정책 할당

1
2
3
4
5


# backup_policy_assignment.tf
resource "oci_core_volume_backup_policy_assignment" "nfs_core_volume_backup_policy_assignment" {
 asset_id = oci_core_volume.nfs_core_volume.id
 policy_id = oci_core_volume_backup_policy.nfs_core_volume_backup_policy.id
}

변수 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# variables.tf
variable "compartment_id" {
 description = "OCI Compartment ID"
 type = string
}

variable "availability_domain" {
 description = "OCI Availability Domain"
 type = string
}

출력값 정의

1
2
3
4
5


# outputs.tf
output "nfs_volume_id" {
 description = "NFS Core Volume OCID"
 value = oci_core_volume.nfs_core_volume.id
}

nfs_volume_id 값은 PV를 만들 때 필요하다.

변수 파일 생성

1
2
3
4


cat > terraform.tfvars << EOF
compartment_id = "< 배포할 OCI Compartment의 ID >"
availability_domain = "< AD 이름, 예시: ibHX:AP-CHUNCHEON-1-AD-1 >"
EOF

Terraform 배포

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Terraform 초기화
terraform init

# 인프라 계획 확인
terraform plan -var-file="terraform.tfvars"

# 인프라 배포
terraform apply -var-file="terraform.tfvars"

# 출력값 확인 (볼륨 ID 등)
terraform output

k8s Manifest

네임스페이스 생성

1
2
3
4
5


# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
 name: nfs-system

PersistentVolume 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# persistentvolume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-pv
 annotations:
 pv.kubernetes.io/provisioned-by: blockvolume.csi.oraclecloud.com
spec:
 storageClassName: oci-bv
 persistentVolumeReclaimPolicy: Retain
 capacity:
 storage: 100Gi
 accessModes:
 - ReadWriteOnce
 persistentVolumeSource:
 csi:
 driver: blockvolume.csi.oraclecloud.com
 volumeHandle: <OCI_VOLUME_OCID> # Terraform에서 Output 된 Volume ID값을 넣어준다.
 # ocid1.volume.oc1 어쩌구 하는 값이다. Web Console에서 복사해서 가져와도 된다.
 fsType: ext4
 nodeAffinity:
 required:
 nodeSelectorTerms:
 - matchExpressions:
 - key: failure-domain.beta.kubernetes.io/zone
 operator: In
 values:
 - <AVAILABILITY_DOMAIN>

PersistentVolumeClaim 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# persistentvolumeclaim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-pvc
 namespace: nfs-system
spec:
 volumeName: nfs-pv # 위에서 생성한 PV의 이름이다
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 100Gi
 storageClassName: oci-bv

ConfigMap (Pod의 SFTP 컨테이너용 SSH 키 관리, 선택사항)

1
2
3
4
5
6
7
8
9


# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: nfs-system-sftp-config
 namespace: nfs-system
data:
 ssh-public-key: |
 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ... # SSH 공개키

Service 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# service.yaml
apiVersion: v1
kind: Service
metadata:
 name: nfs-service
 namespace: nfs-system
spec:
 selector:
 app: nfs
 ports:
 - name: nfs
 port: 2049
 targetPort: 2049
 protocol: TCP
 # -- 선택 사항 -- #
 - name: file-browser
 port: 8080
 targetPort: 8080
 protocol: TCP
 - name: sftp
 port: 22
 targetPort: 22
 protocol: TCP

Deployment 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113


# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nfs-deployment
 namespace: nfs-system
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nfs
 template:
 metadata:
 labels:
 app: nfs
 spec:
 # FileBrowser를 안 쓸 거라면 initContainers는 필요 없음 
 initContainers:
 - name: init-filebrowser-db
 image: busybox:1.35
 command:
 - /bin/sh
 - -c
 - |
 mkdir -p /exports/fb-database
 chown -R 1000:1000 /exports/fb-database
 chmod -R 755 /exports/fb-database
 volumeMounts:
 - name: nfs-storage
 mountPath: /exports

 containers:
 # NFS 서버 컨테이너 (핵심!!)
 - name: nfs-server
 image: itsthenetwork/nfs-server-alpine:latest-arm
 imagePullPolicy: Always
 ports:
 - containerPort: 2049
 protocol: TCP
 securityContext:
 capabilities:
 add:
 - SYS_ADMIN
 - SETPCAP
 command:
 - /bin/sh
 - -c
 - |
 mkdir -p /exports/services
 /usr/bin/nfsd.sh
 volumeMounts:
 - name: nfs-storage
 mountPath: /exports
 env:
 - name: SHARED_DIRECTORY
 value: /exports
 - name: SHARED_DIRECTORY_2
 value: /exports/services

 # File Browser 컨테이너(선택)
 - name: file-browser
 image: filebrowser/filebrowser
 imagePullPolicy: Always
 ports:
 - containerPort: 8080
 protocol: TCP
 securityContext:
 runAsUser: 1000
 runAsGroup: 1000
 fsGroup: 1000
 volumeMounts:
 - name: nfs-storage
 mountPath: /database
 subPath: fb-database
 - name: nfs-storage
 mountPath: /srv
 subPath: services
 env:
 - name: FB_NOAUTH
 value: 'true'
 - name: FB_DATABASE
 value: /database/database.db
 - name: FB_PORT
 value: '8080'

 # SFTP 컨테이너(선택)
 - name: sftp-server
 image: jmcombs/sftp
 imagePullPolicy: Always
 command:
 - sh
 - -c
 - |
 chmod o+w /home/sftpuser/data
 /entrypoint sftpuser::::data
 ports:
 - containerPort: 22
 protocol: TCP
 volumeMounts:
 - name: ssh-keys
 mountPath: /home/sftpuser/.ssh/keys
 readOnly: true
 - name: nfs-storage
 mountPath: /home/sftpuser/data
 subPath: services

 volumes:
 - name: nfs-storage
 persistentVolumeClaim:
 claimName: nfs-pvc
 - name: ssh-keys
 configMap:
 name: nfs-system-sftp-config

컨테이너별 역할

NFS 서버: Alpine 기반 NFS 서버로 /exports 디렉토리 공유
File Browser: 웹 기반 파일 관리 인터페이스 제공 (선택)
SFTP 서버: SSH 키 기반 파일 전송 서비스 (선택)

FileBrowser Ingress 구성 (선택)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: nfs-ingress
 namespace: nfs-system
 annotations:
 nginx.ingress.kubernetes.io/backend-protocol: HTTP
 nginx.ingress.kubernetes.io/rewrite-target: /
spec:
 ingressClassName: nginx
 rules:
 - host: files.example.com # 소유한 도메인으로 변경 
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: nfs-service
 port:
 number: 8080

k8s 리소스 배포

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 네임스페이스 생성
kubectl apply -f namespace.yaml

# ConfigMap 생성
kubectl apply -f configmap.yaml

# PersistentVolume 생성
kubectl apply -f persistentvolume.yaml

# PersistentVolumeClaim 생성
kubectl apply -f persistentvolumeclaim.yaml

# Service 생성
kubectl apply -f service.yaml

# Deployment 생성
kubectl apply -f deployment.yaml

# Ingress 생성 (선택)
kubectl apply -f ingress.yaml

Helm

Helm 저장소 추가

1
2


helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm repo update

NFS Subdir External Provisioner Values 파일

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


nfs:
 # NFS 서버 서비스 주소
 # 위 k8s manifest에서 생성한 nfs service의 k8s service dns를 사용했다.
 server: 'nfs-service.nfs-system.svc.cluster.local'
 path: '/services' # 공유 경로

# StorageClass 설정
storageClass:
 # StorageClass 이름은 본인이 원하는대로 사용하면 된다
 storageClassName: 'nfs-client'

 accessModes: 'ReadWriteMany'
 # PVC 할당 시 Storage에 저장 될 경로 패턴을 의미한다.
 # 예시의 경우 ./pvc/<네임스페이스 명>/<PVC 명>으로 저장된다.
 pathPattern: '.pvc/${.PVC.namespace}/${.PVC.name}'

보다 구체적인 Values 설정은 다음의 링크를 참조하길 바란다.

Helm Chart 배포

1
2
3
4
5
6
7
8


helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
 --namespace nfs-system \
 --values values.yaml \
 --wait

# 설치 상태 확인
helm list -n nfs-system
helm status nfs-subdir-external-provisioner -n nfs-system

검증 및 테스트

리소스 상태 확인

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Pod 상태 확인
kubectl get pods -n nfs-system

# Service 확인
kubectl get svc -n nfs-system

# PVC 상태 확인
kubectl get pvc -n nfs-system

# StorageClass 확인
kubectl get storageclass

마치며

이제 다른 네임스페이스에서 PVC를 생성해보자.

FileBrowser와 ingress까지 설정했다면 웹상으로 접근해서 확인할 수 있다.

ingress가 별도로 없다면 다음 명령어로 포트포워딩해서 localhost:8080으로 접근해보자.

1

kubectl port-forward --address localhost -n nfs-system svc/nfs-service 8080:8080

PVC가 지정된 경로 (.pvc/namespace/pvc-name)에 생성됨을 알 수 있다.

추후 계획

현재 k8s 클러스터에 Vault가 배포되어 있는데, Node의 수가 2개뿐이라 HA (High-Availability) 구성이 안 되고 있다. (최소 3개 이상 필요)

NFS Provisioner는 외부에 존재하는 NFS Storage를 사용할 수도 있으므로, NAS용 컴퓨터 한 대를 구매해서 NFS 서버를 구축한 뒤 NFS Provisioner의 Source로 활용할 예정이다.

이는 또 다른 클러스터인 On-Premise에도 적용될 예정이다. On-Premise 클러스터는 Longhorn을 설치해서 PVC를 제공하고 있는데, 이래저래 마음에 안 드는 구석이 많아 심플하게 외부 NAS로 통합하려고 한다.

Longhorn에 대해서는 조만간 포스팅할 예정이다.

On-Premise k8s에 Metallb 설치

Mon, 29 Sep 2025 00:00:00 +0900

들어가기 앞서

회사와 무관하게 개인적으로 관리하는 k8s 클러스터는 다음과 같다.
- 클라우드: OKE(EKS/GKE와 유사)처럼 기본 L4/L7 Load Balancer 제공
- 온프레미스: 집에서 운영하는 싱글 노드로 시작한 k8s, 리소스 집약적 워크로드 배치(Jellyfin, 7 Days To Die, Ollama, QBittorrent 등)
Jellyfin같은 앱은 클라우드에 설치하기엔 자원 소모량이 너무 크다.
- 내부망 대역: 93.5.22.0/24
- 초기 Worker Node: 93.5.22.44
- 공유기 포트포워딩: 외부 80/443 → 93.5.22.44:80/443, 클러스터 내 Nginx Ingress Controller가 도메인 기반 라우팅
로드밸런서란?
- 트래픽을 여러 노드/파드로 분산하고, 가상 IP(VIP)를 통해 단일 진입점을 제공
- 하드웨어 전용 장비도 있으나, 온프레미스 k8s에서는 소프트웨어 방식이 일반적
- Bare Metal 환경에서는 Metallb가 사실상 표준 솔루션
Metallb 핵심 개념
- 데몬셋 speaker가 호스트 네트워크로 동작하며 외부 IP를 네트워크에 광고
- LoadBalancer 서비스의 External IP 전파에 표준 프로토콜 사용: ARP(IPv4), NDP(IPv6), BGP
- 두 가지 모드
  - L2(ARP/NDP): 같은 서브넷에서 VIP를 광고 — 가정/소규모 환경에 적합
  - BGP: 라우터와 경로를 교환 — 데이터센터/고급 네트워크에 적합
- 관련 개념
  - GARP(Gratuitous ARP): 자신의 IP-MAC 정보를 네트워크에 알리는 ARP, VIP 전환 시 필수
  - Strict ARP: 노드가 소유하지 않은 IP에 응답하지 않도록 제한, L2 모드와 IPVS에서 안전성 향상

문제의 시작

초기에는 단일 노드(93.5.22.44)로 포워딩하면 충분했지만, 노드가 추가되면 단일 대상 포워딩만으로는 고가용성/확장성 확보 불가
이런 상황이라면 공유기는 대체 어느 Node로 포워딩을 해야하는가?
Kubernetes의 LoadBalancer 타입이 클라우드 밖에서는 기본 제공되지 않아, 외부에서 접근 가능한 VIP가 부재
결과적으로, 인입 트래픽을 안정적으로 받아 서비스로 라우팅할 수 있는 소프트웨어 로드밸런서가 필요

해결방안 — Metallb(L2 모드) 도입

같은 서브넷(93.5.22.0/24)에서 VIP를 광고하는 L2 모드로 간단하게 시작
예시 VIP: 93.5.22.100 (공유기 포트포워딩은 이 VIP로 설정)

설치(Helm)

1
2
3
4


helm repo add metallb https://metallb.github.io/metallb
helm repo update
kubectl create namespace metallb-system
helm upgrade --install metallb metallb/metallb -n metallb-system --wait

설치 후 CRD 확인:

1

kubectl get crd | grep metallb.io

다음과 같이 출력되면 정상이다.

1
2
3
4
5
6
7
8


bfdprofiles.metallb.io 2025-08-03T16:07:22Z
bgpadvertisements.metallb.io 2025-08-03T16:07:22Z
bgppeers.metallb.io 2025-08-03T16:07:22Z
communities.metallb.io 2025-08-03T16:07:22Z
ipaddresspools.metallb.io 2025-08-03T16:07:22Z
l2advertisements.metallb.io 2025-08-03T16:07:22Z
servicebgpstatuses.metallb.io 2025-08-03T16:07:22Z
servicel2statuses.metallb.io 2025-08-03T16:07:22Z

이중 IPAddressPool과 L2Advertisement CRD를 Manifest로 생성 해줘야 한다.
- IPAddressPool: Metallb이 할당할 수 있는 IP 주소(VIP) 풀이다.
- L2Advertisement: Layer2 광고 정의. L2 모드에서 Metallb이 IP 주소를 어떻게 광고하는가를 설정한다.

IP 풀/광고 리소스 생성

ipaddresspool.yaml:

1
2
3
4
5
6
7
8


apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
 name: workstation-ip-pool
 namespace: metallb-system
spec:
 addresses:
 - 93.5.22.100

Note: addresses는 범위로 지정할 수도 있다. 예를들면 192.168.0.100-192.168.0.104

적용:

1

kubectl apply -f ipaddresspool.yaml

l2advertisement.yaml:

1
2
3
4
5
6
7
8


apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
 name: workstation-l2adv
 namespace: metallb-system
spec:
 ipAddressPools:
 - workstation-ip-pool

적용:

1

kubectl apply -f l2advertisement.yaml

동작 확인 체크리스트

1
2
3
4
5
6
7
8


# 컨트롤러/스피커 파드 상태
kubectl get pods -n metallb-system -o wide

# 풀/광고 리소스 상태
kubectl get ipaddresspools.metallb.io,l2advertisements.metallb.io -n metallb-system

# LoadBalancer 서비스의 외부 IP 할당 여부
kubectl get svc -A | grep LoadBalancer || true

공유기 포트포워딩

외부 80/443 → VIP 93.5.22.100:80/443로 설정

참고(안전한 네트워킹을 위해)

Strict ARP를 활성화하면, 노드가 소유하지 않은 IP에 응답하지 않아 ARP 오류를 방지
kube-proxy IPVS 모드 사용 시에도 Strict ARP는 중요
BGP 모드는 외부 라우터와의 동적 라우팅이 필요할 때 선택
추가로 Nginx Ingress Controller가 VIP로 들어온 요청을 각 서비스로 라우팅하도록 설정했다

마무리

온프레미스 k8s에서 Metallb는 외부 트래픽을 받는 가장 간단하고 표준적인 방법이다. 같은 서브넷에서는 L2 모드만으로도 VIP를 안전하게 광고하여, 노드 수가 늘어나도 일관된 진입점을 유지할 수 있다.