[인프라] OpenStack Magnum, 왜 다시 주목받나?

OpenStack Magnum을 다시 보는 이유는 예전과 조금 다릅니다. 2026년 8월 기준 공식 문서와 릴리즈 노트를 다시 읽어보면, 지금의 Magnum은 단순히 Heat로 클러스터를 띄우는 오래된 서비스로 보기 어렵더라고요. 방향이 분명히 Cluster API 기반 Kubernetes as a Service 쪽으로 옮겨갔기 때문입니다.

핵심은 이제 “쿠버네티스를 한 번 띄우는 법”이 아닙니다. Keystone 인증, Neutron 네트워크, Cinder 스토리지, Octavia 로드밸런서, Barbican 인증서 저장 같은 OpenStack 자원을 하나의 운영 모델로 묶을 수 있느냐가 더 중요하거든요. 이 글에서는 OpenStack Magnum을 언제 검토할 만한지, 반대로 언제 과감히 제외하는 게 맞는지 실무 관점으로 정리해 보겠습니다.

OpenStack Magnum이 Keystone, Neutron, Cinder, Octavia와 어떻게 연결되고 Cluster API 기반으로 Kubernetes 클러스터를 관리하는지 보여주는 개요 이미지입니다.

1. OpenStack Magnum을 볼 때 먼저 버려야 할 오해

Magnum을 아직도 “Heat로 쿠버네티스를 띄우는 서비스”로만 보면 판단이 자꾸 어긋납니다. 최신 Magnum 사용자 가이드는 Heat 드라이버가 deprecated이며, 앞으로 제거될 예정이라고 분명히 적고 있습니다. 신규 설계에서 Heat를 기본 전제로 잡는 건 이제 장기 운영 관점에서 무리가 있습니다.

지금 봐야 할 축은 k8s_capi_helm과 k8s_cluster_api입니다. 특히 magnum-capi-helm은 OpenStack 거버넌스 아래에서 유지되고 있고, 공식 릴리즈 노트는 이 드라이버를 production use에 generally ready라고 설명합니다. 다만 이 표현을 곧바로 “대규모 운영에 아무 검증도 필요 없다”로 받아들이면 곤란합니다. 제 해석은 이렇습니다. 이제 Magnum의 실전성은 클러스터 생성 성공 여부보다, 관리 클러스터와 Cluster API 수명주기를 얼마나 안정적으로 운영하느냐에 달려 있습니다.

• 예전 시선: Magnum이 Heat 템플릿으로 인프라를 직접 밀어 올린다.
• 지금 시선: Magnum은 OpenStack API 진입점이고, 실제 클러스터 수명주기는 Cluster API와 provider가 선언적으로 맞춘다.
• 실무 함의: 장애 지점도 Magnum API, 관리 클러스터, CAPO, Helm chart, addon reconciliation까지 넓게 봐야 한다.

구성요소가 늘어나니 관찰 포인트도 많아집니다. 그래도 장점은 분명합니다. 예전에는 여기저기 흩어져 있던 업그레이드, 노드그룹 변경, autoscaling, 기본 정책 강제가 이제 플랫폼 계층에서 조금 더 정리되기 시작했거든요.

2. OpenStack Magnum이 다시 주목받는 이유

2026년 기준으로 다시 볼 만한 이유는 다섯 가지 정도로 압축됩니다.

1. 공식 방향이 Heat에서 CAPI 계열로 옮겨갔습니다. Heat는 유지 중인 환경을 이해하는 용도에 가깝고, 신규 표준으로 추천되는 분위기는 아닙니다.
2. magnum-capi-helm의 성숙도가 높아졌습니다. 공식 릴리즈 노트는 production use에 generally ready라고 밝히지만, 동시에 예상하지 못한 이슈 가능성도 언급합니다. 즉, 실전 배치 가능성은 높아졌지만 검증 책임이 사라진 건 아닙니다.
3. 생성보다 변경 관리가 중심으로 들어왔습니다. create, delete, upgrade, node group size update 같은 수명주기 작업이 문서 중심에 올라와 있습니다.
4. autoscaling 범위가 넓어졌습니다. 기본 워커뿐 아니라 non-default worker node group에도 min/max 정책을 줄 수 있고, 최신 릴리즈 노트 기준으로 min_node_count=0을 통한 scale-to-zero도 지원합니다. 다만 이 기능은 capi-helm-charts >= 0.26.0과 cluster-api-provider-openstack >= 0.26.0 조건을 확인해야 합니다.
5. 운영자 기본값 설계가 쉬워졌습니다. [capi_helm_cluster_labels] 섹션에서 사이트 전역 기본 라벨을 둘 수 있어서 사용자 자유도와 플랫폼 일관성의 균형을 잡기 편해졌습니다.

한 문장으로 줄이면 이렇습니다. OpenStack Magnum은 더 이상 “OpenStack에 쿠버네티스를 얹는 기능”이 아니라, OpenStack 조직 구조 안에서 Kubernetes 수명주기를 표준화하는 서비스에 가까워졌습니다.

3. OpenStack Magnum 운영에서 더 중요한 건 기본값 설계

현장에서 진짜 갈리는 지점은 Magnum 자체보다 기본값을 어떻게 잠그느냐입니다. 많은 글이 ClusterTemplate 예제만 보여주고 끝나는데, 운영팀은 그 전에 무엇을 사용자 자율에 맡길지, 무엇을 플랫폼 기본값으로 강제할지 먼저 정해야 하거든요. 이걸 늦게 정하면 클러스터가 늘어날수록 편차가 커집니다.

최신 magnum-capi-helm 설정 레퍼런스를 보면 핵심 섹션은 [capi_helm]와 [capi_helm_cluster_labels]입니다. 시작점으로는 아래와 같은 구성이 무난합니다.

[capi_helm]
kubeconfig_file = /etc/magnum/kubeconfig
namespace_prefix = magnum
helm_chart_repo = https://azimuth-cloud.github.io/capi-helm-charts
helm_chart_name = openstack-cluster
default_helm_chart_version = 0.26.0
minimum_flavor_ram = 2048
minimum_flavor_vcpus = 2

[capi_helm_cluster_labels]
auto_scaling_enabled = true
min_node_count = 1
max_node_count = 5
monitoring_enabled = true
kube_dashboard_enabled = false
auto_healing_enabled = true
keystone_auth_enabled = true
octavia_provider = amphora
octavia_lb_healthcheck = true
csi_cinder_reclaim_policy = Retain
csi_cinder_volume_binding_mode = WaitForFirstConsumer
csi_cinder_allow_volume_expansion = true
master_lb_floating_ip_enabled = true
api_master_lb_allowed_cidrs = 10.20.0.0/16
fixed_subnet_cidr = 10.40.0.0/24
pod_network_cidr = 10.100.0.0/16
service_network_cidr = 172.24.0.0/13

몇 가지는 그냥 옵션 나열로 보면 안 됩니다.

• kubeconfig_file: Magnum이 붙는 CAPI management cluster의 kubeconfig입니다. 이 관리 클러스터가 흔들리면 생성뿐 아니라 업그레이드와 노드그룹 변경도 같이 막힙니다.
• namespace_prefix: 여러 Magnum 배포가 하나의 관리 클러스터를 공유할 때 충돌을 피하는 최소 장치입니다.
• default_helm_chart_version: 여기서 버전을 통제하지 않으면 사용자별 드리프트가 시작됩니다.
• minimum_flavor_ram, minimum_flavor_vcpus: 성능 튜닝이라기보다 실패 방지용 안전장치에 가깝습니다.
• csi_cinder_volume_binding_mode=WaitForFirstConsumer: 멀티 AZ나 토폴로지 제약이 있는 환경에서는 특히 보수적으로 가져가는 편이 안전합니다.
• api_master_lb_allowed_cidrs: Kubernetes API를 너무 넓게 여는 실수가 의외로 자주 나옵니다. 초기에 편하다고 넓게 열면 나중에 되돌리는 비용이 더 큽니다.

제가 보는 핵심 질문은 하나입니다. 사용자가 바꿔야 하는 값과 플랫폼이 묶어야 하는 값을 구분했는가? OpenStack 기반 KaaS는 자유도보다 일관성이 중요할 때가 많습니다. 특히 여러 프로젝트가 같은 기반 인프라를 쓰는 조직에서는 더 그렇습니다. 이전에 다뤘던 Neutron·Octavia 운영 글과 함께 보면 이 경계가 더 또렷하게 잡힙니다.

운영자 설정 파일에서 기본 라벨을 정의하고, 사용자가 ClusterTemplate와 Cluster 생성 시 이를 어떻게 상속하거나 덮어쓰는지 보여주는 이미지입니다.

4. ClusterTemplate는 청사진이 아니라 운영 계약서입니다

ClusterTemplate를 만들 때 흔한 실수는 “생성만 되면 된다”는 태도로 옵션을 넣는 겁니다. 그렇게 만든 템플릿은 나중에 업그레이드, 보안, 확장성에서 발목을 잡습니다. Magnum의 템플릿은 사용자에게 노출되는 상품 정의서에 더 가깝습니다.

아래 예시는 공식 CLI 문법에 맞춰 정리한 시작 예시입니다. 다만 이미지 이름이나 flavor 이름은 환경마다 다르니, 실제 배포 전에는 운영 중인 Glance 이미지와 Nova flavor를 먼저 맞춰 확인하는 편이 좋습니다.

openstack coe cluster template create k8s-capi-template \
  --coe kubernetes \
  --image <validated-kubernetes-image> \
  --external-network public \
  --fixed-network tenant-net-prod \
  --fixed-subnet tenant-subnet-prod \
  --dns-nameserver 8.8.8.8 \
  --flavor m1.large \
  --master-flavor m1.large \
  --network-driver calico \
  --master-lb-enabled \
  --labels auto_scaling_enabled=true,min_node_count=1,max_node_count=3,monitoring_enabled=true,keystone_auth_enabled=true,octavia_provider=amphora,csi_cinder_volume_binding_mode=WaitForFirstConsumer,csi_cinder_reclaim_policy=Retain,api_master_lb_allowed_cidrs=10.20.0.0/16,pod_network_cidr=10.100.0.0/16,service_network_cidr=172.24.0.0/13 \
  k8s-capi-template

openstack coe cluster create prod-k8s-01 \
  --cluster-template k8s-capi-template \
  --master-count 3 \
  --node-count 2 \
  --timeout 90 \
  prod-k8s-01

openstack coe cluster config --dir ./kubeconfig --force prod-k8s-01
export KUBECONFIG=./kubeconfig/config
kubectl get nodes -o wide
kubectl get storageclass
kubectl get pods -A

여기서 체크할 기준은 분명합니다.

• 신규 구축이면 control plane 고가용성과 로드밸런서 경로를 먼저 잡는 편이 낫습니다. 실제로 magnum-capi-helm 문서는 업그레이드 안정성 측면에서 로드밸런서 사용을 강하게 시사합니다.
• 운영 안정성이 우선이면 CNI는 Calico부터 시작하는 편이 안전합니다. 공식 문서도 Cilium 지원은 언급하지만, 정기 검증은 Calico 중심이라고 설명합니다.
• master-lb-enabled는 CLI 옵션으로 존재하지만, CAPI Helm 문서상 현재 드라이버는 이 플래그를 사실상 무시합니다. 실무적으로는 로드밸런서를 전제로 설계하는 편이 낫습니다.

그리고 하나 더 있습니다. autoscaling을 켜면 초기 워커 수 해석이 Heat 시절과 다를 수 있습니다. 공식 릴리즈 노트에 따르면 auto_scaling_enabled=true일 때 min_node_count, max_node_count를 존중하며, 이 경우 기본 워커는 node_count 대신 최소 노드 수로 시작할 수 있습니다. 이 부분은 운영팀이 미리 공유해 두는 게 좋습니다.

5. nodegroup 설계가 좋으면 운영 절반은 끝납니다

실무에서 비용과 안정성을 동시에 좌우하는 건 워커를 한 덩어리로 둘지, 역할별 nodegroup으로 나눌지입니다. OpenStack 위에서 Magnum을 쓸 때는 기본 워커 그룹 하나로 오래 버티는 설계가 나중에 꽤 답답해지더라고요.

• 스토리지 성격이 다른 워크로드가 섞입니다.
• ingress, 배치, 일반 애플리케이션의 확장 패턴이 다릅니다.
• flavor 요구사항도 달라집니다.
• scale-to-zero 같은 정책은 특정 그룹에만 적용하고 싶은 경우가 많습니다.

그래서 역할 분리를 먼저 해두는 편이 낫습니다.

openstack coe nodegroup create \
  --node-count 2 \
  --min-nodes 2 \
  --max-nodes 6 \
  --flavor m1.large \
  --role worker \
  --labels workload=general \
  prod-k8s-01 general-workers

openstack coe nodegroup create \
  --node-count 1 \
  --min-nodes 0 \
  --max-nodes 4 \
  --flavor m1.xlarge \
  --role worker \
  --labels workload=batch \
  prod-k8s-01 batch-workers

openstack coe nodegroup list prod-k8s-01
openstack coe nodegroup show prod-k8s-01 batch-workers
openstack coe cluster resize --nodegroup general-workers prod-k8s-01 3

min_node_count=0은 확실히 매력적입니다. 다만 공식 릴리즈 노트 기준으로 scale-to-zero는 capi-helm-charts 0.26.0 이상과 cluster-api-provider-openstack 0.26.0 이상이 필요합니다. 조건이 안 맞으면 명시적 에러가 납니다. 이건 단순 옵션 문제가 아니라 플랫폼 버전 관리 문제로 봐야 합니다.

6. OpenStack Magnum 장애는 생성 실패보다 상태 전이 실패가 더 까다롭습니다

문서만 보면 클러스터 생성 성공 여부가 가장 중요해 보입니다. 그런데 실무에서는 CREATE_IN_PROGRESS가 왜 오래 가는지, DELETE_IN_PROGRESS에서 왜 자원이 남는지, 노드는 떴는데 왜 Ready가 안 되는지를 빨리 분리하는 쪽이 훨씬 중요합니다.

저는 장애를 볼 때 계층을 네 개로 나눠서 봅니다.

• Magnum API 계층: 요청이 접수되고 상태 전이가 시작됐는가
• OpenStack 인프라 계층: Nova, Neutron, Octavia, Cinder 자원이 기대대로 생성됐는가
• CAPI management cluster 계층: CRD와 controller가 reconciliation을 정상 수행하는가
• 워크로드 클러스터 계층: kubelet, CNI, CSI, addon이 정상 기동하는가

이 구분 없이 한 화면만 보면 시간이 꽤 많이 날아갑니다. 아래처럼 대조해 보는 습관이 실제로 편합니다.

openstack coe cluster show prod-k8s-01
openstack coe nodegroup list prod-k8s-01
openstack coe nodegroup show prod-k8s-01 general-workers
openstack server list --name prod-k8s-01
openstack loadbalancer list
kubectl --kubeconfig /etc/magnum/kubeconfig get clusters.cluster.x-k8s.io -A
kubectl --kubeconfig /etc/magnum/kubeconfig get machinedeployments.cluster.x-k8s.io -A
kubectl --kubeconfig /etc/magnum/kubeconfig get openstackmachines.infrastructure.cluster.x-k8s.io -A

이 명령 묶음이 좋은 이유는 분명합니다. Magnum에서 보이는 추상 상태와 CAPI에서 실제 reconcile 중인 객체 상태를 한 번에 비교할 수 있기 때문입니다.

7. 자주 막히는 실패 모드와 원인

7-1. Pod/Service CIDR 겹침: 증상은 Kubernetes인데 원인은 주소 설계일 때가 많습니다

최신 설정 레퍼런스의 기본값은 fixed_subnet_cidr=10.0.0.0/24, pod_network_cidr=10.100.0.0/16, service_network_cidr=172.24.0.0/13입니다. 공식 문서도 Pod/Service CIDR가 OpenStack provider나 external network subnet과 겹치면 안 된다고 설명합니다.

현장에서는 CNI부터 의심하기 쉽지만, 실제 원인이 Neutron 주소계획 충돌인 경우가 정말 있습니다. 이 부분은 감으로 보지 말고 숫자로 대조하는 게 빠릅니다.

openstack subnet list
openstack network list
openstack coe cluster template show k8s-capi-template -f yaml
openstack coe cluster show prod-k8s-01 -f yaml
kubectl get nodes -o wide
kubectl get pods -A -o wide

7-2. Cilium 선택: 지원과 운영 추천은 다른 말입니다

공식 릴리즈 노트에는 network_driver로 calico와 cilium을 선택할 수 있다고 나옵니다. 다만 magnum-capi-helm 구성 문서는 현재 정기 테스트가 Calico 중심이라고 적고 있습니다. 그래서 제 추천은 단순합니다. 운영 서비스 중심이면 Calico, 특정 네트워크 기능 검증이 목적이면 Cilium입니다.

7-3. scale-to-zero 실패: autoscaling보다 버전 매트릭스를 먼저 봐야 합니다

min_node_count=0이 안 먹는다면 autoscaler 설정만 볼 게 아닙니다. 공식 릴리즈 노트는 차트와 provider 버전 조건이 맞지 않으면 명시적으로 막는다고 설명합니다. 그래서 scale-to-zero 같은 기능은 사용자 문서보다 플랫폼 지원 매트릭스를 먼저 정리해 두는 게 훨씬 낫습니다.

7-4. DELETE_IN_PROGRESS 잔류: 상태 표시와 실자원 정리는 다를 수 있습니다

최신 릴리즈 노트에는 non-default node group 삭제 시 DELETE_IN_PROGRESS에 머물고 VM이 남는 이슈가 수정됐다고 나옵니다. 실무적으로 중요한 포인트입니다. 화면상 삭제 중인데 실제 자원 점유가 계속될 수 있기 때문이죠.

• Magnum 상태: nodegroup 또는 cluster 상태 전이
• 실자원 상태: Nova 인스턴스, 로드밸런서, 볼륨 잔존 여부

7-5. 인증서 저장: 동작보다 수명주기 관리가 더 중요합니다

Magnum 설치 가이드는 kubectl 접근용 TLS 인증서를 저장할 때 Barbican 사용을 권장합니다. 데이터베이스 저장도 가능하지만, 운영 환경에서는 누가 접근을 통제하고 어떻게 회전하고 감사 추적을 남길지가 더 중요하거든요. 이건 실제로 커질수록 차이가 크게 납니다.

8. 무엇을 보면 정상이라고 판단할까

클러스터가 생성됐다고 바로 정상 판정을 내리면 위험합니다. OpenStack 위의 KaaS는 클러스터 내부 상태와 OpenStack 연동 상태를 같이 봐야 하거든요. 저는 최소한 아래 네 묶음을 통과해야 초기 정상으로 봅니다.

openstack coe cluster show prod-k8s-01 -f yaml
kubectl get nodes
kubectl get pods -A
kubectl get storageclass
kubectl get pvc -A
kubectl cluster-info

• Cluster 상태: 상태가 완료로 수렴하는지, API 주소가 기대대로 생성됐는지 확인합니다.
• Node 상태: 모든 노드가 Ready인지 봅니다.
• 스토리지 상태: 기본 StorageClass가 의도한 reclaim policy와 binding mode를 사용하는지 확인합니다.
• API 접근 경로: 업그레이드 계획이 있다면 API endpoint가 로드밸런서 뒤에서 안정적으로 열리는지 확인해야 합니다.

그리고 하나 더요. 정상 판정은 단발성 스냅샷보다 상태 전이의 일관성으로 보는 편이 낫습니다. 생성 직후 잠깐 좋아 보이는 건 큰 의미가 없더라고요.

클러스터 생성 완료 후 노드 상태, 스토리지 클래스, API 엔드포인트, 로드밸런서 연결 상태를 함께 검증하는 장면을 표현한 이미지입니다.

9. 그래서 OpenStack Magnum은 언제 쓰고, 언제 쓰지 말아야 할까

• OpenStack이 이미 조직의 핵심 플랫폼이고, 프로젝트 단위로 Kubernetes를 표준 서비스처럼 공급해야 한다면 Magnum을 검토할 가치가 충분합니다.
• 기존 Heat 기반 Magnum 기억만으로 판단하면 안 됩니다. 공식 방향은 CAPI 계열에 집중돼 있습니다.
• 퍼블릭 클라우드 managed Kubernetes 제약이 없고 OpenStack 통합 요구가 약하면 Magnum을 굳이 들고 오지 않는 편이 낫습니다.
• 멀티테넌시, 내부망, 규제, 인증 통합, 스토리지 정책 일관성이 중요하면 Magnum 쪽 설득력이 커집니다.
• 신규 구축이면 처음부터 CAPI Helm 기준으로 설계하는 편이 낫습니다.
• 운영 안정성이 우선이면 Calico, 실험 목적이 분명할 때만 Cilium을 권합니다.
• autoscaling이 필요하면 nodegroup 분리부터 먼저 설계해야 합니다.
• 업그레이드를 생각한다면 API 로드밸런서를 전제로 잡는 편이 덜 아픕니다.

OpenStack Magnum을 도입해야 할 상황과 그렇지 않은 상황을 한눈에 비교하는 요약 이미지입니다.

10. 결론: OpenStack Magnum은 이제야 자기 자리를 찾는 중입니다

결론은 꽤 분명합니다. OpenStack Magnum은 지금 프라이빗 클라우드 안에서 Kubernetes를 OpenStack 자원처럼 제공하고 운영하려는 팀에게 다시 현실적인 선택지가 되고 있습니다. 유행이라서가 아니라 역할이 더 또렷해졌기 때문입니다.

물론 환상은 버려야 합니다. Magnum을 넣는다고 운영이 자동으로 쉬워지지는 않습니다. 대신 운영 난이도가 개별 팀의 임시 스크립트와 수작업에서 플랫폼 차원의 제어로 옮겨갑니다. 이 차이가 꽤 큽니다.

제 추천은 간단합니다. 기존 Heat 기반 환경은 CAPI 전환 검토를 시작하고, 신규 구축은 처음부터 CAPI Helm 기준으로 설계하세요. 반대로 OpenStack 통합 가치가 약한 조직이라면 외부 managed Kubernetes가 더 나을 수 있습니다. 이건 취향보다 운영 모델의 문제에 가깝습니다.

다음 단계까지 이어간다면 두 가지를 먼저 정리해 두면 좋겠습니다. 하나는 관리 클러스터 운영 책임 주체, 다른 하나는 지원할 chart/provider 버전과 nodegroup 정책 매트릭스입니다. 이 두 가지가 정리되면 OpenStack Magnum이 훨씬 덜 추상적으로 보입니다.

11. 참고한 공식 문서

• Magnum User Guide
• Magnum Installation Guide
• OpenStack CLI Magnum Commands
• Magnum CAPI Helm Driver Docs
• Magnum CAPI Helm Configuration Reference
• Magnum CAPI Helm Release Notes
• Magnum 2025.1 Release Notes