Oxide, 고객 요구 따라 Rancher·Omni·Cluster API용 Kubernetes 통합 3종 공개

최신 Kubernetes용 oxide-cloud-controller-manager가 기존 in-tree CCM과 얼마나 달라질지 궁금함. karpenter-provider-oxide도 언젠가 나올 것 같다고 봄.

제대로 된 Load Balancer, Gateway API용 Ingress Controller, API Gateway가 필요해 보임. 온프레미스와 클라우드 제품들은 이쪽이 너무 복잡하거나 부족했음.

CCM의 주 역할은 node, route, service controller를 담은 cloudprovider.Interface 구현임. 임의의 named controller도 실행할 수 있고, in-tree CCM은 out-of-tree 방식으로 넘어가는 중임. Karpenter는 내부 데모를 했지만 공개 릴리스는 아직 논의 중임.

Oxide의 문서 시스템을 오픈소스로 보고 싶을 정도로 마음에 듦.

RFD 시스템을 말하는 거라면 이미 rfd-site가 GitHub에 오픈소스로 공개돼 있음.

CAPOx provider와 Cluster API를 받아들인 점이 좋음.

Oxide의 Kubernetes는 아직 퍼블릭 클라우드와 차이가 있음. EKS Fargate는 Pod마다 VM을 쓰지만 Oxide는 노드가 VM이라 Talos 같은 계층이 필요하고, 외부 서브넷으로 overlay 없이 Pod 라우팅은 가능해도 Load Balancing과 사용자 접근 제어 통합은 더 필요해 보임.

Oxide에서의 'native Kubernetes'를 논의 중이지만 일부는 제품 기능이 더 갖춰져야 함. 외부 서브넷으로 overlay를 없애는 고객은 이미 있지만 아직 controller에 통합하지 않았음.

PVC마다 실행 중인 worker VM에 새 볼륨을 붙이는 방식인가? 단일 대형 볼륨을 붙이고 경로 기반으로 provision하면 안 되는지 궁금함.

초기 prototype은 PVC마다 볼륨을 붙이는 방식이었지만 local disk 출시와 disk hot-plug 작업 전 이야기임. 대형 볼륨 경로 분할도 가능성은 있지만 hot-plug가 먼저여야 클러스터를 미리 특정 형태로 만들어야 하는 제약이 없음.

온프레미스에서는 bare metal Kubernetes와 KubeVirt 대신 언제 Oxide를 써야 하는지 궁금함. VM 중심 Oxide보다 containerd나 WASM을 직접 돌리는 Kubernetes API 호환 플랫폼이 더 맞는 경우도 있어 보임.

Oxide는 KVM/QEMU가 아니라 자체 Propolis hypervisor를 쓰고, 현재 nested virtualization이 없어 KubeVirt 모델은 지원하지 않음. 기본 단위는 VM instance이며 Kubernetes manifest만으로 운영하려는 사용자를 위한 OxideInstance 같은 CRD는 논의 중이지만 컨테이너 primitive는 당장 추진하지 않음.

Oxide에서 데이터베이스 같은 stateful workload를 어떻게 관리하는지 궁금함.

현재는 Oxide storage 위의 Longhorn 등을 쓰고 있음. CSI plugin을 출시하면 그 방식을 쓸 수 있다고 함.