Open Service Broker를 통한 Kubernetes의 동적 로컬 영구 볼륨
Source: Dev.to
공유 스토리지는 많은 워크로드에 잘 맞지만, 지연 시간과 I/O 일관성이 중요해지면 로컬 디스크가 매우 매력적으로 다가옵니다.
Kubernetes는 로컬 퍼시스턴트 볼륨(Local PV)을 지원하지만 큰 제한이 있습니다: Local PV는 반드시 정적으로 프로비저닝되어야 합니다. 이 때문에 워크로드가 필요에 따라 생성되는 동적 환경에서는 사용하기 어렵습니다. 우리는 Open Service Broker 인터페이스를 통해 로컬 스토리지를 제공하려다 이 문제에 직면했습니다.
정적 Local PV가 문제인 이유
- 워크로드가 요청하기 전에 PV가 미리 존재해야 함
- 용량 계획을 수동으로 해야 함
- 자동화 파이프라인이 중단됨
서비스 브로커와 셀프‑서비스 플랫폼에서는 이것이 허용되지 않습니다. 사용자는 스토리지가 동적으로 프로비저닝되길 기대합니다.
우리가 취한 접근 방식
Kubernetes 설계를 거스르기보다 우회했습니다. 핵심 아이디어는 다음을 분리하는 것이었습니다:
- 스케줄링 결정 – 여전히 Kubernetes가 수행
- 디스크 생성 – 대상 노드에서 수행
프로비저닝 흐름
전체적인 흐름은 다음과 같습니다:
- 서비스 브로커가 로컬 스토리지 요청을 받음.
- 브로커가 임시 “더미” Kubernetes 매니페스트를 제출함:
- 리소스 요구사항
- 노드 어피니티
- Kubernetes가 워크로드를 특정 노드에 스케줄링함.
- 노드가 결정되면 브로커가:
- 원격으로 로컬 디스크를 생성
- 해당 Local PV 객체를 생성
- 실제 워크로드가 배포되고 해당 PV에 바인딩됨.
- 서비스가 삭제되면 로컬 디스크를 정리함.
이렇게 하면 Local PV가 내부적으로는 정적이지만, 마치 동적 프로비저닝처럼 동작하는 시스템을 만들 수 있었습니다.
왜 성공했는가
- Kubernetes가 여전히 배치 결정을 담당.
- 디스크 생성은 필요할 때만 해당 노드에서 수행.
- 사용되지 않는 용량을 미리 프로비저닝하지 않음.
- 스토리지 수명 주기가 서비스 인스턴스와 연결됨.
CSI 드라이버만큼 우아하지는 않지만, 온‑프레미스 및 하이브리드 클러스터에서는 실용적인 해결책이었습니다.
트레이드오프와 교훈
- 노드 수준 접근 권한이 필요함.
- 정리 작업을 신중히 처리해야 함.
- 실패 경로에 대한 추가적인 주의가 필요함.
그 대가로 우리는 예측 가능한 성능과 상태 저장 워크로드에 대한 훨씬 나은 개발자 경험을 얻었습니다.
이 패턴이 적합한 경우
- 클러스터를 직접 관리하고 있음.
- I/O 성능이 중요함.
- 클라우드 블록 스토리지를 사용할 수 없음.
- 서비스 브로커가 플랫폼의 일부임.
많은 내부 플랫폼에서 이것이 “충분히 좋음”으로 판명되었으며, 수동 PV 관리보다 훨씬 나은 선택이었습니다.
오픈소스 구현
우리는 이 접근 방식을 더 큰 플랫폼 프로젝트의 일부로 문서화하고 오픈소스로 공개했습니다:
만약 여러분이 Local PV를 활용한 동적 스토리지 워크플로를 구축했거나(또는 포기했다면) 어떤 점이 잘 작동했고 어떤 점이 그렇지 않았는지 공유해 주시면 좋겠습니다.