CFM Operator 로 NiFi 를 쿠버네티스에 올릴 때 노드 사양을 어떻게 잡고 저장소를 어떻게 나눌지 정리한다. 설치 절차와 CRD 문제는 CFM Kubernetes Operator 설치와 NiFi 배포 에 있다.
3노드 NiFi 클러스터를 기준으로 한 값이다.
| 항목 | 최소 | 권장 |
|---|---|---|
| NiFi 노드당 CPU | 4 vCPU | 8 vCPU |
| JVM 힙 | 4 GB | 8~16 GB |
| 노드당 총 RAM | 8~16 GB | 32 GB |
| 콘텐츠 저장소 | 100 GB SSD | 500 GB 이상 SSD |
| 디스크 성능 | — | NVMe · SSD |
| 네트워크 | 1 Gbps | 10 Gbps |
힙에는 두 가지 상한이 걸린다.
베어메탈에서 권장하던 디스크 분리 원칙은 쿠버네티스에서도 그대로 간다 — OS, FlowFile 저장소, 콘텐츠 저장소, 프로버넌스 저장소를 각각 다른 물리 경로에 둔다.
한 볼륨에 전부 몰아넣지 않는다. 세 저장소는 입출력 성격이 다르고, 하나가 가득 차면 나머지까지 멈춘다.
| 저장소 | 성격 | 권장 크기 | 스토리지 클래스 |
|---|---|---|---|
| FlowFile Repository | 작은 쓰기가 잦다. 여기가 막히면 플로우 전체가 멈춘다 | 50~100 GB | 빠른 SSD |
| Content Repository | 실제 데이터가 쌓인다. 가장 크다 | 200~500 GB | 빠른 SSD |
| Provenance Repository | 이력 인덱싱. 쓰기량이 만만치 않다 | 200~500 GB | 빠른 SSD |
| 로그 | 순차 쓰기 | 50 GB | 일반 |
CR 의 저장소 항목으로 각각 마운트 경로와 크기, 스토리지 클래스를 지정한다.
apiVersion: cfm.cloudera.com/<apiVersion>
kind: Nifi
metadata:
name: nifi-cluster
namespace: nifi
spec:
replicas: 3
resources:
requests:
cpu: "4"
memory: "16Gi"
limits:
cpu: "8"
memory: "32Gi"
storageConfigs:
- name: flowfile-repo
mountPath: /opt/nifi/data/flowfile_repository
storage: "50Gi"
storageClassName: fast-ssd
- name: content-repo
mountPath: /opt/nifi/data/content_repository
storage: "200Gi"
storageClassName: fast-ssd
- name: provenance-repo
mountPath: /opt/nifi/data/provenance_repository
storage: "200Gi"
storageClassName: fast-ssd
apiVersion 과 필드 이름은 오퍼레이터 버전마다 다르다. 문서 예시를 그대로 복사하지 말고 클러스터에 등록된 CRD 에서 확인한다.
kubectl get crd nifis.cfm.cloudera.com -o jsonpath='{.spec.versions[*].name}'; echo
kubectl explain nifi.spec --api-version=cfm.cloudera.com/<version>
저장소 용량 자체보다 저장 정책이 중요하다. 보존 기간과 아카이브 설정을 그대로 두면 콘텐츠 저장소가 금세 찬다. NiFi 저장소 사용량과 보존 을 같이 본다.
| 항목 | 내용 |
|---|---|
| 쿠버네티스 | 오퍼레이터가 요구하는 최소 버전 이상. OpenShift 도 별도 최소 버전이 있다 |
| cert-manager | 오퍼레이터 웹훅과 NiFi · Registry 인증서 발급에 쓴다. 시험 목적이면 자체 서명 CA 로 충분하다 |
| 스토리지 클래스 | 영구 볼륨을 동적으로 만들 수 있어야 한다 |
| 레지스트리 접근 | 벤더 컨테이너 레지스트리 자격증명 |
| 라이선스 | 오퍼레이터가 라이선스 없이는 기동하지 않는다. Secret 으로 저장된다 |
| 로그 수집 · Prometheus | 선택. 메트릭 수집용 |
이미지 pull secret 은 오퍼레이터 네임스페이스와 NiFi 네임스페이스 양쪽에 모두 만든다. 한쪽만 만들고 파드가 뜨지 않는 경우가 흔하다. 오퍼레이터는 자기 네임스페이스에 배포되고, 실제 NiFi 인스턴스는 별도 네임스페이스에서 관리되기 때문이다.
오퍼레이터 기반 배포에서는 클러스터 상태를 쿠버네티스 리소스에 저장하고 리더 선출도 쿠버네티스가 처리하므로, 별도 ZooKeeper 앙상블을 두지 않는 구성이 가능하다. 기존 온프레미스 CFM 과 크게 다른 점이다.
다만 오퍼레이터 · NiFi 버전 조합에 따라 여전히 ZooKeeper 를 요구하는 경우가 있다 (확인 필요). 쓰려는 버전의 문서에서 확인하고, 불확실하면 단일 노드로 먼저 띄워 본 뒤
replicas를 올린다.
kubectl get crds | grep nifi
kubectl get pods -n <operator-namespace>
kubectl get pods -n nifi
kubectl get pvc -n nifi
노드가 죽어도 진행 중인 데이터가 끊기지 않는 것은 볼륨이 새 노드로 다시 붙기 때문이다. 이 동작은 스토리지 클래스가 노드 간 재부착을 지원할 때만 성립한다. 로컬 디스크 기반 스토리지 클래스를 쓰면 파드가 그 노드에 고정된다.