PVC가 Bound여도 디스크가 가득 찰 수 있습니다

8월 중순에는 Kafka 데이터 증가량과 OpenEBS local hostpath 볼륨의 저장 공간을 점검했습니다. PVC의 요청 크기는 Kubernetes에서 볼륨을 할당하는 기준이고, 사용하는 hostpath 구성에서는 그 숫자가 디렉터리의 실제 사용량을 강제로 제한하는 quota가 아닙니다.

그래서 KafkaTopic 보존 정책과 실제 노드 파일시스템의 여유 공간을 함께 봅니다. Kafka는 PostgreSQL의 업무 원본과 outbox를 전달하는 경로로 사용하며, 메시지 보존 기간을 원본 데이터의 보관 정책과 동일하게 취급하지 않습니다.

시간과 크기 보존 정책을 명시합니다

Strimzi가 관리하는 KafkaTopic의 spec.config에 보존 정책을 둡니다. 아래는 가상의 topic에 적용하는 축약 예제이며 시간과 크기는 운영값이 아닙니다.

YAML
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: example-events
  namespace: example
  labels:
    strimzi.io/cluster: example-kafka
spec:
  partitions: 3
  replicas: 3
  config:
    cleanup.policy: delete
    retention.ms: 172800000
    retention.bytes: 268435456
    segment.bytes: 67108864

retention.ms는 보존 시간이고 retention.bytes는 파티션 단위의 크기 기준입니다. 전체 topic 크기나 모든 broker의 디스크 한도로 해석하지 않습니다. Kafka는 segment 단위로 정리하므로 설정값에 도달한 순간 정확히 그 크기로 잘리는 동작도 아닙니다. partition 수, 복제 수, active segment와 삭제 지연을 함께 고려해야 합니다.

DLQ처럼 조사에 필요한 메시지는 보존 정책을 줄이기 전에 kcat으로 내보내는 절차를 구분합니다. broker 데이터 디렉터리의 segment 파일을 직접 삭제하는 방식으로 공간을 확보하지 않습니다.

현재 여유와 증가 속도를 같이 봅니다

PROMQL
node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}

predict_linear(
  node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h],
  24 * 60 * 60
) < 0

첫 쿼리는 현재 여유 공간이고 두 번째 쿼리는 최근 기울기가 유지될 경우 하루 안에 공간이 부족해지는지 보는 예제입니다. 실제 경보에는 Kafka 데이터가 놓인 mountpoint와 읽기 전용 여부를 필터링해야 합니다. predict_linear는 급격한 삭제나 보존 정책 변경을 예측하지 못하므로 확정적인 고갈 시각으로 사용하지 않습니다.

검증에서는 Topic 설정과 실제 segment 정리, 노드 파일시스템 변화, 경보의 대상 mountpoint를 대조했습니다. PVC 상태, Kafka 보존 설정, 실제 디스크 사용량을 각각 확인하는 운영 기준을 남겼습니다.