02.Ceph 구성하기

Rook-Ceph로 Object Storage 준비하기

Loki의 Object Storage 구성용으로 Rook-ceph를 설치합니다

object storage를 Kubernetes 내부에 둘지, 외부에 둘지

먼저 방향부터 정해야 한다. Ceph object storage는 크게 두 방식으로 둘 수 있다.

Kubernetes 내부: Rook-Ceph가 클러스터 안에서 CephCluster, RGW, Bucket, User를 관리한다.
Kubernetes 외부: 별도 Rocky Linux 9 서버군에 Ceph를 구축하고, Kubernetes에서는 외부 S3 endpoint만 소비한다.

기준	Kubernetes 내부 배치	Kubernetes 외부 배치
구축 난이도	Rook CRD 중심으로 일관된 배포 가능	cephadm 또는 수동 운영까지 별도 설계 필요
블로그 실습 적합성	Kubernetes 리소스 흐름으로 설명하기 좋음	Ceph 전용 운영 지식 비중이 커짐
Loki와 연계	같은 클러스터 안에서 Service와 Secret 활용이 쉬움	endpoint, routing, firewall, cert 설계가 더 많아짐
운영 분리	상대적으로 약함	스토리지와 앱 플랫폼 책임 분리 쉬움
확장성	중소규모 private cloud에 적합	대규모 전용 스토리지 플랫폼에 더 적합

통합 Ceph를 사용할게 아니라면 Kubernetes 내부에 배치하는 방향으로 설계하는 것이 최적의방안이 될지도 모르겠습니다.
Rook은 기존 Kubernetes 클러스터 위에 Ceph를 배포하고 운영할 수 있게 해주며, CephObjectStore를 통해 S3 호환 object storage를 제공한다.

Ceph 도입 전제 조건

Rook 문서에 따르면 Rook은 기존 Kubernetes 클러스터 위에 설치되며, 지원되는 Kubernetes 버전과 필요한 권한, 스토리지 디바이스 조건을 충족
또한 Ceph OSD용으로는 파일시스템이 올라가지 않은 raw device, raw partition, LVM logical volume, 또는 block 모드 PV가 필요하다. - Kubernetes 노드 아키텍처는 amd64/x86_64 또는 arm64가 적합하다. - 스토리지 노드에는 Ceph OSD가 사용할 비어 있는 디스크나 파티션이 필요하다. - 필요한 경우 lvm2 패키지를 설치해야 하며, 그렇지 않으면 재부팅 후 OSD가 정상 기동하지 않을 수 있다. - 커널 모듈 rbd 사용 가능 여부를 점검하는 편이 좋다.

Ceph 설치

Rocky Linux 9 서버 준비 예시는 다음 정도로 정리하면 충분하다.

sudo dnf update -y
sudo dnf install -y lvm2 curl tar git jq
lsblk -f
sudo modprobe rbd

lsblk -f 결과에서 OSD로 사용할 디스크의 FSTYPE가 비어 있는지 먼저 확인하는 것이 중요하다. Rook 문서도 파일시스템이 이미 올라간 디바이스는 OSD 대상으로 적합하지 않다고 설명한다.

Rook-Ceph 설치 흐름

Rook-Ceph 설치는 대체로 네 단계로 이해하면 쉽다.
1. Rook operator와 CRD를 배포한다.
2. CephCluster 리소스로 실제 Ceph 클러스터를 구성한다.
3. CephObjectStore로 RGW 기반 object storage 엔드포인트를 만든다.
4. CephObjectStoreUser 또는 S3 사용자 방식으로 접근 계정을 준비한다.

root-ceph 설치하기

kubectl create namespace rook-ceph
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/deploy/examples/crds.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/deploy/examples/common.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/deploy/examples/operator.yaml

배포 후에는 operator 상태를 먼저 본다.

kubectl -n rook-ceph get pods
kubectl -n rook-ceph logs deploy/rook-ceph-operator

CephCluster 배포

Rook에서 실제 Ceph 저장소 클러스터는 CephCluster CR로 선언한다. 이 리소스 안에서 monitor 수, manager, dashboard, storage 사용 정책, 사용할 디스크나 노드 범위를 정의하면 됩니다

Info

private cloud에서는 OS 디스크를 건드리는 사고를 막기 위해 useAllDevices: false와 nodes 또는 deviceFilter를 명확히 두는 구성이 좋다.

예시 YAML은 아래처럼 설명할 수 있다.

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v19
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    count: 1
    allowMultiplePerNode: false
  dashboard:
    enabled: true
  storage:
    useAllNodes: false
    useAllDevices: false
    nodes:
    - name: worker-1
      devices:
      - name: sdb
    - name: worker-2
      devices:
      - name: sdb
    - name: worker-3
      devices:
      - name: sdb

적용 후에는 아래처럼 상태를 확인한다.

kubectl apply -f cephcluster.yaml
kubectl -n rook-ceph get cephcluster
kubectl -n rook-ceph get pods -o wide
kubectl -n rook-ceph describe cephcluster rook-ceph

정상 배포가 되면 mon, mgr, osd, prepare 계열 Pod가 차례대로 올라온다. 이 단계가 안정화되어야 그다음 object storage 계층도 무리 없이 올라간다.

CephObjectStore 생성

Ceph object storage는 CephObjectStore 리소스로 만든다. Rook 문서에 따르면 이 리소스는 RGW daemon과 관련 설정을 배포해 S3 및 Swift 호환 object storage 서비스를 제공한다.

Loki 용도라면 처음부터 복잡한 멀티사이트나 고급 zone 구성을 가져가기보다, 단일 object store와 기본 포트 구성을 잡는 편이 적절하다. 블로그에서는 아래와 같은 최소 예제를 소개하면 충분하다.

apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: loki-store
  namespace: rook-ceph
spec:
  metadataPool:
    replicated:
      size: 3
  dataPool:
    replicated:
      size: 3
  gateway:
    port: 80
    instances: 2

적용과 확인은 다음처럼 진행한다.

kubectl apply -f cephobjectstore.yaml
kubectl -n rook-ceph get cephobjectstore
kubectl -n rook-ceph get svc,pods | grep rgw

정상 생성되면 RGW Service가 노출되고, 이후 Loki가 사용할 S3 endpoint는 이 RGW Service 주소가 된다. 같은 Kubernetes 내부에 Loki를 올릴 예정이므로 Service DNS를 그대로 활용할 수 있다는 점이 내부 배치의 장점이다.

Bucket 준비와 S3 사용자/키 생성

접근 계정은 CephObjectStoreUser CRD로 만드는 방식이 Rook 관점에서 가장 선언적이다. Rook 문서에 따르면 사용자 이름, 표시 이름, 최대 bucket 수, quota, capability 등을 CRD로 정의할 수 있다.

예시 리소스는 아래와 같이 잡을 수 있다.

apiVersion: ceph.rook.io/v1
kind: CephObjectStoreUser
metadata:
  name: loki-user
  namespace: rook-ceph
spec:
  store: loki-store
  displayName: Loki User

생성 후에는 access key와 secret key가 Secret으로 만들어진다.

kubectl apply -f cephobjectstoreuser.yaml
kubectl -n rook-ceph get cephobjectstoreuser
kubectl -n rook-ceph get secret rook-ceph-object-user-loki-store-loki-user -o yaml

Bucket은 두 방식 중 하나를 선택하면 된다.

AWS CLI나 s3cmd로 직접 bucket 생성.
애플리케이션 초기화 단계에서 Loki가 사용할 bucket을 사전에 수동 생성.

블로그 흐름상 가장 이해하기 쉬운 방법은 AWS CLI를 사용해 loki-chunks, loki-ruler, loki-admin 같은 bucket을 직접 만드는 것이다. 실제 Loki 설정에서도 object storage용 bucket 이름을 명시하게 되므로, 이름을 미리 정리해두면 3편 연결이 훨씬 부드럽다.

확인용 테스트 업로드

Ceph RGW가 S3 호환 object storage로 정상 동작하는지 확인하려면, 실제로 bucket 생성과 업로드를 해보는 것이 가장 확실하다. Ceph RGW는 S3 API와 호환되므로 AWS CLI를 endpoint만 바꿔 사용해 테스트할 수 있다.

Rocky Linux 9 테스트 노드 또는 관리용 호스트에서 다음처럼 진행하면 된다.

sudo dnf install -y awscli
aws configure set aws_access_key_id <ACCESS_KEY>
aws configure set aws_secret_access_key <SECRET_KEY>
aws configure set default.region us-east-1

aws --endpoint-url http://rook-ceph-rgw-loki-store.rook-ceph.svc s3 mb s3://loki-chunks
aws --endpoint-url http://rook-ceph-rgw-loki-store.rook-ceph.svc s3 mb s3://loki-ruler
aws --endpoint-url http://rook-ceph-rgw-loki-store.rook-ceph.svc s3 mb s3://loki-admin

echo 'ceph rgw test object' > test.txt
aws --endpoint-url http://rook-ceph-rgw-loki-store.rook-ceph.svc s3 cp test.txt s3://loki-chunks/
aws --endpoint-url http://rook-ceph-rgw-loki-store.rook-ceph.svc s3 ls s3://loki-chunks/

만약 Kubernetes 외부 호스트에서 테스트한다면, RGW Service를 NodePort, LoadBalancer, Ingress, 또는 별도 프록시로 노출해야 한다. 하지만 이번 시리즈는 내부 배치를 택했기 때문에, 먼저 클러스터 내부 접근 기준으로 검증한 뒤 필요 시 외부 노출을 추가하는 순서가 더 안전하다.

이번 편에서 정한 설계 결정

이번 시리즈의 설계 결론은 다음과 같다.

운영체제 기준은 Rocky Linux 9로 통일한다.
Ceph object storage는 Kubernetes 내부에 Rook-Ceph로 구성한다.
Loki는 이후 편에서 Ceph RGW의 S3 endpoint를 backend로 사용한다.
bucket과 access key, secret key는 3편에서 Loki values에 연결한다.

이렇게 정리하면 3편에서는 고민이 크게 줄어든다. 이미 RGW endpoint, bucket, credential이 준비되어 있으므로, Loki Helm values에서 S3 backend와 path-style 옵션을 연결하는 데 집중하면 된다.

작성일: 2026년 7월 25일 , 마지막 업데이트: 2026년 7월 25일