ceph storage class 사용 wordpress, mysql pod 생성

2025년 12월 23일 Jason 댓글 남기기

개요

Rook-Ceph 구축 이후 Ceph StorageClass를 활용하면 Kubernetes Pod에서 PVC(PersistentVolumeClaim)를 통해 Ceph RBD(RADOS Block Device) 기반의 영구 볼륨을 동적으로 프로비저닝할 수 있습니다. Pod가 삭제되거나 재스케줄링되어도 데이터가 Ceph에 안전하게 보존됩니다.

이 글에서는 Ceph RBD StorageClass를 생성하고, PVC가 포함된 MySQL과 WordPress Deployment를 배포하는 전체 절차를 정리합니다. MetalLB LoadBalancer를 통해 WordPress에 외부 IP가 할당되어 실제 서비스 접근까지 확인합니다. 이 구성은 Rook-Ceph 구축이 완료된 환경을 전제합니다.

사전 준비

이 절차를 진행하기 전에 다음 구성 요소가 준비되어 있어야 합니다.

Rook-Ceph 클러스터가 정상 기동 중 (ceph status에서 HEALTH_OK)
MetalLB가 구성되어 있고 LoadBalancer IP 풀이 설정된 상태
Rook 저장소 클론이 로컬에 존재 (rook/deploy/examples/ 디렉토리 필요)

Rook 예제 디렉토리에는 mysql.yaml, wordpress.yaml, csi/rbd/storageclass.yaml이 포함되어 있습니다. 이 파일들을 기반으로 StorageClass를 생성하고 WordPress와 MySQL을 배포합니다.

Ceph StorageClass 생성

Rook 저장소의 csi/rbd/storageclass.yaml을 적용하면 rook-ceph-block StorageClass가 생성됩니다. 이후 Pod에서 storageClassName: rook-ceph-block으로 PVC를 요청하면 Ceph RBD 볼륨이 자동으로 생성·마운트됩니다.

StorageClass의 reclaimPolicy: Delete는 PVC 삭제 시 볼륨도 함께 삭제됨을 의미합니다. 데이터를 보존해야 하는 경우 Retain으로 변경해야 합니다. allowVolumeExpansion: true로 설정되어 있어 운영 중에도 PVC의 용량을 늘릴 수 있습니다.

kubectl apply -f csi/rbd/storageclass.yaml

kubectl get storageclass
NAME              PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION
rook-ceph-block   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           true

MySQL Deployment 배포 (PVC 포함)

Service, PersistentVolumeClaim, Deployment가 포함된 MySQL manifest를 배포합니다. PVC가 생성되면 Rook CSI 드라이버가 Ceph 클러스터에 RBD 이미지를 자동으로 생성하고, kubelet이 해당 볼륨을 Pod에 마운트합니다. PVC Status가 Bound이면 Ceph RBD 볼륨이 정상 마운트된 것입니다.

MySQL Deployment의 환경변수(MYSQL_ROOT_PASSWORD 등)는 실제 운영 환경에서 Secret 리소스로 분리하는 것을 권장합니다. 또한 MySQL 데이터 디렉토리(/var/lib/mysql)를 PVC에 마운트하므로, Pod를 재시작하거나 노드가 변경되어도 데이터가 보존됩니다.

kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-6d458ff1-54bf-4f34-b010-a0f4b2a0966e  20Gi       RWO            rook-ceph-block   94s

WordPress Deployment 배포 (PVC 포함)

MySQL과 동일하게 Service, PVC, Deployment가 포함된 WordPress manifest를 배포합니다. WordPress는 업로드 파일 등을 /var/www/html에 저장하는데, 이 디렉토리가 PVC에 마운트되어 Pod 재시작 후에도 데이터가 유지됩니다. WordPress 서비스 타입은 LoadBalancer로 설정되어 MetalLB로부터 외부 IP를 할당받습니다.

kubectl create -f wordpress.yaml
service/wordpress created
persistentvolumeclaim/wp-pv-claim created
deployment.apps/wordpress created

kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
wordpress-7cf5c5c8b-5cgqk          1/1     Running   0          42s
wordpress-mysql-6f99c59595-9vs7z   1/1     Running   0          4m8s

MetalLB로 외부 접근 확인

MetalLB가 구성된 환경에서는 WordPress Service에 외부 IP가 자동 할당됩니다. 해당 IP로 브라우저에서 접속하면 WordPress 설치 화면이 표시되며, Ceph 기반 영구 스토리지 구성이 완료된 것입니다.

이 구성에서 WordPress와 MySQL은 서로 다른 Ceph RBD PVC를 사용합니다. 스토리지 레이어가 Ceph로 추상화되어 있기 때문에, 향후 WordPress나 MySQL Pod를 다른 Worker 노드로 재스케줄링해도 동일한 데이터에 접근할 수 있습니다. PVC의 accessMode: ReadWriteOnce(RWO) 특성상 한 번에 한 Pod만 볼륨에 마운트할 수 있으며, 수평 확장이 필요한 경우에는 CephFS(RWX)를 사용해야 합니다.

kubectl get svc wordpress
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
wordpress   LoadBalancer   x.x.x.x         x.x.x.x       80:31494/TCP   27s

배포 결과 및 볼륨 확인

모든 리소스 배포 후 아래 명령어로 최종 상태를 확인합니다. PVC가 Bound, Pod가 Running, Service에 외부 IP가 할당된 것이 정상 상태입니다.

# PVC 상태 확인 (Bound이면 정상)
kubectl get pvc

# Pod 상태 확인
kubectl get pods

# WordPress Service 외부 IP 확인
kubectl get svc wordpress

# Ceph에서 실제 RBD 이미지 확인 (Toolbox Pod 내에서)
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
rbd ls replicapool

PVC가 Pending 상태에서 멈추는 경우 주요 원인으로는 Ceph 클러스터 상태 이상(HEALTH_WARN 이상), StorageClass 미적용, 또는 Rook CSI 드라이버 Pod 이상이 있습니다. kubectl describe pvc <pvc-name>으로 이벤트를 확인하고 조치합니다.

참고

ceph 구축

2025년 12월 23일 Jason 댓글 남기기

개요

Rook은 Kubernetes용 스토리지 오케스트레이터로, Ceph 구축을 Kubernetes 네이티브 방식으로 자동화합니다. Rook-Ceph를 사용하면 Worker 노드에 연결된 Raw Disk를 기반으로 분산 오브젝트 스토리지를 구성하고, Kubernetes PersistentVolume(PV)을 동적으로 프로비저닝할 수 있습니다. Pod가 PersistentVolumeClaim(PVC)을 요청하면 Ceph RBD(Block Device) 또는 CephFS를 통해 영구 저장소가 자동으로 할당됩니다.

이 글에서는 Rook Operator를 배포하고 Ceph Cluster를 구성하는 전체 절차를 정리합니다. 최소 Worker 노드 3개와 각 노드에 파티션 또는 포맷이 되지 않은 Raw Disk가 필요합니다.

사전 준비 — Worker 노드 Raw Disk 확인

Ceph 스토리지는 각 Worker 노드에 할당된 초기화된(파티션/포맷 없는) Raw Disk를 OSD(Object Storage Daemon)로 사용합니다. 아래는 Worker 노드에 할당된 Raw Device 목록입니다.

OSD 외에도 Ceph는 여러 핵심 컴포넌트로 구성됩니다. MON(Monitor)은 클러스터 상태 맵을 관리하며 Quorum을 형성하기 위해 홀수(최소 3개)로 배포합니다. MGR(Manager)은 Ceph 대시보드와 메트릭 수집을 담당합니다. Rook Operator는 이 모든 컴포넌트를 Kubernetes CRD로 선언적으로 관리합니다.

Rook Operator 배포

Rook 공식 저장소에서 특정 버전을 클론한 뒤, CRD(Custom Resource Definition), 공통 리소스, Operator를 순서대로 배포합니다. Operator Pod가 정상 기동된 것을 확인한 뒤 Ceph Cluster를 배포합니다.

crds.yaml은 CephCluster, CephBlockPool 등 Rook이 사용하는 커스텀 리소스 타입을 등록합니다. common.yaml은 RBAC, ServiceAccount 등 공통 리소스를 생성하며, operator.yaml은 Rook Operator Deployment를 배포합니다. Operator는 rook-ceph 네임스페이스에서 실행되며, 이후 적용되는 CephCluster CR을 감지하여 Ceph 컴포넌트를 자동으로 생성합니다.

git clone --single-branch --branch v1.10.10 https://github.com/rook/rook.git
cd rook/deploy/examples

kubectl create -f crds.yaml -f common.yaml -f operator.yaml

# Operator Pod 기동 확인
kubectl -n rook-ceph logs -l app=rook-ceph-operator -f

Ceph Cluster 배포

cluster.yaml을 적용하면 Rook Operator가 OSD, MON, MGR 등 Ceph 컴포넌트를 자동으로 생성합니다. 초기 배포 시 Raw Disk를 OSD로 포맷하는 작업이 포함되어 있어 5~10분 정도 소요될 수 있습니다.

기본 cluster.yaml은 클러스터 내 모든 Raw Disk를 자동으로 검색하여 OSD로 사용합니다. 특정 디바이스만 사용하려면 spec.storage.nodes에서 노드별로 사용할 디바이스를 명시해야 합니다. spec.mon.count: 3으로 MON을 3개 배포하여 Quorum을 유지하고, Worker 노드가 3개 미만이면 allowMultiplePerNode: true를 설정해야 합니다.

kubectl create -f cluster.yaml

# 배포 진행 상태 모니터링
kubectl -n rook-ceph get pods -w

Pod 상태 확인

Ceph 구축이 완료되면 rook-ceph 네임스페이스에 OSD, MON, MGR Pod가 Running 상태로 기동됩니다. OSD Pod 수는 사용 가능한 Raw Disk 수와 일치하며, MON은 3개(또는 설정값), MGR은 1개(액티브) + 1개(스탠바이)가 기동됩니다.

Ceph 클러스터 상태 확인

Rook Toolbox Pod를 배포하면 ceph status, ceph osd tree 등 Ceph 관리 명령어를 직접 실행할 수 있습니다. ceph status 출력에서 HEALTH_OK가 표시되면 Ceph 구축이 정상 완료된 것입니다.

HEALTH_WARN이 표시되는 경우 주요 원인으로는 OSD 개수가 PG(Placement Group) 비율에 맞지 않는 경우, CLOCK_SKEW(노드 간 시간 차이), 또는 OSD가 아직 초기화 중인 경우가 있습니다. ceph health detail 명령어로 구체적인 경고 내용을 확인하고 조치합니다.

# Toolbox 배포 (Rook 예제 디렉토리에서)
kubectl create -f toolbox.yaml

# Toolbox Pod에 접속
kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

# Ceph 클러스터 상태 확인
ceph status
ceph osd tree

참고

VMware ESXi7 인증서 변경

2025년 8월 18일 Jason 댓글 남기기

개요

VMware vSphere(ESXi) 설치 시 기본 적용되는 자체 서명 인증서(Self-Signed Certificate)는 브라우저에서 “안전하지 않은 연결” 경고를 지속적으로 표시합니다. VMware ESXi7 인증서 변경을 통해 Let’s Encrypt에서 발급받은 공인 인증서를 적용하면 이 경고를 제거하고 도메인 기반으로 안전하게 웹 콘솔에 접근할 수 있습니다. ESXi의 인증서 파일은 /etc/vmware/ssl/ 경로에 위치하며, 기존 파일을 백업한 뒤 새 인증서로 교체하고 hostd 서비스를 재시작하는 방식으로 진행합니다.

구성 환경
– 인증서 보관 경로 : /etc/vmware/ssl
– root 인증서 : castore.pem
– public key : rui.crt
– private key : rui.key
– 인증서 발급 기관 : Let’s Encrypt(RSA 키 발급)

Self-Signed 인증서의 문제점과 해결 방법

VMware ESXi를 처음 설치하면 자체 서명 인증서(Self-Signed Certificate)가 자동으로 생성됩니다. 이 인증서는 공인 CA(Certificate Authority)가 서명하지 않았기 때문에 브라우저에서 신뢰할 수 없는 연결로 표시되고 매번 예외를 추가해야 하는 불편함이 있습니다. 또한 자동화 스크립트나 SDK에서 ESXi API를 호출할 때 인증서 검증 오류가 발생하여 --no-verify-ssl 같은 보안 우회 옵션을 사용하게 됩니다.

Let’s Encrypt에서 발급받은 무료 공인 인증서를 ESXi에 적용하면 이 문제를 해결할 수 있습니다. Let’s Encrypt는 90일 유효기간의 인증서를 무제한 발급하며, RSA와 ECDSA 키 타입을 모두 지원합니다. ESXi는 RSA 키만 지원하므로 반드시 certbot certonly --key-type rsa로 발급해야 합니다.

기존 인증서 백업

$ cd /etc/vmware/ssl

# 원복을 위한 root 인증서, public key, private key 백업
$ cp castore.pem castore.pem.bak
$ cp rui.crt rui.crt.bak
$ cp rui.key rui.key.bak

Let’s Encrypt 인증서 적용 및 웹서비스 재기동

$ cd /etc/vmware/ssl

# root 인증서 다운로드 및 적용
$ curl https://letsencrypt.org/certs/isrgrootx1.pem.txt -o castore.pem

# Let's Encrypt 인증서 파일(fullchain.pem, privkey.pem) /etc/vmware/ssl 사전 복사 처리 후 진행
$ openssl x509 -inform PEM -in fullchain.pem -out rui.crt
$ cp privkey.pem rui.key

# 웹서비스 재기동
$ /etc/init.d/hostd restart

서비스 재기동 완료 후 브라우저에서 할당된 도메인으로 정상 접속되면 완료입니다. 브라우저 주소창의 자물쇠 아이콘을 클릭하여 인증서 발급자가 Let’s Encrypt인지, 도메인이 일치하는지 확인합니다.

인증서 갱신 및 유의사항

Let’s Encrypt 인증서는 90일 유효기간을 가집니다. 만료 전에 갱신하지 않으면 브라우저에서 다시 경고가 표시됩니다. ESXi는 시스템 내부에 certbot이 설치되지 않으므로 자동 갱신을 ESXi 자체에서 처리할 수 없습니다. 대신 별도 서버에서 certbot으로 인증서를 갱신한 뒤, 갱신된 인증서 파일을 SCP나 SFTP로 ESXi의 /etc/vmware/ssl/에 복사하고 /etc/init.d/hostd restart를 실행하는 방식으로 갱신합니다.

인증서 교체 후에는 vSphere Client나 ESXi Host Client에서 로그아웃 후 재로그인해야 새 인증서가 반영됩니다. 또한 기존에 이 ESXi를 vCenter에 연결한 경우 vCenter에서도 인증서 재인증이 필요할 수 있습니다. 백업 파일(*.bak)은 인증서 교체에 문제가 생겼을 때 원복할 수 있도록 보관합니다.

IT Garage