본문으로 건너뛰기
VMware vSphere Kubernetes Service (VKS) · VMware Kubernetes Deployment & Management Platform

가상 머신과 컨테이너의 통합 운영,
완벽한 아키텍처 설계에서 시작됩니다

가상 머신과 컨테이너를 동일한 인프라에서 효율적으로 운영하는 핵심은 철저한 ‘설계’에 있습니다. VKS(vSphere Kubernetes Service)는 기존 vSphere 자원 환경 위에 Kubernetes 클러스터를 빠르고 안전하게 배포할 수 있도록 지원합니다. 하지만 성공적인 도입을 위해서는 기술 적용을 넘어 워크로드 성격에 따른 정확한 역할 분담이 선행되어야 합니다. 소프트웍스는 인프라 전문 엔지니어링 역량을 바탕으로 어떤 워크로드를 VKS에 배치하는 것이 가장 효과적인지 처음부터 함께 검토합니다. 복잡한 컨테이너 인프라 전환 과정에서 시행착오를 없애고, 가장 안정적이고 확장 가능한 모던 클라우드 환경을 완성합니다.

Why Softworks

소프트웍스가 VMware vSphere Kubernetes Service를 다루는 방식

01

Kubernetes 및 VKS를 독립된 핵심 기술 영역으로 깊이 있게 수행합니다

소프트웍스는 Kubernetes 기반 인프라 구축과 운영을 별도의 핵심 사업 영역으로 전문화하여 수행하고 있습니다. 대부분의 가상화 사업자가 VKS를 단순한 부속 기능으로 접하는 것과 달리, 수많은 클러스터 통합 관리와 GPU 자원 분할 관리 등 고도화된 컨테이너 환경 구축 노하우를 축적해 왔습니다. vSphere 환경과 VKS가 유기적으로 맞물려 최고의 성능을 낼 수 있도록 깊이 있는 기술력 기반의 엔터프라이즈 VKS 전환을 수행합니다.

워크로드 도메인 안의 Supervisor와 그 위에 올라가는 네임스페이스 · 클러스터 구조
워크로드 도메인 안의 Supervisor와 그 위에 올라가는 네임스페이스 · 클러스터 구조
02

워크로드 특성 분석부터 최적의 배치까지, 명확한 기준을 가이드합니다

모든 컨테이너 워크로드를 무조건 VKS로 이전하는 것이 항상 최선의 정답은 아닙니다. 소프트웍스는 단순 이관에 그치지 않고, 기존 Kubernetes 환경을 그대로 유지해야 할 워크로드와 VKS(vSphere 자원) 위로 통합했을 때 가장 효율적인 워크로드를 명확히 구분합니다. 다년간 축적된 엔지니어링 노하우를 바탕으로 시스템의 안정성, 비용, 운영 편의성을 모두 고려한 워크로드 배치 가이드라인을 제시합니다.

컨테이너 워크로드를 VKS에 둘지 별도 클러스터에 둘지 가르는 세 가지 기준
컨테이너 워크로드를 VKS에 둘지 별도 클러스터에 둘지 가르는 세 가지 기준
03

기존 TKG 환경의 호환성을 정밀 진단하고, VKS로의 성공적인 전환을 제공합니다

기존 Tanzu Kubernetes Grid(TKG) 환경이 최신 vSphere Kubernetes Service(VKS) 체계로 통합되면서 API 규격 및 리소스 정의 방식에 변화가 생겼습니다. 소프트웍스는 이전 버전에서 사용하시던 인프라 구성과 리소스가 최신 VKS 환경에서 정상 동작하는지 사전 호환성을 정밀하게 진단합니다. 진단 결과에 따라 기존 아키텍처를 현재 기준에 맞게 수용 · 재설계하여, 중단 리스크 없는 VKS 마이그레이션을 제공합니다.

04

가상화부터 Kubernetes까지, 하나의 전담 팀이 끝까지 책임집니다

VKS(vSphere Kubernetes Service)의 안정성은 결국 이를 받쳐주는 하부 가상화 자원의 설계 품질에 좌우됩니다. 인프라 영역과 Kubernetes 영역을 따로 나누어 사업을 추진하면, 정작 장애나 성능 저하가 발생했을 때 책임 소재가 불분명해지는 큰 위험이 따릅니다. 소프트웍스는 가상화 인프라와 Kubernetes 기술을 모두 이해하는 통합 전담 팀이 프로젝트 처음부터 끝까지 직접 수행합니다. 기술 간 경계에서 생기는 시행착오를 없애고, 가장 안정적인 모던 인프라 환경을 완성합니다.

Scope of Work

진단부터 운영까지, 소프트웍스가 맡는 범위

Assess

진단

컨테이너 워크로드 인벤토리 · 기존 Kubernetes 환경 진단 · 배치 기준 수립 · TKG 전환 영향도 확인

Design

설계

Supervisor 및 네임스페이스 설계 · 클러스터 규모와 노드 구성 산정 · 스토리지 클래스 설계 · 네트워크 및 접근 정책 설계 · 백업 연계 설계

Build

구축

Supervisor 활성화 · 클러스터 배포 및 표준 구성 · 레지스트리와 CI 연동 · 성능 검증

Migrate

전환

대상 워크로드 이관 · 기존 TKG 리소스 정의 전환 · 단계별 전환 계획 및 롤백 기준

Operate

운영

운영 인수인계 · 관리자 교육 · 클러스터 수명 주기 절차 수립 · 기술 지원 체계 연결

Knowledge Base

클러스터는 만드는 것보다, 사방으로 늘어난 뒤가 진짜 문제입니다

Kubernetes 환경에서 진정한 운영의 위기는 클러스터가 하나일 때가 아니라, 부서별 요구에 따라 여러 개로 늘어난 이후에 찾아옵니다. 제각각인 쿠버네티스 버전, 통제되지 않는 접근 권한과 자원 할당은 인프라 담당자의 가장 큰 골칫거리입니다. 소프트웍스는 다수의 엔터프라이즈 멀티 클러스터 환경을 직접 구축하고 운영해 오며 축적한 노하우를 가지고 있습니다. 단순히 클러스터를 만들어 주는 데 그치지 않고, 확장 이후의 운영 복잡도를 근본적으로 낮추는 설계 기준을 프로젝트 초기 단계부터 이식합니다.

  • 복수 클러스터통합 관리 제품 운영 경험
  • 팀 · 업무별 격리 및 권한 경계 설계네임스페이스 분할 기준과 상한 설정 패턴
  • 수명 주기버전 정책과 업그레이드 절차 표준

축적된 자산

  • 컨테이너 워크로드 배치 기준표
  • 네임스페이스 분할 패턴 (팀 · 업무 · 환경)
  • 클러스터 규모 산정 기준
  • 스토리지 클래스 선택 기준
  • 버전 정책과 업그레이드 절차서
  • 접근 권한 설계 패턴
  • TKG 전환 점검 항목
  • 네트워크 대역 설계 기준 (관리 · 워크로드 · Pod · 서비스)
  • 폐쇄망 컨테이너 이미지 반입 절차
  • PoC 수행 항목 체크리스트 (Supervisor · 네임스페이스 · 클러스터 · 배포 검증)
Field Issues

현장에서 자주 마주치는 6가지 문제

현장에서 생기는 문제소프트웍스의 해법
“컨테이너 환경을 따로 두어야 할지 통합해야 할지 모르겠습니다”소프트웍스는 워크로드의 기술적 특성과 운영 조직의 체계를 기준으로 가장 합리적인 배치를 제안합니다. 기존 가상화 자원을 유연하게 재사용하면서 단일 콘솔을 통해 통합 운영하는 것이 핵심 목표라면 VKS(vSphere Kubernetes Service)가 가장 명쾌한 답입니다. 반면, 독자적인 배포 수명 주기나 철저한 환경 격리가 필요한 특수 워크로드는 별도로 분리해 두는 것이 바람직합니다. 시행착오 없이 인프라 효율을 극대화할 수 있도록 명확한 배치 아키텍처를 가이드합니다
“기존 TKG 환경에서 그대로 올릴 수 있습니까”TKG가 VKS로 통합되는 과정에서 릴리스 명칭과 일부 리소스 정의 방식이 새로워졌습니다. 따라서 기존 환경의 매니페스트를 그대로 올려 사용할 수 있는지 사전 검증 과정이 반드시 필요합니다. 소프트웍스는 전환 작업에 착수하기 전, 현재 사용 중인 리소스의 호환 여부를 철저히 진단합니다. 변경이 필요한 영역과 영향 범위를 명확히 식별한 후, 서비스 중단을 최소화하는 최적의 전환 순서와 보완 가이드를 제시합니다
“클러스터가 팀마다 늘어나 관리가 되지 않습니다”클러스터가 사방으로 늘어날 때 발생하는 버전 혼선과 관리 부담은 기업 IT 운영의 고질적인 문제입니다. 소프트웍스는 우선 무분별한 클러스터 증설을 지양하고, 단일 클러스터 내에서 네임스페이스를 활용해 팀과 업무 단위의 견고한 경계를 나누는 설계 패턴을 검토합니다. 아울러 비즈니스 요건상 클러스터를 반드시 분리해야 하는 환경에서는, 사전에 엄격한 버전 관리 정책과 업그레이드 주기를 수립한 뒤 확장에 나섭니다
“컨테이너 환경의 백업 범위를 정하기 어렵습니다”소프트웍스는 아키텍처 진단을 통해 가장 합리적인 백업 범위를 제시합니다. 먼저 상태 유지가 필요한 자원(Stateful)과 단순 처리용 자원(Stateless)을 정확히 구분합니다. 이어 데이터 손실이 없어야 하는 영속 볼륨(PV)과 클러스터 재생성에 필요한 구성 정보(YAML · etcd)를 독립된 보호 대상으로 지정합니다. 이를 전사 백업 체계와 통합 연계하여, 장애 상황에서도 단시간 내 복구가 가능한 안전망을 구축합니다
“폐쇄망이라 컨테이너 이미지를 외부에서 받을 수 없습니다”보안이 엄격한 공공 및 금융 기관의 폐쇄망 환경에서는 외부 공인 저장소에 접근할 수 없어 컨테이너 이미지 확보와 배포가 큰 난관이 됩니다. 소프트웍스는 먼저 내부 인프라에 안전한 컨테이너 이미지 레지스트리를 구축하고, 보안 검증을 통과한 이미지만 정해진 반입 절차를 거쳐 등록되도록 관리 체계를 잡습니다. 아울러 기존 설정 파일이나 Helm Chart 등에 남아 있는 외부 저장소 참조 경로를 내부 레지스트리로 일괄 변환하는 작업까지 빠짐없이 수행하여, 외부 통신 오류나 경로 설정 누락이 없는 폐쇄망 배포 환경을 완성합니다
“NSX 없이도 구성할 수 있습니까”NSX 오버레이 네트워크 대신 표준 vSphere 네트워킹 구조에 외부 로드밸런서를 연동하는 실용적인 대안 아키텍처를 제공합니다. 다만 NSX 미도입 시에는 분산 방화벽(마이크로세그멘테이션) 설정이나 네임스페이스 단위의 세밀한 네트워크 정책 구현에 기술적 한계가 존재합니다. 소프트웍스는 무조건적인 NSX 도입을 권하지 않으며, 고객사의 실제 보안 정책과 예산 상황을 사전에 객관적으로 평가합니다. 표준 네트워킹으로도 충분한 환경인지, NSX가 필수적인 보안 요건인지를 명확히 가려내어 가장 경제적이고 안전한 네트워크 경로를 제시합니다

“NSX 없이도 구성할 수 있습니까”

NSX를 쓰는 구성과 vSphere 네트워킹에 로드밸런서를 붙이는 구성의 비교
NSX를 쓰는 구성과 vSphere 네트워킹에 로드밸런서를 붙이는 구성의 비교
Components

vSphere Kubernetes Service를 이루는 네 가지 구성요소

VKS는 vSphere 클러스터 위에 제어 계층을 올려 Kubernetes 클러스터를 유연하게 배포하고 통합 관리합니다. 소프트웍스는 각 핵심 구성요소가 최고의 성능과 안정성을 발휘할 수 있도록 사전 검토와 아키텍처 설계 가이드를 함께 제공합니다.

01

Supervisor

vSphere 클러스터를 스마트한 Kubernetes 제어 허브로 변환합니다

Supervisor는 vSphere 클러스터의 잠재력을 극대화하여 강력한 Kubernetes 제어 계층으로 작동하게 만드는 핵심 기능입니다. 클러스터에 Supervisor가 활성화되면, 관리자는 네임스페이스 단위로 정교하게 자원을 분할하여 Kubernetes 클러스터와 전통적인 가상 머신(VM)을 동일한 인프라 위에서 조화롭게 배포할 수 있습니다. 복잡한 이중 구조를 없애고, 가상화와 컨테이너를 하나의 체계 안에서 효율적으로 운영할 수 있는 길을 제시합니다.

Supervisor 위의 Kubernetes Service · VM Service · Supervisor Service
Supervisor 위의 Kubernetes Service · VM Service · Supervisor Service
제어 계층 가상 머신과 각 호스트에 올라가는 에이전트 배치
제어 계층 가상 머신과 각 호스트에 올라가는 에이전트 배치
소프트웍스가 하는 일

Supervisor를 활성화할 클러스터 선택은 VKS 전체의 안정성을 좌우하는 첫 단추입니다. 기존 운영 업무가 올라간 클러스터에 그대로 활성화하면 예기치 못한 자원 경합이 발생할 위험이 있습니다. 소프트웍스는 프로젝트 착수 단계에서 고객사의 현재 자원 여유량과 장애 발생 시 영향 범위를 다각도로 검토합니다. 전용 클러스터를 별도 구성할지, 기존 클러스터를 증설할지에 대해 현장 환경에 가장 부합하는 아키텍처 가이드라인을 제시합니다.

02

네임스페이스 · 자원 할당

팀과 업무 단위로 완벽한 자원 경계를 세웁니다

다중 사용자 환경에서 가장 중요한 것은 각 팀의 자원과 권한이 서로 침범하지 않도록 안전한 울타리를 치는 것입니다. VKS 환경에서는 네임스페이스 단위로 CPU, 메모리, 스토리지의 상한을 설정하고 접근 권한을 명확히 지정할 수 있습니다.

Supervisor 위에 올라가는 네임스페이스 경계와 그 안의 클러스터 · 가상 머신
Supervisor 위에 올라가는 네임스페이스 경계와 그 안의 클러스터 · 가상 머신
네임스페이스 한 칸에 CPU · 메모리 · 스토리지 상한이 걸리는 구조
네임스페이스 한 칸에 CPU · 메모리 · 스토리지 상한이 걸리는 구조
소프트웍스가 하는 일

소프트웍스는 조직의 규모와 업무 특성에 맞는 최적의 네임스페이스 분할 기준을 제안합니다. 이 체계 안에서 개발팀은 할당된 리소스 범위 내에서 자유롭게 클러스터를 생성하며 신속하게 개발을 진행할 수 있습니다. 인프라 통제력과 개발 편의성을 모두 잡는 아키텍처 가이드를 제공합니다.

03

Kubernetes 클러스터 배포

표준 규격의 클러스터를 손쉽게 생성하고 관리합니다

VKS 환경에서는 정해진 네임스페이스 내부에서 검증된 릴리스 버전을 바탕으로 표준 Kubernetes 클러스터 노드들을 즉시 구성할 수 있습니다. 특히 클러스터의 신규 배포부터 자원 확장, 버그 수정 및 버전 업그레이드에 이르는 전 과정이 선언적 정의 파일(YAML)을 통해 이뤄지므로 관리 편의성이 비약적으로 향상됩니다.

클러스터 생성과 확장을 담당하는 내부 구성요소
클러스터 생성과 확장을 담당하는 내부 구성요소
소프트웍스가 하는 일

소프트웍스는 서비스 특성에 맞는 노드 스펙과 안정적인 업그레이드 수명 주기(Lifecycle) 기준을 사전에 안내하여, 지속 가능하고 안전한 클러스터 운영 환경을 구성합니다. 정의 파일은 고객 자산으로 인수인계합니다.

04

VM Service

가상 머신도 컨테이너와 똑같은 방식으로 다룹니다

클라우드 네이티브로의 전환 과정에서 컨테이너로 바로 이식하기 힘든 워크로드는 여전히 존재합니다. VM Service는 이러한 워크로드를 위해 동일한 네임스페이스 환경 내에서 가상 머신(VM)을 신속하게 배포할 수 있는 환경을 제공합니다. 가상 머신과 컨테이너가 동일한 자원 할당량과 접근 권한 체계를 공유하므로, 관리자는 이중 관리의 부담 없이 일관된 보안 및 자원 정책을 유지할 수 있습니다.

이미지와 VM 클래스, 스토리지 정책을 묶어 가상 머신을 만드는 흐름
이미지와 VM 클래스, 스토리지 정책을 묶어 가상 머신을 만드는 흐름
소프트웍스가 하는 일

소프트웍스는 컨테이너 전환 대상과 VM 유지 대상을 정밀하게 분류합니다. 이를 통해 기존 자산을 보호하면서도 가상 머신과 컨테이너가 유기적으로 연동되는 가장 합리적인 모던 인프라를 완성합니다.

출처구성요소 설명에 사용한 도식은 Broadcom 공식 기술 문서에 공개된 자료이며, 일부는 소프트웍스가 다시 그렸습니다.

References

구축 사례

고객 구분수행 사업수행 범위
공공 · 시험인증기관라이브 가상화 환경 내 Kubernetes 통합 운영 체계 구축 완료Supervisor · 네임스페이스 · 컨테이너 레지스트리 PoC
Operation & Support

구축 이후에도 기술 지원은 이어집니다

Kubernetes는 버전 주기가 짧아 구축 완료 이후에도 업그레이드가 반복됩니다. 구축을 수행한 엔지니어가 그대로 기술 지원 창구를 담당합니다.

  • 클러스터 상태 정기 점검
  • 버전 업그레이드 기술 지원
  • 네임스페이스 자원 상한 재조정
  • 장애 1차 분석 및 제조사 에스컬레이션
  • 연 1회 아키텍처 리뷰

글로벌 기술 리더의 솔루션과 소프트웍스의 구축·운영 역량을 결합해 고객의 디지털·AI 전환 환경을 제공합니다.

컨테이너 운영, 가상화 위에서 시작하십시오

워크로드 분류와 Supervisor · 클러스터 설계부터 함께 검토합니다.

도입·컨설팅 문의 →