목차
- OpenStack Magnum이 여전히 의미 있는 이유
- OpenStack Magnum 핵심 개념: Magnum, Cluster Template, Heat
- 시작 전에 체크했던 항목들
- OpenStack Magnum으로 Kubernetes 클러스터 만들기
- 1. 기본 리소스 확인
- 2. Cluster Template 생성
- 3. 클러스터 생성
- 4. cluster config 가져와서 접속
- 5. 간단한 워크로드 배포
- 6개월 운영하면서 좋았던 점
- 운영하면서 부딪힌 문제와 트러블슈팅
- 1. 문제를 Kubernetes에서만 찾으면 늦습니다
- 2. 업그레이드 전략은 미리 정해야 합니다
- 3. 네트워크 플러그인과 외부 노출은 가장 먼저 검증해야 합니다
- 4. 노드 장애 복구는 '재현 가능성'이 핵심입니다
- 검증과 결과: 운영 기준으로 무엇을 확인했나
- 어떤 환경에 잘 맞고, 어떤 경우엔 아쉬운가
- 정리와 다음 단계
- 자주 묻는 질문 FAQ
- Magnum이 있으면 Kubernetes 운영이 쉬워지나요?
- Magnum과 kubeadm 중 무엇이 더 낫나요?
- 6개월 운영 기준으로 가장 먼저 챙길 것은 무엇인가요?
OpenStack Magnum Kubernetes 운영: 6개월 회고와 교훈
OpenStack Magnum Kubernetes 조합으로 클러스터를 6개월 정도 운영해보면, 처음 기대했던 포인트와 실제 운영 포인트가 꽤 다르다는 걸 느끼게 됩니다. 저도 처음엔 'OpenStack 위에서 Kubernetes를 좀 더 쉽게 만들 수 있겠네?' 정도로 접근했는데, 막상 돌려보니 편한 부분은 분명했고 반대로 운영자가 꼭 알아야 하는 제약도 꽤 있더라고요. 특히 사내 프라이빗 클라우드나 홈랩처럼 OpenStack 자원이 이미 깔린 환경에서는 Magnum 사용 후기를 많이 찾게 되는데, 실제로는 설치보다 운영이 더 중요했습니다. 이번 글은 OpenStack Magnum Kubernetes 환경을 6개월 운용하면서 느낀 점, 부딪힌 문제, 그리고 어떤 팀에 잘 맞는지 차분하게 정리한 회고입니다.
혹시 이런 경험 있으신가요? 클러스터는 금방 만들었는데 업그레이드, 노드 교체, 네트워크 연결, 외부 로드밸런서 연동에서 갑자기 난도가 확 올라가는 순간 말이죠. 저도 딱 그랬습니다. 생성이 끝났다고 안심했는데, 운영은 또 다른 문제더라고요.
Magnum, OpenStack, Kubernetes 워커 노드와 로드밸런서 관계를 보여주는 전체 구성도입니다.
OpenStack Magnum이 여전히 의미 있는 이유
쉽게 말해 Magnum은 OpenStack에서 COE(Container Orchestration Engine) 클러스터를 프로비저닝하는 서비스입니다. 과거 문서에는 Mesos나 Swarm도 함께 언급됐지만, 최근 공식 문서 기준으로는 사실상 Kubernetes 중심으로 보는 편이 맞습니다. OpenStack을 이미 쓰고 있다면 가상머신 인프라를 따로 만들고 그 위에 수동으로 kubeadm을 올리는 대신, OpenStack API와 템플릿 기반으로 클러스터 생성 흐름을 어느 정도 표준화할 수 있다는 점이 장점이거든요.
제가 직접 써보니 이 지점이 꽤 중요했습니다. 인프라 팀 입장에서는 Nova, Neutron, Cinder, Octavia 같은 OpenStack 리소스 운영 경험이 이미 있잖아요. Magnum은 그 위에서 Kubernetes 클러스터를 조금 더 OpenStack스럽게 관리하게 해줍니다. 다만 완전한 Managed Kubernetes처럼 기대하면 실망할 수 있습니다. 제 경험상 Magnum은 '운영을 없애주는 도구'라기보다 'OpenStack 친화적인 클러스터 생성 자동화 계층'으로 이해할 때 만족도가 높았습니다.
OpenStack Magnum 핵심 개념: Magnum, Cluster Template, Heat
처음엔 이 구조가 꽤 헷갈렸는데, 큰 그림을 이해하고 나면 훨씬 수월해집니다. 여기서 중요한 포인트는 Magnum이 혼자 모든 걸 하는 게 아니라는 점입니다.
- Magnum: Kubernetes 같은 COE 클러스터를 생성하고 관리하는 OpenStack 서비스입니다.
- Cluster Template: 어떤 이미지, 네트워크, 플러그인, 노드 사양으로 클러스터를 만들지 정의하는 청사진입니다.
- Heat: 전통적인 Magnum 배포에서 실제 인프라 스택을 구성하는 오케스트레이션 계층입니다. 장애를 파고들다 보면 결국 Heat 이벤트를 보게 되더라고요.
- BayModel: 과거 명칭입니다. 최신 문서와 운영 맥락에서는 보통 Cluster Template 기준으로 보면 됩니다.
한 줄로 요약하면 이렇습니다. Magnum이 요청을 받고, Cluster Template을 참고해 OpenStack 자원을 만들고, 전통적인 드라이버 환경에서는 Heat가 실제 스택 생성을 수행하는 구조입니다. 참고로 최근 공식 문서에서는 Heat 기반 드라이버가 deprecated로 안내되고 있어서, 운영 중인 환경이 어떤 드라이버를 쓰는지도 꼭 확인해두는 게 좋습니다.
| 구성 요소 | 역할 | 운영할 때 봐야 할 포인트 |
|---|---|---|
| Magnum | 클러스터 생성/삭제 요청 처리 | API 상태, 템플릿 파라미터, 사용 중인 드라이버 |
| Heat | 스택 생성과 자원 오케스트레이션 | 이벤트 로그, 실패 리소스 추적 |
| Neutron/Octavia | 네트워크와 로드밸런서 | 외부 연결, 서비스 노출, 포트/보안그룹 |
| Kubernetes | 워크로드 스케줄링과 운영 | 노드 상태, CNI, Ingress, 스토리지 |
시작 전에 체크했던 항목들
Magnum 사용 후기에서 잘 안 보이는데, 실제로는 사전 점검이 절반입니다. 저도 처음엔 클러스터 생성 명령부터 쳤다가 네트워크랑 이미지 때문에 한참 돌아갔거든요.
- OpenStack 서비스 상태 확인
Magnum만 살아 있어도 되는 게 아니라 Keystone, Nova, Neutron, Glance, Heat가 기본적으로 안정적이어야 합니다. - Kubernetes용 이미지 준비
이미지 이름보다 더 중요한 건 클러스터 드라이버 요구사항입니다. 최근 공식 문서 기준으로는 Kubernetes용 이미지의os_distro메타데이터가 드라이버와 맞아야 하고, 기본 예시는 Fedora CoreOS 계열을 전제로 설명합니다. - 외부 네트워크와 DNS 설계
API 접근, 노드 egress, 이미지 pull 경로를 미리 봐야 합니다. - Load Balancer 정책 확인
마스터 API 엔드포인트와 Service 노출 방식이 Octavia와 어떻게 연결되는지 미리 확인해야 합니다. - 스토리지 전략 결정
Cinder 연동 방식을 어떻게 가져갈지, 동적 볼륨 전략을 초반부터 쓸지 미리 정해두는 게 좋습니다.
OpenStack Magnum으로 Kubernetes 클러스터 만들기
이제 실전입니다. 아래 예시는 홈랩과 테스트 환경에서 자주 확인하던 흐름을 기준으로 정리했습니다. 다만 배포판, 드라이버, OpenStack 릴리스에 따라 옵션 이름이나 권장 이미지가 달라질 수 있습니다. 그래서 핵심은 명령어를 외우는 것보다 어떤 리소스를 먼저 확인해야 하는지를 잡는 데 있습니다.
1. 기본 리소스 확인
openstack coe service list
openstack network list
openstack subnet list
openstack image list
openstack flavor list
openstack keypair list여기서 네트워크, 서브넷, 이미지, flavor, keypair가 실제로 준비되어 있는지 먼저 봅니다. 이거 안 보고 바로 템플릿 만들면 높은 확률로 다시 돌아오게 됩니다.
2. Cluster Template 생성
openstack coe cluster template create k8s-template \
--coe kubernetes \
--image fedora-coreos-k8s \
--external-network public \
--fixed-network private-net \
--fixed-subnet private-subnet \
--flavor m1.medium \
--master-flavor m1.medium \
--docker-storage-driver overlay2 \
--network-driver flannel \
--volume-driver cinder \
--floating-ip-enabled \
--master-lb-enabled여기서 실수가 가장 많이 나왔습니다. 특히 external-network, fixed-network, image 조합이 안 맞으면 생성이 중간에 터지더라고요. 처음엔 Magnum 문제인 줄 알았는데, 파고 들어가면 Neutron 설정이나 이미지 메타데이터 문제인 경우가 많았습니다. 이미지 이름은 예시일 뿐이고, 실제 환경에서는 해당 드라이버가 요구하는 이미지 속성을 꼭 확인하셔야 합니다.
Cluster Template이 네트워크, 이미지, 플레버, 로드밸런서와 연결되는 흐름을 설명하는 다이어그램입니다.
3. 클러스터 생성
openstack coe cluster create k8s-prod-like \
--cluster-template k8s-template \
--master-count 1 \
--node-count 3 \
--keypair mykey테스트 환경에서는 master-count와 node-count를 보수적으로 시작하는 게 좋습니다. 처음부터 크게 만들면 실패 원인도 커지고, 디버깅 비용도 같이 올라갑니다. 저는 1 control plane, 2~3 worker부터 시작해서 네트워크와 스토리지가 안정적인지 먼저 봤습니다.
4. cluster config 가져와서 접속
mkdir -p k8s-prod-like-config
openstack coe cluster config k8s-prod-like --dir k8s-prod-like-config
export KUBECONFIG=$(pwd)/k8s-prod-like-config/config
kubectl get nodes
kubectl get pods -A이 단계는 환경에 따라 조금 다릅니다. 어떤 환경에서는 eval $(openstack coe cluster config <cluster-name>) 형태로 바로 접속하기도 하고, 어떤 환경에서는 생성된 config 파일을 KUBECONFIG로 잡아 쓰는 식이 더 명확했습니다. 생성 직후에는 CNI가 아직 완전히 올라오지 않은 경우도 있으니 몇 분 정도 여유를 두고 확인하는 게 좋습니다.
5. 간단한 워크로드 배포
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-nginx
spec:
replicas: 2
selector:
matchLabels:
app: demo-nginx
template:
metadata:
labels:
app: demo-nginx
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
---apiVersion: v1
kind: Service
metadata:
name: demo-nginx
spec:
selector:
app: demo-nginx
ports:
- port: 80
targetPort: 80
type: LoadBalancerkubectl apply -f demo-nginx.yaml
kubectl get deploy,svc,pods이 단계에서 OpenStack Magnum Kubernetes 환경이 정말 내 환경에서 굴러가는지 감이 옵니다. Service가 외부 IP를 잘 받는지, Pod가 정상 스케줄링되는지, 노드 간 통신이 되는지까지 같이 볼 수 있거든요.
6개월 운영하면서 좋았던 점
장점은 분명합니다. 특히 인프라 팀이 OpenStack에 익숙할수록 체감이 큽니다.
- 클러스터 생성 표준화: 템플릿 기반이라 환경 복제가 수월했습니다.
- OpenStack 권한 체계와 잘 맞음: 프로젝트 단위 자원 분리가 익숙해서 운영 흐름이 덜 낯설었습니다.
- 홈랩 실험에 좋음: kubeadm을 매번 손으로 치는 것보다 반복 실험이 편하더라고요.
- 자원 가시성 확보: VM, 볼륨, 포트, 로드밸런서를 OpenStack 관점에서 같이 추적할 수 있었습니다.
특히 여러 팀이 비슷한 Kubernetes 클러스터 운영 패턴을 가져가야 한다면 Cluster Template은 생각보다 강력합니다. 누가 만들어도 기본 뼈대가 크게 흔들리지 않거든요. 이건 실제로 꽤 편했습니다.
운영하면서 부딪힌 문제와 트러블슈팅
여기가 진짜 중요했습니다. OpenStack Magnum Kubernetes 글을 보면 설치 데모는 많아도, 운영 중 생기는 문제는 상대적으로 덜 보이더라고요. 그런데 결국 운영은 장애와 변경 관리 싸움이었습니다.
1. 문제를 Kubernetes에서만 찾으면 늦습니다
Pod가 안 뜨거나 Service 외부 노출이 안 되면 처음엔 kubectl만 보게 됩니다. 저도 그랬습니다. 그런데 실제 원인은 Heat 스택 실패, 보안그룹 규칙, Neutron 포트 상태, Octavia 리스너 문제인 경우가 적지 않았습니다.
openstack stack list
openstack stack resource list <stack-name>
openstack stack event list <stack-name>여기서 중요한 포인트는 Magnum 장애 분석에는 Kubernetes와 OpenStack을 같이 보는 시야가 필요하다는 점입니다. 한쪽만 보면 원인을 놓치기 쉽습니다.
2. 업그레이드 전략은 미리 정해야 합니다
Kubernetes 클러스터 운영에서 가장 민감한 건 업그레이드입니다. Magnum이 있다고 해서 업그레이드가 마법처럼 쉬워지는 건 아니었습니다. 오히려 템플릿, 이미지, 애드온, CNI 버전 호환성을 같이 보게 되더라고요. 그래서 운영 중반부터는 '인플레이스 업그레이드에 집착하지 말고, 새 템플릿 기반 병행 클러스터를 검증한 뒤 전환하자' 쪽으로 사고를 바꿨습니다.
조금 번거로워 보여도 결과적으로는 더 안전했습니다. 특히 사내 서비스나 장기 운영 워크로드가 얹힌 상태라면 더 그렇습니다.
3. 네트워크 플러그인과 외부 노출은 가장 먼저 검증해야 합니다
Ingress나 LoadBalancer 서비스가 기대대로 동작하지 않으면, 사용자 입장에서는 클러스터가 죽은 것처럼 보입니다. 실제로 써보니까 네트워크 드라이버와 OpenStack 네트워크 설계가 맞물리는 구간이 생각보다 까다로웠습니다.
- Node 간 Pod 통신 확인
- API 서버 접근 경로 확인
- 외부 IP 할당 정책 확인
- 보안그룹 인바운드/아웃바운드 확인
처음엔 애플리케이션 문제인 줄 알았는데, 보안그룹 한 줄 빠진 거여서 허탈했던 적도 있습니다. 이런 삽질이 은근 많더라고요.
4. 노드 장애 복구는 '재현 가능성'이 핵심입니다
노드 하나가 망가졌을 때 수동 조치만으로 복구가 되면 당장은 편합니다. 그런데 그게 반복 가능하지 않으면 다음 장애 때 더 힘들어집니다. 저는 6개월 운영하면서 로그를 많이 남겼고, 결국에는 '노드 문제는 수동 응급조치보다 템플릿과 생성 절차 정비가 우선'이라는 결론을 내렸습니다.
검증과 결과: 운영 기준으로 무엇을 확인했나
클러스터가 떴다는 것과 운영 가능한 상태라는 것은 다릅니다. 저는 아래 순서로 검증했습니다.
- 노드 Ready 상태 확인
- CoreDNS, CNI, kube-proxy 같은 기본 시스템 Pod 확인
- LoadBalancer 서비스 외부 노출 확인
- Persistent Volume 동작 확인
- 재부팅 또는 노드 교체 후 상태 재확인
kubectl get nodes
kubectl get pods -A
kubectl get svc -A
kubectl get storageclass
kubectl describe node <node-name>간단하지만 이 체크리스트가 꽤 유효했습니다. 6개월 동안 느낀 건, OpenStack Magnum Kubernetes 환경에서는 처음 생성 성공보다 반복 검증 성공이 훨씬 중요하다는 점입니다.
노드 Ready 상태, 시스템 Pod, 서비스 외부 IP 상태를 함께 보여주는 결과 확인 이미지입니다.
운영 결과를 한 줄로 정리하면 이렇습니다. 소규모 프라이빗 클라우드나 내부 플랫폼 팀 환경에서는 충분히 의미가 있지만, 모든 운영 복잡도를 감춰주는 도구는 아니다. 이 기대치만 정확하면 꽤 만족스럽게 사용할 수 있습니다.
어떤 환경에 잘 맞고, 어떤 경우엔 아쉬운가
| 상황 | Magnum 적합도 | 이유 |
|---|---|---|
| OpenStack 중심의 내부 인프라 팀 | 높음 | 기존 운영 지식과 연결되기 좋습니다. |
| 홈랩/검증 환경 | 높음 | 반복 생성과 실험에 유리합니다. |
| 완전관리형 서비스 기대 | 낮음 | 운영자가 알아야 할 영역이 여전히 넓습니다. |
| 빠른 버전 전환이 잦은 환경 | 중간 | 이미지, 템플릿, 네트워크 호환성 검증이 필요합니다. |
저도 처음엔 Magnum이 조금 더 많은 걸 알아서 해주길 기대했었습니다. 그런데 6개월 써보니 관점을 바꾸게 되더라고요. Magnum은 운영을 없애주는 도구가 아니라, OpenStack 안에서 Kubernetes 클러스터 운영의 출발점을 정리해주는 도구에 가깝습니다. 이 차이를 이해하면 만족도가 확 올라갑니다.
수동 kubeadm 방식과 Magnum 기반 운영 방식의 차이를 요약한 비교 인포그래픽입니다.
정리와 다음 단계
정리해보면, OpenStack Magnum으로 Kubernetes 클러스터 운영을 해보면서 얻은 교훈은 꽤 명확했습니다.
- Magnum은 생성 자동화에 강점이 있습니다.
- 운영 문제는 결국 OpenStack과 Kubernetes를 함께 봐야 풀립니다.
- 업그레이드와 네트워크 검증은 초반 설계 단계에서 방향을 잡아야 덜 힘듭니다.
- 작게 시작해서 반복 검증하는 방식이 가장 현실적이었습니다.
지금 OpenStack 기반으로 클라우드 네이티브 환경을 고민하고 계시다면 Magnum은 충분히 검토할 만한 선택지입니다. 다만 Managed Kubernetes처럼 생각하면 실망할 수 있고, OpenStack 친화적인 클러스터 프로비저닝 계층으로 이해하면 훨씬 잘 맞습니다. 관련해서 이전에 정리한 OpenStack 네트워크 기본기 글이나 스토리지 구성 글도 함께 보면 이해가 훨씬 빨라집니다.
다음 글에서는 이번 회고에서 살짝 언급했던 Ingress 구성, Cinder 기반 스토리지 연결, 그리고 운영 중 모니터링 포인트를 따로 묶어서 정리해보려 합니다. 이어서 보면 실제 운영 흐름이 더 선명하게 보이실 거예요.
자주 묻는 질문 FAQ
Magnum이 있으면 Kubernetes 운영이 쉬워지나요?
일부는 맞고, 일부는 아닙니다. 클러스터 생성과 표준화는 확실히 편해집니다. 하지만 장애 분석, 네트워크, 업그레이드 전략은 여전히 운영자의 몫입니다.
Magnum과 kubeadm 중 무엇이 더 낫나요?
OpenStack 환경 표준화가 중요하면 Magnum이 편합니다. 반대로 세밀한 수동 제어가 더 중요하고 OpenStack 통합이 핵심이 아니라면 kubeadm 쪽이 더 단순하게 느껴질 수도 있습니다.
6개월 운영 기준으로 가장 먼저 챙길 것은 무엇인가요?
네트워크와 업그레이드 전략입니다. 이 두 가지를 초반에 대충 잡으면 나중에 운영 피로도가 크게 올라갑니다.
'IT > openstack' 카테고리의 다른 글
| [인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈 (0) | 2026.07.27 |
|---|---|
| [OpenStack] OpenStack Barbican 보안: 민감 데이터 관리 체크리스트 (0) | 2026.07.24 |
| [OpenStack] RDO OpenStack 마이그레이션: DevStack에서 운영형 배포로 전환하기 (1) | 2026.07.24 |
| [OpenStack] DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드 (1) | 2026.07.20 |
| [OpenStack] OpenStack Glance 이미지 관리, 효율적인 스토리지 활용 전략 (1) | 2026.07.20 |
| [OpenStack] OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석 (0) | 2026.07.19 |
