브라운필드 쿠베플로우 on RKE2: 덱스 & 시위드FS를 Keycloak & Ceph RGW로 교체
(dev.to)
Kubeflow를 기존 인프라에 통합할 때 발생하는 중복 컴포넌트 문제를 해결하기 위해 Dex, SeaweedFS 등을 Keycloak, Ceph RGW로 교체하여 효율적인 브라운필드 클러스터를 구축하는 기술적 방법론을 다룹니다.
이 글의 핵심 포인트
- 1Kubeflow 기본 구성 요소(Dex, SeaweedFS, MySQL)를 기존 인프라(Keycloak, Ceph RGW, CloudNativePG)로 교체하여 중복 방지
- 2Keycloak을 통한 단일 SSO(Single Sign-On) 체계 구축 및 인증 파편화 해결
- 3Rook-Ceph RGW를 활용한 S3 호환 오브젝트 스토리지 통합으로 데이터 관리 일원화
- 4Kustomize 오버레이를 사용하여 Kubeflow의 구성 요소를 기존 RKE2 클러스터 환경에 맞게 재정의
- 5기존 Istio 서비스 메쉬 및 Cert-manager와의 정교한 통합을 통한 보안 및 인증 자동화
이 글에 대한 공공지능 분석
왜 중요한가?
ML 플랫폼 도입 시 '그린필드(신규)' 방식의 단순 설치는 기존 인프라와 충돌하여 관리 복잡도를 폭증시킵니다. 인프라 자원의 중복 사용을 막고 단일화된 인증/저장 체계를 유지하는 것은 운영 비용 절감과 보안 관리의 핵심입니다.
어떤 배경과 맥락이 있나?
Kubeflow는 기본적으로 독립적인 클러스터를 가정하고 설계되어, 이미 운영 중인 서비스(Identity Provider, Object Store 등)가 있는 '브라운필드(기존 환경)' 클러스터에서는 구성 요소 간의 불일치가 발생합니다.
업계에 어떤 영향을 주나?
MLOps 플랫폼 도입 시 단순 설치를 넘어, 기존 클라우드 네이티브 스택(Istio, Ceph, Keycloak 등)과의 정교한 통합 설계가 필수적임을 시사합니다. 이는 플랫폼 엔지니어링의 난이도를 높이는 요소입니다.
한국 시장에 어떤 시사점이 있나?
인프라 비용 최적화가 중요한 한국 스타트업들에게, 기존에 구축된 공유 인프라를 재활용하여 ML 워크로드를 통합하는 '브라운필드 전략'은 기술적 부채를 줄이고 운영 효율을 극대화하는 중요한 접근법입니다.
이 글에 대한 큐레이터 의견
MLOps 플랫폼을 도입할 때 가장 큰 함정은 '플랫폼이 가져오는 모든 것을 무비판적으로 수용하는 것'입니다. 저자가 보여준 것처럼, 기존 인프라(Keycloak, Ceph 등)를 활용하여 Kubeflow의 기본 컴포넌트를 교체하는 작업은 운영 효율성 측면에서 매우 탁월한 선택입니다. 이는 인증 체계의 파편화를 막고, 데이터 저장소의 단일 진실 공급원(Single Source of Truth)을 유지하게 해줍니다.
다만, 이러한 '커스텀 통합'에는 상당한 엔지니어링 비용과 리스크가 따릅니다. 저자 역시 이를 위해 수 주간의 작업과 Kustomize 오버레이 관리가 필요했습니다. 업그레이드 시 upstream의 변경 사항이 커스텀 레이어와 충돌할 위험이 있으며, 이는 장기적인 기술적 부채로 남을 수 있습니다. 따라서 스타트업은 '표준 설치'의 편의성과 '커스텀 통합'의 운영 효율성 사이에서, 팀의 운영 역량과 인프라 복잡도를 고려한 냉정한 트레이드오프 결정을 내려야 합니다.
관련 뉴스
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.