왜 VMware에서 Kubernetes로의 마이그레이션이 빨라지고 있는가
예전에는 VMware 마이그레이션 논의를 미루기 쉬웠습니다. 많은 조직이 라이선스 복잡성, 하드웨어 결합, 스토리지 오버헤드를 감수했는데, 운영 모델이 익숙했고 변화 비용이 너무 커 보였기 때문입니다.
하지만 그 계산이 바뀌었습니다. 이제 인프라 리더는 세 가지 질문에 답해야 합니다.
- 가상 머신과 상태 저장 애플리케이션을 위한 장기 플랫폼은 무엇인가?
- VMware 시대의 스토리지 가정을 다음 환경으로 어떻게 끌고 가지 않을 것인가?
- 운영 혼란 없이 어떻게 단계적으로 마이그레이션할 것인가?
점점 더 많은 팀에게 답은 “VMware를 또 다른 고립된 하이퍼바이저 스택으로 교체하는 것”이 아닙니다. 대신 Kubernetes를 현대 인프라의 운영 모델로 삼고, OpenShift, Rancher, Talos 또는 upstream Kubernetes 같은 운영 환경을 선택하며, 가상 머신이 여전히 중요하다면 KubeVirt를 사용하는 방향입니다.
그렇다고 모든 워크로드가 하루아침에 컨테이너가 된다는 뜻은 아닙니다. 팀이 자신의 일정에 맞춰 현대화하는 동안 목표 플랫폼이 두 세계를 모두 지원할 수 있다는 뜻입니다.
현실적인 VMware-to-Kubernetes 목표 아키텍처는 어떤 모습인가
현실적인 목표 아키텍처는 네 개의 계층으로 이루어집니다.
- Kubernetes는 오케스트레이션, 정책, 자동화, 라이프사이클 관리를 위한 제어면입니다.
- OpenShift, Rancher, Talos 또는 upstream Kubernetes는 팀이 표준화할 운영 환경입니다.
- KubeVirt는 VM 워크로드가 남아 있을 때 Kubernetes 내부에서 VM을 실행하기 위한 가상화 계층입니다.
- Simplyblock은 VM 디스크, 스냅샷, 클론, 상태 저장 데이터를 위한 영구 블록 스토리지 플랫폼입니다.
이것이 중요한 이유는 VMware 마이그레이션 프로젝트가 보통 슬라이드에서가 아니라 스토리지와 운영 계층에서 실패하기 때문입니다. Kubernetes에서 VM을 실행하는 것은 가능합니다. 하지만 적절한 성능 프로파일, 데이터 서비스, day-2 운영 특성을 갖춘 상태로 실행하는 것이 실험과 진짜 목적지 플랫폼을 가르는 기준입니다.
Simplyblock은 현대 환경을 위해 설계된 NVMe-first 스토리지 계층으로 이 문제를 해결하도록 돕습니다. 팀은 Kubernetes 네이티브 스토리지에서 시작하고, 플랫폼을 OpenShift, Rancher by SUSE, Talos에 맞게 정렬하면서, VM 사용 사례를 위해 KubeVirt 스토리지를 추가할 수 있습니다. 같은 스토리지 기반이 시간이 지나면서 더 넓은 프라이빗 클라우드나 플랫폼 엔지니어링 모델까지 지원할 수 있습니다.
어떤 대상 플랫폼이 가장 잘 맞는가
모든 VMware 마이그레이션이 같은 Kubernetes 배포판이나 같은 운영 모델에 안착하는 것은 아닙니다. 더 좋은 질문은 어떤 제어면과 어떤 운영 패턴이 팀, 규정 준수 요구사항, 라이프사이클 기대치에 가장 잘 맞는가입니다.
엔터프라이즈 플랫폼 표준화를 위한 OpenShift
이미 Red Hat에 맞춰진 팀은 클러스터 전반에서 정책, 보안, 운영을 일관되게 유지하는 마이그레이션 경로를 원하는 경우가 많습니다. 대상이 OpenShift이고 스토리지 계층이 OpenShift 네이티브 운영과 깔끔하게 작동해야 한다면 OpenShift용 Simplyblock이 가장 관련 있는 경로입니다.
멀티 클러스터 플릿 관리를 위한 Rancher
여러 비즈니스 유닛, 지역 또는 고객에 걸쳐 Kubernetes 환경을 운영하는 조직은 Rancher를 운영 계층으로 선호하는 경우가 많습니다. Rancher by SUSE용 Simplyblock과 Simplyblock + Rancher 가상화 번들은 중앙 집중형 클러스터 관리와 현대적 스토리지가 함께 필요한 목표 상태에 적합한 참고 자료입니다.
최소한의 API 기반 Kubernetes 인프라를 위한 Talos
어떤 팀은 VMware 시대의 운영 패턴뿐 아니라 범용 Linux 노드가 가져오는 드리프트까지 함께 떠나고 싶어 합니다. Talos용 Simplyblock과 Simplyblock + Talos 가상화 번들은 더 간결하고 선언적인 Kubernetes 플랫폼을 목표로 할 때 가장 좋은 기준점입니다.
가상 머신이 여전히 필요한 경우의 KubeVirt
가상 머신이 환경의 일부로 남아 있다면 KubeVirt는 기존 자산과 새로운 운영 모델 사이의 다리가 됩니다. KubeVirt 스토리지는 simplyblock이 VM 디스크, 스냅샷, 클론, 성능 민감형 가상화 워크로드를 Kubernetes에서 어떻게 지원하는지 보여줍니다.
어떤 워크로드를 먼저 옮겨야 하는가
VMware 마이그레이션은 가장 어렵고 비즈니스 크리티컬한 VM 자산부터 시작할 필요가 없습니다. 실제로 가장 좋은 첫 번째 물결은 불필요한 마이그레이션 위험 없이 목표 아키텍처를 검증하는 데 도움이 되는 워크로드를 포함하는 경우가 많습니다.
좋은 초기 후보는 다음과 같습니다.
- 개발 및 테스트 VM
- 성능 요구가 중간 수준인 내부 비즈니스 서비스
- 플랫폼 팀이 관리하는 공유 서비스
- 이미 Kubernetes 환경과 나란히 존재하는 VM 기반 애플리케이션
- 그렇지 않으면 기본적으로 VMware에 배치될 신규 워크로드
이런 마이그레이션은 팀이 운영 모델을 입증하고, 스토리지 동작을 검증하며, 더 큰 프로덕션 자산을 옮기기 전에 플랫폼을 다듬는 데 도움을 줍니다.
보통 더 깊은 설계가 필요한 워크로드는 다음과 같습니다.
- 지연시간에 매우 민감한 데이터베이스
- 규제 요건이 강한 시스템
- 환경에 대한 가정이 강한 레거시 어플라이언스
- 복잡한 네트워크 및 백업 의존성을 가진 대규모 VM 자산
이런 워크로드도 옮길 수는 있지만, 목표 플랫폼이 충분히 검증되고 표준화된 이후에 움직이는 편이 좋습니다.
절대 무시할 수 없는 스토리지 요구사항
VMware에서 Kubernetes로의 마이그레이션을 진지하게 생각한다면, 스토리지는 나중에 붙이는 항목이 될 수 없습니다.
1. VM 성능은 여전히 중요하다
KubeVirt로 옮긴 가상 머신이 Kubernetes 위에서 실행된다고 해서 시끄러운 스토리지를 갑자기 견딜 수 있게 되는 것은 아닙니다. 특히 데이터베이스, 미들웨어, 내부 플랫폼의 경우 예측 가능한 지연시간, 안정적인 처리량, 일관된 IOPS가 계속 필요합니다.
2. 스냅샷, 클론, 복구는 운영 요구사항이다
마이그레이션 프로젝트는 종종 컴퓨트 배치에 집중하고 스토리지 워크플로의 중요성을 놓칩니다. 팀은 여전히 가상 디스크와 상태 저장 데이터에 대해 동작하는 스냅샷, 클론, 백업 연동, 복구 프로세스를 필요로 합니다.
3. 멀티테넌시와 QoS가 더 중요해진다
Kubernetes가 공유 플랫폼이 될수록 서로 다른 테넌트와 워크로드가 같은 인프라를 두고 경쟁하게 됩니다. 스토리지는 단순 용량이 아니라 명확한 성능 제어와 격리를 제공해야 합니다. 대상 플랫폼이 여러 팀, 사업부, 서비스 환경을 지원해야 한다면 특히 중요합니다.
4. 독립적 확장은 실제 경제적 레버다
소프트웨어 정의 인프라의 큰 장점 중 하나는 컴퓨트와 스토리지가 항상 함께 확장될 필요가 없다는 점입니다. 이는 VMware 대체 프로젝트에서 중요합니다. 레거시 가상화 환경은 비싼 번들 용량 뒤에 비효율적인 확장 패턴을 숨기는 경우가 많기 때문입니다.
바로 이 지점에서 소프트웨어 정의 스토리지와 NVMe over TCP 스토리지가 단순히 기술적으로 흥미로운 수준을 넘어 전략적으로 중요해집니다.
리스크를 줄이는 단계별 마이그레이션 계획
대부분의 팀은 VMware 마이그레이션을 한 번의 컷오버가 아니라 플랫폼 마일스톤의 연속으로 생각해야 합니다.
1단계: 현재 자산 평가
현재 VMware 환경의 워크로드, 스토리지 패턴, 복구 기대치, 운영 의존성을 파악하세요. 무엇을 먼저 옮기기 쉬운지, 무엇이 더 많은 설계가 필요한지 식별합니다.
2단계: 목표 플랫폼 구축
Kubernetes를 세우고, 운영 모델이 OpenShift인지 Rancher인지 Talos인지 upstream Kubernetes인지 정의하고, VM이 범위에 남아 있다면 KubeVirt를 검증하며, 그 아래에 적절한 스토리지 계층을 배치합니다. 이 단계에서 스토리지 성능, 스냅샷, 클론, 테넌트 격리를 테스트해야지, 당연시하면 안 됩니다.
3단계: 저위험 워크로드부터 이전
초기 마이그레이션을 통해 다음을 검증하세요.
- VM 라이프사이클 워크플로
- 스토리지 성능 특성
- 백업 및 복구 프로세스
- 운영 소유권
- 관측성과 지원 런북
4단계: VM과 컨테이너의 혼합 운영으로 확장
플랫폼이 입증되면 팀은 같은 Kubernetes 기반 위에서 가상 머신과 컨테이너화된 워크로드를 함께 지원할 수 있습니다. 일반적으로 이 시점부터 새로운 모델이 운영 및 재무 측면의 레버리지를 만들어 내기 시작합니다.
5단계: 전략적 상태 저장 워크로드 이동
플랫폼이 안정화되면 팀은 더 중요한 VM 서비스와 상태 저장 서비스를 성능, 확장성, 복구에 대한 더 큰 확신을 가지고 이전할 수 있습니다.
왜 simplyblock이 VMware 마이그레이션 프로그램에 도움이 되는가
simplyblock은 VMware-to-Kubernetes 전략에서 가장 어려운 현실적 공백 중 하나를 해결하기 때문에 중요합니다. 바로 레거시 스토리지 아키텍처의 비용과 복잡성을 끌고 오지 않으면서 가상 머신과 상태 저장 워크로드를 위한 현대적인 블록 스토리지를 제공하는 일입니다.
마이그레이션 프로그램에서 이것은 보통 다음을 의미합니다.
- 공유 플랫폼에서 VM 디스크와 영구 데이터를 지원하기
- 하드웨어 제약형 스토리지 스택에 대한 의존도 줄이기
- 플랫폼 워크플로 일부로 스냅샷과 클론 활성화하기
- 시간이 지나면서 비용 예측 가능성 높이기
- 플랫폼 팀에 Kubernetes 운영에 맞는 스토리지 계층 제공하기
이는 목표 상태가 단순히 “VMware에서 벗어나기”가 아니라 “가상화 및 클라우드 네이티브 워크로드를 위한 더 나은 장기 플랫폼 구축”일 때 특히 유용합니다.
그것이 목표라면, 이 페이지는 다음과 함께 읽는 것이 좋습니다.
- OpenShift 스토리지
- Rancher by SUSE 스토리지
- Talos 스토리지
- Simplyblock + Rancher 가상화 번들
- Simplyblock + Talos 가상화 번들
- KubeVirt 스토리지
- Kubernetes 스토리지
- Kubernetes용 영구 스토리지
- VMware vs Kubernetes
- KubeVirt vs VMware
VMware에서 Kubernetes로의 마이그레이션 FAQ
Kubernetes가 정말 VMware의 대체재인가요?
직접적으로는 아닙니다. Kubernetes는 오케스트레이션 플랫폼이고 VMware는 가상화 플랫폼입니다. 더 현실적인 모델은 OpenShift, Rancher, Talos 같은 적절한 운영 계층과, 가상 머신이 계속 중요할 때의 KubeVirt, 그리고 VM과 상태 저장 워크로드를 지원하는 스토리지 플랫폼을 Kubernetes와 함께 사용하는 것입니다. 제대로 설계한다면 이 조합은 VMware 중심 인프라의 상당 부분을 대체할 수 있습니다.
모든 VMware 워크로드가 Kubernetes로 가야 하나요?
아니요. 어떤 워크로드는 다른 것보다 초기 마이그레이션 후보로 더 적합합니다. 올바른 목표는 이념적 순수성이 아니라, 맞는 워크로드를 옮기고 더 나은 목표 플랫폼을 만들며 다음 10년의 인프라가 같은 옛 제약에 묶이지 않도록 하는 것입니다.
VMware 마이그레이션에서 왜 스토리지가 그렇게 중요한가요?
가상 머신 마이그레이션의 성공은 컴퓨트만으로 결정되지 않기 때문입니다. VM 디스크, 스냅샷, 복구, 예측 가능한 지연시간, 워크로드 격리는 모두 스토리지 계층에 달려 있습니다. 약한 스토리지 설계는 유망한 마이그레이션을 나쁜 운영 경험으로 바꿀 수 있습니다.
OpenShift, Rancher, Talos, KubeVirt 중 하나만 선택해야 하나요?
아니요. OpenShift, Rancher, Talos는 Kubernetes 주변의 운영 환경을 설명합니다. KubeVirt는 그 환경 안에서 가상 머신을 실행하게 해주는 가상화 계층입니다. 이들은 목표 아키텍처의 서로 다른 부분을 해결하며 동일한 simplyblock 스토리지 계층과 함께 사용할 수 있습니다.
VMware 탈출 전략에서 KubeVirt의 역할은 무엇인가요?
KubeVirt는 Kubernetes 내부에서 가상 머신을 실행할 수 있게 하므로, 팀이 하나의 제어면에 표준화하면서도 VM 기반 애플리케이션을 계속 지원할 수 있게 합니다. 그래서 모든 워크로드를 즉시 컨테이너화하지 않고 현대화를 원하는 조직에 실용적인 다리가 됩니다.
팀은 언제부터 마이그레이션 계획을 시작해야 하나요?
대개 생각보다 더 일찍입니다. 실행이 단계적으로 이루어진다 해도 플랫폼 설계, 워크로드 평가, 스토리지 검증에는 시간이 필요합니다. 일찍 시작할수록 선택지가 많아지고 나중에 반응적으로 의사결정을 해야 하는 압박도 줄어듭니다.